US20210056157A1

US20210056157A1 - Dynamic user agent strings

Info

Publication number: US20210056157A1
Application number: US17/094,453
Authority: US
Inventors: Jason Bosarge; D. Levi King; Spencer Patrick Smith
Original assignee: Cake Technologies Inc
Current assignee: Cake Technologies Inc
Priority date: 2017-07-25
Filing date: 2020-11-10
Publication date: 2021-02-25
Also published as: US20190034531A1; US20190034549A1; US10860674B2; US20190034541A1

Abstract

Optimizations are provided for distinguishing between webpages that are cached and webpages that have been or currently are displayed on a user interface. In some instances, a list of webpages is generated in response to a query entered by a user. Then, a determined number of webpages that were included in the list are cached in memory. These cached webpages each have an associated agent string, and at least some of these agent strings are updated to reflect a cached status. Subsequently, a first webpage is displayed on a user interface. This first webpage was included among those webpages that were cached. Further, the agent string for this webpage is updated to reflect an in-view status. In response to the first webpage being replaced by a second webpage, the agent string for the second webpage is then updated to reflect the in-view status.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 16/044,820 filed on Jul. 25, 2018, entitled “PAGE COMPETE,” which issued as U.S. Pat No. ______ on ______, 20______, and which application claims the benefit and priority to U.S. Provisional Application No. 62/536,851, entitled “PAGE COMPETE”, filed on Jul. 25, 2017, as well as U.S. Provisional Application No. 62/574,058, entitled “PAGE COMPETE”, filed on Oct. 18, 2017, as well as U.S. Provisional Application No. 62/538,451, entitled “DYNAMIC USER AGENT STRINGS”, filed on Jul. 28, 2017, as well as U.S. Provisional Application No. 62/574,063, entitled “DYNAMIC USER AGENT STRINGS”, filed on Oct. 18, 2017, as well as U.S. Provisional Application No. 62/549,806, entitled “AUTOMATED CONTEXTUAL INDEX SUPPRESSION”, filed on Aug. 24, 2017, as well as U.S. Provisional Application No. 62/574,070, entitled “AUTOMATED CONTEXTUAL INDEX SUPPRESSION”, filed Oct. 18, 2017, and all of which are incorporated herein by reference in their entireties.

BACKGROUND

Various systems and interfaces have been created for accessing and navigating content on the Internet. For instance, when a user enters search terms into a web browser, that browser will initially generate a search request. This search request is then sent to one or more search engines (e.g., Google, Bing, Yahoo, etc.). These search engines search the Internet to find webpages/websites that are relevant to the search terms. After finding relevant webpages, the search engines return a set of search results to the browser. Notably, this set of search results includes an indication regarding the webpages that the search engine determined were relevant to the user's search term. The browser then displays the set of search results in a user-friendly manner (e.g., it generates a list of indexed content and displays that list to the user). This list can be used by the user to navigate to those relevant webpages. Many browsers also display a variety of different controls that allow the user to better work with the listed content.
When attempting to find relevant webpages, it is typical for search engines to utilize indexes. These indexes identify correlations between (1) search terms and (2) webpage content. In other words, the indexes create searchable relationships. The indexes are formulated and updated in response to data obtained by web crawlers that identify and examine the countless number of webpages. The search engines utilize complex algorithms to then weight the searchable relationship in relation to the user's current search term. After a search is complete, most search engines compile their search results as a Search Engine Results Page (SERP) which is simply an ordered list. This SERP is then delivered to the browser, and the browser may then format or perform other customizations to the SERP. Then, the browser presents the SERP (i.e. the search results) to the user.
Worthwhile to note, the SERP includes references to the webpages that were identified as being relevant to the user's search terms. Before being presented by the browser, the SERP may be customized to include selectable links for each of those referenced webpages. When such a selectable link is selected, the browser is redirected from its own domain to one or more different domains that are hosting the content corresponding to the selected link. In some situations, the browser may belong to the search engine, so the browser's domain may be the same as the search engine's domain.
Many webpage developers use analytics to monitor how many and how often users access their webpages. In fact, one way that webpages generate revenue is by posting advertisements. For example, webpages that are visited more often receive more revenue because more users are viewing the advertisements. Similarly, most webpage developers desire to proliferate their content to as many viewers as possible. To help with these processes, many developers track/monitor a wide variety of metrics or analytics for their webpages.
In some instances, the analytics for a webpage may be skewed or become inaccurate. For example, if a webpage is cached in a device's memory but never actually viewed by the user, then that webpage's analytics may falsely report that the webpage was viewed when it actually was not. To clarify, because webpage content is being retrieved and cached, there is currently no way to differentiate between content that was actually viewed and content that was cached but not viewed. Indeed, from a server's perspective, the webpage content was requested and delivered. As a result, users that rely on the current analytic information are negatively impacted because they are receiving false information. Accordingly, the current technology fails to consider situations in which false analytics are being generated. Even further, the current technology fails to properly differentiate between content that was actually viewed and content that was merely cached but not viewed.
The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided to illustrate only one exemplary technology area where some embodiments described herein may be practiced.

BRIEF SUMMARY

Disclosed embodiments are directed to systems, hardware storage devices, and methods for differentiating between webpages that have different characteristics.
In some embodiments, a list of webpages is generated in response to a query entered by a user. Once the list is generated, a determined number of webpages that were included within that list are then cached in memory. Notably, at least some of the agent strings are updated to reflect a “cached” status. Subsequently, a first webpage is displayed on a user interface of the computer system. This first webpage is one that was included among those webpages that were initially cached in memory. Just like the other cached webpages, this first webpage also has associated with it a first agent string. When the first webpage is displayed on the user interface, the first agent string is updated to reflect an “in-view” status. Later, a second webpage replaces the first webpage on the user interface. Just like the other cached webpages, this second webpage also has an associated agent string. Notably, when the second webpage is displayed on the user interface, its agent string is updated so that it reflects an “in-view” status. As a result, the embodiments are able to use agent strings to differentiate between webpages that are merely cached in memory from webpages that are actually displayed on a user interface.
This Summary is provided to introduce a selection of concepts in a simplified form, which concepts are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Additional features and advantages will be set forth in the description which follows and, in part, will be obvious from the description, or may be learned by the practice of the teachings herein. Features and advantages of the embodiments may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of the embodiments will become more fully apparent from the following description and appended claims, or may be learned by the practice of the embodiments as set forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered to be limiting in scope, embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 illustrates an abstract view of a computer system.

FIG. 2 illustrates an exemplary user interface for displaying webpages resulting from a search event.

FIG. 3 illustrates another exemplary user interface for displaying webpages resulting from a search event.

FIG. 4 illustrates an exemplary computer system that can use agent strings to differentiate between webpages that have different characteristics.

FIG. 5 illustrates use of an agent string to reflect a status of a webpage.

FIG. 6 illustrates the various different types of content that may be included within a webpage.

FIGS. 7A and 7B illustrate a user action to transition from displaying one webpage to displaying another webpage.

FIG. 8 illustrates the transitional flow between displaying one webpage to displaying another webpage.

FIG. 9 illustrates content that may be displayed during a network connection interruption event.

FIG. 10 illustrates other content that may be displayed during a network connection interruption event.

FIG. 11 illustrates an exemplary method for differentiating between webpages having different characteristics.

FIG. 12 illustrates another exemplary method for differentiating between webpages having different characteristics.

FIG. 13 illustrates an exemplary method related to the transmission of telemetry data.

DETAILED DESCRIPTION

