HK1190475A - Software application delivery and launching system - Google Patents

Abstract

One embodiment allocates a first virtual memory; receives executable code of a first piece of software; writes the executable code of the first piece of software directly into the first virtual memory; marks the first virtual memory as executable; executes the executable code of the first piece of software directly from the first virtual memory; and downloads and executes executable code of a second piece of software as facilitated by the executable code of the first piece of software.

Description

Software application distribution and initiation system

Technical Field

The present invention relates generally to computer software distribution over a computer network and more particularly to deploying computer software from a server over a computer network to a client for execution on the client without installing any portion of the software on the client.

Background

The computer software may be distributed to individual computer systems in a variety of ways. For example, a piece of software may be stored on a Compact Disc (CD) or a Digital Versatile Disc (DVD). An individual may place such a disk into a disk drive of a computer system to install the piece of software stored on the disk on the computer system. More recently, computer networks have provided another channel for software distribution. An individual may download software from a remote computer system (e.g., a server) over a computer network (e.g., the internet) on his own computer system (e.g., a client). In general, the files downloaded over the network may be installation kits, scripts, or executable files embedded in software. An individual may save a downloaded file in a permanent location or in a temporary directory on the hard drive of their computer system and run the saved file to install software on their computer system.

Disclosure of Invention

The present invention relates generally to computer software distribution over a computer network and more particularly to deploying computer software from a server over a computer network to a client for execution on the client without installing any portion of the software on the client.

Particular embodiments allocate a first virtual memory; receiving executable code of first software; directly writing the executable code of the first software into the first virtual memory; marking the first virtual memory as executable; executing the executable code of the first software directly from the first virtual memory; and downloading and executing the executable code of the second software with the assistance of the executable code of the first software.

These and other features, aspects, and advantages of the present invention will be described in more detail below in the detailed description and in conjunction with the following figures.

Drawings

FIG. 1 illustrates an example method of deploying computer software from a server to a client for execution on the client without installing any portion of the software on the client.

FIG. 2 illustrates an example method of streaming computer software from a server to a client for execution on the client.

FIG. 3 illustrates an example network environment.

FIG. 4 illustrates an example computer system.

Detailed Description

The present invention will now be described in detail with reference to a few embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention. In addition, while the invention will be described in conjunction with the specific embodiments, it will be understood that this description is not intended to limit the invention to the described embodiments. On the contrary, the description is intended to cover alternatives, modifications, and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims.

Computer software can be distributed from one computer system (e.g., a server) to another computer system (e.g., a client) over a computer network (e.g., the internet). Indeed, computer networks are considered by an increasing number of software developers, manufacturers, and distributors to be a convenient, fast, and cost-effective channel for software distribution. For example, individuals are often able to download the latest version of computer software developed by a company from the company's website. In a typical scenario, an individual may load a web page containing a software download link on a web browser executing on their computer system and then click on the download link provided in the web page. This typically results in the file being downloaded to the personal computer system. The file may be an installation script or an executable file or executable code of the software itself. The individual may save the file on the hard drive of his computer system. If the file is an installation script or executable file, the individual may run the downloaded file to install the software on their computer system. On the other hand, if the file is executable code of the software, the individual may run the software directly (e.g., by double-clicking on the executable file).

It is inconvenient or sometimes cumbersome to have to save or install a software program downloaded over a computer network on a hard drive of a computer system in order to execute the program. For example, first, it often takes time to save a downloaded file to a hard drive and install the software on a computer system. In addition, in the case of large software (e.g.,PDF) The installation process will take a significant amount of time. The user of the computer system has to go through several steps (e.g., installation, setup, etc.) before he can execute the downloaded software. Second, save the file hardDisk drives and installing software on a computer system take up storage capacity (e.g., hard drive space) of the computer system. Sometimes, a computer system (e.g., a netbook or laptop) may not have sufficient storage space for all software that a user wishes to install on the computer system. Third, software developers may update their software and release newer versions of the software on an untimely basis. Newer versions of software are typically of better quality than older versions. Therefore, people want to keep their software relatively current. However, in order to update software, individuals often need to uninstall older versions of the software currently installed on their computer systems, and then download and install the newer versions. In addition, some software developers may want to deliver software-based application services to users who do not need such an installation because they want to avoid any downloaded code remaining on the persistent data store after initial use or any subsequent use.

To address some of these issues, particular embodiments enable a user of one computer system (e.g., a client) to download a computer software program from another computer system (e.g., a server) over a computer network (e.g., the Internet) for execution on the user's computer system without storing or installing the software program or any other type of software on any permanent storage area (e.g., a hard drive) of the user's computer system. In other words, a user may download software onto their computer system and execute the software on their computer system. After the execution of the software is completed (e.g., after the user exits the software), no traces of the software or any other related software are left on the user's computer system.

For the sake of clarity, hereinafter, computer systems onto which software is downloaded and executed are collectively referred to as "clients", and computer systems from which software is downloaded are collectively referred to as "servers". However, those skilled in the art will appreciate that the embodiments described in detail below may be suitably applied to any two computer systems (e.g., two servers, two clients, or one server and one client). In addition, software that is downloaded from a server to a client and executed on the client (i.e., software that an individual wants to use) is referred to as target software.

In particular embodiments, another piece of software may assist in the downloading and execution of the target software, hereinafter referred to as "stub software" or simply "stub". In particular embodiments, the stub may be implemented using any suitable programming language and compiled into computer executable code. In particular embodiments, the stub's executable code may be stored on a server and may be downloaded to a client for execution using client-side scripts written in any suitable programming language (such as, for example and without limitation, Java, JavaScript, Python, etc., which may be executed on a web browser). For example, the client-side script may be included in a web page as a clickable link. To access the client-side script, a user may load a web page containing the client-side script in a web browser (e.g., Microsoft Internet Explorer, Mozilla Firefox, or Google Chrome) residing on the client, and then click on a link to the client-side script provided in the web page. This causes client-side script code to be transferred to the web browser for web browser execution.

