WO2000073922A2 - Content delivery system - Google Patents

Content delivery system Download PDF

Info

Publication number
WO2000073922A2
WO2000073922A2 PCT/US2000/011078 US0011078W WO0073922A2 WO 2000073922 A2 WO2000073922 A2 WO 2000073922A2 US 0011078 W US0011078 W US 0011078W WO 0073922 A2 WO0073922 A2 WO 0073922A2
Authority
WO
WIPO (PCT)
Prior art keywords
content
network
delivery system
routing
icds
Prior art date
Application number
PCT/US2000/011078
Other languages
French (fr)
Other versions
WO2000073922A3 (en
Inventor
John M. Scharber
Original Assignee
Cacheflow, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cacheflow, Inc. filed Critical Cacheflow, Inc.
Priority to AU46617/00A priority Critical patent/AU4661700A/en
Publication of WO2000073922A2 publication Critical patent/WO2000073922A2/en
Publication of WO2000073922A3 publication Critical patent/WO2000073922A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/957Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching

Definitions

  • This invention relates to the transmission and storage of digital information across a network. More particularly, the invention relates to an improved system and method for caching and/or delivering various types of digital content using a plurality of network protocols.
  • the World Wide Web (hereinafter "the Web") is a network paradigm which links documents known as "Web pages" locally or remotely across multiple network nodes (i.e., Web servers).
  • Web pages documents known as "Web pages” locally or remotely across multiple network nodes (i.e., Web servers).
  • a single Web page may have links (a.k.a., "hyperlinks") which point to numerous other Web pages.
  • a cursor control device such as a mouse
  • the user can jump from the initial page to another page, regardless of where the Web pages are actually located.
  • the initial Web page might be stored on a Web server in New York and the second page (accessed via the hyperlink in the first page) might be stored on a Web server in California.
  • ISPs Internet Service Providers
  • FIG. 1 illustrates an ISP 100 with a link 160 to a larger network 150 (e.g., the Internet) through which a plurality of clients 130, 120 can access a plurality of Web servers 140-144 and/or News servers 146-148.
  • a link 160 to the Internet 150 with enough bandwidth to handle the continually increasing traffic requirements of its clients 120, 130 represents a significant cost for ISP.
  • ISP 110 must absorb this cost in order to provide an adequate user experience for its clients 120, 130.
  • proxy server 210 with a Web cache 220, illustrated in Figure 2.
  • client 120 When client 120 initially clicks on a hyperlink and requests a Web page (shown as address "www.isp.com/page.html") stored on Web server 144, client 120 will use proxy server 210 as a "proxy agent.” This means that proxy server 210 will make the request for the Web page on behalf of client 120 as shown. Once the page has been retrieved and forwarded to client 120, proxy server will store a copy of the Web page locally in Web cache 220.
  • proxy server 210 will immediately transfer the Web page from its Web cache 210 to client 130.
  • the speed with which client 130 receives the requested page is substantially increased, and at the same time, no additional bandwidth is consumed across Internet link 160.
  • proxy server configuration alleviates some of the network traffic across Internet link 160, several problems remain.
  • One problem is that prior Web cache configurations do not have sufficient intelligence to deal with certain types of Web pages (or other Web-based information). For example, numerous Web pages and associated content can only be viewed by a client who pays a subscriber fee. As such, only those clients which provide proper authentication should be permitted to download the information.
  • proxy servers such as proxy server 210 will simply not cache a Web document which requires authentication.
  • Web caches do not address the increasing bandwidth problem associated with non-Web based Internet information. In particular, little has been done to alleviate the increasing bandwidth problems created by Usenet news streams. In fact, ISPs today must set aside a substantial amount of bandwidth to provide a continual Usenet news feed to its clients.
  • streaming implies a one-way transmission from a server to a client which provides for uninterrupted sound or video.
  • client When receiving a streaming transmission, the client will buffer a few seconds of audio or video information before it starts sending the information to a pair of speakers and/or a monitor, thus compensating for momentary delays in packet delivery across the network.
  • a content delivery system which will reduce the bandwidth requirements for ISP 110 while still providing clients 120, 130 with an adequate user experience.
  • a system which will work seamlessly with different types of Web-based and non-Web-based information and which can be implemented on currently available hardware and software platforms.
  • an intelligent content delivery system which is capable of caching all types of Web-based information, including information which requires the authentication of a client before it can be accessed.
  • a content delivery system which is easily adaptable so that it can be easily reconfigured to handle the caching of new Internet information and protocols.
  • a data replication system which runs on a distributed database engine, thereby incorporating well known distributed database procedures for maintaining cache coherency.
  • a network content delivery system configured to: select a first content routing technique for processing a first set of network content; and select a second content routing technique for processing a second set of network content, wherein the first and second content routing techniques are selected based on one or more content routing variables.
  • a content delivery system comprising: a network node for storing network content; a first transmission medium communicatively coupled to the network node for transmitting a first set of network content to the network node; and a second transmission medium communicatively coupled to the network node for transmitting a second set of network content to the network node, wherein the first and second sets of network content are selected based on one or more routing variables.
  • FIG. 1 illustrates generally a network over which an ISP and a plurality of servers communicate.
  • FIG. 2 illustrates an ISP implementing a proxy server Web cache.
  • FIG. 3 illustrates one embodiment of the underlying architecture of an Internet content delivery system node.
  • FIG. 4 illustrates a plurality of Internet content delivery system nodes communicating across a network.
  • One embodiment of the present system is a computer comprising a processor and a memory with which software implementing the functionality of the internet content delivery system described herein is executed.
  • a computer system stores and communicates (internally or with other computer systems over a network) code and data using machine readable media, such as magnetic disks, random access memory, read only memory, carrier waves, signals, etc.
  • machine readable media such as magnetic disks, random access memory, read only memory, carrier waves, signals, etc.
  • alternative embodiments can implement one or more of these parts using any combination of software, firmware and/or hardware.
  • ICDS internet content delivery system
  • a single ICDS node 300 is shown including a cache 330, an ICDS application programming interface (hereinafter “API”) 360 which includes a distributed database engine 361, and a plurality of software modules 310-326 which interface with the ICDS API 360.
  • API ICDS application programming interface
  • ICDS node 300 may communicate over a network
  • 340 (e.g., the Internet) over communication link 370 and may also interface with a plurality of clients 350-351 and/or other ICDS nodes (e.g., through link 380).
  • an API such as ICDS API 360 is comprised of a plurality of subroutines which can be invoked by application software (i.e., software written to operate in conjunction with the particular API).
  • application software i.e., software written to operate in conjunction with the particular API.
  • each of the plurality of software modules 310-326 may be uniquely tailored to meet the specific needs of a particular ISP.
  • the modules interface with API 360 by making calls to the API's set of predefined subroutines.
  • Another significant feature of ICDS API 360 is that it is platform-independent. Accordingly, it can be implemented on numerous hardware platforms including those that are Intel-based, Macintosh-based and Sun Microsystems-based.
  • SDK Software Development Kit
  • modules 310-326 may be dynamically linked, they may be loaded and unloaded without having to reboot the hardware platform on which cache 330 is executed.
  • ICDS node 300 includes a plurality of network protocol modules 310- 319 which interface with API 360. These modules provide caching support on ICDS node 300 for numerous different Internet protocols including, but not limited to, Web protocols such as the Hypertext Transfer Protocol (hereinafter "HTTP") 310, Usenet news protocols such as the Network News Transport Protocol (hereinafter “NNRP”) 312, directory access protocols such as the Lightweight Directory Access Protocol (hereinafter “LDAP”) 314, data streaming protocols such as the Real Time Streaming Protocol (hereinafter "RTSP”) 316, and protocols used to perform Wide Area Load Balancing (hereinafter "WALB”) 318.
  • Web protocols such as the Hypertext Transfer Protocol (hereinafter "HTTP") 310
  • HTTP Hypertext Transfer Protocol
  • NRP Network News Transport Protocol
  • LDAP Lightweight Directory Access Protocol
  • RTSP Real Time Streaming Protocol
  • WALB Wide Area Load Balancing
  • One embodiment of the ICDS system includes a plurality of standardized service definitions through which individual service modules 320-326 may be configured to interface with the ICDS API 360.
  • These service modules provide the underlying functionality of ICDS node 300 and may include a data services module 320, an access services module 322, a transaction services module 323, a commercial services module 324, a directory services module 325, and a resource services module 326. The functionality of each of these modules will be described in more detail below.
  • the ICDS API includes a distributed relational database engine 361.
  • a plurality of ICDS nodes 410-440 can be distributed across ISP 400' s internal network and still maintain a coherent, up-to-date storage of Internet content.
  • the underlying distributed database system may be configured to resolve any conflicts between the two modifications using a predefined set of distributed database algorithms.
  • the present system provides built in caching support for dynamically changing Internet content (e.g., Web pages which are modified on a regular basis). Such a result was not attainable with the same level of efficiency in prior art caching systems such as proxy server 210 of Figure 2 (which are executed on, e.g., standard flat file systems such as UNIX or NFS file servers).
  • Data services modules such as module 320 running on each ICDS node 410-440 provide support for data replication and distribution across ISP 400' s internal network 480. This includes caching support for any data protocol included in the set of protocol modules 310-319 shown in Figure 3 as well as for any future protocol which may be added as a module to the ICDS API 360. Because the ICDS API 360 provides a set of standardized service definitions for data services module 320, an ISP using a plurality of ICDS nodes 300 as illustrated in Figure 4 can replicate data across its network without an extensive knowledge of distributed database technology. In other words, the ISP can configure its plurality of nodes by invoking the standardized service definitions associated with data services module 320 and leave the distributed database functionality to the distributed database engine 361.
  • dynamic replication Using dynamic replication, if client 472 requests content from internal ICDS server 460 or from a server across network 490, the content will be delivered to client 472 and replicated in ICDS node 430. If client 473 (or any other client) subsequently requests the same content, it will be transmitted directly from ICDS node 430 rather than from its original source (i.e., a second request to server 460 or a server across network 490 will not be required). Accordingly, bandwidth across ISP 400's internal network and across Internet link
  • the dynamic replication mechanism just described works well for replicating static content but not for replicating dynamically changing content.
  • the replicated content is a magazine article then caching a copy locally works well because it is static information - i.e., there is no chance that the local copy will become stale (out of date).
  • the replicated content is a Web page which contains continually changing information such as a page containing stock market quotes, then dynamic replication may not be appropriate.
  • No built in mechanism is available for proxy cache server 210 to store an up- to-date copy of the information locally.
  • the present ICDS system may use database replication to maintain up-to- date content at each ICDS node 410-440.
  • the present system includes a distributed database engine 361, when a particular piece of content is changed at one node (e.g., ICDS server 460) a store procedure may be defined to update all copies of the information across the network. This may be in the form of a relational database query.
  • the present system may be configured to use dynamic replication for static content but to use database replication for time-sensitive, dynamically changing content.
  • index replication The third type of database replication is known as index replication.
  • index replication Using index replication a master index of content is replicated at one or more ICDS nodes 410-440 across the network 480.
  • ICDS node engine is a distributed database engine.
  • Certain types of information distributions are particularly suitable for using index replication. For example, news overview information (i.e., the list of news articles in a particular newsgroup) is particularly suited to index replication. Instead of replicating each individual article, only the news overview information needs to be replicated at various nodes 410-440 across the network 480. When a client 473 wants to view a particular article, only then will the article be retrieved and cached locally (e.g., on ICDS node 430).
  • ICDS node 430 is capable of caching and delivering various types of Internet data using any of the foregoing replication techniques. While prior art proxy servers such as proxy server 210 may only be used for caching Web pages, ICDS node 430 is capable of caching various other types of internet content (e.g., news content) as a result of the protocol modules
  • ICDS node 430 (in conjunction with nodes 410, 420 and 440) may be configured to cache dynamic as well as static Web-based content using various distributed database algorithms.
  • WALB Wide Area Load Balancing
  • the present system may also perform dynamic protocol selection, dynamic query resolution, and/or heuristic adaptation for replicating content across a network as set forth in the co-pending U.S. Patent Application entitled Dynamic Protocol
  • proxy server cache systems such as proxy server 210 are only capable of caching static, publicly available Web pages.
  • a substantial amount of Web- based and non-Web-based content requires some level of authentication before a user will be permitted to download it.
  • client 472 may pay a service fee to obtain access to content on a particular web site (e.g., from server 460 or from another server over network 490).
  • server 460 may pay a service fee to obtain access to content on a particular web site (e.g., from server 460 or from another server over network 490).
  • server 460 e.g., from server 460 or from another server over network 490.
  • proxy server 210 are not permitted to cache the requested content. This is because proxy server 210 has no way of authenticating subsequent users who may attempt to download the content. Thus, documents which require authentication are simply uncacheable using current network cache systems.
  • the present ICDS system includes user authentication support embedded in access services module 322.
  • client 473 for example, attempts to access a Web page or other information which requires authentication
  • ICDS node will determine whether the requested content is stored locally. If it is, then ICDS node 430 may communicate with the authentication server (e.g., server 460 or any server that is capable of authenticating client 473 's request) to determine whether client 473 should be granted access to the content. This may be accomplished using standardized authentication service definitions embedded in access services module 322. Using these definitions, ICDS node 430 will not only know what authentication server to use, it will also know what authentication protocol to use when it communicates to the authentication server. As a result of providing local access services module 322 for authentication, network information which requires authentication can now be cached locally in ICDS node 430, thereby conserving additional bandwidth across network link 405 and/or ISP network 480.
  • the authentication server e.g., server 460 or any server that is capable of authenticating client 473
  • RADIUS Remote Authentication Dial In User Service
  • ISP Internet Protocol
  • profile services detailing the type of service provided to the user (for example, SLIP, PPP, telnet, rlogin).
  • NASs Network Access Servers
  • the NAS client passes the necessary user information to the central RADIUS server, and then acts on the response which is returned.
  • RADIUS servers receive user connection requests, authenticate users, and then return all configuration information necessary for the client to deliver service to the user.
  • One problem associated with the RADIUS protocol is that it does not provide any built in facilities for replication of RADIUS information. Accordingly, on large ISP's such as
  • America Online which may have tens of millions of users, RADRJS servers are hard hit, potentially handling thousands of logon requests a minute. This may create severe performance/bandwidth problems during high traffic periods.
  • ISP's have taken a brute-force approach to distributing RADIUS information by simply copying the information to additional servers across the network without any built in mechanism to keep the RADIUS data coherent and up-to-date.
  • a RADRJS module is configured to interface with ICDS API 360 in this embodiment (similar to the way in which protocol modules 310-319 interface with the ICDS API 360).
  • RADIUS information can them be seamlessly distributed across the system using distributed database engine 361.
  • the RADRJS module in conjunction with access services module 322 on ICDS node 430 may maintain radius information for local users. [Exactly how will this work?
  • ICDS node 430 may communicate with a second ICDS node (e.g., central ICDS server 460) which contains the necessary RADIUS authentication and user profile information.
  • Client 472 will input a user name and password and will then be permitted access to the network as per his service agreement with ISP 400.
  • ICDS node 430 in the present embodiment may locally cache client 472' s RADRJS information so that the next time client 472 attempts to login to the network, the information will be readily available (i.e., no access to a second ICDS node will be necessary).
  • ICDS node 430 may be configured to save client 472' s RADIUS information locally for a predetermined period of time. For example, the information may be deleted if client 472 has not logged in to local ICDS node 430 for over a month.
  • the present system provides a quick, effective mechanism for dynamically replicating client 472' s user information into those geographical locations from which he most commonly accesses ISP 400. This reduces the load which would otherwise be borne by a central RADRJS server and also improves client 472' s user experience significantly (i.e., by providing him with a quick login).
  • Database replication can also be used to update RADIUS information distributed across multiple ICDS nodes 410-440. This may be done using known store procedures defined in relational database 361. For example, if client 472 cancels his service agreement with ISP 400, he should not be able to continually log in to local ICDS node 430 using the RADRJS information which has been cached locally. Thus, under the present ICDS system, ISP 400 may simply issue a relational database query such as [let's add another update query here using database terminology as an example] to immediately update ICDS node 430' s radius information.
  • Access services module 322 may also provide local encryption/decryption and watermarking of internet content. Audio or video content delivery systems, for example, commonly use encryption of content to protect the rights of the underlying copyright holder. When a user requests a particular piece of content some delivery systems encrypt the content using a unique client encryption key. Only a client who possesses the encryption key (presumably the client who paid for the content) will be permitted to play the content back. Other systems provide for the "watermarking" of content (rather than encrypting) so that the rightful owner of the content may be identified. This simply entails embedding a unique "tag" which identifies the source of the content and/or the owner of the content (i.e., the one who paid for it).
  • access services module 322 of ICDS nodes 410-440 includes a local encryption module and/or a local watermarking module.
  • client 473 requests specific content such as a copyrighted music content stored on a music server (e.g., ICDS server 460)
  • the initial request for the content will be made from ICDS node 430 on behalf of client 473.
  • ICDS node 430 will retrieve the requested content and cache it locally. If the requested content requires encryption, ICDS node 430 will use its local encryption module to encrypt the requested content using a unique user encryption key for client 473.
  • ICDS module 430 will simply encrypt the content using a different encryption key for user 472.
  • frequently requested multimedia content (which, as is known in the art, can occupy a substantial amount of storage space) may be cached locally at ICDS node 430 notwithstanding the fact that the content requires both user authentication and encryption.
  • ICDS node will use a watermarking module (which may comprise a component of access services module 322) to individually watermark multimedia information requested by individual clients, thereby protecting the rights of the copyright holder of the underlying multimedia content. This information can then be regularly communicated back to a central database repository.
  • a watermarking module which may comprise a component of access services module 322
  • multimedia files can be extremely large and, accordingly, take substantially more time to communicate across a network than do, for example, generic Web pages.
  • the ability to locally cache multimedia files significantly reduces traffic across network 480, and also significantly improves the user experience for local users when downloading multimedia information.
  • the present ICDS system In addition to replicating data services and access services information across a network, the present ICDS system also provides for the replication of transaction services.
  • Transaction services includes maintaining information on client payments for use of ISP 400' s services as well as information relating to the client's online access profile (i.e., recording of the times when the user is online).
  • the central server maintains records of when and for how long the client logged in to the network and may also include information about what the client did while he was online.
  • maintaining a central RADIUS server maintaining a central transaction server for all users of a large ISP is inefficient and cumbersome.
  • the present system solves the performance and bandwidth problems associated with such a configuration by storing transaction information locally via transaction module 323 and algorithms build around distributed database engine 361.
  • client 472 only logs on to ISP 400's network 480 via ICDS node 430, all of his transaction and billing information will be stored locally. The information may then be communicated across network 480 to a central billing server at predetermined periods of time (e.g., once a month). [We didn't go into great detail on transaction services and the rest; please add information as you feel appropriate]
  • Commercial services module 324 provides a significantly improved local caching capability for add rotation and accounting.
  • An add rotation system operating in conjunction with a typical proxy cache server will now be described with respect to Figure 2.
  • client 120 downloads a web page from Web server 142 the Web page may contain an ad tag or an add tag may automatically be inserted.
  • the add tag will identify add server 170 and will indicate that an add should be inserted into the requested Web page from add server 170.
  • Add server will then identify a specific add to insert into the downloaded Web page from add content server.
  • the Web page plus the inserted add will then be forwarded to proxy server 210 and on to client 120.
  • Add server 170 will keep an accounting of how many different users have downloaded
  • proxy server 210 requests Web pages on behalf of its clients. Accordingly, once the requested Web pages has been cached locally in Web cache 220, add server will only receive requests from proxy server 210 for any subsequent requests for the Web page. This will result in an inaccurate accounting of how many unique clients actually requested the Web page (and how many adds were viewed by unique users).
  • one embodiment of the present system provides built in caching support for ad rotation services, an accurate accounting of the number of hits that a particular ad receives may be maintained. More specifically, one embodiment of the present ICDS system solves this problem by providing a commercial services module that monitors and records how often individual clients request Web pages containing particular adds from add content server 171. This information than then be communicated to a central server (e.g., ICDS server 460) at predetermined intervals for generating add rotation usage reports.
  • a central server e.g., ICDS server 460
  • Directory services provide the ability to cache locally a directory of information across network 480 or 490. That is, the question here is not whether the particular information is available but where exactly over networks 480 or 490 it is located. It should be noted that there may be some overlap between the directory services concept and the index replication concept described above with respect to data services. [I'm still not 100% sure what this is - please elaborate with an example]
  • content routing refers to the ability to select among various techniques/protocols for maintaining a coherent set of content across a network.
  • the selection of a particular technique may be based on several routing variables including, but not limited to, the type of content involved (i.e., FTP, HTTP . . . etc), the size of the content involved (i.e., small files such as HTTP vs.
  • the location of the content on network 480 and/or network 490 the location of the content on network 480 and/or network 490, the importance of a particular piece of content (i.e., how important it is that the content be kept up-to-date across the entire network), the particular user requesting the content and the terms of his subscription agreement (i.e., some users may be willing to pay more to be insured that they receive only the most up-to-date content without having to wait), the frequency with which the content is accessed (e.g., 5%-
  • Three content routing techniques which may be selected (based on one or more of the foregoing variables) to maintain coherent content across the plurality of nodes illustrated in Figure 4 are content revalidation, content notification, and content synchronization.
  • the original content source When content validation is selected, the original content source will be checked only when the content is requested locally.
  • client 473 may request an installation program for a new Web browser (e.g., the latest version of Microsoft'sTM Internet ExplorerTM).
  • the file may then be transmitted form ICDS server 460 to client 473 and a copy of the file cached locally on ICDS node 430. Consequently, if client 472 requests the same program, for example, two weeks later, ICDS node 430 may be configured to check ICDS server 460 to ensure that it contains the most recent copy of the file before passing it on to client 472 (i.e., ICDS node 430 "revalidates" the copy it has locally).
  • ICDS node 430 may also be configured to revalidate a piece of content only if has been stored locally for a predetermined amount of time (e.g., 1 week). The particular length of time selected may be based on one or more of the variables discussed above. Moreover, in one embodiment, the age/revision of a particular piece of content is determined based on tags (e.g., HTML metatags) inserted in the particular content/file.
  • tags e.g., HTML metatags
  • Revalidation may work more efficiently with certain types of content than with others. For example, revalidation may be an appropriate mechanism for maintaining up-to-date copies of larger files which do not change very frequently (i.e., such as the program installation files described above). However, revalidation may not work as efficiently for caching smaller and/or continually changing files (e.g., small HTML files) because the step of revalidating may be just as time consuming as making a direct request to ICDS server 460 for the file itself. If the file in question is relatively small and/or is changing on a minute-by-minute basis (e.g., an HTML file containing stock quotes) then one or more other content routing techniques may be more appropriate. Of course, other routing variables may influence the decision on which technique to use, including the issue of how strong the data transmission connection is between ICDS node
  • ICDS node 430 and ICDS server 460 i.e., how reliable it is, how much bandwidth is available . . . etc
  • the underlying information cached locally at ICDS node 430
  • the important thing to remember is that ICDS node 430 - because of its underlying open API architecture - may be configured based on the unique preferences of a particular client.
  • Content notification is a mechanism wherein the central repository for a particular piece of content maintains a list of nodes, or "subscribers," which cache a copy of the content locally.
  • a plurality of agents may run on ICDS server 460 which maintain a list of content subscribers (e.g., ICDS node 430, ICDS node 420 . . . etc) for specific types of content (e.g., HTML, data streaming files, FTP files . . . etc).
  • a different agent may be executed for each protocol supported by ICDS server 460 and/or ICDS nodes 410-440.
  • a notification of the modification may be sent to all subscriber nodes (i.e., nodes which subscribe to that particular content).
  • the subscriber node - e.g., ICDS node 430 - may then invalidate the copy of the content which it is storing locally.
  • ICDS node 430 will retrieve the up-to-date copy of the content from ICDS server 460. The new copy will then be maintained locally on ICDS node 430 until ICDS node 430 receives a second notification from an agent running on ICDS server 460 indicating that a new copy exists.
  • each time content is modified on ICDS server 460 the modified content may be sent to all subscriber nodes along with the notification. In this manner a local, up-to- date copy of the content is always ensured.
  • notification and/or transmittal of the updated content by the various system agents is done after a predetermined period of time has elapsed (e.g., update twice a day). The time period may be selected based on the importance of having an up-to-date copy across all nodes on the network 480, 490. As was the case with content revalidation, the different varieties of content notification may work more efficiently in some situations than in others.
  • content notification may be selected as a protocol (or not selected) based on one or more of the routing variables recited at the beginning of this section (i.e., the "content routing" section).
  • content notification may be an appropriate technique for content which is frequently requested at the various nodes across networks 480 and 490 (e.g., for the 5-10% of the content which is requested 90% of the time), but may be a less practical technique for larger amount of content which is requested infrequently.
  • large files which change frequently may not be well suited for content notification (i.e., particularly the type of content notification where the actual file is sent to all subscribers along with the notification) due to bandwidth constraints across networks 480 and/or 490 (i.e., the continuous transmission of large, frequently changing files may create too much additional network traffic).
  • Content synchronization is a technique for maintaining an exact copy of a particular type of content on all nodes on which it is stored. Using content synchronization, as soon as a particular piece of content is modified at, for example, ICDS node 430, it will immediately be updated at all other nodes across networks 480 and/or 490. If the same piece of data was concurrently modified at one of its other storage locations (e.g., ICDS node 410) then the changes may be backed off in order to maintain data coherency. Alternatively, an attempt may be made to reconcile the two separate modifications if it is possible to do so (using, e.g., various data coherency techniques).
  • content synchronization is more suitable for some situations than it is for others.
  • content synchronization is particularly useful for information which can be modified from several different network nodes (by contrast, the typical content notification paradigm assumes that the content is modified at one central node).
  • content synchronization may be useful for maintaining content across a network which it is particularly important to keep current. For example, if network 480 is an automatic teller machine (hereinafter "ATM") network, then when a user withdraws cash from a first node (e.g., ICDS node 440), his account will be instantly updated on all nodes (e.g., ICDS node 410, 420, 460, and 430) to reflect the withdrawal.
  • ATM automatic teller machine
  • a user's account status on a network may be maintained using content synchronization. If, for example, a user of network 480 were arrested for breaking the law over network 480 (e.g., distributing child pornography), it would be important to disable his user account on all network nodes on which this information might be cached. Accordingly, using content synchronization, once his account was disabled at one node on network 480 this change would automatically be reflected across all nodes on the network.
  • the choice of which content routing technique to use for a particular type of content may be based on any of the variables set forth above.
  • the frequency with which content is accessed across the networks 480 and/or 490 may be an important factor in deciding which protocol to use. For example, the top 1% accessed content may be selected for content synchronization, the top 2%-10% accessed content may be selected for content notification, and the remaining content across networks 480, 490 may be selected for content revaildation.
  • ICDS node 430 may receive content from ICDS server 460 via a plurality of communication media, including, but not limited to, satellite transmission, wireless RF transmission, and terrestrial transmission (e.g., fiber).
  • a plurality of communication media including, but not limited to, satellite transmission, wireless RF transmission, and terrestrial transmission (e.g., fiber).
  • the selection of a particular transmission medium may be based on any of the variables set forth above (see, e.g., routing variables listed under counter routing heading; page 24, line 18 through page 25, line 9).
  • the choice of a particular transmission medium may be dynamically adjustable based on performance of that medium.
  • ICDS node 430 may be configured to receive all of its content over terrestrial network 480 as long as network 480 is transmitting content at or above a threshold bandwidth. When transmissions over network 480 dip below the threshold bandwidth, ICDS node 480 may then begin receiving certain content via satellite broadcast or wireless communication.
  • a transmission medium may be selected for transmitting specific content based on how frequently that content is accessed.
  • the top 10% frequently accessed content may be continually pushed out to ICDS node 430 via satellite broadcast while the remaining content may be retrieved by (i.e., "pulled” to) ICDS node 430 over network 480 upon request by clients (e.g., client 473).
  • clients e.g., client 473
  • those employing ICDS nodes such as node 430 can run a cost-benefit analysis to determine the most cost effective way to implement their system by taking in to consideration, for example, the needs of their users, the importance of the content involved and the expense of maintaining multiple transmission connections into ICDS node 430 (e.g., the cost associated with maintaining an ongoing satellite connection).
  • tags may be inserted into particular types of content to identify a specific transmission path/medium for delivering that content to ICDS node 480.
  • the tags in this embodiment may identify to various nodes (and/or routers) across networks 480 and/or 490 how the particular content should be routed across the networks (e.g., from node 410 to node 420 via terrestrial network 480; from node 420 to node 430 via wireless transmission).

Abstract

Disclosed is a network content delivery system configured to: select a first content routing technique for processing a first set of network content; and select a second content routing technique for processing a second set of network content, wherein the first and second content routing techniques are selected based on one or more content routing variables. Also disclosed is a content delivery system comprising: a network node for storing network content; a first transmission medium communicatively coupled to the network node for transmitting a first set of network content to the network node; and a second transmission medium communicatively coupled to the network node for transmitting a second set of network content to the network node, wherein the first and second sets of network content are selected based on one or more routing variables.

Description

CONTENT DELIVERY SYSTEM 1
BACKGROUND OF THE INVENTION
Field of the Invention
This invention relates to the transmission and storage of digital information across a network. More particularly, the invention relates to an improved system and method for caching and/or delivering various types of digital content using a plurality of network protocols.
Description of the Related Art
The World Wide Web (hereinafter "the Web") is a network paradigm which links documents known as "Web pages" locally or remotely across multiple network nodes (i.e., Web servers). A single Web page may have links (a.k.a., "hyperlinks") which point to numerous other Web pages. When a user points and clicks on a link using a cursor control device such as a mouse, the user can jump from the initial page to another page, regardless of where the Web pages are actually located. For example, the initial Web page might be stored on a Web server in New York and the second page (accessed via the hyperlink in the first page) might be stored on a Web server in California.
The underlying principles of the Web were developed 1989 at the European Center for Nuclear Research (CERN) in Geneva. By 1994 there were approximately 500 Web servers on the Internet. Today there are more than a million, with new sites starting up at an extraordinary rate. In sum, the Web has become the center of Internet activity and is the primary reason for the explosive growth of the Internet over the past several years.
In addition to providing a simple point-and-click interface to vast amounts of information on the Internet, the Web is quickly turning into a content delivery system. Well known Internet browsers such as Netscape Navigator™ and Microsoft Internet Explorer™ frequently provide plug-in software which allow additional features to be incorporated into the browser program. These include, for example, support for audio and video streaming, telephony, and videoconferencing.
The unparalleled increase in Web usage combined with the incorporation of high bandwidth applications (i.e., audio and video) into browser programs has created serious performance/bandwidth problems for most Internet Service Providers (hereinafter "ISPs").
Moreover, the network traffic resulting from non-Web-based Internet services such as Internet
News (commonly known as "Usenet" News) has increased on the same scale as the increase in Web traffic, thereby further adding to the bandwidth problems experienced by most ISPs.
These issues will be described in more detail with respect to Figure 1 which illustrates an ISP 100 with a link 160 to a larger network 150 (e.g., the Internet) through which a plurality of clients 130, 120 can access a plurality of Web servers 140-144 and/or News servers 146-148. Maintaining a link 160 to the Internet 150 with enough bandwidth to handle the continually increasing traffic requirements of its clients 120, 130 represents a significant cost for ISP. At the same time, ISP 110 must absorb this cost in order to provide an adequate user experience for its clients 120, 130.
One system which is currently implemented to reduce network traffic across link 160 is a proxy server 210 with a Web cache 220, illustrated in Figure 2. When client 120 initially clicks on a hyperlink and requests a Web page (shown as address "www.isp.com/page.html") stored on Web server 144, client 120 will use proxy server 210 as a "proxy agent." This means that proxy server 210 will make the request for the Web page on behalf of client 120 as shown. Once the page has been retrieved and forwarded to client 120, proxy server will store a copy of the Web page locally in Web cache 220. Thus, when client 120 or another client - e.g., client 130 - makes a subsequent request for the same Web page, proxy server 210 will immediately transfer the Web page from its Web cache 210 to client 130. As a result, the speed with which client 130 receives the requested page is substantially increased, and at the same time, no additional bandwidth is consumed across Internet link 160.
While the foregoing proxy server configuration alleviates some of the network traffic across Internet link 160, several problems remain. One problem is that prior Web cache configurations do not have sufficient intelligence to deal with certain types of Web pages (or other Web-based information). For example, numerous Web pages and associated content can only be viewed by a client who pays a subscriber fee. As such, only those clients which provide proper authentication should be permitted to download the information. Today, proxy servers such as proxy server 210 will simply not cache a Web document which requires authentication. In addition, Web caches do not address the increasing bandwidth problem associated with non-Web based Internet information. In particular, little has been done to alleviate the increasing bandwidth problems created by Usenet news streams. In fact, ISPs today must set aside a substantial amount of bandwidth to provide a continual Usenet news feed to its clients.
Moreover, no mechanism is currently available for caching other data transmissions such as the streaming of digital audio and video. The term "streaming" implies a one-way transmission from a server to a client which provides for uninterrupted sound or video. When receiving a streaming transmission, the client will buffer a few seconds of audio or video information before it starts sending the information to a pair of speakers and/or a monitor, thus compensating for momentary delays in packet delivery across the network.
Accordingly, what is needed is a content delivery system which will reduce the bandwidth requirements for ISP 110 while still providing clients 120, 130 with an adequate user experience. What is also needed is a system which will work seamlessly with different types of Web-based and non-Web-based information and which can be implemented on currently available hardware and software platforms. What is also needed is an intelligent content delivery system which is capable of caching all types of Web-based information, including information which requires the authentication of a client before it can be accessed. What is also needed is a content delivery system which is easily adaptable so that it can be easily reconfigured to handle the caching of new Internet information and protocols. Finally, what is needed is a data replication system which runs on a distributed database engine, thereby incorporating well known distributed database procedures for maintaining cache coherency.
SUMMARY OF THE INVENTION
Disclosed is a network content delivery system configured to: select a first content routing technique for processing a first set of network content; and select a second content routing technique for processing a second set of network content, wherein the first and second content routing techniques are selected based on one or more content routing variables.
Also disclosed is a content delivery system comprising: a network node for storing network content; a first transmission medium communicatively coupled to the network node for transmitting a first set of network content to the network node; and a second transmission medium communicatively coupled to the network node for transmitting a second set of network content to the network node, wherein the first and second sets of network content are selected based on one or more routing variables.
BRIEF DESCRIPTION OF THE DRAWINGS
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
FIG. 1 illustrates generally a network over which an ISP and a plurality of servers communicate.
FIG. 2 illustrates an ISP implementing a proxy server Web cache.
FIG. 3 illustrates one embodiment of the underlying architecture of an Internet content delivery system node.
FIG. 4 illustrates a plurality of Internet content delivery system nodes communicating across a network.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
One embodiment of the present system is a computer comprising a processor and a memory with which software implementing the functionality of the internet content delivery system described herein is executed. Such a computer system stores and communicates (internally or with other computer systems over a network) code and data using machine readable media, such as magnetic disks, random access memory, read only memory, carrier waves, signals, etc. In addition, while one embodiment is described in which the parts of the present invention are implemented in software, alternative embodiments can implement one or more of these parts using any combination of software, firmware and/or hardware.
The underlying architecture of one embodiment of the present internet content delivery system (hereinafter "ICDS") is illustrated in Figure 3. A single ICDS node 300 is shown including a cache 330, an ICDS application programming interface (hereinafter "API") 360 which includes a distributed database engine 361, and a plurality of software modules 310-326 which interface with the ICDS API 360. ICDS node 300 may communicate over a network
340 (e.g., the Internet) over communication link 370 and may also interface with a plurality of clients 350-351 and/or other ICDS nodes (e.g., through link 380).
As is known in the art, an API such as ICDS API 360 is comprised of a plurality of subroutines which can be invoked by application software (i.e., software written to operate in conjunction with the particular API). Thus, in Figure 3 each of the plurality of software modules 310-326 may be uniquely tailored to meet the specific needs of a particular ISP. The modules interface with API 360 by making calls to the API's set of predefined subroutines. Another significant feature of ICDS API 360 is that it is platform-independent. Accordingly, it can be implemented on numerous hardware platforms including those that are Intel-based, Macintosh-based and Sun Microsystems-based.
In one embodiment, a portion of API 360' s subroutines and a set of prefabricated modules can be marketed together as a Software Development Kit (hereinafter "SDK"). This will allow ISPs, corporations and/or end-users to customize the type of internet content delivery/caching which they require. In addition, because modules 310-326 may be dynamically linked, they may be loaded and unloaded without having to reboot the hardware platform on which cache 330 is executed.
I. Distributed Content Processing
As illustrated, ICDS node 300 includes a plurality of network protocol modules 310- 319 which interface with API 360. These modules provide caching support on ICDS node 300 for numerous different Internet protocols including, but not limited to, Web protocols such as the Hypertext Transfer Protocol (hereinafter "HTTP") 310, Usenet news protocols such as the Network News Transport Protocol (hereinafter "NNRP") 312, directory access protocols such as the Lightweight Directory Access Protocol (hereinafter "LDAP") 314, data streaming protocols such as the Real Time Streaming Protocol (hereinafter "RTSP") 316, and protocols used to perform Wide Area Load Balancing (hereinafter "WALB") 318. Because the underlying architecture of the present ICDS system includes an open API, new protocol modules (e.g., module 319) can be seamlessly added to the system as needed.
One embodiment of the ICDS system includes a plurality of standardized service definitions through which individual service modules 320-326 may be configured to interface with the ICDS API 360. These service modules provide the underlying functionality of ICDS node 300 and may include a data services module 320, an access services module 322, a transaction services module 323, a commercial services module 324, a directory services module 325, and a resource services module 326. The functionality of each of these modules will be described in more detail below.
In one embodiment of the ICDS system, the ICDS API includes a distributed relational database engine 361. As a result, a plurality of ICDS nodes 410-440 can be distributed across ISP 400' s internal network and still maintain a coherent, up-to-date storage of Internet content. For example, if a particular data object is updated at two nodes simultaneously, the underlying distributed database system may be configured to resolve any conflicts between the two modifications using a predefined set of distributed database algorithms. Accordingly, the present system provides built in caching support for dynamically changing Internet content (e.g., Web pages which are modified on a regular basis). Such a result was not attainable with the same level of efficiency in prior art caching systems such as proxy server 210 of Figure 2 (which are executed on, e.g., standard flat file systems such as UNIX or NFS file servers).
Data Services
Data services modules such as module 320 running on each ICDS node 410-440 provide support for data replication and distribution across ISP 400' s internal network 480. This includes caching support for any data protocol included in the set of protocol modules 310-319 shown in Figure 3 as well as for any future protocol which may be added as a module to the ICDS API 360. Because the ICDS API 360 provides a set of standardized service definitions for data services module 320, an ISP using a plurality of ICDS nodes 300 as illustrated in Figure 4 can replicate data across its network without an extensive knowledge of distributed database technology. In other words, the ISP can configure its plurality of nodes by invoking the standardized service definitions associated with data services module 320 and leave the distributed database functionality to the distributed database engine 361.
Generally, three different types of data replication may be implemented by the present system: dynamic replication, database replication (or "actual" replication), and index replication. Using dynamic replication, if client 472 requests content from internal ICDS server 460 or from a server across network 490, the content will be delivered to client 472 and replicated in ICDS node 430. If client 473 (or any other client) subsequently requests the same content, it will be transmitted directly from ICDS node 430 rather than from its original source (i.e., a second request to server 460 or a server across network 490 will not be required). Accordingly, bandwidth across ISP 400's internal network and across Internet link
405 is conserved.
The dynamic replication mechanism just described works well for replicating static content but not for replicating dynamically changing content. For example, if the replicated content is a magazine article then caching a copy locally works well because it is static information - i.e., there is no chance that the local copy will become stale (out of date). However, if the replicated content is a Web page which contains continually changing information such as a page containing stock market quotes, then dynamic replication may not be appropriate. No built in mechanism is available for proxy cache server 210 to store an up- to-date copy of the information locally.
The present ICDS system, however, may use database replication to maintain up-to- date content at each ICDS node 410-440. Because the present system includes a distributed database engine 361, when a particular piece of content is changed at one node (e.g., ICDS server 460) a store procedure may be defined to update all copies of the information across the network. This may be in the form of a relational database query. Thus, the present system may be configured to use dynamic replication for static content but to use database replication for time-sensitive, dynamically changing content.
The third type of database replication is known as index replication. Using index replication a master index of content is replicated at one or more ICDS nodes 410-440 across the network 480. Once again, this implementation is simplified by the fact that the underlying ICDS node engine is a distributed database engine. Certain types of information distributions are particularly suitable for using index replication. For example, news overview information (i.e., the list of news articles in a particular newsgroup) is particularly suited to index replication. Instead of replicating each individual article, only the news overview information needs to be replicated at various nodes 410-440 across the network 480. When a client 473 wants to view a particular article, only then will the article be retrieved and cached locally (e.g., on ICDS node 430). ICDS node 430 is capable of caching and delivering various types of Internet data using any of the foregoing replication techniques. While prior art proxy servers such as proxy server 210 may only be used for caching Web pages, ICDS node 430 is capable of caching various other types of internet content (e.g., news content) as a result of the protocol modules
310-319 interfacing with ICDS API 360. Moreover, as stated above, ICDS node 430 (in conjunction with nodes 410, 420 and 440) may be configured to cache dynamic as well as static Web-based content using various distributed database algorithms.
One specific example of a data service provided by one embodiment of the present system is Wide Area Load Balancing (hereinafter "WALB") using layer 7 switching as described in the co-pending U.S. Patent Application entitled "WIDE AREA LOAD BALANCING"
(Serial No. ), which is assigned to the assignee of the present application and which is incorporated herein by reference. The present system may also perform dynamic protocol selection, dynamic query resolution, and/or heuristic adaptation for replicating content across a network as set forth in the co-pending U.S. Patent Application entitled Dynamic Protocol
Selection and "QUERY RESOLUTION FOR CACHE SERVERS" (Serial No. ), which is assigned to the assignee of the present application and which is incorporated herein by reference. Finally, the present system also may include network news (e.g., Usenet news) services set forth in the co-pending U.S. Patent Applications entitled "HYBRID NEWS SERVER"
(Serial No. ), and "SELF-MODERATED VIRTUAL COMMUNITIES" (Serial No. ), each assigned to the assignee of the present application and each incorporated herein by reference.
Access Services
As stated above, prior art proxy server cache systems such as proxy server 210 are only capable of caching static, publicly available Web pages. A substantial amount of Web- based and non-Web-based content, however, requires some level of authentication before a user will be permitted to download it. Thus, client 472 (in Figure 4) may pay a service fee to obtain access to content on a particular web site (e.g., from server 460 or from another server over network 490). As a result, when he attempts to access content on the site he will initially be prompted to enter a user name and password. Once the user transmits this information to the Web server, he will then be permitted to download Web server content as per his service agreement. A problem that arises, however, is that prior art cache systems such as proxy server
210 are not permitted to cache the requested content. This is because proxy server 210 has no way of authenticating subsequent users who may attempt to download the content. Thus, documents which require authentication are simply uncacheable using current network cache systems.
The present ICDS system, however, includes user authentication support embedded in access services module 322. Thus, when client 473, for example, attempts to access a Web page or other information which requires authentication, ICDS node will determine whether the requested content is stored locally. If it is, then ICDS node 430 may communicate with the authentication server (e.g., server 460 or any server that is capable of authenticating client 473 's request) to determine whether client 473 should be granted access to the content. This may be accomplished using standardized authentication service definitions embedded in access services module 322. Using these definitions, ICDS node 430 will not only know what authentication server to use, it will also know what authentication protocol to use when it communicates to the authentication server. As a result of providing local access services module 322 for authentication, network information which requires authentication can now be cached locally in ICDS node 430, thereby conserving additional bandwidth across network link 405 and/or ISP network 480.
One particular embodiment of the present system replicates Remote Authentication Dial In User Service (hereinafter "RADIUS") information across network 480. RADIUS is an application-level protocol used by numerous ISP's to provide user authentication and profile services. This is achieved by setting up a central RADRJS server with a database of users, which provides both authentication services (i.e., verification of user name and password) and profile services detailing the type of service provided to the user (for example, SLIP, PPP, telnet, rlogin).
Users connect to one or more Network Access Servers (hereinafter "NASs") which operate as a RADIUS clients and communicate with the central RADIUS server. The NAS client passes the necessary user information to the central RADIUS server, and then acts on the response which is returned. RADIUS servers receive user connection requests, authenticate users, and then return all configuration information necessary for the client to deliver service to the user. One problem associated with the RADIUS protocol is that it does not provide any built in facilities for replication of RADIUS information. Accordingly, on large ISP's such as
America Online ("AOL"), which may have tens of millions of users, RADRJS servers are hard hit, potentially handling thousands of logon requests a minute. This may create severe performance/bandwidth problems during high traffic periods. In response, some ISP's have taken a brute-force approach to distributing RADIUS information by simply copying the information to additional servers across the network without any built in mechanism to keep the RADIUS data coherent and up-to-date.
One embodiment of the present ICDS system provides an efficient, dynamic mechanism for distributing RADIUS information. Specifically, a RADRJS module is configured to interface with ICDS API 360 in this embodiment (similar to the way in which protocol modules 310-319 interface with the ICDS API 360). RADIUS information can them be seamlessly distributed across the system using distributed database engine 361. For example, the RADRJS module in conjunction with access services module 322 on ICDS node 430 may maintain radius information for local users. [Exactly how will this work? I assume that access services module will be used but there will be a separate RADIUS protocol module to support the protocol??] Thus, when client 472 first logs in to the system, ICDS node 430 may communicate with a second ICDS node (e.g., central ICDS server 460) which contains the necessary RADIUS authentication and user profile information. Client 472 will input a user name and password and will then be permitted access to the network as per his service agreement with ISP 400.
Unlike previous RADIUS systems, however, ICDS node 430 in the present embodiment may locally cache client 472' s RADRJS information so that the next time client 472 attempts to login to the network, the information will be readily available (i.e., no access to a second ICDS node will be necessary). ICDS node 430 may be configured to save client 472' s RADIUS information locally for a predetermined period of time. For example, the information may be deleted if client 472 has not logged in to local ICDS node 430 for over a month.
Thus, if client 472 represents a user who frequently travels across the country and logs in to ISP 400' s network 480 from various different ICDS nodes, the present system provides a quick, effective mechanism for dynamically replicating client 472' s user information into those geographical locations from which he most commonly accesses ISP 400. This reduces the load which would otherwise be borne by a central RADRJS server and also improves client 472' s user experience significantly (i.e., by providing him with a quick login).
Database replication can also be used to update RADIUS information distributed across multiple ICDS nodes 410-440. This may be done using known store procedures defined in relational database 361. For example, if client 472 cancels his service agreement with ISP 400, he should not be able to continually log in to local ICDS node 430 using the RADRJS information which has been cached locally. Thus, under the present ICDS system, ISP 400 may simply issue a relational database query such as [let's add another update query here using database terminology as an example] to immediately update ICDS node 430' s radius information.
One of ordinary skill in the art will readily recognize from the preceding discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention. Throughout the foregoing description, specific embodiments of the ICDS system were described using the RADIUS protocol in order to provide a thorough understanding of the operation of the ICDS system. It will be appreciated by one having ordinary skill in the art, however, that the present invention may be practiced without such specific details. For example, the ICDS system may also distribute authentication and user profile information in the form of the Lightweight Directory Access Protocol ("LDAP"). In other instances, well known software and hardware configurations/techniques have not been described in detail in order to avoid obscuring the subject matter of the present invention.
Access services module 322 may also provide local encryption/decryption and watermarking of internet content. Audio or video content delivery systems, for example, commonly use encryption of content to protect the rights of the underlying copyright holder. When a user requests a particular piece of content some delivery systems encrypt the content using a unique client encryption key. Only a client who possesses the encryption key (presumably the client who paid for the content) will be permitted to play the content back. Other systems provide for the "watermarking" of content (rather than encrypting) so that the rightful owner of the content may be identified. This simply entails embedding a unique "tag" which identifies the source of the content and/or the owner of the content (i.e., the one who paid for it).
Prior art caching systems such as proxy server 210 are not capable of dealing with encrypted or watermarked content because the encryption/watermarking functionality was not provided locally (i.e., proxy server 210 was not "smart" enough). In one embodiment of the present ICDS system, however, access services module 322 of ICDS nodes 410-440 includes a local encryption module and/or a local watermarking module. For example, if client 473 requests specific content such as a copyrighted music content stored on a music server (e.g., ICDS server 460), the initial request for the content will be made from ICDS node 430 on behalf of client 473. ICDS node 430 will retrieve the requested content and cache it locally. If the requested content requires encryption, ICDS node 430 will use its local encryption module to encrypt the requested content using a unique user encryption key for client 473.
If a second client - e.g., client 472 - requests the same content, the copy stored locally on ICDS module 430 can be used. ICDS module 430 will simply encrypt the content using a different encryption key for user 472. Thus, frequently requested multimedia content (which, as is known in the art, can occupy a substantial amount of storage space) may be cached locally at ICDS node 430 notwithstanding the fact that the content requires both user authentication and encryption.
The same functionality may be provided for watermarking of content. ICDS node will use a watermarking module (which may comprise a component of access services module 322) to individually watermark multimedia information requested by individual clients, thereby protecting the rights of the copyright holder of the underlying multimedia content. This information can then be regularly communicated back to a central database repository.
As is known in the art, multimedia files can be extremely large and, accordingly, take substantially more time to communicate across a network than do, for example, generic Web pages. As such, the ability to locally cache multimedia files significantly reduces traffic across network 480, and also significantly improves the user experience for local users when downloading multimedia information. Transaction Services
In addition to replicating data services and access services information across a network, the present ICDS system also provides for the replication of transaction services.
Transaction services includes maintaining information on client payments for use of ISP 400' s services as well as information relating to the client's online access profile (i.e., recording of the times when the user is online).
When a client logs in to an ISP today, the client's online information is maintained on a single central server. The central server maintains records of when and for how long the client logged in to the network and may also include information about what the client did while he was online. As was the case with maintaining a central RADIUS server, maintaining a central transaction server for all users of a large ISP is inefficient and cumbersome. The present system solves the performance and bandwidth problems associated with such a configuration by storing transaction information locally via transaction module 323 and algorithms build around distributed database engine 361.
Thus, if client 472 only logs on to ISP 400's network 480 via ICDS node 430, all of his transaction and billing information will be stored locally. The information may then be communicated across network 480 to a central billing server at predetermined periods of time (e.g., once a month). [We didn't go into great detail on transaction services and the rest; please add information as you feel appropriate]
Commercial Services
Commercial services module 324 provides a significantly improved local caching capability for add rotation and accounting. An add rotation system operating in conjunction with a typical proxy cache server will now be described with respect to Figure 2. When client 120 downloads a web page from Web server 142 the Web page may contain an ad tag or an add tag may automatically be inserted. The add tag will identify add server 170 and will indicate that an add should be inserted into the requested Web page from add server 170. Add server will then identify a specific add to insert into the downloaded Web page from add content server. The Web page plus the inserted add will then be forwarded to proxy server 210 and on to client 120. Add server 170 will keep an accounting of how many different users have downloaded
Web pages with adds inserted as described above. However, one problem with accounting on this system is that proxy server 210 requests Web pages on behalf of its clients. Accordingly, once the requested Web pages has been cached locally in Web cache 220, add server will only receive requests from proxy server 210 for any subsequent requests for the Web page. This will result in an inaccurate accounting of how many unique clients actually requested the Web page (and how many adds were viewed by unique users).
Because one embodiment of the present system provides built in caching support for ad rotation services, an accurate accounting of the number of hits that a particular ad receives may be maintained. More specifically, one embodiment of the present ICDS system solves this problem by providing a commercial services module that monitors and records how often individual clients request Web pages containing particular adds from add content server 171. This information than then be communicated to a central server (e.g., ICDS server 460) at predetermined intervals for generating add rotation usage reports.
Directory Services
Directory services provide the ability to cache locally a directory of information across network 480 or 490. That is, the question here is not whether the particular information is available but where exactly over networks 480 or 490 it is located. It should be noted that there may be some overlap between the directory services concept and the index replication concept described above with respect to data services. [I'm still not 100% sure what this is - please elaborate with an example]
II. Content Routing
The term "content routing" refers to the ability to select among various techniques/protocols for maintaining a coherent set of content across a network. The selection of a particular technique may be based on several routing variables including, but not limited to, the type of content involved (i.e., FTP, HTTP . . . etc), the size of the content involved (i.e., small files such as HTTP vs. large files such as audio/video streaming), the location of the content on network 480 and/or network 490, the importance of a particular piece of content (i.e., how important it is that the content be kept up-to-date across the entire network), the particular user requesting the content and the terms of his subscription agreement (i.e., some users may be willing to pay more to be insured that they receive only the most up-to-date content without having to wait), the frequency with which the content is accessed (e.g., 5%-
10% of content on the Internet represents 90% of all the requested content), and the underlying costs and bandwidth constraints associated with maintaining up-to-date, coherent content across a particular network (e.g., network 480).
Three content routing techniques which may be selected (based on one or more of the foregoing variables) to maintain coherent content across the plurality of nodes illustrated in Figure 4 are content revalidation, content notification, and content synchronization.
Content Revalidation
When content validation is selected, the original content source will be checked only when the content is requested locally. For example, client 473 may request an installation program for a new Web browser (e.g., the latest version of Microsoft's™ Internet Explorer™). The file may then be transmitted form ICDS server 460 to client 473 and a copy of the file cached locally on ICDS node 430. Consequently, if client 472 requests the same program, for example, two weeks later, ICDS node 430 may be configured to check ICDS server 460 to ensure that it contains the most recent copy of the file before passing it on to client 472 (i.e., ICDS node 430 "revalidates" the copy it has locally).
ICDS node 430 may also be configured to revalidate a piece of content only if has been stored locally for a predetermined amount of time (e.g., 1 week). The particular length of time selected may be based on one or more of the variables discussed above. Moreover, in one embodiment, the age/revision of a particular piece of content is determined based on tags (e.g., HTML metatags) inserted in the particular content/file.
Revalidation may work more efficiently with certain types of content than with others. For example, revalidation may be an appropriate mechanism for maintaining up-to-date copies of larger files which do not change very frequently (i.e., such as the program installation files described above). However, revalidation may not work as efficiently for caching smaller and/or continually changing files (e.g., small HTML files) because the step of revalidating may be just as time consuming as making a direct request to ICDS server 460 for the file itself. If the file in question is relatively small and/or is changing on a minute-by-minute basis (e.g., an HTML file containing stock quotes) then one or more other content routing techniques may be more appropriate. Of course, other routing variables may influence the decision on which technique to use, including the issue of how strong the data transmission connection is between ICDS node
430 and ICDS server 460 (i.e., how reliable it is, how much bandwidth is available . . . etc) and the necessity that the underlying information cached locally (at ICDS node 430) be accurate. The important thing to remember is that ICDS node 430 - because of its underlying open API architecture - may be configured based on the unique preferences of a particular client.
Content Notification
Content notification is a mechanism wherein the central repository for a particular piece of content maintains a list of nodes, or "subscribers," which cache a copy of the content locally. For example, in Figure 4, a plurality of agents may run on ICDS server 460 which maintain a list of content subscribers (e.g., ICDS node 430, ICDS node 420 . . . etc) for specific types of content (e.g., HTML, data streaming files, FTP files . . . etc). In one embodiment of the system, a different agent may be executed for each protocol supported by ICDS server 460 and/or ICDS nodes 410-440.
When a particular piece of content is modified on ICDS server 460, a notification of the modification may be sent to all subscriber nodes (i.e., nodes which subscribe to that particular content). Upon receiving the notification, the subscriber node - e.g., ICDS node 430 - may then invalidate the copy of the content which it is storing locally. Accordingly, the next time the content is requested by a client (e.g., client 472), ICDS node 430 will retrieve the up-to-date copy of the content from ICDS server 460. The new copy will then be maintained locally on ICDS node 430 until ICDS node 430 receives a second notification from an agent running on ICDS server 460 indicating that a new copy exists.
Alternatively, each time content is modified on ICDS server 460 the modified content may be sent to all subscriber nodes along with the notification. In this manner a local, up-to- date copy of the content is always ensured. In one embodiment of the system, notification and/or transmittal of the updated content by the various system agents is done after a predetermined period of time has elapsed (e.g., update twice a day). The time period may be selected based on the importance of having an up-to-date copy across all nodes on the network 480, 490. As was the case with content revalidation, the different varieties of content notification may work more efficiently in some situations than in others. Accordingly, content notification may be selected as a protocol (or not selected) based on one or more of the routing variables recited at the beginning of this section (i.e., the "content routing" section). For example, content notification may be an appropriate technique for content which is frequently requested at the various nodes across networks 480 and 490 (e.g., for the 5-10% of the content which is requested 90% of the time), but may be a less practical technique for larger amount of content which is requested infrequently. As another example, large files which change frequently may not be well suited for content notification (i.e., particularly the type of content notification where the actual file is sent to all subscribers along with the notification) due to bandwidth constraints across networks 480 and/or 490 (i.e., the continuous transmission of large, frequently changing files may create too much additional network traffic).
Content Synchronization
Content synchronization is a technique for maintaining an exact copy of a particular type of content on all nodes on which it is stored. Using content synchronization, as soon as a particular piece of content is modified at, for example, ICDS node 430, it will immediately be updated at all other nodes across networks 480 and/or 490. If the same piece of data was concurrently modified at one of its other storage locations (e.g., ICDS node 410) then the changes may be backed off in order to maintain data coherency. Alternatively, an attempt may be made to reconcile the two separate modifications if it is possible to do so (using, e.g., various data coherency techniques).
Once again, as with content notification and content revalidation, content synchronization is more suitable for some situations than it is for others. For example, content synchronization is particularly useful for information which can be modified from several different network nodes (by contrast, the typical content notification paradigm assumes that the content is modified at one central node). Moreover, content synchronization may be useful for maintaining content across a network which it is particularly important to keep current. For example, if network 480 is an automatic teller machine (hereinafter "ATM") network, then when a user withdraws cash from a first node (e.g., ICDS node 440), his account will be instantly updated on all nodes (e.g., ICDS node 410, 420, 460, and 430) to reflect the withdrawal. Accordingly, the user would not be able to go to a different node in a different part of the country and withdraw more than what he actually has in his account. As another example, a user's account status on a network (i.e., whether he is a current subscriber and/or what his network privileges are) may be maintained using content synchronization. If, for example, a user of network 480 were arrested for breaking the law over network 480 (e.g., distributing child pornography), it would be important to disable his user account on all network nodes on which this information might be cached. Accordingly, using content synchronization, once his account was disabled at one node on network 480 this change would automatically be reflected across all nodes on the network.
As previously stated, the choice of which content routing technique to use for a particular type of content may be based on any of the variables set forth above. In one embodiment, the frequency with which content is accessed across the networks 480 and/or 490 may be an important factor in deciding which protocol to use. For example, the top 1% accessed content may be selected for content synchronization, the top 2%-10% accessed content may be selected for content notification, and the remaining content across networks 480, 490 may be selected for content revaildation.
III. Content Delivery Medium Selection
In addition to the content routing flexibility provided by the content delivery system as set forth above, one embodiment of the system allows content delivery nodes such as ICDS node 430 to select from a plurality of different transmission media. For example, ICDS node 430 may receive content from ICDS server 460 via a plurality of communication media, including, but not limited to, satellite transmission, wireless RF transmission, and terrestrial transmission (e.g., fiber).
Moreover, as with the selection of a particular content routing technique, the selection of a particular transmission medium may be based on any of the variables set forth above (see, e.g., routing variables listed under counter routing heading; page 24, line 18 through page 25, line 9). Moreover, the choice of a particular transmission medium may be dynamically adjustable based on performance of that medium. For example, ICDS node 430 may be configured to receive all of its content over terrestrial network 480 as long as network 480 is transmitting content at or above a threshold bandwidth. When transmissions over network 480 dip below the threshold bandwidth, ICDS node 480 may then begin receiving certain content via satellite broadcast or wireless communication. In addition, a transmission medium may be selected for transmitting specific content based on how frequently that content is accessed. For example, the top 10% frequently accessed content may be continually pushed out to ICDS node 430 via satellite broadcast while the remaining content may be retrieved by (i.e., "pulled" to) ICDS node 430 over network 480 upon request by clients (e.g., client 473). Accordingly, those employing ICDS nodes such as node 430 can run a cost-benefit analysis to determine the most cost effective way to implement their system by taking in to consideration, for example, the needs of their users, the importance of the content involved and the expense of maintaining multiple transmission connections into ICDS node 430 (e.g., the cost associated with maintaining an ongoing satellite connection).
In one embodiment of the system, tags (e.g., HTML metatags) may be inserted into particular types of content to identify a specific transmission path/medium for delivering that content to ICDS node 480. The tags in this embodiment may identify to various nodes (and/or routers) across networks 480 and/or 490 how the particular content should be routed across the networks (e.g., from node 410 to node 420 via terrestrial network 480; from node 420 to node 430 via wireless transmission).
One of ordinary skill in the art will readily recognize from the preceding discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention. Throughout this detailed description, numerous specific details are set forth such as specific network protocols (i.e., RADRJS) and networks (i.e., the Internet) in order to provide a thorough understanding of the present invention. It will be appreciated by one having ordinary skill in the art, however, that the present invention may be practiced without such specific details. In other instances, well known software and hardware configurations/techniques have not been described in detail in order to avoid obscuring the subject matter of the present invention. The invention should, therefore, be measured in terms of the claims which follow.

Claims

CLAIMSWhat is claimed is:
1. A network content delivery system configured to: select a first content routing technique for processing a first set of network content; and select a second content routing technique for processing a second set of network content, wherein said first and second content routing techniques are selected based on one or more content routing variables.
2. The network content delivery system as claimed in Claim 1 wherein one of said selected content routing techniques is a content revalidation technique.
3. The network content delivery system as claimed in Claim 1 wherein one of said selected content routing techniques is a content notification technique.
4. The network content delivery system as claimed in Claim 1 wherein one of said selected content routing techniques is a content synchronization technique.
5. The network content delivery system as claimed in Claim 1 wherein one of said content routing variables is the frequency with which said network content is accessed by users.
6. The network content delivery system as claimed in Claim 1 wherein one of said content routing variables is the size of said network content.
7. The network content delivery system as claimed in Claim 1 wherein one of said content routing variables is the frequency with which said network content is modified.
8. The network content delivery system as claimed in Claim 1 wherein one of said content routing variables is the type of network content (e.g., HTML, Usenet News).
9. The network content delivery system as claimed in Claim 1 wherein one of said content routing variables is identity of the user requesting said network content.
10. The network content delivery system as claimed in Claim 2 wherein said content revalidation technique is selected based on the size of said network content.
11. The network content delivery system as claimed in Claim 2 wherein said content revalidation technique is selected based on the frequency with which said network content is accessed.
12. The network content delivery system as claimed in Claim 3 wherein said content notification technique is selected based on the size of said network content.
13. The network content delivery system as claimed in Claim 3 wherein said content notification technique is selected based on the frequency with which said network content is accessed.
14. The network content delivery system as claimed in Claim 4 wherein said content synchronization technique is selected based on the size of said network content.
15. The network content delivery system as claimed in Claim 4 wherein said content synchronization technique is selected based on the frequency with which said network content is accessed.
16. The network content delivery system as claimed in Claim 1 including the additional step of selecting a first transmission medium for a first group of network content based on one or more of said content routing variables.
17. The network content delivery system as claimed in Claim 16 including the additional step of selecting a second transmission medium for a second group of network content based on one or more of said content routing variables.
18. The network content delivery system as claimed in Claim 1 including an application programming interface for interfacing with a plurality of network protocol and service modules.
19. A content delivery system comprising: a network node for storing network content; a first transmission medium communicatively coupled to said network node for transmitting a first set of network content to said network node; and a second transmission medium communicatively coupled to said network node for transmitting a second set of network content to said network node, wherein said first and second sets of network content are selected based on one or more routing variables.
20. The content delivery system as claimed in Claim 19 wherein said first transmission medium is a satellite transmission.
21. The content delivery system as claimed in Claim 19 wherein said first transmission medium is a wireless radio frequency transmission.
22. The content delivery system as claimed in Claim 19 wherein said first transmission medium is terrestrial-based transmission.
23. The content delivery system as claimed in Claim 19 wherein said network node monitors transmission bandwidth of said first transmission medium and reallocates content from said first set to said second set if said first transmission medium drops below a predetermined threshold value.
24. The content delivery system as claimed in Claim 23 wherein said first transmission medium is terrestrial and said second transmission medium is non-terrestrial.
25. The content delivery system as claimed in Claim 19 wherein content is included in said first set based on the frequency with which said content is accessed.
26. The network content delivery system as claimed in Claim 19 including an application programming interface for interfacing with a plurality of network protocol and service modules.
27. An article of manufacture including a sequence of instructions stored on a computer-readable media which, when executed by a network node, cause the network node to perform the acts of: establishing a plurality of groups of network content to be cached on said network node based on one or more content routing variables; selecting a first content routing technique for maintaining data coherency in a first group of said plurality; and selecting a second content routing technique for maintaining data coherency in a second group of said plurality.
28. The article of manufacture as claimed in claim 27 wherein said first content routing technique is content revalidation.
29. The article of manufacture as claimed in Claim 28 wherein said second content routing technique is content notification.
30. The article of manufacture as claimed in Claim 28 wherein said second content routing technique is content synchronization.
31. The article of manufacture as claimed in Claim 28 wherein said content routing variable used to select said content for said first group is the frequency with which said content is accessed.
32. The article of manufacture as claimed in Claim 29 wherein said content routing variable used to select said content for said first group is the frequency with which said content is accessed.
33. The article of manufacture as claimed in Claim 30 wherein said content routing variable used to select said content for said first group is the frequency with which said content is accessed.
34. A network node comprising: an application programming interface ("API"), said API including a distributed relational database engine; a plurality of protocol modules for interfacing with said API, said protocol modules configured to allow said system to communicate over a network using a plurality of network protocols; a cache memory for caching data communicated to said cache memory using said plurality of protocol modules; and a data services module for maintaining coherency between said data stored in said cache memory and data stored at other nodes across said network.
PCT/US2000/011078 1999-06-01 2000-04-25 Content delivery system WO2000073922A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU46617/00A AU4661700A (en) 1999-06-01 2000-04-25 Content delivery system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US32363599A 1999-06-01 1999-06-01
US09/323,635 1999-06-01

Publications (2)

Publication Number Publication Date
WO2000073922A2 true WO2000073922A2 (en) 2000-12-07
WO2000073922A3 WO2000073922A3 (en) 2001-08-16

Family

ID=23260047

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/011078 WO2000073922A2 (en) 1999-06-01 2000-04-25 Content delivery system

Country Status (2)

Country Link
AU (1) AU4661700A (en)
WO (1) WO2000073922A2 (en)

Cited By (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1346307A2 (en) * 2001-05-31 2003-09-24 ContentGuard Holdings, Inc. Method and apparatus for dynamically assigning usage rights to digital works
US6658000B1 (en) 2000-06-01 2003-12-02 Aerocast.Com, Inc. Selective routing
WO2004043045A2 (en) * 2002-11-06 2004-05-21 Tellique Kommunikationstechnik Gmbh Method for the pre-transmission of structured data amounts between a client device and a server device
US6836806B1 (en) 2000-06-01 2004-12-28 Aerocast, Inc. System for network addressing
US6879998B1 (en) 2000-06-01 2005-04-12 Aerocast.Com, Inc. Viewer object proxy
US6904460B1 (en) 2000-06-01 2005-06-07 Aerocast.Com, Inc. Reverse content harvester
US7213062B1 (en) 2000-06-01 2007-05-01 General Instrument Corporation Self-publishing network directory
US7664708B2 (en) 1994-11-23 2010-02-16 Contentguard Holdings, Inc. System for controlling the distribution and use of digital works using digital tickets
US7685642B2 (en) 2003-06-26 2010-03-23 Contentguard Holdings, Inc. System and method for controlling rights expressions by stakeholders of an item
US7720767B2 (en) 2005-10-24 2010-05-18 Contentguard Holdings, Inc. Method and system to support dynamic rights and resources sharing
US7725401B2 (en) 2001-05-31 2010-05-25 Contentguard Holdings, Inc. Method and apparatus for establishing usage rights for digital content to be created in the future
US7743259B2 (en) 2000-08-28 2010-06-22 Contentguard Holdings, Inc. System and method for digital rights management using a standard rendering engine
US7765403B2 (en) 1997-02-28 2010-07-27 Contentguard Holdings, Inc. System for controlling the distribution and use of rendered digital works through watermarking
US7774280B2 (en) 2001-06-07 2010-08-10 Contentguard Holdings, Inc. System and method for managing transfer of rights using shared state variables
US7774279B2 (en) 2001-05-31 2010-08-10 Contentguard Holdings, Inc. Rights offering and granting
US7805371B2 (en) 2002-03-14 2010-09-28 Contentguard Holdings, Inc. Rights expression profile system and method
US7809644B2 (en) 1994-11-23 2010-10-05 Contentguard Holdings, Inc. Digital work structure
US7840488B2 (en) 2001-11-20 2010-11-23 Contentguard Holdings, Inc. System and method for granting access to an item or permission to use an item based on configurable conditions
US7853531B2 (en) 2001-06-07 2010-12-14 Contentguard Holdings, Inc. Method and apparatus for supporting multiple trust zones in a digital rights management system
US7907749B2 (en) 2000-12-29 2011-03-15 Contentguard Holdings, Inc. Multi-stage watermarking process and system
US7913095B2 (en) 2000-08-28 2011-03-22 Contentguard Holdings, Inc. Method and apparatus for providing a specific user interface in a system for managing content
US7974923B2 (en) 2001-11-20 2011-07-05 Contentguard Holdings, Inc. Extensible rights expression processing system
US8001053B2 (en) 2001-05-31 2011-08-16 Contentguard Holdings, Inc. System and method for rights offering and granting using shared state variables
US8069116B2 (en) 2001-01-17 2011-11-29 Contentguard Holdings, Inc. System and method for supplying and managing usage rights associated with an item repository
US8099364B2 (en) 2001-05-31 2012-01-17 Contentguard Holdings, Inc. Digital rights management of content when content is a future live event
US8108313B2 (en) 2002-03-14 2012-01-31 Contentguard Holdings, Inc. Rights expression profile system and method using templates
US8244579B2 (en) 2001-01-17 2012-08-14 Contentguard Holdings, Inc. Method and apparatus for distributing enforceable property rights
US8271350B2 (en) 2000-11-03 2012-09-18 Contentguard Holdings, Inc. Method and system for automatically publishing content
US8275716B2 (en) 2001-05-31 2012-09-25 Contentguard Holdings, Inc. Method and system for subscription digital rights management
US8275709B2 (en) 2001-05-31 2012-09-25 Contentguard Holdings, Inc. Digital rights management of content when content is a future live event
US8442916B2 (en) 2001-05-31 2013-05-14 Contentguard Holdings, Inc. Digital rights management of content when content is a future live event
US8543511B2 (en) 2002-04-29 2013-09-24 Contentguard Holdings, Inc. System and method for specifying and processing legality expressions
US8660961B2 (en) 2004-11-18 2014-02-25 Contentguard Holdings, Inc. Method, system, and device for license-centric content consumption
US8869293B2 (en) 2001-05-31 2014-10-21 Contentguard Holdings, Inc. Method and apparatus for hierarchical assignment of rights to documents and documents having such rights
US9898715B2 (en) 2001-11-20 2018-02-20 Contentguart Holdings, Inc. Systems and methods for creating, manipulating and processing rights and contract expressions using tokenized templates

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4308161A1 (en) * 1993-03-16 1994-09-22 Philips Patentverwaltung System for communication via satellites
EP0689338A2 (en) * 1994-06-24 1995-12-27 Sony Corporation System for providing information to subscribers via telephone lines
GB2294132A (en) * 1994-10-10 1996-04-17 Marconi Gec Ltd Data communication network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4308161A1 (en) * 1993-03-16 1994-09-22 Philips Patentverwaltung System for communication via satellites
EP0689338A2 (en) * 1994-06-24 1995-12-27 Sony Corporation System for providing information to subscribers via telephone lines
GB2294132A (en) * 1994-10-10 1996-04-17 Marconi Gec Ltd Data communication network

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ARANGO M ET AL: "GUARANTEED INTERNET BANDWIDTH" PHOENIX, MAY 4 - 7, 1997,NEW YORK, IEEE,US, vol. CONF. 47, 18 November 1996 (1996-11-18), pages 862-866, XP000741554 ISBN: 0-7803-3660-7 *
CAO P ET AL: "MAINTAINING STRONG CACHE CONSISTENCY IN THE WORLD WIDE WEB" IEEE TRANSACTIONS ON COMPUTERS,US,IEEE INC. NEW YORK, vol. 47, no. 4, 1 April 1998 (1998-04-01), pages 445-457, XP000740725 ISSN: 0018-9340 *
CAUGHEY S J ET AL: "Flexible open caching for the Web" COMPUTER NETWORKS AND ISDN SYSTEMS,NL,NORTH HOLLAND PUBLISHING. AMSTERDAM, vol. 29, no. 8-13, 1 September 1997 (1997-09-01), pages 1007-1017, XP004095299 ISSN: 0169-7552 *
DINGLE A ET AL: "Web cache coherence" COMPUTER NETWORKS AND ISDN SYSTEMS,NL,NORTH HOLLAND PUBLISHING. AMSTERDAM, vol. 28, no. 11, 1 May 1996 (1996-05-01), pages 907-920, XP004018195 ISSN: 0169-7552 *
WOOSTER R P ET AL: "Proxy caching that estimates page load delays" COMPUTER NETWORKS AND ISDN SYSTEMS,NL,NORTH HOLLAND PUBLISHING. AMSTERDAM, vol. 29, no. 8-13, 1 September 1997 (1997-09-01), pages 977-986, XP004095296 ISSN: 0169-7552 *

Cited By (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7809644B2 (en) 1994-11-23 2010-10-05 Contentguard Holdings, Inc. Digital work structure
US8170955B2 (en) 1994-11-23 2012-05-01 Contentguard Holdings, Inc. System and method for enforcing usage rights associated with digital content
US9953328B2 (en) 1994-11-23 2018-04-24 Contentguard Holdings, Inc. Method and system for conducting transactions between repositories
US7788182B2 (en) 1994-11-23 2010-08-31 Contentguard Holdings, Inc. Method for loaning digital works
US7970709B2 (en) 1994-11-23 2011-06-28 Contentguard Holdings, Inc. Method and apparatus for client customization by executing software parts on plural servers
US7664708B2 (en) 1994-11-23 2010-02-16 Contentguard Holdings, Inc. System for controlling the distribution and use of digital works using digital tickets
US7765403B2 (en) 1997-02-28 2010-07-27 Contentguard Holdings, Inc. System for controlling the distribution and use of rendered digital works through watermarking
US8205089B2 (en) 1997-02-28 2012-06-19 Contentguard Holdings, Inc. System for controlling the distribution and use of rendered digital works through watermarking
US6904460B1 (en) 2000-06-01 2005-06-07 Aerocast.Com, Inc. Reverse content harvester
US7213062B1 (en) 2000-06-01 2007-05-01 General Instrument Corporation Self-publishing network directory
US6879998B1 (en) 2000-06-01 2005-04-12 Aerocast.Com, Inc. Viewer object proxy
US7747772B2 (en) 2000-06-01 2010-06-29 Aerocast.Com, Inc. Viewer object proxy
US6836806B1 (en) 2000-06-01 2004-12-28 Aerocast, Inc. System for network addressing
US6658000B1 (en) 2000-06-01 2003-12-02 Aerocast.Com, Inc. Selective routing
US7743259B2 (en) 2000-08-28 2010-06-22 Contentguard Holdings, Inc. System and method for digital rights management using a standard rendering engine
US8489900B2 (en) 2000-08-28 2013-07-16 Contentguard Holdings, Inc. Method and apparatus for providing a specific user interface in a system for managing content
US7913095B2 (en) 2000-08-28 2011-03-22 Contentguard Holdings, Inc. Method and apparatus for providing a specific user interface in a system for managing content
US8832852B2 (en) 2000-08-28 2014-09-09 Contentguard Holdings, Inc. Method and apparatus for dynamic protection of static and dynamic content
US8271350B2 (en) 2000-11-03 2012-09-18 Contentguard Holdings, Inc. Method and system for automatically publishing content
US7907749B2 (en) 2000-12-29 2011-03-15 Contentguard Holdings, Inc. Multi-stage watermarking process and system
US8069116B2 (en) 2001-01-17 2011-11-29 Contentguard Holdings, Inc. System and method for supplying and managing usage rights associated with an item repository
US8244579B2 (en) 2001-01-17 2012-08-14 Contentguard Holdings, Inc. Method and apparatus for distributing enforceable property rights
US8275709B2 (en) 2001-05-31 2012-09-25 Contentguard Holdings, Inc. Digital rights management of content when content is a future live event
US8001053B2 (en) 2001-05-31 2011-08-16 Contentguard Holdings, Inc. System and method for rights offering and granting using shared state variables
US8862517B2 (en) 2001-05-31 2014-10-14 Contentguard Holdings, Inc. Digital rights management of content when content is a future live event
EP1346307A4 (en) * 2001-05-31 2004-07-28 Contentguard Holdings Inc Method and apparatus for dynamically assigning usage rights to digital works
US7774279B2 (en) 2001-05-31 2010-08-10 Contentguard Holdings, Inc. Rights offering and granting
US8869293B2 (en) 2001-05-31 2014-10-21 Contentguard Holdings, Inc. Method and apparatus for hierarchical assignment of rights to documents and documents having such rights
US8468098B2 (en) 2001-05-31 2013-06-18 Contentguard Holdings, Inc. Method and system for subscription digital rights management
US8275716B2 (en) 2001-05-31 2012-09-25 Contentguard Holdings, Inc. Method and system for subscription digital rights management
US7725401B2 (en) 2001-05-31 2010-05-25 Contentguard Holdings, Inc. Method and apparatus for establishing usage rights for digital content to be created in the future
US8442916B2 (en) 2001-05-31 2013-05-14 Contentguard Holdings, Inc. Digital rights management of content when content is a future live event
US8099364B2 (en) 2001-05-31 2012-01-17 Contentguard Holdings, Inc. Digital rights management of content when content is a future live event
US8412644B2 (en) 2001-05-31 2013-04-02 Contentguard Holdings, Inc. Method and apparatus for establishing usage rights for digital content to be created in the future
EP1346307A2 (en) * 2001-05-31 2003-09-24 ContentGuard Holdings, Inc. Method and apparatus for dynamically assigning usage rights to digital works
US8892473B2 (en) 2001-05-31 2014-11-18 Contentguard Holdings, Inc. Method and system for subscription digital rights management
US7774280B2 (en) 2001-06-07 2010-08-10 Contentguard Holdings, Inc. System and method for managing transfer of rights using shared state variables
US7853531B2 (en) 2001-06-07 2010-12-14 Contentguard Holdings, Inc. Method and apparatus for supporting multiple trust zones in a digital rights management system
US7974923B2 (en) 2001-11-20 2011-07-05 Contentguard Holdings, Inc. Extensible rights expression processing system
US9898715B2 (en) 2001-11-20 2018-02-20 Contentguart Holdings, Inc. Systems and methods for creating, manipulating and processing rights and contract expressions using tokenized templates
US7840488B2 (en) 2001-11-20 2010-11-23 Contentguard Holdings, Inc. System and method for granting access to an item or permission to use an item based on configurable conditions
US9626668B2 (en) 2002-03-14 2017-04-18 Contentgaurd Holdings, Inc. Rights expression profile system and method using templates
US8108313B2 (en) 2002-03-14 2012-01-31 Contentguard Holdings, Inc. Rights expression profile system and method using templates
US7805371B2 (en) 2002-03-14 2010-09-28 Contentguard Holdings, Inc. Rights expression profile system and method
US8543511B2 (en) 2002-04-29 2013-09-24 Contentguard Holdings, Inc. System and method for specifying and processing legality expressions
WO2004043045A3 (en) * 2002-11-06 2004-11-04 Tellique Kommunikationstechnik Method for the pre-transmission of structured data amounts between a client device and a server device
EP1930818A1 (en) * 2002-11-06 2008-06-11 Tellique Kommunikationstechnik GmbH Method for pre-transmission of structured data sets between a client device and a server device
EP1887484A3 (en) * 2002-11-06 2008-08-27 Tellique Kommunikationstechnik GmbH Method for pre-transmission of structured data sets between a client device and a server device
US8078759B2 (en) 2002-11-06 2011-12-13 Tellique Kommunikationstechnik Gmbh Method for prefetching of structured data between a client device and a server device
WO2004043045A2 (en) * 2002-11-06 2004-05-21 Tellique Kommunikationstechnik Gmbh Method for the pre-transmission of structured data amounts between a client device and a server device
US7685642B2 (en) 2003-06-26 2010-03-23 Contentguard Holdings, Inc. System and method for controlling rights expressions by stakeholders of an item
US8660961B2 (en) 2004-11-18 2014-02-25 Contentguard Holdings, Inc. Method, system, and device for license-centric content consumption
US8768850B2 (en) 2004-11-18 2014-07-01 Contentguard Holdings, Inc. Method, system, and device for license-centric content consumption
US7720767B2 (en) 2005-10-24 2010-05-18 Contentguard Holdings, Inc. Method and system to support dynamic rights and resources sharing

Also Published As

Publication number Publication date
WO2000073922A3 (en) 2001-08-16
AU4661700A (en) 2000-12-18

Similar Documents

Publication Publication Date Title
WO2000073922A2 (en) Content delivery system
US10645149B2 (en) Content delivery reconciliation
AU714336B2 (en) Web serving system with primary and secondary servers
US6799248B2 (en) Cache management system for a network data node having a cache memory manager for selectively using different cache management methods
Wessels Web caching
EP2263208B1 (en) Content delivery in a network
EP1269714B1 (en) Method and device for distributed caching
US6687846B1 (en) System and method for error handling and recovery
US8438263B2 (en) Locality based content distribution
US6192398B1 (en) Remote/shared browser cache
EP1410285B1 (en) Method for controlling access to digital content and streaming media
US20030093511A1 (en) System for reducing server loading during content delivery
US6766422B2 (en) Method and system for web caching based on predictive usage
US20050273514A1 (en) System and method for automated and optimized file transfers among devices in a network
US20070061863A1 (en) Method and system for distribution of digital protected content data via a peer-to-peer data network
US20010051927A1 (en) Increasing web page browsing efficiency by periodically physically distributing memory media on which web page data are cached
US20040264471A1 (en) Method and system for accessing a peer-to-peer network
WO1998004985A9 (en) Web serving system with primary and secondary servers
US6704781B1 (en) System and method for content caching implementing compensation for providing caching services
US6236661B1 (en) Accelerating access to wide area network information
JP3437680B2 (en) Dialogue management type information providing method and apparatus
US8515773B2 (en) System and method for enabling distribution and brokering of content information
WO2002011392A2 (en) Propagation of state and content over a distributed electronic network
WO2002052384A2 (en) System and method for automated and optimized file transfers among devices in a network
Rzewski et al. RFC3570: Content Internetworking (CDI) Scenarios

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP