JP5459743B2 - Stream-based software application distribution and activation system - Google Patents

Description

  The present invention relates to the distribution of computer software over a computer network, and more particularly to providing computer software from a server to a client over a computer network for execution on a client.

  Computer software can be distributed to individual computer systems in a variety of ways. For example, a piece of software can be stored on a CD (Compact Disc) or a DVD (Digital Versatile Disc). A user can insert such a disc into the disc drive of the computer system and install a piece of software stored on the disc into the computer system. Recently, computer networks have provided another channel for software distribution. A user can download a piece of software from another, remote computer system (eg, a server) over a computer network (eg, the Internet) to his computer system (eg, a client). Often, a file downloaded through a network is an installation suite, script, or executable file in which a piece of software is incorporated. The user can save the downloaded file in a permanent location or temporary directory on the computer system hard drive. The user can then execute the stored file and install a piece of software on the computer system.

  It can sometimes be inconvenient and cumbersome to store or install a software program downloaded over a computer network on a hard drive of a computer system in order to execute the software.

  Accordingly, it is an object of certain embodiments of the present invention to provide a method for embedding executable code objects into a data stream such as multimedia data.

In certain embodiments, the method is:
A first computer system receiving a software stub including a Uniform Resource Identifier (URI) identifying a downloadable software program from the second computer system;
The first computer system installing the received software stub;
Sending the request for executable code of the downloadable software program, wherein the software stub is a request including the URI;
Through a network connection between said first computer system and said second computer system, said software stub of the first computer system, capable the download in the data stream transmitted from the second computer system Receiving executable code of a software program, wherein the data stream includes executable code of a software program;
Said first computer system extracting executable code of said downloadable software program from said data stream;
Said first computer system allocating dynamic memory to said executable code of said downloadable software program;
The first computer system directly loads the executable code of the downloadable software program extracted from the data stream into the allocated dynamic memory and executes the downloadable software program No code is stored or installed in persistent storage of the first computer system ; and
Said first computer system, loaded into the dynamic memory allocated by activating the executable code of the downloadable software program, the method comprising executing the downloadable software programs; including.

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

FIG. 4 is a diagram representing an exemplary method of providing a piece of computer software from a server to a client for execution on the client. 1 is a diagram representing an exemplary network environment. FIG. 1 is a diagram illustrating an example computer system.

  The present disclosure will be described with reference to the accompanying drawings, with reference to some embodiments. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without some or all of these specific details. In other instances, well-known processing steps and / or structures have not been described in detail so as not to unnecessarily obscure the present disclosure. Furthermore, although the present disclosure is described with respect to particular embodiments, such description is not intended to limit the disclosure to the described embodiments. On the one hand, such description is intended to cover alternatives, modifications and equivalents that may be included within the spirit and scope of the disclosure as defined by the appended claims.

  Computer software can be distributed from one computer system to another over a computer network (eg, the Internet). In fact, many software developers, manufacturers and distributors consider computer networks as a convenient, fast and cost effective channel for software distribution. For example, a user can download the latest version of a piece of computer software developed by a company from a company website. In a typical scenario, a user can load a web page containing a download link to a piece of software with a web browser running on his computer system and click on the download link provided within the web page. . This downloads the file to the user's computer system. This file can be an install script, an executable file, or executable code of the software body. The user can save the file on the hard drive of his computer system. If the file is an installation script or an executable file, the user can execute the downloaded file to install the software on his computer system. On the other hand, if the file is an executable code of the software, the user can execute the software directly (eg, by double-clicking the executable file).

It may sometimes be inconvenient and cumbersome for software programs downloaded over a computer network to be stored or installed on a hard drive of a computer system in order to execute the software. For example, first, storing downloaded files on a hard drive and installing software on a computer system is often time consuming. If the size of one software is large (for example, Adobe PDF Reader (registered trademark)), the installation process may take a significant amount of time. A computer system user needs to take several steps (eg, installation, setup, etc.) before executing the downloaded software. Second, storing files on the hard drive and installing software on the computer system uses up the storage capacity (eg, hard drive space) of the computer system. Sometimes a computer system (eg, a netbook or notebook computer) does not have enough storage space for all of the software that the user wants to install on the computer system. Third, software developers can sometimes update software and release new versions of the software. A new version of one software is usually of better quality than an older version.
Thus, the user may want to keep the software reasonably up to date. However, in order to update a piece of software, the user needs to uninstall the old version of the software currently installed on his computer system, and then download and install the new version.

  In order to address some of these issues, in certain embodiments, a user of one computer system (eg, a client) downloads software to permanent storage (eg, a hard drive) of the user's computer system. Downloading a computer software program from another computer system (eg, a server) over a computer network (eg, the Internet) for execution on a user's computer without having to store or install the program it can. For clarity, hereinafter, a computer system that downloads software and executes the software is referred to as a “client”, and a computer system that downloads software is referred to as a “server”. However, those skilled in the art will appreciate that the embodiments described in more detail below are well adaptable to any two computer systems (eg, two servers, two clients, one server and one client). I can understand.

  In certain embodiments, a software program, referred to herein as a “software stub” or simply “stub”, may be installed and executed on the client. In certain embodiments, a stub can establish a network connection between a client and a server and download a computer software program from the server to the client over the network connection. In certain embodiments, executable code for a piece of software downloaded from the server to the client may be embedded in a data stream that is sent from the server to the client over a network connection. Upon receipt of the data stream, the stub can extract a piece of software executable code and load it directly into the client's random access memory (RAM) for execution at the client. One software is not stored or installed on any persistent storage (eg, hard drive) of the client. When the one software finishes executing the code on the client, the RAM space of the executable code loaded with the one software is released, and the one software does not exist anywhere on the client.

  In certain embodiments, the stub may be a stand-alone software program stored or installed on the client, or a web browser plug-in or add-on installed on the client. A stub may be stored or installed on a client using any existing method suitable for distributing computer software programs to individual computer systems (eg, CD, DVD, network download, etc.). Good. In certain embodiments, stubs can be small software (ie, small in size) and therefore do not consume much of the client's storage capacity. The stub can be executed alone if it is a stand-alone software program, and can be executed through a web browser if it is plug-in or add-on software.

  By using a stub on the client to download and launch a computer software program, only the stub needs to be permanently stored or installed on the client. Other software can be downloaded and launched on the client without having to be stored or installed. This can reduce the storage capacity used by the client. Furthermore, a piece of software is downloaded on the client just before its execution. As such, certain embodiments facilitate providing the latest version of the software (or any desired version) each time the software is downloaded and launched.

  FIG. 1 is an illustration of a server-to-client, for installing directly on client executable memory and running on the client without permanently storing or installing computer software on the client. To download a typical computer program. In certain embodiments, the steps shown in FIG. 1 may be performed by a stub that is executed on the client. In certain embodiments, the stub can be run as a stand-alone application or as a web browser plug-in or add-on installed on the client so that the steps shown in FIG. 1 can be performed. In certain embodiments, the downloaded software program is an application program.

  As shown in step 100, certain embodiments can establish a network connection between a client and a server. A network connection can be established by a method of performing an appropriate handshake between two computer systems connected to a computer network. For example, a stub running on the client sends a connection request to the server. When the server receives the connection request, the server can transmit a response indicating whether the connection request is accepted or rejected. Once the server accepts the connection request, certain embodiments can establish a network connection between the client and the server accordingly.

  In certain embodiments, each software program downloaded from the server to the client by a stub running on the client may be identified by a unique identifier. This unique identifier can be used to inform the server what software the client stub wants to download. In certain embodiments, each downloadable software can be considered a network resource. Therefore, specific software that can be downloaded can be specified by its unique network path or URI (Uniform Resource Identifier).

  In certain embodiments, to establish a network connection for the purpose of downloading specific software, a client user may provide a unique identifier (eg, a URI) for the specific software and if the stub is a standalone application. Can be provided directly to a stub running on the client, or can be provided to a web browser having a stub as a plug-in. This process is very similar to requesting a web page by providing the web page URL (Uniform Resource Locator) to the web browser. For example, the user can click on the URL corresponding to the video data stream. Thereby, the plug-in receives the URL and starts the processing flow shown below. The stub is based on the specific software identifier that the user is requesting (for example, by mapping the requested software URI to the server's IP address) to which specific server the network connection is. Decide what should be established. In certain embodiments, the stub can provide a user interface (UI) that allows bookmarking of individual identifiers of the software so that the user can conveniently search the software.

  In certain embodiments, when requesting a network connection from a particular server, the stub sends a unique identifier for the particular software that the user is requesting to the server, either with the connection request or as part of the connection request. can do. The server can determine which particular software to send to the requesting client. The process can be similar to invoking a data stream via a web browser (eg, by clicking on a URL or URI link to a downloadable file contained on a web page).

  As shown in step 102, in certain embodiments, the server may send the data stream to the requesting client, particularly to a stub running on the requesting client. The network connection may be a Transport Control Protocol (TCP) connection, a User Datagram Protocol (UDP) connection, or other suitable connection. In certain embodiments, the data stream may be a video stream or an audio stream. In certain embodiments, the particular software requested by the stub may be embedded in the data stream as one or more data packets. For example, the 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 client display.

  In certain embodiments, the executable code of the requested software may be embedded in the data stream. In certain embodiments, the executable code of the requested software may be machine code or native code and may be platform dependent. In certain embodiments, the executable code of the requested software is compiled to execute on the particular client platform that requested the software (eg, based on the client architecture and operating system). .

  In certain embodiments, the data stream may include two parts. In certain embodiments, the first portion of the data stream (ie, the first portion of the data stream) may include software executable code. In certain embodiments, software executable code may optionally be compressed using a suitable compression method. For example, a lossless compression method, such as zip or gzip, can be used to compress software executable code. In certain embodiments, software executable code may be embedded within a video stream. Since most types of video streams are in the form of common containers, data, especially software executable code, can be embedded in such video streams. In certain embodiments, the first portion of the data stream is an operation, such as a parameter indicating the size of memory space (eg, RAM memory space) required to load and execute the software executable code. The above variables and parameters may further be included.

  In certain embodiments, the second portion of the data stream may optionally include additional data that may be used by the software during execution of the software. In certain embodiments, the additional data may be optionally encoded or compressed and transmitted as one or more data packets using an appropriate encoding or compression method. Again, if the data stream is a video stream, the additional data can be encoded using a video encoding method, such as MPEG encoding.

  In certain embodiments, upon receiving a data stream, the stub can access a first portion of the data stream and extract the embedded software executable code. If necessary, the stub may decode or extract the extracted software executable code. The decoding method or decompression method used by the stub may correspond to the encoding method or compression method used by the server sending the software executable code. For example, if software executable code is compressed using an appropriate compression algorithm (eg, a lossless compression algorithm), the stub may decompress the code using a corresponding decompression algorithm. it can. Similarly, if the software executable code is encoded using an appropriate encoding algorithm, the stub may be decoded using a corresponding decoding algorithm. Further, in certain embodiments, the stub may access a first portion of the data stream and extract a parameter indicating the size of the memory space needed to load and execute the software executable code. it can.

  As shown in step 104, in certain embodiments, to prevent unauthorized or malicious software from being downloaded on the client, the stub uses an appropriate verification method to The executable code of the software extracted from the first part of the stream can be verified. In certain embodiments, a white list of trusted sources (eg, trusted server domain names or IP addresses) may be provided with the stub. Upon receiving the software, the stub can compare the source (e.g., server or website) sending the software with the whitelist. Only software that is whitelisted and sent by a trusted source can be run on the client. Software received from sources not on the whitelist can be discarded or quarantined. In certain embodiments, software executable code embedded in the first portion of the data stream may be signed and associated with a digital certificate. The stub can verify the executable code of the software using the associated digital certificate.

  If the software executable code is not valid ("NO" at step 106), the software executable code is not launched on the client and can be discarded. On the other hand, if the software executable code is valid (“Yes” in step 106), in a particular embodiment, the stub loads the software executable code, as shown in step 108. And a sufficient amount of memory can be allocated to execute. In certain embodiments, the amount of allocated memory is greater than the size of the memory space required to load and execute the software executable code, indicated by a variable included in the first part of the data stream. Don't get smaller. In certain embodiments, the allocated memory may be client dynamic memory, virtual memory or RAM.

  Most operating systems provide library functions that allow application programs to dynamically allocate and free memory and execute other types of memory related functions at runtime. In certain embodiments, the stub can invoke the appropriate library function provided by the client operating system and allocates the necessary memory space for the software executable code. For example, “malloc ()” is a standard library function of C language and C ++ language for dynamically allocating a memory space. In the Microsoft® Windows® platform, “VirtualAlloc ()” is a Win32 library function for reserving an area with a page in the virtual address space. Once the memory is allocated, the stub can invoke the appropriate library function to set the “executable” flag for the allocated memory space. The flag indicates to the operating system that the data stored in the allocated memory is executable code. For example, Microsoft's Windows® platform specifies the "PAGE-EXECUTE-READWRITE" flag to request the operating system a sufficient amount of virtual memory that has read, write, and execute permissions. be able to.

  As shown in step 110, in certain embodiments, the stub can load software executable code directly into the allocated memory without having to save it on the client hard drive. . In certain embodiments, the stub is a suitable library provided by the client operating system to copy binary data representing the executable code of the software directly into the allocated dynamic memory space. A function can be invoked. For example, “memcpy ()” is a standard library function in C language and C ++ language for copying data from one memory area to another memory area.

  In certain embodiments, the stub may further adjust a branch table (also referred to as a jump table) to contain information about the software executable code loaded into the allocated memory. Such a process is called a “fix-up” process. A branch table is an efficient way to transfer program control from one part of a program to another, or from one program to another. By adjusting the appropriate branch table entries, the operating system can now know the executable code of the software loaded into the allocated memory.

The actual steps performed during the fixup process may vary depending on the platform or OS of the computer system. For example, on Microsoft's Windows platform, the executable formats typically include a relocation table and an import table. In general, executable code is linked on the assumption that it is loaded into a fixed address. In order to load executable code to a different address, all of the absolute addresses used by the executable code are detected and “fixed up” to respond to changes in the base address.
This can be achieved by using a relocation table. In certain embodiments, the relocation table edits a list of all absolute addresses in the executable code so that when the executable code is loaded, all absolute addresses are fixed up. . The import table lists the absolute addresses of all routines that can be called by executable code. This can include both API routines and routines in other dynamic link libraries (DLLs). These import addresses are replaced with the actual addresses of the routines in the address space for the current process. The import table is a list of the locations of those addresses in the executable code (addresses can be in the jump table or trampoline area, but can also be a list of data for indirect calls).

  Certain embodiments take advantage of the PE (Portable Executable) format, which is one file format for executable files, object code and DLLs used in the Microsoft Windows operating system. The PE format has wide application in many environments of operating system software architecture. In general, the PE format is a data structure that encapsulates the information necessary for Microsoft's Windows® operating system loader to manage wrapped executable code. Certain embodiments may use PE format to compile and save software executable code.

  As shown in step 112, in certain embodiments, the software may be executed on the client. In certain embodiments, the executable code of the software can be launched directly from the allocated dynamic memory where it is stored. In certain embodiments, the stub may cause software executable code loaded in the allocated memory to begin execution. Thus, the stub can move its execution to software.

  As shown at 114, in a particular embodiment, the stub is currently running on the client a socket, more precisely an internet socket or network socket associated with the network connection between the client and server. Can be passed to software. Network sockets constitute a mechanism for communicating incoming data packets to the appropriate application process or thread. By passing the network socket associated with the data stream to the software, the software can receive additional data packets that include additional data in the second portion of the data stream. The software can use (eg, process) additional data contained in the second portion of the data stream. In certain embodiments, the stub can call the appropriate library function provided by the client operating system and pass the network socket to the currently running software. For example, in the Windows socket application programming interface (API), also called Winsock, network sockets can be passed from one process to another by the “WSADuplicateSocket ()” function.

  The software program can continue to run until it is complete. In certain embodiments, when a software program completes its execution (i.e., terminates), the dynamic memory space that was used to load the software executable code (e.g., the client operating system) Can be opened by the system). Later, such memory space can be used for other purposes. Other data is loaded into that memory space and overwrites the executable code of the software program. In this regard, the software program does not exist on the client without making any state changes (eg, files on the drive, system registry changes, etc.) to the client. Because software programs are installed directly into memory by stub 232, in some embodiments persistent media on the client, including browser cache or other temporary data storage schemes. This is because they are not stored.

  To enable caching of various state and application data, such as user preferences, settings, and downloaded modules of code from the data stream itself, the stub 230 is routed via a resource fork. You can store such data in your own file container. In this manner, the stub 232 is completely portable across multiple systems. For example, a known instance of a stub (including a file container) can be attached to an email, loaded onto a USB drive, etc., and transferred to another system.

  In some implementations, the first executable code object that is embedded in the stream and activated by the stub 232 itself requests another data stream that includes the second executable code object. By doing so, another process can be generated. The second executable code may be launched as a child process of the first code object and share the same sandbox file system created by the first executable code object. For example, the first executable code object is a virtual machine, and the code object includes one or more second executable code objects in memory and by the code object of the first virtual machine. It can be run completely in the sandbox. In certain implementations, for example, writing to the data storage subsystem by the second code object is made to memory by the virtual machine and not to the peripheral device that can be analyzed when the user logs off from the client 230. . For example, this embodiment can be used to prepare a demo version of the software. This is because the first executable code object can be a virtual machine that provides a sandbox of a second program to be demod or tested. As described above, when the first and second code objects are finished, all their traces in memory are erased. The embodiments described above can also be used to prevent unauthorized access to data that is typically cached during application execution.

  Certain embodiments may be implemented in a network environment. FIG. 2 illustrates an example network environment 200. The network environment 200 includes a network 210 that connects one or more servers 220 and one or more clients 230 to each other. In certain embodiments, the network 210 is an intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), metropolitan area network (MAN), A communication network, satellite network, part of the Internet, another network 210 or a combination of two or more such networks 210. This disclosure contemplates any suitable network 210.

  One or more links 250 connect the server 220 or the client 230 to the network 210. In certain embodiments, each of the one or more links 250 includes one or more wired, wireless, or optical links 250. In certain embodiments, each of the one or more links 250 is an intranet, extranet, VPN, LAN, WLAN, WAN, MAN, communication network, satellite network, part of an intranet, another link 250 or such link. Including two or more combinations of 250. This disclosure contemplates any suitable link 250 that connects server 220 and client 230 to network 210.

  In certain embodiments, each server 220 can be a centralized server or a distributed server across multiple computers or multiple data centers. The server 220 may be various types of servers such as a web server, news server, mail server, message server, advertisement server, file server, application server, exchange server, database server or proxy server (however, Not limited to). In certain embodiments, each server 220 may comprise hardware, software or embedded logic components or a combination of two or more such components to perform the appropriate functions implemented or supported by the server 220. May be included. For example, a web server can generally host a web site that includes a web page or specific elements of a web page. More specifically, the web server can host HTML files or other types of files, or can dynamically generate or configure files upon request, such as HTTP requests or other requests from clients 230. Depending on the, you can send those files to the client. A mail server can generally provide electronic mail services to various clients 230. A database server can generally provide an interface for managing data stored in one or more data stores.

  In certain embodiments, each client 230 is an electronic device that includes hardware, software or embedded logic components, or a combination of two or more such components, and is implemented or supported by the client 230 as appropriate. The function can be executed. For example, the client 230 can be, but is not limited to, a desktop computer system, a notebook computer system, a netbook computer system, a handheld electronic device, or a mobile phone. Client 230 allows network users of client 230 to access network 210. Client 230 has a web browser, such as Microsoft Internet Explorer or Mozilla Firefox, and may have one or more add-ons, plug-ins, or other extensions, such as Google Toolbar or Yahoo Toolbar. Client 230 allows that user to interact with other users of other clients 230. This disclosure contemplates any suitable client 230.

  In certain embodiments, one or more data storage devices 240 may be communicatively linked to one or more servers 220 through one or more links 250. In certain embodiments, the data storage device 240 can be used to store various types of information. In certain embodiments, the information stored in data storage device 240 is organized according to a particular data structure. Some specific embodiments may provide an interface that allows the server 220 or client 230 to manage (eg, search, modify, add or delete) information stored in the data storage device 240.

  In certain embodiments, the stub 232 may be installed and executed on the client 230. In certain embodiments, the stub 232 may be a stand-alone software program or may be a plug-in or add-on to other software programs such as a web browser that are installed and run on the client 230. Good. When executed on the client 230, the stub 232 may perform the steps shown in FIG. In certain embodiments, the stub 232 may include one or more additional modules for deploying executable code of software programs embedded in the data stream. In another embodiment, the decompression module is itself encoded in the data stream and is invoked by the stub 232 to decompress one or more additional code modules embedded in the data stream. Also good.

  Further, in certain embodiments, the executable code module embedded in the data stream is one or more clients, such as device type, hardware capabilities, display mode, peripherals, graphics accelerator capabilities, etc. Based on 230 attributes, it can be determined dynamically. For example, different executable code modules may be embedded in the data stream, allowing different clients to use the same media stream.

  Certain embodiments may be implemented as hardware, software, or a combination of hardware and software. For example, one or more computer systems can execute specific logic or software, and perform (but are not limited to) one or more steps for one or more processes described or described herein. Not) The one or more computer systems may be centralized or distributed, connecting multiple computer systems or multiple data centers in appropriate locations. This document contemplates any suitable computer system. In certain embodiments, the execution of one or more steps for one or more processes described or described herein need not necessarily be limited to one or more specific geographic locations; Moreover, it is not necessarily limited in terms of time. By way of example, one or more computer systems can perform (but is not limited to) functions in real time, offline, batch mode, or any suitable combination thereof. One or more computer systems may perform some of the functions of one or more at different times and at different locations, using different processes as needed. Here, logic includes software, and vice versa when appropriate. Software includes one or more computer programs, and vice versa, if necessary. Software includes data, instructions, or both, and vice versa if necessary. Similarly, data includes instructions and vice versa if necessary.

  One or more computer-readable storage media may store software that implements a particular embodiment or otherwise embody such software. A computer-readable medium may carry, communicate, contain, contain, maintain, propagate, retain, store, transmit, transport, or otherwise implement the software as appropriate. It can be any medium that can be converted. The computer readable medium may be a biological, chemical, electronic, electromagnetic, infrared, magnetic, optical, quantum or other suitable medium or a combination of two or more such media. The computer readable medium may include one or more nanometer scale components or may embody a nanometer scale design or manufacture. Exemplary computer readable storage media include compact disks (CDs), field-progRAMmable gate arrays (FPGAs), floppy disks, floptical disks, hard disks, holographic storage devices, (application-specific integrated circuits, ASICs). Integrated circuit (IC), magnetic tape, cache, programmable logic device (PLD), random access memory (RAM), read only memory (ROM), semiconductor memory and other suitable computer readable storage media Including, but not limited to.

  The software that implements a particular embodiment is written in any suitable (procedural or object-oriented) programming language, or, if necessary, a combination of multiple programming languages. Any suitable type of computer system or systems (such as a single processor or multiprocessor computer system) may execute software implementing particular embodiments, if desired. A general purpose computer system may execute software that implements a particular embodiment, if desired.

  For example, FIG. 3 illustrates an exemplary name computer system 300 that is suitable for implementing one or more components of a particular embodiment. Although this specification describes and describes a particular computer system 300 having a particular part in a particular configuration, this specification describes any particular component having any suitable part in any suitable configuration. Intended for an appropriate computer system. Further, the computer system 300 may include, for example, one or more integrated circuits (ICs), one or more printed circuit boards (PCBs), one or more handheld devices (such as a mobile phone or PDA) or other devices, one or more PCs. Or it can take any suitable physical form, such as one or more supercomputers.

  A system bus 310 connects subsystems of the computer system 300 to each other. The bus here includes one or more digital signal lines that provide a common function. This specification describes any suitable system, including any suitable bus architecture (such as one or more memory buses, one or more peripheral buses, one or more local buses, or combinations thereof) having a suitable bus architecture. Bus 310 is intended. Exemplary bus architectures include Industry Standard Architecture (ISA) bus, Enhanced ISA (EISA) bus, Micro Channel Architecture (MCA) bus, Video Electronics Standards Association Bus (VLB), Peripheral Component Interconnect (PCI) bus, PCI Express ( PCI-X) bus and AGP (Accelerated Graphics Port) bus, but not limited to this.

  Computer system 300 includes one or more processors 320 (or central processing units (CPUs)). The processor 320 may include a cache 322 for temporary local storage of instructions, data or computer addresses. The processor 320 is connected to one or more storage devices including the memory 330. The memory 330 may include random access memory (RAM) 332 and read only memory (ROM) 334. Data and instructions may transfer data bi-directionally between processor 320 and RAM 332. Data and instructions may transfer data from ROM 334 to processor 320 in one direction. RAM 332 and ROM 334 may include any suitable computer-readable storage medium.

  Computer system 300 includes a persistent storage device 340 that is bi-directionally connected to processor 320. The fixed storage device 340 can be connected to the processor 320 via the storage device control unit 352. Permanent storage 340 can provide additional data storage capacity and can include any suitable computer-readable medium. The persistent storage 340 can store an operating system (OS) 342, one or more executable files 344, one or more applications or programs 346, data 348, and the like. Fixed storage 340 is typically a secondary storage medium (such as a hard disk) that is slower than primary storage. Where appropriate, information stored in persistent storage 340 may be coupled to memory 330 as virtual memory.

  The processor 320 may be connected to various interfaces such as, for example, a graphics control 354, a video interface 358, an input interface 360, an output interface 362, and a storage device interface 364. They can each be connected in turn to a suitable device. Exemplary input or output devices are: video display, trackball, mouse, keyboard, microphone, touch display, transducer card reader, magnetic tape or paper tape reader , Tablet, stylus, speech or handwriting recognition device, biometric reader, or computer system. Network interface 356 may connect processor 320 with another computer system or network 380. Network interface 356 allows processor 320 to read information from network 380 and send information to network 380 while performing steps for a particular embodiment. Certain embodiments may execute alone in processor 320. Certain embodiments may execute together on processor 320 and one or more remote processors.

  In a network environment, when the computer system 300 is connected to the network 380, the computer system 300 can communicate with other devices connected to the network 380. Computer system 300 can communicate with network 380 via network interface 356. For example, computer system 300 can receive information from network 380 (such as a request or response from another device) at network interface 356 as one or more incoming packets. The memory 330 can then store the incoming packet for subsequent processing. The computer system 300 can send information (such as a request or response to another device) from the network interface 356 to the network 380 as one or more outgoing packets. The memory 330 can store it prior to transmission. The processor 320 can access incoming or outgoing packets in the memory 330 and process them as needed.

  The computer system 300 includes one or more input devices 366 (including a keypad, keyboard, mouse, stylus), one or more output devices 368 (including one or more displays, one or more speakers, one or more printers, etc.), One or more storage devices 370 and one or more storage media 372 may be included. The input device 366 may be externally attached to the computer system 300 or may be built therein. The output device 368 may be externally attached to the computer system 300 or may be built therein. The storage device 370 may be externally attached to the computer system 300 or may be built therein. The storage medium 372 may be externally attached to the computer system 300 or may be built therein.

  Certain embodiments include one or more computer-readable storage media that embody software that performs one or more steps for one or more processes described and described herein. Includes the above computer-storage products. In certain embodiments, one or more components of media, software, or both are specifically designed to perform one or more steps for one or more processes described and described herein, Can be manufactured. Additionally or alternatively, in certain embodiments, one or more components of media, software, or both are generally available rather than the process-specific design or manufacture described and described herein. It may be anything. Exemplary computer readable storage media include CD (such as CD-ROM), FPGA, floppy disk, floppy disk, hard disk, holographic storage device, IC (such as ASIC), magnetic tape, This includes but is not limited to cache, PDL, RAM, ROM, semiconductor memory, and other suitable computer readable storage media. In certain embodiments, the software may be a machine language generated by a compiler or one or more files containing high-level code that the compiler can execute using an interpreter.

  By way of example, memory 330 may include one or more computer readable storage media that embody software. The computer system 300 can then provide the specific functions described or described herein as a result of the processor 320 executing its software. The memory 330 can store the software and the processor 320 can execute the software. Memory 330 may read the software from a computer readable storage medium in mass storage device 330 that embodies the software, or from one or more other sources via network interface 356. . When executing the software, the processor 320 may perform one or more steps for one or more processes described or illustrated herein. The process includes defining one or more data structures for storage in the memory 330, and optionally, one or more data structures as directed by one or more components of the software. Including the step of modifying. Additionally or alternatively, the computer system 300 may perform certain functions described or described herein as a result of logic embedded in the hardware or logic embodied in the circuit. Can be offered. The logic operates in place of or in conjunction with software and performs one or more steps for one or more processes described or described herein. This specification includes the appropriate combination of hardware and software, where appropriate.

  Although this specification describes or describes particular operations that occur in a particular order, it is intended that appropriate operations be performed in any suitable order. In addition, this specification contemplates appropriate operations that are repeated one or more times in an appropriate order. This specification describes or describes specific operations that occur in sequence, but is intended to be appropriate operations that are performed substantially simultaneously, if desired. Any suitable operation or sequence of operations described or illustrated herein may be interrupted, suspended, or controlled by other processes, such as an operating system or kernel, as appropriate. obtain. Such an operation may operate in an operating system environment. Alternatively, it can operate as an independent procedure that occupies all or an essential part of the system processing.

  This specification includes all modifications, substitutions, variations, alternatives or improvements to the present exemplary embodiments that will be understood by those skilled in the art. Similarly, where appropriate, the appended claims encompass all modifications, substitutions, variations, alternatives or improvements to the present exemplary embodiments that would be understood by one of ordinary skill in the art.