FIG. 1 sets forth an exemplary method for distributing target software from a server to a client for execution on the client through the use of a stub. In certain embodiments, once a client-side script is executed in a web browser, the script accesses a foreign function library residing on the client, as shown in step 100. Many programming languages provide foreign function interfaces. A foreign function interface is a mechanism by which a software program written in one programming language can call a routine or use a service written in another programming language (e.g., a function provided by an operating system or software library). Typically, the functions that implement the foreign function interface of the programming language are contained in a foreign function library provided by the programming language. For example, Python provides a foreign function library called a "ctypes package"; java provides Java local access and a Java local interface that enable Java programs to access the local shared library; and JavaScript provides JavaScript local interface (JSNI), also known as JavaScript foreign function interface (JSFFI). Some web browsers (e.g., Mozilla Firefox) also support local or foreign function access to code executing in these web browsers.

Depending on the particular programming language in which the script code is written, the script may call a library of related foreign functions of that programming language. For example, for Python, a function called "load _ library" may be used to load a particular library. Microsoft Windows provides a function called "LoadLibrary" for loading a specified module into the calling process address space.

In particular embodiments, the script may retrieve a pointer to a storage allocation function residing on the client through a suitable foreign function interface, as shown at step 102. The particular storage allocation function available on the client may depend on the software library available on the client or the operating system of the client. For example, Microsoft Windows has a function called "VirtualAlloc" for reserving or committing a region of a web page in the virtual address space of a calling process. Both the C and C + + programming languages have a library function called "malloc" for performing dynamic memory allocation of a specified size.

In certain embodiments, the script may allocate a specified amount of memory using a memory allocation function (e.g., "VirtualAlloc"), as shown in step 104. The allocated memory should be sufficient for the executable code of the stub. In certain embodiments, the executable code of the stub may be downloaded from the server and written to the allocated memory, as shown in step 106. In particular embodiments, the stub may require some library functions contained in various shared libraries. For example, for Microsoft Windows, the shared library is referred to as a Dynamic Link Library (DLL). The shared library containing the functions necessary for the stub may be loaded by using an appropriate library load function (e.g., "LoadLibrary" or "load _ library").

In a particular embodiment, memory of the executable code written to the stub is marked as executable memory. For example, Microsoft Windows provides a mechanism known as Data Execution Protection (DEP), which is a range of hardware and software techniques that perform additional detection on memory to assist in preventing exploitation of malicious code. In short, all memory locations in a process are marked as non-executable until the location explicitly contains executable code. Therefore, in order to execute the stub code, the storage location to which the executable code of the stub is written needs to be marked as executable. For Microsoft Windows, a particular memory location may be marked as executable by setting an appropriate flag or attribute (e.g., marking the allocated memory as "Page _ EXECUTE", "Page _ EXECUTE _ READ", "Page _ EXECUTE _ READWRITE", or "Page _ EXECUTE _ WRITECOPY").

In particular embodiments, the script may retrieve a pointer to the executable code of the stub in the allocated memory, as shown in step 110. In certain embodiments, the executable code of the stub may be launched directly from memory, as shown in step 112. In certain embodiments, the stub may assist in the downloading and execution of the target software on the client, as shown in step 114. This process will be described in more detail below in conjunction with fig. 2.

In certain embodiments, after the stub completes its task (i.e., assists in the downloading and execution of the target software on the client), the script, in turn, through a suitable foreign function interface, may retrieve a pointer to a memory deallocation function residing on the client, as shown at step 116. The particular memory deallocation function available on the client may depend on the software library available on the client or the operating system of the client. For example, Microsoft Windows provides a function called "VirtualFree" for freeing, de-submitting, or freeing and de-submitting a region of a web page within the calling process's virtual address space. Both the C and C + + programming languages provide library functions such as "dealloc" and "free" for freeing (i.e., deallocating) allocated dynamic memory.

In certain embodiments, the script may deallocate memory written to the executable code of the stub using a memory deallocation function (e.g., "VirtualFree"), as shown at step 118. This memory space can then be used for other purposes and other data can be loaded into the same memory space, overwriting the stub's executable code. Thus, after the storage location of the executable code written to the stub is released (i.e., deallocated), the executable code of the stub disappears (e.g., is replaced or removed) from the client. Since the stub is not saved or installed on any persistent storage (e.g., hard drive) of the client, no trace of the stub's executable code is left on the client.

In particular embodiments, instead of explicitly deallocating storage locations of executable code written to the stub, the storage locations may be implicitly freed. For example, if the user logs out of the web browser or leaves a web page containing a client-side script, all storage locations associated with the script will be freed, meaning that storage locations of executable code written to the stub are also freed.

In particular embodiments, the stub facilitates the downloading and execution of the target software upon execution of the stub directly from the allocated memory on the client. In particular embodiments, the stub may establish a network connection between a client and a server storing the target software and download the executable code of the target software from the server to the client over the network connection. In particular embodiments, the executable code of the target software may be embedded in a data stream sent from a server to a client over a network connection. Based on the received data stream, the stub may extract the executable code of the target software and load it directly into a Random Access Memory (RAM) of the client for execution on the client. Like the stub, the target software is not saved or installed on any persistent storage (e.g., hard drive) of the client. Once the target software completes its execution on the client, the RAM space to load the executable code of the target software will be freed and the target software will no longer exist anywhere on the client.

Downloading and launching the target software on the client without saving or installing the target software on the client may reduce the use of the client's storage capacity. In addition, since the target software is downloaded just before it is executed on the client, the latest or any desired version of the target software may be obtained each time the target software is downloaded and launched.

FIG. 2 sets forth an example method for a stub to assist in downloading and executing target software on a client. In particular embodiments, the target software being downloaded is an application. The executable code of the target software may be stored on a server, which may be the same server as the server storing the executable code of the stub or a different server.