Disclosed embodiments are directed to systems, hardware storage devices, and methods for differentiating between webpages that have different characteristics. In particular, the embodiments utilize an agent string to dynamically distinguish between webpages that are merely cached in memory from webpages that are actually displayed on a user interface. As used herein, the terms “website” and “webpage” are synonymous and may be interchanged.
The embodiments may be implemented to overcome many of the technical difficulties and computational expenses associated with displaying a webpage on a user interface. In particular, the embodiments enable a web browser to generate more accurate analytic information related to the actual viewing of a webpage. Currently, traditional systems fail to distinguish between cached-but-not-viewed webpages and actually-viewed webpages. As a result, the analytics for these cached-but-not-viewed webpages are not accurate because the analytics portray false data. For example, when a webpage is cached in memory, traditional systems record that webpage as having been viewed, even if it actually was not viewed. As a result, developers working with that webpage receive false analytic information. This false information is harmful, or rather unhelpful, for a variety of reasons. By way of example and not limitation, developers often interject user-directed content (e.g., advertisements, notifications, warnings, etc.) into their webpages. This user-directed content is meant to be viewed by the users. Often, webpages are even rewarded based on how often that user-directed content is viewed. For example, highly popular webpages are able to charge more for advertisements that are posted on those webpages. If a webpage receives false hits (i.e. indications of being viewed by a user), then both the developer and the owner of the user-directed content may not have reliable information. Accordingly, the present embodiments actively improve the current technology because they enable interested parties to receive more accurate analytic information.
Furthermore, the disclosed embodiments may also protect a user. For example, a user may accidentally (or intentionally) submit a request for illegal or disreputable content. By differentiating between webpages that were actually viewed and webpages that were merely cached (but not viewed), a record can be maintained to protect the user. Indeed, if no such record were maintained, a user might be wrongfully accused of viewing content that he/she actually did not, simply because it was cached.
The disclosed embodiments also improve the overall performance of a computer system. As discussed above, the current embodiments provide valuable information to a developer by more accurately monitoring the analytics of a webpage. This process is achieved, at least in part, by distinguishing between webpages that have merely been cached from webpages that have actually been viewed. By tracking these distinctions, the operations of the underlying computer system become more efficient because less overall resources will be consumed. To clarify, developers will be able to spend their time maintaining webpages that are actually viewed and therefore profitable. Further, these developers can reassign, or rather free-up, the computing resources that were previously being used on less important (i.e. less viewed) webpages. Stated differently, by obtaining better analytics for webpages, computing resources can be better assigned and better utilized.
Furthermore, the present embodiments help prevent any wasteful or unnecessary processing on the part of the computer because only those webpages that are actually being viewed will have resources assigned to them. Even further, because the use of an agent string is computationally inexpensive, the processes described herein can be performed quickly and without utilizing significant computational resources. Accordingly, the present embodiments actually operate to improve the computer system's overall efficiency and operability.
To achieve these benefits, the disclosed embodiments generate a list of webpages in response to a query entered by a user. Once the list is generated, then a determined number of webpages that were included within that list are cached in memory. Each of these cached webpages has a corresponding agent string. These agent strings may include updatable values or other types of data fields which are used for tracking and recording various types of information. Notably, at least some of the agent strings (for those webpages that were cached in memory) are updated to reflect a “cached” status. Subsequently, a first webpage is displayed on a user interface of the computer system. This first webpage is one that was included among those webpages that were initially cached in memory. Just like the other cached webpages, this first webpage also has associated with it a first agent string. When the first webpage is displayed on the user interface, the first agent string is updated to reflect an “in-view” status. Later, a second webpage replaces the first webpage on the user interface. Just like all of the other cached webpages, this second webpage also has an associated agent string. Notably, when the second webpage is displayed on the user interface, its agent string is updated so that it reflects an “in-view” status. As a result, the embodiments are able to use agent strings to differentiate between webpages that are merely cached in memory from webpages that are actually displayed on a user interface.
Having just described various benefits and high-level attributes of the embodiments, the disclosure will now focus on FIG. 1, which presents an introductory discussion of an exemplary computing system. Following that discussion, various architectures and supporting illustrations will be discussed using FIGS. 2-10. Lastly, various flow diagrams and illustrations will be detailed with respect to the remaining figures (FIGS. 11-13).

Exemplary Computing Systems

As illustrated in FIG. 1, an exemplary computing system 100 includes, in its most basic configuration, at least one hardware processor 102 and memory 104. The memory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system 100 is distributed, the processor 102, memory 104, and/or storage capability may be distributed as well. As used here, the term “executable module,” “executable component,” or even “component” can refer to software objects, routines, or methods that may be executed on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processors that execute on the computing system (e.g., as separate threads).
Embodiments of the present invention may comprise or utilize a special-purpose or general-purpose computer including computer hardware, as discussed in greater detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions are physical storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: physical computer-readable storage media and transmission computer-readable media.
Physical computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage (such as CDs, DVDs, etc.), magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
The computer system 100 also includes one or more communication channels 106 for communication with a network 108. A “network” (e.g., the network 108) is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred, or provided, over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry out desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above are also included within the scope of computer-readable media.
Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission computer-readable media to physical computer-readable storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”) and then eventually transferred to computer system RAM and/or to less volatile computer-readable physical storage media at a computer system. Thus, computer-readable physical storage media can be included in computer system components that also (or even primarily) utilize transmission media.
Computer-executable instructions comprise, for example, instructions and data which cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions. The computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.
As detailed above, computer systems are able to provide a broad variety of different functions. One such function includes a web browser user interface as shown in FIG. 2. Accordingly, attention will now be focused on an exemplary browser user interface that may be used by the embodiments presented herein.

Exemplary Browser User Interface

