System for enhancing script execution performance

Information

  • Patent Grant
  • 9578137
  • Patent Number
    9,578,137
  • Date Filed
    Thursday, June 13, 2013
    11 years ago
  • Date Issued
    Tuesday, February 21, 2017
    7 years ago
Abstract
Systems and methods can optimize or attempt to optimize portions of scripts that might be overlooked by traditional compilers. These systems and methods can include a code analysis module that develops an aggregate execution profile for a script by aggregating individual execution profiles of a plurality of users. These systems and methods can use the aggregate execution profile to emphasize aspects of the script that can be optimized for a plurality of users, enabling improved script performance for users.
Description
BACKGROUND

Generally described, computing devices and communication networks can be utilized to exchange information. In a common application, a computing device can request content from another computing device via the communication network. For example, a user at a personal computing device can utilize a software browser application, typically referred to as a browser software application, to request a Web page from a server computing device via the Internet. In such embodiments, the user computing device can be referred to as a client computing device and the server computing device can be referred to as a content provider.


With reference to an illustrative example, a requested Web page, or original content, may be associated with a number of additional resources, such as images or videos, that are to be displayed with the Web page. In one specific embodiment, the additional resources of the Web page are identified by a number of embedded resource identifiers, such as uniform resource locators (“URLs”). In turn, software on the client computing devices, such as a browser software application, typically processes embedded resource identifiers to generate requests for the content. Accordingly, in order to satisfy a content request, one or more content providers will generally provide client computing devices data associated with the Web page as well as the data associated with the embedded resources.


Once the client computing device obtains the Web page and associated additional resources, the content may be processed in a number of stages by the software browser application or other client computing device interface. For example, and with reference to the above illustration, the software browser application may parse the Web page to process various HyperText Markup Language (HTML) layout information and references to associated resources, may identify and process Cascading Style Sheets (“CSS”) information, may process and instantiate various Javascript code associated with the Web page, may construct a native object model to represent one or more components of the Web page, and may calculate various layout and display properties of the processed content for presentation to a user.





BRIEF DESCRIPTION OF THE DRAWINGS

Throughout the drawings, reference numbers are re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate embodiments of the features described herein and not to limit the scope thereof.



FIG. 1 depicts an embodiment of a content delivery environment that can facilitate script optimizations based on aggregate profile data.



FIG. 2 depicts an embodiment of a script execution profile aggregation process.



FIG. 3 depicts an embodiment of a state flow diagram in which an aggregate execution profile of a script is provided to a client device.



FIG. 4 depicts an embodiment of a state flow diagram in which a decompiled script is provided to a client device.



FIG. 5 depicts an embodiment of a state flow diagram in which a compiled script is provided to a client device.



FIG. 6 depicts an embodiment of a state flow diagram in which an aggregate execution profile of a script is provided to a client device.



FIGS. 7 and 8 depict embodiments of example browser user interfaces that may implement any of the scripts described herein.



FIG. 9 depicts an embodiment of a state flow diagram in which a content page is modified based on user browsing interactions.



FIG. 10 depicts an example browser user interface that may implement the modified content page of FIG. 9.





DETAILED DESCRIPTION
I. Introduction

From the perspective of a user utilizing a client computing device, a user experience can be defined in terms of the performance and latencies associated with obtaining network content over a communication network, such as obtaining a Web page, processing embedded resource identifiers, generating requests to obtain embedded resources, and rendering content on the client computing device. Latencies and performance limitations of any of the above processes may diminish the user experience. Additionally, latencies and inefficiencies may be especially apparent on computing devices with limited resources, such as processing power, memory or network connectivity such as netbooks, tablets, smartphones, and the like.


One approach to improving performance of loading content pages, such as web pages, is to attempt to optimize compilation of a script included in the content. An example of a script language in common use in many content pages is JavaScript. Scripts coded in JavaScript may be compiled into bytecode and interpreted, or they may be directly compiled. In either case, optimizations may be implemented at the compile stage to improve performance (e.g., faster execution speed) to facilitate faster load and/or execution times. An example of a compiler used to compile JavaScript is the V8 JavaScript Engine included in the Google Chrome™ web browser. The V8 JavaScript Engine includes a performance profiler that profiles a script to create an execution profile having information about execution times and frequency that methods in the script are executed. The V8 JavaScript Engine runs the performance profiler on a client device of a user to obtain the execution profile and may use this profile to identify methods that have a certain “hotness” level, meaning, among other things, that such methods may be executed frequently. The V8 JavaScript engine can optimize or attempt to optimize these methods, for example, by performing function inlining, elision of runtime properties, loop unrolling, inline caching, or other optimization techniques. A programmer can also use the execution profile information manually to improve or otherwise optimize a script.


A drawback to the optimization techniques of compilers such as the V8 JavaScript Engine compiler is that such compilers tend to optimize only those functions or methods that are executed frequently, while overlooking slowly-executing functions that execute infrequently. However, for a network resource site, such as a web site, a script in a content page may include a function that executes infrequently for each user that visits the site but that actually executes frequently when taken in the aggregate over many users. Such a function may be slow and cause degraded performance for many users, particularly users of mobile devices.


This disclosure describes embodiments of systems and methods that can optimize or attempt to optimize portions of scripts that might be overlooked by traditional compilers. These systems and methods can include a code analysis module that develops an aggregate execution profile for a script by aggregating individual execution profiles of a plurality of users. These systems and methods can use the aggregate execution profile to emphasize aspects of the script that can be optimized for a plurality of users, enabling improved script performance for users.


As used herein, the term “optimize” and its derivatives, when referred to compilation or script execution techniques, in addition to having their ordinary meaning, are used herein to refer to improving one or more aspects of compilation or execution of a script (such as execution speed) and may, but need not, mean that a theoretically optimal or best compilation or execution of a script has been achieved. In addition, for convenience, script examples are described herein in the context of JavaScript, although other scripts in different script languages and scripting platforms may also take advantage of the features described herein, including, for example, VBScript, ActionScript/Flash, Silverlight, TypeScript, Dart, and the like. Further, although this disclosure focuses primarily on optimization of scripts, some or all of the features described herein may also be applied to computer program code other than scripts, including program code that is compiled into script code.


II. Example Content Delivery Environment


FIG. 1 illustrates an example content delivery environment 100 for delivering content to users. This content may include content pages, such as web pages or other electronic documents, mobile application content, or the like. The content pages may include any combination of text, images, videos, audio, animations, interactive features, and the like. The content may also include scripts embedded in or provided together with the content pages. The scripts can provide or enhance functionality of the content pages by, for example, enabling dynamic updating of content in the content pages. Advantageously, in certain embodiments, the content delivery environment 100 enables script optimizations to be performed based on aggregate profile data, as will be described in greater detail below.


The content delivery environment 100 can include an intermediary system 120, any number of client devices 104, and any number of content servers 106. The various systems may communicate with each other via a communication network 108. The network 108 may be a publicly accessible network of linked networks, possibly operated by various distinct parties, such as the Internet. In other embodiments, the network 108 may include a private network, personal area network, local area network, wide area network, cable network, satellite network, cellular telephone network, combinations of the same, or the like.


The intermediary system 120 can be any computing system that serves as an intermediary between a client device 104 and content servers 106 that serve the content. For example, the intermediary system 120 can be an intelligent proxy server, a system operated by an internet service provider (ISP), or some other device or group of devices that retrieve content on behalf of the client devices 104. The intermediary system 120 can include a number of components, such as a code analysis module 124, a content rendering engine 122, and a script profile data store 126. In some embodiments, the intermediary system 120 may include additional or fewer components than illustrated in FIG. 1. For example, the intermediary system 120 may include or otherwise be associated with various additional computing resources, such as content delivery network (CDN) systems, domain name system (DSN) servers, and the like.