In particular embodiments, the stub may establish a network connection between the client and a server storing executable code of the target software, as shown in step 200. The stub may take over an existing connection already established at the server and client (e.g., a connection established by a web browser) or establish a new connection. If the stub establishes a new network connection, any suitable handshaking method between two computer systems coupled to the computer network may be employed to establish the new connection. For example, a stub executing on a client may send a connection request to a server, and the server may send back a response indicating whether the connection request was accepted or rejected based on the received connection request. If the server receives the connection request, a network connection is established accordingly between the client and the server. In particular embodiments, communications between the server and the client may employ any suitable communication protocol, such as, for example and without limitation, hypertext transfer protocol (HTTP), User Datagram Protocol (UDP), or Transmission Control Protocol (TCP).

In particular embodiments, multiple software programs may be stored on the server or multiple versions of a particular software program may be stored on the server, which may be downloaded to separate clients. In particular embodiments, each version of each piece of software downloaded from the server to the client via the stub executing on the client may be identified by a unique identifier. Such a unique identifier may be used to inform the server which particular piece of software the client's stub wishes to download. In particular embodiments, each piece of downloadable software may be considered a network resource. Thus, a particular piece of downloadable software may be identified by its unique network path or Uniform Resource Identifier (URI). The stub may consult the target software using the URI of the target software.

Sometimes, a piece of software may have multiple versions. In particular embodiments, the stub may determine the most appropriate version of the target software for the client. For example, there are multiple versions of the Microsoft Windows operating system (e.g., Windows XP, Windows ME, or Windows 7) as well as the 32-bit operating system and the 64-bit operating system. The stub may examine the client's operating system to determine the particular version of the target software that is most compatible with the client operating system. If the client's operating system is a 32-bit operating system, the stub may identify a 32-bit version of the target software. On the other hand, if the client's operating system is a 64-bit operating system, the stub may identify a 64-bit version of the target software.

In particular embodiments, when a network connection is requested with a particular server storing the target software, the stub may send the unique identifier of the target software to that server as part of the connection request or with the connection request. Alternatively, in certain embodiments, after a connection is established between the server and the client, the stub may send the identifier of the target software to the server as a separate request. The server may then determine which particular piece of software it should transmit to the requesting client. This process is similar to invoking a data stream through a web browser (e.g., by clicking on a URL or URI link of a downloadable file contained in a web page).

In particular embodiments, the server may transmit the data stream to the requesting client, and more particularly, to a stub executing on the requesting client, over a network connection, as shown in step 202. The network connection may be a TCP connection, a UDP connection, an HTTP connection, or any other suitable connection. In particular embodiments, the data stream may be a video stream or an audio stream. In particular embodiments, the executable code of the target software requested by the stub is embedded in the data stream as one or more data packets. For example, the target software may be a video decoder that receives a video stream encoded by a video codec, decodes the data, and renders the video data on a display of the client. As another example, the target software may be a computer game.

In particular embodiments, the executable code of the target software may be embedded in the data stream. In particular embodiments, the executable code of the target software may be machine code or native code and may be platform dependent. In particular embodiments, the executable code of the target software is followed to run on the platform of the particular client requesting the target software (e.g., a client-based hardware architecture and operating system).

In particular embodiments, the data stream may include two portions. In particular embodiments, the first portion of the data stream (i.e., the beginning of the data stream) may contain executable code of the target software. In particular embodiments, the executable code of the target software may be selectively compressed using any suitable compression method. For example, a lossless compression method, such as zip or gzip, may be used to compress the executable code of the target software. In particular embodiments, the executable code of the target software may be embedded in the video stream. Since most types of video streams are in a generic container format, data (more specifically, executable code of the target software) can be embedded into such video streams. In particular embodiments, the first portion of the data stream may also include operational variables and parameters, such as parameters indicating the size of memory space (e.g., RAM memory space) needed for loading and executing the executable code of the software.

In particular embodiments, the second portion of the data stream may optionally include additional data consumed by the target software in its execution process. In particular embodiments, the additional data may be selectively encoded or compressed and transmitted as one or more data packets by employing any suitable encoding or compression method. Further, if the data stream is a video stream, the additional data may be encoded using a video encoding method such as MPEG encoding.

In particular embodiments, based on the received data stream, the stub may access a first portion of the data stream to extract executable code of the target software embedded therein. The stub may decode or decompress the extracted executable code of the target software, if desired. The decoding or decompression method employed by the stub may correspond to an encoding or compression method used to encode or compress the executable code of the target software. For example, if the executable code of the target software is compressed using a suitable compression algorithm (e.g., a lossless compression algorithm), the stub may decompress it using a corresponding decompression algorithm. Similarly, if the executable code of the target software is encoded using a suitable encoding algorithm, the stub may decode it using a corresponding decoding algorithm. Additionally, in particular embodiments, the stub may also access the first portion of the data stream to extract a parameter indicating the size of the memory space needed to load and execute the executable code of the target software.

In particular embodiments, to prevent unauthorized or malicious software from being downloaded and executed on the client, the stub may employ any suitable verification method to verify the executable code of the target software extracted from the first portion of the data stream, as shown in step 204. In particular embodiments, the stub provides a white list of trusted sources (e.g., domain names or IP addresses of trusted servers). Based on the received software, the stub may compare the source (e.g., server or website) that transmitted the software to its white list. Software transmitted only by trusted sources on the white list may be executed on the client. Software received from sources not on the white list may be discarded or quarantined. In particular embodiments, the executable code of the target software embedded in the first portion of the data stream may be signed and associated with a digital certificate. The stub may verify the executable code of the target software with its associated digital certificate.

If the executable code of the target software is not valid ("NO" of step 206), then the executable code of the target software is not launched on the client and may be deleted. On the other hand, if the executable code of the target software is valid ("yes" at step 206), then, in certain embodiments, the stub may allocate a sufficient amount of memory on the client for loading and executing the executable code of the target software, as shown at step 208. In a particular embodiment, the amount of memory allocated is not less than the size of the memory space required to load and execute the executable code of the target software, as indicated by a variable contained in the first portion of the data stream. In particular embodiments, the allocated memory may be dynamic memory, virtual memory, or RAM of the client.

Most operating systems provide library functions that enable applications to allocate and deallocate virtual or dynamic memory and perform other types of memory-related functions at runtime. In particular embodiments, the stub may call, through an appropriate foreign function library, an appropriate library function provided by the client operating system for allocating the required memory space for the executable code of the target software. For example, as described above, "malloc" is a standard library function in the C and C + + programming languages for allocating dynamic memory space. For Microsoft Windows, "VirtualAlloc" is a Win32 library function used to reserve areas of web pages in the virtual address space. Once memory is allocated, the stub may call the appropriate library function to set the allocated memory as "executable," indicating to the operating system that the data stored in the allocated memory is executable code. For example, for Microsoft Windows, the attributes "PAGE _ EXECUTE", "PAGE _ EXECUTE _ READ", "PAGE _ EXECUTE _ READWRITE", or "PAGE _ EXECUTE _ WRITECOPY" may be specified to be associated with a memory allocation (e.g., using "VirtualAlloc") to request a sufficient amount of virtual memory from the operating system that is authorized to EXECUTE code and to operatively READ or write code.

In particular embodiments, as shown in step 210, the stub may load the executable code of the target software directly into the allocated memory (e.g., allocated dynamic memory) without saving or installing the executable code of the target software on the hard drive of the client. In particular embodiments, the stub may call an appropriate library function provided by the client operating system or a software library on the client to copy binary data representing the executable code of the target software directly to the allocated virtual or dynamic storage space. For example, for Microsoft Windows, "CopyMemory" is a function used to copy a memory block from one location to another; and "memcpy" is a standard library function in the C and C + + programming languages for copying data from one storage location to another.

In particular embodiments, the target software may require certain library functions. If the required library function already exists on the client, the stub may load the target software with a shared library containing the required library function. For example, for Microsoft Windows, a shared library (e.g., a DLL) may be loaded using a "LoadLibrary" function. On the other hand, if the required library function does not exist on the client, the stub may download the shared library containing the required library function or its own required library function from an appropriate server, allocate virtual memory for the shared library or required library function, and write the shared library or required library function to the allocated virtual memory so that the target software can use the library function when required. In other words, for a resource (e.g., library function) necessary in a process executed by the target software, if the resource already exists on the client, the resource on the client is employed; and if the resource does not exist on the client, the stub downloads the resource for the target software.

In particular embodiments, the stub may also adjust a jump table (also referred to as a jump table) to include information about the executable code of the target software loaded in the allocated memory. This process may be referred to as a "fix" process. A branch table is an efficient way to transfer program control from one part to another part of a program or from one program to another program. By adjusting the appropriate branch table entry, the operating system may be made aware of the executable code of the software currently loaded in the allocated memory.

The actual steps performed in the correction process may vary depending on the operating system or platform of the client. For example, for the Microsoft Windows platform, the executable format typically has a relocation table and an import table. Typically, assuming that executable code is loaded onto a fixed address, the executable code is linked. To load the executable code to a different address, any absolute address used by the executable code is looked for and "fixed" to meet the change in base address. This can be obtained by using a relocation table. In certain embodiments, the relocation table compiles a list of all absolute addresses within the executable code so that they can be modified when the executable code is loaded. The lead-in table lists the actual addresses of all programs that the executable code can call. This may include API programs and programs in other Dynamic Link Libraries (DLLs). These incoming addresses are replaced by the actual addresses of the program within the address space of the current process. The import table is a list of the locations of these addresses within the executable code (the addresses may be within the jump table or trampoline area, or may be a list of data for indirect calls).

Particular embodiments may utilize a Portable Executable (PE) format, which is a file format used in Microsoft Windows operating systems for executable files, object code, and DLLs. The PE format is common in many environments of operating system software architecture. In general, the PE format is a data structure that encapsulates the information necessary for the Microsoft Windows operating system to load a program to manage the packed executable code. Particular embodiments may edit and save the executable code of the software in PE format. For other platforms, implementations of the invention may operate with the original executable code requiring a single entry point without any modification. In some implementations, the original executable code can be configured to perform the correction itself and can cover code such as ELF and MACH-O.

In certain embodiments, the target software may be executed on the client, as shown in step 212. In particular embodiments, the executable code of the target software may be launched directly from the allocated dynamic memory storing the executable code of the target software. In particular embodiments, the stub may cause the executable code of the target software loaded in the allocated memory to begin execution. Thus, the stub may transfer execution to the target software.

In certain embodiments, the stub may transmit a socket (or more specifically, an internet socket or a network socket associated with a network connection between the client and the server) and a data stream to the target software executing on the client, as shown in step 214. The network sockets constitute a mechanism for passing incoming data packets to the appropriate application process or thread. By transmitting the network socket associated with the data stream to the target software, the target software can immediately receive additional data packets containing additional data in the second portion of the data stream. The target software may then consume (e.g., process) the additional data contained in the second portion of the data stream. In particular embodiments, the stub may call an appropriate library function provided by the client operating system to transfer the network socket to the executing target software. For example, a Windows socket Application Program Interface (API), also known as Winsock, enables a network socket to be transferred from one process to another by using the "WSADuplicateSesocket" function.

