[go: up one dir, main page]

WO2002023363A1 - Systemes et procedes pour distribuer un contenu sur un reseau informatique - Google Patents

Systemes et procedes pour distribuer un contenu sur un reseau informatique Download PDF

Info

Publication number
WO2002023363A1
WO2002023363A1 PCT/US2001/028452 US0128452W WO0223363A1 WO 2002023363 A1 WO2002023363 A1 WO 2002023363A1 US 0128452 W US0128452 W US 0128452W WO 0223363 A1 WO0223363 A1 WO 0223363A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
client
program
network
server
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/US2001/028452
Other languages
English (en)
Inventor
Joe D. Croman
Christophe Anderson
Robert Rees
Seth Silverman
Yishai Sered
Mark W. Eichin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Into Networks Inc
Original Assignee
Into Networks 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 Into Networks Inc filed Critical Into Networks Inc
Priority to AU2001290796A priority Critical patent/AU2001290796A1/en
Publication of WO2002023363A1 publication Critical patent/WO2002023363A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/509—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to media content delivery, e.g. audio, video or TV
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/2312—Data placement on disk arrays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2408—Monitoring of the upstream path of the transmission network, e.g. client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26216—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8186—Monomedia components thereof involving executable data, e.g. software specially adapted to be executed by a peripheral of the client device, e.g. by a reprogrammable remote control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity

Definitions

  • This invention relates to methods and systems for delivering content over a computer network, including delivering executable and data content that may be executed by a remote user in real time.
  • the systems and methods of the invention include, inter alia, systems for allowing a remote user to access content, such as data or an executable program, on demand from a remote server for local execution. When accessed the content can be delivered on demand to the user's remote workstation for use by the user, providing the user with an experience comparable to the user experience provided when accessing the content locally.
  • content such as data or an executable program
  • the systems described herein further include systems that will monitor network resources, and other factors, versus the transfer demands for the content requested by the user.
  • the systems may then determine a schedule and method, or load map, for transferring blocks of the content in a way that efficiently employs the available resources, and in a way that provides the user with a user-experience that is similar, or substantially similar, to the user- experience that the user would have if the content were stored locally on the user's workstation.
  • a user at a remote workstation may request access to content, such as an executable program.
  • content such as an executable program.
  • the system transfers blocks of content to the user, where each block contains either data, content or executable code that the remote workstation can employ to execute the application locally.
  • the system may continue to allow the workstation to retrieve portions of the executable program as the application requires.
  • the systems described herein may also employ predictive threading to preselect requests for content given the resource constraints of the network.
  • the systems and methods described herein include a profiler process that analyzes the content access pattern, which can include the disk access or memory access pattern of an executing title and generates a load map. This process can collect information about how the title is accessed from storage as the user employs the title.
  • the profiler may observe and analyze the execution of the executable content and/or data. During analysis of the content, the file access pattern of the executable content may be observed. The profiler may then create a load map that is representative of the disk access or other file or memory access that are made as a user selects among the different options provided by the content.
  • the systems described herein may also include a map reader.
  • the map reader may be a computer process that interprets the load map created by the profiler and creates one or more cache preload requests.
  • the cache preload requests may be representative of requests from the client to the remote server for additional components of the executable title.
  • a cache manager is provided wherein the cache manager communicates with the map reader and responds to, inter alia, preload requests from the map reader.
  • systems described herein include scheduling processes that more efficiently use network resources to facilitate the real-time execution of the program.
  • the systems and methods described herein include a method of transmitting data over a network, to support execution of a program at a remote location.
  • the methods may comprise determining a measure of available throughput for transmitting data over the network.
  • the method in certain practices, but not all, may include, identifying information to be transmitted over the network and generating a forward-looking load map of information for a given execution state of the program, and based on the load map and the execution state, generating an anticipatory load request for transmitting the information within the available throughput and for maintaining consistent execution of the program.
  • the information comprises at least one of data or an executable file.
  • the information may be transmitted from a server to a client.
  • the act of identifying information may include selecting information based on the available throughput and the execution state of the program at a time of selection.
  • Information may be packaged, or be associated with load maps that are more suited to one throughput than another, or that are associated with a fee structure that provides one level of service versus another.
  • the methods may further include the acts of the client requesting information to be . transmitted, the client selecting a subset of the information based on the available throughput at a time of selection, and the client selecting, for transmission from the server to the client, information from the subset of the information.
  • the client requesting information to be transmitted, and if the request is approved, receiving a key adapted to access the information for transmission from the server to the client.
  • the methods may include methods wherein the forward-looking load map is generated based an access pattern for the transmitted information.
  • the access pattern may include the disk access pattern, where the title is run under different scenarios or conditions, and the disk access is monitored under these conditions. From this activity, a load map that maps out a sequence for retrieving data blocks may be generated.
  • the systems described herein may include a system for transmitting structured information over a network having an identified available throughput, comprising a server providing the information, a client receiving the information from the server, a profiler monitoring transmission of the information from the server and generating at least one load map based on an analysis of an information access pattern at the server, a map reader, based on the at least one load map, for interpreting information contained within a load map and for generating time valued requests to the server based on available throughput and informational requirements, and a cache manager that merges the information to organize the structured information.
  • the cache manager may further include storage means to store at least the information associated with a pre-load operation and may select for merging a block of the information from the storage means, if the block is available, and requests a block from the server, if the block is not yet available.
  • the system may also include a player which arranges for the execution of the structured information.
  • the invention may provide methods for providing multiple • levels of support for executing over a computer network a program having blocks of executable code, comprising providing, for a plurality of network performance levels, a plurality of load maps associated with respective ones of said network performance levels and having a list of sections of executable code of the program ordered according to the expected priority of access of the executable code by the program, determining a network performance level available through the network to a client, selecting a load map as a function of the network performance level available, and allowing the client to request sections of the program according to the load map selected.
  • the method may include processing the program to generate the plurality of load maps. To this end processing the program includes determining for a respective network performance level a preload list representative of a series of sections of executable code that are to be transmitted over the network prior to execution of the program.
  • Processing the program includes monitoring execution of the program to determine a sequence of block fetches for moving sections of executable code into computer memory and cache during program execution.
  • Generating an ordered list includes ordering the list to provide a delivery sequence for scheduling delivery of sections of executable code over the network to the client. Generating the ordered list to schedule transmission of executable code over the network during a period of low network activity during program execution.
  • the method may determine a network performance level by launching a player program at the client capable of exchanging information with a remote server for determining the available network bandwidth, including launching a player program at the client capable of exchanging information with a remote server for determining network latency.
  • determining a network performance level includes determining cache memory available at the client, and selecting a load map includes comparing a network performance level to a threshold level and preceding to selecting of a load map as a function of the comparison.
  • Other methods provided herein include a method for providing multiple levels of support for executing over a computer network a program having blocks of executable code, comprising providing a file system management process for monitoring file access operations of a computer program executing within an application memory space, executing the program, employing the file system management process, while the program is being executed, for determining a sequence and a timing pattern with which blocks of executable code are loaded into the application memory space, and processing the sequence and timing pattern to generate a load map representative of a sequence and timing pattern for transmitting blocks of executable code over the network.
  • generating a load map includes processing the sequence and timing pattern to identify periods during program execution available for transmitting additional blocks of executable code. This may include determining probabilistically the additional blocks of executable code to deliver over the network, as well as processing the sequence and timing pattern while collecting information representative of blocks of executable code requested from a remote site and adjusting the load map as a function of the collected information.
  • the method may add trigger controls within the generated load map for controlling post-load execution on a client based on programs file accesses.
  • Figure 1 depicts schematically the structure of one embodiment of a system according to the invention
  • Figure 2 depicts on example of a Load Map
  • Figure 3 depicts graphically the download demand for a title versus time. Best Mode for Carrying Out the Invention
  • the systems and methods described herein include systems for delivering content over a data network, and more particularly include systems and methods for delivering executable content over a data network, in a manner that allows a user at a remote site to access the content on demand to have a user experience that is comparable to the user experience that would be achieved if the content were being accessed locally
  • the systems and methods described herein include systems and methods that analyze the throughput available for delivering data between the client and the server. Based on this determined throughput, the systems select a delivery schedule and method for transferring data to the client. Moreover, the systems monitor the client's use of the content to determine what other content should be preloaded or cached on the client system, so that the user's access to the content is comparable to the access the user would have if the content was stored locally.
  • Examples of such systems include client/server systems that allow users at a remote client system to access an executable title stored at a remote location and to run that title locally on the client system by retrieving on demand portions of the executable content from the remote server.
  • the systems and methods may further include a mechanism for determining the network characteristics and throughput available for transmitting data between the server and the client.
  • the systems and- methods described herein employ the determined available network characteristics and throughput to select a load map file suitable for use with a network having the identified characteristics and available throughput.
  • the load map file may, in one embodiment, be a data file associated with the content, or title, that the user at the remote client desires to access from the server and execute locally at the client.
  • the load map file may be a data file associated with and representative of a title that has been formatted into a package that makes the executable code within the title more easy to segment and to deliver in sections across the data network and to the remote client.
  • the load map may include predictive loading information.
  • the predictive loading information may be information that can be employed by a load map reader to fetch segments of the title from the server.
  • the load map may include a method and an ordered list of data blocks to be fetched, without considering the progress of the particular title session. After the title is launched, the client is to fetch blocks on this ordered list per the defined method in the given order when- the network conditions permit.
  • the load map may also include information in a tree structure that is representative of a list of a set of blocks, each set being associated with an additional set of blocks. If the client detects that the blocks in the first order set are being fetched by the title, then the blocks in the second order set are to be loaded. This provides for probabilistic loading.
  • the load map data file may include information and methods that allows a client to download blocks of executable code from the server to the client.
  • This probabilistic loading in combination with the use of load maps, can provide the user with a user experience that is comparable to the user experience the user would have if the content were stored locally.
  • a computer game may comprise both executable code as well as data including images, text and other types of data content.
  • Figure 1 depicts a system 10 that employs a client/server architecture to allow a user on a remote client to execute locally a title that is maintained at a remote server.
  • Figure 1 depicts a system 10 that includes a server 12, that optionally may comprise multiple servers 62, 64, 68,1 8 and 20. and a client 14.
  • the structure of the client 12 and the server 14 includes elements described in detail in the above identified US patent applications and PCT applications: 60/231,992- entitled Systems and Methods for Delivering Content Over a Computer Network, filed 11 September 2000 and naming Joe D.
  • the depicted server 12 includes a server front end 16, a dispatcher 18, a RAFT (remote content) server 20, a plurality title briqs 22 a, b and c respectively, a plurality of title load maps 24 a, b and c respectively, and an optional profiler 28 and an optional running title 30.
  • RAFT remote content
  • the server front end 16 includes a web storefront 62, an e-commerce server 64 and a conditional access server 68.
  • the server front end 16 allows a user to negotiate a transaction with the server 12 to purchase access to a title the user wishes to employ.
  • the server front end 16 is in communication with the dispatcher 18.
  • the dispatcher 18 illustrated in Figure 1 discovers local RAFT servers, tracks their relative loading and bandwidth delivery, and provides this information upon request optionally to the conditional access server 16 and optionally the Player 38 of the client 14. There will typically be only one instance of the Dispatcher service running per bank of RAFT servers, although the design should allow for fail-over as well.
  • the Random Access File Transfer (RAFT) server 20 may be a read-only content server designed specifically for Internet-based content distribution.
  • the RAFT server 20 may also be designed to enable proxy or cache servers on the network.
  • the RAFT can enable dynamic bandwidth restrictions and employ other methods to prevent network congestion. More specifically, the RAFT server 20 is capable of serving content to the client 14 .
  • the client 14 after having negotiated with the store front 16 to purchase access to a title, contacts the RAFT server 20 to gain access to that title.
  • the RAFT server 20 can verify that the client 14 has purchased access to a particular title 22, and can provide the client 14 with access to that title.
  • the RAFT server 20 can process a request from the client 14 that includes a protocol version, the path name for the title and an access token.
  • the protocol version is a 32-bit value used to verify that the client and server are protocol compatible.
  • the RAFT server 20 verifies the token is valid.
  • the RAFT server 20 can monitor the parameters of the users access requests to make sure they stay within prescribed limits. For example, the user may have purchased a limited amount of access time, or access to only certain portions of the title, or some other type of limited access.
  • the RAFT server can check the token's parameters, such as its start and expiration times during the open. If the RAFT OPEN is successful, the RAFT server returns a RAFT file handle and a unique ID for the briq associated with the title. Typically, the RAFT access token will eventually expire, and the RAFT server 20 will no longer grant access to the title 22.
  • the RAFT server 20 may be implemented as an application executable on a POSLX.1 (IEEE Std 1003.1, 1998) compatible platform, such as the Sun Solaris® operating system commercially available from Sun Microsystems, Palo Alto, CA, or the Linux operating system commercially available from Red Hat Software.
  • the RAFT server may be implemented as a RAFT application and a Simple Network Management Protocol (SNMP) master agent executing on top of the operating system.
  • SNMP Simple Network Management Protocol
  • a commercial product suitable for implementing the SNMP master agent is the Emanate product commercially available from SNMP Research, Inc.
  • the master agent communicates with the network using published application program interfaces in accordance with the SNMP standards.
  • the server 12 further includes a plurality of titles 22 as shown in Fig. 1.
  • a title 22 is formatted into an electronic package that contains the title's files in a compressed and encrypted form, referred to as a briq.
  • title software used in the system of Figure 1 is packaged in briqs 22.
  • the briq 22 contains the executables, support software, and data files, arranged in the appropriate directory structure. Additionally, the briq may contain meta data that that supports an install abstraction, security, system requirements, and other processes and data for allowing the title to execute locally.
  • data is fetched in discrete units, referred to as Blocks.
  • the block size may be fixed at some power of 2, such as 32768 bytes.
  • the title running on the client 14 makes requests for directory, executable or content information, which are to be satisfied from the associated briq 22, these requests are translated to some extent of bytes in the associated briq 22.
  • the client 14 then fetches the Block or Blocks in which this extent of bytes is stored.
  • the briq 22 is a portable, self-contained file system, containing files and meta-data to be employed to run a particular title. Briqs 22 are stored on the file server 12, or a storage device or system accessible by the server 12 or to which the server 12 can refer the client 14.
  • FIG. 1 shows that the server 12 includes a plurality of briqs 22.
  • each of the depicted Title briqs 22 is associated with a separate title or titles.
  • the different load maps 24 for each respective title briq 22, provide different loading profiles or loading schedules and methods for the respective title briq22, wherein the difference in loading profiles or load schedule and methods arises from the difference in network characteristics and throughput that can arise when users request access to a particular title.
  • the system 10 may determine the network characteristics and throughput available to server for delivering the blocks to the user.
  • the first user may have a high speed cable access that is providing about 1Mbit throughput and minimal latency.
  • the second user may have a DSL connection that is presently burdened and is providing about 300 Kbit throughput with high latency.
  • the server has 1Mbit of throughput available and low latency. Throughput may be understood as the rate at which data may be transferred between the Raft server 20 and the player 38. The throughput is effected by the network resources, including bandwidth, latency, QoS and other factors.
  • the server 12 can employ a schedule and method of access that downloads the blocks necessary to begin the title run, and can service the title's request for more blocks on demand on a network channel that provides 1Mbit of throughput.
  • the server 12 has only 300Kbit of throughput to service the second user.
  • the client may need to preload a greater number of blocks into cache prior to the title starting in order to preserve the quality of play.
  • a second access method may be deployed by the client under these network conditions to request further blocks from the server, not on demand, after the title is running on the client predicting future needs of the title for data and executable.
  • the system 10 of Figure 1 provides a plurality of load maps 24, where the load maps 24 provide a delivery schedule and access methods that is adapted to support delivery of title content for the associated network characteristics and throughput in a manner that achieves a user experience for the running title that is similar or identical to the user experience the user would have if the title were running locally.
  • the load maps 24 contain information that the load map readers 52 on the client 14 can use to request blocks from the server 12 with a schedule and method that should make blocks available from cache before the running title 48 needs them, thus providing a user experience that is identical or similar to the user experience the user would have if the title were stored locally.
  • load maps like load map 24, work in conjunction with the local cache. If a request is made for data and it is not in the cache it goes directly to RAFT server. Thus, as the timeliness by which blocks may be transferred across the data network turns on the available network throughput and characteristics, a separate load map 24 may be generated for each network environment employed by users.
  • each title can have three separate load maps, each providing a schedule and method of access suited for a respective one of the three bandwidths.
  • the load maps 24 may describe the content access patterns of the titles 22, parameterized typically by time, by access history and by runtime state of title. Additionally load maps may contain the access methods to be deployed by for a given access pattern and runtime title state.
  • the load maps 24 cooperate with associated load map readers 52, to provide vehicles for distributing information about title behavior and state, in terms of accessing blocks within the briq, to the client- 14.
  • the load maps 24 contain data and the load map readers 52 contain executable code to interpret the information of the load maps.
  • the load map readers 52 monitoring the running titles briq network utilization, and operating on the data in the load map 24, perform the client cache transactions for sustaining the title experience when client bandwidth is limited. Typically, the process the load map readers 52 employ are .
  • Load maps in the embodiment of Figure 1 are stored in load map containers.
  • Each load map container 80 is associated with one briq.
  • a load map container 80 contains one or more load maps 82.
  • Each title in the briq 22 is associated with a set of load maps 82 within the container 80.
  • Each load map 82 in the set is associated with a Network Metric Descriptor 84.
  • the client 14 when choosing a load map 82 for a title session, the client 14 locates the load map container 80 for the title's briq 22, locates a title load map directory within the load map container 80, and selects the load map 82 within this directory which is associated with the Network Metric Descriptor 84 closest to the network environment in which the title session is to take place. Typically, the client 14 compares the available network throughput and characteristics with information within the Network Metric Descriptor 84, and makes the selection based on this comparison.
  • Each load map 82 may contain some or all of the following information stored in different fields within the container 80: cache replacement information 88; preload information 90; and predictive loading information 92.
  • Cache replacement information 88 can comprise information which is used by the client 14 when storing incoming data in the client's cache. This information can include, for example, the cache replacement algorithm to use, e.g., Least Recently Used (LRU), priority cache list or some other suitable algorithm for determining what information to keep in the cache. The information can also include the amount of cache space to be allocated exclusively for the title; and the relative caching priority of each briq block, used by the cache replacement algorithm when the subject block is considered for insertion into the cache.
  • LRU Least Recently Used
  • the preload information may contain a list of briq blocks, which are to be present in the client's cache before the title's executable is launched. Typically, the faster the network throughput, the smaller the number of blocks that need to be preloaded into cache prior to the title starting execution. In either case, those blocks that need to be preloaded may be stored in the field 90 as an ordered list.
  • the load map 82 may optionally contain predictive loading information in field 92. This information may be used by the load map reader 52 to fetch briq content while the title is running, even though the title 48 has not yet accessed them. This information may include one or more of the following: An ordered list of briq blocks to be fetched, without considering the progress of a particular title session. The client 14 is to fetch blocks on this list, in the given order, during periods when the running title's network activity permits,. This list is known as a postload list.
  • the field 92 may contain a tree structure of sets of briq blocks, each set potentially associated with multitude of branching secondary sets. If the client detects that the blocks in one of the first sets are fetched by the title, then the blocks in the second set are to be loaded based on the probability access.
  • This list is known as the Probabilistic loading List, and this is the type of list depicted in Figure 2.
  • the data structures associated with the Probabilistic loading technology is a structure of sets of data. Each of these sets contains the following elements: Event definition: A set of triggering events that would cause the cache manager 40 to signal the map reader to continue with its probabilistic post loading. The cache manager 40 may pass to the map reader 52 event information such that the map reader 52 could along with its current state determine which target set of blocks from the tree would be loaded next.
  • Target set An ordered list of blocks in the briq, which are likely to be required by the title in the near future.
  • Probability of correctness The probability that, if the event is detected, the target set of blocks would be required by the running title. This is used when considering a plurality of events and choosing between them.
  • Longevity of prediction The span of title activity (quantified in title briq accesses and/or in wall clock time), which the prediction claims to cover. After this span is exhausted (the title has performed this many briq accesses, or that much time has passed, since the putative event), the prediction is pronounced stale and would be ignored.
  • the load map 24 contains information that the lad map reader may employ for downloading blocks from the briq in a manner that maintains the desired user experience.
  • FIG. 3 one example of how a load map 24 may be employed for delivering content more efficiently over a network is depicted.
  • Figure 3 depicts the load demand for a title over a period of time T. .
  • the available bandwidth is noted by the horizontal line BW, and for the depicted example the bandwidth is 768K.
  • the load demand for the title sometimes rises above the available bandwidth.
  • These peak times are shown to as having dashed lines extending through the peaks (1', 2', 3').
  • the load map 24 may be employed to schedule delivery of blocks of the title during those times of excess bandwidth, and to employ those times to deliver data into a cache on the client. This is shown in Figure 3 by the reversed peaks (1,2 3) that represent the delivery of blocks that are predicted to be needed in the future. This preloaded and postloaded data may then be accessed by the executing title, without requiring the system to employ the network.
  • the activity of the map reader to request data to be delivered over the network during times of excess capacity turns in part on the map reader's analysis of the load map.
  • the load map may include a decision tree and access methods that sets out an outline for possible file access patterns for the title given certain operating conditions.
  • the decision tree may be employed by the map reader to generate data requests to the RAFT server.
  • the Profiler 28 component is the primary piece of the title preparation process. It observes the execution of a title 30 and creates one or more load maps 24 based on analysis of the title's disk access patterns and selected network o characteristics. The process employed by the profiler 28 can depend upon the application. Typically, the profiler 28 monitors the access patterns of a title as a user employs the title. Additionally the profiler can receive and use title access patterns from remote users that accessing a deployed system. The profiler 28 can build a log of these access. Given some useful patterns, possible profiling and map reading algorithms can be tested and validated by simulation. Then the appropriate components can be developed to support each map type.
  • load maps 24 will be comparatively small and are likely to be updated much more often than the title content. Load maps will need a version link to their corresponding briq so that RAFT server 20 data synchronization is not a problem. Logistical (distribution) issues could force load maps to become physically part of a briq, but such as change is within the skill of the ordinary artisan..
  • the load map format and map reader algorithms may vary according to application, and based on factors such as time, action within title, disk access, and quality of runtime experience (freezes), and statistical analysis may be employed to find patterns.
  • the two components which have direct knowledge of title delivery bandwidth are the RAFT server 20 and the cache manager 40 of the client 14. Each should track bandwidth and be queryable by the Dispatcher or Player/store front so that the customer can be presented with appropriate choices and estimates of delivery time. In addition to the Dispatcher 18 , it may also be desirable to have a daemon process that resides on the Client 14 which periodically measures bandwidth availability when the cache Manager 40 is idle. This would allow the Dispatcher to stay up-to-date with network conditions and be queryable directly by the server front end 16.
  • the depicted client 14 includes a web browser 32 having plug in 34 , a player 38, a cache manager 40, a plurality of title caches 42 a, b and c respectively, and a cache admin tool. As further shown the client 14 includes a running title 48, a plurality of map readers 52 a, b and c respectively and a plurality of cached title load maps 54 a, b and c respectively.
  • the systems and methods described herein include systems and methods where multiple servers 12 are employed and where each server may support a plurality of client 14. For example, depending upon the application, the server 12 may support a thousand client systems 14.
  • the web browser may be any suitable web browsers, and typically comprises an HTML browser such as NetScape Navigator or Microsoft Explorer.
  • the browser is provided a plug-in
  • the Plug in allows the server front end 16 to communicate with the player: and to cause actions on the player side and to gather data such as version numbers, throughput measurements, and other information
  • the type of browser employed will depend upon the application, and in those applications where the device is unable to support a typical browser, a proprietary client application may be provided for exchanging data with the server 12.
  • the player 38 depicted in Figure 1 may be implemented as a Windows application containing logic which coordinates communication between the client 14 and the CAS 68.
  • the player 38 may be invoked by the client's browser 32, and may include a library which may be implemented as a series of objects or program code which generate and receive communications to/from the CAS server 68 through a remote procedure call (RPC) library.
  • RPC remote procedure call
  • the player 38 may also include a process for moving data across the network and for measuring available network resources and characteristics including throughput, bandwidth, latency, buffer capacity and other parameters. Additionally, the player is capable of processing information provided by the server 12 to determine for a title of interest to the user, which of the plurality of available load maps for that title should be employed.
  • GUI graphic user interface
  • the user interface includes the appropriate program logic and/or objects necessary to interface with the operating system and application program (APIs) contained within the Windows or other operating systems or environments in order to render windows, present graphic information within such windows, and receive commands from a user via a keyboard, mouse or other input devices, such user interface being well within the scope of those reasonably skilled in the art:
  • APIs application program
  • the user may set user preferences, e.g., disk cache size, and be notified of error conditions.
  • the player 38 can launch a title and continue communications between the client 14 and the CAS 68 and the RAFT server 20.
  • the depicted Player 38 is also an intermediary between the CAS and the cache manager.
  • the player 38 locates the BSP's Dispatcher service 18 and queries it for information about a suitable RAFT server; tells the cache manager 40 which RAFT connection to make; provides the RAFT title or content access keys from the CAS to the cache manager 40, and refreshes them with the CAS 68 as needed, configures the appropriate map reader 52a,b,c with network information, such as bandwidth and delay mode information; and starts/stops the application as needed.
  • the player's 38 interaction with the Dispatcher 18 may optionally include a bandwidth test. Also, the player 38 can launch the cache Admin, tool to manage local cache space if forced to do so by the requirements of new content, or by user's choice.
  • the depicted cache manager 40 maintains one or more local disk caches. '
  • Each cache may be associated with a specific body of content.
  • the cache manager 40 responds to requests from the player 38, which configures it to connect with a specific RAFT server 20, briq 22, and load map 24.
  • the cache manager 40 may also respond to the map reader 52a,b,c, which makes anticipatory load requests that are driven by the title's load map 54a,b,c and current execution state.
  • the cache manager 40 provides a block directly from the local disk when it is available, and makes a request of the RAFT server 20 for blocks it does not have a local copy of yet.
  • the algorithm by which the cache is managed can be simple LRU optionally, may also encode and use load map information that preserves critical cache data which may not be accessed frequently by the title.
  • the profiling process will determine substantially optimum cache size for each title, and possibly for each bandwidth tier in which title may execute.
  • the cache manager 40 also records the load state of the cache, which means that it knows which blocks are in cache. This information allows the map reader request that are not in cache to access the content server 20 and allows the player 38 to determine whether the title should be allowed to run or not.
  • the cache admin tool 44 provides a GUI which allows administration of local caches by the end user. It shows how much disk space is taken up by each title and allows the user to dispose of cache blocks for titles that are no longer needed. The user can start this tool manually or it may be run by the player 38 when reconfiguration of cache space is necessary.
  • the depicted map reader 52a,b,c interprets a profiler- generated, title-specific load map 54a,b,c that has been downloaded from the server 12 to the client 14.
  • the load map 54a,b,c describes the content access patterns of the title application, parameterized by time and by access history.
  • the map reader 52a,b,c uses a load map 54a,b,c to create cache pre-load requests which are meant to anticipate the disk accesses of the title application.
  • a proper load map allows a running title to be available as soon as possible and avoids title freezes during execution. To do this, the map reader 52a,b,c uses the profiler load map data to "lead" the title accesses by a time delta which will be variable during execution.
  • Figure 1 depicts a block diagram that shows the different elements of one embodiment of the invention, which embodiment comprises a system for delivering content over a data network to support execution of a program at a remote location.
  • the server 12 and the client 14 cooperate to deliver portions of executable code over the data network in a manner that allows a user operating the client PC, or some other remote device, to execute the program on the remote device in a manner that provides for the same, or substantially same, user experience that the user would have if the executable code was part of a program that was stored locally and accessed by the client device.
  • the system 10 is capable of providing a server system that any client can access for the purpose of downloading a program, or title, that the user is interested in rum ing.
  • the server 12 includes a front-end 60 that comprises a web storefront 62, an e-commerce server 64 and a conditional access server 68.
  • the front-end 60 therefore provides an electronic storefront that may broker a transaction for allowing a user to purchase access to a title stored on, or otherwise accessible to, the server 12. Operation of the Depicted System 10
  • users may select a title to run from a virtual storefront provided by the storefront system 16, which contains a virtual catalog of available titles.
  • the user negotiates for an actual purchase of the title.
  • Negotiation may include user registration with a third party, electronic commerce system, provision of user billing information, and selection of one of the purchase types offered with the selected title. Examples of possible purchase types may include a time-limited demo of the title, a single payment for a single use" of a title, a single payment which allows unlimited "uses" of a title over some specified time period e.g., week, month, etc.
  • the server 12 includes the front-end 60 that provides the above-described electronic storefront.
  • the navigational server may be removed from the systems and methods described herein.
  • the particular embodiment of Figure 1 shows the front-end server 60 as including a transactional e-commerce server 64.
  • the transactional e-commerce server 64 may comprise a server system integrated into the Server 12, or, in alternate embodiments, may be supported by a third-party service provider such that the e-commerce server 64 may be located at a remote location and not integrated into the front-end 60.
  • Other elements shown in the front-end 60 including the web storefront may also, in whole or in part, be supplied or supported by third-party systems that are accessed, but remote from, the front-end 60.
  • the user would negotiate a transaction to receive access to the title of interest.
  • client software running on the user's PC obtains an authorization token and keying material from the Conditional Access Server (CAS) 68.
  • the token authorizes the client 14 to run the selected title from the file server 12 across the network.
  • the data retrieved from the file server 12 is encrypted.
  • the client 14 uses the keying material provided by the CAS 68 to decrypt the data from the file server 12.
  • the eCommerce server 64 generates a launch string, containing the information identifying and authorizing the purchase, including a Universal Resource Name (URN) uniquely identifying the desired title.
  • the launch string may be digitally signed by the CAS 68 and provided to the eCommerce server 64 for delivery to the client 14.
  • UPN Universal Resource Name
  • the launch string in one practice is wrapped with a MIME header.
  • the MIME type associated with the launch string is located in a registry entry, which results in the invocation of a player module 38 within the client 14.
  • the player module 38 establishes a secure RPC connection with the CAS 68 and requests that CAS provide a URL for the specified URN , i.e. a URN to URL conversion.
  • the URL identifies the location of the corresponding title data.
  • the CAS 68 forwards the corresponding URL to the player 38.
  • the player 38 sends a purchase request to the CAS 68, the purchase request including the Launch string.
  • a title is formatted into an electronic package that contains the title's files in a compressed and encrypted form, referred to as a briq.
  • the briq is a portable, self-contained file system, containing the data that makes up the files to be employed to run a particular title.
  • Briqs are stored on the file server 12, or a storage device or system accessible by the server 12 or to which the server 12 can refer the client 14.
  • the server that manages the titles is referred to hereafter as the RAFT server 20.
  • the client 14 treats the briq like a local file system on the user's computer.
  • the operating system e.g.
  • the client 14 which, in the illustrative embodiment, includes a cache manager 40, services these requests by retrieving the requested blocks of briq data from the RAFT server 20. After retrieving the requested block of data, cache manager 40 decompresses and decrypts the briq data, and passes the data onto the operating system on the user's computer.
  • the CAS 68 verifies the launch string's signature, and then returns a RAFT authorization token and activator to the player 38.
  • the authorization token may be actually embedded within the activator.
  • the player 38 launches the title by passing the activator to the cache manager 40.
  • Thecache manager 40 runs the activator and opens the URL and reads the header.
  • the cache manager 40 sends the initial authorization token to the RAFT Server 20.
  • the cache manager 40 starts reading content from RAFT server 20.
  • the cache manager 40 uses the activator to decrypt and decompress the content in the form of briq data, and perform integrity checking on the blocks of decrypted data.
  • the operating system executes the title, via the local file system presented by cache manager.
  • the activator requests the player 38 to ask the CAS 68 to refresh the activator and the RAFT authorization token.
  • the CAS 68 posts the purchase to the eCommerce server 64 for transaction settlement.
  • the lifetime of the first activator may be on the order of minutes. Successful activator refresh after the first timeout serves as an indication that the title is running successfully on the client 14.
  • the software title is never "installed” on the client 14.
  • the client 14 creates an installation abstraction, maintaining the illusion for the operating system that the title currently executing is installed on the host computer.
  • no files associated with the title are left on the computer's hard-drive, and no operating system state information e.g., registry variables associated with the title, remains.
  • users of titles have the option of saving certain, state information that would be desirable to maintain across plays; e.g., the "level” achieved in a game, etc. Such state information may be saved in write through file described hereinafter.
  • the client 14 uses the Random Access File Transport (RAFT) protocol to retrieve briq data across the network.
  • the protocol in one practice, may provide the client 14 with read-only access to files and directories stored on RAFT server 20. Because the briq is treated like a local file system, the RAFT client does not need to be visible as an operating system drive and does not need to interface with the operating system's file system manager, the Windows Installable File System (IFS) Manager in the illustrative embodiment. As a result, the RAFT client file system - driver, the cache manager 40 in the illustrative embodiment, is smaller and simpler than a remote or network file system driver.
  • IFS Windows Installable File System
  • the RAFT protocol supports dynamic bandwidth restrictions ,e.g., "bandwidth throttling", and access control through the use of RAFT authorization tokens.
  • the client 14 may employ a variety of security mechanisms to protect content from unauthorized access and replay.
  • Authorization tokens and decryption keys are obtained from a CAS 68.
  • Network communication between the client 14 and CAS 68 may be protected via a secure remote procedure call (RPC) interface.
  • RPC secure remote procedure call
  • the authorization token in one embodiment may be a signed message from the CAS 68 indicating that the requesting user can have access to a specified briq, on a specific RAFT file server 20, for the length of time spelled out in the negotiated payment type. While the RAFT authorization token gives a client 14 access to a title's briq, the client 14 in certain embodiments, is to unpack, e.g. decompress and decrypt, the briq to gain access to the title's file data. The CAS 68 provides the user with the keying material to decrypt briq data. In one practice, the CAS 68 does not directly provide the client 14 with keying material.
  • the CAS 68 may hide keying material from the user by embedding the keys in obfuscated bytecode that implements the decryption algoritlim. Rather than delivering isolated keying material to the client 14, the CAS 68 delivers obfuscated bytecode, referred to as an activator.
  • the client's cache manager 40 decrypts briq data by running the activator on a bytecode interpreter.
  • both the RAFT authentication tokens and activators may have a limited lifetime. For example, in certain embodiments, authorization tokens include an expiration time, after which they are no longer valid.
  • a running activator at a certain point, may initiate an exchange with the CAS 68 to refresh itself. If the exchange is unsuccessful, the activator becomes inoperable and the title inoperable. The refreshing of activators is referred to as activator keep alive.
  • the client systems can be any suitable computer system such as a PC workstation, a handheld computing device, a wireless communication device, or any other such device, equipped with a network client capable of accessing a network server and interacting with the server to exchange information with the server.
  • the network client is a web client, such as a web browser that can include the Netscape web browser, the Microsoft Internet explorer web browser, the Lynx web browser, or a proprietary web browser, or web client that allows the user to exchange data with a web server, and ftp server, a gopher server, or some other type of network server.
  • the servers may be supported by a commercially available server platform such as a Sun SparcTM system and running a server capable of connecting with, or exchanging data with, one of the subscriber systems, h the embodiment of Figure 1, the server includes a program for delivering content over a TCP/IP data network.
  • a commercially available server platform such as a Sun SparcTM system and running a server capable of connecting with, or exchanging data with, one of the subscriber systems, h the embodiment of Figure 1, the server includes a program for delivering content over a TCP/IP data network.
  • Such programs may be written using principles known in the art.
  • Figure 1 depicts the elements of the systems as functional block elements.
  • these elements can be realized as computer programs or portions of computer programs that are capable of running on the data processor platform to thereby configure the data processor as a system according to the invention.
  • the elements, such as the player and profiler can be realized as a software component operating on a conventional data processing system such as a Unix or Windows workstation.
  • these mechanisms can be implemented .as a C language computer program, or a computer program written in any high level language including C+ + , Fortran, Java or basic. General techniques for high level programming are known, and set forth in, for example, Stephen G. Kochan Programming in C, Hayden Publishing (1983).

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention porte sur des systèmes (10) et sur des procédés destinés, entre autre, à permettre l'accès d'un contenu tel que des données ou un programme exécutable à un utilisateur à distance (14), sur demande, à partir d'un serveur à distance. Une fois l'accès obtenu, le contenu peut être distribué sur demande à la station de travail à distance de l'utilisateur (14) en vue d'être utilisé par celui-ci. Du fait de la possibilité de variation des ressources du système, les systèmes de cette invention comprennent également des systèmes qui contrôlent les ressources du réseau, et d'autres facteurs, contre les demandes de transfert du contenu demandé par l'utilisateur. Les systèmes peuvent ensuite déterminer un programme ou une carte de chargement (24) en vue de transférer des blocs du contenu de façon à utiliser efficacement les ressources disponibles et de façon à assurer à l'utilisateur une expérience similaire ou pratiquement similaire à celle qu'il devrait avoir si le contenu était stocké localement sur la station de travail utilisateur.
PCT/US2001/028452 2000-09-11 2001-09-12 Systemes et procedes pour distribuer un contenu sur un reseau informatique Ceased WO2002023363A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001290796A AU2001290796A1 (en) 2000-09-11 2001-09-12 Systems and methods for delivering content over a computer network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US23199200P 2000-09-11 2000-09-11
US60/231,992 2000-09-11

Publications (1)

Publication Number Publication Date
WO2002023363A1 true WO2002023363A1 (fr) 2002-03-21

Family

ID=22871442

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/028452 Ceased WO2002023363A1 (fr) 2000-09-11 2001-09-12 Systemes et procedes pour distribuer un contenu sur un reseau informatique

Country Status (2)

Country Link
AU (1) AU2001290796A1 (fr)
WO (1) WO2002023363A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NL2000966C2 (nl) * 2007-10-29 2009-05-06 Bizzchannel B V Weergavesysteem en werkwijze voor narrowcasting in een computernetwerk.
WO2009087550A2 (fr) 2007-12-31 2009-07-16 Alcatel Lucent Procédé et appareil pour distribuer un contenu
US7680758B2 (en) 2004-09-30 2010-03-16 Citrix Systems, Inc. Method and apparatus for isolating execution of software applications
US7752600B2 (en) 2004-09-30 2010-07-06 Citrix Systems, Inc. Method and apparatus for providing file-type associations to multiple applications
US7853947B2 (en) 2004-09-30 2010-12-14 Citrix Systems, Inc. System for virtualizing access to named system objects using rule action associated with request
US8117559B2 (en) 2004-09-30 2012-02-14 Citrix Systems, Inc. Method and apparatus for virtualizing window information
US8171479B2 (en) 2004-09-30 2012-05-01 Citrix Systems, Inc. Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers
US9009721B2 (en) 2007-10-20 2015-04-14 Citrix Systems, Inc. Method and system for communicating between isolation environments
US9071526B2 (en) 2009-06-22 2015-06-30 Citrix Systems, Inc. Systems and methods for platform rate limiting
US9538141B2 (en) 2007-12-31 2017-01-03 Alcatel Lucent Method and apparatus for controlling presentation of content at a user terminal

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5793966A (en) * 1995-12-01 1998-08-11 Vermeer Technologies, Inc. Computer system and computer-implemented process for creation and maintenance of online services
US5832483A (en) * 1995-12-15 1998-11-03 Novell, Inc. Distributed control interface for managing the interoperability and concurrency of agents and resources in a real-time environment

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5793966A (en) * 1995-12-01 1998-08-11 Vermeer Technologies, Inc. Computer system and computer-implemented process for creation and maintenance of online services
US5832483A (en) * 1995-12-15 1998-11-03 Novell, Inc. Distributed control interface for managing the interoperability and concurrency of agents and resources in a real-time environment

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8117559B2 (en) 2004-09-30 2012-02-14 Citrix Systems, Inc. Method and apparatus for virtualizing window information
US8042120B2 (en) 2004-09-30 2011-10-18 Citrix Systems, Inc. Method and apparatus for moving processes between isolation environments
US7680758B2 (en) 2004-09-30 2010-03-16 Citrix Systems, Inc. Method and apparatus for isolating execution of software applications
US8171479B2 (en) 2004-09-30 2012-05-01 Citrix Systems, Inc. Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers
US7752600B2 (en) 2004-09-30 2010-07-06 Citrix Systems, Inc. Method and apparatus for providing file-type associations to multiple applications
US7853947B2 (en) 2004-09-30 2010-12-14 Citrix Systems, Inc. System for virtualizing access to named system objects using rule action associated with request
US9009721B2 (en) 2007-10-20 2015-04-14 Citrix Systems, Inc. Method and system for communicating between isolation environments
US9009720B2 (en) 2007-10-20 2015-04-14 Citrix Systems, Inc. Method and system for communicating between isolation environments
US9021494B2 (en) 2007-10-20 2015-04-28 Citrix Systems, Inc. Method and system for communicating between isolation environments
NL2000966C2 (nl) * 2007-10-29 2009-05-06 Bizzchannel B V Weergavesysteem en werkwijze voor narrowcasting in een computernetwerk.
JP2011508333A (ja) * 2007-12-31 2011-03-10 アルカテル−ルーセント コンテンツを配信するための方法および装置
WO2009087550A2 (fr) 2007-12-31 2009-07-16 Alcatel Lucent Procédé et appareil pour distribuer un contenu
WO2009087550A3 (fr) * 2007-12-31 2009-09-11 Alcatel Lucent Procédé et appareil pour distribuer un contenu
CN101911687B (zh) * 2007-12-31 2015-07-22 阿尔卡特朗讯公司 用于分发内容的方法和装置
US9538141B2 (en) 2007-12-31 2017-01-03 Alcatel Lucent Method and apparatus for controlling presentation of content at a user terminal
US10560663B2 (en) 2007-12-31 2020-02-11 Alcatel Lucent Method and apparatus for distributing content
US11134219B2 (en) 2007-12-31 2021-09-28 Alcatel Lucent Method and apparatus for distributing content
EP3982639A1 (fr) * 2007-12-31 2022-04-13 Alcatel Lucent Procédé et appareil pour distribuer un contenu
US9071526B2 (en) 2009-06-22 2015-06-30 Citrix Systems, Inc. Systems and methods for platform rate limiting

Also Published As

Publication number Publication date
AU2001290796A1 (en) 2002-03-26

Similar Documents

Publication Publication Date Title
US7225264B2 (en) Systems and methods for delivering content over a computer network
US8539038B2 (en) Method and system for preloading resources
US6374402B1 (en) Method and apparatus for installation abstraction in a secure content delivery system
US7017188B1 (en) Method and apparatus for secure content delivery over broadband access networks
US6763370B1 (en) Method and apparatus for content protection in a secure content delivery system
US6226739B1 (en) Method and computer program for distributing software to a personal palm-type device through a global software distribution package transmittable over the world wide web
EP1530863B1 (fr) Système de fourniture et de présentation dynamique de contenus multimédia de grande taille sur des réseaux à bande passante limitée
US7178143B2 (en) Multi-version hosting of application services
US20030084439A1 (en) Incentive system for distributing software over a computer network
US20100235473A1 (en) System and method of embedding second content in first content
US7342928B2 (en) Method and system for accessing a peer-to-peer network
US20030187929A1 (en) Multi-version hosting of application services
US8205001B1 (en) Digital rights management integrated service solution
CA2351078C (fr) Procede et appareil pour assurer la fourniture d'un contenu sur des reseaux d'acces a large bande
EP1531398A1 (fr) Dispositif de terminal, serveur d'approvisionnement, procede d'utilisation d'informations electroniques, procede d'approvisionnement d'informations electroniques, programme de dispositif de terminal, programme de serveur d'approvisionnement et programme intermediaire et support d'enregistrement
US20030037107A1 (en) Application distribution system, and distribution server and distribution method thereof
US20040158582A1 (en) Method and apparatus for synchronously transferring data from a local storage medium to a remote storage medium, and method and system for managing transfer of data from a source storage medium to a repository storage medium
WO2002023363A1 (fr) Systemes et procedes pour distribuer un contenu sur un reseau informatique
JP5005527B2 (ja) ストレージシステム及びストレージシステムにおけるデータ管理方法
US20090094346A1 (en) Method and System for Retrieval and Usage of Remote Entry Points
US8515773B2 (en) System and method for enabling distribution and brokering of content information
WO2007076557A1 (fr) Apport de contenu multimedia souscrit par abonnement a des dispositifs de lecture multimedia portatifs associes a des abonnes
Mittapally Mobile Workforce--Amway
HK1068702A1 (zh) 用户应用程序的控制方法
HK1068702B (en) Method of controlling user application program

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP KR

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION PURSUANT TO RULE 69 EPC (EPO FORM 1205A OF 240703)

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

Ref country code: JP