The intermediary system 120 may include multiple computing devices, such as computer servers, logically or physically grouped together. The components of the intermediary system 120 can each be implemented as hardware, such as one or more server computing devices, or as a combination of hardware and software. In addition, the components of the intermediary system 120 can be combined on one server computing device or separated individually or into groups on several server computing devices. In some embodiments, the intermediary system 120 can include multiple instances of a single component, for example, implemented in virtual machines.


The client devices 104 can include a wide variety of computing devices, including personal computing devices, laptop computing devices, handheld computing devices, terminal computing devices, mobile devices (e.g., mobile phones, tablet computing devices, ebook readers, etc.), wireless devices, video game platforms, media players, and various other electronic devices and appliances. The client devices 104 may be configured with a browser application 112 to communicate via the network 108 with other computing systems, such the intermediary system 120 or content servers 106, and to request, receive, process, and display content. In addition, the client devices 104 can include a script engine 114 that interprets, compiles, or otherwise processes scripts included in the content. Moreover, the client devices 104 optionally include a page profiler 106 that can profile general user interactions with content pages. The page profiler 106 is described in greater detail below with respect to FIGS. 9 and 10.


The content servers 106 can each include one or more computing devices for hosting content and servicing requests for the hosted content over the network 112. For example, the content servers 106 can include a web server component that can obtain and process requests for content (such as content pages) from the client devices 104, the intermediary system 120, or other devices or service providers. In some embodiments, one or more content servers 106 may be associated with a CDN service provider, an application service provider, or the like.


In operation, one or more of the client devices 104 may be associated with the intermediary system 120. For example, the client device 104 may utilize proxy and caching services provided by the intermediary system 120. A user of the client device 104 may initialize the browser 112 and use the browser 112 to transmit a request for a content page, such as a web page. Due to the client device's 104 association with the intermediary system 120, the request may be transmitted to the intermediary system 120 rather than directly to the content server 106 of the content page. The intermediary system 120 can retrieve the content page from a content server 106 or some other source of the content page, such as a CDN system. The intermediary system 120 may process the content page prior to transmitting it to the client device 104. For example, the intermediary system 120 may utilize the content rendering engine 122 to partially or completely render the page, for example, by obtaining objects embedded in the page from various different content servers 106. The intermediary system 120 may then transmit the rendered content to the client device 104. Various examples of a content rendering engine 122 executing on an intermediary system 120 or other network computing component, and the browser 112 configurations and processing that can facilitate usage of the content rendering engine 122, is described in U.S. patent application Ser. No. 13/174,589, filed Jan. 3, 2013, titled “Remote Browsing Session Management,” the disclosure of which is hereby incorporated by reference in its entirety.


The intermediary system 120 may utilize the code analysis module 124 to obtain execution profile data from the client devices 104. These execution profiles may be received from the script engine 114 in the client devices 104. For example, if the client device 104 receives a script from the content rendering engine 122, the script engine 114 at the client device 104 can profile the script and export this profile to the code analysis module 124. The code analysis module 124 can accumulate or otherwise aggregate data obtained from these execution profiles into an aggregate execution profile. In one embodiment, the code analysis module 124 therefore creates an aggregate execution profile for each script, and this aggregate execution profile reflects the accumulated or aggregated execution profiles of multiple users.


The code analysis module 124 can store the received execution profiles and the aggregate execution profile in the script profile data repository 126. This repository 126 may include logical and/or physical computer storage, a database, or the like. In an embodiment, the script profile data repository 126 includes tables or other data structures that map scripts (or representations thereof) to execution profiles. Each script can be represented in the script profile data repository 126 by some unique value, such as a hash of the script, or the like. In one embodiment, the script profile data repository 126 is a key-value data store, such as a non-relational (or NoSQL) data store implemented in a cloud computing platform or infrastructure-as-a-service (IaaS) platform or the like.


Once the code analysis module 124 has received these execution profiles from a sufficient number of client devices 104, or otherwise has aggregated a sufficient amount of data, the code analysis module 124 can begin sending the aggregate execution profile to client devices 104 that subsequently receive the script from the content rendering engine 122 (and/or to devices 104 that have already received the script). The script engine 114 at the client device 104 can import the aggregate execution profile and use this profile to optimize compilation. Advantageously, in certain embodiments, this optimized compilation can have better results than traditional optimization that is based on a single user's interactions with the script. For example, the optimizations may cause more methods, functions, or routines in the script to compile with compiler optimizations.


In another embodiment, the code analysis module 124 compiles the script at the intermediary system 120 using the aggregate execution profile. The code analysis module 124 can either send this compiled version of the script to the client device 104 or can first decompile the compiled version and send the decompiled version to the client device. In either case, the script can execute with increased optimization. Other variations are possible, some examples of which are described in greater detail below.


It should be noted that the script engine 114 can be a modified version of an off-the-shelf or currently-available script engine. For instance, the script engine 114 may be modified to enable importing and/or exporting of execution profiles. The script engine 114 may include a plug-in, dynamic-linked library, or other code module that enhances the script engine's 114 functionality to allow importing and exporting of profiles. In another embodiment, the script engine 114 can be partially rewritten to include this enhanced functionality. In one embodiment, the script engine 114 is a modified version of the V8 JavaScript engine described above. Additional example modifications to off-the-shelf script engines 114 are described below.


In some embodiments, the script profile aggregation and optimization features described herein can also be implemented without the use of the intermediary system 120. For instance, the client devices 104 may communicate directly with the content servers 106 while forwarding script execution profiles to a third party server that aggregates the profiles for subsequent compiler optimizations (see, e.g., FIG. 6). Other embodiments are also described in greater detail below.


III. Example Script Optimization Process


FIG. 2 depicts an embodiment of a script profile aggregation process 200. The script profile aggregation process 200 can be implemented by the intermediary system 120 described above. In particular, certain blocks of the process 200 can be implemented by the content rendering engine 122 or the code analysis module 124 of the intermediary system 120. The process 200 need not be implemented by the intermediary system 120 and instead may more generally be implemented by any computing device. However, for convenience, the process 200 will be described in the context of the intermediary system 120.


At block 202 of the process 200, the content rendering engine 122 retrieve a script for a plurality of client devices (e.g., the client devices 104). The script may be a portion of a content page or mobile application requested by the client devices, as described above. Although not shown, in one embodiment, each time the content rendering engine 122 retrieves the script, the content rendering engine 122 can determine whether the script has changed since a previous time obtaining the script. If so, the content rendering engine 122 may direct the code analysis module 124 to discard execution profile data obtained for the script, as this data may be invalid for the changed script. The content rendering engine 122 can determine whether the script has changed by hashing the script and comparing the resulting hash value with a previously stored hash value obtained by hashing a previous version of the script. If the hash values differ, the scripts likely differ to a high degree of probability (which probability depends on choice of hash function). The content rendering engine 122 may instead (or also) examine any hypertext markup language (HTML) header associated with the script to determine whether data in the header indicates that a new version of the script has been received.


