Patent Grant
8370420
The present invention relates to the field of content precaching in a networked environment; more particularly, the present invention relates to displaying content objects in a web environment.
The World Wide Web (“web”) uses the client-server model to communicate information between clients and servers. Web servers are coupled to the Internet and respond to document requests from web clients. Web clients (e.g., web “browsers”) are programs that allow a user to simply access web documents located on web servers.
An example of a client-server system interconnected through the Internet may include a remote server system interconnected through the Internet to a client system. The client system may include conventional components such as a processor, a memory (e.g., RAM), a bus which coupled the processor and memory, a mass storage device (e.g., a magnetic hard disk or an optical storage disk) coupled to the processor and memory through an I/O controller and a network interface, such as a conventional modem. The server system also may include conventional components such as a processor, memory (e.g., RAM), a bus which coupled the processor and memory, a mass storage device (e.g., a magnetic or optical disk) coupled to the processor and memory through an I/O controller and a network interface, such as a conventional modem.
To define the addresses of resources on the Internet, Uniform Resource Locator (URL) system are used. A URL is a descriptor that specifically defines a type of Internet resource and its location. To access an initial web document, the user enters the URL for a web document into a web browser program. Then, a request is made by a client system, such as a router or other network device, and is sent out over the network to a web server. Thus, the web browser sends a request to the server that has the web document using the URL. The web server responds to the request and sends the desired content back over the network to the requester. For example, the web server responds to the HyperText Transfer Protocol (HTTP) request by sending the requested object to the client. In many cases, the object is a plain text (ASCII) document containing text (in ASCII) that is written in HyperText Markup Language (HTML); however, the object may be a video clip, movie or other bandwidth intensive content.
A problem with the Internet is that it has limited bandwidth resources and different points in the Internet may experience network congestion, resulting in poor performance especially for bandwidth-intensive applications. The Internet backbone is often painfully slow. The bandwidth limitation is mainly due to one or more congested links between the web server and the client. Broadband access can help in solving the first mile problem but does not help if the congestion occurs deeper in the network. The “first-mile” is the first link from the server to the Internet. This can become a bottleneck if the content provider does not provision for sufficient bandwidth on this link or if there is a “flash-flood” of requests to the server.
High-quality on-demand video over the Internet has been promised for a long time now. Lately, the hype has increased due to the emerging deployment of broadband access technologies like digital subscriber line (DSL), cable modems, and fixed wireless. These technologies promise to bring full motion, TV quality video to consumers and businesses. Unfortunately, early adopters of the technology quickly discovered that they still cannot get video in any reasonable quality over the network. Certainly, broadband access improves the viewing experience—some web sites targeted to broadband connected customers provide movies with slightly higher resolution. However, the video remains as jerky and fuzzy as before, synchronization with the audio is poor, and it requires often tens of seconds of buffering before starting. Nobody would seriously consider this to be an alternative to DVD or analog TV.
Providing video over the Internet is difficult because video requires huge amounts of bandwidth, even by today's standards. MPEG4-compressed NTSC-quality video, for example, uses an average data rate of 1.2 Mbits/s, with peak rates as high as 3 Mbits/s. MPEG2/DVD quality video consumes 3.7 Mbits/s on the average, with peaks up to 8 Mbits/s.
Most of today's broadband Internet links, especially those to small to medium-sized businesses (SMBs) typically provide data rates in the 100s of Kbits/s up to 2 Mbits/s. Most residences get asynchronous digital subscriber line (ADSL) technology, which is typically provisioned at approximately 1 Mbits/s for downloads from the Internet, and 128 Kbits/s for uploads. Often access links are shared among multiple users, which further reduces the bandwidth available to an individual.
While these data rates are expected to gradually increase in the long term, another phenomenon causing bandwidth shortage will remain: overprovisioning. Typically, Internet Service Providers (ISPs) overprovision their broadband links for economic reasons by a factor of ten. This means that if all their customers would use the service simultaneously, every one of those customers would get only 1/10th of the bandwidth they signed up for. While this scenario might sound unlikely, it is important to note that bandwidth will degrade during peak hours. The problem is better known from cable modems, where customers share a cable segment, but applies to all broadband access technologies.
The network backbone can also be the bottleneck. Especially backbone peering points are likely to impose low data rates, which slows down end-to-end network speed despite fast last mile technology. Even technology advances such as terabit routers, dense wave division multiplexing (DWDM), and faster transmission equipment will not help significantly if, as expected, Internet traffic continues to keep growing faster than these advances in technology.
One prior art solution to accommodate the slowness of the Internet backbone is to move content closer to individuals desiring the content. To that end, content may be cached on the carrier edge and requests for such content may be serviced from these caches, instead of the web server servicing the requests. Distributing content in this manner can require large numbers of cache memories being deployed at the carrier edge and each cache memory stores content from a number of sites. When a request is made for content from a site that has been stored in one (or more) of the cache memories that is closer (from a network proximity viewpoint) to the requester than the original website, the request is satisfied from the cache. In such a situation, the interactive experience for text and images is improved significantly only if content from the site has been stored in the cache and the individual making the request is close enough to one of the servers supporting such a cache to satisfy requests with the content stored therein. This is referred to as carrier edge caching. One provider of such a service is Akamai. Also, such an arrangement for caching content requires that the content owner and the entity caching the content enter an agreement with respect to the access for that content so that the content can be stored ahead of time. Some of the providers of a carrier edge caching service use dedicated links (e.g., via satellites) to feed web pages and embedded objects to these servers and circumvent the Internet backbone entirely. Providing carrier edge caching for high-resolution video requires a particularly large number of servers to be deployed, since the number of clients each server can handle simultaneously is very small.
While carrier edge caching takes the load off the backbone and has the potential to significantly improve the end user's experience for text and image-based content, there are two major shortcomings with this approach. First, it requires hardware infrastructure to be deployed on a giant scale. Without servers in all major ISP's point of presence (POPs) and satellite receivers in central offices (COs), caching on the carrier edge does not work effectively. To deploy and maintain this hardware infrastructure is very cost intensive. Second, the last mile access link remains the bottleneck for affordable truly high resolution video for the foreseeable future.
While carrier edge caching has shortcomings, there are other problems associated with providing content over the Internet. For example, when providing content over the Internet, a content provider is limited in only being able to display the content in one way and without any insight into what content is already cached at a particular client. In other words, the content provider is limited in that it does not know what client side caching is occurring. This may limit a content provider's ability to control the number and order in which those content objects are displayed as that is under the control of the browser. This is of significance when the content provider only desires to allow display of content to which an individual has subscribed.
A method and apparatus for displaying locally stored content objects is disclosed. In one embodiment, the method comprises running an agent on a machine and integrating one or more locally stored objects in a page being displayed using information from the agent.
Other features and advantages of the present invention will be apparent from the accompanying drawings and from the detailed description that follows below.
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.
A method and apparatus for integrating the display of locally stored content objects into web pages is described. In one embodiment, the method comprises a browser receiving a page over a network. The page includes a program (e.g., script) and one or more links to objects that are accessible over the network. The method also includes obtaining a list of one or more locally stored objects based on information in the script prior to completely displaying the web page and displaying the web page with at least one link to one of the one or more locally stored objects in place of at least one of the one or more of links in the page.
The content objects may include web pages, video files, audio files, source code, executable code, programs (e.g., games), archives of one Or more of these types of objects, databases, etc. A chapter, for purposes herein, is a set of content objects classified according to content.
In the following description, numerous details are set forth. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.
Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc. Each may be coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
Overview
A method and apparatus for integrating the display of locally stored content objects into web pages is described.
Referring to
Processing logic, such as a web browser, prior to allowing the page to be displayed, obtains a list of one or more locally stored objects from a process running on the same machine as the web browser (e.g., a daemon process, called “agent”) (e.g., script) (processing block 102).
Thereafter, processing logic (e.g., the web browser) displays the page with links to zero, one or more locally stored content objects (processing block 103).
In one embodiment, a web browser running on the client changes the link to a content object after determining that a client has downloaded or is in the process of downloading this content object (or one or more additional objects) or portions thereof, such that these content objects are in the cache of the client. A daemon process or agent also running on the client provides this information to the browser. For example, the agent may provide information to a program (e.g., script) in an HTML document that causes a web page to be displayed in a certain fashion (e.g., only showing content objects already in the client's cache or only those subscribed to). In another example, such information may cause the web browser to embed an object in another page to display a content object to an individual.
In one embodiment, a web browser on the client changes a web page by replacing at least one string in the page based on the information provided by an agent running locally to the client. The string may be a portion of a program (e.g., script). In one embodiment, the web page includes a program that uses the information to indicate how a content object is to be presented or stored at the client and changing the web page comprises modifying the program to change a representation of the content object. The local information upon which a change in the web page is based may be whether an individual is subscribed to one or more other objects and/or whether one or more other objects are stored in a cache of the client.
In a previous approach, middleware sat between the operating system and the browser and as the browser would browse the world wide web, web pages would go through the middleware. When the browser sought the particular page, the middleware would translate the link if a particular object being sought was in a local cache. That is, the middleware would change the web URL to specify a local URL to a file stored locally. This was performed using special strings (macros).
In the present invention, the middleware consists of an agent (daemon) no longer exists and the browser obtains information about objects stored locally, as opposed to their web location, from that agent directly. In such a case, web pages contain special text, such as html text. An example of this text is given below:
This instructs the browser to include a javascript file into a web page. The above language specifies that there is a Javascript file at the location that is to be fetched before the rest of the web page is displayed. The browser, upon seeing the javascript, fetches a file from the location of the URL specified in the script. In one embodiment, an example of a URL may be as follows:
The file jibe_include.js is pulled in from the agent. In one embodiment, the object agent generates the file on the fly from information it has stored locally and sends it to the browser. Thus, a number of objects are stored locally and the agent conveys information about locally stored objects to the browser. In one embodiment, this is done with the following script as a second set of variables:
These variables can include a list of the objects in the cache and can contain the state information that the agent wants to tell the browser. For example, for each cached object in the list of cached objects that are maintained by the object agent, there may be an object name specified (object_name), an amount of the object that is in the cache (fraction_cached), and local access URL (local_URL). In the web page, the locally stored version of the object may be accessed the local_URL. That is, the local_URL indicates where to get the local object from and is, in essence, a direct link to that object. Therefore, there is no need to replace any URLs in the webpage as they are coming. An example of such a case is shown in
An example list of objects is shown in
For purposes of security and authentication, a REFERER field in the HTTP header may be used. The REFERER field specifies the URL of the page that is requesting an embedded object. Such embedded objects could be images, video files, or Javascript, which are part of the page and which are loaded after the page (or more specifically the HTML for the page) is loaded. Upon receiving the request for an embedded object, the agent determines if the domain of the requesting page is authorized to obtain the data requested. For example, if the requesting page has the following URL
The agent checks if jibefilms.com is a valid domain for the provider jibe.tv. Valid domains are specified ahead of time by the provider and may be given to the agent by a network operations center (NOC). If the agent determines the domain of the page including the object to be valid, the agent responds to the request by sending the desired object, for example a content object, or a Javascript database file. If not, the agent responds by not sending the content object or sending only a subset of the Javascript data base or no Javascript data at all. One application of this is when a web page includes the jibe_include.js Javascript file.
The remainder of the web page can access this information either directly or through special functions which are also added to the file by the agent.
For example, for an object that is to be displayed is stored locally, the browser can be controlled through a script in a web page to replace the link to the object to point to the one in local storage. Such may be accomplished using the following:
Note that the script determines if the object is cached and that its status is complete indicating that the entire object is in the cache. If those conditions are met, then the web page is modified to link to the content object in memory. Thus, when the remainder of the webpage is to be displayed, the browser can include links to one or more locally stored objects. In one embodiment, such a link may be the following:
Portions of an exemplary web page are given below. In one embodiment, each such page includes the following line in the ‘head’ section of the page.
<script language=“javascript”
src=“http://localhost:26138/provider_name/jibe_include.js”></script>
This line provides access to javascript functions that allow a user to subscribe to chapters or individual objects. It also provides a user with the database of locally cached/deleted objects, and the list of existing chapter/object subscriptions. In one embodiment, this database only contains information relevant to an individual site. An exemplary format of this database and the functions is provided below.
The field entitled “provider_name” in the URL below is replaced with an assigned provider name, for example:
The following is an exemplary body of a web page that has been modified as described above. Note that the page includes text to indicate the chapters to which an individual has subscribed along with the amount of space in the cache currently occupied by objects.
This is an example of the javascript database file served by the agent. On a computer system that is running the agent, a version of this file contains locally relevant data is usually accessible through the following URL:
First, a check is made to see if the object agent is installed. In one embodiment, this is performed by the browser, which checks the ‘jibe-is-installed’ variable before accessing any other variables defined in this file. For example, the following may be used in the included file (e.g., jibe_include.js) to indicate that agent is installed:
The following statement may also be used to indicate the version number of the installed agent:
The following statement may set for the provider-specific user id:
The following statement may be used to set forth the providers' cache size (summed over all subscribed chapters), in bytes:
The following statement may be used to set forth the number of bytes of the cache that are currently in use:
The ‘jibe_cached_objects’ variable is an associative array containing meta-data for objects that are currently in the user's local disk cache. In one embodiment, this array is indexed by the object name. A check to determine whether an object is in this set is by the following: “if (jibe_cached_objects[object_name]) {”. In one embodiment, for each cached object, the following fields are defined: provider; status; content_length; cached_bytes; local_url; and provider_data. A subset of these may be used or additional field may be added in alternative embodiments.
provider: the name of the provider that published this object. In one embodiment, the object agent checks the HTTP Referrer field of the web page that includes this script against a list of host names for the provider (these should have been registered earlier). Only objects that have been published by that provider are included in jibe_cached_objects. In one embodiment, this comment applies also to other database elements included in this file.
status: one of the three “completed” (e.g., download has completed and the checksum over the object data has been verified), “inprogress” (i.e., download is currently in-progress), or “deleted” (i.e., the object has been deleted by the user).
content-length: the total size of the object, in bytes.
cached-bytes: the number of bytes of the object that are currently in cache. The cached_bytes and content_length fields may be used by the provider to implement a download progress meter.
local_url: the URL at which the cached copy of the file is available locally. This may be either a file:/// or a http://localhost:port/ URL. In one embodiment, if this field is absent (e.g., undefined), a default value of http://localhost:26138/object_name should be used, where object_name is the full name of the object. If the object is a packaged object, the local_url points to the local folder into which the package has been “unzipped”. Individual files within the archive can be accessed by appending the corresponding relative file path to the local_url.
provider_data: an associative array containing provider_specific <name, value> pairs that the provider supplied when the object was published. These values are used by the provider to render the web page. They are obtained from the corresponding <PARAM Name=“xxx” Value=“xxx”/> constructs in the configuration index published by the provider. This field is absent if there is no provider_specific data associated with the object.
An example list of cached objects is given in the following below.
var jibe_cached_objects={
A jibe_subscribed_chapters variable may be used and is an associative array containing names of chapters to which the user is currently subscribed. In one embodiment, the following properties are associated with each subscribed chapter:
provider: the name of the provider that published the chapter.
status: one of three strings: “unknown”, “active”, or “inactive”. When the chapter is first subscribed to, its status is “unknown”. If the NOC verifies that this is a valid published chapter, its status changes to “active”. If the NOC does not find a valid chapter that is currently published, its status is marked as “inactive”. The user may be automatically unsubscribed from a chapter that has been inactive for a long time (e.g., on the order of a month). This field can be used to alert the user to the existence of chapters that are no longer active so s/he may unsubscribe.
cache_size: the current amount of local disk cache space, in bytes, that have been dedicated to the chapter. This is usually equal to the min_cache_size that was specified when the chapter was first subscribed to; it may, however, be larger if the user decides to dedicate more disk space to the chapter. Note that not all of this space may be available if the user's disk is full.
cache_used: the number of bytes of this chapter's cache that are currently in use by cached objects belonging to this chapter.
preferred_server: this is an optional field that contains the preferred server that was specified at the time the chapter was subscribed to. If an object is available from multiple locations, this field allows the provider to specify (on a per-machine/per-chapter basis) which server to use for downloads to that host.
cached_objects: an array containing the objects belonging to this chapter that are currently (partially or completely) in cache. To obtain the full download status of these objects, a look up is made to obtain its name in jibe_cached_objects (see above).
provider_data: an associative array containing provider-specific <name, value> pairs that the provider supplied when the user subscribed to this chapter (see the jibe_url_for_chapter_subscriptions( ) function below for more details). This field is absent if there is no provider-specific data associated with the chapter.
An example of the jibe_subscribed_chapters variable is given below:
var jibe_subscribed_chapters={
The teachings described herein may be utilized in a networked environment that supports content precaching.
Clients 203 or 204 may comprise a PC, a work station, a network appliance device, a web pad, a wireless phone or other communication device, a set-top box, etc. Client appliance 205 may be implemented on a service gateway (e.g., a router, bridge, switch, other network device) in the LAN or as an end point on the LAN. Clients 203 or client appliance 205 may run software and reside in a LAN or other networked environment. In one embodiment, the precache memory is part of client 203. In another embodiment, the precache memory is part of client appliance 205, or on another client machine that is linked to client 203 by way of a LAN or some other networking subsystem.
Client 203 or client appliance 205 may be coupled to the Internet by a modem link, a digital subscriber line (DSL), cable modem, (fixed) wireless connection, fiber, etc. This coupling may be either a direct connection, or indirectly connected through a router, switch, or other similar device.
One or more clients may be peers. A peer is a “nearby” or local host, such as, for example, a host in the same LAN, a host connected to the same ISP, or any other networked device offering reasonable connectivity (e.g., bandwidth, latency). In
Master controller 201 is coupled to Internet 206 or some other networked environment. In one embodiment, master controller 201 is a server host or cluster of server hosts along with storage (e.g., network-attached storage, database engines), and typically resides in a controlled environment at one or a few locations strategically placed in the Internet to allow for reasonable connectivity.
In one embodiment, the precaching described herein involves building a user profile, subscribing for update notifications for new content (e.g., objects) based on information in the user profile, downloading the new content, and intercepting user's requests for a web server to transparently return the content to the user. As described in more detail below, a user profile may be built by tracking user access patterns, receiving profile information from another entity, and/or being configured with a profile (or portion thereof) from a user.
A client may subscribe for an update of new content based on information in the user profile. In one embodiment, periodic checking is performed to obtain an update of new content and includes sending the requests to the controller, which determines if there are any new content objects that correspond to content specified in the profile. A determination of whether new content exists may be performed by querying a master controller, subscribing with the master controller, and/or crawling the networked environment. Each of these will be described in more detail below.
In one embodiment, to facilitate the precaching process, the master controller maintains one or more databases of available objects and the locations of the objects. As new content becomes available, the controller searches the database of client profiles to determine the set of clients that will want a copy of the new content. The controller sends a message to each of the clients in the set to instruct them to download the content. The message contains the location from where an object may be downloaded to the client making the request. When the content has already been downloaded by a peer client, the controller may indicate to the other clients making the request that the peer client has the content and provides an indication to allow the requesting client to download the content from the peer client. Thus, in such a case, there is peer-to-peer precaching.
In an alternative embodiment, the controller checks for new content, in response to a request by a client, by searching one or more database(s) to determine if the content object has been already downloaded by a client in the system.
In one embodiment, the clients run on a platform and maintain profiles. A client may be an end point of a network or one or multiple hops away from the end point of a network (e.g., a local area network). By forwarding its profile to the controller and having the controller indicate when to download new content objects, the client is able to obtain and precache content objects prior to web browser or other end user program requests based on profiles. The content objects are downloaded and stored in a precache memory (or disk) when the network access link is not being used interactively.
When a web browser or other end user program makes a request for a content object, the client intercepts the request and checks to determine if it has the content object stored locally. If it is stored locally, then the client obtains the content and sends the content object to the browser or other end-user program using any inter-process communication (IPC) mechanism; in doing so, the object may simply be transferred to another task, process, or thread running on the same machine as the client, or it may travel over a local network (e.g., LAN) to a different machine that is running the browser or end-user program. If the content object is not available locally, then the client retrieves the object, or a low-quality representation of the object, over the wide area network from any server which hosts the content object.
Thus, each of the clients sends a profile to the master controller (NOC). The master controller gathers information about new objects being published and compares this to the profiles of each client to determine which objects the client's should download. The information of more objects being published may come from content servers. In other words, the master controller indicates to the client(s) when to download specific objects (and when to delete content). The master controller provides this indication in the form of commands. In other words, after downloading, each client has a collection of cached objects residing on disk, which is managed by the master controller.
Discovery of Content
Master controller 201 can discover content that becomes available at content servers 202. One way in which new content can be discovered is through direct reports 210 coming from content servers 202. Such direct reports 210 could be generated periodically, or in response to an event on server 202 (e.g., new content being placed on the server by the server administrator). Direct reports 210 are usually generated by software running on servers 202.
Another way in which master controller 201 can discover the availability of content on content servers 202 is by use of a server appliance 207 that is co-located on the server 202's site, or close to it. Server appliance 207 can locally crawl (220) through the content on server 202 frequently to check for the availability of new content. It can then report new changes, or provide a summary of all content on server 202, by sending messages 230 to master controller 201. In this context, the server 202 need not run any special software that can communicate directly with the master controller.
A third way in which master controller 201 can discover the availability of content on content servers 202 is by directly crawling (240) the content available on content server 202. This crawling operation 240 is similar to the way in which web search engines retrieve files from an Internet web server.
Profiles for one or more clients 304 may also be maintained by a client appliance 305. In this case, it would not be necessary for clients 304 to run special software to collect and report profiles.
Clients 303 report on the profiles they maintain to master controller 301 using messages 310. Similarly, client appliances 305 report on the profiles they maintain to master controller 301 using messages 320. Messages 310 and 320 can be generated periodically, or in response to some event (e.g., a request from master controller 301).
In an alternate embodiment of the invention, clients 503 or client appliance 505 may directly query the master controller 501 for new content objects that match their local profiles, and receive from the master controller 501 a list of the new objects that are available, as well as their locations (e.g., content servers 502, peer clients 503, or peer client appliances 505). These queries may occur periodically or in response to some external event (e.g., a request from the master controller). Clients 503 or client appliances 505 can then select a suitable location to directly download the content from. In this embodiment, master controller 501 need not maintain profiles for all the clients, and messages 310 and 320 would be unnecessary.
In one embodiment, master controller 501 knows four things: 1) the content clients want based on profiles received from clients; 2) the new content that is available; 3) the location of the new content (e.g., servers, carrier edge caches, peers, etc.); and 4) network information such as, for example, network connectivity (e.g., network topology information, bandwidth, delay, and dynamically changing snapshots of network congestion and/or utilization). Using this information, master controller 501 schedules downloads of new content objects to clients 503 and client appliances 505. Such downloads may take the form of commands such as, for example, “get object from server 1” or may take the form of instructions such as, for example, “instruct client 2 to obtain the object from client 1”. The network information and information about which downloads are taking place allow master controller 501 to do provisioning taking into account resource availability.
In one embodiment, master controller 501 is able to coordinate downloads so that prior to a download of content completing to a particular client, another download of that content may start occurring form that particular client. This kind of pipelining of downloads can significantly reduce the delay before a content object is replicated to a potentially very large number of clients and/or client appliances.
Clients 503 download content objects from the locations specified in messages 410 or 510 from the master controller. For example, in one embodiment, client 503 may download bandwidth intensive content such as, for example, movies, video, software, images, sound files, etc. Client 503 stores the content locally in one or more precache memories. The precache memory may be part of a client 503 (or is at least accessible by it over a fast link, for example, over a LAN). The content may be downloaded on the end user's premises. In one embodiment, the downloading occurs without excessive interference with any other interactive network traffic.
A user request may be generated (e.g., from a web browser) to download specific content from the network. Client software running on an end system can observe these requests. Alternately, a client appliance can observe such a request originating from an end system to which it is connected (e.g., through a LAN). Clients or client appliances monitoring these requests can detect when the request is for a content object that is in the local precache memory of the client or client appliance. If such a request occurs, clients or client appliances can satisfy the request by returning the stored (precached) content object from its local precache memory. If the request is for a content object that is not in the precache memory clients or client appliances can forward the request on to their original destination (e.g., content server, carrier-edge cache, etc.). Thus, requests for a specific type of bandwidth intensive content are intercepted. In one embodiment, clients and client appliances are configurable to intercept requests for a certain type of content object.
Thus, with content cached locally, clients and client appliances detect requests for embedded objects, check their precache memory to determine if the embedded objects are stored locally, and return the object from the precache memory if available. If the content is not available, the request is sent out into the network (e.g., Internet) to an appropriate location where the content or an alternate representation of the content may be found.
Presentation of Objects
As discussed above, the techniques described herein allow for presenting information in useful ways to a user. In one embodiment, pages are generated dynamically using a local approach. In the local approach, the web page is dynamically generated based on information at the client. In other words, the resulting page that is rendered is based on local information, not content provider (e.g., server) information. The dynamic generation of the content object allows different versions of the object to be displayed based on the information at the client. For example, the page may only be displayed with objects that are already cached. For another example, the pages may be displayed with a particular logo on an object to indicate the object is in the cache or may have cached objects displayed differently (e.g., more prominently) than non-cached objects.
In the local approach, the content provider supplies the web page. As the web page comes to the client, the browser's request information from an agent running on the client (i.e., the object agent) to determine if objects set forth therein are cached locally and sends information to the browser regarding the cached objects so that the browser can change the web page to reflect information from the profile and the cached object(s). In one embodiment, the web page contains a program, or script. In one embodiment, the program may comprise Javascript or another scripting language.
Subscribing to Chapters
In one embodiment, content providers can make a user subscribe to a chapter by providing a “subscribe” link on any of their web pages. In one embodiment, when a user clicks on a link, the client goes to the site and the site provides an indication of how to add a chapter to his/her profile. When the user clicks on this link to add a chapter to the profile, instead of going to the remote web site, the user is taken to the middleware agent running on the same machine. This agent returns a page asking the user to confirm whether they want to subscribe to the chapter. The page may result in a pop-up dialog, or it could be a normal web dialog. When the user hits the “confirm” button, the chapter is added to the profile.
An Exemplary Protocol
In one embodiment, once registration has been completed, all but one of the remaining operations are controlled from master controller 501 (e.g., in response to a NOC request or message). Thus, master controller 501 sends a, request to which the client replies, with the exception of one situation.
After registration, master controller 501 requests the profile from the client (602). In one embodiment, master controller 501 indicates the size of the profile it is willing to accept or is able to accommodate. Then the client sends the profile to master controller 501 (622). In one embodiment, the profile is a list of content objects (e.g., 50 to 100 URLs) in order of access frequency, with content objects that are accessed more often being at the top of the profile. If the profile is larger than the maximum specified by master controller 501, the profile may be made smaller by the client by removing links that have been accessed less frequently (e.g., that are at the bottom of the list of links).
Similarly, master controller 501 communicates with the web servers (e.g., content providers). A server registers with master controller 501 (603). In response to the registration, master controller 501 requests state information from the server (604). This request may be generated by master controller 501 periodically while the server remains registered. In response to the request, the server sends state information (605). The state information may include a listing of all content objects that are linked through the sites. The list may be limited to only those content objects that are rich media objects or bandwidth intensive objects in terms of downloading. Every time new content is added or removed, the server sends an add message (606) or a remove message (607) to master controller 501 to update the list (e.g., in a database) master controller 501 maintains of the content objects linked through the site.
In one embodiment, master controller 501 initiates one or more maintenance tests on the client (621). These tests are well-known in the art. For example, master controller 501 can request traceroutes from this client to some other Internet address or a bandwidth test from the client to a different Internet address. Master controller 501 uses these tests to determine network connectivity and resource availability: With this information, master controller 501 is able to obtain information about the network topology, a network map, etc., as listed above. Note that such information may be provided to master controller 501 directly without the need of testing to discover it. At this point, master controller 501 has information about network topology, information about server size state, and information about clients.
In one embodiment, master controller 501 may send a reset cache message (609) if a cache checksum doesn't match a previously defined or calculated value.
Master controller 501 keeps track of where the content is. Specifically, master controller 501 keeps track of a particular content piece (e.g., video clips) and the identity of the servers and/or clients on which it is located. Occasionally, master controller 501 determines that a client is to download some object from a location and at this time, master controller 501 sends an initiate download message (610) to the client that identifies an object and the object's location. In one embodiment, the initiate download message includes the name of the object (e.g., universal resource identifier (URI) and its natural location (e.g., a URL corresponding to its location on the server of its origin, a URL corresponding to some peer client, etc.)).
In response to the download message, the client initiates the download by sending a get data command to a peer (611). After the peer begins to send the data (623), the client sends a message to master controller 501 indicating that the download has started (612). The download may take a while. Once the download has been completed, then the client sends a message to master controller 501 indicating that the download has been completed (613). This allows master controller 501 to know which downloads are occurring at any time.
In case the peer is behind a firewall, then the client cannot connect to the peer directly and download the data from behind the firewall. In that case, master controller 501 sends a message (615) directly to the peer to indicate that the peer is to upload the new content to the client. Master controller 501 also sends a message to the client to expect an upload (614) from some peer. A particular session key or number may be used to correlate uploaded information received by the client from other peer clients with the correct download identified by master controller 501. The peer sends the upload (616). Finally, the client sends a heartbeat message (617) to master controller 501 so that master controller 501 knows that the client is up in and running.
In one embodiment, the messages are small. Therefore, because almost all requests come from master controller 501, master controller 501 is able to schedule all the downloads to ensure that no single client or network link is being overloaded.
Building User Profiles
The client creates a profile for an end user that is coupled to the client. The profile may comprise a list of resource locators (e.g., URLs), object type, object size, and a time stamp associated with the URLs to provide information as to when the end user accessed the resource. In one embodiment, the profile comprises URLs and access times, identifying web sites or portions of web sites, and when the user tends to access them.
Profiles may be configured by, or built, using input from a network administrator or manager, such as master controller 501 in the NOC. For example, the master controller 501 could add or remove URLs and access times. To make a change to the profile, the client would be accessible via the network, such as by, for example, an Internet service provider (ISP), application service provider (ASP), or content provider, and the profile could be configured through that access. An example of its use might be where the ISP provides a service by which a video movie is provided once a day to an end user. The individual could choose to watch the movie or not because the movie would have been already downloaded. Profiles may also be configured by a content server or a content provider.
Alternatively, the profile may be manually set by an individual, such as, for example, the user. The user may provide the specific URLs and access times manually to the profile. For example, if a user checks a set of web sites at a predetermined time during the day, the user can configure the network access gateway to access the web sites prior to that time each day to obtain updated or new content. Such additions to the profile augment the accuracy of the precaching.
A profile may be developed for a user using a combination of two or more of these profile building methods. Further priorities can be assigned to URLs stored in the precache memory in case of conflicting access times. In one embodiment, user configured URLs have priority over learned URLs (developed from tracking user access patterns) and network administrator configured URLs (e.g., from master controller 501).
In one embodiment, only one precaching client is running on a system at any one time. An open application program interface (API) to the profile may be provided to allow third parties to add URLs to user profiles, to schedule downloads, and to use the services provided by the precaching architecture for their applications.
Locating New Content
In one embodiment, clients may check for new content by subscribing with master controller 501 in the NOC. Clients 503 can subscribe with master controller 501 to get automatic notification when new content becomes available. This is advantageous on large web sites with millions of clients because it reduces, or even minimizes, time and resources used in crawling.
Using the information stored in the user profiles, master controller 501 periodically checks for new content. To facilitate this, client 503 may have previously passed updates to its profile, such as shown as arrow 310 in
In one embodiment, content providers 502 support the system by periodically crawling locally all available web pages on their servers to look for new object content. This local crawl can be implemented by software, hardware or a combination of both.
The content providers 502 provide a summary of changes to master controller 501. Alternatively, such information may be provided directly to a client. The summary information may comprise the link, time, type and size of each object. The summary may include a list of URLs for those objects. The master controller compares the content in the list with the profile information (e.g., the list maintained by the network access gateway) to determine what content has changed and therefore what content, if any, is to be downloaded. In one embodiment, the result of the local crawl is made available in a special file, namely an update index. Master controller 501 analyzes the update index to find the new download candidates. In one embodiment, content providers 502 manually build an update index.
Master controller 501 collects and aggregates the summaries. In one embodiment, each content provider 502 sends the summary to master controller 501. In such a case, all the clients need only contact one server to download summary information for groups of participating content servers in the network. In one embodiment, master controller 501 may unicast or multicast the information to one or more clients 503.
In an embodiment in which clients maintain their own profile, such as described in U.S. application Ser. No. 09/566,068, entitled “Intelligent Content Precaching,” filed May 5, 2000, assigned to the corporate assignee of the present invention and incorporated herein by reference, clients 503 directly crawl a web site and search for new content objects. Clients 503 perform a crawl operation by periodically checking web servers indicated in the profile for new or updated content objects that it believes end users or other local devices will be accessing in the near future. In one embodiment, in such a case, a client begins with a URL stored in the profile and follows links into web pages down to a configurable level.
In one embodiment, the controller obtains the first page from the server and determines if any bandwidth intensive objects are present. In one embodiment, a bandwidth intensive object may be identified by its size. If bandwidth intensive, embedded objects exist, the controller determines if new versions are available and downloads them. When new content objects have been identified, the controller indicates to the client to download only the bandwidth intensive (e.g., large), new content objects (as they become available). The content objects obtained as a result of crawling are stored locally. In one embodiment, the precache memory storing such objects also stores their URLs, data type, size, the time when the data was acquired and the actual data itself. This process is transparent to the network and no change is needed to the content servers or the network to operate the precaching client.
In an alternative embodiment, each new and/or updated content object is downloaded independent of size (after determining if the content object is a new version).
Some or all of these crawling techniques may be used in the same networked environment. For example, client 503 may crawl one or more sites to determine if any of the content objects have changed, while receiving information from master controller 501 or web servers employing a mechanism to crawl their sites to identify updated or new content and while caches in the network or content servers provide updated and new content to the client 503.
Downloading
Master controller 501 in the NOC maintains a database of available objects and their physical location. When a new object is available for downloading to client 503, master controller 501 determines the most suitable location from which client 503 may download the object. In one embodiment, master controller 501 does this by analyzing the database and the client's Internet protocol (IP) address, and relating this to network topology, map, and connectivity information known to it. A scheduler in the NOC returns a download trigger to client 503. The trigger provides information to enable client 503 to download the object. This trigger information, or pointer, may comprise a location and an object name (e.g., URL).
A requested object can be downloaded from a variety of sources, e.g. a peer, a carrier edge cache, or the original server. In
If no suitable peer is available (e.g., if the request is the first request for an object or if suitable peers are too far away), the object can also be downloaded from a server installed on the carrier edge if the content provider supports carrier edge caching. If there is no suitable peer and no cache can be found, the object is downloaded from the original content provider server 502. Client 503 downloads the object in the background without excessively interfering with interactive traffic, regardless of the location from which it downloads.
Applications
The peer-to-peer precaching technique facilitates provision of premium services, such as explicit downloads, mapped content, aggregated access statistics, etc. The premium service of explicit downloads is done by triggering operations (potentially at regular intervals or at specific times) to pull the customer's content (e.g., all new clips on a web site immediately go to all sites with the web site's URL in their profiles).
Mapped content allows customers to offer dense content dedicated to precache-enabled users. In one embodiment, this is implemented by offering a separate high resolution file of a video clip which is not linked into any web page, but is available to the master controller when it checks a target web site for new content. When the user clicks on a video icon on a web page, the transparent precache technology delivers the high resolution version instead of the potentially low resolution version.
In aggregated access statistics, access statistics and user profile statistics are provided to content providers and distributors. For example, individual user access profiles on the customer premises are retained, with the statistics being reported. By only reporting the aggregated statistics, privacy concerns are avoided.
Besides enhancing traditional web sites with high-quality video, the precaching technique can be applied in other areas, such as advertising, and DVD on demand. Running decent quality video advertising over the Internet has not been possible so far. A broadband connection can barely deliver a single low-quality video stream, and consumers would certainly not want video ads to eat up their interactive bandwidth. Thus, advertisers are currently limited to using “banner ads,” which are mostly implemented as blinking images (animated GIFs). With precaching, advertisements can be downloaded while the link is not used otherwise. Thus, full motion ads can be downloaded in the background, and embedded in web pages, without exhausting the interactive bandwidth. The peer-to-peer video precaching technique helps advertisers to succeed in their hunt for eye balls. In addition, the precaching technique allows the advertisers and content providers to retain their ability to keep track of the number of “hits” of the embedded ads.
The precaching technique also makes online distribution of DVD video feasible. The hassle with late fees, midnight video store runs and rewinding charges would be avoided using an online renting model. MPEG2 video, the coding standard used on DVDs, requires an average bandwidth of 3.7 Mbits/sec. The average length of a DVD movie is two hours. An average movie needs approximately 3.5 Gbytes of disk space. Over a 500 kbits/sec Internet connection, three hours of DVD-quality movie can be downloaded in 24 hours. If the connection is twice as fast (e.g., 1 Mbit/sec), three full DVD movies can be delivered over the Internet in a day.
Thus, a technique of personalized content delivery using peer-to-peer precaching has been described. In particular, this technique saves content providers bandwidth on their server farms and carrier edge caches. It also improves the interactive experience of a large number of web sites. While the previous discussion focuses on clients running on end system PCs, the technique can be implemented to run in access gateways, home gateways, set-top boxes, etc.
An Exemplary Computer System
System 700 further comprises a random access memory (RAM), or other dynamic storage device 704 (referred to as main memory) coupled to bus 711 for storing information and instructions to be executed by processor 712. Main memory 704 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 712.
Computer system 700 also comprises a read only memory (ROM) and/or other static storage device 706 coupled to bus 711 for storing static information and instructions for processor 712, and a data storage device 707, such as a magnetic disk or optical disk and its corresponding disk drive. Data storage device 707 is coupled to bus 711 for storing information and instructions.
Computer system 700 may further be coupled to a display device 721, such as a cathode ray tube (CRT) or liquid crystal display (LCD), coupled to bus 711 for displaying information to a computer user. An alphanumeric input device 722, including alphanumeric and other keys, may also be coupled to bus 711 for communicating information and command selections to processor 712. An additional user input device is cursor control 723, such as a mouse, trackball, trackpad, stylus, or cursor direction keys, coupled to bus 711 for communicating direction information and command selections to processor 712, and for controlling cursor movement on display 721.
Another device that may be coupled to bus 711 is hard copy device 724, which may be used for printing instructions, data, or other information on a medium such as paper, film, or similar types of media. Furthermore, a sound recording and playback device, such as a speaker and/or microphone may optionally be coupled to bus 711 for audio interfacing with computer system 700. Another device that may be coupled to bus 711 is a wired/wireless communication capability 725 to communication to a phone or handheld palm device.
Note that any or all of the components of system 700 and associated hardware may be used in the present invention. However, it can be appreciated that other configurations of the computer system may include some or all of the devices.
Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5220501 | Lawlor et al. | Jun 1993 | A |
| 5307456 | MacKay | Apr 1994 | A |
| 5572643 | Judson | Nov 1996 | A |
| 5666501 | Jones et al. | Sep 1997 | A |
| 5754939 | Herz et al. | May 1998 | A |
| 5761662 | Dasan | Jun 1998 | A |
| 5768528 | Stumm | Jun 1998 | A |
| 5862325 | Reed et al. | Jan 1999 | A |
| 5870559 | Leshem et al. | Feb 1999 | A |
| 5905492 | Straub et al. | May 1999 | A |
| 5913033 | Grout | Jun 1999 | A |
| 5920701 | Miller et al. | Jul 1999 | A |
| 5923736 | Shachar | Jul 1999 | A |
| 5958008 | Pogrebisky et al. | Sep 1999 | A |
| 5974572 | Weinberg et al. | Oct 1999 | A |
| 5987476 | Imai et al. | Nov 1999 | A |
| 5999179 | Kekic et al. | Dec 1999 | A |
| 6011537 | Slotznick | Jan 2000 | A |
| 6022315 | Iliff | Feb 2000 | A |
| 6029175 | Chow et al. | Feb 2000 | A |
| 6038601 | Lambert et al. | Mar 2000 | A |
| 6052730 | Felciano et al. | Apr 2000 | A |
| 6076109 | Kikinis | Jun 2000 | A |
| 6081840 | Zhao | Jun 2000 | A |
| 6088717 | Reed et al. | Jul 2000 | A |
| 6108703 | Leighton et al. | Aug 2000 | A |
| 6125387 | Simonoff et al. | Sep 2000 | A |
| 6138141 | DeSimone et al. | Oct 2000 | A |
| 6144962 | Weinberg et al. | Nov 2000 | A |
| 6145003 | Sanu et al. | Nov 2000 | A |
| 6163779 | Mantha et al. | Dec 2000 | A |
| 6166729 | Acosta et al. | Dec 2000 | A |
| 6181736 | McLaughlin et al. | Jan 2001 | B1 |
| 6182129 | Rowe et al. | Jan 2001 | B1 |
| 6185625 | Tso et al. | Feb 2001 | B1 |
| 6199082 | Ferrel et al. | Mar 2001 | B1 |
| 6206829 | Iliff | Mar 2001 | B1 |
| 6230205 | Garrity et al. | May 2001 | B1 |
| 6237006 | Weinberg et al. | May 2001 | B1 |
| 6263201 | Hashimoto et al. | Jul 2001 | B1 |
| 6272537 | Kekic et al. | Aug 2001 | B1 |
| 6282711 | Halpern et al. | Aug 2001 | B1 |
| 6285985 | Horstmann | Sep 2001 | B1 |
| 6286029 | Delph | Sep 2001 | B1 |
| 6292835 | Huang et al. | Sep 2001 | B1 |
| 6295551 | Roberts et al. | Sep 2001 | B1 |
| 6308273 | Goertzel et al. | Oct 2001 | B1 |
| 6314451 | Landsman et al. | Nov 2001 | B1 |
| 6317761 | Landsman et al. | Nov 2001 | B1 |
| 6340977 | Lui et al. | Jan 2002 | B1 |
| 6341310 | Leshem et al. | Jan 2002 | B1 |
| 6345288 | Reed et al. | Feb 2002 | B1 |
| 6366907 | Fanning et al. | Apr 2002 | B1 |
| 6366933 | Ball et al. | Apr 2002 | B1 |
| 6389462 | Cohen et al. | May 2002 | B1 |
| 6389469 | Vekslar et al. | May 2002 | B1 |
| 6405192 | Brown et al. | Jun 2002 | B1 |
| 6449627 | Baer et al. | Sep 2002 | B1 |
| 6470383 | Leshem et al. | Oct 2002 | B1 |
| 6473794 | Guheen et al. | Oct 2002 | B1 |
| 6482156 | Iliff | Nov 2002 | B2 |
| 6490587 | Easty et al. | Dec 2002 | B2 |
| 6492995 | Atkin et al. | Dec 2002 | B1 |
| 6507854 | Dunsmoir et al. | Jan 2003 | B1 |
| 6519571 | Guheen et al. | Feb 2003 | B1 |
| 6523027 | Underwood | Feb 2003 | B1 |
| 6536037 | Barrese et al. | Mar 2003 | B1 |
| 6549944 | Weinberg et al. | Apr 2003 | B1 |
| 6553129 | Rhoads | Apr 2003 | B1 |
| 6553376 | Lewis et al. | Apr 2003 | B1 |
| 6560639 | Dan et al. | May 2003 | B1 |
| 6567918 | Flynn et al. | May 2003 | B1 |
| 6573907 | Madrane | Jun 2003 | B1 |
| 6578078 | Smith et al. | Jun 2003 | B1 |
| 6587928 | Periyannan et al. | Jul 2003 | B1 |
| 6594692 | Reisman | Jul 2003 | B1 |
| 6606744 | Mikurak | Aug 2003 | B1 |
| 6611840 | Baer et al. | Aug 2003 | B1 |
| 6611862 | Reisman | Aug 2003 | B2 |
| 6615166 | Guheen et al. | Sep 2003 | B1 |
| 6615235 | Copeland et al. | Sep 2003 | B1 |
| 6622168 | Datta | Sep 2003 | B1 |
| 6633742 | Turner et al. | Oct 2003 | B1 |
| 6643657 | Baird et al. | Nov 2003 | B1 |
| 6658000 | Raciborski et al. | Dec 2003 | B1 |
| 6658464 | Reisman | Dec 2003 | B2 |
| 6664978 | Kekic et al. | Dec 2003 | B1 |
| 6671818 | Mikurak | Dec 2003 | B1 |
| 6678864 | Tsai | Jan 2004 | B1 |
| 6687745 | Franco et al. | Feb 2004 | B1 |
| 6697824 | Bowman-Amuah | Feb 2004 | B1 |
| 6714536 | Dowling | Mar 2004 | B1 |
| 6721713 | Guheen et al. | Apr 2004 | B1 |
| 6728000 | Lapstun et al. | Apr 2004 | B1 |
| 6735497 | Wallace et al. | May 2004 | B2 |
| 6735691 | Capps et al. | May 2004 | B1 |
| 6747970 | Lamb et al. | Jun 2004 | B1 |
| 6757710 | Reed | Jun 2004 | B2 |
| 6766944 | Silverbrook et al. | Jul 2004 | B2 |
| 6766945 | Kia et al. | Jul 2004 | B2 |
| 6772214 | McClain et al. | Aug 2004 | B1 |
| 6785784 | Jing et al. | Aug 2004 | B1 |
| 6788315 | Kekic et al. | Sep 2004 | B1 |
| 6789731 | Kia et al. | Sep 2004 | B2 |
| 6792615 | Rowe et al. | Sep 2004 | B1 |
| 6813039 | Silverbrook et al. | Nov 2004 | B1 |
| 6816872 | Squibb | Nov 2004 | B1 |
| 6825945 | Silverbrook et al. | Nov 2004 | B1 |
| 6825956 | Silverbrook et al. | Nov 2004 | B2 |
| 6832717 | Silverbrook et al. | Dec 2004 | B1 |
| 6836806 | Raciborski et al. | Dec 2004 | B1 |
| 6839701 | Baer et al. | Jan 2005 | B1 |
| 6843420 | Paul et al. | Jan 2005 | B2 |
| 6848000 | Reynolds | Jan 2005 | B1 |
| 6849045 | Iliff | Feb 2005 | B2 |
| 6862105 | Silverbrook et al. | Mar 2005 | B2 |
| 6865736 | Holmberg et al. | Mar 2005 | B2 |
| 6880123 | Landsman et al. | Apr 2005 | B1 |
| 6901595 | Mukundan et al. | May 2005 | B2 |
| 6904449 | Quinones | Jun 2005 | B1 |
| 6907451 | Mukundan et al. | Jun 2005 | B1 |
| 6917971 | Klein | Jul 2005 | B1 |
| 6918113 | Patel et al. | Jul 2005 | B2 |
| 6934376 | McLaughlin et al. | Aug 2005 | B1 |
| 6938212 | Nakamura | Aug 2005 | B2 |
| 6947440 | Chatterjee et al. | Sep 2005 | B2 |
| 6957186 | Guheen et al. | Oct 2005 | B1 |
| 6959320 | Shah et al. | Oct 2005 | B2 |
| 6959377 | Gold et al. | Oct 2005 | B2 |
| 6963981 | Bailey et al. | Nov 2005 | B1 |
| 6965912 | Friedman et al. | Nov 2005 | B2 |
| 6972864 | Lapstun et al. | Dec 2005 | B2 |
| 6976090 | Ben-Shaul et al. | Dec 2005 | B2 |
| 6980318 | Silverbrook et al. | Dec 2005 | B1 |
| 6980962 | Arganbright et al. | Dec 2005 | B1 |
| 6983878 | Silverbrook et al. | Jan 2006 | B2 |
| 6986102 | Baer et al. | Jan 2006 | B1 |
| 6987506 | Lapstun et al. | Jan 2006 | B1 |
| 6988126 | Wilcock et al. | Jan 2006 | B2 |
| 6993591 | Klemm | Jan 2006 | B1 |
| 6996274 | Lapstun et al. | Feb 2006 | B2 |
| 6996605 | Low et al. | Feb 2006 | B2 |
| 7000019 | Low et al. | Feb 2006 | B2 |
| 7003731 | Rhoads et al. | Feb 2006 | B1 |
| 7006881 | Hoffberg et al. | Feb 2006 | B1 |
| 7006893 | Hart et al. | Feb 2006 | B2 |
| 7007034 | Hartman, Jr. et al. | Feb 2006 | B1 |
| 7009738 | Silverbrook et al. | Mar 2006 | B2 |
| 7010578 | Lewin et al. | Mar 2006 | B1 |
| 7012710 | Lapstun et al. | Mar 2006 | B2 |
| 7013290 | Ananian et al. | Mar 2006 | B2 |
| 7017823 | Lapstun et al. | Mar 2006 | B2 |
| 7025276 | Lapstun et al. | Apr 2006 | B2 |
| 7028025 | Collins | Apr 2006 | B2 |
| 7031010 | Lapstun et al. | Apr 2006 | B2 |
| 7034691 | Rapaport et al. | Apr 2006 | B1 |
| 7035907 | Decasper et al. | Apr 2006 | B1 |
| 7038797 | Lapstun et al. | May 2006 | B1 |
| 7043488 | Baer et al. | May 2006 | B1 |
| 7043524 | Shah et al. | May 2006 | B2 |
| 7047212 | Pych et al. | May 2006 | B1 |
| 7047485 | Klein et al. | May 2006 | B1 |
| 7047498 | Lui et al. | May 2006 | B2 |
| 7054901 | Shafer | May 2006 | B2 |
| 7055169 | Delpuch et al. | May 2006 | B2 |
| 7055739 | Lapstun et al. | Jun 2006 | B1 |
| 7057608 | Paul et al. | Jun 2006 | B2 |
| 7058720 | Majidimehr | Jun 2006 | B1 |
| 7064681 | Horstemeyer | Jun 2006 | B2 |
| 7068382 | Silverbrook et al. | Jun 2006 | B1 |
| 7070098 | Lapstun et al. | Jul 2006 | B1 |
| 7076494 | Baer et al. | Jul 2006 | B1 |
| 7077333 | Silverbrook et al. | Jul 2006 | B2 |
| 7079712 | Silverbrook et al. | Jul 2006 | B1 |
| 7080780 | Silverbrook et al. | Jul 2006 | B2 |
| 7085755 | Bluhm et al. | Aug 2006 | B2 |
| 7085764 | Bangel et al. | Aug 2006 | B2 |
| 7089239 | Baer et al. | Aug 2006 | B1 |
| 7089487 | Tsai | Aug 2006 | B2 |
| 7096418 | Singhal et al. | Aug 2006 | B1 |
| 7103673 | Kumagai et al. | Sep 2006 | B2 |
| 7107619 | Silverman | Sep 2006 | B2 |
| 7113110 | Horstemeyer | Sep 2006 | B2 |
| 7119716 | Horstemeyer | Oct 2006 | B2 |
| 7123239 | Lapstun et al. | Oct 2006 | B1 |
| 7124101 | Mikurak | Oct 2006 | B1 |
| 7130807 | Mikurak | Oct 2006 | B1 |
| 7134598 | Silverbrook et al. | Nov 2006 | B2 |
| 7134601 | Silverbrook et al. | Nov 2006 | B2 |
| 7146617 | Mukundan et al. | Dec 2006 | B2 |
| 7149698 | Guheen et al. | Dec 2006 | B2 |
| 7150017 | Vogl et al. | Dec 2006 | B1 |
| 7150396 | Silverbrook et al. | Dec 2006 | B2 |
| 7154638 | Lapstun et al. | Dec 2006 | B1 |
| 7155243 | Baldwin et al. | Dec 2006 | B2 |
| 7159014 | Kausik et al. | Jan 2007 | B2 |
| 7162088 | Lapstun et al. | Jan 2007 | B2 |
| 7165041 | Guheen et al. | Jan 2007 | B1 |
| 7167270 | Silverbrook et al. | Jan 2007 | B2 |
| 7173722 | Lapstun et al. | Feb 2007 | B1 |
| 7174056 | Silverbrook et al. | Feb 2007 | B2 |
| 7175079 | Silverbrook et al. | Feb 2007 | B1 |
| 7177949 | Bracewell et al. | Feb 2007 | B2 |
| 7181696 | Brock | Feb 2007 | B2 |
| 7203948 | Mukundan et al. | Apr 2007 | B2 |
| 7222098 | Silverbrook et al. | May 2007 | B2 |
| 7222780 | Lapstun et al. | May 2007 | B2 |
| 7225244 | Reynolds et al. | May 2007 | B2 |
| 7234107 | Aoki et al. | Jun 2007 | B1 |
| 7269664 | Hutsch et al. | Sep 2007 | B2 |
| 7430598 | Raden et al. | Sep 2008 | B2 |
| 7609689 | Desanti et al. | Oct 2009 | B1 |
| 7653744 | Kanefsky et al. | Jan 2010 | B2 |
| 20010044809 | Parasnis et al. | Nov 2001 | A1 |
| 20020023141 | Yen et al. | Feb 2002 | A1 |
| 20020033844 | Levy et al. | Mar 2002 | A1 |
| 20020035619 | Dougherty et al. | Mar 2002 | A1 |
| 20020038388 | Netter | Mar 2002 | A1 |
| 20020055966 | Border et al. | May 2002 | A1 |
| 20020069223 | Goodisman et al. | Jun 2002 | A1 |
| 20020078087 | Stone | Jun 2002 | A1 |
| 20020083093 | Goodisman et al. | Jun 2002 | A1 |
| 20020083183 | Pujare et al. | Jun 2002 | A1 |
| 20020087883 | Wohlgemuth et al. | Jul 2002 | A1 |
| 20020091763 | Shah et al. | Jul 2002 | A1 |
| 20020099738 | Grant | Jul 2002 | A1 |
| 20020124055 | Reisman | Sep 2002 | A1 |
| 20020129164 | Van Der Meulen et al. | Sep 2002 | A1 |
| 20020138619 | Ramaley et al. | Sep 2002 | A1 |
| 20020138841 | Ward | Sep 2002 | A1 |
| 20020147805 | Leshem et al. | Oct 2002 | A1 |
| 20020161908 | Benitez et al. | Oct 2002 | A1 |
| 20030004882 | Holler et al. | Jan 2003 | A1 |
| 20030005116 | Chase et al. | Jan 2003 | A1 |
| 20030009538 | Shah et al. | Jan 2003 | A1 |
| 20030014368 | Leurig et al. | Jan 2003 | A1 |
| 20030014442 | Shiigi et al. | Jan 2003 | A1 |
| 20030046577 | Silverman | Mar 2003 | A1 |
| 20030069803 | Pollitt | Apr 2003 | A1 |
| 20030163478 | Kirkland | Aug 2003 | A1 |
| 20030191812 | Agarwalla et al. | Oct 2003 | A1 |
| 20030206554 | Dillon | Nov 2003 | A1 |
| 20030217126 | Polcha et al. | Nov 2003 | A1 |
| 20040002903 | Stolfo et al. | Jan 2004 | A1 |
| 20040031058 | Reisman | Feb 2004 | A1 |
| 20040073630 | Copeland et al. | Apr 2004 | A1 |
| 20040255048 | Lev Ran et al. | Dec 2004 | A1 |
| 20050220086 | Dowling | Oct 2005 | A1 |
| 20050273514 | Milkey et al. | Dec 2005 | A1 |
| 20060008256 | Khedouri et al. | Jan 2006 | A1 |
| 20060069926 | Ginter et al. | Mar 2006 | A1 |
| 20060075463 | Braddy et al. | Apr 2006 | A1 |
| 20060130124 | Richardson et al. | Jun 2006 | A1 |
| 20060190455 | Braddy et al. | Aug 2006 | A1 |
| 20060256130 | Gonzalez | Nov 2006 | A1 |
| 20070179955 | Croft et al. | Aug 2007 | A1 |
| 20070245409 | Harris et al. | Oct 2007 | A1 |
| 20080212945 | Khedouri et al. | Sep 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| WO-2006074072 | Jul 2006 | WO |
| Entry |
|---|
| Eric M. Schurman et al., Dynamic HTML in Action Web Technology, Second Edition, Microsoft Press, 1999, pp. 5-6,82,85-89. |
| Non Final Office Action. USPTO, U.S. Appl. No. 09/566,068, filed Jul. 30, 2003. pp. 3-15. |
| Final Office Action. USPTO, U.S. Appl. No. 09/566,068, filed May 19, 2004. pp. 2-15. |
| Non Final Office Action. USPTO, U.S. Appl. No. 10/028,398, Jun. 3, 2004. pp. 2-3. |
| Final Office Action. USPTO, U.S. Appl. No. 10/028,398, filed Nov. 26, 2004. pp. 2-4. |
| Non Final Office Action. USPTO, U.S. Appl. No. 10/028,398, filed May 27, 2005. pp. 3-5. |
| Neuman et al., The Kerberos Network Authentication Service (V5), Internet draft, work in progress, Sep. 2004. |
| Non Final Office Action, USPTO, U.S. Appl. No. 09/566,068. Jul. 30, 2003. |
| Non Final Office Action, USPTO, U.S. Appl. No. 09/660,991, Aug. 15, 2003. |
| Final Office Action, USPTO, U.S. Appl. No. 09/660,991, Apr. 2, 2004. |
| Final Office Action, USPTO, U.S. Appl. No. 09/566,068, May 19, 2004. |
| Non Final Office Action, USPTO, U.S. Appl. No. 10/028,398, Jun. 3, 2004. |
| Final Office Action, USPTO, U.S. Appl. No. 10/028,398, Nov. 26, 2004. |
| Non Final Office Action, USPTO, U.S. Appl. No. 09/660,991, Feb. 23, 2005. |
| Non Final Office Action, USPTO, U.S. Appl. No. 10/028,398, May 27, 2005. |
| Final Office Action, USPTO, U.S. Appl. No. 09/660,991, Jan. 5, 2006. |
| Final Office Action, USPTO, U.S. Appl. No. 09/660,991, Oct. 20, 2006. |
| Non Final Office Action. USPTO, U.S. Appl. No. 09/566,068. Jul. 30, 2003. |
| Non Final Office Action. USPTO, U.S. Appl. No. 09/660,991. Aug. 15, 2003. |
| Final Office Action. USPTO, U.S. Appl. No. 09/660,991. Apr. 2, 2004. |
| Final Office Action. USPTO, U.S. Appl. No. 09/566,068. May 19, 2004. |
| Non Final Office Action. USPTO, U.S. Appl. No. 10/028,398. Jun. 3, 2004. |
| Final Office Action. USPTO, U.S. Appl. No. 10/028,398. Nov. 26, 2004. |
| Non Final Office Action. USPTO, U.S. Appl. No. 09/660,991. Feb. 23, 2005. |
| Non Final Office Action. USPTO, U.S. Appl. No. 10/028,398. May 27, 2005. |
| Final Office Action. USPTO, U.S. Appl. No. 09/660,991. Jan. 5, 2006. |
| Final Office Action. USPTO, U.S. Appl. No. 09/660,991. Oct. 20, 2006. |
