Take the 2-minute tour ×
Ask Patents is a question and answer site for people interested in improving and participating in the patent system. It's 100% free, no registration required.

AN OVERBROAD PATENT ON Dynamic preloading of web pages - This Apple application seeks to patent the idea of...Identifying links in a loaded first web page, determining an order of pre-loading second web pages based on links to those web pages, and loading one or more of the second web pages according to the order!

The assignment history here is illustrative because Julien Nguyen apparently assigned the patent in 1996 to his employer at the time, MagicWeb. After a long chain of assignments and reassignments over 15 years... the patent family is purchased by Apple.

Apple is trying to "improve" the claims of the patent through this continuation while retaining the 1996 priority date of Nguyen's original application.

10 minutes of your time can help narrow US patent applications before they become patents. Follow @askpatents on twitter to help.

QUESTION - Have you seen anything that was published before 9/13/1996 (this is a continuation of an old patent by Julien Nguyen) that discusses:

  • Dynamic pre-loading of web pages

If so, please submit evidence of prior art as an answer to this question. We welcome multiple answers from the same individual.

EXTRA CREDIT - Dynamically selecting and preloading web pages from page server to page client using parameters indicated by the page client or the page server.

TITLE: Dynamic preloading of web pages

Summary: [Translated from Legalese into English] Identifying a plurality of links in a loaded first web page, each of the plurality of links pointing to a respective one of a plurality of secondary web pages, determining an order of the plurality of secondary web pages for loading, and loading one or more of the plurality of secondary web pages according to the order.

  • Publication Number: US 20120221930 A1
  • Application Number: US 13/439,226
  • Assignee: Julien Tan Nguyen
  • Prior Art Date: Seeking prior Art predating 9/13/1996
  • Open for Challenge at USPTO: Open through 2/26/2013
  • Link to Google Prior Art Search - "Find Prior Art"

Claim 1 requires each and every step below:

A method implemented by a computing device, the method comprising:

  1. Loading a first web page;

  2. Identifying a plurality of links in the loaded first web page, each of the plurality of links pointing to a respective one of a plurality of secondary web pages;

  3. Determining an order of the plurality of secondary web pages for loading; and

  4. Loading one or more of the plurality of secondary web pages according to the order.

In English this means:

A method implemented by a computing device, the method comprising:

  1. Loading a first web page;

  2. Identifying multiple links in the loaded first web page, each of the multiple links pointing to a respective one of multiple secondary web pages;

  3. Determining an order of the multiple secondary web pages for loading; and

  4. Loading one or more of the multiple secondary web pages according to the determined order.

Good prior art would be evidence of a system that did each and every one of these steps prior to 9/13/1996

You're probably aware of ten pieces of art that meet this criteria already... separately, the applicant is claiming Dynamically saving and recalling behavior information, by the page client, about web pages to be presented, the behavior information being independent of actual links indicated on the web pages. The behavior information is further responsive to parameters selected by the operator parameters adaptively determined by the page client, or responsive to a combination thereof.


"Dynamic preloading of web pages" from the Applicant


What is good prior art? Please see our FAQ.

Want to help? Please vote or comment on submissions below. We welcome you to post your own request for prior art on other questionable US Patent Applications.


share|improve this question

3 Answers 3

Whilst I have not found prior art, the "Alternative Embodiments" seems rather vague though may be common in such patents?

Although embodiments are disclosed herein, many variations are possible which remain within the concept, scope, and spirit of the embodiments described herein, and these variations would become clear to those skilled in the art after perusal of this application.

I assume this will cover other methods of prefetching webpages, of which prior art does exist. For example:

This is from Feb 1995. It describes a process of server-initiated prefetching of web pages based on what users are statistically likely to click on next. However it also notes:

In this paper we have assumed that servers (and not clients) are the ones responsible for initiating speculative services. This need not be the case. In particular, it is possible to adopt a protocol whereby servers attach to each document they serve a list of document URLs that are highly likely to be accessed in the near future, leaving it to the clients to decide which documents to prefetch.

Client caching is referenced in the above, which is discussed in prefetching via client speculation

share|improve this answer

How important is it that this is specifically "web pages" i.e. html loaded in a web browser as opposed to non www? And http versus other protocols? I ask for two reasons. First in 1996 the www had not yet won the day so if you read the academic work from that time www is clearly important and seen as the likely winner but a lot of attention is also give to similar problems in usenet, gopher, and other protocols besides http and of course today just as then lots of mobile was not on the web.

This article is from 1995 http://ftp.isi.edu/touch/pubs/jsac95.pdf

Touch, J.D., "Defining high-speed protocols: five challenges and an example that survives the challenges," Selected Areas in Communications, IEEE Journal on , vol.13, no.5, pp.828,835, Jun 1995 doi: 10.1109/49.391751 Abstract: The First IEEE Gigabit Networking (GBN) Workshop defined a set of characteristics of “Interesting” high-speed applications. The GBN criteria ensure that the application addresses a significant problem, and that it actually requires a gigabit network. This paper presents five challenges that augment the GBN criteria. These challenges ask whether gigabit applications require new research into different protocols, or can be supported by existing protocols that merely run faster. It shows a class of applications, interactive distributed multimedia, namely interactive real-time World Wide Web (WWW) access, that survive the challenges. It also shows how source presenting is a way to use excess bandwidth-delay product to reduce the browser response time, and how this is one example of a truly gigabit protocol keywords: {computer networks;delays;distributed processing;interactive systems;multimedia communication;professional aspects;protocols;societies;First IEEE Gigabit Networking Workshop;bandwidth-delay product;browser response time;gigabit network;gigabit protocol;high-speed applications;high-speed protocols;interactive distributed multimedia;interactive real-time World Wide Web;research;Bandwidth;Broadcasting;Computational modeling;Concurrent computing;Conferences;Distributed computing;Government;Multimedia communication;Protocols;Telemedicine}, URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=391751&isnumber=8876

In the article Touch discusses the need to "keep the pipe full" in order to optimize speed. In particular he discusses the World Wide Web as a gigabyte application and on pages 829-830