At block 204, the content rendering engine 122 provides the script to a plurality of client devices. The content rendering engine 122 provides the script to each client device for which it is requested. At block 206, the code analysis module 124 collects execution profiles of the script from the client devices 104 (or from a subset thereof, e.g., by obtaining a random sample). As described above, the script engine 114 in some or all of the client devices 104 can profile a user's actual usage of the script based on the user's interactions with the script. The resulting execution profiles generated by these script engines 114 can include information regarding which methods or functions were executed by the script, how often these functions were executed, and the amount of time that the functions took to execute, among other data. Further, the execution profiles may also include information about functions or other parts of the script that rarely or never executed, giving clues as to which functions or parts of the script to avoid optimizing. Similarly, the execution profiles may include information on the code path taken by users, including branch behavior of the script. For example, the execution profiles may include information regarding which branches (such as if-then statements, case statements, and switch statements) that were frequently or always followed. This information can also give clues as to which portions of the script to optimize (e.g., the branch that is most commonly selected). For instance, if 85% of the execution profiles indicate that a certain “if” statement was true, it may be beneficial to focus optimization on the Boolean true path of that “if” statement.


The code analysis module 124, at block 208, aggregates the collected execution profiles into an aggregate execution profile for the script. The code analysis module 124 can do so by accumulating related data in the execution profiles. For instance, the code analysis module 124 can accumulate the number of times various users executed or entered the same function in the script. The code analysis module 124 can repeat this process for each function. This aggregate number may be much higher for some functions that would ordinarily be executed a small number of times by individual users. As a result, this number may be used as a clue or data point that suggests that the related functions might benefit from optimization. Similarly, the total execution time for a given function or portion of the script can be accumulated by the code analysis module 124. Alternatively, the number of times that functions were executed or their execution times can be averaged by the code analysis module 124, or other mathematical operations may be performed on such data.


At decision block 210, the code analysis module 124 determines whether sufficient profile data has been obtained from the client devices 104. Once sufficient data has been obtained, the code analysis module 124 can proceed to send the aggregate execution profile for the script or perform script compiling (and associated optimizations) at block 212. The features of block 212 are described in greater detail with respect to subsequent FIGURES. However, if sufficient data is not obtained at block 210, the process 200 can loop back to block 204 (and/or block 202), where the process 200 continues to obtain script execution profiles from client devices 104 to which the script is provided.


Determining whether sufficient profile data has been obtained may be performed in a number of ways. The code analysis module 124 may, for instance, compare the number of execution profiles received with a predetermined threshold to determine whether a sufficient number of profiles have been received. Alternatively, the code analysis module 124 can determine whether a predetermined time period has elapsed prior to aggregating the profiles. In another embodiment, the code analysis module 124 optimizes or attempts to optimize a script until a certain hotness level is achieved for some or all of the methods of the script, such as the highest level of hotness. Once that level is reached, aggregation of the profile data may be considered sufficient.


In another embodiment, sufficiency is determined by determining whether there is convergence in the common code path detected in the aggregate execution profile. As described above, the code analysis module 124 can detect common code paths in the execution profiles and can store this information in the aggregate execution profile. As execution profiles are initially combined to create the aggregate execution profile, the common code path information may change rapidly because different client devices 104 may have entered different functions, branches, or the like. After several execution profiles have been aggregated into the aggregate execution profile, a common pattern may begin to emerge in function calls and/or branch behavior, such that the common code path information may start to change slowly, indicating convergence on a common code path or paths. In another embodiment, the code analysis module 124 determines whether the distribution of usage of the script's functions or branches has reached a stable or convergence point, at which point the code analysis module considers sufficiency to be reached. Moreover, the code analysis module may use any of the sufficiency measures described herein together or in concert to measure sufficiency.


Although aggregation may be considered sufficient, the code analysis module 124 may still continue to aggregate execution profiles in some embodiments. Further, in other embodiments, no check for sufficiency is made, and the code analysis module 124 sends aggregation profiles to the client devices 104 that request content as the aggregation profiles are made.


Furthermore, although the code analysis module 124 may collect data from every client device 104 with which it interacts, in other embodiments the code analysis module 124 samples profile data from a smaller subset of the client devices 104. Sampling profiles may be a more efficient way to obtain profile data than aggregating profile data from all client devices 104. In one embodiment, the code analysis module 124 samples a small portion of client devices 104 initially to determine whether most or all devices are taking the same (or substantially same) execution path. If most or all devices are taking the same (or substantially same) execution path, there may be little to no benefit in sampling more, as the code analysis module 124 knows which execution path to optimize.


Conversely, if in the small sample of execution profiles from client devices 104, the execution path is not converging, the code analysis module 124 may increase the sampling rate or percentage of client devices 104 being sampled until some convergence or stabilization in execution path is reached. Thus, in one example scenario, the code analysis module 124 may sample about 10% of client devices 104, ramp up to sampling about 50% of client devices 104 after not detecting convergence, and ramp down to sampling 5% (or even 0%, e.g., no longer collecting data) after reaching some measure of convergence or stability in the execution path.


IV. Example Script Optimization State Flows


FIGS. 3 through 5 depict various state flow diagrams in which the client device 104 requests content from the intermediary system 120, which in turn retrieves the content including a script from the content server 106. Each state flow diagram then focuses on how example embodiments of the intermediary system 120 interacting with the client device 104 to provide enhanced compilation of the script. For ease of illustration, further details regarding rendering and transmitting the remainder of the content are not shown. In addition, FIG. 6 depicts another embodiment of a state flow diagram for facilitating enhanced compilation of scripts that does not include an intermediary system 120. Each of the state flow diagrams in FIGS. 3 through 6 takes place after an aggregate execution profile is obtained for a script using the process 200 of FIG. 2.


Turning to FIG. 3, an embodiment of a state flow diagram 300 is depicted in which an aggregate execution profile of a script is provided to a client device 104. At state 1, the client device 104 requests content from the intermediary system 120. The intermediary system 120 in turn requests the content at state 2 from the content server 106. The content server 106 returns the content, including a script, at state 3 to the intermediary system 120.


At state 4, the intermediary system 120 identifies an aggregate execution profile associated with the script, for example, from the script data repository 126. If such a profile exists, the intermediary system 120 sends the aggregate execution profile to the client device 104 along with the script at state 5. At state 6, the client device 104 compiles the script with the aggregate execution profile using, for example, the script engine 114. The client device 104 then executes the compiled script at state 7. The client device 104 can also create another execution profile at state 8, based on the user's execution of the script, and can send this execution profile to the intermediary system at state 9. The intermediary system 120 can then incorporate the execution profile from the client device 104 in the aggregate execution profile.


In some embodiments, the script engine 114 of the client device 104 includes decision tree logic or the like that determines whether an aggregate execution profile has been received. If so, the client device 104 can use the aggregate execution profile to initiate compiler optimization instead of generating its own profile. However, in another embodiment, the client device 104 generates its own profile anyway and uploads this profile to the intermediary system 120 for further aggregation with the existing aggregate execution profile by the code analysis module 124. Thus, the code analysis module 124 can continue to aggregate and improve the aggregate execution profile based on information obtained from the client device 104. In still another embodiment, the client device 104 still performs its own execution profile but appends or otherwise aggregates the aggregate execution profile with its own, user-specific execution profile to create a custom aggregate execution profile. The script engine 114 can compile the script using this custom aggregate execution profile instead of the aggregate execution profile received at state 5.


In an embodiment, the script engine 114 in the client device 104 uses the aggregate execution profile to optimize compilation by identifying methods or functions or other parts of the script code that execute frequently, e.g., that have a certain hotness as described above. The client device 104 can then optimize these parts of the script during compilation. Advantageously, since the optimization of this compilation is performed based on the aggregate execution profile, optimization can be performed on most, more, or all of the script code to provide faster script code than might be obtained from an execution profile generated by a single client device 104.


In another embodiment, the intermediary system 120 can strip portions of the script that the intermediary system 120 has detected will never be executed or will likely not be executed prior to sending the script to the client device 104. The code path information contained in the aggregate execution profile can indicate to a high probability whether certain functions or branches of the script will never be executed based on aggregate behavior of many users. Stripping these portions of the script out of the script can beneficially reduce the network bandwidth consumption of the script's transmission to the client device 104 and can reduce the compile, execution, and/or load time of the script at the client device 104.



FIG. 4 depicts an embodiment of a state flow diagram 400 in which a decompiled script is provided to a client device 104. As above, at state 1, the client device 104 requests content from the intermediary system 120. The intermediary system 120 in turn requests the content at state 2 from the content server 106. The content server 106 returns the content, including a script, at state 3 to the intermediary system 120.


However, instead of sending an aggregated execution profile of the script to the client device 104, the intermediary system 120 instead compiles the script using the aggregate execution profile at state 4. At state 5, the intermediary system 120 decompiles the script. The resulting decompiled script may be more optimized than the script originally received at state 3. This increased optimization may be due in part to compilation of the script using the aggregate execution profile, which may indicate which portions (e.g., functions or subparts thereof) of the script are never logically executed. The compiler, when optimizing the script code, can remove or discard these portions of the code that are never logically executed. Some examples of code that may never be executed include debug code used during development of the script that now cannot logically be reached and branches of conditional statements that can never logically be reached. Further, the compiled code may also be optimized based on the other benefits of the aggregate execution profile described above.


The decompiled script is sent by the intermediary system 120 to the client device 104 at state 6. One advantage of sending this compiled and then decompiled code is that it may also be smaller in size, due to the removed code. Thus, transmission may consume less bandwidth and may be accomplished faster. The client device 104 can compile and execute the script at states 7 and 8, respectively. Further, as above with respect to FIG. 3, the client device 104 can also create another execution profile at state 9, based on the user's execution of the script, and can send this execution profile to the intermediary system at state 10. The intermediary system 120 can then incorporate the execution profile from the client device 104 in the aggregate execution profile.


In an embodiment, when compiling the script, the client device 104 can perform additional optimizations. In another embodiment, however, the client device 104 skips these optimizations since optimizations were initially performed by the intermediary system 120 when compiling the script at state 5. Skipping these optimizations can save compile time in some embodiments.


In an embodiment, the server-side compilation shown in FIG. 4 can compile just a part of the script that the client devices 104 tend to not focus on optimizing to reduce compile time in the intermediary system 120. If the aggregate execution profile indicates that a certain method is executed very frequently on any given individual client device 104, the intermediary system 120 can leave that method unoptimized and uncompiled, as the client device 104 will likely optimize that method. Conversely, the intermediary system 120 can focus on optimizing and compiling methods that tend not to be frequently executed on any given individual client device 104 because otherwise, the client device 104 might not optimize those methods. As an example, a script-based video game may include an initialization portion and a main game loop. The main game loop may execute frequently, such that the intermediary system 120 can have a level of confidence that the client device 104 will likely optimize that portion of the script. Conversely, the initialization portion may be executed much less frequently, and the intermediary system 120 can compile and optimize that portion while leaving the rest of the script uncompiled.



FIG. 5 depicts an embodiment of a state flow diagram 500 in which a compiled script is provided to a client device 104. The state flow diagram 500 proceeds as the state flow diagram 400 until state 5, where instead of decompiling the compiled code and sending the decompiled code to the content device 104, the intermediary system 120 sends the compiled code directly to the client device 104. The client device 104 can then execute the compiled script.


Thus, in FIG. 5, the client device 104 can skip the compilation process and thereby execute the script faster. However, the browser 112 of the client device 104 may be modified to expect to receive the compiled script instead of the script source code.



FIG. 6 depicts an embodiment of a state flow diagram 600 in which an aggregate execution profile of a script is provided to a client device 504 without using an intermediary system 120. The client device 504 can have all the functionality of the client device 104 described above, as well as additional functionality described herein.


At state 1, the client device 504 sends a content request directly to the content server 106. The content server 106 responds at state 2 with the content, which includes a script. At state 3, the client device 504 requests an aggregate execution profile of the script from a script analysis system 524. In one embodiment, the browser in the client device 504 is modified to request the aggregate execution profile at state 3 in response to receiving the script at state 2.


The script analysis system 524 can include all of the functionality of the code analysis module 124 described above but may be implemented as an independent system other than the intermediary system 120. The script analysis system 524 may also implement the process 200 of FIG. 2 to obtain execution profiles from a plurality of client devices 504 and aggregate these profiles into an aggregate execution profile.


At state 4, the script analysis system 524 provides the aggregate execution profile to the client device 504. As in FIG. 3, the client device 504 can use the aggregate execution profile to compile and execute the script at states 6 and 7.


Alternatively, the client device at state 3 can provide the script to the script analysis system 524, which can compile the script using the aggregate execution profile and send either the compiled version or a decompiled version thereof to the client device 504. Thus, in certain embodiments, the state flow diagram 600 of FIG. 6 acts as a pull model, with the client device 504 pulling either aggregate execution profile information or optimized script code from the script analysis system 524. In contrast, the state flow diagrams 300-500 of FIGS. 3 through 5 operate as push models, with the intermediary system 120 providing either aggregate execution profile information or optimized script code to the client device 104.


V. Example Browser User Interfaces


FIG. 7 depicts an embodiment of an example browser user interface 700 that may implement any of the scripts described herein. The browser user interface 700 includes a content page 702 that further includes example user interface controls 710-730, any number of which can trigger a script associated with the user interface 700 to be executed. In the depicted embodiment, the controls 710-730 include a text box control 710, a search button 720, and links 730. User selection of any of these controls 710-730 can cause a script embedded in the content page 702 to execute and perform any of a variety of actions, such as loading a new page, making a dynamic modification to the content page 702, bounds-checking input values (e.g., in the text box 710), and so forth. Advantageously, in certain embodiments, the script or scripts executed can be optimized or improved using any of the techniques described above.


As an example, a select box control 740 is shown with the text “Select Language.” A user can select the select box control 740 using a mouse cursor 742 (or with the user's finger on a mobile device, without a cursor) to cause the select box control 740 to expand. Instead of using the standard HTML select box, in an embodiment, the browser user interface 700 can use a custom select box based on a script such as JavaScript to output a more full-featured select box. Thus, for example, user selection of the select box control 740 can cause a menu 850 such as that shown in a browser user interface 800 of FIG. 8 to be displayed. The menu 850 is wider, being double-columned, than a standard HTML text box, and includes languages that may be selected to cause the content page 702 to be translated into the selected language. In one embodiment, the code analysis module 124 can determine from aggregate execution profiles that users frequently select the select box control 740 and select a specific language in a particular geographic region. The content rendering engine 122 can use this information to optimize the execution of this script.


Further, the content rendering engine 122 can use this information to cause the content page 702 to automatically select the desired language and translate the page, for example, using any of the content page profiling techniques described below.


VI. Content Page Profiling

As described, profiling can be performed for code other than scripts. For example, code profiling can be done to identify execution paths of browser code, such as HTML code, in addition to or instead of script code. It may be useful, for instance, to determine which common browsing actions a plurality of users take so as to enable those actions to be taken beforehand by pre-rendering a content page.


Referring again to FIG. 1, as mentioned above, the client device 104 can also include a page profiler 116. The page profiler 116 may include hardware and/or software for profiling user browsing interactions with respect to one or more content pages. The page profiler 116 may be integral with the browser 112 (e.g., as a plug-in) or may be a separate component that communicates with the browser 112. The page profiler 116 can identify user interactions with a content page provided by the intermediary system 120 or a content server 106, including interactions such as selection of a link, expansion of a menu, scrolling of the content page, playing a video, filling at least a portion of a form, expanding a select box, or interaction with a script to perform any of these actions or others. More generally, the page profiler 116 can identify an execution path of the client device 104 based on the browsing actions of a user. The execution path may include a click path taken by a user. As an example, the execution path might include information about a user clicking a first link, then expanding a menu and selecting a second link from the menu, followed by the user scrolling to the bottom of the page.


The page profiler 116 can provide this browsing profile data to the code analysis module 124 of the intermediary system 120. The code analysis module 124 can aggregate this profile data to produce an aggregate execution profile or aggregate browsing profile for a content page, much like the aggregate script execution profiles described above. In an embodiment, this aggregate browsing profile can include information on common execution paths taken by the client devices 104, the number or frequency of user browse interactions with the content page, and so forth. The code analysis module 124 can perform sampling, similar to any of the sampling techniques described above, to collect profile data from a portion of the client devices 104, rather than all devices 104, in some embodiments.


The content rendering engine 122 can use the aggregate browse profile to modify the content page to reflect a common browse interaction or execution path in response to the content page being requested by one of the client devices 104. Thus, for example, if the aggregate browsing profile includes a common execution path taken by many client devices 104 such as expanding a particular menu, the content rendering engine 122 can modify the code of the content page to expand the menu and send the modified content page to the requesting client device 104. In another example embodiment, pre-selection of a link by the content rendering module 122 causes the content rendering module 122 to fetch the linked-to content page from the content server 106 and supply this linked-to content page as the modified page in place of the originally-requested content page. As a result of modifying the page (or fetching a linked-to page), the content rendering engine 122 can enable users to reach more relevant content in the modified content page faster than if the content rendering engine 122 were to send the unmodified content page to the client device 104.


As another example, users may access a content page and commonly scrolling immediately to a bottom portion of the page. The code analysis module 124 can identify this common scroll point as, for example, a common X (horizontal), Y (vertical) position (or just Y position) taken by users. The content rendering engine 122 can subsequently modify the content page to reflect this common scroll point, such that the browser 112 of the client device 104 receiving the modified content page scrolls immediately to the common scroll point.


In one embodiment, the content rendering engine 122 can be said to pre-render the content page to create any of the modifications described above. Such modifications can speed up the user browsing experience and may be particularly beneficial for mobile devices, although any device or user may benefit from faster loading of relevant content.


The content rendering engine 122 can use thresholding techniques to determine which execution paths to take when modifying a content page. For instance, the content rendering engine 122 can determine whether a threshold percentage of users take a certain execution path. If the threshold is met, the content rendering engine 122 can modify the content page to match the execution path (or at least a portion thereof). The threshold may be a relatively high percentage for some browse actions and relatively lower percentage for other browse actions. Some browse actions, like selecting a link to fetch a new content page, may have a higher threshold than expanding a menu to show a submenu, for instance. In some embodiments, more major modifications to the page may have a higher threshold than more minor modifications to a page. Some examples of major modifications might include, for example, selecting of links, selecting of menu options, and the like, while some examples of minor actions can include playing a video upon loading, filling commonly-filled fields of a form with generic information, and so on. However, any of the above user browse actions can be considered either major or minor modifications in different scenarios, which may depend on the type of content page being modified.



FIG. 9 depicts an embodiment of a state flow diagram 900 in which a content page is modified based on user browsing interactions. At state 1, the client device 104 requests a content page from the intermediary system 120. The intermediary system 120 in turn requests the content page at state 2 from the content server 106. The content server 106 returns the content page at state 3 to the intermediary system 120. The content page may or may not include a script.


At state 4, the intermediary system identifies one or more common browsing interactions based on aggregate browsing data collected from a plurality of client devices 104. The intermediary system 120 can then pre-render the content page based on the browsing interaction to produce a modified content page at state 5. The intermediary system 120 then sends the modified content page to the client device at state 6. The client device 104 can then output the modified content page at state 7, which may include performing other rendering of the page.



FIG. 10 depicts an example browser user interface 1000 that may implement the modified content page described above with respect to FIG. 9. The browser user interface 1000 includes all the features of the browser user interface 700 of FIG. 7. In particular, the browser user interface 1000 is an embodiment of a modified content page, where the original content page is the browsing user interface 700 of FIG. 7.


In an embodiment, the code analysis module 124 of FIG. 1 may identify a common user browse action with respect to the browsing user interface 700 of FIG. 7, in that most users initially select the “Entertainment” link 730 upon loading of the browsing user interface 700. The content rendering engine 122 can therefore modify the code of the browsing user interface 700 to cause the browsing user interface 1000 to already have this link selected upon loading. As a result, in this particular example embodiment, the browsing user interface 1000 includes a listing of sub-links 1010 below the “Entertainment” link 730 upon loading of the browsing user interface 1000, as if the user had pre-selected the “Entertainment” link 730 without actually requiring the user to do so.


VII. Terminology

Many other variations than those described herein will be apparent from this disclosure. For example, depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the algorithms). Moreover, in certain embodiments, acts or events can be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines and/or computing systems that can function together.


The various illustrative logical blocks, modules, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.


The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor may also include primarily analog components. For example, any of the signal processing algorithms described herein may be implemented in analog circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, and a computational engine within an appliance, to name a few.


The steps of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of non-transitory computer-readable storage medium, media, or physical computer storage known in the art. An example storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor and the storage medium can reside as discrete components in a user terminal.


Conditional language used herein, such as, among others, “can,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list. Further, the term “each,” as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term “each” is applied.


While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As will be recognized, certain embodiments of the inventions described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others.

