System for downloading and executing a virtual application

A virtual process manager for use with a client application. Both the process manager and the client application are installed on a client computing device. In response to a user command to execute a virtual application at least partially implemented by a virtualized application file stored on a remote computing device, the client application sends a high priority command to the process manager to execute the virtual application. Before receiving the user command, the client application sends a low priority command to the process manager to download at least a portion of the virtualized application file. In response to the high priority command, and without additional user input, the process manager downloads any portion of the file not downloaded in response to the low priority command, and executes the virtual application on the client computing device. The client application may comprise a conventional web browser or operating system shell process.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is directed generally to a virtual process manager and more particularly, to a virtual process manager configured to download a virtualized application file from a remote server and execute the downloaded file.

2. Description of the Related Art

A virtual application is a virtual machine image pre-configured with all of the files, registry data, settings, components, runtimes, and other dependencies required for a specific application to execute immediately and without installation on a host computing device. The virtual application is partially isolated from other applications implemented on a host computing device and partially isolated from an underlying host operating system installed and executing on the host computing device. The virtual application is encapsulated from the host operating system by a virtual runtime environment, which includes a virtual operating system, that receives operations performed by the virtualized application and redirects them to one or more virtualized locations (e.g., a virtual filesystem, virtual registry, and the like).

Thus, the virtual application may be conceptualized as including two components: a virtualization runtime and a virtual application configuration. The virtualization runtime implements the virtual runtime environment, which implements various operating system application programming interfaces (“APIs”) in such a way that allows the executing virtual application to access and interact with items that may not be present on the host computer. The virtual application configuration includes data necessary to implement the virtual application within the virtualization runtime.

The virtual application is stored in and implemented by one or more data files and/or executable files. Depending upon the implementation details, the one or more data files and/or executable files storing and implementing the virtual application may include blocks of data corresponding to each application file of a natively installed version of the application. Herein, these blocks of data will be referred to as “virtual application files.” The one or more data files and/or executable files storing and implementing the virtual application also include configuration information. When the virtual application is executed, the configuration information is used to configure the virtual operating system to execute the virtual application. For example, the configuration information may contain information related to the virtual application files, virtual registry entries, environment variables, services, and the like. The virtual operating system is configured to communicate with the host operating system as required to execute the virtual application on the host computing device.

A download manager is a computer program that downloads files from a web server over the Internet. The download manager is separate from a web browser, which is used to navigate to a web page displaying a link to a file stored on the server. When the user clicks on the link to the file, the download manager is launched and manages the download.

Conventional download managers require user interaction and an application installation process. For example, download managers typically require a user to select a storage location on the user's computer into which the file will be downloaded. Then, after the file is downloaded, the download manager typically launches the installation process or the user executes the file separately. Alternatively, a dialog box may ask the user if the user wants to install an application implemented by the downloaded file and/or execute the file. Often, when the user indicates the user wants to execute the application, an installer is launched that installs the application. The installation process often requires additional user interactions, and may be very time consuming, require special permissions to perform the installation, and perform potentially undesirable modifications to the user's computing device. When the installer is finished, the installer may execute the downloaded (and installed) file. However, the user is typically queried a second time as to whether the user would like to execute the file.

Thus, prior art download managers require user interaction after a file is selected for download. Therefore, using conventional download managers is time consuming and requires substantial user interaction. Further, because the user must respond to the questions presented by the download manager, the user must monitor at least a portion of the file transfer.

A need exists for a virtual process manager configured to download and execute a virtual application while requiring less user interaction than prior art download managers. A further need exists for a virtual process manager that more quickly executes virtualized application files stored on a remote server particularly in view of the fact that a virtualized application file need not be installed on the user's computer to execute thereon. A method of launching applications stored on a remote server is also desirable. The present application provides these and other advantages as will be apparent from the following detailed description and accompanying figures.

DETAILED DESCRIPTION OF THE INVENTION

The present application describes a virtual process manager (referred to as a “Sandbox Manager”) configured to download a virtualized application file from a server computing device to a client computing device operated by a user. The Sandbox Manager does not query the user for any information during the download or execution of the virtualized application file. The user simply selects the virtualized application file for download using a Client Application (such as a web browser or operating system shell) and together the Client Application and the Sandbox Manager effect the transfer of the virtualized application file to the client computing device and the execution of the virtualized application file on the client computing device. Thus, the user need not select a location in which to store the virtualized application file on the client computing device or indicate whether the user would like to execute the virtualized application file. In this manner, the Sandbox Manager may be used to download and execute the virtualized application file in less time than is required using a conventional download manager.

FIG. 1illustrates a system5for downloading or otherwise transferring a virtualized application file stored on a server computing device7to a client computing device9over a network10(e.g., the Internet, a WAN, a LAN, a combination thereof, and the like). One or more additional computing devices, such as the computing device11may also be coupled to the network10. In the embodiment illustrated, the server computing device7is implemented as a web server. A diagram of hardware and an operating environment in conjunction with which implementations of the server computing device7, the client computing device9, the network10, and the computing device11may be practiced is provided inFIG. 8and described below.

FIG. 2illustrates a system memory22A of the client computing device9(illustrated inFIG. 1) storing a conventional operating system35A, that like most operating systems, includes a filesystem126A, a registry128A, and a process environment and threading subsystems component130A. A Client Application132(e.g., a web browser application) and a Sandbox Manager134are also stored in the system memory22A of the client computing device9(illustrated inFIG. 1). Optionally, as explained below, the Client Application132may include a plug-in136or similar application. In the embodiment illustrated, the Client Application132communicates with the Sandbox Manager134over a communication link138that may be implemented as a Transmission Control Protocol (“TCP”) connection using TCP protocol. A cache139may be stored on the filesystem126A for use by the Sandbox Manager134.

As explained above, a virtualized application file140is transferred to the client computing device9from the server computing device7. The virtualized application file140is illustrated in dashed lines to indicate that the virtualized application file140is stored in the cache139during and after the download. However, before the download begins, the virtualized application file140is not stored in the cache139. As will be explained below, the virtualized application file140may be an executable file or a file configured to execute within a virtualized environment provided by a virtual machine.

The system memory22A stores one or more files implementing one or more virtual machines. By way of a non-limiting example, the system memory22A may include a plurality of virtual machine executable files137that when executed, each implement a different virtual machine. For example, each of the virtual machine executable files137may implement a different version of the same virtual machine. The virtual machine executable files137may be executed individually. When executed, a virtual machine executable file implements a virtualized environment. Execution of a virtual machine executable file may be initiated by the Sandbox Manager134using a command including a parameter (e.g., a file path) identifying a virtualized application file to execute. In response to receiving the parameter, the virtual machine executable file executes the identified virtualized application file inside the virtualized environment implemented by the virtual machine executable file. The virtual machine may execute within an operating system shell process. Optionally, the virtual machine executable files137may be stored in the cache139.

The virtualized application file140includes a version identifier that may be used by the Sandbox Manager134to select which of the virtual machine executable files137is configured to execute the virtualized application file140.

FIG. 3illustrates a system memory22B of the server computing device7(illustrated inFIG. 1). The system memory22B stores a conventional operating system35B, illustrated as including a filesystem126B, a registry128B, and a process environment and threading subsystems component130B. The system memory22B stores the virtualized application file140, which is configured to execute on the operating system35A (seeFIG. 2) of the client computing device9(illustrated inFIG. 1), optionally within a virtual machine implemented by a separate virtual machine executable file, without having been installed on the operating system35A of the client computing device9. The virtualized application file140may be configured to execute on the operating system35B of the server computing device7(illustrated inFIG. 1), optionally within a virtual machine implemented by a separate virtual machine executable file, but this is not a requirement.

In the embodiment illustrated, the system memory22B stores web server components142configured to implement a web server. The web server components142may be configured to provide a web page having one or more links to virtualized application files using standard http protocol. By way of non-limiting examples, the web server components142may include Internet Information Services (“IIS”) provided by Microsoft Corporation, Apache, and the like. While illustrated as being outside the filesystem126B, those of ordinary skill in the art appreciate that the virtualized application file140and web server components142may be conceptualized as being within the filesystem126B.

