Pre-storing blocks for a streamed application in a local cache on a host computer system

A streamed application includes a plurality of application blocks. A first subset of the plurality of application blocks is pre-stored in a cache on a host computer system prior to initiating execution of the streamed application. The streamed application may then be executed. One or more application blocks of the first subset of the plurality of application blocks may be retrieved from the cache during execution of the streamed application in response to one or more requests to access the one or more application blocks of the first subset. A second subset of the plurality of application blocks may be received from a server computer system during the execution of the streamed application and may be stored in the cache. The second subset may include one or more application blocks that were not stored in the cache when the streamed application was installed.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of computer software. More particularly, the invention relates to the field of streamed applications, e.g., an application which executes on a host computer system, where executable code blocks for the application are dynamically streamed to the host computer system from a server computer system during execution of the application.

2. Description of the Related Art

The Internet is a rapidly growing network of interconnected computers from which users and applications can access a wide variety of resources. Initial widespread use of the Internet was limited to the delivery of static information. A newly developing area of functionality is the delivery and execution of complex software applications via the Internet.

One technique for delivering a software application to a host computer is to first download the entire application to the host computer from a server computer via the Internet, and then install and execute the software application on the host computer. However, the download time can be prohibitively long for large applications, resulting in a long wait between the time when the download begins and the time when the software application begins local execution.

More recently, streaming technology has been used to stream the executable code for a software application from a server computer to a host computer in such a way that allows the application to begin execution on the host computer before all of the executable code for the application has been delivered to the local host computer. Such a software application is referred to as a “streamed application”. For example, the server computer may first stream one or more startup blocks which include just enough executable code for the streamed application to be launched on the host computer. Upon receiving the startup blocks, the host computer may execute the startup blocks to launch the streamed application. Further blocks of executable code for the streamed application may then be dynamically streamed to the host computer from the server computer while the streamed application is executing.

SUMMARY

Various embodiments of a system and method for installing and executing a streamed application on a host computer system are described herein. The streamed application may include a plurality of application blocks. The application blocks may include the executable code for the streamed application, as well as possibly other data of the streamed application. According to some embodiments of the method, a first subset of the plurality of application blocks may be pre-stored on a first storage device of the host computer system prior to initiating execution of the streamed application on the host computer system. For example, in some embodiments the first subset of the plurality of application blocks may be stored in a cache on the first storage device during an installation of the streamed application on the host computer system.

The method may further comprise initiating execution of the streamed application on the host computer system after the first subset of the plurality of application blocks has been stored on the first storage device. During the execution of the streamed application, one or more requests to access one or more application blocks of the first subset of the plurality of application blocks may be received. The one or more application blocks may be retrieved from the first storage device in response to the one or more requests.

In some embodiments the method may further comprise receiving a second subset of the plurality of application blocks from a server computer system during the execution of the streamed application. In some embodiments the second subset of the plurality of application blocks may be stored on the first storage device after being received from the server computer system. For example, the second subset of the plurality of application blocks may be stored in the cache on the first storage device along with the first subset of the plurality of application blocks.

DETAILED DESCRIPTION

Various embodiments of a system and method for installing and executing a streamed application on a host computer system are described herein. The streamed application may include a plurality of application blocks. The application blocks may include the executable code for the streamed application, as well as possibly other data of the streamed application. According to some embodiments of the method, a subset of the plurality of application blocks may be pre-stored on a storage device of the host computer system prior to initiating execution of the streamed application on the host computer system. For example, in some embodiments the first subset of the plurality of application blocks may be stored in a cache on the first storage device during an installation of the streamed application on the host computer system.

When the application is subsequently executed, executable code blocks or other application blocks that were pre-cached may be retrieved from the local cache as they are needed, thus avoiding the need to download these blocks from a remote server computer system. When other application blocks (e.g., other executable code blocks or data blocks) that were not pre-cached are needed, streamed application management software on the host computer system may dynamically request and receive these blocks from the remote server computer system.

In some embodiments each of the application blocks may be equally sized. In various embodiments the block size may be any size. In some embodiments the block size may be the same size as a page size used by the operating system when reading file data from a disk drive of the host computer system in response to page faults. For example, some Windows™ operating systems use a page size of 4 kb. Thus, if the streamed application executes on a Windows™ host computer system then the application blocks of the streamed application may have a size of 4 kb each.

FIG. 1illustrates one embodiment of the system. The system includes a host computer system82on which the streamed application is to be executed. The system may also include an installation medium9. The installation medium9stores information for installing the streamed application on the host computer system82, such as an installation program50, application blocks17(the subset of application blocks to be pre-cached), mapping information35, and metadata37for the streamed application.

The application blocks17may be stored on the installation medium9in one or more files or databases. The mapping information35may map each of the blocks17to a file of the streamed application and a location within the file, as described in detail below. The metadata37includes information about the streamed application which is used by the installation program50to install the streamed application on the host computer system82. For example, the metadata37may include information indicating which files are included in the streamed application, the sizes of the files and their file system layout, registry entries for the streamed application, installation scripts, etc.

FIG. 2is a flowchart diagram illustrating one embodiment of a method for installing the streamed application on the host computer system82. In this embodiment, the installation program50may first be launched, as indicated in301. For example, in some embodiments the installation medium9may be a CD-ROM, and the user may launch the installation program50by inserting the CD-ROM in a CD-ROM drive of the host computer system82. Inserting the CD-ROM may cause the installation program50to launch automatically, or the user may browse to the installation program50in a file browser and request the installation program50to be launched. In other embodiments the installation program50may be stored in a location other than the installation medium9, such as on a disk drive of the computer system82.

In other embodiments the installation medium9may be in any of various forms other than a CD-ROM. For example, the installation medium9may be another type of optical disc or medium, such as a DVD for example. As another example, the installation medium9may be a flash memory device, e.g., where the flash memory device may be connected to the host computer system82through a USB port or other port of the host computer system82. As another example, in some embodiments the installation medium9may be a hard disk or other storage medium of the host computer system82. For example, in some embodiments the information illustrated inFIG. 1which is stored on the installation medium9may be copied to the hard disk of the host computer system82from a server computer system. In yet other embodiments the installation medium9may be a medium of a network storage device with which the host computer system82communicates via a network. In general, the installation medium9may be any kind of storage medium and may be coupled to the host computer system82in any of various ways.

The installation program50may execute to install the streamed application on the host computer system82, e.g., by configuring the host computer system82so that it is able to execute the streamed application. In various embodiments the installation program50may configure the host computer system82in any of various ways during the installation, e.g., depending on the operating system used by the host computer system82. For example, as indicated in302, in some embodiments installing the streamed application may include configuring registry entries, configuring operating system icons and menus for launching the streamed application in response to user input, etc., as indicated in302. The metadata37stored on the installation medium9may include information enabling the installation program50to perform these operations.

As noted above, the metadata37stored on the installation medium9may also include information indicating which files are included in the streamed application, and the sizes of the files and their appropriate file system layout. In302the installation program may use this information to configure file system metadata for the files of the streamed application. For example, the installation program may create file system metadata structures for the files of the streamed application so that it appears to the operating system that the files are fully present on the host computer system82and layed out as indicated by the metadata37. However, the files may be empty, e.g., such that the actual data for the files is not stored within the files. As described below, streamed application management software may execute to intercept and handle requests to access the files of the streamed application when the streamed application is subsequently executed.

As indicated in303, the installation program may also read the blocks17from the installation medium9and store them in the cache33. The cache33is a storage area on a storage device which is accessible to the host computer system82. For example, in some embodiments the cache33may be stored on a disk drive of the host computer system82. In other embodiments the cache33may be stored on any of various other types of storage devices included in or accessible by the host computer system82. The storage device on which the cache33is stored is preferably either a local storage device (e.g., coupled to the host computer system82via a communication bus or port), or otherwise coupled to the host computer system82through a fast network so that the host computer system82can quickly and reliably access data on the storage device, e.g., without a long network latency.

As indicated in305, the installation program may also store mapping information on the host computer system82, where the mapping information maps each of the blocks17to a file of the streamed application and a location within the file. In some embodiments the mapping information may be copied from the installation medium9to the disk drive or other storage device of the host computer system82.

As described below, streamed application management software is used during the execution of the streamed application, and in some embodiments may also be used during the installation of the streamed application. In some embodiments, installing the streamed application may also include installing the streamed application management software on the host computer system82if the streamed application management software is not already installed.

FIG. 3illustrates an example of the host computer system82in more detail according to one embodiment. It is noted thatFIG. 3is provided as an example, and in other embodiments the host computer system82may be implemented in various other ways. In some embodiments the host computer system82may comprise a computer such as a personal computer system (PC), workstation, portable computer (e.g., laptop or notebook), personal digital assistant (PDA), television system, or other computing device or combination of devices.

In the illustrated example, the host computer system82includes one or more processors120coupled to memory122. In some embodiments, the memory122may include one or more forms of random access memory (RAM) such as dynamic RAM (DRAM) or synchronous DRAM (SDRAM). However, in other embodiments, the memory122may include any other type of memory instead or in addition.

The memory122may be configured to store program instructions and/or other data. In particular, the memory122may store the installation program50, e.g., where the installation program50is read into the memory122from the installation medium9or from another location. The installation program50may be executed by the processor(s)120to install the streamed application, as described above. In some embodiments the memory122may also store streamed application management software102. In some embodiments the streamed application management software102may execute in conjunction with the installation program50to install the streamed application, e.g., as described below. The streamed application management software102may also execute during the execution of the streamed application to handle requests to access the files of the streamed application, as discussed below. The memory122may also store various other software which executes in conjunction with the installation program50when installing the streamed application, such as operating system software, file system software, network communication software, etc.

Referring again toFIG. 3, it is noted that the processor120is representative of any type of processor. For example, in some embodiments the processor120may be compatible with the x86 architecture, while in other embodiments the processor120may be compatible with the SPARC™ family of processors. Also, in some embodiments the host computer system82may include multiple processors120.

In the illustrated embodiment, the cache33is stored on a disk drive125of the host computer system82. The disk drive125may be implemented as one or more hard disks configured independently or as part of a disk storage system. For example, in some embodiments the disk storage system may be a redundant array of inexpensive disks (RAID) system. In other embodiments, the disk storage system may be a disk array, or Just a Bunch Of Disks (JBOD), (used to refer to disks that are not configured according to RAID). The disk drive125may be included in or coupled to the host computer system82in any of various ways, such as direct attached storage, fibre channel storage, storage area network (SAN) storage, iSCSI storage, etc. In other embodiments the cache33may be stored on any of various types of storage devices other than a disk drive, such as a tape drive, optical storage device, flash memory device, or RAM disk, for example.

In the illustrated embodiment, the installation medium9is a CD-ROM accessible through a CD-ROM device131. However, as noted above, in other embodiments the installation medium9may take on various other forms.

The host computer system82may also include one or more input devices126for receiving user input. The input device(s)126may include any of various types of input devices, such as keyboards, keypads, microphones, or pointing devices (e.g., a mouse or trackball).

The host computer system82may also include one or more output devices128for displaying output. The output device(s)128may include any of various types of output devices or display devices, such as LCD screens or monitors, CRT monitors, etc.

The host computer system82may also include network connection hardware129. The host computer system82may couple through a network to a streaming server computer system using the network connection hardware129. The network may include any type or combination of local area network (LAN), a wide area network (WAN), wireless networks, an Intranet, the Internet, etc. Examples of local area networks include Ethernet networks, Fibre Channel networks, Fiber Distributed Data Interface (FDDI) networks, and token ring networks. Also, the host computer system82may be coupled to the network using any type of wired or wireless connection medium. For example, wired mediums may include Ethernet, fiber channel, a modem connected to plain old telephone service (POTS), etc. Wireless connection mediums may include a wireless connection using a wireless communication protocol such as IEEE 802.11 (wireless Ethernet), a modem link through a cellular service, a satellite link, etc.