The target software may continue to run until it is completed. In particular embodiments, once the target software has completed its execution (i.e., has exited), the dynamic memory space for loading the executable code of the target software program may be deallocated (e.g., by the operating system of the client). For example, for Microsoft Windows, the "VirtualFree" function may be called to free up memory allocated to store the executable code of the target software. This memory space can then be used for other purposes and other data can be loaded into the same memory space, overlaying the executable code of the target software. At this point, because the target software is installed directly into memory through the stub and is not stored in any persistent media on the client (including, in some embodiments, a browser cache or other temporary data storage mechanism, etc.), the target software no longer exists on the client and does not bring any state changes to the client (e.g., no files on the drive, no system registry changes, etc.).

In some embodiments, a first executable code object initiated by a stub and embedded in a stream may itself cause another process to generate by requesting another data stream that also includes a second executable code object. The second executable code object may be launched as a child of the first executable code object and share the same sandboxed file system generated by the first executable code object. For example, the first executable code object may be a virtual machine that has one or more second executable code objects running entirely in memory and is sandboxed by the first virtual machine code object. In a specific implementation, for example, the virtual machine writes to memory writes to the data storage subsystem by the second code target, rather than the peripheral device being resolved when the user logs off the client. For example, this embodiment may be used to demonstrate a version of software since the first executable code object may be a virtual machine of a second program to be demonstrated or tested by the sandbox. As discussed above, when the first and second executable code objects end, all of their traces in memory will disappear. The foregoing embodiments can also be used to prevent unauthorized access to typically buffered data during application execution.