The virtualized application file140may include components necessary to implement a virtual runtime environment including a virtual operating system120configured to execute in the operating system35A (seeFIG. 2) of the client computing device9(illustrated inFIG. 1). Alternatively, the virtual runtime environment may be implemented by one of the virtual machine executable files137(seeFIG. 2). The virtualized application file140includes components necessary to implement a virtual application110configured to execute in the virtual runtime environment. In particular embodiments, a single virtualized application file is used to implement both the virtual operating system120and the virtual application110. However, those of ordinary skill in the art appreciate that more than one virtualized application file may be used to implement the virtual operating system120and the virtual application110. For example, the components implementing the virtual runtime environment may be stored in one of the virtual machine executable files137(seeFIG. 2) and the components implementing the virtual application110may be stored in the virtualized application file140. Further, one or more of the files used to implement the virtual application110may be other than an executable file having the “exe” file extension.

U.S. patent application Ser. No. 12/697,029 filed on Jan. 29, 2010 describes a file format that may be used by the virtualized application file140and an xlayer file. U.S. patent application Ser. No. 12/697,029 is incorporated by reference herein in its entirety. The virtual application110may be implemented using the virtualized application file140and/or one or more xlayer files as described in U.S. patent application Ser. No. 12/697,029. The xlayer file cannot be executed directly from the operating system35A and instead requires the virtual runtime environment supplied at least in part by the virtual operating system120. The virtual operating system120may be supplied by one of the virtual machine executable files137. Thus, the xlayer file may be executed by one of the virtual machine executable files137.

The virtual operating system120includes a virtual filesystem150, a virtual registry152, and a virtual process environment and threading subsystems component154. When executing, the virtual application110interacts with the virtual filesystem150, virtual registry152, and virtual process environment and threading subsystems component154, instead of interacting directly with the filesystem126A, the registry128A, and the process environment and threading subsystems component130A of the operating system35A illustrated inFIG. 2. The virtual operating system120is configured to communicate with the operating system35A illustrated inFIG. 2as required to execute the virtual application110.

The virtual application110executes inside a virtual runtime environment provided at least in part by the virtual operating system120. Some virtual applications require one or more additional runtime environments to execute. For example, to execute a Flash application, the Flash runtime engine must also be installed. Therefore, to virtualize a Flash application, both the Flash application and Flash runtime engine must be included in the virtualized application file140and configured to execute in the portions of the virtual runtime environment provided by the virtual operating system120. Collectively, all runtime components necessary to execute the virtual application110will be referred to as a virtual runtime engine. However, those of ordinary skill in the art appreciate that the virtual runtime engine may include only the virtual operating system120and components of other additional runtime engines (e.g., the Flash runtime engine) required to execute the virtual application110may be loaded separately by the virtual operating system120. When executed, the virtual runtime engine generates, at least in part, the virtual runtime environment in which the virtual application110executes.

The virtualized application file140includes a configuration data block121. The configuration data block121may include virtual application files123A-123C corresponding to each of the application files of a natively installed version of the same application. The virtualized application file140identifies one or more of the virtual application files123A-123C as a startup executable that executes when the virtual application110is first executed. The startup executable may be identified in the configuration data block121.

When the virtualized application file140is executed, the configuration data block121configures the virtual operating system120to execute the virtual application110. For example, the configuration data block121may contain configuration information related to files and directories in the virtual filesystem150, keys and values in the virtual registry152, environment variables, services, and the like.

The configuration data block121may also include basic application metadata and settings such as the application name, application version, and sandbox location. Further, the configuration data block121may provide isolation information to the virtual operating system120. This information indicates which directories, virtual application files123A-123C, virtual registry entries, environment variables, and services are to be isolated from the operating system35A (seeFIG. 2) of the client computing device9(seeFIG. 1). While illustrated as being outside the virtual filesystem150, those of ordinary skill in the art appreciate that the application files123A-123C may be conceptualized as being within the virtual filesystem150when the virtual application110is executing.

To execute the virtual application110, an initialization process is first performed. During this process, the virtual operation system120is launched and configured by the configuration data block121. After the initialization process has completed, the appropriate startup executable(s) is/are launched inside the virtual operating system120. The virtual operating system120intercepts calls to the operating system35A and routes them to corresponding components of the virtual operating system120. For example, when the virtual application110requests access an application file that corresponds to the virtual application file123A using a path of a natively installed version of the application, the virtual operating system120intercepts the request and routes the request to one of the virtual application file123A. The virtual operating system120may also route some requests and actions to the operating system35A (seeFIG. 2) of the client computing device9(seeFIG. 1) for processing.

U.S. patent application Ser. No. 12/188,155, filed on Aug. 7, 2008, U.S. patent application Ser. No. 12/188,161 filed on Aug. 7, 2008, and U.S. patent application Ser. No. 12/685,576 filed on Jan. 11, 2010, all of which are incorporated herein by reference in their entireties, disclose systems that may be used to create and configure the virtualized application file140. As described in greater detail in U.S. patent application Ser. Nos. 12/188,155, 12/188,161, and 12/685,576, the virtualized application file140may be created by a virtual application executable constructor or authoring tool170using an application template that includes copies of files, such as a configuration file202, application files111A-111C, and the like, used to configure the virtualized application file140. However, the template is not a requirement. Instead, to build the virtualized application file140, the authoring tool170needs only the configuration file202and copies of any applications files111A-111C necessary for a natively installed version of the application to execute. The applications files111A-111C, and the configuration file202are referred to collectively as an application configuration171. In some embodiments, the authoring tool170combines the application configuration171and the components of the virtual runtime engine (e.g., the virtual operating system120) into an executable virtualized application file. However, in other embodiments, the authoring tool170omits the components of the virtual runtime engine from the virtualized application file to create a virtualized application file for execution by a virtual machine implemented by a virtual machine executable file, such as one of the virtual machine executable files137.

For ease of illustration, the authoring tool170and the application configuration171have been illustrated as being stored in the system memory22B of the server computing device7(seeFIG. 1). However, this is not a requirement. As is apparent to those of ordinary skill in the art, the virtualized application file140may be created on a computing device other than the server computing device7, such as the computing device11illustrated inFIG. 1, and transferred to the server computing device7illustrated inFIG. 1for storage thereon.

Returning toFIG. 2, as mentioned above, the system memory22A of the client computing device9(seeFIG. 1) stores the Client Application132and the Sandbox Manager134.

Client Application

The Client Application132translates user commands (button clicks, etc) into requests for operations that the Sandbox Manager134performs. In embodiments in which the Client Application132is implemented as a web browser, the browser plug-in136or other type of translation application may be installed on the client computing device9(seeFIG. 1). Together the browser and browser plug-in136perform the functions of the Client Application132.

By way of a non-limiting example, the browser plug-in136may be installed on the client computing device9(seeFIG. 1) by placing a dynamic link library (“dll”) implementing the plug-in136in a predetermined installation directory and registering the dll (i.e., an assembly) in the registry128A (e.g., a Windows registry) of the client computing device9(seeFIG. 1). An Assembly Registration tool (e.g., Regasm.exe) may be used to register the dll in the registry128A.

Once the plug-in136has been installed, the plug-in can be used by a website (implemented by the web server components142(seeFIG. 3) of the server computing device7illustrated inFIG. 1) via client-scripting technologies, such as client-side javascript code executing in the Client Application132. To access the plug-in136from the server computing device7illustrated inFIG. 1, a plug-in object reference is created and sent to the Client Application132. In response to receiving the reference to the plug-in136, the Client Application132loads the plug-in by mime-type, ProgID, class GUID, and the like depending on the implementation details of the Client Application132(which in this embodiment, is implemented as a web browser). The plug-in136exposes methods which can be used to send requests to the Sandbox Manager134.

The requests include commands and optionally, one or more parameters. The requests may be implemented as strings, each including a command. If the request also includes parameters, the parameters may be separated from one another and the command by a predetermined character, such as a semi-colon, comma, and the like. In other words, the request may be implemented as a semi-colon delimitated string or a string delimited in another manner. The following Table A provides a list of commands that my be included in a request.

TABLE ACommandParametersDescription of CommandpingNoneCommands the Sandbox Manager 134 to return apredetermined value. For example, the pingcommand may command the Sandbox Manager toreturn a predetermined string (e.g., “TRUE”)startan applicationCommands the Sandbox Manager 134 to start theidentifier,transfer of the virtualized application file 140priority valueidentified by the application identifier to the clientcomputing device. The priority value indicateswhether the transfer is given a low priority or ahigh priority.statussessionCommands the Sandbox Manager 134 to provideidentifiercurrent status of the transfer of the virtualizedapplication file 140 identified by the sessionidentifierprogresssessionCommands the Sandbox Manager 134 to provideidentifiercurrent progress of the transfer of the virtualizedapplication file 140 identified by the sessionidentifier. The progress may be indicated aspercentage of the virtualized application file 140transferred (e.g., 10%, 25%, and 100%).execsessionCommands the Sandbox Manager 134 to executeidentifier; andthe virtual application 110 implemented at least inoptionally,part by the virtualized application file 140command-lineidentified by the session identifier that wasargumentstransferred previously to the client computingdevice 9 illustrated in FIG. 1

As mentioned above, the Client Application132communicates with the Sandbox Manager134over the communication link138, which may be implemented as a TCP connection. By way of a non-limiting example, the Client Application132may send the requests as text messages using TCP protocol to the Sandbox Manager134over the TCP connection. As described above, each of the requests includes a command and may include one or more parameters (e.g., a parameter list). These commands may be characterized as a communication protocol between the Client Application132and the Sandbox Manager134.

FIG. 4provides a flow diagram of a method200performed by the Client Application132illustrated inFIG. 2. In first block205, the Client Application132connects with the server computing device7illustrated inFIG. 1. In embodiments in which the server computing device7includes the web server components142that implement a website, and the Client Application132is a web browser in which the plug-in136is installed, in block205, the Client Application132connects to the server computing device7over the network10, and downloads a webpage from the website. The webpage includes a reference to the plug-in136. When the Client Application132receives the reference to the plug-in136, the Client Application132loads the plug-in136.

In block210, the Client Application132receives a command from the user via a conventional user interface (e.g., a mouse, keyboard, and the like). The user command instructs the Client Application132to download the virtualized application file140and/or execute the virtualized application file140.

The plug-in136is configured to request a different session for each virtualized application file being transferred and/or executed. Thus, each virtualized application file being transferred and/or executed may be identified by a unique session identifier.

In decision block212, the plug-in136determines whether a session identifier is associated with the virtualized application file140. The decision in decision block212is “YES” when a session identifier is associated with the virtualized application file140. The decision in decision block212is “NO” when a session identifier is not associated with the virtualized application file140.

When the decision in decision block212is “NO,” in block214, the plug-in136requests a new communication session having a unique session identifier with the Sandbox Manager134over the communication link138. Then, the Client Application132advances to block220.

When the decision in decision block212is “YES,” the Client Application132advances to block220.

In block220, the Client Application132translates the user command received in block210into a request to be sent to the Sandbox Manager134over the communication link138. For example, in embodiments in which the Client Application132is a web browser in which the plug-in136is loaded, in block210, the web browser receives the user command (e.g., the user clicks on a hyperlink, presses a button, and the like) and in block220, the plug-in136translates the user command into a request including a command (e.g., one of the commands listed in Table A above) and optionally, one or more parameters (e.g., the session identifier associated with the virtualized application file140). The user command may be an instruction to download the virtualized application file140(seeFIG. 3), an instruction to execute the virtualized application file140, and the like. As mentioned above, the request may be a string including the command and parameters, if any.

Returning toFIG. 4, in block230, the Client Application132transmits the request to the Sandbox Manager134over the communication link138(e.g., a TCP connection) illustrated inFIG. 2. Optionally, in block240, the Client Application132may receive information from the Sandbox Manager134. The information received may be a response to the command (e.g., a response to a “ping” command), a result of performing the command, status and/or progress information related to performing a command, an error message, and the like. Then, the method200terminates.

Sandbox Manager

Returning toFIG. 2, the Sandbox Manager134receives requests from the Client Application132and performs the command included in the requests. The Sandbox Manager134manages the transfer of the virtualized application file140(seeFIG. 3) from the server computing device7to the client computing device9illustrated inFIG. 1. The Sandbox Manager134also manages execution of the virtual application110(seeFIG. 3) on the client computing device9(seeFIG. 1). Turning toFIG. 5, the Sandbox Manager134includes a communications server300(e.g., a TCP server), one or more predefined Client Request object types305, a Client Request Manager310, a Downloader315, and an Executer320.

Returning toFIG. 4, as mentioned above, in block214, the plug-in136requests a different communication session having a unique session identifier for each virtualized application file being transferred and/or executed. Referring toFIGS. 2 and 5, in response to each request for a new communication session, the communications server300establishes a communication session between the Client Application132and the Sandbox Manager134and generates a unique session identifier for the new communication session. In this manner, each virtualized application file being transferred and/or executed may be identified by a unique session identifier.

Each of the predefined Client Request object types305is associated with a particular type of virtualized application file. For example, the Client Request object types305include a Client Request object type associated with the virtualized application file140. The types are used to create a Client Request object for each virtualized application file to be downloaded and/or executed by the Sandbox Manager134. An object of the Client Request object type associated with the virtualized application file140is responsible for managing transfer and execution of the virtualized application file140, including determining status, managing the cache139(seeFIG. 2) stored on the filesystem126A, etc.

The Client Request Manager310determines whether a Client Request object has been created for a particular virtualized application file associated with a session identifier. If a Client Request object has not been created for a virtualized application file, the Client Request Manager310(seeFIG. 5) identifies which of the predefined Client Request object type is configured to manage details about the virtualized application file, creates a Client Request object of the type identified, and associates the Client Request object with the session identifier associated with the virtualized application file. By way of a non-limiting example, a Client Request object may need to be created when the Sandbox Manager134receives a “start” command for the first time to start downloading the virtualized application file140. The Client Request Manager310may include a dictionary330configured to store Client Request objects for use in performing commands included in requests. The dictionary330may be stored in the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2).

Each of the Client Request objects includes a status field indicating a status related to the transfer and/or execution of the virtualized application file. Table B below provides non-limiting examples of status values or codes that may be stored in the status field.

TABLE BStatus CodeDescriptionNot StartedTransfer of virtualized application file is currently beinginitialized.In ProgressTransfer of virtualized application file is currently inprogress.CompleteTransfer of virtualized application file has completed andthe virtualized application file is ready to execute.CanceledTransfer of virtualized application file has been cancelled.Transfer may be canceled by a request from the ClientApplication 132. Alternatively, transfer of virtualizedapplication file may be canceled by an internal operation ofthe Sandbox Manager 134.ErrorTransfer of virtualized application file has been aborteddue to an error. An error code may be sent to the ClientApplication 132. For example, an error code may beencoded in high-order bits of a message sent in responseto the “start” command. Table C below provides a non-limiting exemplary list of error codes.

The status field may be set to “Canceled” when user exits the web page (e.g., browses to another page, closes the browser window, and the like) on which the link to the virtualized application file being downloaded is displayed. By way of a non-limiting example, when the user exits the web page, a cancel call may be created automatically (e.g., by script code executing in the Client Application132) and sent to the plug-in136. In response, the plug-in136sends a cancel message including the session identifier (e.g., “cancel;<session id>”) to the Sandbox Manager134over the communication link138. If the status value of the status field of the Client Request object including the session identifier in the cancel message is “In Progress,” the transfer is cancelled by the Sandbox Manager134.

By way of a non-limiting example, the status value of the status field may be determine in the following manner. If the transfer of the virtualized application file has not yet started, the current status is “Not Started.” If the transfer has started and is in progress, the current status is “In Progress.” If the transfer has started, is not in progress, and has completed, the current status is “Complete.” If the transfer has started, is not in progress, has not completed, and has been canceled, the current status is “Canceled.” If the transfer has started, is not in progress, has not completed, has not been canceled, and has encountered an error, the current status is “Error.” Table C below provides a non-limiting example of error codes that may used by the Sandbox Manager134.