FIG. 4is a diagram illustrating execution of the streamed application after it has been installed on the host computer system82. As discussed above, the installation program50may create metadata for the files of the streamed application so that it appears to the operating system that the files are fully present on the host computer system82, but the actual file data may not be present. When the streamed application is executed the operating system may attempt to read the executable code for the streamed application from the application files. The streamed application management software is configured to intercept the requests to read pages from the application files of the streamed application. As noted above, the application blocks for the streamed application may have the same size as the page size used by the operating system. Thus, each block may correspond to a page in one of the application files.

When the streamed application management software intercepts a request to read a particular application file page, the streamed application management software may check to determine whether the block corresponding to the application file page is already present in the cache33on the host computer system82. The streamed application management software may use the mapping information to determine whether the block is present in the cache33. If the block is present then the streamed application management software may retrieve the corresponding block from the cache33and return the block to the operating system, thus satisfying the read request. The block may then be executed or otherwise used by the streamed application.

Otherwise, if the corresponding block is not present in the cache33then the streamed application management software may communicate through the network16to retrieve the block from the streaming server computer system84. Once the block has been received from the streaming server computer system84, the block may be returned to the operating system to satisfy the read request. The streamed application management software may also add the block to the cache33so that the block can be retrieved from the cache locally in response to future requests for the corresponding application file page without having to retrieve the block from the remote streaming server computer system84again. The streamed application management software may also update the mapping information on the host computer system82to indicate that the block is now stored in the cache33and to indicate a block identifier or other information useable to retrieve the block from the cache33.

Thus, the blocks17that were pre-stored in the cache33during the installation of the streamed application may be retrieved locally from the cache33when the application file pages corresponding to these blocks are needed by the operating system during the execution of the streamed application. As illustrated inFIG. 4, other blocks18that were not pre-stored in the cache33during the installation of the streamed application may be dynamically retrieved from the streaming server computer system84when the application file pages corresponding to these blocks are needed during the execution of the streamed application.

For some applications it is likely that large portions of code and data may never need to be accessed. Thus, some of the application blocks for the streamed application may not be pre-cached during the installation. This may enable the streamed application to be installed in significantly less time than if all of the code and data for the streamed application were completely installed on the host computer system during the installation. If any of the blocks that were not pre-cached are ever needed, these blocks can be dynamically retrieved from the streaming server computer system84during execution of the streamed application.

In some embodiment the blocks17that are pre-cached on the host computer system82during the installation may include one or more startup blocks necessary to begin executing the streamed application. Thus, the host computer system82may be able to immediately begin executing the streamed application without waiting for the startup blocks to be streamed from the server computer system84. In some embodiments the pre-cached blocks17may also include executable code blocks that implement commonly used functionality or features of the streamed application. Thus, in some embodiments the execution efficiency of the streamed application may be increased by pre-caching executable code blocks that are likely to be needed during the execution of the streamed application so that these blocks do not need to be streamed to the host computer system82from the streaming server computer system84.

Pre-caching the startup blocks, commonly used blocks, or other blocks of the streamed application during the installation of the streamed application may thus increase the execution efficiency of the streamed application in some embodiments. This may be particularly useful for host computer systems with slow or intermittent network connections.

In other embodiments all of the blocks of the streamed application may be pre-cached on the host computer system82during the installation so that none of the blocks need to be retrieved from the streaming server computer system84. Although all of the blocks may be pre-cached during the installation, the streamed application may still be managed by the streamed application management software. For example, the streamed application management software may provide various management features, such as licensing features. For example, although the application code may not need to be downloaded from the streaming server computer system84, the streamed application management software may still contact the streaming server computer system84, e.g., to verify that the user of the host computer system82has a valid license to use the streamed application, or to verify that a time limit for the use of the streamed application has not expired.

FIG. 5is a block diagram showing a high-level architecture of the host computer system82and the streaming server computer system84according to one embodiment. As shown, the streaming server computer system84may include streaming server software12that accesses one or more databases which store information used to manage the application streaming. In some embodiments, the streaming server software12may access an application library171which contains blocks for the streamed application. In some embodiments the streaming server software12may also access a predictive data model172which contains information about the usage patterns of the streamed application, e.g., the probability that the application will require a given block depending on the previous blocks that were accessed. A user database173may also be provided for storing various user-specific information for use in authorizing access to the streamed application, storing information related to streaming order, etc.

The host computer system82may include an operating system140which can access a variety of local system resources142, such as data storage devices and memory. Streamed application management software102is also provided. The streamed application management software102may be configured to initiate the execution of the streamed application100, request specific blocks from the streaming server84when necessary, process received blocks, and make blocks available for use by the streamed application in a manner which is generally transparent to the native operating system140.

FIG. 6is a more detailed block diagram of the host computer system82showing various modules of the streamed application management software102according to one embodiment. The operating system140may access various storage devices190of the host computer system82, such as a removable disk, a hard drive, and a CD-ROM drive. Each storage device190typically has an associated device driver180which acts as an interface between the standard I/O protocols used by the operating system140and the specific I/O protocols used by the given device190.

In some embodiments, the cache33may be implemented in a virtual file system (VFS)160, such as illustrated inFIG. 6. The VFS160is provided to store and organize received application blocks and present an appearance to the operating system140that all of the application files are locally present. The VFS160may reside on a local storage device, such as a hard drive of the host computer system82. Some or all of the VFS160can alternatively be retained in system memory. A streaming file system device driver (“FSD”)150is provided to act as an interface between the operating system140and the VFS160. The VFS160, through the FSD driver150, is configured to appear to the operating system as a local virtual file system which can be accessed by the operating system in the same manner as other data storage devices190. When the streamed application is launched, it is configured to indicate the VFS160as the source for application files. Thus, from the operating system point of view, the application appears to be present on a local drive. However, unlike a conventional local file system190, such as a hard disk or CD-ROM accessed through a conventional device driver180, the VFS160does not need to (and generally will not) contain complete copies of the various application files of the streamed application. Instead, only those blocks of the various application files that were pre-cached during the installation or that were previously received from the streaming server84during previous executions of the streamed application are present. The blocks representing the executable code or data for some files may be missing altogether, and the blocks for other files may be only partially present.

In addition to the VFS160and FSD driver150, the streamed application management software102may also include an application manager110and a communication driver170. In some embodiments the application manager may register the streamed application with the VFS160and/or FSD150to limit access to the blocks of the streamed application as a way of preventing a user from extracting application data from the VFS160without authorization. The application manager110may be further configured to monitor and meter the usage of the streamed application, to indicate the application status to the end user, and perform or initiate cleanup functions when the streamed application is terminated. The communication driver170is configured to process blocks streamed to the host computer system82from the streaming server84and to issue requests to the streaming server84for blocks needed by the VFS.

When the application manager110is started, it is provided with information that identifies the streamed application to execute and also indicates which block or blocks of the application are required for initial execution. This information can be passed to the application manager110as startup parameters or can be fetched from the streaming server84. When first starting an application, the application manager110may check the VFS160to determine if the startup blocks for the application are already present, as may be the case if they were pre-cached during the installation or if the user previously executed the streaming application. If the required startup blocks are present, the application manager110instructs the operating system using standard operating system procedures to load and run the application from the VFS160. If the required startup blocks are not present, a fetch request will be issued to the streaming server84to retrieve them. Once retrieved from the streaming server84, the startup blocks may be stored in the VFS160, and may be executed.

The VFS160appears to the operating system as a drive which contains the application files. While information about the folder structure and file structure of the streaming application is available, the actual data of the files may or may not be present in the VFS160. When the application is started, the operating system may attempt to load the initial application executable file and possibly additional library files, such as DLLs. Many conventional operating systems, such as the various Windows™ operating systems from Microsoft Corporation, use memory mapped file mechanisms. This functionality allows a portion of a file to be loaded into memory and the remaining aspects of the file to be represented as missing code pages. As the loaded executable or DLL is processed, the operating system issues a series of page faults or similar input requests to dynamically load additional needed portions of the file into memory.

The specific mechanisms for dynamically loading sections of an application file or library vary in accordance with the operating system at issue and will be known to those skilled in the art. For example, in a Windows™ operating environment, the LoadLibrary API can be called from an application to have the operating system load a DLL. In response, the header of the DLL is read and loaded into memory. The remainder of the DLL itself is loaded using a memory mapped file mechanism which represents the additional portions of the DLL as a series of absent pages or code blocks for the various functions defined in the DLL. The additional parts will be loaded dynamically through fault conditions as functions are called from the DLL. In particular, using the DLL header information, when the operating system detects that an unloaded function of a DLL is required, a data read operation is issued to load the needed portion of the DLL. Typically, a DLL contains many functions, only one or a few of which are needed immediately after the DLL is loaded and thus the majority of the DLL may remain absent from memory for some time after the initial DLL load.

When a page fault exception occurs in the streamed application context, the operating system issues a paging request signaling that a specific page of code is needed for the streamed application. A typical request will specify the drive, file name (or handle), offset, and length of the application block(s) to retrieve. Because the operating system140views the application as residing on the virtual file system “drive”160, it will automatically direct the paging request to the dedicated streaming FSD driver150. When the FSD150receives a paging request, it passes the request to the VFS160which determines if the desired block is available locally. If the block corresponding to the requested page is present, it is retrieved and returned to the operating system. For example, if the block was pre-cached during the installation or previously received during a previous execution of the streamed application than the block may be present locally in the cache/VFS160.

If the desired block is not available locally, a fetch request for the needed block is sent through the communication driver170to the streaming server84. The VFS160waits until the request to the server has been fulfilled. After the requested block has been received from the server and stored in the VFS, the block is returned to the operating system. A busy or wait flag can be presented to the operating system during the time the fetch request is outstanding.

The format and content of the fetch request issued by the VFS160and/or application manager110can vary. In one embodiment, the request specifically identifies the blocks which are required. Alternatively, details regarding the faulting read request issued by the operating system, such as the file name, offset, and length, can be forwarded to the server which then determines the appropriate blocks to be returned and may also return additional data not yet requested if it determines that the additional data may be required shortly.

FIG. 7illustrates one embodiment of the VFS160which is configured to appear to the host computer system82as a drive which can be accessed through the FSD driver150. The VFS160includes a VFS Manager module200which provides a functional interface to a plurality of data files for the streamed application. In particular, the VFS160includes an application file structure database210which indicates the complete folder/file structure for the streamed application. In addition a block library230is provided within which blocks (e.g., blocks that are pre-cached during the installation and/or blocks that are received from the streaming server84during execution) are stored. Mapping information220can be used to associate each block in the library230with a respective file name and position within that file.

The various libraries, maps, and databases used by the VFS160can be stored in RAM, in appropriate data files on a conventional local device, such as a hard drive, or distributed between various short and long-term storage devices. In one embodiment, the application file structure and block map information is retained in RAM, and the blocks in the block library are stored on a local hard disk.

FIG. 7shows representative data for a simple example streamed application FOOBAR which includes a 100 kb executable, FOOBAR.EXE and a 40 kb library file, FOOBAR.DLL, both of which are stored under the application folder FOOBAR. A data file, DEFAULT.DATA, is also provided under a DATA subfolder. Preferably, each block has a size which corresponds to the standard I/O page size used by the native operating system. A typical size is the 4 kb page size used in Windows™ operating systems. In this example, seven 4 kb blocks have been stored in the block library230, six of which are associated with various sections of the executable file FOOBAR.EXE, and one of which is associated with the DLL file FOOBAR.DLL. The mapping information220indicates which parts of the various application files each block is associated with. For example, the block FOOBAR001 represents a code page in the FOOBAR.EXE file beginning at offset 4 k.