Claims
  • 1. A method of facilitating enhanced script execution performance, the method comprising: collecting execution profiles of a script from a plurality of client devices;aggregating the collected execution profiles, said aggregating comprising (1) identifying portions of the script that cannot execute in a compiled script and (2) producing an aggregate execution profile of the script;receiving a request from a first client device to access a network resource that is associated with the script;retrieving the script from a content server;providing the script to the first client device; andproviding the aggregate execution profile to the first client device to enable the first client device to compile the script, using the aggregate execution profile, to produce the compiled script that excludes the portions of the script that cannot execute;wherein at least said aggregating and said providing the aggregate execution profile to the first client device are implemented by a computer system comprising computer hardware.
  • 2. The method of claim 1, wherein said aggregating the collected execution profiles comprises accumulating data in the collected execution profiles.
  • 3. The method of claim 2, wherein said accumulating data comprises accumulating a number of times users accessed portions of the script.
  • 4. The method of claim 3, wherein said accumulating is configured to emphasize the portions of the script for the purpose of triggering compiler optimization.
  • 5. The method of claim 1, further comprising transmitting the script to the plurality of client devices with an intermediary system.
  • 6. A system for facilitating enhanced script execution performance, the system comprising: a code analysis module comprising computer hardware, the code analysis module configured to: collect execution profiles of a code module from a plurality of client devices, andaggregate the collected execution profiles to (1) identify portions of the script that cannot execute in a compiled script and (2) produce an aggregate execution profile of the code module; andprovide the aggregate execution profile to a first client device to enable the first client device to compile the code module, using the aggregate execution profile, to produce the compiled script that excludes the portions of the script that cannot execute.
  • 7. The system of claim 6, wherein the code analysis module is further configured to aggregate the collected execution profiles by at least determining a common code path in the collected execution profiles.
  • 8. The system of claim 7, wherein the code analysis module is further configured to determine the common code path by determining which functions or code branches are commonly executed.
  • 9. The system of claim 8, wherein the code analysis module is further configured to accumulate the data by at least emphasizing the portions of the code module for the purpose of triggering compiler optimization.
  • 10. The system of claim 6, wherein the code analysis module is implemented on an intermediary system configured to act as a proxy for requests from the first client device to receive content.
  • 11. The system of claim 10, further comprising a content rendering engine configured to receive a request for content from the first client device, to retrieve the requested content and the code module from a content server, and send the code module to the first client device.
  • 12. The system of claim 6, wherein the code analysis module is further configured to provide the aggregate execution profile of the code module to the first client device without providing the code module to the first client device.
  • 13. A method of facilitating enhanced script execution performance, the method comprising: collecting execution profiles of a script from a plurality of client devices;aggregating the collected execution profiles, said aggregating comprising (1) identifying portions of the script that cannot execute in a compiled script and (2) producing an aggregate execution profile of the script;receiving a request from a first client device to access a network resource that is associated with the script;accessing the script from a content server;compiling the script to produce the compiled script, said compiling comprising using the aggregate execution profile of the script to optimize compilation of the script by at least excluding the portions of the script that cannot execute from the compiled script;decompiling the compiled script to produce a modified script; andproviding the modified script to the first client device.
  • 14. The method of claim 13, wherein said aggregating the collected execution profiles comprises accumulating data in the collected execution profiles.
  • 15. The method of claim 14, wherein said accumulating data comprises accumulating a number of times users accessed portions of the script.
  • 16. The method of claim 15, wherein said accumulating is configured to emphasize the portions of the script for the purpose of triggering compiler optimization.
  • 17. The method of claim 13, wherein said collecting comprises sampling a portion of a set of client devices that access the script.
  • 18. A system for facilitating enhanced script execution performance, the system comprising: a code analysis module configured to: collect execution profiles of a script from a plurality of client devices, andaggregate the collected execution profiles to (1) identify portions of the script that cannot execute in a compiled script and (2) produce an aggregate execution profile of the script; anda content rendering engine comprising computer hardware, the content rendering engine configured to: access the script;compile the script to produce a compiled script, said compiling comprising using the aggregate execution profile of the script to optimize compilation of the script by at least excluding the portions that cannot execute from the compiled script;decompile the compiled script to produce a modified script; andprovide the modified script to a first client device.
  • 19. A system for facilitating enhanced script execution performance, the system comprising: a code analysis module configured to: collect execution profiles of a script from a plurality of client devices, andaggregate the collected execution profiles to produce an aggregate execution profile of the script, the aggregate execution profile comprising code path information that indicates which portions of the script that are not likely to be executed; anda content rendering engine comprising computer hardware, the content rendering engine configured to: remove the portions of the script not likely to be executed from the script to produce a first modified script;compile the first modified script to produce a compiled script;decompile the compiled script to produce a second modified script; andprovide the second modified script to a first client device.
  • 20. The system of claim 19, further comprising providing the aggregate execution profile to the first client device.