FIG. 2 illustrates an example of a browser interface 200 on a mobile device. This browser interface 200 includes a search field 210, a set of suggested search terms 220, and a plurality of pivot icons 230. When a user begins to enter a search term into the search field 210, the set of suggested search terms 220 will appear. Each term in the set of suggested search terms 220 is based on the user's search term and is useful in assisting the user in entering his/her desired search terms. Here, the user has entered “cat” in the search field 210. As a result, each term in the set of suggested search terms 220 is related to the three-letter word “cat.”
Each of the different pivot icons 230 corresponds to a filter that can be used to refine the user's search results. In this regard, when one of the pivot icons 230 is selected, a search request is formulated by the browser to cause one or more search engines to search for content associated with that filter/content type (e.g., if a “news” pivot icon was selected, then news articles corresponding to the search term will be displayed). Selection of one or more of the pivot icons 230 will trigger the formulation of a search request for content corresponding to the selected pivot icon (e.g., News).
Once a search is formulated by the browser, it will be sent to a predetermined default search engine. Alternatively, in some embodiments, the search will be sent to multiple different search engines (e.g., Google, Bing, Yahoo, Giphy, YouTube, Amazon, Ebay, etc.). In this regard, it will be appreciated that the term “search engine” corresponds to any computing system or Internet domain that is configured to receive a search request from a browser. When the search request is processed by the search engine, the search engine searches the Internet to identify one or more webpages that are relevant to the user's search request. To complete the search request, the search engine generates a set of search results that includes the one or more relevant webpages. Sometimes, the search results are composed in the form of a SERP (Search Engine Results Page). A SERP may comprise one or more webpages or instructions for rendering those webpages' Uniform Resource Locators (URL). The SERP will typically include selectable hyperlinks to those URLs.
In some embodiments, the SERP will not be displayed to the user. Instead, the SERP is used to derive a new index that is suppressed in memory and that is used as the basis for navigating to the webpages identified in the SERP. To clarify, in some instances, the SERP is not displayed to the user. Instead, the browser may be configured to further customize or refine the SERP in various different ways. By way of example and not limitation, such customizations might include implementation of a page compete process (discussed later) or modifications to make the SERP more visually appealing for the user. In some instances, the derived index excludes one or more references that were identified in the SERP. As a result, the derived index (also referred to herein as a “suppressed index”) may comprise only a subset of the SERP's search results.
FIG. 3 illustrates an example browser interface similar to the browser interface 200 of FIG. 2. In particular, FIG. 3 includes an index link 310, a list of indexes 320, and a displayed webpage 330. The index link 310 is a URL for the displayed webpage 330. The list of indexes 320 are shown as tabs that correspond to some of the remaining search results included within the SERP. Notably, the ordering of the list of indexes 320 is based on the same ordering as the search results used by the browser (e.g., the SERP). The displayed webpage 330 is displayed in response to a search term that was previously entered in a search field (e.g., the search field 210 of FIG. 2) and/or in response to a user selecting a particular search term from the set of suggested search terms 220.
Although the webpage 330 is shown in abstract form, it will be appreciated that the webpage 330 includes a variety of content (e.g., a title, various images, text, etc.).
In this embodiment, the user previously entered or selected the term “cat” as the term to be searched. In response, the webpage 330 is displayed. Notably, the webpage 330 corresponds to the user's search term (i.e. cat). To clarify, once the search term was entered at the browser, the browser then submitted a search to one or more predetermined search engines. These search engines then scoured the Internet in search for webpages that include content relevant to the user's search term (i.e. cat). After conducting the search, the search engines generate search results which, as discussed earlier, may in the form of a SERP. As also discussed, the browser may additionally create a derived index using the SERP and may cause the SERP to be suppressed.
In the situation presented in FIG. 3, the browser also automatically accessed (i.e. selected and displayed) the first webpage in the derived index. In other words, after the SERP was generated, the embodiment immediately caused a webpage corresponding to one of the search results (e.g., perhaps the first search result) to be displayed on the user interface, which display was performed without any user interaction.
In some embodiments, a swiping action will enable the user to access a next or previous webpage identified in the suppressed index. If there is no previous webpage identified in the suppressed index when the swipe action is performed, the browser may display the suppressed list so that the suppressed list effectively acts as the previous webpage. As shown in FIG. 3, a webpage corresponding to index link 2 is available to view next. Further detail on navigating between webpages will be discussed later.
While the above discussion focused on an “overall” suppressed list, other embodiments are configured to make use of a second, or rather a “derivative,” list. For instance, suppose the webpage 330 shown in FIG. 3 includes additional links of its own. By way of example, many webpages include hyperlinks to other webpages. As a result, a user can navigate from one webpage to another simply by clicking a link that is included within an existing webpage. Some of the current embodiments are able to analyze a webpage to extract some or all of the links/hyperlinks that are included within that webpage. Once extracted, then these embodiments are able to generate a “derivative” list of webpages. The webpages in this derivative list were all originally included in the one webpage that forms a part of the suppressed list. Accordingly, each webpage that is shown in the suppressed list, or rather the list of indexes 320, may have a corresponding derivative list.
Once this derivative list is generated, then the user can navigate through the webpages in the derivative list according to the same principles that have been discussed with regard to the user's navigation through the webpages that are included in the list of indexes 320. For instance, by swiping in a particular direction, the user is able to navigate through the webpages included in the derivative list. Here, it will also be appreciated that the user is able to navigate between the webpages in the derivative list and the webpages of the list of indexes 320 without having to perform backtrack actions, as is commonly required in the conventional technology. An example will be helpful. In the conventional technology, when a user drills down through the hyperlinks of a set of webpages (e.g., the user navigates to a first webpage, then selects a hyperlink within that first webpage in order to navigate to a second webpage, and so on in a “drill down” process), then the user will be required to backtrack through his/her sequence of navigations in order to return to the original webpage or to navigate to a next webpage that was originally included as part of the user's original search results.
In contrast to the conventional technology, the current embodiments are configured to enable a user to readily transition between navigating through the webpages of the derivative index, or any other index described herein (e.g., the SERP). For example, suppose a list of indexes is initially created (e.g., the list of indexes 320 of FIG. 3). This list of indexes makes reference to at least four different webpages (as shown in FIG. 3). Now suppose that one of the webpages includes a number of hyperlinks. The disclosed embodiments enable a user to drill down through the hyperlinks in any of the pages and to, thereafter, at any time, swipe or navigate to another linked webpage from the base suppressed index (e.g., the SERP, the derived index or other base index). For instance, by way of example, the embodiments are configured to enable a user to access a webpage that is included in the SERP (e.g., the Index Link 2 shown in FIG. 3). After accessing the webpage, then the embodiments enable the user to selectively/progressively drill down into additional linked websites that are included in that first webpage. At any point throughout the progressive drilling operation, the embodiments are configured such that the user is able to immediately return to the original SERP by clicking a button or performing a swiping gesture. For instance, once the user accesses the first webpage, then the derivative list may be generated. By performing a swipe gesture, the user can then access the links in the derivative list (or any other list). Furthermore, at any point throughout the process, the user is able to immediately return to the list of indexes included in the SERP as shown in the list of indexes 320 of FIG. 3 by clicking a button or performing a swipe gesture.
In one embodiment, using the navigation techniques described herein (e.g., a swiping action), the user is able to navigate from the original webpage that is included in the list of indexes (e.g., list of indexes 320) directly into the first webpage included in the derived list. Once the derivative list is navigated into, the user is able to navigate through each of the remaining webpages of the derivative list. Even further, once the user has completed his/her desired navigations through the derivative list (e.g., either by navigating completely through the list or by navigating through only a part of the list until the user no longer desires to navigate through the derivative list), then the user can immediately return to the original list of indexes (i.e. the SERP which is illustrated by the list of indexes 320) without having to backtrack. This return to the original list of indexes is performed in a variety of ways. For example, in one embodiment, after a user has navigated through all of the webpages in the derivative list, the next webpage in the original list of indexes becomes immediately available, and the user simply has to swipe to navigate to the next webpage. In an alternative situation in which the user did not navigate completely through the webpages of the derivative list, the user simply needs to click on one of the links included in the list of indexes 320 as shown in FIG. 3. By directly clicking on the link in the list of indexes 320, the user is able to navigate out of the derivative list and return to the original list of indexes (e.g., the list of indexes 320). Accordingly, the current embodiments enable a user to navigate through both a list of indexes and a derivative list (and to navigate between those two lists) without requiring the user to perform a backtrack operation.
In some embodiments, the system pre-fetches/caches a predetermined number of webpages referenced in the suppressed index. This pre-fetch/cache action may be performed before and/or after one of the webpages is automatically displayed. Further, this pre-fetch/cache action is performed even before receiving navigation input from the user. Subsequently, when a request is made for the next/previous webpage (e.g., by the user performing a swipe gesture), the browser simply accesses the already-cached webpage from the system's memory.
In some embodiments, only selected portions of the webpages will be automatically pre-fetched/cached. By way of example, some mobile device users have limited data plans. If the user downloads more content than is allowed by his/her plan, then that user is charged an extra fee. Accordingly, some embodiments will actively limit the amount of pre-fetched/cached content in an effort to protect the user from incurring additional expenses related to data expenditure. Some embodiments accomplish this objective by caching only pre-selected or pre-determined types of webpage content. For example, suppose a webpage includes a title, text, links, and a gif. By analyzing the user's search terms, some embodiments are able to determine which portions of the webpage are most relevant to the user's search term. For instance, based on the user's browsing history (e.g., the user historically clicks only on the first link), the embodiments may determine that the gifs for the second webpage need not be pre-fetched/cached. Instead, those gifs are loaded only if the user actually navigates to that webpage. Accordingly, some of the embodiments are able to limit the amount of pre-fetched/cached content in an effort to reduce a mobile device user's data consumption. Further detail on this feature will be presented later.
As discussed above, the search results from each of the search engines includes a SERP. As also discussed above, the browser may additionally create a corresponding suppressed, or rather parsed, index that is used for navigating the content. This suppressed index is used to identify the links that are presented in the navigation control panel. However, rather than providing the SERP from only a single search engine, the current embodiments are also able to combine the search results of multiple search engines. When multiple different search engine results are received, these embodiments create a suppressed index using the SERPs of all of the other search engines. By way of example and not limitation, the embodiments may combine a Google SERP, a YouTube SERP, and a Bing SERP to create a new SERP that is then made available to a user.
As described herein, systems are provided for enabling a user to navigate between a search engine's search results (or even the results obtained from multiple search engines). Indeed, a user can navigate through a plurality (2, 3, 4, or more) webpages that have been automatically cached and that are available for immediate viewing. In this regard, the disclosed embodiments facilitate continuous navigation from a suppressed index without having to display that index. Accordingly, by using the exemplary user interface discussed herein, the embodiments greatly improve the efficiency for navigating Internet content, particularly on mobile devices and particularly when the linked content is hosted by different domains.