TABLE CError CodeDescriptionNoneNo error occurred.UnknownAn unknown error occurred.Invalid Session IdSession identifier is not valid.NetworkAn error occurred during transfer of the virtualizedapplication file.Invalid SourceThe source path of the virtualized application file (orone of its dependencies) is not valid (e.g., the path isnot in the correct format).

Each of the Client Request objects includes a progress field indicating an amount (e.g., a percentage from 0% to 100%) of the virtualized application file stored in the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2).

Each of the Client Request objects may include a path to the transferred virtualized application file stored on the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2).

The Downloader315downloads a particular virtualized application file identified by a session identifier.

The Executer320executes a particular virtualized application file identified by a session identifier.

FIG. 6provides a flow diagram of a method350performed by the Sandbox Manager134illustrated inFIGS. 2 and 5. In first block355, the Sandbox Manager134receives a request from the Client Application132. After the request is received, in block360, the Sandbox Manager134parses the request to obtain the command and optionally, one or more parameters that may be included in the request. By way of a non-limiting example, in embodiments in which the request is a string, when a request from the Client Application132is received at the Sandbox Manager134, the Sandbox Manager134parses the string to obtain the command and optional list of parameters.

Next, in decision block365, the parameters are validated. By way of a non-limiting example, the parameters may be validated by determining whether the number of parameters matches the number that were expected. The decision in decision block365is “YES,” when the parameter are valid (e.g., the number of parameters matches the number that were expected). Thus, if a particular command does not include parameters (e.g., the “ping” command), the decision in decision block365is “YES,” if the request does not include any parameters. The decision in decision block365is “NO,” when the parameter are invalid (e.g., the number of parameters does not match the number that were expected).

When the decision in decision block365is “NO,” in block366, an error message is sent to the Client Application132. Then, the method350terminates.

When the decision in decision block365is “YES,” the Sandbox Manager134advances to decision block367. In decision block367, the Sandbox Manager134determines whether the request includes a session identifier. The decision in decision block367is “YES” when the request includes a session identifier. The decision in decision block367is “NO” when the request does not include a session identifier.

When the decision in decision block367is “YES,” in block370, the session identifier is used to identify or locate a Client Request object associated with the session identifier and responsible for downloading and/or executing the virtualized application file identified by the session identifier. The dictionary330of the Client Request Manager310may be used to lookup the Client Request object associated with the session identifier.

In decision block375, the Sandbox Manager134determines whether a Client Request object associated with the session identifier has been identified. The decision in decision block375is “YES,” when a Client Request object associated with the session identifier has been identified. The decision in decision block375is “NO,” when a Client Request object associated with the session identifier has not been identified in block370.

When the decision in decision block375is “NO,” in block377, the Sandbox Manager134sends an error message to the Client Application132. The error message may include the error indicator “Invalid Session Id” (see Table C above). Then, the method350terminates. Thus, if a command is sent to the Sandbox Manager134with a session identifier that is not in the dictionary330, an error is returned to the Client Application132and a new request must be sent to the Sandbox Manager134. For example, if a “status,” “progress,” or “exec” command was received in block355including a session identifier not associated with a Client Request object, for the Sandbox Manager134to perform the command, the transfer must be started again with a new request including the “start” command.

When the decision in decision block375is “YES,” the Sandbox Manager134advances to block380described below.

When the decision in decision block367is “NO,” the Sandbox Manager134advances to decision block385to determine whether the Sandbox Manager134should create a new Client Request object. Referring to Table A above, only two commands listed do not include the session identifier: the “start” command; and the “ping” command. The decision in decision block385is “YES” when the command in the request is the “start” command. Otherwise, the decision in decision block385is “NO.” Thus, the decision in decision block385is “NO” when the request includes the “ping” command.

When the decision in decision block385is “YES,” in block387, the Sandbox Manager134creates a new Client Request object and associates the new Client Request object with a session identifier. By way of a non-limiting example, a method call may be made to the Client Request Manager310(seeFIG. 5) to create the new Client Request object. In response to the method call, the Client Request Manager310identifies the Client Request object type that manages details about the particular virtualized application file being transferred to and/or executed on the client computing device9(seeFIG. 1). Then, a new Client Request object having the type identified by the Client Request Manager310is created.

The Client Request Manager310includes a Client Request object for each virtualized application file the Sandbox Manager134is transferring and/or executing. The Client Request object may be cached in the dictionary330of the Client Request Manager310, which may be configured to provide fast lookup of the Client Request object in response to subsequent requests including the session identifier involving the cached Client Request object. The Client Request object is responsible for managing the transfer of the virtualized application file, status of the transfer, progress of the transfer, execution of the virtualized application file, management of the cache139(seeFIG. 2), etc. Thus, when a transfer is started, a unique session identifier is generated, a Client Request object is created, the Client Request object is associated with the unique session identifier, and the Client Request object is stored in the dictionary330for future lookups. The status field of the new Client Request object is set to “Not Started” and the progress field is set to “0%.”

Then, the Sandbox Manager134advances to block380from block387. When the decision in decision block385is “NO,” the Sandbox Manager134also advances to block380.

In block380, Sandbox Manager134performs the command. If applicable, the command is executed on the Client Request object identified in block370or created in block387. Then, in optional block390, Sandbox Manager134sends information back to the Client Application132. For example, as discussed below with respect to the method400(seeFIG. 7), some commands instruct the Sandbox Manager134to perform operations that return values to the Client Application132. Then, the method350terminates.

If the command is a “ping” command, in blocks380and390, the Sandbox Manager134sends a response to the Client Application132. If the command is a “start” command, in block380, the Downloader315downloads the virtualized application file140. If the command is a “status” command, in blocks380and390, the Sandbox Manager134obtains the status value from the status field of the Client Request object identified in block370or created in block387and sends the status value to the Client Application132. If the command is a “progress” command, in blocks380and390, the Sandbox Manager134obtains the progress value from the progress field of the Client Request object identified in block370or created in block387and sends the progress value to the Client Application132. If the command is a “exec” command, in block380, the Executer320executes the virtualized application file140.

FIG. 7is a flow diagram illustrating the method400, which provides a non-limiting example of a typical communication flow between the Client Application132and the Sandbox Manager134. The method400transfers the virtualized application file140(if the virtualized application file140is not already stored in the cache139illustrated inFIG. 2) from the server computing device7(seeFIG. 1) to the cache139illustrated inFIG. 2of the client computing device9(seeFIG. 1). The method400then executes the downloaded virtualized application file140stored in the cache139on the client computing device9(seeFIG. 1). The method400is performable automatically by the Client Application132and the Sandbox Manager134after the user has entered a single user command into the Client Application132. Thus, the method400may be characterized as implementing a one-click virtualized application file download manager and Executer.

In first block405, the Client Application132receives a new user command to download and execute the virtualized application file140. In block410, the Client Application132sends a request including the “ping” command to the Sandbox Manager134. The “ping” command is sent by the Client Application132to determine whether the Sandbox Manager134is in a state to service commands (e.g., available and functioning) and capable of responding to requests. If the Sandbox Manager134is running and in a state to service commands, the Sandbox Manager134will send a response to the Client Application132.

In decision block415, the Client Application132determines whether it has received a response from the Sandbox Manager134to the request sent in block410. The decision in the decision block415is “YES” when the Client Application132has received a response from the Sandbox Manager134indicating that the Sandbox Manager134is in a state to service commands and is capable of responding to requests. The decision in the decision block415is “NO” when the Client Application132has not received a response from the Sandbox Manager134or receives a response indicating the Sandbox Manager134is not in a state to service commands (e.g., available and functioning) or is incapable of responding to requests.

When the decision in the decision block415is “NO,” the Client Application132returns to block410. Alternatively, when the decision in the decision block415is “NO,” the method400may terminate. Optionally, the Client Application132may display a message to the user indicating the virtualized application file140is not available to download.

When the decision in the decision block415is “YES,” in block420, the Client Application132establishes a new communication session with the Sandbox Manager134and sends a request including a “start” command to the Sandbox Manager134. As mentioned above, when the communications server300(seeFIG. 5) of the Sandbox Manager134initiates a new session, the communications server300generates a new and unique session identifier. The “start” command commands the Sandbox Manager134to begin transferring the virtualized application file140.

In block425, when the Sandbox Manager134receives the “start” command, the Client Request Manager310identifies a Client Request object type for the virtualized application file140, creates a Client Request object of the type identified, and associates the session identifier with the new Client Request object. Then, the Sandbox Manager134determines whether at least a portion of the virtualized application file140is stored in the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2). The decision in the decision block425is “YES” when at least a portion of the virtualized application file140is stored in the cache139(seeFIG. 2). Otherwise, the decision in the decision block425is “NO.”

When the decision in decision block425is “YES,” in decision block430, the Sandbox Manager134determines whether the virtualized application file140is stored in its entirety in the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2). The decision in the decision block430is “YES” when the virtualized application file140is stored in its entirety in the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2). The decision in the decision block430is “NO” when less than the entire virtualized application file140is stored in the cache139(seeFIG. 2).

When the decision in decision block430is “YES,” the virtualized application file140need not be transferred to the client computing device9because the virtualized application file is already stored in the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2). In block435, the Sandbox Manager134updates the status field of the Client Request object to “Complete” and the progress field to “100%.” Then, the Sandbox Manager134advances to block440.

When the decision in decision block425or decision block430is “NO,” the Sandbox Manager134begins transferring the virtualized application file. If the decision block425was “NO,” in block445, the Sandbox Manager134adds the virtualized application file140to the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2). The Sandbox Manager134sets the status field of the Client Request object to “Not Started” and the progress field to “0%.” Then, in block450, the Sandbox Manager134begins transferring the virtualized application file140from its beginning.

If the decision block425was “YES” but the decision block430was “NO,” in block450, the Sandbox Manager134sets the status field of the Client Request object to “In Progress,” calculates the progress value, and sets the progress field to the calculated progress value. Then, the Sandbox Manager134begins transferring the virtualized application file from wherever the previous transfer activities left off. The transfer may be started in a new thread using http protocol. In block455, the progress field of the Client Request object is updated occasionally (e.g., periodically) to indicate the percentage of the virtualized application file140transferred. Then, the Sandbox Manager134advances to block440.

In block440, the Sandbox Manager134returns the session identifier associated with the virtualized application file140to the Client Application132.

In block460, the Client Application132sends a request to the Sandbox Manager134including the “status” command. In response to the “status” command, in block465, the Sandbox Manager134sends the status value (e.g., “in progress” or “complete”) of the status field of the Client Request object to the Client Application132. In block467, the Client Application132receives the status value sent by the Sandbox Manager134. Optionally, the Client Application132may display the status value of the transfer to the user. In decision block470, the Client Application132determines whether the entire virtualized application file has been downloaded. The decision in decision block470is “YES,” if the status field of the Client Request object indicates the entire virtualized application file has been downloaded (e.g., the status field has the value “Complete”). The decision in decision block470is “NO,” if the status field of the Client Request object indicates the virtualized application file140has not been completely downloaded (e.g., status field has the value “In Progress”).

If the decision in decision block470is “NO,” in block475, the Client Application132sends a request to the Sandbox Manager134including the “progress” command to determine the progress value of the transfer of the virtualized application file140. In response to the “progress” command, in block480, the Sandbox Manager134sends the progress value in the progress field of the Client Request object (e.g., “10%,” “25%,” etc.) to the Client Application132. In block482, the Client Application132receives the progress value sent by the Sandbox Manager134. Optionally, the Client Application132may display the progress value to the user. Then, the Client Application132returns to block460.

If the decision in decision block470is “YES,” in block485, the Client Application132sends a request to the Sandbox Manager134including an “exec” command. In response to the “exec” command, in block490, the Executer320(seeFIG. 5) of the Sandbox Manager134executes the virtual application110at least partially implemented by the virtualized application file140that the Sandbox Manager134has just transferred. Then, the method400terminates.

As mentioned above, the parameters of the “exec” command includes the session identifier (identifying the virtualized application file transferred) and optional command-line arguments. The session identifier is used to identify the Client Request Object storing the path to the transferred virtualized application file stored on the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2). The path is then used to execute the transferred virtualized application file. The transferred virtualized application file may be executed via an operating system programming interface function call (e.g., ShellExecute, CreateProcess, and the like).

In block490, if the virtualized application file140is configured to be executed inside a virtualized environment provided a virtual machine executable file (e.g., the virtualized application file140is not an executable file having the “.exe” extension), the Sandbox Manager134executes the virtual machine executable file and instructs the executing virtual machine to execute the virtualized application file140. The Sandbox Manager134may send a command to the operating system35A to execute the virtual machine inside an operating system shell process. The command may include the path to the virtualized application file140as a parameter that the virtual machine uses to locate and execute the virtualized application file140.

If more than one virtual machine executable file (e.g., virtual machine executable files137) are stored in the system memory22A, the Sandbox Manager134identifies which of the virtual machine executable files137is configured to execute the virtualized application file140. As explained above, the virtualized application file140may include a version identifier that may be used by the Sandbox Manager134to select which of the virtual machine executable files137is configured to execute the virtualized application file140. Each of the virtual machine executable files137may also include a version identifier that may be matched to the version identifier of a particular virtualized application file to determine whether the virtual machine executable file is configured to execute the particular virtualized application file.

By way of a non-limiting example, blocks425,430,435,445,450, and455of the method400may be implemented in accordance with the following block of pseudo code.

By way of a non-limiting example, the function named “StartDownload” used in the above block of pseudo code may be implemented as follows:

By way of a non-limiting example, the function named “FindFullSize” used in the first block of pseudo code may be implemented as follows:

// a function to return the full size of the// application to be transferred.function long FindFullSize(Uri uriAppSource){string sResponse = DoHttpHeadRequest(uriAppSource);long lContentLength = ParseContentLength(sResponse);return lContentLength;}

Referring toFIG. 2, during a “pre-fetching operation,” the Sandbox Manager134automatically begins transferring one or more virtualized application files (e.g., the virtualized application file140) from the server computing device7(seeFIG. 1) before the user has instructed the Client Application132to download and/or execute the file or files being automatically transferred. Virtualized application files being transferred in this manner are referred to as being “pre-fetched.” A portion of the pre-fetching operation may be performed by the Client Application132and a portion of the pre-fetching operation may be performed by the Sandbox Manager134.

FIG. 9provides a flow diagram of a method500that may be performed by the Client Application132illustrated inFIG. 2. The method500is an exemplary implementation of the portions of the pre-fetching operation performed by the Client Application132. In first block505, the Client Application132connects to the server computing device7(seeFIG. 1). The operations performed by the Client Application132in block505may be substantially similar to the operations performed by the Client Application132in block205of the method200illustrated inFIG. 4.

Referring toFIGS. 1 and 2, in embodiments in which the server computing device7includes the web server components142that implement a website, and the Client Application132is a web browser in which the plug-in136is installed, in block505, the Client Application132connects to the server computing device7over the network10, and downloads a webpage from the website.

In block510, the Client Application132receives information from the server computing device7(seeFIG. 1) with respect to one or more virtualized application files (e.g., the virtualized application file140). The information received in block510includes an application identifier (e.g., a path to the virtualized application file) and a pre-fetch indicator for each virtualized application file available for execution by the client computing device9. Alternatively, the information may include a single pre-fetch indicator for all virtualized application files available for execution. The application identifier identifies a particular virtualized application file and the pre-fetch indicator indicates whether the pre-fetch operation is to be performed with respect to the particular virtualized application file.

As discussed above, in embodiments in which the client computing device9(seeFIG. 1) receives a webpage from the server computing device7(seeFIG. 1), the webpage includes a reference to the plug-in136. When the Client Application132receives the reference to the plug-in136, the Client Application132loads the plug-in136. The webpage also includes the application identifier and the pre-fetch indicator for each virtualized application file available on the webpage for execution by the client computing device9. Alternatively, the webpage may include a single pre-fetch indicator for all virtualized application files available for download from the webpage.