The mapping information220is shown in a basic table format for simplicity. Also shown in the sample mapping information220are absent blocks. For example, the block corresponding to the code page starting at an offset of 4 k in the DLL file is not defined in the map, here having an associated block ID of “x”, and is therefore considered absent. As will be appreciated, absent blocks need not be defined expressly. The actual mapping and local block storage can be done in a variety ways using various database and linked object mechanisms and data structures which are known to those of skill in the art. In one implementation, the map is stored, at least in part, as a binary table with a bit corresponding to each block in each file. Thus, the sample 140 kb file set would contain 35 bit entries reflecting the presence or absence of the twenty five 4 kb blocks in the executable and the ten blocks in the DLL.

During execution, blocks representing additional code pages streamed to the host computer system82from the streaming server84are received by the application manager110where, after verification, they are passed to the VFS manager200which adds the blocks to the library230and updates the mapping information220accordingly. When a page fault occurs, the application issues a read request which is passed in an appropriate format to the VFS manager200by the FSD driver150. The VFS manager accesses the map220to determine if the required blocks for the requested pages are present and, if so, returns the requested data.

According to a further embodiment, the VFS160is configured to prevent a user from running a streamed application locally without first accessing the streaming server84and requesting the streamed application be initiated. This feature can be useful, for example, to control use of the application as per license agreements or for billing purposes.

In one technique, one or more key blocks of code or data are specially flagged to prevent them from being persistently stored in the VFS160between sessions. When the streamed application exits, these tagged blocks are deleted. To execute the streamed application, the streaming server84must be accessed again to retrieve these key blocks. Alternatively, the blocks can be encrypted and the key(s) stored in the VFS160only for an authorized period of time.

In another technique, the VFS160or FSD driver150can contain a registry of running authorized streamed applications. Such a registry can be created by the application manager110when a new streamed application is started. To prevent a user from copying the stored blocks to a local drive, the streaming FSD150can be configured to only process read or page-in requests from the operating system which are generated on behalf of the application itself or on behalf of other approved processes.

FIG. 8is a flow diagram illustrating an alternative embodiment of a method for installing the streamed application on the host computer system82. In this example, the streamed application management software is used during the installation. The installation program may launch a setup program that needs to access one or more of the application files during the installation in order to obtain information about the streamed application. For example, an icon to be placed on the desktop GUI of the host computer system82may need to be extracted from one of the application files.

As indicated by the arrow1, the streaming file system driver (FSD)150may intercept requests to read various pages of the application files during the installation and may notify the application manager110of the read requests. As indicated by the arrow2A, the application manager110may check to determine whether the blocks corresponding to the requested pages are stored on the installation medium9. If so, the blocks may be retrieved from the installation medium9. Otherwise, as indicated by the arrow2B, the application manager110may communicate with the streaming server computer system84to retrieve the needed blocks. The blocks retrieved from the installation medium9and/or the streaming server84are then passed back to the FSD150, as indicated by the arrow3. The FSD in turn passes the blocks back to the operating system, which in turn passes the blocks back to the setup program.

The installation medium9may include other blocks that were not requested by the setup program. Any blocks stored on the installation medium that were not requested by the setup program may be copied into the cache/VFS160, as indicated by the arrows4and5.

It is noted that various embodiments may further include receiving, sending or storing instructions and/or data implemented in accordance with the foregoing description upon a computer-accessible storage medium. Generally speaking, a computer-accessible storage medium may include any storage media accessible by one or more computers (or processors) during use to provide instructions and/or data to the computer(s). For example, a computer-accessible storage medium may include storage media such as magnetic or optical media, e.g., one or more disks (fixed or removable), tape, CD-ROM, DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, etc. Storage media may further include volatile or non-volatile memory media such as RAM (e.g. synchronous dynamic RAM (SDRAM), Rambus DRAM (RDRAM), static RAM (SRAM), etc.), ROM, Flash memory, non-volatile memory (e.g. Flash memory) accessible via a peripheral interface such as the Universal Serial Bus (USB) interface, etc. In some embodiments the computer(s) may access the storage media via a communication means such as a network and/or a wireless link.