Differentiating Between Webpages

Having just described a new type of user interface that can be used to display search results, attention will now be turned to a system that is able to differentiate between webpages that have various different characteristics. This differentiating process is used to not only improve the computer's operations but is also used to provide more accurate analytic information to developers.
For example, FIG. 4 illustrates a browser system 400 capable of performing the functions described herein to differentiate between webpages. Browser system 400 includes all of the functionalities, features, and abilities that were discussed in conjunction with the computer system 100 of FIG. 1.
As shown in FIG. 4, the browser system 400 includes a reporting mechanism 405, a browser 410, a timing mechanism 415, hardware processors 420, input/output (I/O) devices 425, and storage 430. The storage 430 includes different content, including, but not limited to, cached content 435, lists 440 (e.g., a SERP), and agent strings 445. Although the storage 430 is depicted as having only three different data items, the ellipses 450 demonstrates that the storage 430 may include any number of different data items.
FIG. 4 also shows that browser system 400 is connected to a network 455, which may be similar to the network 108 of FIG. 1. By using the network 455, the browser system 400 is able to communicate and interact with a variety of different domain hosts (e.g., domain host 1, domain host 2, domain host 3, etc.). In other words, FIG. 4 illustrates that the browser system 400 is able to connect to the network 455 to access remotely stored information. By connecting to the network 455, the browser system 400 is able to acquire and then manipulate a set of search results in order to improve a user's browsing experience.
The processors 420 may include CPU(s), GPU(s), or a combination of both. The I/O devices 440 may include displays, touch sensitive screens, interfaces, speakers, cameras, microphones, keyboards, or any other kind of input device.
The browser 410 is configured as an application that accepts user input and that displays output corresponding to the user input (e.g., the application may be the user interface 200 of FIG. 2 and/or the user interface in FIG. 3). The browser 410 is also configured to interface with the other system components and remote systems to perform much of the functionality described herein.
The reporting mechanism 405 and the timing mechanism 415 will be discussed in more detail later.
The cached content 435 may be any type of cached data. However, in many embodiments, the cached content 435 at least includes cached data corresponding to one or more webpages. To clarify, after a user search is executed, a set of search results is obtained. This set of search results may be embodied in the form of a list, for example, one of the lists 440 shown in storage 430 of FIG. 4. These lists 440 may include a search engine's SERP or even a derived index (e.g., as discussed above, a browser may subsequently modify a SERP to create the derived index). Accordingly, the storage 430 is able to store, maintain, and differentiate between many different types of lists 440, including many different types of SERPs (e.g., SERPs from many different search engines).
Once the lists 440 are acquired, some embodiments will then select a predetermined number of webpages to automatically cache (e.g., in the storage 430) on the local device. Further, at least one of these automatically cached webpages will be selected for actual display on a user interface of the local device. In order to differentiate between webpages that are merely cached in storage and webpages that have actually been viewed, the present embodiments employ the use of an agent string, such as the agent strings 445 shown in storage 430 of FIG. 4. These agent strings 445 enable the embodiments to monitor a status of the webpage. For instance, the embodiments are at least able to monitor a “cached” status, an “in-view” status, or an “out-of-view” status. The cached status relates to webpages that are cached but not yet viewed. The in-view status relates to webpages that are currently being displayed on the user interface of the computer system. The out-of-view status relates to webpages that were previously viewed on the user interface but that are no longer being viewed on the user interface. Accordingly, by updating and maintaining the agent strings 445 for each webpage, the embodiments are able to provide more accurate analytic data to developers. This analytic data may be included in telemetry data that is then sent for processing and analysis by either a third party or perhaps even a local party.
To illustrate, the telemetry data analyst 460 may be either a third party, who is then communicated with via the network 455, or a local entity. Regardless of where the telemetry data analyst 460 is located, the telemetry data analyst 460 is able to receive telemetry data. This received telemetry data may include a plethora of information, including but not limited to, a webpage's analytic data. Once the telemetry data is received, then the telemetry data analyst 460 is able to process the telemetry data to discern both generalized and specific information. For example, by processing analytic data for a large number of webpages, the telemetry data analyst 460 may identify certain generalized trends. These trends may identify which webpages are viewed very frequently. Further, the trends may identify one or more characteristics that are common between those highly viewed webpages. As a result, a developer may incorporate those characteristics into subsequently developed webpages in an effort to increase the viewing rate of those subsequent webpages.
Relatedly, the trends might identify one or more other characteristics that are common between webpages that are not viewed very frequently. Notably, the telemetry data analyst 460 might establish threshold values for differentiating between webpages that are not viewed very frequently from webpages that are viewed somewhat frequently and from webpages that are considered to be viewed very frequently. Accordingly, the trends might identify common characteristics between webpages that are not viewed very frequently and then may relay those characteristics to a developer. As a result, the developer may avoid using those characteristics during subsequent webpage development.
By analyzing the analytic information, developers are able to design and develop better webpages. Further, in some instances, the telemetry data may also be sent to a search engine or other kind of index provider. By transmitting the telemetry data to these parties, these parties may be able to improve the search features for their corresponding search engines.
Accordingly, the browser system 400 is able to use agent strings 445 to optimize when and how the browser system 400 determines whether a webpage has been viewed or whether that webpage was simply cached in memory.
Attention will now be directed to FIG. 5 which more fully details the use of an agent string in the current embodiments.
FIG. 5 shows that a webpage 500 may have associated therewith a corresponding agent string 505. In some embodiments, this agent string 505 is stored and controlled on the local device while in other instances this agent string 505 is maintained remotely. By way of example and not limitation, some embodiments will maintain a local database of agent strings. The database will record relationships between webpages and agent strings. By querying the database, the embodiments will be able to determine a current status of the webpages. In other embodiments, the agent string 505 is maintained remotely. Regardless of where the agent string 505 is located or how it is managed, each webpage 500 will have a corresponding agent string 505.
As shown in FIG. 5, this agent string 505 includes a plethora of information. For example, the agent string 505 includes a status 510 of the webpage 500. This status 510 is reflected as a “cached” status, an “in-view” status, or an “out-of-view” status. As indicated earlier, the cached status indicates that the webpage 500 is cached but not yet viewed. The in-view status indicates that the webpage 500 is currently being displayed by a user interface. The out-of-view status indicates that the webpage 500 was previously displayed on the user interface but is no longer being displayed. As a result, the agent string 505 may be updated to reflect a current status 510 of the webpage 500. This status 510 is selected from the group comprising the cached status, the in-view status, or the out-of-view status.
FIG. 5 also illustrates that the agent string 505 includes other content. For example, the agent string 505 includes a timestamp 515. This timestamp 515 is useful to indicate transitions between webpage statuses. For example, the timestamp 515 may reflect when the agent string 505 of the webpage 500 was first updated to reflect the cached status. Later, when the webpage 500 is actually viewed on the user interface, the timestamp 515 may reflect the new status of the agent string 505, namely the in-view status. After the user navigates away from the webpage 500, then the timestamp 515 may reflect the out-of-view status. Accordingly, the timestamp 515 is usable to identify various events (e.g., cached, viewed, and navigated away events) that are related to the webpage 500. As indicated earlier, the browsing system 400 of FIG. 4 includes a timing mechanism 415. This timing mechanism 415 is able to generate the timestamp 515 of FIG. 5.
It should be noted that the timestamp 515, in some instances, is not a single field that is repeatedly updated. Rather, the timestamp 515 may be comprised of a plurality of values. To illustrate, new time data may be continually appended to the timestamp 515. As a result, the timestamp 515 forms a timing record related to the webpage 500, which record indicates all of the times for events that are associated with the webpage 500 (e.g., when the webpage 500 was cached, when it was viewed, and when it was navigated away from). Accordingly, the timestamp 515 may not be limited to just a single value that is updated and replaced. Instead, the timestamp 515, in some instances, may represent the webpage 500's entire event history.
Similarly, the timestamp 515 may include a name of the event with the timing data. By way of example and not limitation, the timestamp 515 may include the following information for the webpage 500: 9-9-2017 @ 11:32:21 “cached”; 9-9-2017 @ 11:32:51 “in-view”; 9-9-2017 @ 11:33:01 “out-of-view.” As indicated, the timestamp 515 maintains the timing data for the webpage 500. Accordingly, the timestamp 515 maintains a log of the webpage 500's event data. While the example presented above illustrated a specific format and a specific event history, it will be appreciated that the embodiments are able to use any format when updating the timestamp 515. Accordingly, the example presented above is simply one manner of updating the timestamp 515.
Although the agent string 505 is depicted as including a status 510 (e.g., the cached status, the in-view status, or the out-of-view status) and a timestamp 515, the ellipses 520 indicates that the agent string 505 is able to monitor additional information and is not limited simply to that which is presented in FIG. 5. By way of example, other types of information that may be included within the agent string 505 includes (1) metadata associated with the webpage 500 (e.g., the webpage's title, the date when the webpage was last updated or created, information about the hosting entity, the webpage developer's information, etc.), (2) various key search terms for the webpage 500 (e.g., terms used by search engines and/or web crawlers to index the webpage 500), (3) one or more rankings for the webpage 500 (e.g., a ranking placement within the SERP where the webpage 500 was initially ranked, or a ranking placement within a subsequently derived list where the webpage 500 is currently ranked), or (4) information regarding how/when a web crawler last examined the webpage. Accordingly, the agent string 505 may be used to not only monitor a status of the webpage 500 but may also be used to record a plethora of other data for the webpage 500.
Furthermore, the agent string 505 may be used to relay different levels of information granularity. For instance, one level of granularity may include a detailed description of all of the information that is included within the agent string 505 while a different level of granularity may include just a synopsis or brief summary of the information. Worthwhile to note, a user may submit a query to view the information that is being monitored by the agent string 505. This query may dictate a specific level of granularity that the user desires to receive. Examples of some of the different levels of granularity include, but are not limited to, varying the amount of detail regarding (1) when the webpage was viewed and when the webpage was not being viewed, (2) specific time events associated with the webpage, (3) specific values included within the agent string 505, (4) how long a webpage was viewed, etc.
Attention will now be directed to FIG. 6. As indicated earlier, the embodiments pre-fetch and cache a predetermined number of webpages referenced in the derived index before and/or after the webpage that is currently being displayed. This pre-fetch action occurs even before any navigation input is received from the user or at the browser. In some embodiments, however, only selected portions of the webpages will be automatically pre-fetched and cached. To clarify, some mobile device users have limited data plans. If the user downloads/caches more content than is allowed by his/her plan, then that user is charged an extra fee. Accordingly, some embodiments will actively limit the amount of pre-fetched/cached content in an effort to protect the user from incurring additional expenses related to data expenditure. Some embodiments accomplish this objective by caching only pre-selected or pre-determined types of webpage content.
For example, FIG. 6 illustrates a webpage 600 that includes various different types of content (e.g., content type 1, content type 3, content type 3, content type 4, etc.). Although the webpage 600 is illustrated as including only four different types of content, the ellipses 610 demonstrates that the webpage 600 may include additional (or fewer) types of content. Accordingly, the embodiments are able to interact with webpages that include any number of different types of content. This webpage content may include, but is not limited to, a webpage title, text, links, gifs, videos, selectable control buttons, or any other type of webpage content that is traditionally known in the art. Accordingly, as shown in FIG. 6, the webpage 600 may include content type 1, content type 2, content type 3, content type 4, etc.
By analyzing the user's search terms, some embodiments are able to determine which portions of the webpage 600 are most relevant to the user's search term (i.e. which content type is most relevant based on the search term). Even further, the embodiments are able to determine an estimated likelihood of being displayed for each of those content types. To clarify, some research into search behavior on the Internet has shown that the top three results of any given SERP gets a combined click-through rate of just over 60%. Accordingly, the majority of viewed links are the first three listed links. As a result, the embodiments are able to analyze the user's search term as well as the content's likelihood of actually being viewed in order to determine how much and which content to pre-fetch and cache in memory. In some instances, the embodiments may also analyze the user's browsing history when determining the likelihood of being viewed. For instance, based on the user's browsing history (e.g., a trend might be identified in which the user historically clicks only on the first link, or the first two links, or the first three links, etc.), the embodiments might determine that content type 2, which may be a data intensive gif image, might not need to be pre-fetched and cached. Instead, content type 2 can be loaded only if the user actually navigates to the webpage 600. Accordingly, some of the embodiments discussed herein are able to limit the amount of pre-fetched content in an effort to reduce a mobile device user's data consumption.
Attention will now be directed to FIGS. 7A and 7B. In particular, these figures illustrate the transitional flow that occurs when navigating between webpages that are displayed on a user interface. As discussed, the embodiments are able to generate a list of search results based on a search term. This list of search results might be a search engine's original SERP, they might be a browser-modified list of search results (which modified list is based on the search engine's SERP), or the list might be a customized list of search results (e.g., by utilizing a page compete process in which webpages are ranked based on real-time metrics such that webpages that currently (i.e. in real-time) have the fastest load speeds are given priority in the list). Regardless of which list of search results is used, the embodiments then cache a selected number of webpages and cause at least one of the webpages to be automatically displayed on the user interface. In order to transition from one webpage to the user, the user simply performs a user action (e.g., a swipe gesture, closing a current webpage, tapping or otherwise selecting the cached webpage, etc.). This transitional flow between webpages is illustrated in FIGS. 7A and 7B.
In particular, FIG. 7A shows a user interface on which a first webpage 700A is being displayed. In this example, the first webpage 700A illustrates a globe. This first webpage 700A was automatically displayed in response to the user entering a search term (e.g., “World”) into a search field of the user interface (e.g., the search field 210 as shown in FIG. 2). In response to user input (e.g., the swipe gesture 710 shown in FIG. 7), the embodiments cause the user interface to transition from displaying the first webpage 700A to displaying a new webpage. Specifically, FIG. 7B shows that the user interface is now displaying a second webpage 700B in response to the swipe gesture 710. This second webpage 700B includes “News” related content that is focused on the search term previously entered by the user (i.e. the search term “World”). Furthermore, this second webpage 700B corresponds to a link that was included in the search results. This link immediately followed the link that corresponded to the first webpage 700A. Accordingly, the embodiments are able to display webpages on a user interface. To transition from one webpage to another, the user need only perform an action (e.g., a swipe gesture). The transitional flow from one webpage to another is based on an ordering of the links that were included in the search results list. Stated differently, such transitions constitute a flow from one webpage to another webpage.
In some instances, user-directed content (e.g., an advertisement, warning, the original SERP, or any other content that may be important for the user to view) may be interleaved between the display of the webpages. Further, in some instances, the user-directed content may be organized in a format similar to a traditional webpage such that the user is not aware that he/she is viewing user-directed content as opposed to a traditional webpage.
Attention will now be directed to FIG. 8 which more fully illustrates some of the advantages of the current embodiments, particularly with regard to the transition from one webpage to another.
In particular, FIG. 8 illustrates a transitional flow from a first webpage 800A to a second webpage 800B. When a user first commences a swipe gesture (e.g., the swipe gesture starts at swipe progress 805A in FIG. 8) to transition from the first webpage 800A to the second webpage 800B, the user places his/her finger on the touchscreen. As shown by the swipe progress 805B, the user has moved his/her finger in a particular direction (e.g., to the left). When this occurs, portions of the first webpage 800A are removed from display while portions of the second webpage 800B are brought into display. Swipe progress 805C shows that the user has moved his/her finger even further in the particular direction. Similarly, the swipe progress 805D shows an even further progression of the removal of the first webpage 800A and the display of new content for the second webpage 800B. Accordingly, by performing the swipe gesture, the user may transition from viewing a first webpage 800A to viewing a second webpage 800B. These webpages correspond to a search term that was previously entered by the user and also correspond to the resulting search list. Additionally, the first webpage 800A may have been automatically displayed on the user interface while the second webpage 800B may have been cached according to the principles discussed herein.
Some embodiments monitor the progressive replacement of one webpage with another to determine whether a threshold amount of the new webpage has been brought into view. To clarify, the current embodiments are able to distinguish between webpages that have been cached and webpages that have actually been viewed. Some users may attempt to improperly take advantage of the cached content by partially performing a user action (e.g., a swipe gesture) so as to bring a part of the cached webpage into view without the corresponding webpage actually being identified/indicated as being viewed. In other words, some users may attempt to “peak” at the new webpage. Accordingly, to prevent such improper use (i.e. peaking without updating the agent string), some embodiments monitor a progression of the swipe gesture to determine how much content of the new webpage is being displayed on the user interface. Once a threshold amount of the new webpage is displayed, then the agent string for that new webpage is updated to reflect the in-view status, even if the entirety of the webpage is not displayed and even if the user cancels the swipe gesture. As a result, some of the present embodiments prevent users from “peaking” at cached webpages.
In these embodiments, the threshold amount may be any amount. For example, the threshold amount may be 5%, 10%, 15%, 20%, 25%, 30%, 35%, or any other percentage amount of the new webpage that is being brought into view. By way of example, if a predetermined percentage of the new webpage (e.g., 25%) is brought into view, then a triggering action will occur and the agent string for this new webpage will be updated to reflect the in-view status even though a remaining portion (e.g., 75%) of the new webpage has not yet (or may never be) brought into view.
Returning to FIG. 8, the swipe progress 805B reflects a situation in which a particular percentage (e.g., 25%) of the second webpage 800B has been brought into view. Accordingly, in some embodiments, because the threshold amount has been reach, the agent string for the second webpage 800B will be updated to reflect the in-view status.
While the above examples and embodiments were focused on a situation in which the triggering action for updating a webpage's agent was focused on the display of a certain percentage of that webpage, other embodiments use different events to trigger the update event. For instance, instead of a percentage of the new webpage being displayed, some embodiments trigger the update event based on a progression of the swipe gesture itself. Still further, other embodiments trigger the event based on how much (e.g., a percentage) of the user interface is being occupied by the incoming webpage.
Returning to FIG. 8, FIG. 8 can also be used to illustrate the situation in the triggering event is based on how much of the user interface is being occupied by the incoming webpage. To illustrate, during the swipe progress 805B, 25% of the user interface is now being occupied by the incoming second webpage 800B. Accordingly, using the principles discussed above, some embodiments will update the agent string of the second webpage 800B to the “in-view” status.
Attention will now be directed to FIG. 9. FIG. 9 presents a situation that is similar to the situation presented in FIGS. 7A, 7B, and 8 in which a transition between webpages is occurring.
As shown in FIG. 9, a user interface 900 is displaying a webpage 905. Whereas in earlier situations, the mobile devices were connected to a network, in the situation presented in FIG. 9, the mobile device is not connected to a network 910. To clarify, the “x” line between the network 910 and the mobile device illustrates that the mobile device is not connected to the network 910.
In some instances, users may attempt to improperly take advantage of cached content. For instance, some users may desire to view the cached content without the agent strings for that cached content being updated to reflect the viewed status. As a result, these users may initially cause various webpages to be cached in memory, which action will cause the corresponding agent strings to be updated to the “cached” status, and then terminate the connection to the network 910. Because the webpages are cached, some users may determine that the agent strings for those webpages will not be updated because there is no connection to the network 910. However, the present embodiments address this improper use in a variety of ways.
For example, the situation presented in FIG. 9 shows one possible solution to the above-mentioned problem. In this situation, after webpages have been cached in memory and after the connection to the network 910 has been terminated (or ended in some other manner), a user may perform a swipe gesture 915 in an attempt to viewed the cached webpages.
To address the above problem, some embodiments will wipe all of the cached webpage content in response to the swipe gesture 915. As a result, no content will be presented to the user. For example, the user interface 920 presented in FIG. 9 illustrates such an occurrence. Here, all (or at least a portion) of the webpage content that was previously cached in memory has been wiped and no content 925 is presented. In some instances, the no content 925 may display an error message, a network connection failure message, or any other kind of message to alert the user that the cached content is no longer available.
In other instances, instead of actually wiping the data, the user interface 920 may display those error messages but the cached content is retained in memory. As a result, when the user reconnects to the network 910, the embodiments will not be required to re-cache the content a second time. This feature helps reduce the amount of data that is expended. Notably, however, the cached content is inaccessible until a network connection is reestablished. Accordingly, in these embodiments, although the cached content might not be wiped, the user is still not able to access that cached content.
FIG. 10 presents another solution to the problem of a user attempting to circumvent the updating of a webpage's agent string. FIG. 10 shows many of the same illustrations that were presented in FIG. 9, so it is unnecessary to repeat the labeling. However, after a swipe gesture is performed and after the connection to the network is terminated, some embodiments will allow the cached content to be displayed. In particular, FIG. 10 shows that a second webpage 1000 is displayed to the user when faced with such a situation. Notably, however, these embodiments are able to store local data on the mobile device to signify that the second webpage 1000 was actually viewed. Later, when a connection to the network (or a connection to a new network) is established, these embodiments then upload the locally stored information so that the agent strings for each of the webpages that were actually displayed during the interrupted connection may be updated to reflect the fact that they were actually viewed. Accordingly, even when faced with a situation in which the mobile device is not connected to a network, the embodiments are able to properly update webpage agent strings. As illustrated in FIG. 4, the browser system 400 includes a reporting mechanism 405. This reporting mechanism 405 is configured to upload and report the locally stored information. Further, the locally stored information may be included in the storage 430 (e.g., with the agent strings 445).
While the above discussion focused on the use of a network to maintain agent strings, some embodiments are configured to locally monitor and manage a webpage's agent string. Accordingly, in these embodiments, the connection or nonconnection to a network does not impact the monitoring and management of an agent string.
The following discussion now refers to a number of methods and method acts that may be performed. Although the method acts may be discussed in a certain order or illustrated in a flow chart as occurring in a particular order, no particular ordering is required unless specifically stated, or required because an act is dependent on another act being completed prior to the act being performed. The methods are implemented by one or more processors of a computer system (e.g., the computer system 100 of FIG. 1). By way of example, a computer system includes one or more computer-readable hardware storage media that stores computer-executable code. This computer-executable code is executable by the one or more processors to cause the computer system to perform these methods.