In decision block515, for each virtualized application file available for execution, the Client Application132determines whether the pre-fetch indicator associated with the virtualized application file indicates the pre-fetch operation should be performed with respect to the virtualized application file. As explained above, in particular embodiments, the plug-in136communicates with the Sandbox Manager134. Thus, in some embodiments, after the webpage loads, the plug-in136determines whether the pre-fetch operation has been enabled for the virtualized application file(s) available for execution on the webpage.

As explained above, the plug-in136is configured to request a different session for each virtualized application file being transferred and/or executed. This includes a different session for each virtualized application file being transferred by a pre-fetch operation. Thus, each virtualized application file being transferred and/or executed may be identified by the Client Application132and the Sandbox Manager134using the unique session identifier. However, for ease of illustration, sending a request for the creation of a session by the Sandbox Manager134, and receiving of the session identifier from the Sandbox Manager134have been omitted fromFIG. 9.

For each virtualized application file for which the pre-fetch indicator indicates the pre-fetch operation should be performed, the decision in decision block515is “YES,” and the Client Application132sends a request including the “start” command and two parameters to the Sandbox Manager134in block520. The first parameter is the application identifier (e.g., the session identifier) associated with the virtualized application file to be transferred and the second parameter is the priority value for the transfer. In block520, the priority value indicates the transfer has a low priority.

In block520, while the virtualized application file is downloading, the Client Application132may send requests including “Status” and “Progress” commands as described above with respect to blocks460and475, respectively, of the method400(illustrated inFIG. 7). In response to these requests, the Client Application132may receive responses from the Sandbox Manager134as described above with respect to blocks467and482of the method400(illustrated inFIG. 7). However, even if the virtualized application file is fully downloaded, the Client Application132does not send a request including the “exec” command to the Sandbox Manager134.

Then, in block525, the Client Application132waits for a user command to download and/or execute a particular virtualized application file (e.g., the virtualized application file140). By way of an example, the user command may be received in any manner described above with respect to block405of the method400(seeFIG. 7)

For each virtualized application file for which the pre-fetch indicator indicates the pre-fetch operation is not to be performed, the decision in decision block515is “NO.” When the decision in decision block515is “NO,” the Client Application132does not send a request to the Sandbox Manager134and instead waits for a user command in block525. Pre-fetching may be disabled for many reasons. For example, there may be too many virtualized application files available for download and/or execution. Alternatively, pre-fetching may be disabled when a particular virtualized application file is too large and/or too infrequently downloaded and/or executed.

In decision block530, the Client Application132determines whether it has received a user command to download and/or execute a particular virtualized application file (e.g., the virtualized application file140). The decision in decision block530is “YES” when the Client Application132has received a user command. The decision in decision block530is “NO” if the Client Application132does not receive a user command.

When the decision in decision block530is “YES,” in block535, the Client Application132sends a request including the “start” command and two parameters to the Sandbox Manager134. The first parameter is the application identifier (e.g., the session identifier) associated with the virtualized application file to be transferred. The second parameter is the priority value for the transfer. In block535, the priority value indicates the transfer has a high priority.

In block535, while the virtualized application file is downloading, the Client Application132may send requests including “Status” and “Progress” commands as described above with respect to blocks460and475, respectively, of the method400(illustrated inFIG. 7). In response to these requests, the Sandbox Manager134may send responses as described above with respect to blocks465and480of the method400(illustrated inFIG. 7).

Then, optionally, after the virtualized application file is fully downloaded, the Client Application132may send a request including the “exec” command to the Sandbox Manager134. Then, the Client Application132advances to decision block540.

When the decision in decision block530is “NO,” the Client Application132advances to decision block540.

In decision block540, the Client Application132determines whether it has disconnected from the server computing device7(seeFIG. 1) or in embodiments in which the Client Application132is a web browser, the Client Application132determines whether it has navigated to a different webpage. The decision in decision block540is “YES” when the Client Application132determines it has disconnected from the server computing device7(seeFIG. 1) or navigated to a different webpage. For example, in embodiments in which the server computing device7includes the web server components142that implement a website, and the Client Application132is a web browser in which the plug-in136is installed, the decision in decision block540is “YES” when the Client Application132determines it has exited the webpage (e.g., navigated to a different webpage) even though the Client Application132may remain connected to the server computing device7. The decision in decision block540is “NO” when the Client Application132determines it has not disconnected from the server computing device7or navigated to a different webpage.

When the decision in decision block540is “YES,” the method500terminates. Alternatively, in embodiments in which the Client Application132is a web browser and has navigated to a different webpage provided by the server computing device7, the web server components142may provide a different webpage to the Client Application132identifying one or more virtualized application files for download. When this occurs, the Client Application132returns to block510to receive information related to those virtualized application files.

When the decision in decision block540is “NO,” the Client Application132returns to block525to wait for a user command.

FIG. 10provides a flow diagram of a method600that may be performed by the Sandbox Manager134illustrated inFIG. 2. The method600is an exemplary implementation of the portions of the pre-fetching operation performed by the Sandbox Manager134.

As explained above, the Client Application132is configured to send a request to the Sandbox Manager134requesting a different session for each virtualized application file being transferred and/or executed. This includes a different session for each virtualized application file being transferred by a pre-fetch operation. Thus, each virtualized application file being transferred and/or executed may be identified by the Client Application132and the Sandbox Manager134using the unique session identifier. However, for ease of illustration, receiving a request for the creation of a session from the Client Application132, creating the session, and sending the session identifier to the Client Application132have been omitted fromFIG. 10.

In first block605, the Sandbox Manager134receives a request from the Client Application132including the “start” command, the application identifier (e.g., the session identifier), and the priority value. As explained above, a Client Request object is created for each virtualized application file to be downloaded and/or executed. For example, when the Sandbox Manager134receives a “start” command for the first time to start downloading the virtualized application file140, a new Client Request object may be created for the virtualized application file140. As explained above, the Client Request object associated with the virtualized application file is responsible for managing transfer and execution of the virtualized application file, including determining status, managing the cache139(seeFIG. 2) stored on the filesystem126A, etc.

In decision block610, the Sandbox Manager134determines whether the priority value in the request indicates the transfer has a high priority (i.e., the request is for a high priority transfer). The decision in decision block610is “YES” when the request is for a high priority transfer. On the other hand, the decision in decision block610is “NO” when the priority value in the request indicates the transfer has a low priority (i.e., the request is for a low priority transfer).

When the decision in decision block610is “NO,” in block615, the request is added to a pre-fetch stack (or similar data structure). Then, in decision block620, the Sandbox Manager134determines whether a high priority request is presently being processed. The decision in decision block620is “YES” when a high priority request is presently being processed. On the other hand, the decision in decision block620is “NO” when a high priority request is not presently being processed.

When the decision in decision block620is “YES,” in block625, the Sandbox Manager134waits to process low priority requests (e.g., low priority requests in the pre-fetch stack) until after the high priority request has finished processing. Then, the Sandbox Manager134advances to block630.

When the decision in decision block620is “NO,” the Sandbox Manager134advances to block630. In block630, the Sandbox Manager134selects a low priority request for processing. In embodiments in which the requests are stored in a pre-fetch stack, in block630, the last low priority request added to the pre-fetch stack may be “popped” from the pre-fetch stack.

Then, in block635, the Sandbox Manager134processes the low priority request selected in block630. In block635, if no portion of the virtualized application file identified by the application identifier has been downloaded, the Downloader315(seeFIG. 5) downloads at least a portion of the virtualized application file. For example, the Downloader315may download only a predetermined portion (e.g., 5%, 10%, 25%, 30%, 50%, etc.) of the virtualized application file. In particular embodiments, the portion to be downloaded may be between about 5% and about 20%. By way of a non-limiting example, the predetermined portion may have a predetermined size, e.g., 10 MB, 15 MB, etc. By way of another non-limiting example, the portion to be downloaded may be specified by the user (e.g., as a configuration setting). Further, the Sandbox Manager134may determine different portion sizes for different types of virtual applications. In other words, one or more properties or characteristics of a virtual application may be used to determine the size of the portion to be downloaded during a pre-fetch operation.

In embodiments configured to download only a portion of the virtualized application file, after the portion has been downloaded, the Downloader315(seeFIG. 5) stops downloading the virtualized application file.

If the low priority request is a request to download and/or execute a virtualized application file that has already been at least partially downloaded, any portion of the virtualized application file that was not downloaded by the pre-fetch operation may be downloaded by the Downloader315(seeFIG. 5) in block635. For example, if less than the predetermined portion is downloaded, the Downloader315may download more of the virtualized application file until the Downloader315has downloaded the predetermined portion of the virtualized application file.

If the high priority request is a request to download and/or execute a virtualized application file that has already been downloaded by the Downloader315(seeFIG. 5) (e.g., by a pre-fetch operation), in block635, the Downloader315(seeFIG. 5) need not download any portion of the virtualized application file. For example, if the predetermined portion has been downloaded, the Downloader315(seeFIG. 5) need not download more of the virtualized application file. In embodiments in which the predetermined portion is one hundred percent, the Downloader315(seeFIG. 5) need not download more of the virtualized application file when the virtualized application file has been fully downloaded and is stored in the in the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2).

However, as mentioned above with respect to the method500illustrated inFIG. 9, the Client Application132(seeFIG. 2) does not send a request including the “exec” command to the Sandbox Manager134after sending a low priority request in block520. Therefore, in block635, the Executer320(seeFIG. 5) does not execute the virtualized application file after it is partially or fully downloaded.

While downloading the virtualized application file, the Client Application132may send requests including “Status” and “Progress” commands as described above with respect to blocks460and475, respectively, of the method400(illustrated inFIG. 7). In response to these requests, in block635, the Sandbox Manager134may send responses as described above with respect to blocks465and480of the method400(illustrated inFIG. 7). Further, the Sandbox Manager134may update the status and progress fields of the Client Request objects as described above with respect to blocks435and455of the method400(illustrated inFIG. 7).

Next, in decision block640, the Sandbox Manager134determines whether there are any remaining low priority requests to process. In embodiments in which the low priority requests are stored in a pre-fetch stack, in decision block640, the Sandbox Manager134determines whether there are any low priority requests stored in the pre-fetch stack. The decision in decision block640is “YES” when the Sandbox Manager134determines there are no low priority requests left to be processed (e.g., the pre-fetch stack is empty). On the other hand, the decision in decision block640is “NO” when the Sandbox Manager134determines there are low priority requests left to be processed (e.g., the pre-fetch stack is not empty).

When the decision in decision block640is “YES,” the method600terminates. When the decision in decision block640is “NO,” the Sandbox Manager134returns to decision block620.

When the decision in decision block610is “YES,” in decision block650, the Sandbox Manager134determines whether it is currently pre-fetching one or more virtualized application files. The decision in decision block650is “YES” when the Sandbox Manager134is currently pre-fetching one or more virtualized application files. Otherwise, the decision in decision block650is “NO.”

When the decision in decision block650is “NO,” in block655, the Sandbox Manager134processes the high priority request. In block655, if no portion of the virtualized application file identified by the application identifier has been downloaded, the Downloader315(seeFIG. 5) downloads the virtualized application file. Then, optionally, the Sandbox Manager134may receive a request including the “exec” command from the Client Application132(sent in block535of the method500illustrated inFIG. 9). In response, in block655, the Executer320(seeFIG. 5) executes the virtualized application file.

If the high priority request is a request to download and/or execute a virtualized application file that has already been at least partially pre-fetched, any portion of the virtualized application file that was not downloaded by the pre-fetch operation may be downloaded by the Downloader315(seeFIG. 5) as a high priority request in block655. Then, optionally, the Sandbox Manager134may receive a request including the “exec” command from the Client Application132(sent in block535of the method500illustrated inFIG. 9). In response, in block655, the Executer320(seeFIG. 5) executes the virtualized application file.

If the high priority request is a request to download and/or execute a virtualized application file that has already been fully downloaded by the Downloader315(seeFIG. 5) (e.g., by a pre-fetch operation), in block655, the Downloader315(seeFIG. 5) need not download any portion of the file. Then, optionally, the Sandbox Manager134may receive a request including the “exec” command from the Client Application132(sent in block535of the method500illustrated inFIG. 9). In response, in block655, the Executer320(seeFIG. 5) executes the virtualized application file.

In block655, the Executer320(seeFIG. 5) may execute the virtualized application file in a manner substantially similar to that described above with respect to block490of the method400illustrated inFIG. 7.

Returning toFIG. 10, when the decision in decision block650is “YES,” in block660, the Sandbox Manager134pauses any pre-fetching operations that the Sandbox Manager134is currently performing. Then, in block665, the Sandbox Manager134processes the high priority request. In block665, if none of the virtualized application file identified by the application identifier has been downloaded, the Downloader315(seeFIG. 5) downloads the virtualized application file. Then, optionally, the Sandbox Manager134may receive a request including the “exec” command from the Client Application132(sent in block535of the method500illustrated inFIG. 9). In response, in block655, the Executer320(seeFIG. 5) executes the virtualized application file.

If the high priority request is a request to download and/or execute a virtualized application file that has already been at least partially pre-fetched, the priority value for the low priority request may be updated in block665to high priority. Then, any portion of the virtualized application file not downloaded by the pre-fetch operation may be downloaded by the Downloader315(seeFIG. 5) as a high priority request in block665. Then, optionally, the Sandbox Manager134may receive a request including the “exec” command from the Client Application132(sent in block535of the method500illustrated inFIG. 9). In response, in block655, the Executer320(seeFIG. 5) executes the virtualized application file.

If the high priority request is a request to download and/or execute a virtualized application file that has already been fully downloaded by the Downloader315(seeFIG. 5) (e.g., by a pre-fetch operation), in block665, the Downloader315(seeFIG. 5) need not download any portion of the file. Then, optionally, the Sandbox Manager134may receive a request including the “exec” command from the Client Application132(sent in block535of the method500illustrated inFIG. 9). In response, in block655, the Executer320(seeFIG. 5) executes the virtualized application file.

In block665, the Executer320(seeFIG. 5) may execute the virtualized application file in a manner substantially similar to that described above with respect to block490of the method400(illustrated inFIG. 7).

After the high priority request has been processed, in block670, the Sandbox Manager134resumes any pre-fetching operations paused in block660. Then, the Sandbox Manager134advances to decision block640.

While in the description of method600provided above the pre-fetch stack has been described as storing requests, in alternative embodiments, the pre-fetch stack may store Client Request objects instead. Further, while the requests have been described as being stored in a stack, other data structures such as a queue, array, linked list, and the like may be used to store the requests or Client Request objects.

When performing the method600, the Sandbox Manager134treats low priority requests (which are automatically initiated the Client Application132) differently than high priority requests (which are initiated by a user command provided to the Client Application132). If no high priority requests are being processed by the Sandbox Manager134, low priority requests are processed. However, if during the processing of low priority requests, a high priority request is received by the Sandbox Manager134, processing of the low priority requests is paused.

However, during the processing of high and low priority requests, the user may decide to execute a virtual application on the webpage. As explained above, to do so, the user enters a user command (e.g., clicks on a hyperlink, presses a button, etc.) into the Client Application132. In response, the Client Application132sends a request including the “start” command, the application identifier, and the priority value to the Sandbox Manager134. Under these circumstances, the priority value will have the high priority value. As explained above, when the Sandbox Manager134receives the high priority request, the Sandbox Manager134will pause any pre-fetching operations the Sandbox Manager134was performing when it received the high priority request.

The following pseudo code provides an exemplary implementation of portions of the method600.

The pseudo code above includes a function named “HandleRequest” that receives a request sent by the Client Application132and extracts the command. If the command is a “start” command, the “HandleRequest” function extracts the application identifier (“sSource”) and the priority value (“iPriority”) from the parameters. Then, the “HandleRequest” function calls a function named “StartTransfer” configured to receive the application identifier (“sSource”) and the priority value (“iPriority”).