US Referenced Citations (263)
Number Name Date Kind
5634064 Warnock et al. May 1997 A
5872850 Klein et al. Feb 1999 A
5961593 Gabber et al. Oct 1999 A
6049812 Bertram et al. Apr 2000 A
6108637 Blumenau Aug 2000 A
6138156 Fletcher et al. Oct 2000 A
6144991 England Nov 2000 A
6195679 Bauersfeld et al. Feb 2001 B1
6282542 Carneal et al. Aug 2001 B1
6430624 Jamtgaard et al. Aug 2002 B1
6438597 Mosberger et al. Aug 2002 B1
6513061 Ebata et al. Jan 2003 B1
6549941 Jaquith et al. Apr 2003 B1
6560620 Ching May 2003 B1
6560705 Perlman et al. May 2003 B1
6625624 Chen et al. Sep 2003 B1
6704024 Robotham et al. Mar 2004 B2
6704204 Eskildsen et al. Mar 2004 B1
6785864 Te et al. Aug 2004 B1
6842777 Tuli Jan 2005 B1
6871236 Fishman et al. Mar 2005 B2
6931439 Hanmann et al. Aug 2005 B1
6944665 Brown et al. Sep 2005 B2
6963850 Bezos et al. Nov 2005 B1
6976059 Rogalski et al. Dec 2005 B1
7003442 Tsuda Feb 2006 B1
7051084 Hayton et al. May 2006 B1
7054952 Schwerdtfeger et al. May 2006 B1
7082476 Cohen et al. Jul 2006 B1
7085736 Keezer et al. Aug 2006 B2
7085753 Weiss et al. Aug 2006 B2
7089316 Andersen et al. Aug 2006 B2
7159023 Tufts Jan 2007 B2
7171478 Lueckhoff et al. Jan 2007 B2
7191211 Tuli Mar 2007 B2
7260841 Tenereillo Aug 2007 B2
7353252 Yang et al. Apr 2008 B1
7373313 Kahle et al. May 2008 B1
7409719 Armstrong et al. Aug 2008 B2
7441045 Skene et al. Oct 2008 B2
7448079 Tremain Nov 2008 B2
7543059 Johnson et al. Jun 2009 B2
7792944 DeSantis et al. Sep 2010 B2
7831582 Scofield et al. Nov 2010 B1
7865528 Neil Jan 2011 B2
7890528 Khoshnevisan Feb 2011 B1
7941450 Hulaj et al. May 2011 B2
7975000 Dixon et al. Jul 2011 B2
7991859 Miller et al. Aug 2011 B1
7996912 Spalink et al. Aug 2011 B2
8010545 Stefik et al. Aug 2011 B2
8010679 Low et al. Aug 2011 B2
8015343 Garman et al. Sep 2011 B2
8015496 Rogers Sep 2011 B1
8051166 Baumback et al. Nov 2011 B1
8051180 Mazzaferri et al. Nov 2011 B2
8060463 Spiegel Nov 2011 B1
8073850 Hubbard et al. Dec 2011 B1
8103742 Green Jan 2012 B1
8117314 Croft et al. Feb 2012 B2
8171085 Tevanian, Jr. May 2012 B1
8185621 Kasha May 2012 B2
8190682 Paterson-Jones et al. May 2012 B2
8195767 Albrecht et al. Jun 2012 B2
8209623 Barletta et al. Jun 2012 B2
8224964 Fredrickson et al. Jul 2012 B1
8249904 DeSantis et al. Aug 2012 B1
8271887 Offer et al. Sep 2012 B2
8316124 Baumback et al. Nov 2012 B1
8336049 Medovich Dec 2012 B2
8839200 Roskind Sep 2014 B1
20010039490 Verbitsky et al. Nov 2001 A1
20010051996 Cooper et al. Dec 2001 A1
20010052006 Barker et al. Dec 2001 A1
20020026511 Garcia-Luna-Aceves et al. Feb 2002 A1
20020030703 Robertson et al. Mar 2002 A1
20020107985 Hwang et al. Aug 2002 A1
20020184493 Rees Dec 2002 A1
20020194302 Blumberg Dec 2002 A1
20030004882 Holler et al. Jan 2003 A1
20030005041 Ullmann et al. Jan 2003 A1
20030014478 Noble Jan 2003 A1
20030023712 Zhao et al. Jan 2003 A1
20030041106 Tuli Feb 2003 A1
20030046335 Doyle et al. Mar 2003 A1
20030208570 Lapidous Nov 2003 A1
20030233621 Paolini et al. Dec 2003 A1
20040010543 Grobman Jan 2004 A1
20040030887 Harrisville-Wolff et al. Feb 2004 A1
20040066397 Walker et al. Apr 2004 A1
20040083294 Lewis Apr 2004 A1
20040098463 Shen et al. May 2004 A1
20040139208 Tuli Jul 2004 A1
20040143579 Nakazawa Jul 2004 A1
20040181613 Hashimoto et al. Sep 2004 A1
20040205448 Grefenstette et al. Oct 2004 A1
20040220905 Chen et al. Nov 2004 A1
20040228335 Park et al. Nov 2004 A1
20040243622 Morisawa Dec 2004 A1
20040260767 Kedem et al. Dec 2004 A1
20050010863 Zernik Jan 2005 A1
20050027815 Christodoulou et al. Feb 2005 A1
20050060643 Glass et al. Mar 2005 A1
20050138382 Hougaard et al. Jun 2005 A1
20050183039 Revis Aug 2005 A1
20050188361 Cai et al. Aug 2005 A1
20050246193 Roever et al. Nov 2005 A1
20060031774 Gaudette Feb 2006 A1
20060085766 Dominowska et al. Apr 2006 A1
20060095336 Heckerman et al. May 2006 A1
20060122889 Burdick et al. Jun 2006 A1
20060123092 Madams et al. Jun 2006 A1
20060161535 Holbrook Jul 2006 A1
20060168510 Bryar et al. Jul 2006 A1
20060184421 Lipsky et al. Aug 2006 A1
20060248195 Toumura et al. Nov 2006 A1
20060248442 Rosenstein et al. Nov 2006 A1
20060277167 Gross et al. Dec 2006 A1
20060280121 Matoba Dec 2006 A1
20060294366 Nadalin et al. Dec 2006 A1
20060294461 Nadamoto et al. Dec 2006 A1
20070022072 Kao et al. Jan 2007 A1
20070027672 Decary et al. Feb 2007 A1
20070094241 Blackwell et al. Apr 2007 A1
20070118740 Deishi May 2007 A1
20070124693 Dominowska et al. May 2007 A1
20070139430 Korn et al. Jun 2007 A1
20070226044 Hanson Sep 2007 A1
20070240160 Paterson-Jones et al. Oct 2007 A1
20070288589 Chen et al. Dec 2007 A1
20070288855 Rohrabaugh et al. Dec 2007 A1
20080016040 Jones et al. Jan 2008 A1
20080028334 De Mes Jan 2008 A1
20080086264 Fisher Apr 2008 A1
20080104502 Olston May 2008 A1
20080134033 Burns et al. Jun 2008 A1
20080148401 Shen Jun 2008 A1
20080155691 Fossen et al. Jun 2008 A1
20080183672 Canon et al. Jul 2008 A1
20080183889 Andreev et al. Jul 2008 A1
20080184128 Swenson et al. Jul 2008 A1
20080189770 Sachtjen Aug 2008 A1
20080222299 Boodaei Sep 2008 A1
20080229025 Plamondon Sep 2008 A1
20080291294 Cha Nov 2008 A1
20080301225 Kamura Dec 2008 A1
20080320225 Panzer et al. Dec 2008 A1
20090012969 Rail et al. Jan 2009 A1
20090013034 Cheng et al. Jan 2009 A1
20090019372 Chu et al. Jan 2009 A1
20090049443 Powers et al. Feb 2009 A1
20090063854 Parkinson Mar 2009 A1
20090164597 Shuster Jun 2009 A1
20090164924 Flake et al. Jun 2009 A1
20090204478 Kaib et al. Aug 2009 A1
20090204964 Foley et al. Aug 2009 A1
20090217199 Hara et al. Aug 2009 A1
20090240717 Mimatsu Sep 2009 A1
20090241191 Keromytis et al. Sep 2009 A1
20090248680 Kalavade Oct 2009 A1
20090254867 Farouki et al. Oct 2009 A1
20090276488 Alstad Nov 2009 A1
20090282021 Bennett Nov 2009 A1
20090287698 Marmaros et al. Nov 2009 A1
20090327914 Adar et al. Dec 2009 A1
20100027552 Hill Feb 2010 A1
20100036740 Barashi Feb 2010 A1
20100042724 Jeon et al. Feb 2010 A1
20100057639 Schwarz et al. Mar 2010 A1
20100070569 Turakhia Mar 2010 A1
20100070849 Sadan et al. Mar 2010 A1
20100125507 Tarantino, III et al. May 2010 A1
20100131594 Kashimoto May 2010 A1
20100131646 Drako May 2010 A1
20100138293 Ramer et al. Jun 2010 A1
20100144314 Sherkin et al. Jun 2010 A1
20100161754 Davis Jun 2010 A1
20100198742 Chang et al. Aug 2010 A1
20100218106 Chen et al. Aug 2010 A1
20100235473 Koren et al. Sep 2010 A1
20100281112 Plamondon Nov 2010 A1
20100293190 Kaiser et al. Nov 2010 A1
20100312788 Bailey Dec 2010 A1
20100313149 Zhang et al. Dec 2010 A1
20100318892 Teevan et al. Dec 2010 A1
20100325239 Khedouri et al. Dec 2010 A1
20100325287 Jagadeeswaran et al. Dec 2010 A1
20100332513 Azar et al. Dec 2010 A1
20110022957 Lee Jan 2011 A1
20110029854 Nashi et al. Feb 2011 A1
20110055203 Gutt et al. Mar 2011 A1
20110055398 DeHaan et al. Mar 2011 A1
20110066982 Paulsami et al. Mar 2011 A1
20110072502 Song et al. Mar 2011 A1
20110078140 Dube et al. Mar 2011 A1
20110078705 Maclinovsky et al. Mar 2011 A1
20110119352 Perov May 2011 A1
20110119661 Agrawal et al. May 2011 A1
20110161849 Stallings et al. Jun 2011 A1
20110173177 Junqueira et al. Jul 2011 A1
20110173637 Brandwine et al. Jul 2011 A1
20110178868 Garg et al. Jul 2011 A1
20110185025 Cherukuri et al. Jul 2011 A1
20110191327 Lee Aug 2011 A1
20110197121 Kletter Aug 2011 A1
20110208822 Rathod Aug 2011 A1
20110208840 Blackman Aug 2011 A1
20110212717 Rhoads et al. Sep 2011 A1
20110214082 Osterhout et al. Sep 2011 A1
20110246873 Tolle et al. Oct 2011 A1
20110261828 Smith Oct 2011 A1
20110271175 Lavi et al. Nov 2011 A1
20110289074 Leban Nov 2011 A1
20110289157 Pirnazar Nov 2011 A1
20110296341 Koppert Dec 2011 A1
20110296503 Shull et al. Dec 2011 A1
20110302510 Harrison et al. Dec 2011 A1
20110320598 Solin Dec 2011 A1
20110321139 Jayaraman et al. Dec 2011 A1
20120005600 Ito Jan 2012 A1
20120022942 Holloway et al. Jan 2012 A1
20120030460 Chang Feb 2012 A1
20120054316 Piazza et al. Mar 2012 A1
20120054869 Yen et al. Mar 2012 A1
20120066502 Borneman et al. Mar 2012 A1
20120066586 Shemesh Mar 2012 A1
20120072821 Bowling Mar 2012 A1
20120084433 Bar-Caspi et al. Apr 2012 A1
20120084644 Robert et al. Apr 2012 A1
20120096365 Wilkinson et al. Apr 2012 A1
20120110017 Gu et al. May 2012 A1
20120117565 Staelin et al. May 2012 A1
20120117649 Holloway et al. May 2012 A1
20120137201 White et al. May 2012 A1
20120143944 Reeves et al. Jun 2012 A1
20120144288 Caruso et al. Jun 2012 A1
20120150844 Lindahl et al. Jun 2012 A1
20120166922 Rolles Jun 2012 A1
20120192220 Wyatt et al. Jul 2012 A1
20120198020 Parker et al. Aug 2012 A1
20120198516 Lim Aug 2012 A1
20120203904 Niemela et al. Aug 2012 A1
20120210233 Davis et al. Aug 2012 A1
20120215833 Chen et al. Aug 2012 A1
20120215834 Chen et al. Aug 2012 A1
20120215919 Labat et al. Aug 2012 A1
20120216035 Leggette et al. Aug 2012 A1
20120254402 Panidepu et al. Oct 2012 A1
20120284629 Peters et al. Nov 2012 A1
20120297341 Glazer et al. Nov 2012 A1
20120317295 Baird et al. Dec 2012 A1
20120324043 Burkard et al. Dec 2012 A1
20120331406 Baird et al. Dec 2012 A1
20130007102 Trahan et al. Jan 2013 A1
20130031461 Hou et al. Jan 2013 A1
20130051686 Bennett Feb 2013 A1
20130080611 Li et al. Mar 2013 A1
20130097380 Colgrove et al. Apr 2013 A1
20130103785 Lyon Apr 2013 A1
20130185715 Dunning et al. Jul 2013 A1
20130254652 Chinosornvatana et al. Sep 2013 A1
20140181803 Cooper Jun 2014 A1
20160132547 Hong May 2016 A1
Non-Patent Literature Citations (35)
Entry
Amazon Gives Virtual Private Clouds Internet Access, available at http://web2.sys-con.com/node/1759026/, Mar. 2011.
Acharya et al., Balancing Push and Pull for Data Broadcast, Proceedings of ACM SIGMOD Conference, May 1997, pp. 1-12, Tucson, AZ.
Acharya et al., Prefetching from a Broadcast Disk, Proceedings of the International Conference on Data Engineering, Feb. 1996, New Orleans, LA.
Amazon Gives Virtual Private Clouds Internet Access, available at http://web2.sys-con.com/node/1759023/, Mar. 2011.
Bango, Rey “How JS & Ajax work in Opera Mini 4”, Nov. 2, 2007, XP055050107, Retrieved from the Internet.
Baumann, A., et al., Enhancing STEM Classes Using Weave: A Collaborative Web-Based Visualization Environment, Integrated Stem Education Conference Apr. 2, 2011, pp. pp. 2A-1-2A-4, Ewing, New Jersey.
Bestavros et al., Server-initiated Document Dissemination for the WWW, IEEE Data Engineering Bulletin, Sep. 1996, vol. 19, Issue 3, pp. 3-11, Boston, MA.
Brinkmann, M., “Record and Share your browser history with Hooeey,” ghacks.net, Feb. 26, 2008, 6 pages, printed on Jan. 25, 2013.
Brooks et al., Application-Specific Proxy Servers as HTTP Stream Transducers, Dec. 1995, pp. 1-7.
Chen, H., et al., Bringing Order to the Web: Automatically Categorizing Search Results, Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Apr. 2000, pp. 145-152.
Chinen et al., An Interactive Prefetching Proxy Server for Improvement of WWW Latency, Jun. 1997, pp. 1-10.
Considine, A., The Footprints of Web Feet, The New York Times, accessed Jan. 25, 2013, Mar. 4, 2011, pp. 3.
Curewitz et al., Practical Prefetching via Data Compression, SIGMOD Conference, 1993, pp. 10, San Diego, CA.
De Carvalho, L.G., et al., Synchronizing Web Browsing Data With Browserver, Proceedings of the IEEE Symposium on Computers and Communications, Jun. 22-25, 2010, Riccione, Italy, pp. 738-743.
Dias et al., A Smart Internet Caching System, 1996, pp. 1-12, Moratuwa, Sri Lanka.
EyeBrowse: Record, Visualize and Share your Browser History, Information Aesthetics, Sep. 18, 2009, 2 pages, printed on Jan. 25, 2013.
Feuerstein, A., Flyswat Takes Aim, San Francisco Business Times, printed from http://www.bizjournals.com/sanfrancisco/stories/1999/10/25/story2.html?t=printable, Oct. 22, 1999, pp. 2.
Franklin et al., Dissemination-Based Information Systems, IEEE Data Engineering Bulletin, Sep. 1996, vol. 19, Issue 3, pp. 1-9.
Gabber, et al., “How to Make Personalized Web Browsing Simple, Secure, and Anonymous,” Financial Cryptography, 16 pages (1997).
Gingerich, J., Keycorp Making Site Into Portal, KRTBN Knight-Ridder Tribune Business News (South Bend Tribune, Indiana), Oct. 25, 1999, pp. 2.
Gulbrandsen et al., “A DNS RR for specifying the location of services (DNS SRV)”, RFC 2782, 12 pages, Feb. 2000.
Hopper, D.I. , Desktops Now Have Power to Comparison-Shop, http://www.cnn.com/TECH/computing/9910/18/r.u.sure/index.html, accessed Oct. 18, 1999, pp. 3.
Inoue et al., An Adaptive WWW Cache Mechanism in the AI3 Network, 1997, pp. 1-9.
Kevin, Close ‘n’ Forget Firefox add on, Evilfantasy's Blog, Retrieved from the Internet: URL: http://evilfantasy.wordpress.com/2009/03/24/close-%E2%80%98n%E2%80%99-forget-firefox-add-on/ [retrieved on Feb. 7, 2013]., Mar. 24, 2009.
Malik et al., “Virtual Cloud: Rent Out the Rented Resources”, 6th International Conference on Internet Technology and Secured Transactions, Dec. 2011.
Mockapetris, “Domain Names—Implementation and Specification”, RFC 1035, 55 pages, Nov. 1987.
Opera Mini, http://en.wikipedia.org/wiki/Opera—mini, last modified on Mar. 7, 2013 at 10:31.
Padmanabhan et al., Using Predictive Prefetching to Improve World Wide Web Latency, Computer Communication Review, 1996, vol. 26, pp. 22-36.
Rao, H.C.-H.,et al., A Proxy-Based Personal Web Archiving Service, Operating Systems Review, 2001, vol. 35, Issue 1, pp. 61-72.
RSS Ticker: Add-ons for Firefox, https://addons.mozilla.org/en-US/firefox/addon/rss-ticker/, accessed Feb. 7, 2013, pp. 3.
Shrikumar et al., Thinternet: Life at the End of a Tether, 1994, vol. 222-09.
Sullivan, Danny, “Google Search History Expands, Becomes Web History”, http://searchengineland.com/google-search-history-expands-becomes-web-history-11016, Apr. 19, 2007,12 pages.
Teevan, J., et al., Changing How People View Changes on the Web, , Proceedings of the 22nd Annual ACM Symposium on User Interface Software and Technology, 2009, pp. pp. 237-246, New York.
Van Kleek, M., Introducing “Eyebrowse”—Track and share your web browsing in real time, Haystack Blog, accessed Jan. 25, 2013, Aug. 28, 2009, pp. 3.
Wang et al., Prefetching in World Wide Web, Department of Computer Science, University College London, Nov. 18-22, 1996, London, UK.