Exemplary Methods

FIG. 11 illustrates an exemplary method 1100 for differentiating between webpages that have been cached and webpages that have actually been viewed. In some instances, the computer system that performs this method is a mobile device (e.g., a smart phone, tablet, laptop, etc.). Further, the browser system 400 is configured to perform this method.
In particular, method 1100 includes an act 1110 where, in response to a query entered by a user, a list of webpages is generated. This act may be performed by the browser 410 of the browser system 400 shown in FIG. 4.
In some instances, the list of webpages is based at least partially on a set of search results that was received from a search engine. Notably, this set of search results was generated by the search engine in response to the query.
Method 1100 also includes an act 1120 where a determined number of webpages that were included in the list of webpages are cached in memory. This act may also be performed by the browser 410.
In some instances, the cached webpages are cached automatically after the list of webpages is generated. By “automatically,” it is meant that the webpages are cached without any intervening action on the part of the user and is performed contemporaneously with the generation of the list of webpages. By “contemporaneous,” it is meant that the webpage is displayed almost immediately (e.g., 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1 or 1+ to a few seconds) after the list is generated.
Some embodiments cache only selected portions for each of the cached webpages as opposed to caching an entire portion. Further, some embodiments are configured to include a configuration setting. By adjusting this configuration setting, the number of webpages that will be cached can be set/adjusted. To clarify, either a user or the system itself is able to dynamically adjust the configuration setting, which adjustment will determine the number of webpages that are to be cached.
Act 1130 of method 1100 shows that a first webpage that was included among the cached webpages is then displayed on a user interface of a computer system. This first webpage has an associated first agent string. Further, this agent string is updated to reflect an “in-view” status. This act may be performed by the browser 410.
In some embodiments, this first webpage is displayed automatically (i.e. without any intervening action on the part of the user). Further, the display of this webpage may occur at a time that is essentially contemporaneous with when the first webpage was cached. By “essentially contemporaneous,” it is meant that the webpage is displayed almost immediately (e.g., 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1 or 1+ to a few seconds) after being cached.
Subsequently, method 1100 includes an act 1140 where, in response to the first webpage being replaced by a second webpage, a second agent string, which is associated with the second webpage, is also updated to reflect the in-view status. This act may also be performed by the browser 410.
In some embodiments, after the first webpage is replaced by the second webpage, the first agent string is updated to reflect an “out-of-view” status. Furthermore, the first webpage may be replaced by the second webpage in response to user input. The user input may be any type of user input, including, but not limited to, a swipe gesture, a selection of a control button (e.g., a next webpage button on the user interface), or any other action sufficient to cause the system to transition from displaying one webpage to displaying a different webpage.
As indicated earlier, agent strings (including the first agent string and the second agent string) are configured to reflect a plurality of different statuses related to corresponding webpages. The plurality of different statuses includes, but is not limited to, a “cached” status, an “in-view” status, and/or an “out-of-view” status.
In some embodiments, the second agent string was included among those agent strings whose statuses were updated to reflect the cached status. Notably, this action may occur prior to the second webpage being displayed on the user interface. Accordingly, after the second webpage is displayed on the user interface, the second agent string changes from reflecting the cached status to reflecting the in-view status.
The various agent strings can be stored locally, on the client device used to perform the navigation, on a remote server/device, and/or on any combination of local and remote devices. The agent strings can also be stored as a single data structure that is maintained in its entirety or, alternatively, as a distributed data structure with different portions of the agent strings being maintained and updated on different devices. Accordingly, the act of updating and/or creating an agent string can include updating and storing all or only a portion of the agent strings on local and/or remote computing devices.
Some embodiments update the agent strings by submitting a webpage header request (e.g., a http header request) to a currently displayed webpage. For example, the webpage header request may be submitted to the first webpage which is the currently displayed webpage on the user interface. As a result, this webpage header request may be submitted to the first displayed webpage in the list of webpages. Alternatively, this header request can be a request for other HTML elements such as, for example, a logo, image, pixel, or other content. It is advantageous to submit a request that requires little parsing, processing, or other computationally expensive processing. Further, it is advantageous to request only content that is determined to have a high likelihood of actually being present within a majority of webpages so as to avoid an error.
Earlier, it was shown that the browser system 400 of FIG. 4 includes a timing mechanism 415. This timing mechanism 415 includes functionality for recording times of webpage events. By way of example, when the first webpage was displayed on the user interface, the timing mechanism 415 is able to record a first timestamp to thereby document and record when the first webpage was displayed. In some instances, the resulting timestamp may be included as a part of a webpage's agent string. The timing mechanism 415 may further record a second time corresponding to when the first webpage was replaced by the second webpage. This second time may also be included in the first agent string. As a result, the first agent string is able to include a plurality of timestamps, including the first time and the second time.
Other embodiments are configured to handle telemetry data, which is data that is assembled and transmitted for processing. The first time and the second time discussed above are examples of some data that may be included as a part of the telemetry data. By collecting and transmitting this telemetry data, webpage developers are able to learn which characteristics of a webpage are beneficial for viewing purposes and which characteristics are likely to be considered deleterious. Accordingly, the telemetry data is analyzed to determine webpage metrics for the various webpages.
As discussed earlier, some embodiments monitor a progression of the user action (e.g., a swipe gesture), which action causes the first webpage to be replaced by the second webpage. To clarify, as the swipe gesture progresses, portions of the first webpage are progressively caused to no longer be displayed on the user interface while portions of the second webpage are progressively caused to be displayed on the user interface. Then, these embodiments determine that the progression of the swipe gesture has caused a threshold amount of the second webpage to be displayed on the user interface. In response to the threshold amount being displayed, these embodiments cause the second agent string to be updated to reflect the in-view status even though (1) the progression of the swipe gesture is not completed and (2) the second webpage is not fully displayed on the user interface. In other embodiments, the triggering action that causes the agent string to be updated is related to how much of the user interface is being occupied by the incoming webpage. In other embodiments, the triggering action is related to the swipe gesture itself (i.e. how progressed the gesture is, or rather, how complete the swipe gesture is).
In some instances, the threshold amount is reached when 25% or more of the second webpage is displayed on the user interface as a result of the progression of the swipe gesture.
As discussed earlier, some users may improperly attempt to circumvent the updating of an agent string. Accordingly, various embodiments address this problem. In some embodiments, when a network connection is interrupted, then the embodiments will monitor which webpages are already cached. Then, but prior to the first webpage being replaced by the second webpage, the embodiments will wipe all of the cached content associated with the second webpage (and potentially all of the other cached webpages). As a result, when the first webpage is replaced, no content of the second webpage is displayed on the user interface. Instead, a message may be displayed on the user interface informing the user that content is no longer available. In other embodiments, the content is not wiped from memory. Instead, access to that content is restricted and the user interface is updated in the same manner as discussed when an actual wipe event occurs.
Similarly, other embodiments address the network connection issue in a different manner. These embodiments also monitor which webpages are currently cached. Then, the embodiments store information locally on the computer system. This locally stored information indicates which cached webpages were viewed on the user interface while the network connection was interrupted. After either (1) a new network connection is created or (2) the existing network connection is no longer interrupted, the embodiments update the agent strings for those webpages that were displayed (e.g., the second webpage's agent string and any other webpages' agent strings).
FIG. 12 illustrates another exemplary method 1200 for differentiating between different webpages.
In particular, method 1200 includes an act 1210 where a search query is sent to a search engine. This act may be performed by the browser 410 of the browser system 400 shown in FIG. 4.
Then, method 1200 includes an act 1220 where search results are received from the search engine. The search results are a set of webpages that were identified in response to the search query. In some instances, the search results are formatted as a list of webpages. This act may also be performed by the browser 410.
Act 1230 is then shown. In this act, a first agent string corresponding to a first displayed webpage is updated. Notably, this first displayed webpage was included in the list of webpages. This act may also be performed by the browser 410.
Subsequently, method 1200 includes an act 1240 where, after replacing the first displayed webpage with a second displayed webpage, the first agent string is updated a second time. This act may also be performed by the browser 410.
FIG. 13 shows an additional exemplary method 1300 illustrating the use of agent strings. Here, method 1300 includes act 1310 where, after replacing the first displayed webpage with the second displayed webpage (as discussed in connection with method 1200 of FIG. 12), a second agent string corresponding to the second displayed webpage is updated. Then, method 1300 includes an act 1320 in which telemetry data is sent for analysis. This telemetry data corresponds to the first displayed webpage. These acts may also be performed by the browser 410.
Accordingly, the present embodiments provide significant advantages over the current technology by using agent strings to differentiate between webpages. These embodiments advantageously allow a user to quickly progress through viewing multiple webpages without requiring an intervening loading time for each webpage.
The present invention may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A computer system comprising:

one or more processors; and

one or more computer-readable hardware storage devices having stored thereon computer-executable instructions, the computer executable instructions being executable by the one or more processors to cause the computer system to:

in response to a query entered by a user, generate a list of webpages;

cache a determined number of webpages that were included in the list of webpages, the cached webpages each having associated therewith a corresponding agent string, wherein at least some of the agent strings are updated to reflect a cached status;

display, on a user interface of the computer system, a first webpage that was included among the cached webpages along with links in a navigation control panel to a plurality of other webpages that were included in the list of webpages and that are also included among the cached webpages, the first webpage having associated therewith a first agent string, the first agent string being updated to reflect an in-view status;

receiving user input for navigating from the first webpage to a second webpage included in the cached webpages and that has a link displayed in the navigation control panel;

in response to the user input, navigating to the second webpage, replacing the display of the first webpage in the user interface with a display of the second webpage in the user interface; and

while replacing the display of the first webpage with the display of the second webpage, determining a threshold amount of the second webpage has been displayed;

in response to determining the threshold amount of the second webpage has been displayed, updating a second agent string associated with the second webpage to reflect the in-view status for the second webpage.

2. The computer system of claim 1, wherein the list of webpages is based at least partially on a set of search results received from a search engine, the set of search results being generated by the search engine in response to the query.

3. The computer system of claim 1, wherein the cached webpages are cached automatically after the list of webpages is generated.

4. The computer system of claim 1, wherein the first webpage is displayed automatically on the user interface at a time that is essentially contemporaneous with when the first webpage was cached.

5. The computer system of claim 1, wherein, after the first webpage is replaced by the second webpage, the first agent string is updated to reflect an out-of-view status.

6. The computer system of claim 1, wherein user input causes the first webpage to be replaced by the second webpage, the user input being a swipe gesture received at the user interface.

7. The computer system of claim 1, wherein both the first agent string and the second agent string are configured to reflect a plurality of different statuses, the plurality of different statuses including the cached status, the in-view status, and an out-of-view status.

8. The computer system of claim 1, wherein, prior to the second webpage being displayed on the user interface, the second agent string was included among the at least some of the agent strings that were updated to reflect the cached status, whereby, after the second webpage is displayed on the user interface, the second agent string changes from reflecting the cached status to reflecting the in-view status.

9. The computer system of claim 1, wherein the computer system further includes a timestamp mechanism, and wherein the timestamp mechanism recorded a first time corresponding to when the first webpage was displayed on the user interface, the first time being included in the first agent string.

10. The computer system of claim 9, wherein the timestamp mechanism further recorded a second time corresponding to when the first webpage was replaced by the second webpage, the second time also being included in the first agent string such that the first agent string includes both the first time and the second time.