Particular embodiments may be implemented in a network environment. Fig. 3 illustrates an example network environment 300. Network environment 300 includes a network 310 that couples one or more servers 320 and one or more clients 330 to each other. In particular embodiments, network 310 is an intranet, an extranet, a Virtual Private Network (VPN), a Local Area Network (LAN), a Wireless Local Area Network (WLAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a portion of the Internet, or other network 310 or a combination of two or more such networks 310. The present invention encompasses any suitable network 310.

One or more links 350 couple server 320 or client 330 to network 310. In particular embodiments, each of the one or more links 350 includes one or more wired, wireless, or optical links 350. In particular embodiments, one or more links 350 each include an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a MAN, a portion of the Internet, or other link 350 or a combination of two or more such links 350. The present invention contemplates any suitable links 350 coupling server 320 and clients 330 to network 310.

In particular embodiments, each server 320 may be a unitary server or a distributed server across multiple computers or computer data centers. The server 320 may be of various types, such as, for example and without limitation, a web server, a news server, a mail server, a messaging server, an advertising server, a file server, an application server, an interaction server, a database server, or a proxy server. In particular embodiments, each server 320 may include hardware, software, or embedded logic components or a combination of two or more such components for performing the appropriate functions supported or implemented by server 320. For example, a web server is typically capable of hosting websites containing web pages or specific elements of web pages. More specifically, the web server may host HTML files or other file types, or may dynamically create or compose files based on requests, and communicate them to clients 330 in response to HTTP or other requests from clients 330. The mail server is generally capable of providing email services to various clients 330. Database servers are generally capable of providing an interface for managing data stored in one or more data stores.

In particular embodiments, the executable code of stub 322 and the executable code of software 324 may reside on server 320. They may be downloaded to client 330 for execution without being saved or installed on client 330. When they execute on client 330, they exist on the virtual memory of client 330. After their execution is completed, they are removed from client 330 at the time virtual memory is released, thus leaving no traces on client 330.

In particular embodiments, one or more data stores 340 may be communicatively linked to one or more servers 320 via one or more links 350. In particular embodiments, data storage area 340 may be used to store various types of information. In particular embodiments, the information stored in data storage area 340 may be organized according to a particular data structure. In certain embodiments, each data store 340 may be an associated database. Particular embodiments may provide an interface that enables server 320 or client 330 to manage (e.g., retrieve, modify, add to, or delete) information stored in data storage area 340.

In particular embodiments, each client 330 may be an electronic device including hardware, software, or embedded logic components or a combination of two or more such components and capable of performing the appropriate functions implemented or supported by client 330. For example and without limitation, client 330 may be a desktop computer system, a notebook computer system, a netbook computer system, a handheld electronic device, or a mobile telephone. Any suitable client 330 is contemplated by the present invention. Client 330 may enable a network user at client 330 to access network 330. The client 330 may have its user communicate with other users on other clients 330.

Client 330 may have a web browser 332, such as Microsoft Internet Explorer, Google Chrome, or Mozilla Firefox, and may have one or more additional components, plug-ins, or other extensions, such as a toolbar or Yahoo toolbar, or the like. A user at client 330 may enter a Uniform Resource Locator (URL) or other address that directs web browser 332 to server 320, and web browser 332 may generate a hypertext transfer protocol (HTTP) request and communicate the HTTP request to server 320. Server 320 may receive HTTP requests and transmit one or more hypertext markup language (HTML) files responsive to the HTTP requests to client 330. Client 330 may render a web page based on the HTML files from server 320 for presentation to the user. Any suitable web page file is contemplated by the present invention. For example and without limitation, a web page may be rendered from an HTML file, an extended hypertext markup language (XHTML) file, or an extended markup language (XML) file, according to particular needs. Such web pages may also execute scripts such as, for example and without limitation, scripts written in JavaScript, Java, Microsoft Silverlight, a combination of markup languages and scripts such as AJAX (asynchronous JavaScript and XML), and the like. Herein, a web page is referred to as containing one or more corresponding web page files (which are used by the browser to render the web page) and vice versa, where appropriate.

Particular embodiments may be implemented on one or more computer systems. Fig. 4 illustrates an example computer system 400. In particular embodiments, one or more computer systems 400 perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one or more computer systems 400 provide the functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems 400 performs one or more steps of one or more methods described or illustrated herein or provides the functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems 400.

The invention encompasses any suitable number of computer systems 400. The present invention contemplates computer system 400 employing any suitable physical format. For example and without limitation, computer system 400 may be an embedded computer system, a system on a chip (SOC), a single board computer System (SBC) (such as, for example, a computer module (COM) or a system of modules (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe computer, a network of computer systems, a mobile phone, a Personal Digital Assistant (PDA), a server, or a combination of two or more of these. Where appropriate, computer system 400 may include one or more computer systems 400; in an integrated or decentralized manner; across a plurality of sites; across a plurality of mechanisms; or reside in the cloud (which may include one or more cloud components in one or more networks). One or more computer systems 400 may perform without substantial spatial or temporal limitation, where appropriate, one or more steps of one or more methods described or illustrated herein. For example and without limitation, one or more computer systems 400 may perform in real-time or batch mode one or more steps of one or more methods described or illustrated herein. One or more computer systems 400 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.

In a particular embodiment, computer system 400 includes a processor 402, a memory 404, storage 406, an input/output (I/O) interface 408, a communication interface 410, and a bus 412. Although the invention has been described and illustrated with respect to a particular computer system having a particular number of particular components in a particular configuration, the invention contemplates any suitable computer system having any suitable number of any suitable components in any suitable configuration.

In particular embodiments, processor 402 includes hardware for executing instructions, such as those making up a computer program. For example and without limitation, to execute instructions, processor 402 may retrieve (or read) instructions from an internal register, an internal cache, memory 404, or storage 406; decode and execute them; the one or more results are then written to an internal register, internal cache, memory 404, or storage 406. In particular embodiments, processor 402 may include one or more internal caches for data, instructions, or addresses. The invention encompasses a processor 402 that includes any number of any suitable internal caches, where appropriate. For example and without limitation, processor 402 includes one or more instruction caches, one or more data caches, and one or more Translation Lookaside Buffers (TLBs). The instructions in the instruction cache may be copies of instructions in memory 404 or storage 406, and the instruction cache may speed up retrieval of those instructions by processor 402. The data in the data cache may be a copy of data processed by instructions executing on processor 402 in memory 404 or storage 406; or the results of previous instructions executing on processor 402 for access by subsequent instructions executing on processor 402 or for writing to memory 404 or storage 406; or other suitable data. The data cache may speed up read or write operations by processor 402. TLBs may accelerate virtual address translation for processor 402. In particular embodiments, processor 402 may include one or more internal registers for data, instructions, or addresses. The present invention contemplates processor 402 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 402 may include one or more Arithmetic Logic Units (ALUs); may be a multi-core processor; or include one or more processors 402. Although this disclosure describes and illustrates a particular processor, this disclosure encompasses any suitable processor.

In particular embodiments, memory 404 includes main memory for storing instructions executed by processor 402 or data processed by processor 402. For example and without limitation, computer system 400 may load instructions from storage 406 or other sources (such as, for example, another computer system 400) to memory 404. The processor 402 may then load the instructions from the memory 404 into an internal register or internal cache. To execute instructions, processor 402 may retrieve and decode instructions from an internal register or internal cache. During or after execution of the instructions, processor 402 may write one or more results (which may be intermediate results or final results) to an internal register or internal cache. Processor 402 may then write one or more of those results to memory 404. In particular embodiments, processor 402 executes only instructions in one or more internal registers or internal caches or in memory 404 (rather than storage 406 or elsewhere) and processes only data in one or more internal registers or internal caches or in memory 404 (rather than storage 406 or elsewhere). One or more memory buses (each of which includes an address bus and a data bus) may couple processor 402 to memory 404. The bus 412 may include one or more memory buses, as described below. In particular embodiments, one or more Memory Management Units (MMUs) reside between processor 402 and memory 404 and facilitate access to memory 404 as requested by processor 402. In particular embodiments, memory 404 includes Random Access Memory (RAM). Such RAM may be volatile memory, where appropriate. Such RAM may be dynamic RAM (dram) or static RAM (sram), where appropriate. Further, such RAM may be single ported or multi-ported RAM, where appropriate. Any suitable RAM is contemplated by the present invention. The memory 404 may include one or more memories 404, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

In a particular embodiment, the storage 406 includes mass storage for data or instructions. For example and without limitation, storage 406 may include an HDD, a floppy disk drive, flash memory, an optical disk, a magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 406 may include removable or non-removable (or fixed) media, where appropriate. Storage 406 may be internal or external to computer system 400, where appropriate. In a particular embodiment, the storage 406 is non-volatile, solid-state memory. In certain embodiments, storage 406 includes Read Only Memory (ROM). Where appropriate, such ROM may be mask-programmed ROM, Programmable ROM (PROM), Erasable PROM (EPROM), Electrically Erasable PROM (EEPROM), Electrically Alterable ROM (EAROM), or flash memory or a combination of two or more of these. The present invention contemplates mass storage 406 in any suitable physical format. Storage 406 may include one or more storage control units that facilitate communication between processor 402 and storage 406, where appropriate. Storage 406 may include one or more storages 406, where appropriate. Although the present invention describes and illustrates a particular reservoir, the present invention contemplates any suitable reservoir.

In particular embodiments, I/O interface 408 includes hardware, software, or both providing one or more interfaces for communication between computer system 400 and one or more I/O devices. Computer system 400 may include one or more of such I/O devices, where appropriate. One or more such I/O devices may enable communication between a person and computer system 400. For example and without limitation, the I/O devices may include a keyboard, buttons, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, other suitable I/O devices, or a combination of two or more of these. The I/O device may include one or more sensors. The present invention encompasses any suitable I/O devices and any suitable I/O interfaces 408 for them. I/O interface 408 may include one or more device or software drivers to enable processor 402 to drive one or more of these I/O devices, where appropriate. I/O interface 408 may include one or more I/O interfaces 408, where appropriate. Although this disclosure describes and illustrates a particular I/O interface, this disclosure encompasses any suitable I/O interface.

In particular embodiments, communication interface 410 includes hardware, software, or hardware and software that provides one or more interfaces or one or more networks for communication (such as, for example, packet-based communication) between computer system 400 and one or more other computer systems 400. For example and without limitation, the communication interface 410 may include a Network Interface Controller (NIC) or a network adapter for communicating with an ethernet or other wired network or a wireless NIC (wnic) or a wireless adapter for communicating with a wireless network, such as a WI-FI network. The present invention encompasses any suitable network and any suitable communication interface 410 therefor. For example and without limitation, computer system 400 may communicate with an ad hoc network, a Personal Area Network (PAN), or a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), one or more portions of the Internet, or a combination of two or more of these. One or more portions of one or more of these networks may be wired or wireless. For example, computer system 400 may communicate with a Wireless PAN (WPAN) (such as, for example, a Bluetooth WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile communications (GSM) network), or other suitable wireless network or a combination of two or more of these. Computer system 400 may include any suitable communication interface 410 for any of these networks, where appropriate. The communication interface 410 may include one or more communication interfaces 410, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure encompasses any suitable communication interface.

In particular embodiments, bus 412 includes hardware, software, or both that couple components of computer system 400 to one another. By way of example, and not limitation, the bus 412 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infiniband interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a video electronics standards association local (VLB) bus, or another suitable bus, or a combination of two or more of these. The bus 412 may include one or more buses 412, where appropriate. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

Reference herein to a computer-readable storage medium includes one or more non-transitory, tangible, computer-readable storage media having a structure. For example and without limitation, the computer-readable storage medium may include a semiconductor-based or other Integrated Circuit (IC) (such as, for example, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC)), a hard disk, an HDD, a Hybrid Hard Disk (HHD), an Optical Disk Drive (ODD), a magneto-optical disk, a magneto-optical drive, a Floppy Disk Drive (FDD), a magnetic tape, a holographic storage medium, a Solid State Drive (SSD), a RAM drive, a Secure Digital card, a Secure Digital drive, or, where appropriate, another suitable computer-readable storage medium or a combination of two or more of these. The computer-readable storage medium referred to herein excludes any medium from patent that is not entitled to protection as defined in section 101, section 35 of the U.S. code. The computer-readable storage media referred to herein exclude transitory forms of signal transmission, such as propagating electrical or electromagnetic signals themselves, from the scope of non-patent protection as specified in section 101, article 35, of the U.S. code. A computer-readable non-transitory storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile where appropriate.

The invention encompasses one or more computer-readable storage media embodying any suitable storage. In particular embodiments, a computer-readable storage medium implements one or more portions of processor 402 (such as, for example, one or more internal registers or caches), one or more portions of memory 404, one or more portions of storage 406, or a combination of these, where appropriate. In particular embodiments, a computer-readable storage medium implements RAM or ROM. In particular embodiments, the computer storage media implement volatile or persistent memory. In particular embodiments, one or more computer-readable storage media have software recorded thereon. Herein, reference to software may encompass one or more applications, bytecode, one or more computer programs, one or more executables, one or more instructions, logic, machine code, one or more scripts, or source code, and vice versa, where appropriate. In particular embodiments, the software includes one or more Application Programming Interfaces (APIs). The invention encompasses any suitable software written or otherwise expressed in any suitable programming language or combination of programming languages. In particular embodiments, the software is expressed as source code or object code. In particular embodiments, the software is expressed in a higher level programming language (such as, for example, C, Perl, or other suitable extension). In particular embodiments, the software is expressed in a lower-level programming language, such as assembly language (or machine code). In particular embodiments, the software is expressed in hypertext markup language (HTML), extensible markup language (XML), or other suitable markup language.

Herein, "or" is inclusive rather than exclusive, unless expressly stated otherwise or indicated otherwise by context. Thus, herein, "a or B" means "a, B or a and B" unless expressly indicated otherwise or indicated otherwise by context. In addition, "and" are both common and individual unless expressly indicated otherwise or indicated otherwise by context. Thus, herein, "a and B" are intended to mean "a and B, collectively and individually," unless expressly indicated otherwise or indicated otherwise by context.

The present invention encompasses all changes, substitutions, variations, alterations, and modifications to the exemplary embodiments herein that a person having ordinary skill in the art would comprehend. Similarly, where appropriate, the appended claims encompass all changes, substitutions, variations, alterations, and modifications to the example embodiments herein that a person having ordinary skill in the art would comprehend. Furthermore, a device or system, or a component of a device or system adapted, arranged, capable, configured, enabled, operable or operative to perform a particular function, recited in the appended claims encompasses a device, system, component, whether or not it or that particular function is activated, turned on or unlocked, as long as the device, system or component is adapted, arranged, capable, configured, enabled, operable or operative.

Claims (45)

1. A method, comprising:

allocating, by a first computing device, a first virtual memory;

receiving, by the first computing device, executable code of first software;

writing, by the first computing device, executable code of the first software directly to the first virtual memory;

marking, by the first computing device, the first virtual memory as executable;

executing, by the first computing device, executable code of the first software directly from the first virtual memory; and

downloading and executing, by the first computing device, executable code of second software with the assistance of the executable code of the first software.

2. The method of claim 1, further comprising loading one or more shared libraries needed by executable code of the first software.

3. The method of claim 2, wherein the executable code of the first software is a client-side script executed in a browser running on the first computing device.

4. The method of claim 3, wherein the client-side script accesses a foreign function interface supported by the browser.

5. The method of claim 4, wherein the browser is Mozilla Firefox and the client-side script is JavaScript.

6. The method of claim 3, wherein the client-side script accesses a foreign function library residing on the first computing device.

7. The method of claim 6, wherein the foreign function library is a ctypes library.

8. The method of claim 1, further comprising deallocating the first virtual memory upon completion of execution of the executable code of the first software, such that there is no trace of the executable code of the first software on the first computing device.

9. The method of claim 1, wherein downloading and executing the executable code of the second software facilitated by the executable code of the first software comprises:

receiving executable code of the second software;

extracting executable code of the second software from the data stream;

allocating a second virtual memory;

writing executable code of the second software directly to the second virtual memory;

marking the second virtual memory as executable; and

executing the executable code of the second software directly from the second virtual memory.

10. The method of claim 9, further comprising:

verifying executable code of the second software;

loading one or more first shared libraries needed by executable code of the second software residing on the first computing device; and

downloading from a second computing device one or more second shared libraries required by executable code of the second software.

11. The method of claim 9, further comprising deallocating the second virtual memory upon completion of execution of the executable code of the second software, such that there is no trace of the executable code of the second software on the first computing device.

12. The method of claim 9, further comprising determining the second software based on an operating system of the first computing device.

13. The method of claim 9, wherein,

executable code of the first software is received from a second computing device; and

executable code of the second software is received from a third computing device.

14. The method of claim 9, wherein the executable code of the first software and the executable code of the second software are both received from a second computing device.

15. The method of claim 9, wherein the executable code of the second software is embedded into a data stream.

16. A first system, comprising:

a memory containing instructions executable by one or more processors; and

one or more processors coupled to the memory, the one or more processors operable to execute the instructions, the one or more processors operable when executing the instructions to:

allocating a first virtual memory;

receiving executable code of first software;

writing executable code of the first software directly to the first virtual memory;

marking the first virtual memory as executable;

executing executable code of the first software directly from the first virtual memory; and

downloading and executing executable code of a second software facilitated by the executable code of the first software.

17. The system of claim 16, wherein the one or more processors are further operable when executing the instructions to load one or more shared libraries needed by executable code of the first software.

18. The system of claim 16, wherein the executable code of the first software is a client-side script executed in a browser running on the first computing device.

19. The system of claim 18, wherein the client-side script accesses a foreign function interface supported by the browser.

20. The system of claim 19, wherein the browser is mozilla firefox and the client-side script is JavaScript.

21. The system of claim 18, wherein the client-side script accesses a library of foreign functions residing on the first computing device.

22. The system of claim 21, wherein the foreign function library is a ctypes library.

23. The system of claim 16, wherein the one or more processors are further operable when executing the instructions to deallocate the first virtual memory upon completion of execution of the executable code of the first software such that there is no trace of the executable code of the first software on the first computing device.

24. The system of claim 16, wherein downloading and executing the executable code of the second software with the assistance of the executable code of the first software comprises:

receiving executable code of the second software;

extracting executable code of the second software from the data stream;

allocating a second virtual memory;

writing executable code of the second software directly to the second virtual memory;

marking the second virtual memory as executable; and

executing the executable code of the second software directly from the second virtual memory.

25. The system of claim 24, wherein the one or more processors are further operable when executing the instructions to:

verifying executable code of the second software;

loading one or more first shared libraries needed by executable code of the second software residing on the first computing device; and

downloading from a second computing device one or more second shared libraries required by executable code of the second software.

26. The system of claim 24, wherein the one or more processors are further operable when executing the instructions to deallocate the second virtual memory upon completion of execution of the executable code of the second software such that there is no trace of the executable code of the second software on the first computing device.

27. The system of claim 24, wherein the one or more processors are further operable when executing the instructions to determine the second software based on an operating system of the first computing device.

28. The system of claim 24, wherein:

executable code of the first software is received from a second computing device; and

executable code of the second software is received from a third computing device.

29. The system of claim 24, wherein the executable code of the first software and the executable code of the second software are both received from a second computing device.

30. The system of claim 24, wherein the executable code of the second software is embedded into a data stream.

31. One or more computer-readable storage media having software recorded thereon, the software when executed by a first computer system operable to:

allocating a first virtual memory;

receiving executable code of first software;

writing executable code of the first software directly to the first virtual memory;

marking the first virtual memory as executable;

executing executable code of the first software directly from the first virtual memory; and

the executable code of the second software is downloaded and executed with the aid of the executable code of the first software.

32. The medium as in claim 31 wherein the software is further operable when executed by the first computer system to load one or more shared libraries needed by the executable code of the first software.

33. The medium of claim 31, the executable code of the first software being a client-side script executed in a browser running on the first computing device.

34. The medium of claim 33, wherein the client-side script accesses a foreign function interface supported by the browser.

35. The medium of claim 34, wherein the browser is mozilla firefox and the client-side script is JavaScript.

36. The medium of claim 33, wherein the client-side script accesses a foreign function library residing on the first computing device.

37. The medium of claim 36, wherein the foreign function library is a ctypes library.

38. The medium of claim 31, wherein the software is further operable when executed by a first computer system to deallocate the first virtual memory upon completion of execution of executable code of the first software such that there is no trace of executable code of the first software on the first computing device.

39. The medium of claim 31, wherein downloading and executing executable code of second software with the assistance of executable code of the first software comprises:

receiving executable code of the second software;

extracting executable code of the second software from the data stream;

allocating a second virtual memory;

writing executable code of the second software directly to the second virtual memory;

marking the second virtual memory as executable; and

executing the executable code of the second software directly from the second virtual memory.

40. The media of claim 39, wherein the software is further operable when executed by the first computer system to:

verifying executable code of the second software;

loading one or more first shared libraries needed by executable code of the second software residing on the first computing device; and

downloading from a second computing device one or more second shared libraries required by executable code of the second software.

41. The medium of claim 39, wherein the software is further operable when executed by the first computer system to deallocate the second virtual memory upon completion of execution of executable code of the second software such that there is no trace of executable code of the second software on the first computing device.

42. The medium of claim 39, wherein the software is further operable when executed by the first computer system to determine the second software based on an operating system of the first computing device.

43. The medium of claim 39, wherein the executable code of the first software is received from a second computing device; and the executable code of the second software is received from a third computing device.

44. The medium of claim 39, wherein the executable code of the first software and the executable code of the second software are both received from a second computing device.

45. The medium of claim 39, wherein executable code of the second software is embedded into a data stream.