US20080184128A1 - Mobile device user interface for remote interaction - Google Patents

Abstract

Systems and methods pertaining to displaying a web browsing session are disclosed. In one embodiment, a system includes a web browsing engine residing on a first device, with a viewing application residing on a second device and operatively coupled to the web browsing engine, where the viewing application is adapted to display a portion of a webpage rendered by the web browsing engine and an overlay graphical component. In the same embodiment, the system also includes a recognition engine adapted to identify an element on the webpage and communicate information regarding the element to the viewing application.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• The present application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application No. 60/886,577, filed on Jan. 25, 2007, entitled “SYSTEM FOR WEB BROWSING VIDEO,” which is incorporated by reference in its entirety.
BACKGROUND
• The present invention relates to a system for displaying a web browsing session. In particular, the present invention is related to a viewing application for displaying a web browsing session from a separate device.
• Access to applications, including web browsers, is provided for in various client-server environments. Placing a web browser on a server for delivery to a client presents a large number of issues, including issues with the delivery of the browsing experience to the client user, such as handling interactive objects within a web page. For interaction with handheld clients, such as cellular phones, bandwidth and display size constraints pose additional challenges in delivering a satisfactory web browsing experience from a server, including dealing with any latency within the system evident to the end user.
• There exists a need to support full-featured web browsing sessions on a diverse cross-section of bandwidth and capability-limited mobile devices in a way that addresses these challenges and advantageously utilizes a client-server environment, as well as to support the use of other applications in this same manner. Embodiments of this invention will address other needs as well.
SUMMARY
• In various embodiments, the present invention provides systems and methods pertaining to displaying a web browsing session. In one embodiment, a system includes a web browsing engine residing on a first device, with a viewing application residing on a second device and operatively coupled to the web browsing engine, where the viewing application is adapted to display a portion of a webpage rendered by the web browsing engine and an overlay graphical component. In the same embodiment, the system also includes a recognition engine adapted to identify an element on the webpage and communicate information regarding the element to the viewing application.
• In another embodiment, a system for displaying a web browsing session includes a recognition engine further adapted to communicate information regarding the element to the viewing application responsive to the viewing application passing user input to the recognition engine. In yet another embodiment, such user input comprises a selection of a location on the webpage displayed on the second device, the location corresponding to the element's location on the webpage.
• In still yet another embodiment, a system for displaying a web browsing session includes a recognition engine further adapted to communicate information regarding the element to the viewing application with the portion of the webpage.
• In a further embodiment, the system further comprises a state manager engine operatively coupled to the viewing application and the web browsing engine, the state manager engine adapted to synchronize user input displaying locally on the viewing application with user input transferred to the web browsing engine.
• One skilled in the art will recognize that the present invention can be implemented in a wide variety of ways, and many different kinds of apparatus and systems may implement various embodiments of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a block diagram illustrating some aspects of a client-server architecture of the present invention, according to one embodiment.
• FIG. 2 is a block diagram illustrating some aspects of the present invention in connection with a server, according to one embodiment.
• FIG. 3 is a block diagram illustrating some aspects of an architectural overview of the present invention, including a server, an audio server and a client, according to one embodiment.
• FIG. 4 is a block diagram illustrating some aspects of the present invention in connection with a client, according to one embodiment.
• FIG. 5 is a diagram illustrating some aspects of multiple-user software architecture, according to one embodiment.
• FIG. 6 is a flowchart illustrating some supporting aspects of capturing a succession of video frames, according to one embodiment.
• FIG. 7 is a flowchart illustrating some supporting aspects of sending a succession of video frames, according to one embodiment.
• FIG. 8 is a diagram illustrating some aspects of a client-server exchange, according to one embodiment.
• FIG. 9 is a diagram illustrating some aspects of a client-server exchange, including an accompanying exchange within the server, according to one embodiment.
• FIG. 10 is a diagram illustrating some aspects of viewport move operations and related state management, according to one embodiment.
• FIG. 11 is a diagram illustrating some aspects of a client-server exchange with respect to state management, according to one embodiment.
• FIG. 12 is a diagram illustrating some aspects of a client-server exchange, including an accompanying exchange between a server and network storage, according to one embodiment.
• FIG. 13 is a diagram illustrating some aspects of displaying a web browsing session from a server to a cellular phone, according to one embodiment.
• FIG. 14 is a diagram illustrating some aspects of a user interface display, according to one embodiment.
• FIG. 15 is a diagram illustrating some aspects of a user interface display, according to one embodiment.
• FIG. 16 illustrates an example computer system suitable for use in association with a client-server architecture for remote interaction, according to one embodiment.
• One skilled in the art will recognize that these Figures are merely examples of the operation of the invention according to one or some embodiments, and that other architectures, method steps, exchanges and modes of operation can be used without departing from the essential characteristics of the invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS
• The present invention is now described more fully with reference to the accompanying Figures, in which one or some embodiments of the invention are shown. The present invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather these embodiments are provided so that this disclosure will be complete and will fully convey principles of the invention to those skilled in the art.
• For illustrative purposes, embodiments of the invention are described in connection with a server or a mobile client device, such as an example mobile client device. Various specific details are set forth herein regarding embodiments with respect to servers and mobile client devices to aid in understanding the present invention. However, such specific details are intended to be illustrative, and are not intended to restrict in any way the scope of the present invention as claimed herein. In particular, one skilled in the art will recognize that the invention can be used in connection with a wide variety of contexts, including, for example, client devices operating in a wired network. In addition, embodiments of the invention are described in connection with a web browsing application, but such descriptions are intended to be illustrative and examples, and in no way limit the scope of the invention as claimed. Various embodiments of the invention may be used in connection with many different types of programs, including an operating system (OS), a wide variety of applications, including word processing, spreadsheet, presentation, and database applications, and so forth.
• In some embodiments, the present invention is implemented at least partially in a conventional server computer system running an OS, such as a Microsoft OS, available from Microsoft Corporation; various versions of Linux; various versions of UNIX; a MacOS, available from Apple Computer Inc.; and/or other operating systems. In some embodiments, the present invention is implemented in a conventional personal computer system running an OS such as Microsoft Windows Vista or XP (or another Windows version), MacOS X (or another MacOS version), various versions of Linux, various versions of UNIX, or any other OS designed to generally manage operations on a computing device.
• In addition, the present invention can be implemented on, or in connection with, devices other than personal computers, such as, for example, personal digital assistants (PDAs), cell phones, computing devices in which one or more computing resources is located remotely and accessed via a network, running on a variety of operating systems. The invention may be included as add-on software, or it may be a feature of an application that is bundled with a computer system or sold separately, or it may even be implemented as functionality embedded in hardware.
• Output generated by the invention can be displayed on a screen, transmitted to a remote device, stored in a database or other storage mechanism, printed, or used in any other way. In addition, in some embodiments, the invention makes use of input provided to the computer system via input devices such as a keyboard (screen-based or physical, in a variety of forms), scroll wheels, number pads, stylus-based inputs, a touchscreen or touchpad, etc. Such components, including their operation and interactions with one another and with a central processing unit of the personal computer, are well known in the art of computer systems and therefore are not depicted here.
• Any software portions described herein with reference to modules need not include discrete software modules. Any software configuration described herein is meant only by way of example; other configurations are contemplated by and within the scope of various embodiments of the present invention. The term, engine, is used herein to denote any software or hardware configuration, or combination thereof, that performs the function or functions referenced.
• Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearance of the phrase “in one embodiment” in various places in the specification does not necessarily refer to the same embodiment. The appearance of the phrase “in some embodiments” in various places in the specification are not necessarily all referring to the same set of embodiments. The appearance of the phrase “in various embodiments” in various places in the specification are not necessarily all referring to the same set of embodiments.
1. System
• FIG. 1 is a block diagram illustrating some aspects ofsystem100 of the present invention, according to one embodiment.System100 employs a client-server architecture that includes a number of server application instances running onserver200, including server application1 (102), server application2 (104), server application3 (106), and a wide-ranging number of additional server applications (represented by ellipsis108), up to server application n (110). The term “server application” is used herein to denote a server-side application, i.e., an application running on one or more servers. Server application n (110) represents the number of server application instances that happen to be running insystem100 at any given point.Server200 also includesuser manager module502, which serves to manage multiple users among the multiple server application instances102-110.User manager module502 is described herein inFIG. 5, and represents one of potential multiple user managers running onserver200.Server200 is running one instance of an OS underlying server applications102-110. In another embodiment,server200 may run multiple instances of an OS, each OS instance including one or more application instances.Server200 also includesprovision manager module1205, which is described herein inFIG. 12.
• WhileFIG. 1 illustrates multiple server applications102-110, in other embodiments, a number of different types of programs may be alternately used, including, for instance, an OS. Server applications102-110 illustrated inFIG. 1 may run on oneserver200 or any number of servers, as, for example, in one or more server farm environments. Server applications102-110 may each comprise instances of different server applications, or may all comprise an instance of one server application. For example, each server application102-110 could comprise a separate instance of a web browsing application.
A. Server
• Describing server application1 (102) in further detail, as an example server application instance, server application1 (102) includesapplication112,plugin114,state manager module115,recognition module117,audio data generator116,audio encoder module120,video encoder module124, andcommand process module126.Video encoder module124 makes use offeedback parameter125.
• Video encoder module124 is operatively coupled toapplication112, and is adapted to receive a succession of captures (122) of the user interface (UI) ofapplication112 for encoding into video frames for transmission vianetwork128. The succession of captures (122) of the UI comprise data that is captured and transferred fromapplication112 tovideo encoder124 by a separate module, described and illustrated inFIG. 2 (image management module216).State manager module115 manages state information, as will be described in relation to subsequent Figures.Recognition module117 identifies elements related to output ofapplication112, as will be described in relation to subsequent Figures. The term, user interface, as used throughout this disclosure, refers to all or a portion of any user interface associated with a wide variety of computer programs.
• The encoding of application UI captures (122) is not limited to any particular encoding or video compression format, and may include a wide variety of video compression techniques, ranging from the use of a video compression standard, such as H.264, to an entirely customized form of video compression, to a modified version of a video compression standard, and so forth.
• Audio encoder module120 is operatively coupled toaudio data generator116 ofapplication112, and is adapted to transform audio captures118 (e.g., an audio stream) ofaudio data generator116 into an encoded audio stream for transmission vianetwork128. Audio captures118 comprises data being transferred fromaudio data generator116 toaudio encoder module120.
• Audio data generator116 is operatively coupled toapplication112, and is adapted to generate the audiodata accompanying application112.Plugin114 is operatively coupled toapplication112 andcommand process module126.Plugin114 is adapted to facilitate the interface betweenapplication112 andcommand process module126.
• Server200 is further described herein inFIG. 2.
C. Client
• System100 includes a number of clients, including client1 (400), client2 (132), client3 (134), and a wide-ranging number of additional clients (represented by ellipsis136), up to client n (138), with client n (138) representing the number of clients that happen to be engaged in the system at any given point. As illustrated inFIG. 1, the different clients comprise different, non-related client devices.
• Describing client1 (400) in further detail, as an example client, client1 (400) may includeaudio decoder module142,video decoder module144,command process module146,viewing application148,state manager module149, andspeaker150.Video decoder module144 may be adapted to decode the succession of video frames encoded byvideo encoder module124, where the successive video frames have been transmitted acrossnetwork128 for reception by client1 (400).Video decoder module144 may be operatively coupled toviewing application148, and adapted to communicate the decoded video frames toviewing application148 for display of the video frames on client1 (400).State manager module149 manages state information, as will be described in relation to subsequent Figures.
• Client1 (400) includesspeaker150, andaudio decoder module142 is operatively coupled tospeaker150.Audio decoder module142 is adapted to decode the audio captures encoded byaudio encoder module120, where the encoded audio has been transmitted acrossnetwork128 for reception by client1 (400). After decoding the audio stream,audio decoder module142 may communicate the decoded audio tospeaker150 for audio output from client1 (400).
• Viewing application148 is adapted to receive user input and communicate the user input to commandprocess module146.Command process module146 is adapted to communicate the user input back tocommand process module126 ofapplication102 vianetwork128.Command process module126 is adapted to communicate the user input toapplication112 viaplugin114.
• Plugin114 facilitates the remote interactive use ofapplication112 via thesystem100 described inFIG. 1.Plugin114 may also be an extension. In another embodiment,application112 may be customized for use with the client-server architecture of this invention to the extent that a special plugin is not needed. In yet another embodiment, neither a plugin or special application modifications may be needed.
• Command process module146 is adapted to communicate one ormore feedback parameters125 tocommand process module126.Command process module126 is adapted to communicate the one ormore feedback parameters125 tovideo encoder module124 andaudio encoder module120 for their respective encoding of the succession of application UI captures122 and audio captures118. The one ormore feedback parameters125 may comprise one or more of a wide range of parameters, including a bandwidth parameter relating to at least a portion ofnetwork128, a device parameter of client1 (400) or a user input for client1 (400).
• The one ormore feedback parameters125 may comprise a bandwidth parameter, which may include any estimated or measured bandwidth data point. An example bandwidth parameter may include estimated bandwidth based on measurements of certain packets traversing betweenserver200 and client1 (400), (e.g., how much data sent divided by traversal time to obtain a throughput value), or other bandwidth information obtained from, or in conjunction with,network128, including from a network protocol. The one ormore feedback parameters125 may comprise user input for client1 (400), including, for example, a user request for encoding performed in a certain format or manner, with such a request being requested and communicated by viewingapplication148. The one ormore feedback parameters125 may comprise a display resolution of client1 (400) (e.g., CGA, QVGA, VGA, NTSC, PAL, WVGA, SVGA, XGA, etc.). The one ormore feedback parameters125 may comprise other screen parameters (e.g., screen size, refresh capabilities, backlighting capabilities, screen technology, etc.) or other parameters of the client device (e.g., device processor, available memory for use in storing video frames, location if GPS or other location technology-enabled, etc.). None of the example feedback parameters discussed above are meant to exclude their combined use with each other, or other feedback parameters. In some embodiments,video encoder module124 may be adapted to at least partially base its video sample rate on the one ofmore feedback parameters125.
• The multiple clients depicted inFIG. 1 are illustrated to indicate that each client may potentially comprise a different type of client device, each with its own one or more feedback parameters.
• Client1 (400) is further described herein inFIG. 4.
• One skilled in the art will recognize that the client-server architecture illustrated inFIG. 1 is merely an example, and that the invention may be practiced and implemented using many other architectures and environments.
• FIG. 2 is a block diagram illustrating some aspects of the present invention in connection withserver200, according to one embodiment.Server200 includesuser manager module502,provision manager module1205, server application1 (102),application112,plugin114,state manager module115,recognition module117,audio data generator116,audio encoder module120,image management module216,memory218, video encoder module124 (which includes feedback parameter125),command process module126, and alignmodule224.Command process module126 includesclient interpreter sub-module228, andplugin114 includes client implementersub-module208. The components illustrated inFIG. 2 with the same numbers as components illustrated inFIG. 1 correspond to those respective components ofFIG. 1, and thus their general operation will not be repeated. While one running application is illustrated with respect toserver200,server application102 is illustrated as a representative instance of multiple server applications running onserver200, each of the multiple server applications being associated with its own distinct client (clients are not shown in this illustration). Additionally,user manager module502 represents one of potential multiple user managers running onserver200.
• Image management module216 serves to capture the UI of application112 (as the UI would appear on a screen) and save the capture inmemory218. Any capture process such as screen-scraping may be used, andimage management module216 may perform this capture at any desired rate.Image management module216 also compares the last prior capture of the application UI to the current capture to determine whether any changes have occurred in a particular area of the application UI. Any image/video frame matching process may be used for this comparison operation.Image management module216 serves to repetitively perform this function.
• Ifimage management module216 detects any change in the particular area of interest, a delta flag is set to indicate that the area of interest has changed. Upon detecting a change,image management module216 serves to convert the native format of the UI rendered data to a video frame format more suited for compression and transmission to the client device (e.g., color space transformation, data format transformation, etc.).Image management module216 serves to resize the image for the reformatted video frame. In the embodiment ofFIG. 2, multiple parameters of the applicable client device were included in the one ormore feedback parameters125, allowingimage management module216 to perform the reformatting and resizing based on client device parameters (the relevant parameters having been communicated to image management module216).
• Image management module216 periodically checks (based on its sample interval) if the delta flag has been set. If the delta flag is detected as set during a check, the reformatted/resized video frame inmemory218 is encoded byvideo encoder module124 for transmission to the client device.
• Client interpreter sub-module228 ofcommand process module126 serves to interpret data received fromclient device400 and to translate this data for use in connection withvideo encoder module124,audio encoder module120 and application112 (e.g., user commands, etc.).Client interpreter sub-module228 serves to pass thefeedback parameters125 tovideo encoder module124 andaudio encoder120 for use in encoding.
• Client interpreter sub-module228 ofcommand process module126 serves to translate client-received data for use in connection withplugin114 and its client implementersub-module208. In communicating back user input, the client device passes coordinates (of a cursor, etc.) relative to the client device's screen to commandprocess126.Client interpreter sub-module228 serves to determine the corresponding location in relation to the viewport of the client device and the application UI. Client interpreter sub-module228 then communicates the translated coordinates toplugin114 for use by its client implementersub-module208. Client implementer sub-module208 serves to translate from conventional user input to a format appropriate forapplication112, and then to directly inject the translated input intoapplication112.
• Align module224 correlates and cross-stamps video frames encoded byvideo encoder module124 and audio encoded byaudio encoder module120, so that the audio stream and the video frames associated with the UI ofapplication112 may be readily matched atclient device400.Image management module216 may also serve to time-stamp all images, and the operation of capturing audio fromaudio data generator116 may also serve to timestamp the audio stream, both for down-stream alignment byalign module224, as would be appreciated by one skilled in the art. In another embodiment, all alignment/matching of audio and video frames may be performed at the client device.
• One skilled in the art will recognize that the illustration ofFIG. 2 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 3 is a functional block diagram300 illustrating some aspects of an architectural overview of the present invention, including a server, an audio server and a client, according to one embodiment. In this embodiment, audio is sent to the client from dedicatedaudio server304. Functional block diagram300 includesserver302,audio server304 andclient306, withclient306 operatively linked toserver302 andaudio server304 via network310 (viaconnections312,314 and316).Server302 is operatively linked toaudio server304 viaconnection308.Server302 includesapplication318,plugin322,state manager module323,recognition module327,audio data generator320, video encoder module324 (including feedback parameter325),command process module326,audio interceptor module330, PID (process identifier)manager module332, and time-stamp manager module334.
• Video encoder module324 operates as described inFIG. 2, being analogous to video encoder module124 (and likewise, forfeedback parameter325 with respect to feedback parameter125).Video encoder module324 operates to encode application UI captures328 and to communicate the encoded video frames for transmission toclient306. In the process of obtaining application UI captures, the resulting UI captures are time-stamped. Time-stamp manager module334 facilitates the time-stamping of the UI captures.Command process module326 operates as described inFIG. 2, being analogous tocommand process module126.
• While one running application is illustrated with respect toserver302,application318 is illustrated as a representative instance of multiple applications running onserver302, each of the multiple applications having its own video encoder and command process modules, and being associated with its own distinct client.Audio data generator320 renders an audio stream (not shown) forapplication318.Audio interceptor module330 intercepts or traps this audio stream for redirection toaudio server304, and may timestamp the audio stream. Time-stamp manager module334 may facilitate the time-stamping of the audio stream.Audio interceptor module330 may make use of a customized DLL to facilitate such a redirection of the audio stream.PID manager module332, serves to detect and manage the different process IDs of the multiple applications running onserver302.PID manager module332 may stamp each audio stream redirected to audio server with the process ID of its associated application.
• Audio server304 includes audiostream processing module336 andPID authentication module338. Audiostream processing module336 serves to encode the audio streams received from the applications running onserver302, and perform any conversion desired (e.g., conversion of sample rates, bit depths, channel counts, buffer size, etc.). In the embodiment ofFIG. 3, User Datagram Protocol ports are used (not shown) to direct each audio stream to its destination client device; other protocols may be used in other embodiments. Audiostream processing module336 directs each audio stream to the port associated with the audio stream's corresponding client device (i.e., the client device displaying the video frames corresponding to the audio stream). Audiostream processing module336 may work in association withPID authentication module338 to verify and direct the multiple audio streams streaming fromserver302 to the appropriate port.
• Client306 includesvideo decoder module340,audio decoder module342,command process module344 and audio/video sync module346. Afterclient306 receives and decodes the applicable audio and video streams from server302 (i.e., the audio and video streams of the application instantiated for client306), audio/video sync module346 correlates the time-stamps on both streams and works in conjunction withaudio decoder module342 andvideo decoder module340 to synchronize output tospeaker348 andviewing application350, respectively.Client306 also includesstate manager module351 to manage state information.
• One skilled in the art will recognize that the illustration ofFIG. 3 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 4 is a block diagram illustrating some aspects of the present invention in connection with a client, according to one embodiment.Client400 includesvideo decoder module144,audio decoder module142, audio/video sync module406,command process module146,speaker150,viewing application148,state manager module149, andconnections410,412 and414.
• Video decoder module144 receives encoded video frames viaconnection412, whileaudio decoder module142 receives an encoded audio stream via connection414. Audio/video sync module406 serves to match time-stamps or another type of identifier on the audio stream and the video frames for synced output viaspeaker150 andviewing application148, respectively.Audio decoder module142,video decoder module144 andviewing application148 all may serve to provide feedback tocommand process module146, to communicate back to the server-side application feedback parameters (not illustrated inFIG. 4), including to vary the sample rate and/or compression of the video encoding, the audio encoding, etc.
• Command process module146 serves to pass feedback parameters ofclient400 for use in video and/or audio encoding upon initiation of a session or during a session. Such feedback parameters may include one or more of the following parameters: display resolution, screen size, processor identification or capabilities, memory capabilities/parameters, speaker capabilities, and so forth.
• Viewing application148 displays the succession of video frames of a portion of the server-side application's UI.Viewing application148 serves to facilitate communicating user input control, including user commands, to commandprocess module146 for transmission back to the server. Client user input control passed back to the server may include, for example, input from: a keyboard (screen-based or physical, in a variety of forms), scroll wheels, number pads, stylus-based inputs, a touchscreen or touchpad, etc.Viewing application148 serves to aggregate certain user input for sending, such as opening up a local text box for text entry.State manager module149 manages state information, as will be described in relation to sub-sequent Figures.
• In one embodiment,viewing application148 comprises an application based on the Java Platform, Micro Edition, and portable to BREW (Binary Runtime Environment for Wireless). In other embodiments,viewing application148 comprises an application based on the Symbian platform, a Linux-based platform (e.g., Android), a Palm platform, a Pocket PC/Microsoft Smartphone platform, or another platform capable of supporting the functionality described herein. In some embodiments,viewing application148 runs as a stand alone Java application, while in other embodiments,viewing application148 runs as a plugin to a standard mobile browser, as would be appreciated one skilled in the art. In one embodiment,viewing application148 includes a number of modules to facilitate implementing the functionality described herein, including modules to facilitate browser navigation, client I/O and viewport tracking (not shown), as would be appreciated by one of skill in the art.
• One skilled in the art will recognize that the illustration ofFIG. 4 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 5 is a diagram500 illustrating some aspects of a multiple-user software architecture, according to one embodiment.User manager module502 includesworker thread504,worker thread506, and a wide-ranging number of additional worker threads (represented by ellipsis508); with ‘worker thread n’ being represented byworker thread510.Worker thread510 represents the total number of worker threads that happen to be running in the system at any given point. Each worker thread corresponds to a list of active users, and the lists of active users may potentially comprise a different number of active users. As illustrated inFIG. 5,worker thread504 corresponds tothread cycle512,worker thread506 corresponds tothread cycle514, the variable number of worker threads represented byellipsis508 corresponds to the same variable number of thread cycles represented byellipsis518, andworker thread510 corresponds tothread cycle516. As illustrated inFIG. 5,worker thread504 cycles through user1 (520), user2 (522), user3 (524) and user4 (526);worker thread506 cycles through user5 (528), user6 (530) and user7 (532); andworker thread516 cycles through user8 (534), user9 (536), user10 (538), user11 (540) and user12 (542). The number of users supported by the worker threads illustrated inFIG. 5 is meant to represent a snapshot at an arbitrary point in time, as the number of users supported by any given thread is dynamic.
• User manager module502 may be set to instantiate a finite number of worker threads before instantiating additional worker threads to manage further users added to the system. The number of worker threads in the overall architecture illustrated byFIG. 5 will vary according to various embodiments. The parameters regarding the number of active users assigned per worker thread will also vary according to various embodiments.
• User manager module502 runs on a server (as illustrated inFIG. 1) where multiple instances of applications (as illustrated inFIG. 1) are also running.User manager module502 thus serves to manage multiple users in an environment of multiple application instances. When a new user is introduced into the overall system ofFIG. 1, the new user is assigned to a worker thread (504-510) to facilitate the interaction between a specific client and a specific server-side application.
• While the embodiment illustrated inFIG. 5 illustrates multiple users being assigned to a single thread, in other embodiments, a single user may be assigned to their own single thread. In other embodiments, a user may be assigned to either a shared thread or a dedicated thread depending on one or more factors, such as the current loading/usage of the overall system, the user's service policy with the provider of the respective service operating an embodiment of this invention, and so forth.
• User manager module502 facilitates load balancing of multiple users in a number of ways, as each worker thread cycles through their respective list of active users and processes one active event for each user. The active events that may be processed include: (a) send one video frame update to the client or (b) update state information pertaining to the client's viewing application and the server-side application/UI. For illustration purposes for the case in whichuser1 is associated with server application1 (102) ofFIG. 1,worker thread512 will time slice between the respective video encoder/command process modules of users1 (520) through4 (526) to perform (a) and (b) above, withvideo encoder module124 andcommand process module126 comprising the video encoder/command process modules of user1 (520). A separate thread (not shown) would be operatively coupled toaudio encoder module120 to continuously send the encoded audio stream to the client, when audio data is present to send.
• By operating in this manner, no single user suffers as a result of a processing-intensive session (e.g., for a high resolution, high frame rate video) of another user being serviced by the same thread. This will be further described below with reference toFIG. 7. In other embodiments, more than one active event may be processed per user. In other embodiments, a variable number of active events may be processed per user, based on a wide range of factors, including the level of underlying application activity for the applicable user, the user's service policy with the provider of the respective service operating an embodiment of this invention, and so forth.
• User manager module502 may move specific users among different worker threads to load balance among processing-intensive users and processing-light users. For example, if multiple users being serviced by one worker thread are in need of being serviced with high frame rate video,user manager module502 may move one or more such users to another thread servicing only, or predominately, processing-light users. Another thread may also be instantiated for this purpose. As one skilled in the art would appreciate, a user may be treated as an object, and moved to another thread as objects are transferred among threads. The timing of such object moves may take place at specific junctures in the display of video frames by a client device's viewing application, in order to minimize disruption of a user's experience.
• One skilled in the art will recognize that the illustration ofFIG. 5 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 6 is aflowchart600 illustrating some supporting aspects of capturing a succession of video frames, according to one embodiment. Operation602 (Render Application UI to memory) is performed initially, either by a plugin to an application or by an application itself.Operation602 serves to capture the UI of an application as the UI would appear on a screen and save the capture in a memory buffer (218 ofFIG. 2); actual display of the UI on a screen is not required, but may be used. Operation604 (Any delta from prior Application UI capture?) then serves to compare the last prior capture of the application UI to the current capture to determine whether any changes have occurred. This delta checking operation may be performed in a wide number of ways, including, for example, hashing pixel blocks of the current UI capture and comparing the hash values to an analogous pixel-hash table generated from the prior UI capture. The hash values may then also be available for potential use in any compression method utilized, e.g., matching blocks of successive video frames, matching blocks against a reference frame, etc. Alternatively, for example, the application may notify the server when a change occurs prior tooperation602.
• Ifoperation604 is determined in the negative, then Operation606 (Delay) may be implemented by a timer (not shown), beforeoperation602 is repeatedly performed. Ifoperation604 is determined in the affirmative, Operation608 (Convert to appropriate format) is then performed.Operation608 serves to convert the native format of the UI rendered data to another format more suited for compression and transmission over a network for display on a client device (e.g., color space transformation, data format transformation, etc.).
• Operation610 (Resize) is then performed.Operation610 serves to resize the native screen size inherent to the UI rendered data to another size more suited for display on a client device (e.g., a cellular phone, a handheld computer, etc.).Operation610 may make use of one or more feedback parameters (not shown) of the client device communicated to the server-side application and its accompanying video encoder instantiation. Operation612 (Store in memory for encoder) then follows, storing the converted video frame for use by a video encoder. Operation614 (Flag video update needed) then follows, setting an indication for use by an operation determining if a video update is needed (see operation712 (Video update needed?) ofFIG. 7). Operation616 (Delay) then follows, and may be implemented by a timer (not shown), beforeoperation602 is repeatedly performed.
• One skilled in the art will recognize that the illustration ofFIG. 6 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 7 is aflowchart700 illustrating some supporting aspects of sending a succession of video frames, according to one embodiment. Update User N,702, represents a start of a sequence of steps, with the sequence of steps representing the steps undertaken by the worker threads ofFIG. 5 for each user in the applicable worker thread's list of active users. A worker thread initially performsoperation704, (Read back channel). Operation706 (Any data to process for user?) then follows, where it is determined if anything pertinent for User N came in from the network that needs to be processed. Responsive to data pertinent to User N being detected, operation708 (Process network events) then follows. Incoming data pertinent to User N may comprise, for example, information regarding user input to the client device, such as attempting to zoom in on a particular part of the server-side application UI (as shown by a video frame of the server-side application UI displayed on a viewing application running on the client device).Operation708 may include communicating such processed information to its next destination, e.g., if a zoom command had been sent from the client, the zoom command would be appropriately processed and forwarded to the server-side application before the worker thread proceeded to the next applicable operation.
• Either after operation708 (Process network events) or a negative determination of operation706 (Any data to process for user?), operation710 (Update needed?) is then performed.Operation710 may depend on a counter (not shown) being set when the last video frame for the applicable user was sent, or, more specifically, when operation712 (Video update needed?) was last performed. If the counter has not yet reached its endpoint, then the worker thread performing the operations will then proceed to operation718 (Increment N) to commence the sequence of steps illustrated inFIG. 7 for the next applicable user. The counter controls the frame rate for the succession of video frames being communicated from the server to the client, or, more specifically, the allowable frame rate, as will be further described below in relation tooperation712, (Video update needed?). For example, for an allowable frame rate of ten times per second, the counter would be set to count to 100 milliseconds (e.g., from 100 milliseconds down to zero, or vice-versa).
• If operation710 (Update needed?) is determined in the affirmative, then operation712 (Video update needed?) is performed.Operation712 may comprise checking a ‘video update needed’ flag, as was described in relation toFIG. 6, or some such similar operation.Operation712 serves to determine whether anything has changed in the portion of the server-side application being displayed by the client in the client's viewing application. Ifoperation712 is determined in the affirmative, operation714 (Grab needed video info) is then performed.Operation714 serves to obtain any video frame information needed to update the video frame of an application UI from the last transmitted video frame of the UI, and may make use of a wide range of video frame/compression techniques, including video frame/compression standards, customized methods, and combinations thereof.
• Once operation714 (Grab needed video info) has been performed, operation716 (Send network event) is then performed.Operation716 serves to send to the client one video frame update, or updated state information pertaining to the client's viewing application and the server-side application/UI.Operation716 may post the applicable data for User N to the queue for User N's network connection to effectuate this.
• Ifoperation712 is determined in the negative, operation716 (Send network event) may be still be performed if there is updated state information pertaining to the client's viewing application and the server-side application/UI.
• By transmitting only one video frame update (or state information update) per user, the worker thread servicing multiple users may cycle through and serve all of the users on its active user list without any one user significantly consuming the worker thread's time to the detriment of any other particular user. As the worker thread's load across all of its supported users increases, servicing times for all of the worker thread's active users will gradually increase. Load balancing is thus inherently embedded in this manner. Additional load balancing techniques are described in connection withFIG. 5.
• One skilled in the art will recognize that the illustration ofFIG. 7 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 8 is a diagram illustrating some aspects of client-server exchange800, according to one embodiment. Client-server exchange800 depicts a session exchange betweenserver802 andclient device804. As described herein,server802 may refer to any server-side machine, and may include a number of servers, either located in one facility or geographically dispersed, operating in conjunction to facilitate the operations described inFIG. 8. These servers may include authentication servers, database servers, etc.
• Client device804 initiates client-server exchange800 withoperation806, with a user launching a viewing application onclient device804. (The term, client device, is used with respect toFIG. 8 simply because the client device's parameters are discussed throughout; the term, client, could also be used interchangeably.) The viewing application then facilitates opening a connection toserver802 via a network connection viaoperation808.Operation808 makes use of one or more standard Internet protocols, or variations thereof, as would be appreciated by one of skill in the art.Operation808 serves to pass the user's identity (e.g., by telephone number, carrier account, etc.) and client device's (804) display resolution and size toserver802, for use byserver802 in the session.Server802 then performs operation810, which launches and provisions a server application instance, with the server application customized based on the user's preferences. In the present embodiment, the user's preferences are fetched from a database (not illustrated) where they have been associated with the user's identity. Per operation810, the server application renders in a virtual frame buffer. In another embodiment, the server application may render to a screen.
• Operation812 then follows, where audio/video encoder modules, and an accompanying command process module, are launched and provisioned with client device's (804) display resolution and size for customized encoding forclient device804. The command process and encoder modules may also be provisioned with a level of service associated with the user's identity, providing the particular user with a priority-level with regard to other users using the system. Subsequently, as depicted inoperation814, the video encoder may convert and encode video frames of the server application's UI (e.g., converting the video frames rendered by the server application to QVGA resolution from the server application's native rendering resolution becauseclient device804 supports QVGA resolution). The video encoder module also resizes the server application's native UI size rendering to suitably fit within, or work together with client device's (804) screen size. The audio encoder module encodes an audio stream output of the server application based on the speaker capabilities of client device804 (e.g., if client device is known to be a cellular phone, the audio may be encoded such the quality encoded does not exceed the particular phone's speaker capabilities, or of a default level used for cellular phones).Arrow816 illustrates the communication of the encoded audio and video toclient device804.
• Operation818 subsequently follows, where the viewing application's decoder modules (audio and video) decode the audio and video frames received. The video frames may be displayed in the viewing application on the client, and the audio may be output to client device's (804) speakers (if audio is present andclient804 is not on mute), as depicted byoperation820.
• Operation822 subsequently follows, depicting an on-going series of interactions (represented byarrows826 and828) betweenserver802 andclient device804, also represented byoperation824 on the client side.Operation822 depicts the server application only sending information to the encoder modules when the UI or audio output change, with the encoders encoding this information for transmittal toclient device804. Thus, if nothing changes regarding the server application's UI or audio, then audio/video information is not encoded and sent toclient device804. A video encoder of server (802) thus asynchronously communicates video frames based on changes in the UI. Video is sent as video frames to display UI changes, and not as commands outside of a video frame format.
• Operation824 depicts the user interacting with the virtual application, with the user's inputs being transformed into parameters and being passed back to the server application.Operation822 further depicts the server-side command process module translating user input parameters to operate on the server application UI, with the server application UI accordingly changing.Operation824 completes the cyclical sequence by further depicting the encoded audio and video resulting from user inputs to the virtual application being received, decoded and displayed in the viewing application.
• One skilled in the art will recognize that the illustration ofFIG. 8 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 9 is a diagram illustrating some aspects of client-server exchange900, according to one embodiment. Client-server exchange900 depicts a session exchange betweenserver903 andclient904, with an accompanying exchange between encoder/command process modules902 and application906 (both running on server903) also being illustrated.Application906 includesstate management module907 andclient904 includesstate management module905, which will be discussed in relation toFIG. 10.Application906 comprises a web browsing application in this embodiment. Encoder/command process modules902 comprise audio and video encoder modules and a command process module. References to exchanges with encoder/command process modules902 may only specifically comprise an exchange with one of these modules, as would be appreciated by one skilled in the art. In another embodiment, a functional element similarly situated as encoder/command process modules902 may comprise a video encoder module and a command process module, but not an audio encoder module. As described herein,server903 may refer to any server-side machine, and may include a number of servers, either located in one facility or geographically dispersed, operating in conjunction to facilitate the operations described inFIG. 9. These servers may include authentication servers, database servers, etc.
• Client904 initiates client-server exchange900 withoperation908, open connection.Server903 responds withoperation910, connection confirmed.Client904 then send its capabilities to encoder/command process modules902, including screen size and other device parameters, viaoperation912. The device parameters may include a wide variety of device parameters, including a device processor, memory, screen characteristics, etc.Client904 then sends a URL viaoperation914, which may comprise a saved URL (e.g., a homepage) or a URL entered by the user ofclient904. Encoder/command process modules902 in turn communicate the URL toapplication906 viaoperation916, andapplication906 then loads the URL viaoperation918.Application906 also passes the width (w) and height (h) of the web page associated with the URL to encoder/command process modules902 viaoperation920. Encoder/command process modules902 then communicates the web page size toclient904, as well as the viewport visible on the client screen, including parameters characterizing the viewport of the client, e.g., a corner coordinate (x, y) and an associated zoom factor (z), viaoperation922. The parameters characterizing the viewport of the client may comprise absolute position information, relative position information, etc.
• A screen capture of the webpage viewport (the portion of the browser UI that the viewport has been associated with) then takes place viaoperation924, in accordance with a number of techniques known in the art. A video frame of the web page visible through the viewport is then communicated toclient904 viaoperation926. Asubsequent screen capture930 then takes place after avariable sample interval928, with the associated video frame being communicated viaoperation932.Arrow symbol929, commonly used to indicate a variable element, is illustrated crossingvariable sample interval928 to indicate this novel feature.
• An asynchronous feedback channel provides feedback viaoperation934. This feedback may be used to vary thesample interval928 based on one or more feedback parameters, including client device parameters, user input parameters, and/or estimated bandwidth parameters, such as bandwidth parameters based on measurements of the packets traversing back and forth betweenserver903 andclient904. RTCP protocol, or a similar such protocol (standardized or customized) may be used in connection with providing such feedback, as illustrated byoperation936.Ellipsis938 andcycle940 illustrate the repetitive nature of the interaction betweenserver903 sending video frames toclient904.
• Sample interval928 may also be at least partially varied based on the rate of change of the underlying webpage being viewed. For example, if little to no change is detected in the underlying webpage being viewed byclient904, then the frame sample interval may be adjusted upward. Likewise, for a very dynamic webpage, or content within a webpage, the frame sample interval may be adjusted downward.
• The user ofclient904 may move the viewport from which a webpage is being viewed, to view another portion of the webpage, as depicted in operation942, with x′ and y′ comprising new parameters of the viewport. The new portion of the webpage that matches the new viewport will then be captured viaoperation944, and a video frame of the new viewport will be communicated toclient904 viaoperation946.
• The user ofclient904 may again move the viewport, as depicted inoperation948, with x″ and y″ comprising new parameters of the viewport. This time, the new viewport extends beyond what would be displayed on the server browser window, and thus the browser itself must scroll to capture the desired portion of the webpage, as depicted inoperation950. Having appropriately scrolled, as depicted viaoperation952, a screen capture of the new viewport will then be obtained, as illustrated inoperation954, with the resulting video frame communicated viaoperation956.
• The user ofclient904 may also use a mouse or mouse-equivalent (e.g., finger tap/motion on a touchscreen, multi-directional button, trackpoint stylus moving a cursor, etc.), as shown viaoperation958, where a mouse down motion is made, with the new coordinates of the mouse being passed as (a, b).Client904 will pass coordinates relative to the client device's screen back to encoder/command process modules902 in such an operation, with encoder/command process modules902 determining the corresponding location in relation to the viewport and underlying webpage. In the embodiment being described inFIG. 9,server903 is running an underlying Windows OS, permitting the injection of a mouse message with the appropriate location information to the window associated with browser906 (whether there is an actual screen being used for rendering or not). This is illustrated viaoperation960, and the screen cursor would resultantly move inapplication906, and be communicated back in a video frame toclient904 as described above. In other embodiments being used in conjunction with other operating systems, similar such functions may be used if available, or some analogous other such techniques, as would be appreciated by one skilled in the art.
• Operations962,964,966 and968 depict similar mouse-driven events, which will work in an analogous manner. The term, mouse-driven event, is used broadly herein to include input control events triggered by a wide variety of mouse or mouse-equivalent control inputs on a variety of devices (e.g., finger tap/motion on a touchscreen, multi-directional button, trackpoint, stylus moving a cursor, etc.). Other input driven control events (such as a keypad entry) may work in the same manner as well. The types of operations depicted in970,972,974,976 and978 have been described above, andellipsis980 andcycle982 serve to illustrate on-going interactions as long as the session betweenclient904 andserver903 continues.
• One skilled in the art will recognize that the illustration ofFIG. 9 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 10 is a diagram1000 illustrating some aspects of viewport move operations and related state management, according to one embodiment.FIG. 9 is referenced throughout the description ofFIG. 10, as the two figures are related. Diagram1000 includeswebpage1002, with a width of w′1004, and a height of h′1006.Webpage1002 is illustrated partially rendered inFIG. 10, with renderedwebpage portion1008 having a width ofw1010, and a height of h1012.Webpage portions1014,1020, and1026 are illustrated, each having a left corner coordinates of (x, y)1016, (x′, y′)1022, and (x″, y″)1028, respectively, and associated zoom factors of1018,1024, and1030, respectively.Webpage portion1026 includes cursor position (a, b)1032.Webpage portions1014,1020, and1026 relate tooperations922,942 and948, respectively, ofFIG. 9.
• Webpage portion1014 corresponds to a portion ofwebpage1004 sent for remote viewing, which comprises a viewport of client (being indicated by (x, y)1016 and zoom factor1018). Following or performed concurrently with eitheroperations944 or946 ofFIG. 9,state manager module907 ofserver903, having previously identified webpage portion1014 as the current state, updates its current state webpage towebpage portion1020.State manager module905 ofclient904 does likewise uponclient904 displayingwebpage portion1020.State manager modules907 and905 then identify webpage portion1014 as the prior state.Client904 may request priorstate webpage portion1020 fromserver903, such as, for example, via a back icon (not shown). As an intermediate step,client904 may display a locally cached version of the prior state webpage portion whileserver903 is in the process of obtaining/sending the current version of the prior state webpage portion.
• Webpage portion1026 likewise becomes the next current viewport ofclient904 per operations948-956, andstate manager modules907 and905 likewise updating the current state webpage towebpage portion1026, with the addition of internalapplication scrolling operations950 and952 due to part of1026 not being on renderedwebpage1008. In another embodiment, the entire applicable webpage is rendered (analogous to h′1006 by w′1004 ofFIG. 10), and thus there are no internal scrolling operations to perform.
• Similar to the identification of webpage portion states, cursor position sub-states are maintained relative to viewport views and the viewport view's corresponding webpage portion. For example, whilewebpage portion1026 comprises the current state,webpage portion1026 includes cursor position (a, b)1032. As described in relation to operations958-964 inFIG. 9, as cursor position (a, b) is updated, so too is its corresponding sub-state maintained bystate manager module907.
• One skilled in the art will recognize that the illustration ofFIG. 10 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 11 is a diagram illustrating some aspects of a client-server exchange1100 with respect to state management, according to one embodiment. Client-server exchange1100 depicts a session exchange betweenclient1102 andserver1104. As described herein,server1102 may refer to any server-side machine, and may include a number of servers, either located in one facility or geographically dispersed, operating in conjunction to facilitate the operations described inFIG. 11. These servers may include authentication servers, database servers, etc.
• Server1102 includesstate manager module1104 to manage state information, andclient1106 includesstate manager module1108 to manage state information.State manager module1104 andstate manager module1108 operate as described herein; their common name describes their general function and is not meant to imply they are instances of the same module. In another embodiment, these two modules may be instances of the same module. In yet another embodiment,state manager modules1104 and1108 may operate as one logical software unit.
• Operation1110 illustratesstate manager module1104 identifying a portion of a webpage sent for remote viewing, with the portion comprising a viewport view ofclient1106.Operation1114 illustratesstate manager module1104 identifying this webpage portion as the current state webpage portion.Operation1112 illustratesstate manager module1108 identifying a portion of a webpage being displayed, withoperation1112 illustratingstate manager module1108 identifying this webpage portion as the current state webpage portion. The webpage portions are defined areas within a webpage, and thus in another embodiment, a current state checker module (not shown) may be used to periodically verify the current states are uniform acrossserver1102 andclient1106. In yet another embodiment, a common table (not shown) may be shared amongstate manager modules1104 and1108, where states are defined in terms of location identifiers of a specific portion of a specific webpage.
• Operation1118 illustrates a user ofclient1106 selecting a second portion of the webpage. The user can make such a selection in a wide variety of ways, including moving a navigation toggle or a scroll wheel, using a touch screen or keypad, etc. In the embodiment described in relation toFIG. 11, the webpage portions further comprise an area of the webpage surrounding the viewport ofclient1106. Thus, in the instance of a selection by the user of a limited scroll-down foroperation1118, the second portion of the webpage may already reside onclient1106.Operation1120 illustrates checking if the second portion is already in local memory. In another embodiment, the webpage portions match the viewport ofclient1106, and a local memory check, likeoperation1120, may check if the desired webpage portion had been previously loaded and was still resident in local memory. Determining whether on object of interest is in local memory can be performed in a number of ways, as would be appreciated by one of skill in the art.
• In the example illustrated,operation1120 was determined in the negative, and parameters for the second portion of the webpage are thus communicated viaoperation1122.FIGS. 9 and 10 provide more detail regarding passing parameters. Similarly tooperations1110 and1112, a second portion of a webpage is identified byserver1102 and sent toclient1106, as illustrated byoperations1124 and1126.State manager modules1104 and1108 accordingly identify the second portion as the current state portion viaoperations1128 and1130.State manager modules1104 and1108 then identify the former prior state webpage portion as the prior state inoperations1132 and1134.
• In the embodiment illustrated inFIG. 11,operation1120 may also be determined in the positive (not shown). In the case of the second webpage portion residing completely in the local memory ofclient1106, the second webpage portion may not be requested by, and provided to,client1106.Client1106 may simply display the second webpage portion and relay parameters regarding the second webpage portion in order forstate manager module1104 ofserver1102 to update its state information. Displaying the second webpage portion may also comprise an intermediate step before obtaining a more current version of the second webpage portion fromserver1102.
• The same operations discussed herein do not only apply to present and prior states, but also to a plurality of webpage portion states of a plurality of websites. This plurality of states may comprise an ordered succession of states, as may be recorded in a browsing session using an embodiment of the invention. This ordered succession of states may be available toggling through the website portion views of a user session, saved as a series of bookmarks, etc.
• Though not illustrated, a feature of managing state information as described herein includes enabling the sharing of a webpage portion with another user, in accordance with one embodiment. A webpage portion may be included in an identifier that can be placed in a message for sending, with the identifier adapted to facilitate transport to the applicable webpage portion. The message could be an email message, an instant-messaging message, a messaging feature used in a social network, etc. The identifier may route the recipient of the message into their system account (an embodiment client-server system account), where the webpage portion included in the identifier can be accessed like a prior webpage portion state of the user. A database may be used in conjunction with such identifiers. As will be appreciated by those skilled in the art, other ways may be used to augment a webpage portion identifier so that it may be transferred among different users, both within and outside of embodiment client-server system accounts.
• One skilled in the art will recognize that the illustration ofFIG. 11 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 12 is a diagram illustrating some aspects of a client-server exchange, including an accompanying exchange between a server and network storage, according to one embodiment. Client-server exchange1200 depicts a session exchange betweenclient1202 andserver1204, with an accompanying exchange betweenserver1204 andnetwork storage1206. As described herein,server1204 may refer to any server-side machine, and may include a number of servers, either located in one facility or geographically dispersed, operating in conjunction to facilitate the operations described inFIG. 12.Network storage1206 may refer to any one or more storage units, operating in combination or any other way, that are networked toserver1204.Server1204 includesprovision manager module1205 and user manager module502 (ofFIG. 5).
• Operations1208,1210 and1212 serve to initiate a session.Operation1214 launches a unique browser instance forclient1202.Provision manager module1205 uses the user identifier passed in operation1210 (e.g., a telephone number, account number, etc.), or another identifier associated with the user identifier, to fetch browser state information for the user fromnetwork storage1206 viaoperations1216 and1218.Provision manager module1205 likewise fetches a customer profile for the user fromnetwork storage1206 viaoperations1216 and1218. The customer profile and the browser state information may reside in different, unrelated portions ofnetwork storage1206. Browser state information for the user may include any type of user information associated with a browser, including bookmarks, cookies, caches, etc. Viaoperation1220,provision manager module1205 provisions the unique browser instance launched for the user as would be appreciated by one skilled in the art (e.g., by using automated directory copies, automated provisioning techniques, etc.).
• Viaoperation1222,provision manager module1205 works in conjunction with user manager module502 (described in relation toFIG. 5) to provision resources based on the user's customer profile. The user's customer profile could include the user's past usage history (e.g., categorized as bandwidth low, medium, or heavy), encoding usage (also possibly categorized), etc.Provision manager module1205 anduser manager module502 together operate to provide different levels of service to a user, based on a level of service provider plan, etc. A wide range of parameters may be configured, depending on the particular embodiment, including peak/average bandwidth Quality of Service (QoS), video compression settings for motion video (i.e., quality), video frame rate, video image size limits and refitting, server memory, CPU and/or disk usage. The parameters configured could be set statically per user/profile, or the parameters could dynamically change, based on a number of factors, including the type of URL being used. In this way, the service provider could provide higher quality video for low-bandwidth pages (e.g., news websites, etc.) and place more restrictions on bandwidth-intensive websites. As described in relation toFIG. 5, provisioning a user among worker threads may also be used to implement tiered levels of service.
• Arrows1224 and1226 depict a web browsing session. Viaoperation1228, the browser state information will be updated based on the user's use during the session (e.g., the addition of cookies based on websites visited, modifications to bookmarks during the sessions, etc.). Viaoperation1230, at least some of the user's customer profile will also be tracked for updating the user's customer profile on terminating the session.
• During a session,user manager module502 may perform a state copy of a user session to transfer a user to another thread, either on the same server or a different server.User manager module502 may operate in conjunction withprovision manager module1205 to facilitate such a move. While moving a user from one thread to another is discussed in relation toFIG. 5,provision manager module1205 may also facilitate such a state copy by updating state information during a user session.User manager module502 may then pause a browsing session, whileprovision manager module1205 provisions another browser instance with the updated state information at the desired destination.User manager module502 may then move the user session to the desired destination by performing a state copy (which may include a directory copy, etc.). The applicable user web browsing session may then resume. The timing of such transfers may take place at specific junctures in the display of video frames by a client device's viewing application, in order to minimize disruption of a user's experience, such as when a user makes a request of a URL.
• When the user desires to end the session, the user may close their virtual browser, as shown inoperation1232, and accompanyingoperation1234. The user's browser end state will also be captured byprovision manager module1205, as shown viaoperation1236, via a directory save, etc. The user's customer profile will be updated based on the usage information captured, as shown inoperation1238. For example, the user may visit mostly text-based websites during a session, and have their average bandwidth and encoding averages lowered by such a resource-light session.Provision manager module1205 will update the user's state information and customer profile based on the session, saving the updated versions innetwork storage1206, asserver1204 closes the unique server browser instantiated at the beginning of the session.
• One skilled in the art will recognize that the illustration ofFIG. 12 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 13 is a diagram illustrating some aspects of displaying a web browsing session from a server to a cellular phone, according to one embodiment.Server1302 is illustrated, upon which a web browsing engine (not shown) executes,rendering webpage1304.Webpage1304 is rendered into a buffer onserver1302 in the embodiment discussed in relation toFIG. 13, butwebpage1304 may be also rendered to a screen in another embodiment. A recognition engine (not shown) also runs onserver1302, which identifies elements of interest onwebpage1304, such ashyperlink1306. Recognition engine may use any number of techniques known to one skilled in the art to identify elements of interests with respect towebpage1304, including parsing through the HTML/XHTML/Document Object Model data to obtain access to the rendered webpage data/contents of webpage1304 (including location information of the contents of webpage1304). In some embodiments, other techniques for parsing webpage contents may be used, including a tabbing function to cycle through components of a webpage. In some embodiments, optical character recognition techniques known to those skilled in the art may additionally or alternatively be used.
• In some embodiments, the information regarding the elements of interest may be communicated along withwebpage1304, such as in the form of a polygon map. A viewing application (not shown) running oncellular phone1310 may then match such a polygon map with the video ofwebpage1304 being displayed. In various embodiments, the information regarding the elements of interest may be communicated fromserver1302 tocellular phone1310 in combination with the video frames in a wide variety of ways, as would be appreciated by one of skill in the art regarding sending two data sets to be matched at the destination.
• In one embodiment, the information regarding the elements of interest may be communicated in response to viewing application passing user input back to the recognition engine onserver1302. For example, a user may select a location on the image being displayed oncellular phone1310 corresponding to a textbox (not shown) onwebpage1304, for the user to input text into the text box. As described elsewhere in relation to other Figures, the location of the user selection may be passed back toserver1302. Recognition engine onserver1302 may then communicate to the viewing application that the location selected by the user corresponds to a textbox. In one embodiment, the viewing application may then locally render a generic textbox for the input of text by the user, sending the text entered by the user back to the recognition engine once the user has completed the entry.
• In another embodiment, the recognition engine may send information regarding the textbox to the viewing application for the viewing application to customize the locally-rendered textbox, including, for example, information regarding acceptable string length, acceptable character entries, string-formatting, etc. This information may be used by the viewing application to locally police acceptable input for a given textbox, as well as for formatting the display of input (e.g., causing password textbox entries to appear as “*******” instead of cleartext). In some instances, a textbox, radio button, etc., will already contain text (e.g., have an initial state with initial text), be selected, etc., and this information will be sent to the client to appear in the locally rendered textbox, radio button, etc. A state manager on the backend server will also track the state of interactive objects on a webpage, with the state manager serving to synchronize client user input with the web browsing engine on the backend server. The state manager may also serve to react to events on the server that occur while a client control is activated (such as a control losing focus suddenly), and may alert a user in some embodiments if a synchronization was unsuccessful, including, for example, providing a reentry prompt.
• Also, this applies to state. E.g. current selection(s) in a list box, or current state of a radio button.
• Cellular phone1310 is illustrated inFIG. 13 as the destination of webpage1304 (labeledwebpage portion1308 with respect to a portion being displayed on cellular phone1310), after the webpage has been transformed into video frames as discussed in regard to other Figures herein. The viewing application executing oncellular phone1310displays webpage portion1308 along with address bar1312 (displaying URL1340),toolbar1318, and an overlay graphical component, cursor1314, withaddress bar1312,toolbar1318 and cursor1314 being rendered locally oncellular phone1310.Address bar1312 andtoolbar1318 may appear in a number of locations together with a portion ofwebpage1304, according to a variety of embodiments. In some embodiments,address bar1312 andtoolbar1318 may be user-configurable to appear in other display locations, while in some embodiments,address bar1312 andtoolbar1318 may automatically adjust their locations based on positioning ofcellular phone1310 for cellular phones with motion detection ability.
• Hyperlink1316 (analogous to hyperlink1306 rendered on server1302) is displayed in the video image displayed oncellular phone1310. In some of the embodiments in which information regarding elements of interest are communicated along withwebpage1304, the viewing application may be adapted to transform cursor icon1314 into hand icon1315 (or another icon to denote an underlying hyperlink) while cursor icon1314overlays hyperlink1316.Address bar1312, comprising a roll out address bar in the embodiment illustrated inFIG. 13, may include any number of functional user interface elements.Address bar1312 rolls out when “A” icon1320 is tapped, and rolls back intomain toolbar1318 when “A” icon1320 is tapped whenaddress bar1312 is already rolled out, or upon inactivity for a defined time period.Address bar1312 displays the current URL and may also wrap around to another line when a user is entering a long URL.Home icon1334 allows for a user to set a home webpage by a number of means, either throughcellular phone1310 or through an import function through a specialized portal, as would be appreciated by one of skill in the art.Favorites icon1336 allows for a user to save URLs for easy reference, and may also be set up throughcellular phone1310 or through an import function through a specialized portal, as would be appreciated by one of skill in the art. “V”icon1338 allows for a voice/speech URL entry. In some embodiments, viewing application may interface with speech recognition capabilities ofcellular phone1310 for such voice/speech URL entries.
• Back andForward icons1322 allow for a user to scroll through webpages for previously entered URLs. In some embodiments, Back andForward icons1322 may allow for a user to scroll through webpage portion views. In some embodiments, such icons may be configurable to either scroll through prior webpages, or through prior webpage portion views, based on user selection of the two options. “X”stop icon1326 allows for stopping the loading of a portion of a webpage, and thus appears while a portion of a webpage is being loaded. In some embodiments, “X”stop icon1326 may display during the loading of, and permit cessation of the loading of, an entire webpage. When a portion of a webpage, or a webpage, has loaded, “X”stop icon1326 is replaced by “R”refresh icon1324, to allow for a reloading of the portion of the webpage currently being viewed, or the reloading of an entire webpage depending on the embodiment.
• Zoom in/outicons1328 allow for zoom functionality and control. Zoom in/outicons1328 may allow for multiple functionality based on the duration of selecting the icon. For example, for zooming out, each tap may incrementally zoom out, while a long press may zoom out to a full page view. Scrollicons130 and132 allow for scrolling in the client window.
• Depending on the embodiment and functionality ofcellular phone1310, the icons discussed herein may be touched-based for cellular phones with touch screen functionality, may include a menu-based user interface (softkeys), and/or may be selectable via scroll/selection buttons or any other input features of cellular phones. In some embodiments, a specialized touch pattern, e.g., a drag, etc., may be equated to a right-button mouse click, with such a parameter being passed to theserver1302 for right-button mouse options to appear on webpage1304 (and webpage portion1308). In some embodiments, right-button mouse options may be locally rendered by the viewing application.
• In some embodiments, web browsing engine onserver1302 may make use of small screen rendering techniques to render all, or part of,webpage1304 to fit within the width of the screen ofcellular phone1310. In some embodiments, the viewing application oncellular phone1310 may allow for user selection of a small screen rendering view, allowing the user to switch between multiple view formats known in the art. Intra-web page views displayed oncellular phone1310 may be tracked in some embodiments, allowing the center of a view to be maintained across multiple view formats.
• One skilled in the art will recognize that the illustration ofFIG. 13 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 14 is a diagram illustrating some aspects of a user interface display, according to one embodiment.Webpage portion1402 illustrates a collection of textboxes ofcheckout section1401, specifically shippinginformation section1403.Webpage portion1402 appears as if displayed on a mobile device (not shown), such as a cellular phone, withtoolbar1439 appearing on the bottom ofwebpage portion1402. In other embodiments,toolbar1439 may appear elsewhere or may roll out of view, either by default or by user configuration.Shipping information section1403 includescheckbox1415 for selecting the ‘use billing address’ option (illustrated as unchecked),textbox1416 forfirst name information1404,textbox1418 forlast name information1406,textbox1420 foraddress information1408,textbox1422 forcity information1410, dropdown menu1428 forstate information1412,textbox1424 for zip-code information1425,textbox1426 foremail information1414, andradio buttons1434 and1438, indicating “yes”1432 or “no”1436 responses toquestion1430.
• In the embodiment illustrated inFIG. 14, information regarding the interactive elements was communicated along withwebpage portion1402 to the mobile device displayingwebpage portion1402. In another embodiment, information regarding an interactive element may be communicated to the viewing application once the user has selected a location on the webpage being displayed corresponding to the interactive element.Webpage portion1440 will be used to illustrate further operations with respect towebpage portion1402. In the case of a user bypassing the address-related textboxes shown inFIG. 14 by selecting checkbox1415 (e.g., by tapping the location of the screen wherecheckbox1415 was being displayed), a check appearing in checkbox1415 (not shown) would be rendered on the backend server, in accordance with one embodiment. In another embodiment, the viewing application may locally rendercheckbox1415 and the check, or just the check, depending on the embodiment.
• When a user selectstextbox1416 to enter their first name, the viewing application displaying portion ofwebpage1402 locally renderstextbox outline1442 and rolls out overlay textbox1444 (the rolling feature indicated byarrow1446 for illustration purposes). As the user inputs their name, the letters entered by the user display inoverlay textbox1444. Once the user has completed their entry, for example by pressing an enter key on the mobile device or selecting another textbox onwebpage portion1440, the viewing application will communicate the information to a state manager on the backend server, with the state manager serving to synchronize client user input with the web browsing engine on the backend server. In another embodiment, an overlay textbox for character entry may be locally rendered directly wheretextbox1416 is shown. In another embodiment,toolbar1448 may transform to an overlay textbox for character entry.
• In the embodiment illustrated inFIG. 14, the viewing application received information regarding dropdown menu1428 from the recognition engine residing on the backend server, including the available menu options (e.g., items listed, the initial selection, or state, of the drop-down menu), together with the information to displaywebpage1402. Viewing application then locally rendered dropdown menu1428, and will locally render an expanded menu upon the user selecting dropdown menu1428. Once the user makes a selection of the available menu options, viewing application will communicate the information to a state manager on the backend server, with the state manager serving to synchronize client user input with the web browsing engine on the backend server. In other embodiments, other implementations may be used to locally render the selections available from a dropdown menu.
• In the embodiment illustrated inFIG. 14, the viewing application received information regardingradio buttons1434 and1438 from the recognition engine residing on the backend server, together with the information to displaywebpage1402. Viewing application then locally renderedradio buttons1434 and1438, and locally renderedradio button1434 selected upon the user tapping radio button1434 (FIG. 14 illustrating an embodiment where the mobile device includes a touch screen). Once selection of a radio button is made, viewing application will communicate the information to a state manager on the backend server, with the state manager serving to synchronize client user input with the web browsing engine on the backend server. In other embodiments, other implementations may remotely render selection of a radio button.
• One skilled in the art will recognize that the illustration ofFIG. 14 is merely an example, and that the invention may be practiced and implemented in many other ways. In various embodiments, one or more of the above interactive elements of a webpage (for example, a textbox, a radio button, a dropdown menu, etc.) may be rendered completely on the backend server. Additionally, in some embodiments, a state manager module within the viewing application may facilitate collecting user input and synchronizing such user input with user input provided to the backend web browsing engine.
• FIG. 15 is a diagram illustrating some aspects of a user interface display, according to one embodiment.Webpage portion1502 appears as if displayed on a mobile device (not shown), such as a cellular phone, withtoolbar1504 appearing on the side ofwebpage portion1502. In other embodiments,toolbar1504 may appear elsewhere or may roll out of view, either by default or by user configuration.Webpage portion1502 illustratesnews section1506, including headline1508,text section1510 andwebpage video1512.
• In the embodiment illustrated inFIG. 15, information regarding the interactive element ofwebpage video1512 was communicated along withwebpage portion1502 to the mobile device displayingwebpage portion1502. In another embodiment, information regardingwebpage video1512 may be communicated to the viewing application once the user has selected a location on the image displayed corresponding towebpage video1512. Fullscreen video view1518 will be used to illustrate an operation with respect towebpage portion1502. When the user movescursor icon1514 overwebpage video1512, the viewing application locally renderingcursor icon1514 will transformcursor icon1514 tohand icon1516 based on the information communicated from the backend server to the viewing application. In another embodiment, the viewing application may not make such a transformation. In other embodiments, a play icon may be displayed onwebpage video1512, either placed there by the viewing application or as displayed on the underlying webpage.
• Once the user has selectedwebpage video1512, the viewing application illustrated inFIG. 15 will switch to fullscreen video view1518, allowing for larger viewing of webpage video1512 (shown aslarger webpage video1520 in full screen video view1518). In the embodiment illustrated, the same underlying video transport, as discussed with respect to other Figures, is used both for displayingwebpage portion1502 and fullscreen video view1518. Fullscreen video view1518 includes a video-control user interface1522, the length of which corresponds to the length ofwebpage video1520, viewed-portion segment1526, and pause/play icon1524, which may be alternatively used for pausing or playingwebpage video1520, depending on the current play state ofwebpage video1520. In another embodiment, the viewing application may not have a specialized video-control user interface for playingwebpage video1520. In other embodiments, the viewing application may have a different specialized video-control user interface for playingwebpage video1520.
• In some embodiments, the viewing application may playvideo1512 as shown inwebpage portion1502, and not switch to fullscreen video view1518. In some embodiments, whethervideo1512 switches to fullscreen video view1518 may be user-configurable.
• One skilled in the art will recognize that the illustration ofFIG. 15 is merely an example, and that the invention may be practiced and implemented in many other ways.
• FIG. 16 illustrates an example computer system suitable for use in association with a client-server architecture for remote interaction, according to one embodiment. As shown,computer system1600 may represent either a computer operating as a server, or a computer operating as a client, with the general components illustrated inFIG. 16 potentially varying with each respective representation, as would be appreciated by one of skill in the art.Computer system1600 may include one ormore processors1602 and may includesystem memory1604. Additionally,computer system1600 may includestorage1606 in the form of one or more devices (such as a hard drive, an optical or another type of disk, electronic memory, including flash memory, and so forth), input/output devices1608 (as a keyboard (screen-based or physical, in a variety of forms), scroll wheels, number pads, stylus-based inputs, a touchscreen or touchpad, etc.) and communication interfaces1610 (to connect to a LAN, a WAN, a wired or wireless network, and so forth). The elements may be coupled to each other via system bus1612, which may represent one or more buses. In the case where system bus1612 represents multiple buses, the multiple buses may be bridged by one or more bus bridges (not shown). When representing client devices in some embodiments, processor(s)1602 may comprise a controller, andsystem memory1604 andstorage1606 may comprise one cohesive memory component.
• These elements each perform their conventional functions known in the art. In various embodiments,computing system1600 may at least be partially incorporated in a larger computing system.System memory1604 andstorage1606 may be employed to store a working copy and a permanent copy of the programming instructions implementing various aspects of the one or more earlier described embodiments of the present invention. Any software portions described herein need not include discrete software modules. Any software configuration described above is meant only by way of example; other configurations are contemplated by and within the scope of various embodiments of the present invention. The term, engine, is used herein to denote any software or hardware configuration, or combination thereof, that performs the function or functions referenced. In particular, the term, web browsing engine, is used herein to describe any software or hardware configuration, or combination thereof, that performs a web browsing function.
• With respect to some embodiments of the invention, modules have been described to implement various functions. In alternate embodiments, part or all of the modules may be implemented in hardware, for example, using one or more Application Specific Integrated Circuits (ASICs) instead.
• In all of the foregoing, it is appreciated that such embodiments are stated only for the purpose of example, and that other embodiments could equally be provided without departing from the essential characteristics of the present invention.
• The present invention has been described in particular detail with respect to one possible embodiment. Those of skill in the art will appreciate that the invention may be practiced in other embodiments. First, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, as described, or entirely in hardware elements. Also, the particular division of functionality between the various system components described herein is merely by way of example, and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead performed by a single component.
• Some portions of above description present the features of the present invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules or by functional names, without loss of generality.
• Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.
• Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by real time network operating systems.
• The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include a computer (including any type of computer, depending on various embodiments, including a server, personal computer, tablet device, handheld computer, PDA, cellular phone, etc.) selectively activated or reconfigured by a computer program stored on a computer readable medium that can be accessed by the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs, including multi-core designs, for increased computing capability.
• The algorithms and operations presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent to those of skill in the, along with equivalent variations. In addition, the present invention is not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein.
• The present invention is well suited to a wide variety of computer network systems over numerous topologies. Within this field, the configuration and management of large networks include storage devices and computers that are communicatively coupled to dissimilar computers and storage devices over a network, such as the Internet.
• Finally, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims (25)

1. A system for displaying a web browsing session, the system comprising:

a web browsing engine residing on a first device;

a viewing application residing on a second device and operatively coupled to the web browsing engine, the viewing application adapted to display a portion of a webpage rendered by the web browsing engine and an overlay graphical component; and

a recognition engine adapted to identify an element on the webpage and communicate information regarding the element to the viewing application.

2. The system ofclaim 1, wherein the recognition engine is further adapted to communicate information regarding the element to the viewing application responsive to the viewing application passing user input to the recognition engine.

3. The system ofclaim 2, wherein the user input comprises a selection of a location on the webpage displayed on the second device, the location corresponding to the element's location on the webpage.

4. The system ofclaim 1, wherein the recognition engine is further adapted to communicate information regarding the element to the viewing application with the portion of the webpage.

5. The system ofclaim 1, further comprising:

a state manager engine operatively coupled to the viewing application and the web browsing engine, the state manager engine adapted to synchronize user input displaying locally on the viewing application with user input transferred to the web browsing engine.

6. The system ofclaim 1, further comprising:

a plurality of overlay graphical components corresponding to a plurality of elements on the webpage.

7. The system ofclaim 1, wherein the overlay graphical component comprises a cursor icon, the viewing application further adapted to transform the cursor icon, based on the information communicated regarding the element, while the cursor icon overlays the element.

8. The system ofclaim 1, wherein the element comprises a radio button and the overlay graphical component comprises an overlay radio button, the viewing application further adapted to transform the overlay radio button upon a user selection and communicate selection of the radio button element to the web browsing engine.

9. The system ofclaim 1, wherein the element comprises a drop-down menu and the overlay graphical component comprises an overlay drop-down menu, the viewing application further adapted to expand the overlay drop-down menu upon a user selection and communicate user selection of a menu option to the web browsing engine.

10. The system ofclaim 1, wherein the element comprises a textbox and the overlay graphical component comprises an overlay textbox, the viewing application further adapted to fill in the overlay textbox based on user input and communicate the overlay textbox user input to the web browsing engine.

11. The system ofclaim 1, wherein the recognition engine is further adapted to identify elements based on underlying code of the webpage.

12. The system ofclaim 1, wherein the viewing application is further adapted to display a user interface accompanying the portion of the webpage.

13. The system ofclaim 1, wherein the viewing application is further adapted to switch from the portion of the webpage to a full screen view of a video embedded in the webpage.

14. The system ofclaim 13, wherein the viewing application is further adapted to display a video-control user interface accompanying the video.

15. A method for displaying a web browsing session, the method comprising:

rendering a portion of a webpage, the rendering performed by a web browsing engine residing on a first device;

recognizing an element on the webpage and communicating information regarding the element to a viewing application, the recognizing performed by a recognition engine, the viewing application residing on a second device; and

displaying the portion of the webpage and an overlay graphical component via the viewing application.

16. The method ofclaim 15, wherein the communicating information regarding the element to the viewing application is responsive to the viewing application passing user input to the recognition engine, the user input comprising a selection of a location on the webpage displayed on the second device and the location corresponding to the element's location on the webpage.

17. The method ofclaim 15, further comprising:

communicating information regarding the element to the viewing application with the portion of the webpage.

18. The method ofclaim 15, further comprising:

synchronizing user input displaying locally on the viewing application with user input transferred to the web browsing engine.

19. The method ofclaim 15, further comprising:

a plurality of overlay graphical components corresponding to a plurality of elements on the webpage.

20. The method ofclaim 15, wherein the overlay graphical component comprises a cursor icon, the method further comprising:

transforming the cursor icon, based on the information communicated regarding the element, while the cursor icon overlays the element.

21. The method ofclaim 15, wherein the element comprises a radio button and the overlay graphical component comprises an overlay radio button, the method further comprising:

transforming the overlay radio button upon a user selection; and

communicating selection of the radio button element to the web browsing engine.

22. The method ofclaim 15, wherein the element comprises a drop-down menu and the overlay graphical component comprises an overlay drop-down menu, the method further comprising:

receiving an initial state of the drop-down menu, including items listed;

expanding the overlay drop-down menu upon a user selection; and

communicating user selection of a menu option to the web browsing engine.

23. The method ofclaim 15, wherein the element comprises a textbox and the overlay graphical component comprises an overlay textbox, the method further comprising:

receiving an initial state of the textbox, including initial text;

filling in the overlay textbox based on user input; and

communicating the overlay textbox user input to the web browsing engine.

24. The method ofclaim 15, further comprising:

displaying a user interface accompanying the portion of the webpage.

25. The method ofclaim 15, further comprising:

switching from the portion of the webpage to a full screen view of a video embedded in the webpage, the switching performed by the viewing application.

Images