11. The computer system of claim 10, wherein the first time and the second time are included in telemetry data, the telemetry data being analyzed to determine webpage metrics for the first webpage.

12. The computer system of claim 1, wherein updating the first agent string to reflect the in-view status is performed by submitting a webpage header request to a currently displayed webpage, the first webpage at least initially being the currently displayed webpage such that the webpage header request is submitted to the first webpage.

13. A method for differentiating webpages that are automatically cached in response to a webpage search, the method being implemented by one or more processors of a computer system, the method comprising:

in response to a query entered by a user, generating a list of webpages;

caching a determined number of webpages that were included in the list of webpages, the cached webpages each having associated therewith a corresponding agent string, wherein at least some of the agent strings are updated to reflect a cached status;

displaying, on a user interface of the computer system, a first webpage that was included among the cached webpages along with links in a navigation control panel to a plurality of other webpages that were included in the list of webpages and that are also included among the cached webpages, the first webpage having associated therewith a first agent string, the first agent string being updated to reflect an in-view status;

while replacing the display of the first webpage with the display of the second webpage, determining a threshold amount of the user interface is occupied by the second webpage;

in response to determining the threshold amount of the user interface is occupied by the second webpage, updating a second agent string associated with the second webpage to reflect the in-view status for the second webpage.

14. The method of claim 13, wherein the computer system is a mobile smart device, and wherein caching the determined number of webpages that were included in the list of webpages is performed by caching only selected portions for each of the cached webpages as opposed to caching an entire portion for each of the cached webpages.

15. The method of claim 13, wherein determining the number of webpages that will be cached is based on a configuration setting, whereby the user, by adjusting the configuration setting, sets the number of webpages that will be cached.

16. The method of claim 13, wherein replacing the first webpage with the second webpage is triggered by a user action, the user action being a swipe gesture, and wherein determining when the first webpage is to be replaced by the second webpage is performed by:

monitoring a progression of the swipe gesture, wherein, as the swipe gesture progresses, portions of the first webpage are progressively caused to no longer be displayed on the user interface while portions of the second webpage are progressively caused to be displayed on the user interface;

determining that the progression of the swipe gesture has caused a threshold amount of the second webpage to be displayed on the user interface; and

in response to the threshold amount of the second webpage being displayed on the user interface, causing the second agent string to be updated to reflect the in-view status, the second agent string being updated even though the progression of the swipe gesture is not completed and even though the second webpage is not fully displayed on the user interface.

17. The method of claim 16, wherein the threshold amount is reached when 25% or more of the second webpage is displayed on the user interface as a result of the progression of the swipe gesture.

18. One or more hardware storage devices having stored thereon computer-executable instructions, the computer-executable instructions being executable by one or more processors of a computer system to cause the computer system to:

in response to a query entered by a user, generate a list of webpages;

display, in a first portion on a user interface of the computer system, a first webpage that was included among the cached webpages, the first webpage having associated therewith a first agent string, the first agent string being updated to reflect an in-view status; and

in response to the first webpage being replaced by a second webpage in the first portion on the user interface, which second webpage has associated therewith a second agent string, update the second agent string to also reflect the in-view status.

19. The one or more hardware storage devices of claim 18, wherein, when a network connection of the computer system is interrupted, execution of the computer-executable instructions further causes the computer system to:

monitor which webpages are already cached; and

prior to the first webpage being replaced by the second webpage, wipe all cached content associated with the second webpage such that when the first webpage is replaced, no content of the second webpage is displayed on the user interface.

20. The one or more hardware storage devices of claim 18, wherein, when a network connection of the computer system is interrupted, execution of the computer-executable instructions further causes the computer system to:

monitor which webpages are already cached;

store information locally on the computer system, the locally stored information indicating which cached webpages were caused to be displayed on the user interface while the network connection was interrupted, whereby the locally stored information at least includes an indication that the second webpage was caused to be displayed on the user interface; and

after either (1) a new network connection is created or (2) the network connection is no longer being interrupted, update (1) the second agent string to reflect the in-view status and (2) any other agent strings corresponding to any other webpages that were caused to be displayed on the user interface while the network connection was interrupted.