2) Even with Large Windows, There Is Not Enough Stuff: Even if the windowing mechanism allows large amounts of pipelining, there may not be enough data with which to fill the pipe. A gigabit WAN has 30-100 Mb in the pipe4-I2 Mbytes. That is more RAM than many systems have, and certainly larger than most messages an application has to transmit. One solution is to use multiplexing to share the channel among user processes 181. This is a parallel of process- swapping in OS-when one process runs out of data to send, another is activated. This works, provided that the process activation is deterministic, i.e., that the other side of the channel knows what the process activation order is [l 11. This is also tantamount to not having a gigabit application protocol+ach application does not use a gigabit channel, so bandwidth needs to be aggregated over a set of multiplexed applications. The case where the application order is not predictable is more interesting, as will be discussed later

So in other words, to have the best performance no "space" should be left unused, this is almost always the case when loading a single page of html, so more data should be sent than just one page worth. However the issue of predictability is key for solutions.

On 830 he continues

B. Challenge #2--Multiplux (Determinisfic) Multiplexing has been proposed as a solution to the “do not have enough stuff to send” issue, as mentioned before [SI. This is equivalent to not having a gigabit application-the gigabits are shared among a set of applications on a workstation. Using multiple hosts, users, or processes are all ways of providing aggregate gigabits only. In the deterministic multiplexer case, this avoids the domain examined here [ 1 11. In the nondeterministic case, the problem has just moved down a level in the protocol stack. In the original case, there was not enough data to send, primarily because data was sent to be sufficient for the current state of the other end of the channel, and not any possible subsequent states. If there were enough for subsequent states, that data would have been sent too, and so on, increasing the amount of data available to send ad infinitum. This is how sliding windows works-by predicting subsequent states, in a linear manner. If the subsequent state is not predictable, neither is the subsequent data [12]. It does not matter whether it is the application state, or the multiplexer state. Nondeterminis- tic multiplexing moves the state prediction problem to the multiplexer-synchronization level, i.e., lower in the protocol stack.

I'm not going to copy all of the rest of the related portions but among other things he discusses the difference between prefetching and preloading and the problem of unpredictability. Although I don't see statistical prediction the article does propose differentiating preloads of "local" hrefs (from the same domain) and "all" hrefs and has a figure where they appear to have collected data on this. I wonder if this may be enough differentiation.

He does mention the issue of predictability being of key importance and I think that using statistical analysis to proxy deterministic predictibility is part of what is described in this patent.

To me the next article is really to the point in that they really implemented a variety of solutions but across many different kinds of systems, with their discussion of what they did for Usenet particularly interesting.

H. Shrikumar, Rehmi Post, Thinternet: life at the end of a tether, Computer Networks and ISDN Systems, Volume 27, Issue 3, December 1994, Pages 375-385, ISSN 0169-7552,

http://dx.doi.org/10.1016/0169-7552(94)90111-2. (http://www.sciencedirect.com/science/article/pii/0169755294901112) Abstract: As the Internet continues its exponential growth, the user profile is changing. Many of the newer Internet hosts are personal workstations, often connected by dial-up or other slow links. We examine some factors that motivate or mandate “thin” (low-bandwidth) connections to the Internet. We notice that the motivation for adopting thin links in the West can be different from those in developing countries. Using a profile of such typical users, we show how techniques exist that allow practical and adequately efficient use of the Internet even “at the end of a tether”.

We are exploring the use of these methods in routine Internet use from a site in India (a software development laboratory, multi-user LAN, connected to an Internet service provider through an expensive dial-up link) and from mobile computers (e.g., HP100LX and Gateway Handbook) in the US. In each case the user's Internet access is through a thin link, with a bandwidth somewhere between 2400 bps and 28.8 kbps.

Local caching and prefetching of resources naturally suggests itself as a useful candidate. It appears that transparent replay of application protocols is a practical way to retrofit resource caching into existing (shrinkwrapped) software. One promising method which works with most services of interest is Postel spoofing.

Given the “browsing” mode of network usage, progressive encoding mechanisms are shown to effectively reduce the access time for particularly large Internet objects, such as Web pages. An ideal progressive encoding of a resource sends a gross quality rendering followed by successive refinements. Since only a fraction of the images retrieved in a session actually have long-term value, such techniques can reduce on-line bandwidth demands by an order of magnitude. Obviously, such encoding methods apply also to large archive and distribution files (such as from FTP archives).

Filtering and relevance feedback have been recognised as effective tools in overcoming information overload. Many sophisticated general techniques are a subject of active research. However, we found that exploiting certain behaviour patterns typical in Internet usage permits particularly efficient filtering using surprisingly simple methods.

We apply this to USENET communication, and extend this to other services (FTP, HTTP, Gopher, mail, etc.), and outline a method of filtering network hypermedia on the basis of relevance contours. Our method recognises the amount of selected information that can be digested by a user in a day, and maximises the value of the packet so selected. It also differs from others by integrating all network hypermedia and selecting and filtering items without regard to the service they were accessed from (USENET, Web, Gopher, FTP, etc.). It does not depend on a-priori categorisation such as news groups and the consequent need for explicit subscription and unsubscription.

On page 222-09 they say

It also appear that cache hit ratios can be improved considerably by pre-fetching objects based on the branching probabilities of threads of browsing. These can either be statically determined or dynamically discovered. Quantitative information concerning patterns of reference and locality in the Web is hard to come by, but this appears to be an av enue worth exploring

There is also a dissertation that mainly focuses on preloading in file systems but says that similar approaches would apply on the WWW and an NSF document that talks about machine learning based on user click patterns to develop a way of predicting likely browsing patterns and using that to optimize.

SOme of the work on Rover may also be relevant http://scholar.google.com/scholar?q=rover+prefetching&btnG=&hl=en&as_sdt=0%2C33&as_yhi=1996

For example page 14 of

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.6672&rep=rep1&type=pdf describes the issue

article exerpt

There are a lot of other examples from around the same time. Hope that gives some help or clues.

share|improve this answer
    
Nice. I really like this excerpt: "Local caching and prefetching of resources naturally suggests itself as a useful candidate" –  Leonardo Herrera Jan 7 at 21:50

This is a bad patent for a number of reasons, first and foremost it a practice that has been happening for many years.

Any AOL cd from the mid 90's used a web browser view to display the connection interface. This was a web page as it was defined s html, and it was embedded because needed a network connection to see it.

If you press the need for network connectivity, I suggest you lookup Opera mini for the traditional idea of a web browser with embedded content of if your definition of a browser is more fluid, Teleca Symphony have a product that has done that since at least 2003.

The way this question is worded, you could define the Lynx start page or the Firefox compiled in landing page as prior art.

share|improve this answer
    
+1 on opera mini, also because it prefetches the web content, compresses it, then sends it to the mobile phone. That was a big deal 6 years ago. –  Chris K Sep 23 at 20:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.