Source: http://www.google.com/patents/US20050193139?dq=552685
Timestamp: 2014-04-17 01:09:37
Document Index: 695540092

Matched Legal Cases: ['art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500']

Patent US20050193139 - Software streaming system and method - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA method for streaming software may include downloading blocks associated with a software title until an executable threshold is reached, initiating execution of the software title, and continuing to download blocks of the software title while the software title is executed. Another method for streaming...http://www.google.com/patents/US20050193139?utm_source=gb-gplus-sharePatent US20050193139 - Software streaming system and methodAdvanced Patent SearchPublication numberUS20050193139 A1Publication typeApplicationApplication numberUS 11/100,956Publication dateSep 1, 2005Filing dateApr 6, 2005Priority dateJun 16, 1997Also published asUS6453334, US7096253, US7577751, US8509230, US20030056112, US20100023640Publication number100956, 11100956, US 2005/0193139 A1, US 2005/193139 A1, US 20050193139 A1, US 20050193139A1, US 2005193139 A1, US 2005193139A1, US-A1-20050193139, US-A1-2005193139, US2005/0193139A1, US2005/193139A1, US20050193139 A1, US20050193139A1, US2005193139 A1, US2005193139A1InventorsJeffrey Vinson, Steig Westerberg, Jeffrey DeVriesOriginal AssigneeJeffrey Vinson, Steig Westerberg, Devries JeffreyExport CitationBiBTeX, EndNote, RefManReferenced by (11), Classifications (10), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetSoftware streaming system and methodUS 20050193139 A1Abstract A method for streaming software may include downloading blocks associated with a software title until an executable threshold is reached, initiating execution of the software title, and continuing to download blocks of the software title while the software title is executed. Another method for streaming software may include sending to a client data sufficient for the client to build a virtual directory structure for use in executing a software title, streaming a subset of blocks associated with the software title to the client, and streaming additional blocks associated with the software title to the client on demand. A system for streaming software may include a server computer and a client computer. The server computer may include a program database and a streaming engine. In operation the streaming engine may stream an executable streaming application from the program database to the client. Images(8) Claims(21)
The streaming engine 438 determines the best way to stream the files downloaded from server to client, which allows a subscriber to run streaming software before entire package is downloaded. The performance of the streaming engine 438 may be improved by streaming software pre-processing techniques. By way of example but not limitation, streaming software pre-processing may include determining a file dependency order and recording the information into server database (a client may request this information). To arrive at the dependency order, the executable of the software is copied into a new directory with no other files. This executable is executed, and if an error dialog appears, it will describe the dependency file that the main executable is requiring. That dependency file is copied into the directory with the main executable. The main executable is executed, and again if an error dialog appears, it will state the dependency file it requires. This is performed over and over again, until the main executable actually executes and starts running. Another pre-processing technique is file compression. This technique is well-known in the computer-related arts. Another pre-processing technique is to determine the number of files that are required for a program to run. This technique facilitates execution of the program prior to downloading the entire package. The streaming engine 438 is associated with the transactions 314 and 315 of FIG. 3. In the example of FIG. 4, the memory 424 of the client 320 includes an operating system 442, a client shell 444, a cache 446, and an optional browser 448. The memory could, of course, include other software modules or procedures, such as drivers and the like, as is well-known in the computer-related arts. The operating system 442 may include, by way of example but not limitation, Windows 95 (and subsequent releases), Windows NT, or some other operating system. The client shell 444 facilitates access by the server 310, either directly or indirectly, to resources on the client 320. Conceptually, the client shell 444 acts as a layer between the software title and the operating system 442. Thus, a software title that is streamed to the client shell has its own virtual environment including a virtual registry and virtual DLLs. The client shell 444 makes a file system associated with the streaming program on the client 320 available for access. By granting control to the client shell 444, the client shell 444 can execute streaming software in a secure manner. The client shell 444 is executed on the client 320. Advantageously, the client shell 444 can execute streaming software before all the blocks or files associated with the streaming program are downloaded to client 320. The streaming software is executed once the client 320 has downloaded a certain number of files. In a non-limiting embodiment, the client shell 444 continues to download files as a background task while streaming software is executing. In certain embodiments, streaming software execution may be suspended to download a needed block. Thus, if the streaming software �needs� a file resource that is not yet downloaded, the client shell 444 may, by way of example but not limitation, trap the error message and parse out the filename that is needed or missing. For example, in a non-limiting embodiment, the client shell 444 may call, by way of example but not limitation, CreateProcess( ), a Win32 API, to start executing the streaming software, and the client shell 444 uses a debugging property. When an error occurs in the streaming software (e.g., because a file resource is missing), the error may be trapped by the client shell which then can download the appropriate file resource from the server 310. Naturally, before the implementation of the suspension of streaming software, it was still possible to run the streaming software by downloading all necessary files prior to execution, such as by mounting. Thus, suspension of streaming software is a non-limiting aspect of various embodiments. In a non-limiting embodiment, the client shell 444 prompts a subscriber for valid login name and password. In another embodiment, the client shell 444 records when the streaming of streaming software is first started and terminated. Various states get formatted into messages which are, for example, sent to the server 310 or an associated website server. For example, IIS software extensions may be used to send data to a database. The client shell 444 may also be responsible for downloading streaming software. Certain embodiments may include encryption processes. Accordingly, in a non-limiting embodiment, the client shell 444 may decrypt downloaded files, if necessary. In a non-limiting embodiment, an encryption technique is used to prevent subscribers from running streaming software while not connected to the server 320. In a non-limiting embodiment, the encryption technique includes not allowing the subscriber to copy or run streaming software if an ungraceful disconnect occurs between the client 320 and the server 310. This includes, by way of example but not limitation, if a subscriber intentionally disconnects from the server 310 or if any crashes occur, etc. The encryption technique is in contrast to the relatively limited techniques to prevent any purchaser of software from making illegal copies. In a non-limiting embodiment, to improve performance, a subset of files are encrypted. This is because performance will be impacted for every decryption action performed by the client shell 444. In an embodiment, only a main executable file is encrypted. If desired, more files can, of course, be encrypted, but with potential (though not certain) adverse impact on performance. If files other than the executable are decrypted, the client shell 444 will decrypt as the files are downloaded to the client 320. The main executable file will be decrypted in memory just prior to program execution. If files are written to local hard disk unencrypted, streaming software protection is compromised. Certain embodiments may include compression. Compression is used to reduce total number of bytes that have are sent across a network/modem from the server 310 to the client 320. Thus, the client shell 444 may or may not also uncompress blocks of a streaming program prior to use. Watchdog time support was incorporated into a prototype system in December 1996 to make sure streaming software was running and to perform other �watchdog� functions. In a non-limiting embodiment, the client shell 444 can act as a �watchdog� of subscriber running times, and can communicate extensively with the server 310 to, by way of example but not limitation, ensure that a subscriber is accessing appropriate memory resources at any given time. In a non-limiting embodiment, the header of a main executable file may be scrambled so that, even if cached, a subscriber cannot execute the streaming program without using the client shell 444. Of course, in an alternative, the client shell 444 could simply delete one or more files to prevent unauthorized execution of the program. In a non-limiting embodiment, downloaded streaming software can only be run using the client shell 444, which must be coupled somehow to the server 310. In this way, the server 310 can log a subscriber's usage of the streaming software, if desired. The client shell is associated with the transactions 312 to 315 of FIG. 3. In a non-limiting embodiment, the cache 446 is implemented in volatile memory. The cache 446 may be a combination of non-volatile storage and volatile memory. It should be noted that if all files associated with a streaming program are left on the client 320, then, in some cases, performance can be increased if the subscriber uses the streaming program again. If the client shell 444 determines that a next required file is already stored on the client 320 (in the cache 446), then the file need not be downloaded and, if applicable, uncompressed and decrypted. To capitalize on these advantages, caching was added to a prototype system in October 1996. Some files are left in the cache 446 after execution of a streaming program. This allows execution of a �repeat� stream to occur faster. Since files already reside locally in the cache 446, the files don't have to be downloaded again. So long as a sufficient amount of memory is allocated (subject to actual storage limitations at the client 320), the cache 446 can contain every resource required by the streaming program. If the cache 446 is not large enough, then files have to be deleted from the client 320 and downloaded again when needed. There are many known discard priority techniques. The cache 446 is primarily associated with the transaction 315 of FIG. 3. The browser 448 may or may not be required in various embodiments. A user of the client 320 may select software titles using the browser 448, in a manner that is well-known, or some other mechanism could be used. For example, an administrator could assign a software title for streaming to client 320, obviating the need for a browser-based title selection procedure. The browser is associated with the transactions 311 and 312 of FIG. 3. FIG. 5A depicts a flowchart 500A of a method according to an embodiment. The flowchart 500A is intended to illustrate a subscription stage of a client-server model. It may be noted that the method of FIG. 5A is optional since the subscription stage could be conducted using other techniques, such as an administrator adding new subscribers. Moreover, subscription could be assumed for clients on a particular network, such as a company LAN. Accordingly, FIG. 5A is intended to serve as an optional example. In an embodiment, the flowchart 500A starts at module 502 wherein a website is visited. A potential subscriber may visit a website using, by way of example but not limitation, a browser. The website may be maintained by a software title rental, streaming, and/or provisioning entity. In an embodiment, in the flowchart 500A, at decision point 504 it is determined whether to subscribe. A potential subscriber may decide to subscribed (504-Y) by selecting an appropriate link, pressing a button, filling out a form, or some other action that would be known to someone knowledgeable of browsing, for example, the Internet. If a potential subscriber does not decide to subscribe (504-N), then the flowchart 500A ends. Otherwise the flowchart continues at module 506. In an embodiment, the flowchart 500A continues at module 506 wherein subscription information is entered. Potential subscribers may enter optional or required information directly onto the website, send a subscription request, or provide subscription information by some other means. Potential subscribers may sign up for a unique username, password, typical form input, and enter credit information. In an embodiment, the flowchart 500A continues at module 508 wherein a username is checked. The username may be part of the subscription information provided by a potential subscriber. The username must typically be unique, though an alternative embodiment wherein multiple subscribers share the same username is possible. In the event the username is not unique, if uniqueness is required, the potential subscriber may be prompted to enter a different username, be provided with available username suggestions, or be provided with a username. Once subscription information has been received and a (typically unique) username received or assigned, at module 510 a local machine is configured and the flowchart 500A ends. The configuration at module 510 may involve, by way of example but not limitation, modules 512, 514, and 516. In an embodiment, the flowchart 500A continues at module 512 wherein an installation program is downloaded. In a non-limiting embodiment, once the subscriber account is cleared, the subscriber may download and install an installation program, which may include a client shell program. The installation program may be downloaded from a server to a local machine. It may be noted that in an enterprise embodiment, an administrator or technician could configure each machine, rather than downloading the installation program. In an embodiment, the flowchart 500A continues at module 514 wherein an installation program is executed. Again, in an enterprise embodiment, rather than executing an installation program, the client could simply be configured as appropriate. In an embodiment, the flowchart 500A ends at module 516 wherein a local machine is rebooted. An embodiment in which the client is not rebooted is possible. FIGS. 5B and 5C illustrate subsequent steps following subscription and configuration (if necessary) of a local machine, which may be referred to as a client. FIG. 5B depicts a flowchart 500B of a method according to an embodiment. Once a subscription stage, such as, by way of example but not limitation, described with reference to FIG. 5A, has been completed, subscribers can select software title for execution. An example of a method associated with software title execution is described in FIGS. 5B and 5C. It may be noted that at the start of FIG. 5B, a user is assumed to be a subscriber. At the end of FIG. 5C, the subscriber finishes executing a software title (and may or may not logoff). In the example of FIG. 5B, the flowchart 500B starts at module 522 wherein a website is visited. A subscriber may visit a website using, by way of example but not limitation, a browser. The website may be maintained by a software title rental, streaming, and/or provisioning entity. In the example of FIG. 5B, in the flowchart 500B, at decision point 524 it is determined if a title has been selected. A subscriber may select a title (524-Y) by selecting an appropriate link, pressing a button, filling out a form, or some other action that would be known to someone knowledgeable of browsing, for example, the Internet. If a subscriber does not decide to select a title (524-N), then the flowchart 500B loops back to module 522. Otherwise the flowchart 500B continues at module 526. In the example of FIG. 5B, in the flowchart 500B, at decision point 526 it is determined whether a subscriber is logged in. A subscriber may be logged in (526-Y) from a previous session or because, for example, in an enterprise embodiment, a subscriber may automatically login when logging into a typical enterprise account, obviating a login procedure later when obtaining a software title. If a subscriber is not logged in (526-N), then the flowchart 500B continues at module 528 wherein a login dialog is displayed and at module 530 wherein login information is entered. According to an alternative embodiment, once a title selection is made, a token file is downloaded to the local computer, which executes a single instance of a client shell program. If the subscriber has not logged on yet (526-N), the client shell presents a login dialog box on the local machine in order for the subscriber to enter username and password (to login). The login dialog and login information entry is well-known in the art of computer security and is not described in detail herein. In any case, the flowchart 500B loops back to decision point 526, and the subscriber is now (presumably) logged in. If a subscriber is logged in (526-Y), then the flowchart 500B continues at module 532 wherein a validation message is generated and at module 534 wherein the subscriber is validated. In an embodiment, the login information is formatted into a message and sent to a server. The username and password is validated. Typically, a check is also performed to see if the associated account has been disabled. Another check is made to see if the username is already in use; this prevents someone from sharing/loaning their username with someone else. In an enterprise embodiment, this also may promote computer security. Once the subscriber has logged in (and/or has been validated), in the example of 5B, the flowchart 500B continues at module 536 wherein a session is generated. Generating a session may include generating a unique session ID. The unique session ID may be sent back to a client shell associated with the subscriber. In an alternative embodiment, the client shell decodes a token file associated with the generated session, and determines which software title is associated with the token file. In the example of FIG. 5B, the flowchart 500B continues at optional module 538 wherein a dependency string is obtained. It may be noted that a dependency string is not necessary for the purposes of downloading a file. In an embodiment where a software title need not be executed prior to downloading the entire package, a dependency string may not be required and/or desired. A dependency string, according to an exemplary embodiment, includes a file order. If the files are downloaded according to the file order, then the files necessary to begin execution should be received first. In addition to the dependency string, a client may or may not also receive a �minimum number of files� value. This value indicates to the client shell that the client shell should not try to execute until the minimum number of files has been received. In an alternative embodiment, the client shell issues a message with the name of a selected software title. The server checks a program database and returns a �stream� string. The stream string is a string with the software dependencies listed in order. The stream string may also include a number that will tell the client shell the minimum number of files that need to be downloaded before execution. FIG. 5C depicts a flowchart 500C that continues from module 540 (FIG. 5B). In the example of FIG. 5C, the flowchart 500C starts at module 542 wherein a block is downloaded. In an embodiment, a client shell parses a stream string, and starts flipping files in order down to a local machine. Blocks are discrete chunks of the file that are downloaded as part of the streaming procedure. Files are decompressed (if compression is used) and written to the local hard disk in relative order as on, by way of example but not limitation, original CD. If encryption is used, the software title, even though has been written to the local machine's hard disk, should not be able to be executed any other way (command line, network neighborhood, etc.) except from the client shell software. In the example of FIG. 5C, in the flowchart 500C, at decision point 544 it is determined whether a threshold has been reached. In an embodiment, the threshold is a minimum (or greater) number of blocks that must be downloaded before the client executes the software title as a new process. If the threshold has not been reached (544-N), the flowchart 500C loops back to module 542. If, on the other hand, the threshold has been reached (544-Y), then the flowchart 500B continues at module 546 wherein a title is executed as a new process. In the example of FIG. 5C, the flowchart 500C continues at module 548 wherein a start message is generated. In an embodiment, once streaming software is running, the client shell sends a �start-time� message to a database in order to log subscriber usage. In the example of FIG. 5C, in the flowchart 500C, at decision point 550 it is determined whether the software is still running. If the software is still running (550-Y), then at decision point 552 it is determined whether a remote request is required. If no remote request is required (552-N), then presumably the request can be satisfied locally, so the flowchart 500C simply loops back to decision point 550. If, on the other hand, a remote request is required (552-Y), then the flowchart 500C continues at module 554 with suspending the execution of the software title and at module 556 with downloading blocks associated with the request, then looping back to decision point 552 to determine whether another remote request is required. In this way, the client shell may download the rest of the software package either on demand or as a background task. If it is determined that the software title is no longer running (550-N), then the flowchart 500C continues at module 558 wherein a stop message is generated. In an embodiment, when software terminates for any reason, purposely by subscriber or due to a software crash, a message is sent to database to record when software execution ended. This accurately tracks subscriber usage, which may be crucial to a company's billing policy, or may serve other purposes. If the software is some kind of game, high scores may be sent to a database also. In the example of FIG. 5C, in the flowchart 500C, at decision point 560 it is determined whether a logoff has occurred. If a logoff has not occurred (560-N), then the flowchart 500C ends. A logoff may not occur in the case of a software crash or, perhaps, if a subscriber simply closes a program, for example. If, on the other hand, a logoff has occurred (560-Y), then the flowchart 500C continues at module 562 wherein a logoff message is generated, then the flowchart 500C ends. In an embodiment, a subscriber can logout at any point. In this case, the client shell may, by way of example but not limitation, format a message to logoff the subscriber. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7676813Sep 19, 2005Mar 9, 2010Citrix Systems, Inc.Method and system for accessing resourcesUS7680758Sep 30, 2004Mar 16, 2010Citrix Systems, Inc.Method and apparatus for isolating execution of software applicationsUS7908315 *Jan 26, 2006Mar 15, 2011Ancestry.Com Operations Inc.Local installation of remote software systems and methodsUS8171118Jul 31, 2008May 1, 2012Microsoft CorporationApplication streaming over HTTPUS8495625 *Jul 27, 2010Jul 23, 2013Symantec CorporationMethod and system for creation of streamed files on-demandUS8627293 *Mar 19, 2009Jan 7, 2014International Business Machines CorporationDetecting applications in a virtualization environmentUS20090241105 *Mar 19, 2009Sep 24, 2009International Business Machines CorporationDetecting Applications in a Virtualization EnvironmentUS20120185845 *Mar 25, 2012Jul 19, 2012International Business Machines CorporationDetecting Applications in a Virtualization EnvironmentEP2527978A2 *Sep 28, 2006Nov 28, 2012Citrix Systems, Inc.Methods for selecting between a predetermined number of execution methods for an application programWO2007044230A2 *Sep 28, 2006Apr 19, 2007Citrix Systems IncMethods for selecting between a predetermined number of execution methods for an application programWO2010141492A1 *Jun 1, 2010Dec 9, 2010Andrew Buchanan GaultGame execution environments* Cited by examinerClassifications U.S. Classification709/231, 717/176International ClassificationG06F11/30, G06F21/00, G06F15/16, G06F9/445Cooperative ClassificationG06F21/6218, G06F9/445European ClassificationG06F21/62B, G06F9/445Legal EventsDateCodeEventDescriptionFeb 15, 2013FPAYFee paymentYear of fee payment: 4Dec 26, 2012ASAssignmentOwner name: NUMECENT HOLDINGS, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:STREAMTHEORY, INC.;REEL/FRAME:029526/0310Effective date: 20121022Jun 13, 2011ASAssignmentOwner name: STREAMTHEORY, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GAMEWAVE, INC.;REEL/FRAME:026431/0554Effective date: 19981207Jun 9, 2011ASAssignmentOwner name: GAMEWAVE, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:VINSON, JEFFREY;WESTERBERG, STEIG;DEVRIES, JEFFREY;SIGNING DATES FROM 19980715 TO 19980805;REEL/FRAME:026420/0239RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google