The “StartTransfer” function configured to receive the application identifier (“sSource”) and the priority value (“iPriority”) pushes the request to the pre-fetch stack if the priority value has a low value. If instead the priority value of the request has a high value, the “StartTransfer” function calls a function named “StartTransfer” configured to receive the application identifier (“sSource”) and a download amount (“IMaxTransfer”). The download amount is specified as being the entire virtualized application file (e.g., the constant “FULL_DOWNLOAD” indicates the entire virtualized application file is be downloaded).

Then, the “StartTransfer” function configured to receive the application identifier (“sSource”) and the priority value (“iPriority”) calls a function named “PrioritizeTransfers.”

The “PrioritizeTransfers” function determines the highest priority value of the requests including the “start” command received by the Sandbox Manager134. If the highest priority value is the high value, the “PrioritizeTransfers” function calls a function named “PauseLowPriorityTransfers” that pauses download operations being performed in response to low priority requests (i.e., requests including the “start” command and having low value priority values). Thus, the “PrioritizeTransfers” function pauses any pre-fetch operations being performed. If on the other hand, the highest priority value is the low value, the “PrioritizeTransfers” function calls a function named “StartLowPriorityTransfers” that starts download operations with respect to low priority requests. Thus, the “PrioritizeTransfers” function initiates pre-fetch operations.

The “StartLowPriorityTransfers” function pops a low priority request from pre-fetch stack. Then, the “StartLowPriorityTransfers” function calls the “StartTransfer” function configured to receive the application identifier (“sSource”) and the download amount (“IMaxTransfer”). The “StartLowPriorityTransfers” function passes the popped low priority request as the application identifier and specifies the download amount (e.g., the product of 10*1024*1024).

The “StartTransfer” function configured to receive the application identifier (“sSource”) and the download amount (“IMaxTransfer”) downloads the portion of the virtualized application file associated with the application identifier from the server computing device7and stores the downloaded portion in the cache139(seeFIG. 2) of the filesystem126A (seeFIG. 2). Then, the “StartTransfer” function configured to receive the application identifier (“sSource”) and the download amount (“IMaxTransfer”) calls the “PrioritizeTransfers” function.

The methods500and600may be used with limited bandwidth connections (like those that are commonly used from user's homes or businesses to help reduce the amount of time required to download and/or execute a virtual application, such as the virtual application110).

Together, the methods500and600preemptively transfer at least a portion of a particular virtualized application file to reduce an amount of time required to transfer the particular virtualized application file after the user has entered a user command into the Client Application132requesting the download and/or execution of the particular virtualized application file. Thus, the methods500and600gives the user the impression that the download has taken less time.

Because users typically spend at least some time reviewing a web page before selecting a virtual application to execute (e.g., by clicking on a hyperlink), the methods500and600may be used to pre-fetch one or more virtualized application files while the user reviews the web page and is not otherwise downloading data over the network10(seeFIG. 1). In other words, referring toFIG. 1, when the connection between the client computing device9and the server computing device7is idle or otherwise has capacity, the client computing device9may pre-fetch all or a portion of one or more virtualized application files. Thus, the methods500and600may be characterized as simulating a faster connection without requiring or using additional bandwidth.

For example, a user typically spends 30 seconds or more reading information provided on the web page before selecting a virtual application to execute. During this time (e.g., 30 seconds or more), the Sandbox Manager134may be transferring the virtualized application file of the virtual application. Therefore, by the time the user instructs the Client Application132to execute the virtual application, the virtualized application file may already be fully downloaded.

FIG. 8is a diagram of hardware and an operating environment in conjunction with which implementations of the client computing device9(including the Client Application132, the Sandbox Manager134, the virtual machine executable files137, and the transferred virtualized application file140), the server computing device7(including the virtualized application file140, the web server components142, and the authoring tool170), and the network10may be practiced. The description ofFIG. 8is intended to provide a brief, general description of suitable computer hardware and a suitable computing environment in which implementations may be practiced. Although not required, implementations are described in the general context of computer-executable instructions, such as program modules, being executed by a computer, such as a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types.

The exemplary hardware and operating environment ofFIG. 8includes a general-purpose computing device in the form of a computing device12. Each of the client computing device9and the server computing device7may be implemented in accordance with the computing device12. By way of non-limiting example, the Client Application132, the Sandbox Manager134, the virtual machine executable files137, and the transferred virtualized application file140may be implemented on a first computing device like the computing device12. The web server components142, and the authoring tool170may be implemented on a second computing device like the computing device12configured to storing the virtualized application file140and generate a web page displaying a link (e.g., a hyperlink) to the virtualized application file140and providing a reference to the plug-in136.

The computing device12includes the system memory22. Each of the system memory22A (seeFIG. 2) and the system memory22B (seeFIG. 2) may be constructed in accordance with the system memory22.

The computing device12also includes a processing unit21, and a system bus23that operatively couples various system components, including the system memory22, to the processing unit21. There may be only one or there may be more than one processing unit21, such that the processor of computing device12comprises a single central-processing unit (CPU), or a plurality of processing units, commonly referred to as a parallel processing environment. The computing device12may be a conventional computer, a distributed computer, or any other type of computer.

The hard disk drive27, magnetic disk drive28, and optical disk drive30are connected to the system bus23by a hard disk drive interface32, a magnetic disk drive interface33, and an optical disk drive interface34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computing device12. It should be appreciated by those skilled in the art that any type of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, USB drives, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like, may be used in the exemplary operating environment. As is apparent to those of ordinary skill in the art, the hard disk drive27and other forms of computer-readable media (e.g., the removable magnetic disk29, the removable optical disk31, flash memory cards, USB drives, and the like) accessible by the processing unit21may be considered components of the system memory22.

The computing device12may operate in a networked environment using logical connections to one or more remote computers, such as remote computer49. These logical connections are achieved by a communication device coupled to or a part of the computing device12(as the local computer). Implementations are not limited to a particular type of communications device. The remote computer49may be another computer, a server, a router, a network PC, a client, a memory storage device, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computing device12. The remote computer49may be connected to a memory storage device50. The logical connections depicted inFIG. 8include a local-area network (LAN)51and a wide-area network (WAN)52. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. The network10may include any of the aforementioned networking environments.

When used in a LAN-networking environment, the computing device12is connected to the local area network51through a network interface or adapter53, which is one type of communications device. When used in a WAN-networking environment, the computing device12typically includes a modem54, a type of communications device, or any other type of communications device for establishing communications over the wide area network52, such as the Internet. The modem54, which may be internal or external, is connected to the system bus23via the serial port interface46. In a networked environment, program modules depicted relative to the personal computing device12, or portions thereof, may be stored in the remote computer49and/or the remote memory storage device50. It is appreciated that the network connections shown are exemplary and other means of and communications devices for establishing a communications link between the computers may be used.

The computing device12and related components have been presented herein by way of particular example and also by abstraction in order to facilitate a high-level view of the concepts disclosed. The actual technical design and implementation may vary based on particular implementation while maintaining the overall nature of the concepts disclosed.

Returning toFIG. 2, the operating system35A, the Client Application132, the Sandbox Manager134, the virtual machine executable files137, and the transferred virtualized application file140may be stored as computer executable components on the system memory22A. Each of the operating system35A, the Client Application132, the Sandbox Manager134, the virtual machine executable files137, and the transferred virtualized application file140may be implemented using software components that are executable by the processing unit21and when executed perform the functions described above.

Returning toFIG. 3, the virtualized application file140, the web server components142, and the authoring tool170may be stored as computer executable components on the system memory22B. Each of the virtualized application file140, the web server components142, and the authoring tool170may be implemented using software components that are executable by the processing unit21and when executed perform the functions described above.

Returning toFIG. 9, the method500implemented by the Client Application132may be stored as computer executable components on the system memory22A. Returning toFIG. 10, the method600implemented by the Sandbox Manager134may be stored as computer executable components on the system memory22A. Each of the methods500and600may be implemented using software components that are executable by the processing unit21.