Claims (28)

A first computer system receiving a software stub including a Uniform Resource Identifier (URI) identifying a downloadable software program from the second computer system;
The first computer system installing the received software stub;
Sending the request for executable code of the downloadable software program, wherein the software stub is a request including the URI;
Through a network connection between said first computer system and said second computer system, said software stub of the first computer system, capable the download in the data stream transmitted from the second computer system Receiving executable code of a software program, wherein the data stream includes executable code of a software program;
Said first computer system extracting executable code of said downloadable software program from said data stream;
Said first computer system allocating dynamic memory for executable code of said downloadable software program;
Execution of the first computer system, the executable code of the downloadable software programs extracted from the data stream, and the direct loading into a dynamic memory allocated, the downloadable software program Possible code is not stored or installed in persistent storage of the first computer system ; and
Said first computer system, loaded into the dynamic memory allocated, by activating the executable code of the downloadable software program, the method comprising executing the downloadable software programs;
Including a method. The data stream is a video stream;
The executable code of the downloadable software program is embedded in the video stream.
The method of claim 1. The executable code of the downloadable software program is machine code or native code.
The method of claim 1. The executable code of the downloadable software program is compressed by the second computer system,
The method of claim 1, further comprising the first computer system deploying executable code of the downloadable software program. The first computer system marking the allocated dynamic memory as containing executable code;
The first computer system coordinates one or more entries in the branch table to execute the allocated dynamic memory and the downloadable software program loaded into the allocated dynamic memory Reflecting in the code;
The method of claim 1, further comprising: The data stream includes a first portion and a second portion;
The first portion of the data stream includes executable code of the downloadable software program;
The second portion of the data stream includes a plurality of data used by the downloadable software program;
The method of claim 1. The first computer system passes a network socket associated with the data stream to the downloadable software program, wherein the data contained in the second portion of the data stream is the software; The method of claim 6, further comprising the step of being used by the downloadable software program during program execution. The method of claim 1, further comprising: the first computer system verifying executable code of the downloadable software program. The method of claim 1, further comprising: the first computer system freeing the allocated dynamic memory after execution of the downloadable software program is complete. The first system is:
Memory having instructions executable by one or more processors;
One or more processors connected to the memory and operative to execute the instructions;
Have
When the one or more processors execute the instructions:
Receiving from the second system a software stub containing a URI (Uniform Resource Identifier) identifying a downloadable software program;
Install the received software stub;
The software stub sends a request for the executable code of the downloadable software program, the request including the URI;
Receiving executable code of the downloadable software program in a data stream transmitted from the second system over a network connection between the first system and the second system, the data stream comprising : Including executable code for software programs;
Extracting executable code of the software program from the data stream;
Allocate dynamic memory for the executable code of the software program;
The executable code of the downloadable software program extracted from the data stream is loaded directly into the allocated dynamic memory, and the executable code of the downloadable software program is the first code Not stored or installed in the system's persistent storage ;
Executing the software program by invoking executable code of the software program loaded into the allocated dynamic memory;
The system that works like The data stream is a video stream;
The executable code of the software program is embedded in the video stream.
The system according to claim 10. The executable code of the software program is machine code or native code.
The system according to claim 10. The executable code of the software program is compressed by the second system,
The one or more processors further function to deploy executable code of the software program when executing the instructions;
The system according to claim 10. When the one or more processors execute the instructions:
Marking the allocated dynamic memory as containing executable code;
Adjusting one or more entries in the branch table to reflect the allocated dynamic memory and the executable code of the software program loaded into the allocated dynamic memory;
The system of claim 10, further functioning as follows. The data stream includes a first portion and a second portion;
The first portion of the data stream includes executable code of the software program;
The second portion of the data stream includes a plurality of data used by the software program;
The system according to claim 10. When the one or more processors execute the instructions:
Further functioning to pass a network socket associated with the data stream to the software program;
The data contained in the second part of the data stream is used by the software program during execution of the software program;
The system according to claim 15. The system of claim 10, wherein the one or more processors are further operative to verify executable code of the software program when executing the instructions. The system of claim 10, wherein the one or more processors are further operative to free the allocated dynamic memory after execution of the software program is complete when executing the instructions. One or more computer-readable storage media when executed by a first computer system;
Receiving a software stub from a second computer system including a URI (Uniform Resource Identifier) identifying a downloadable software program;
Install the received software stub;
Sending the request for the executable code of the downloadable software program, the request including the URI;
Receiving executable code of the downloadable software program in a data stream transmitted from the second computer system over a network connection between the first computer system and the second computer system; and The stream contains the executable code of the software program;
Extracting executable code of the software program from the data stream;
Allocate dynamic memory for the executable code of the software program;
The executable code of the software program extracted from the data stream is loaded directly into the allocated dynamic memory, and the executable code of the downloadable software program is stored in the first computer system. Not stored or installed in persistent storage ;
Executing the software program by invoking executable code of the software program loaded into the allocated dynamic memory;
A computer-readable storage medium embodying software that functions as follows. The data stream is a video stream;
The executable code of the software program is embedded in the video stream.
The storage medium according to claim 19. The executable code of the software program is machine code or native code.
The storage medium according to claim 19. The executable code of the software program is compressed by the second computer system,
The software further functions to deploy executable code of the software program when executed by the first computer system;
The storage medium according to claim 19. When the software is executed by the first computer system:
Marking the allocated dynamic memory as containing executable code;
Adjusting one or more entries in the branch table to reflect the allocated dynamic memory and the executable code of the software program loaded into the allocated dynamic memory;
The storage medium of claim 19, further functioning as follows. The data stream includes a first portion and a second portion;
The first portion of the data stream includes executable code of the software program;
The second portion of the data stream includes a plurality of data used by the software program;
The storage medium according to claim 19. When the software is executed by the first computer system:
Further functioning to pass a network socket associated with the data stream to the software program;
The data contained in the second part of the data stream is used by the software program during execution of the software program;
The storage medium according to claim 24. The software verifies executable code of the software program when executed by the first computer system;
The storage medium according to claim 19. The software, when executed by the first computer system, releases the allocated dynamic memory after the execution of the software program is completed;
The storage medium according to claim 19. A method for distributing software over a computer network,
A processor associated with the server system constitutes a software stub including a URI (Uniform Resource Identifier) identifying a downloadable software program;
The processor sends the software stub for installation to a client system;
The processor enables the client system to map the URI to an IP (Internet Protocol) address of the server system;
The processor receives the request for executable code of the downloadable software program from the software stub, the request including the URI;
The processor includes the downloadable software program such that executable code of the downloadable software program is extracted from a data stream and loaded directly into the allocated dynamic memory of the client system. Constructing a data stream containing executable code, wherein the executable code of the downloadable software program is not stored or installed in persistent storage of the client system;
The processor sends the data stream to the client system;
Method.

Images