Tracking file system read activity for instant play of video games and for discarding and prefetching game data on the client side

Abstract

To provide a client machine and a method for allowing a user to start playing a video game upon acquiring the video game, and before game data is finished downloading to the user's client machine.SOLUTION: In an environment 100 that includes a video game distribution platform, a client machine 104 tracks read operations made by a game executable during a game session, to generate access data based on the tracked read operations, and to report the access data to a remote system. A remote system 106 collects access data 110 reported by a plurality of client machines, catalogues the access data according to client system configuration, analyzes the access data, and generates game data 126 that is usable by the client machines, thereby implementing instant play 128 of a video game.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a PCT application claiming priority to U.S. Patent Application No. 16 / 821,716, entitled "TRACKING FILE SYSTEM READ OPERATIONS FOR INSTANT PLAY OF VIDEO GAMES," filed March 17, 2020, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] Services for distributing personal computer (PC) video games may utilize network-accessible computing platforms to distribute digital copies of video games to PCs. For example, a user may purchase a video game made available through a distribution service and download the video game to the user's PC from a remote computing system over the Internet. Many of today's video games are relatively large, and as a result, it may take a significant amount of time to download the video game. Also, once downloaded to a user's PC, the video game may use a significant amount of disk storage on the PC to store all of its game data. For example, a video game may contain over 100 gigabytes (GB) of game data, which may take several hours to download using existing technology, depending on the download speed of the user's network connection. Unless a video game developer writes the game code in a way that allows the video game to be played with some, but not all, of the game data downloaded to the PC, the user must wait to play the game until the game download is complete. Furthermore, because most games are so large, users often choose to store the game on a hard disk drive (HDD), which offers the most storage space on a PC. However, despite the current availability of large capacity HDDs, local storage capacity is still limited, and HDDs offer relatively slow read access speeds, which can result in latency when a PC loads game data from the HDD during a game session.

[0003] Technical solutions are provided herein to improve and enhance these and other systems. [Brief explanation of the drawings]

[0004] The detailed description is set forth with reference to the accompanying drawings. In each drawing, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. Use of the same reference number in different drawings indicates similar or identical components or features.

[0005] [Figure 1] FIG. 1 illustrates an exemplary environment including a video game distribution platform configured to implement the techniques described herein. [Figure 2] A block diagram illustrating exemplary components of a client machine and an exemplary process flow diagram for tracking file system read operations to generate access data and for transmitting the access data to a remote system are shown. [Figure 3] A block diagram illustrating example components of a remote system for implementing the techniques described herein for accepting access data from client machines and analyzing the access data across one or more users and an example process flow diagram are shown. [Figure 4] FIG. 10 is a flow diagram of an exemplary process for generating download sequence data for use by client machines to download blocks of game data in a particular sequence of blocks based on access data received from multiple client machines. [Figure 5] FIG. 10 is a flow diagram of an example process for generating block dependency data for use by client machines based on access data received from multiple client machines to pre-fetch blocks of game data to reduce latency during game play. [Figure 6] FIG. 10 is a flow diagram of an example process for determining unused blocks of game data based on access data received from a client machine and for instructing the client machine to discard unused blocks of game data. [Figure 7]FIG. 10 is a flow diagram of an exemplary process for discarding unused blocks of game data from non-volatile memory of a client machine. [Figure 8] FIG. 1 is a flow diagram of an exemplary process for running a video game on a client machine before the game has completed downloading. [Figure 9] FIG. 1 is a flow diagram of an exemplary process for pre-fetching blocks of game data to reduce latency during game play. DETAILED DESCRIPTION OF THE INVENTION

[0006] A video game distribution platform may enable users to acquire video games, download digital copies of the video games to their respective client machines, and run the video games using the installed client applications. As users play video games on their client machines, the game executable file of the video game running on each client machine may continuously request blocks of game data for the video game using the client machine's file system. As used herein, "game executable file" means the video game's executable code (e.g., one or more executable files) that, when executed, enables users to play the video game on the client machine by rendering frames based on user input provided via the client machine's input devices. As used herein, "game data" means data read by the game executable file of a video game during its execution through a series of frames. Game data can be used, among other things, to render the video game's graphics, calculate gameplay logic, and / or calculate the video game's physical properties. Examples of game data include, but are not limited to, textures, virtual objects, maps, game characters, parameters and other characteristics of virtual objects, and / or virtual game worlds. Such game data may be stored in memory by dividing the game data into blocks (e.g., uniformly sized blocks), and the file system of the client machine is configured to control how these blocks of game data are stored in and retrieved from the client machine's local memory. When a video game is played on a client machine, each request to read a block of game data made by the game executable file of the video game is referred to herein as a "read operation."Thus, the game executable file of a video game may perform a series of read operations on the file system throughout a game session.

[0007] The techniques, devices, and systems described herein relate to using a file system proxy component of a client machine to track read operations performed by a game executable file of a video game during a game session, generating access data based on the tracked read operations, and reporting the access data to a remote system. An example process implemented by the client machine may include executing a game executable file of the video game for playing the video game on the client machine, determining read operations performed by the game executable file on a file system of the client machine, generating access data based at least in part on the read operations, and transmitting the access data, an identifier of the video game, and a configuration of the client machine to the remote system. The read operations performed by the game executable file may request reading blocks of game data of the video game. Thus, the access data generated by the client machine may specify (i) identifiers of blocks of game data accessed during the game session and (ii) times during execution of the game executable file at which blocks of game data were accessed based at least in part on the read operations.

[0008] This telemetry technique enables a remote system to collect access data reported by multiple client machines, catalog the access data according to client system configuration, and analyze the access data to generate data usable by the client machines to implement various game-related features, including, but not limited to, “instant play” of a video game, discarding unused blocks of game data to free up local memory resources, and / or local pre-fetching of game data to reduce latency during game play. An exemplary process implemented by the remote system may include receiving access data associated with a video game from multiple client machines having a common client system configuration, analyzing the access data, generating data based at least in part on analyzing the access data, and transmitting the data to one or more client machines having the client system configuration. The access data received by the remote system may specify, for each client machine, (i) identifiers of blocks of game data of the video game that were accessed by the game executable file of the video game during execution of the game executable file on the respective client machine, and (ii) the times during execution of the game executable file that the blocks of game data were accessed by the game executable file. Further, the data generated by the remote system based at least in part on analyzing the access data may include at least one of (i) download sequence data specifying the sequence in which at least some of the blocks of game data are downloaded to a client machine having a client system configuration, or (ii) block dependency data specifying individual relationships between two or more blocks of game data.

[0009] As mentioned, one exemplary game-related feature that can be enabled is an “instant play” feature. The instant play feature described herein can allow a user who acquires a video game to begin playing the video game responsive to acquiring the video game and before the download of game data to the user's client machine is complete. Thus, the user does not need to wait until the video game download is complete before starting a game session of the video game. To enable the instant play feature, a remote system may receive access data (as described herein) for a particular video game from multiple client machines, and the remote system may generate download sequence data that specifies a sequence of blocks of game data for the video game based on the access data. This sequence may position blocks that are more likely to be accessed first toward the beginning of the sequence and blocks that are less likely to be accessed first toward the end of the sequence. In this way, when blocks of game data begin downloading to a client machine, the blocks of game data that are most likely to be accessed early during a game session are stored in the client machine's non-volatile memory before downloading other blocks of game data that are less likely to be accessed early during a game session. This allows a user to begin playing a video game responsive to acquiring the video game even while blocks of game data are still being downloaded to the client machine's non-volatile memory. In fact, the techniques and systems described herein allow a user to begin playing a video game even before the first block of game data has completed downloading to the user's client machine.This is enabled at least in part by using a file system proxy component on the client machine, which is configured to receive read operations made by the game executable file and determine whether the requested block of game data has been downloaded to non-volatile memory or whether the block still needs to be completed downloaded. If the block is "realized" in non-volatile memory, this means that the download of the block of game data to non-volatile memory has completed, and the game executable file can read the block of game data using the file system. If the block has not completed downloading to non-volatile memory, the file system proxy component can intercept the read operation, request the unrealized block of game data from the remote system, and, in response to receiving the block from the remote system, read the block using the file system. There may be a brief interruption in the execution of the video game while the unrealized block of game data is retrieved from the remote system, but this is unlikely to occur frequently or at all, assuming that the download of game data begins in response to acquisition of the video game, and assuming that the blocks of game data are downloaded in a sequence that aligns with the sequence in which the game executable file accesses the blocks of data during a game session.

[0010] Another exemplary game-related feature that can be enabled is freeing up local memory resources on a client machine by discarding unused blocks of game data. By freeing up local memory resources, a client machine can reclaim valuable storage capacity that could otherwise be utilized for game data for other video games and / or other data generally. To enable client-side game data discarding, a client machine—on which game data for a video game is stored in non-volatile memory—can execute a game executable file for the video game and generate access data over one or more game sessions when read operations are performed by the game executable file on the client machine's file system. This access data can specify a first subset of blocks of game data accessed over one or more game sessions, as well as the times during which these blocks were accessed during the game sessions. A remote system can receive the access data from the client machine, and based on the access data, the remote system can determine one or more second blocks of game data, which can be classified as “unused” blocks based on blocks that have not been accessed by the game executable file on the client machine for at least a threshold period of time or a threshold number of game sessions. In this case, the remote system may send an instruction to the client machine instructing the client machine to delete one or more second blocks of game data from non-volatile memory. If the client machine deletes these unused blocks from non-volatile memory, storage capacity on the client machine may be increased. Furthermore, if the game executable file requires retrieving the deleted blocks of game data, the file system proxy component of the client machine may request the blocks of game data from the remote system in an on-demand manner, with some additional latency compared to storing the blocks in local memory.

[0011] Another exemplary game-related feature that can be enabled is local prefetching of blocks of game data to reduce latency when loading game data during a game session. To enable the local prefetching feature, a remote system may receive access data (as described herein) from multiple client machines regarding a particular video game, and the remote system may generate block dependency data that specifies individual associations between two or more blocks of game data based on the access data. For example, the block dependency data may indicate that whenever a first block of game data is accessed during a game session, a second block of game data will typically be accessed within a threshold period. In this manner, the block dependency data may describe relationships between blocks of a set of two or more blocks based on access patterns indicated in the access data received at the remote system. The remote system may send the block dependency data to a client machine on which the video game is installed, and when the client machine executes a game executable file for the video game, the client machine can prefetch blocks of game data by caching the blocks in local memory that offers faster read access speeds than memory in which the game data is persistently stored (e.g., non-volatile memory such as an HDD or SD card). This local prefetching can reduce load time latency when the game executable requests to read a block of game data.

[0012] The techniques and systems described herein may improve the gameplay functionality of client machines without requiring game developers to change the way they create video games today. For example, implementing a client-side component such as the file system proxy component described herein allows a user of a client machine to play a video game upon acquiring the video game, meaning the user does not have to wait (potentially for hours) for the game to download before starting a game session. It also allows game data to be intelligently downloaded in a sequence of blocks that positions the blocks most likely to be accessed first at the start of the sequence, which helps reduce wait times during game play while the game data download is in progress. The gameplay functionality of a client machine may additionally or alternatively be improved by pre-fetching game data during a game session according to block dependency data. This is because the client machine can predict which blocks of game data are likely to be accessed next in a series of read operations performed by the game executable file of the video game, and those blocks can be cached in local memory (e.g., volatile memory such as random access memory (RAM)) that offers faster read access speeds than the non-volatile memory in which the game data remains. This "primes" the game data for fast access when the video game requests it.

[0013] The techniques and systems described herein may additionally or alternatively enable one or more devices to conserve resources, at least with respect to memory resources. For example, using access data generated by one or more client machines to determine unused blocks of game data and deleting the unused blocks of game data can free up local memory resources on the client machines. For example, if a client machine and / or a remote system determines from access data associated with tracked file system read operations that a user has never played a game in single-player mode but always plays the game in multiplayer mode, single-player game data for a video game can be deleted from the non-volatile memory of the client machine based on a determination that the blocks have not been used for at least a threshold period of time or a threshold number of game sessions.

[0014] FIG. 1 illustrates an exemplary environment 100 including a video game distribution platform configured to implement the techniques described herein. Users 102 (sometimes referred to as “customers”) of the community may be associated with one or more client machines 104. Accordingly, the client machines 104(1)-(N) shown in FIG. 1 represent computing devices that may be utilized by the user community (or customer base) to run programs such as video games. The client machines 104 may be implemented as any suitable type of computing device configured to process and render graphics on an associated display and to transmit / receive data over a network, including, but not limited to, a PC, a desktop computer, a laptop computer, a mobile phone (e.g., a smartphone), a tablet computer, a portable digital assistant (PDA), a wearable computer (e.g., a virtual reality (VR) headset, an augmented reality (AR) headset, smart glasses, etc.), an in-vehicle (e.g., in-car) computer, a television (smart TV), a set-top box (STB), a game console, and / or any similar computing device.

[0015] The configuration of client machines 104 may vary. For example, a subset of client machines 104 may each use a particular type, version, or characteristics of hardware (e.g., central processing unit (CPU) model, graphics processing unit (GPU) model, etc.) and / or a particular type, version, or characteristics of firmware and / or software (e.g., a certain version of a graphics driver, a downloadable content (DLC) package for use with an installation script, the language in which the video game client runs, etc.). These and other aspects of client machine 104 hardware, firmware, and / or software constitute the “configuration” of client machine 104 and, as used herein, may also be referred to as a “client system configuration,” which may represent a finite set of depots used to download game data (divided into blocks of data) of a video game to a video game distribution platform. Thus, subsets of client machines 104 may share a common client system configuration, and the client system configuration may vary among these subsets of client machines 104. Client machines 104 that differ in client system configuration may download, store, and / or access blocks of game data differently, even for the same video game. Determining whether a pair of client machines 104 have a common client system configuration may be based on the machines 104 sharing a threshold number of common types, versions, or hardware, software, or firmware characteristics. For example, if two client machines 104 use at least the same DLC package for installation scripts, the machines may be considered to have the same client system configuration, even if they differ in some other aspects (e.g., different GPU models, etc.).

[0016] Referring again to FIG. 1 , the client machine 104 may communicate with a remote computing system 106 (sometimes shortened to “remote system 106”) through a computer network 108. This computer network 108 may represent and / or include, but is not limited to, the Internet, other types of data and / or voice networks, wired infrastructure (e.g., coaxial cable, fiber optic cable, etc.), wireless infrastructure (e.g., radio frequency (RF), cellular, satellite, etc.), and / or other connection technologies. The remote system 106 may, in some cases, be part of a network-accessible computing platform that is maintained and accessed via the computer network 108. Such network-accessible computing platforms may be referred to using terms such as “on-demand computing,” “software as a service (SaaS),” “platform computing,” “network-accessible platform,” “cloud services,” “data center,” and the like. In general, the remote system 106 is configured to collect access data 110 from the client machines 104 and to catalog (e.g., organize, categorize, classify, etc.) the access data 110 that it receives in a data store 112. The remote system 106 may also be configured to analyze the access data 110 to generate data usable by the client machines 104 to implement various game-related features described herein. For example, as described herein, the remote system 106 may be configured to generate download sequence data 114 and / or block dependency data 116, and the remote system 106 may deliver this data to the client machines 104.Additionally or alternatively, the remote system 106 may be configured to analyze the access data 110 to determine unused blocks of game data on one or more client machines 104 and may send instructions 118 to the client machines 104 to delete unused blocks of game data in order to free up local memory resources on the client machines 104.

[0017] In some embodiments, the remote system 106 acts as or accesses a distribution service that distributes (e.g., downloads) programs (and data) to the client machine 104. In one example, the client machine 104 may install a client application. The client application, which may be a video game client (e.g., game software for playing a video game), may be configured to run a program, such as a video game, on the client machine 104 on which the client application is installed. With the client application installed, the client machine 104 may then have the ability to download programs (e.g., video games) from the remote system 106 over the computer network 108. To this end, any type of content distribution model may be utilized, such as a direct purchase model in which programs (e.g., video games) are individually purchased for download and execution on the client machine 104, a subscription-based model, a content distribution model in which programs are rented or leased for a period of time, or the like. Thus, an individual client machine 104 may include one or more installed video games that can be executed by loading a client application, and these video games may render graphics on a display during execution. In one embodiment, a user 102 may choose to play one of multiple video games that the user has acquired (e.g., purchased, rented, leased, etc.) and downloaded from a remote system 106, such as by loading a video game client, selecting the desired video game, and starting execution of the video game.

[0018] Consider the example of FIG. 1 , in which several of users 102 play a video game that has been made available to these users 102 by remote system 106. As the video game is played on each of the users' 102's client machines 104, the game executable file running on each client machine 104 may successively make requests to the file system to read blocks of game data for the video game. The read operations performed by the game executable file may be tracked by a file system proxy component of the client machine 104 to generate access data 110. For example, the game executable file running on client machine 104(1) may issue requests to the file system of client machine 104(1) to read blocks of game data from one or more local memory resources of client machine 104(1) during game execution, such as by reading blocks of game data from sectors of a hard disk drive (HDD) or from sectors of a secure digital (SD) card removably coupled to client machine 104(1). Thus, a game executable file for a video game running on client machine 104(1) may perform a series of read operations on the file system throughout a game session, and a file system proxy component on client machine 104(1) may track the read operations to generate access data 110.

[0019] The access data 110 may specify (i) block identifiers that identify accessed blocks of game data of a video game (e.g., blocks accessed by a game executable file during a game session) and (ii) the time, during execution of the game executable file, that the accessed blocks of game data were accessed by the game executable file performing a read operation. As mentioned, game data of a video game may include textures, virtual objects, maps, game characters, etc. In some embodiments, game data may be stored across sectors of non-volatile memory (e.g., sectors of an HDD, SD card, etc.) and organized into blocks of game data within the sectors. Using blocks is a flexible way to handle files of different sizes while avoiding the need to store every file using contiguous storage space in a file system. Each block of game data may be referenced and / or located using a block identifier (e.g., a number). Generally, one or more processors of the client machine 104 may perform read, write, and / or other storage operations as directed by one or more device drivers. In some embodiments, client machine 104 may create a mapping between blocks of game data and sectors of non-volatile memory to determine which blocks are accessed and from where (e.g., which sectors) based on read operations performed by a game executable file during game play. For example, if a game executable file performs a read operation to access game data stored in a first sector of non-volatile memory, an identifier for the particular block of game data stored in the first sector may be specified in access data 110.Additionally, the access times specified in the access data 110 may enable determining the order (or sequence) in which the blocks were accessed during a game session (e.g., block A was accessed first, followed by block D, followed by block F, etc.), as well as the relative times of access (e.g., 4 minutes into the game session, 9 minutes into the game session, 1 hour into the game session, etc.).

[0020] The access data 110 received by the remote system 106 may be cataloged in a data store 112 according to a unique client system configuration and / or according to a video game ID of a corresponding video game. The access data 110 may additionally be stored in association with a user account of a user logged in to a video game client executing on the client machine 104 that sent the access data 110. FIG. 1 illustrates a data store 112 maintained by the remote system 106 for storing, cataloging, or otherwise organizing the access data 110 received from the client machine 104. The data store 112 may organize the access data 110 into groups (or buckets), each associated with a unique combination of client system configuration and video game ID. In other words, each bucket of access data 110 in the data store 112 may be tied to a particular program (e.g., a video game) and to a particular client system configuration, as described herein.

[0021] 1 illustrates a client machine 104(N) sending a request 120 to acquire (e.g., purchase, rent, lease, etc.) a video game from a remote system 106. For example, a user of the client machine 104(N) logging into their user account via an installed video game client may conduct a transaction via the remote system 106 to purchase the video game. In response to the request 120, the client machine 104(N) may receive a game executable file 122 for the video game from the remote system 106, and the client machine 104 may also receive download sequence data 114 and / or block dependency data 116 for the acquired video game and for the particular client system configuration of the client machine 104. Thus, it should be understood that the request 120 may include a configuration of the client machine 104(N), which tells the remote system 106 to locate download sequence data 114 and block dependency data 116 that may be available for that particular client system configuration.

[0022] 1 also depicts the remote system 106 initiating download of blocks 124 of game data 126 for the acquired video game according to a sequence of blocks specified in the download sequence data 114. FIG. 1 illustrates an example where a first block 124(1) is downloaded, followed by a second block 124(2), followed by a third block 124(3), and so on. While FIG. 1 depicts three blocks 124 as being downloaded to the client machine 104(N), it should be understood that the download sequence may include any number of blocks 124, including additional blocks downloaded after block 124(3). The client machine 104(N) may download the blocks 124 to non-volatile memory of the client machine 104(N), such as an HDD, SD card, or the like.

[0023] As shown in FIG. 1 , the client machine 104(N) may implement an instant play 128 feature, in which case the client machine 104(N) may begin executing the game executable file 122 of an acquired video game before or during the download of the block 124 of game data 126. For example, the client machine 104(N) may begin executing the game executable file 122 even before the first block 124(1) of game data is downloaded. The game executable file 122 may begin launching the newly acquired video game in response to user input received by the client machine 104(N), such as by the user 102 if the user uses a mouse and / or keyboard, a game controller, or the like. In this sense, there may be no constraints imposed on the user 102 as to when the user 102 begins playing the video game. As a result, the user 102 may begin playing the game, and the game executable file 122 may begin executing before the first block 124(1) of game data is downloaded to the client machine 104(N). If the user 102 chooses to wait a period of time after acquiring the video game, the game executable file 122 may begin execution after at least one block 124(1) of game data 126 has been downloaded to the client machine 104(N).

[0024] In some embodiments, a video game client running on a client machine 104(N) may be configured to prevent the game executable file 122 from starting until a predetermined time has elapsed since initiating download of blocks 124 or until a predetermined event occurs (e.g., by waiting until a threshold number of blocks 124 have been downloaded before allowing the user 102 to begin playing the game). The predetermined time or event may be determined by the remote system 106 based on how suitable the video game is for the instant play 128 feature, and the remote system 106, upon acquiring the video game, may send instructions to the video game client to wait until the predetermined time period has elapsed and / or until the predetermined event occurs before allowing the game executable file 122 to run on the client machine 104(N). In some embodiments, the remote system 106 may send data to the client machine 104(N) to output a recommendation to the user 102 via the client machine 104(N), such as by displaying a recommendation stating, "For the best user experience, we recommend waiting five minutes after initiating download of [video game X] before playing." In one embodiment, if the video game is sufficiently suitable for the Instant Play 128 feature, the remote system 106 may instruct the client machine 104(N) to output a notification stating, "This game is ready for Instant Play, so you can start playing right away. Have fun!"

[0025] As shown in FIG. 1 , another client machine 104(2) may implement a local prefetching 130 feature, where the client machine 104(2) may prefetch one or more realization blocks 124 of game data 126 to reduce latency during game play. For example, game data 126 of a video game may be stored in a first memory 132(1) that provides read access at a first rate. This first memory 132(1) may represent non-volatile memory, such as an HDD or SD card, on which the game data 126 resides. The client machine 104(2) may also include a second memory 132(2) that provides read access at a second rate that is faster than the first rate. This second memory 132(2) may be additional non-volatile memory (e.g., an SSD) or may be volatile memory (e.g., working memory such as RAM). In either case, block dependency data 116 may be used by client machine 104(2) to determine whether block 124 is likely to be next read by game executable file 122, and if so, block 124 may be cached in second memory 132(2) so that when game executable file 122 eventually requests to read block 124, block 124 can be immediately accessed from second memory 132(2) rather than accessing block 124 from the relatively slower first memory 132(1). As described in more detail below, multiple different local memory resources 132 may be utilized to cache blocks 124 of game data 126 as part of a local prefetching 130 feature, which may improve overall bandwidth and reduce latency much more than caching blocks 124, for example, in working memory alone. This is based on the concept that the game executable file 122 can be read from different local storage resources 132, including the first memory 132(1), in parallel, improving overall bandwidth and further significantly reducing latency.

[0026] 1, yet another client machine 104(1) may implement an unused game data deletion 134 feature, whereby the client machine 104(1) receives instructions 118 from the remote system 106 to delete one or more blocks 124 of game data 126 stored in non-volatile memory of the client machine 104(1), and in response, the client machine 104(1) may delete the one or more blocks 124 to free up local memory on the client machine 104(1). For example, the remote system 106 may determine from the access data 110 received from the client machine 104(1) that the user 102 of the client machine 104(1) has never played a single-player mode of the video game, and as a result, determine that a block 124 of the game data 126 of the video game that is usable for playing the video game in single-player mode has not been accessed by the game executable file 122 for a threshold period of time or a threshold number of game sessions. Thus, remote system 106 may send instructions 118 to one or more client machines 104, such as client machine 104(1), instructing client machine 104 to delete from non-volatile memory therein one or more unused blocks 124 of game data 126 that were previously downloaded to client machine 104 and that were determined to be classifiable as “unused” blocks 124. Instructions 118 may specify identifiers of the unused blocks 124 so that client machine 104(1) can delete the correct blocks 124 of game data 126, thereby freeing up local memory capacity without compromising the user experience of playing the game on client machine 104(1).

[0027] 2 shows a block diagram illustrating exemplary components of a client machine 104, as well as a flow diagram of an exemplary process 200 for tracking file system read operations to generate access data 110 and for transmitting the access data 110 to a remote system 106. In the illustrated implementation, the client machine 104 includes, among other components, one or more processors 202, such as a central processing unit (CPU), a graphics processing unit (GPU), one or more input devices 204, one or more output devices 206, a non-transitory computer-readable medium 208, a local memory 132, and a communication interface 210.

[0028] The non-transitory computer-readable medium 208 may include removable and non-removable media implemented in any method or technology for storing information, such as volatile and non-volatile memory, computer-readable instructions, data structures, program modules, or other logic and / or data. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium that can be used to store desired information and that can be accessed by a computing device. The computer-readable medium 208 may be implemented as a computer-readable storage medium (“CRSM”), which may be any available physical medium accessible by the processor 202 to execute instructions stored on the computer-readable medium 208. In one basic implementation, the CRSM may include random access memory (“RAM”) and flash memory. In other implementations, CRSM may include, but is not limited to, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium that can be used to store desired information and that can be accessed by processor 202. Additionally, while local memory 132 is shown as being separate from computer-readable medium 208, it should be understood that in some implementations computer-readable medium 208 and any one or more of local memories 132(1), 132(2), and / or 132(3) may represent the same memory or at least a portion of the same memory.

[0029] Reference is now made to process 200 shown in FIG. 2. The processes described herein are illustrated as a collection of blocks in a logic flow graph and represent sequences of operations that may be implemented in hardware, software, firmware, or combinations thereof (sometimes referred to herein as "logic"). In the software context, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any some of the described blocks may be combined in any order and / or in parallel to implement a process.

[0030] For purposes of discussion, it is assumed that the client machine 104 performing process 200 has already installed a video game client 212, which represents a client application stored on a computer-readable medium 208 and configured to run a game executable file 122 for the video game. A user 102 of the client machine 104 may acquire (e.g., purchase, rent, lease, etc.) a video game, and in response to that acquisition, the video game may be installed (e.g., downloaded from a remote system 106) and maintained in non-volatile memory. In some embodiments, the first local memory 132(1) (sometimes referred to as “first memory 132(1)”) may represent non-volatile memory (e.g., HDD, SD card, etc.), and the first memory 132(1) may provide read access at a first rate. When a block 124 of game data 126 is downloaded from the remote system 106, the block 124 of game data 126 may be downloaded to the first memory 132(1). Meanwhile, second memory 132(2) may represent additional non-volatile memory (e.g., a solid-state drive (SSD)), and second memory 132(2) may provide read access at a second rate that is faster than the first rate provided by first memory 132(1). Additionally, third memory 132(3) may represent volatile memory (e.g., working memory such as RAM), and third memory 1320(3) may provide read access at a third rate that is faster than the second rate. It should be understood that client machine 104 may implement fewer local memory 132 resources than those shown in FIG. 2 (e.g., by removing second memory 132(2)) or may implement additional local memory 132 resources.

[0031] At 214, the video game client 212 may execute a game executable file 122 of a video game on the client machine 104. For example, a user 102 of the client machine 104 may load the video game client 212, which may provide the user 102 with the ability to run a previously downloaded video game (through the execution of the game executable file 122) and / or obtain new video games from the remote system 106. The game executable file 122 may be loaded into a working memory, such as third memory 132(3), and execute to, among other things, render graphics on the display of the client machine 104. During a game session, there may be a startup phase and a playtime phase. During a game session, the game executable file 122 may be configured to receive input data from the input devices 204 (e.g., a mouse and / or keyboard, a game controller, a head-mounted display (HMD), a microphone, etc.) and may determine which blocks 124 of game data 126 to access to render the next frame of video game content on the display (i.e., the output device 206) of the client machine 104. For example, the game executable file 122 may be configured to determine which portions of the game world to render in the upcoming frame and which objects and / or textures to render in the upcoming frame and may issue a read operation to read the corresponding blocks 124 of the game data 126 for presenting the upcoming frame.

[0032] At 216, a file system proxy component 218 executing on the client machine 104 may determine (e.g., receive, monitor, intercept, etc.) read operations (e.g., first read operation, second read operation, etc.) performed by the game executable file 122 to a file system 220 of the client machine 104. The file system 220 may be configured to control how data, including blocks 124 of game data 126 of the video game, is stored and retrieved. Regardless of whether all of the game data 126 of the video game is embodied in local memory resources such as the first memory 132(1), the file system proxy component 218 may be configured to “lie” to the video game about what blocks 124 (e.g., files) of game data 126 reside in non-volatile memory (e.g., on an HDD, SD card, etc.) of the client machine 104. For example, through the file system proxy component 218, the video game client 212 may learn, based on the identifier of the video game, a list of game files that are expected to be stored in non-volatile memory, the size of the game files, and, if possible, the sectors of non-volatile memory in which the game files are stored. This may, for example, cause the video game (e.g., game executable file 122) to believe that all blocks 124 of game data 126 for the video game are stored in first memory 132(1). The file system proxy component 218 may be an extension of the file system 220 to falsify this information as needed and expose it to the game executable file 122. In any case, consider an example where all blocks 124 of game data 126 for a video game are stored in and accessible from first memory 132(1) of the client machine 104. In this example, the file system proxy component 218 may act as a pass-through, simply monitoring read operations made by the game executable file 122 to the file system 220.As described in more detail herein, particular blocks 124 of game data 126 may be prefetched from first memory 132(1) and cached in at least one of second memory 132(2) or third memory 132(3), both of which provide faster read access speeds than those provided by first memory 132(1). File system 220 may track where blocks 124 of game data 126 are stored at any given moment and may access blocks 124 of game data 126 from the appropriate memory resource 132 to service read operations performed by game executable file 122 during a session.

[0033] At 222, the file system proxy component 218 may generate access data 110 received from the game executable file 122 based at least in part on the read operation. As described elsewhere herein, this access data 110 may specify (i) an identifier of a block 124 of game data 126 accessed by the game executable file 122 during a game session, and (ii) a time during the execution of the game executable file 122 at which the accessed block 124 of game data 126 was accessed by the game executable file 122. For example, with respect to two blocks 124 of game data 126, the access data 110 may specify (i) a first identifier of a first block of game data, (ii) a first time during the execution of the game executable file at which the first block of game data was accessed based at least in part on the first read operation, (iii) a second identifier of a second block of game data, and (iv) a second time during the execution of the game executable file at which the second block of game data was accessed based at least in part on the second read operation. In some embodiments, the access time of each accessed block 124 may be expressed in the access data 110 as a time measured from the start of the game session (e.g., block A was accessed 4 minutes after the game session started, block D was accessed 13 minutes after the game session started, etc.).

[0034] At 224, the client machine 104 may transmit the access data 110 to the remote system 106 via the communication interface 210, through the computer network 108, or the like. The communication interface 210 may implement multiple types of wired and / or wireless or radio technologies. For example, the communication interface 210 may implement a radio, such as a Bluetooth Low Energy (BLE) radio, a Wi-Fi radio, and / or a cellular radio. It should be understood that the communication interface 210 may further include a physical port that facilitates a wired connection to a network, a connected peripheral device, or a plug-in network device that communicates with other wireless networks.

[0035] As shown in sub-block 226, at 224, the access data 110 may be transmitted to the remote system 106 along with the configuration of the client machine 104 and an identifier of the video game. Furthermore, the access data 110 may be transmitted to the remote system 106 at any suitable time, when the access data 110 is generated, and / or in response to an event (e.g., periodically, during a relatively low idle time such as when processing resource consumption is below a threshold percentage of resource consumption, upon resuming network connectivity (e.g., after playing the game offline), after the client machine 104 stops executing the game executable file 122 (e.g., after the user 102 ends the game session by exiting the video game), etc.), in real time or substantially real time, such as by streaming the access data 110 to the remote system 106. The access data 110 may also be transmitted in any suitable format for transmitting metadata resulting from tracked read operations on the client machine 104, such as by transmitting the access data 110 to the remote system 106 as an artifact. Process 200 represents a "telemetry" approach for collecting access data 110 at a remote system 106. Given that a large number of client machines 104 may perform process 200, the remote system 106 may collect access data 110 sent (e.g., uploaded, reported, etc.) at block 224 from a large number of client machines 104 having different client system configurations.

[0036] 3 shows a block diagram illustrating example components of a remote system 106 for implementing the techniques described herein, as well as a flow diagram of an example process 300 for receiving access data 110 from client machines 104 and analyzing the access data 110 across one or more users 102. In the illustrated implementation, the remote system 106 includes, among other components, one or more processors 302, memory 304 (or non-transitory computer-readable medium 304), and a communication interface 306. The memory 304 (or non-transitory computer-readable medium 304) may include volatile and non-volatile memory, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Such memory may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, RAID storage system, or any other medium that can be used to store desired information and that can be accessed by a computing device. Computer-readable medium 304 may be implemented as a computer-readable storage medium (“CRSM”), which may be any available physical medium that is accessible by processor 302 to execute instructions stored on memory 304. In one basic implementation, CRSM may include random access memory (“RAM”) and flash memory. In other implementations, CRSM may include, but is not limited to, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium that can be used to store desired information and that can be accessed by processor 302.The download sequence component 308, the block dependency component 310, and / or the game data usage component 312 may represent instructions stored in the memory 304 that, when executed by the processor 302, cause the remote system 106 to perform the techniques and operations described herein. For example, as described herein, the download sequence component 308 may be configured to generate the download sequence data 114 based on the access data 110. As described herein, the block dependency component 310 may be configured to generate the block dependency data 116 based on the access data 110. As described herein, the game data usage component 312 may be configured to determine unused blocks 124 of the game data 126 on a per-user or per-client machine 104 basis.

[0037] The communication interface 306 may implement multiple types of wired and / or wireless or radio technologies. For example, the communication interface 306 may implement a radio, such as a Bluetooth Low Energy (BLE) radio, a Wi-Fi radio, and / or a cellular radio. It should be appreciated that the communication interface 306 may further include a physical port that facilitates a wired connection to a network, connected peripheral devices, or plug-in network devices that communicate with other wireless networks.

[0038] Reference is now made to process 300 shown in Figure 3. At 314, the remote system 106 may receive access data 110 from a client machine 114 (e.g., as part of a "telemetry" technique using process 200, as described above). The received access data 110 may specify, for a particular client machine 104, identifiers of blocks 124 of game data 126 of a video game that were accessed at the particular client machine 104 by a game executable file 112 of the video game, and the time during the game session (e.g., during execution of the game executable file 122 of the video game). As indicated by sub-block 316, the access data 110 may be received along with the configuration of the particular client machine 104 and along with an identifier of the video game that was executed during the generation of the access data 110.

[0039] At 318, the remote system 106 may catalog the access data 110 received at block 314 by (or according to) the client system configuration and game identifier. For example, the data store 112 may include multiple groups or buckets 320(1)-(M) categorized by unique combinations of game ID and client system configuration. Taking a first client machine 104(1) having client system configuration “1” as an example, upon receiving first access data 110 from the first client machine 104(1) at block 314, the first access data 110 may be cataloged at block 318 into a first bucket 320(1) (or buckets), and at sub-block 316, this bucket 320(1) may be tagged with the game ID of the video game received from the first client machine 104(1) and the client system configuration of the first client machine 104(1). Similarly, a second client machine 104(2) may send second access data 110, which may be cataloged in block 318 in a second bucket 320(2), which may be tagged with the game ID of the video game received from the second client machine 104(2) and the second client system configuration “2” of the second client machine 104(2) in sub-block 316. This may continue for any number of “M” buckets, depending on the number of client machines 104 reporting access data 110, whether the client machines 104 have different client system configurations, and / or the number of different video games running on the client machine 104.

[0040] At 322, the remote system 106 may perform an analysis of the access data 110 received in block 314 to generate data (e.g., results of the analysis). This generated data may include, but is not limited to, a determination of unused blocks 124 of game data 126 based on download sequence data 114 of one or more video games, block dependency data 116 of one or more video games, and / or per-user / per-client machine.

[0041] At 324, the remote system 106 may determine whether a trigger event has occurred. The trigger event may vary, but may include, but is not limited to, receiving a request 120 to acquire (e.g., purchase, rent, lease, etc.) a video game from the client machine 104, generating new download sequence data 114 and / or new block dependency data 116 for the video game, determining that the client machine 104 has unused blocks 124 of game data 126 that have not been accessed for a threshold period of time or a threshold number of game sessions, etc.

[0042] If, at block 324, the remote system 106 determines that a trigger event has not occurred, the process 300 may follow the “No” route from block 324 back to block 314, and the remote system 106 may continue to collect / receive access data 110 from the client machine 104. If, at block 324, the remote system 106 determines that a trigger event has occurred, the process 300 may follow the “Yes” route from block 324 to block 326, and the remote system 106 may send data to one or more client machines 104. For example, if the trigger event includes the client machine 104 acquiring a video game, the remote system 106 may retrieve download sequence data 114 for the video game and send the download sequence data 114 to the client machine 104 along with the game executable file 122 for the video game. Additionally or alternatively, the remote system 106 may retrieve block dependency data 116 for the video game and send the block dependency data 116 to the client machine 104. As yet another example, if the triggering event includes determining that unused blocks 124 of game data 126 are present on the client machine 104, the remote system 106 may send instructions to delete the unused blocks of game data.

[0043] It should be understood that in some embodiments, at least some of the components of the client machine 104 shown in FIG. 2 may be implemented as components of the remote system 106. For example, a game executable file 122 may execute on the remote system 106 (e.g., as part of a video game streaming service), and the game executable file 122 may receive data indicative of user input from the client machine 104 over the network 108 while the video game is being played. In this scenario, game data 126 for the video game may also be stored on the remote system 106, and the file system proxy component 218 may be a component of the remote system 106 that receives read operations from the game executable file 122 and monitors blocks 124 of the game data 126 accessed during gameplay. In this configuration, the client machine 104 may act as a thin client, with most processing occurring in the cloud during a video game session. In another example, the download sequence component 308, the block dependency component 310, and / or the game data usage component 312 may be components of the client machine 104. In this example, the client machine 104 may receive access data 110 generated by other client machines 104 collected by the remote system 106, and the client machine 104 may perform an analysis of its own access data 110 and / or the access data 110 generated by the other client machines 104 to determine download sequence data 114, block dependency data 116, and / or unused blocks 124 of game data 126 stored on the client machine 104.

[0044] FIG. 4 is a flow diagram of an example process 400 for generating download sequence data 114 for use by client machines 104 to download blocks 124 of game data 126 in a particular sequence of blocks 124 based on access data 110 received from multiple client machines 104.

[0045] At 402, the remote system 106 may receive access data 110 related to a video game from multiple client machines 104. The access data 110 received at block 402 may specify, for each client machine 104, (i) an accessed block 124 of game data 126 associated with the video game that was accessed by the game executable file 122 of the video game during execution of the game executable file 122 on the each client machine, and (ii) a time during execution of the game executable file 122 that the accessed block 124 of game data 126 was accessed by the game executable file 122. As indicated by sub-block 404, the access data 110 may be received along with the configuration of the client machine 104 that sent the access data 110 and / or a game identifier of the video game that was executing on the client machine 104 when the access data 110 was generated.

[0046] At 406, the remote system 106 may generate, based at least in part on the access data 110, download sequence data 114 associated with the client system configuration and the game identifier of the video game. The download sequence data 114 may specify a sequence of blocks 124 of game data 126 of the video game, which may represent the order in which the blocks 124 of game data are to be downloaded to a client machine 104 having a particular client system configuration. The download sequence of the video game may be determined in any suitable manner. As indicated by sub-blocks 408 and 410, generating the download sequence data 114 may include multiple sub-operations.

[0047] At 408, statistics (e.g., time, position / order / rank, etc.) may be calculated for at least some blocks 124 of game data 126 of a video game based at least in part on when the blocks 124 were accessed (as specified in access data 110) across N game sessions of N corresponding users 102 who played the video game (where “N” is any positive integer). For example, based on access data 110 associated with the N users 102 who played the video game, the remote system 106 may determine statistics (e.g., average values) based on the amount of time the blocks 124 were accessed by each of the N users 102 during a game session (e.g., during the first game session). The remote system 106 may determine, for example, that the average access time for block A to the first game session was 30 minutes, the average access time for block B to the first game session was 45 minutes, the average access time for block C to the first game session was 2 hours, etc. (e.g., based on multiple different times that block A was accessed by N different users). The remote system 106 may additionally or alternatively determine that, for N users, block A was the first block accessed by user A during an initial game session, block A was the fifth block accessed by user B during the first game session, block A was the seventh block accessed by user C during the first game session, etc. The remote system 106 may then determine statistics (e.g., average position / order / rank) for block A based at least in part on information about when the block was accessed by the N different users 102. This may be repeated for other blocks 124 accessed during the game session. These analyses may be performed for at least the initial game session. Analyses may be performed for any subsequent game sessions as well to determine which blocks 124 of game data 126 are typically accessed during the game session.

[0048] At 410, a download sequence can be determined for multiple blocks 124 of game data 126 for the video game based on the calculated statistics. The blocks 124 specified in the download sequence can be some of the blocks 124 of the game data (e.g., a portion of the total number of blocks 124), or the download sequence can include all of the blocks 124 of the game data 126. It should be understood that for a given video game, the ratio between the initial number of blocks 124 that are likely to be accessed during an initial period of play time and the length of the initial period of play time can be somewhat disproportionate. In other words, 2 gigabytes of game data 126 can provide the first six hours of play time for a particular video game, while the remainder of the game data 126 can be less likely to be accessed during this initial play period. This means that certain games may be well suited for the “instant play” 128 feature, and these games can be flagged as “good instant play games” that are well suited for instant play based on this ratio. In other words, a particular game may be flagged as being able to support a relatively long initial play period with a relatively small amount of game data 126. As an example, a single-player game may be well suited for an “instant play” 128 feature with little or no waiting time, since a new player may be required to play the same level first. This means that for a single-player game, the remote system 106 may determine that all or nearly all players playing the game for the first time will access the same blocks 124 within the first X hours of playtime, and this pattern may be substantially linear and consistent across a set of N players—e.g., all N players may access block A, then block H, block Q, etc.—while there may be discrepancies in the exact times that blocks 124 are accessed, there may be a common order in which blocks 124 are accessed over the initial period of playtime of a given video game.In contrast, a multiplayer game may have an open game world with a large map. For example, across N users, the N users may initially enter the game at different locations in the open world, and each game executable file 122 will have access to different blocks 124 of game data 126 corresponding to the different locations in the open world where the matched players enter the game. This is an example of a game that is not suitable for the instant play 128 feature.

[0049] Assuming the video game can support the instant play 128 feature, the download sequence may specify the order of block A, block D, block G, block C, block F, block E, etc. Thus, for any video game and for any client system configuration, the remote system 106 may determine that, over at least some play time (e.g., the first six hours of play time), the average user 102 is likely to access only a particular subset of the blocks 124 of game data during that play time, and is also likely to access the blocks 124 in a particular sequence. It should be understood that in some embodiments, the download sequence may be user-specific. That is, for the same video game and the same client system configuration, a first download sequence may be determined for a first user 102 and a second download sequence may be determined for a second user 102, where the second download sequence is different from the first download sequence. This may be based on unique access patterns indicated in the user-specific access data 110.

[0050] At 412, the remote system 106 may receive a request 120 to acquire a video game from the client machine 104, the request 120 including a configuration of the client machine 104. For example, a user 102 of the client machine 104 logging into their user account via a video game client 212 may conduct a transaction via the remote system 106 to purchase a video game.

[0051] At 414, the remote system 106 may send a game executable file 122 of the video game to the client machine 104. The game executable file 122 may be executable code (e.g., a file) that is executable by the processor 202 of the client machine 104 to initiate play of the video game on the client machine 104. As indicated by sub-block 416, the remote system 106 may send download sequence data 114 to the client machine 104 to initiate downloading of blocks 124 of game data 126 of the acquired video game in the sequence specified by the download sequence data 114.

[0052] At 418, the remote system 106 may download the blocks 124 of game data to the client machine 104 according to the sequence specified in the download sequence data 114. This may take some time depending on the achievable downlink data rate of the client machine 104. Thus, as the sequence 124 of blocks is downloaded, the blocks 124 that are most likely to be accessed first are realized in the local memory 132 of the client machine 104 before the other blocks, and by the time the game executable file 122 of the video game requests to read the other blocks, those blocks will likely have finished downloading to the client machine 104.

[0053] FIG. 5 is a flow diagram of an example process 500 for generating block dependency data 116 for use by client machines 104 based on access data 110 received from multiple client machines 104 to pre-fetch blocks 124 of game data 126 to reduce latency during game play.

[0054] At 502, the remote system 106 may receive access data 110 related to a video game from multiple client machines 104. The access data 110 received at block 502 may specify, for each client machine 104, (i) an accessed block 124 of game data 126 associated with the video game that was accessed by the game executable file 122 of the video game during execution of the game executable file 122 on the each client machine, and (ii) a time during execution of the game executable file 122 that the accessed block 124 of game data 126 was accessed by the game executable file 122. As indicated by sub-block 504, the access data 110 may be received along with the configuration of the client machine 104 that sent the access data 110 and / or a game identifier of the video game that was executing on the client machine 104 when the access data 110 was generated.

[0055] At 506, the remote system 106 may generate, based at least in part on the access data 110, block dependency data 116 associated with the client system configuration and the game identifier of the video game. The block dependency data 116 may specify individual relationships between two or more blocks 124 of the game data 126 of the video game. In other words, the remote system 106 may predict one or more blocks 124 of the game data 126 that will be accessed when a particular event occurs. In this manner, based on the access data 110, a map of dependencies (e.g., branching, tree-like dependencies) between the blocks 124 of the game data 126 and / or between the blocks 124 and context cues may be constructed. As indicated by sub-blocks 508 and 510, generating the block dependency data 116 may include one or more sub-operations.

[0056] At 508, the remote system 106 may determine an association between a contextual cue and a block 124 of game data 126 of the video game based on access patterns (e.g., access times) indicated in the access data 110 received from the N users 102 who played the video game. For example, the remote system 106 may determine that whenever a particular contextual cue is detected (e.g., whenever a user 102 navigates to a library page of the video game), a particular block 124 of game data 126 is typically accessed within a threshold period (e.g., averaged across the N users). This type of correlation may be determined at least in part based on the access times specified in the access data. For example, across the N users, if block A is the most accessed block within the first 15 seconds by the N users navigating to the library page of the video game, block A may be associated with this type of contextual cue.

[0057] At 510, the remote system 106 may determine associations between pairs of blocks 124 of game data 126 of a video game based on access patterns (e.g., access times) indicated in the access data 110 received from the N users 102 who played the video game. For example, the remote system 106 may determine, based on the access data 110 received from the N users 102 who played the video game, that whenever a first block 124(1) of game data 126 was accessed during a game session, a second block 124(2) of game data 126 was typically accessed during a threshold period. In this manner, the remote system 106 may determine relationships between blocks of a group of two or more blocks 124 based on the access patterns indicated in the access data 110.

[0058] It should be appreciated that in some embodiments, block dependency data 116 may be user-specific. That is, for the same video game and the same client system configuration, a first map of block dependencies may be determined for a first user 102 and a second map of block dependencies may be determined for a second user 102, where the second map differs from the first map. This may be based on unique access patterns indicated in user-specific access data 110.

[0059] At 512, the remote system 106 may transmit the block dependency data 116 to one or more client machines 104. The block dependency data 116 may be transmitted in response to various trigger events. For example, the remote system 106 may transmit the block dependency data 116 of a video game to a client machine 104 in response to a user 102 of the client machine 104 acquiring (e.g., purchasing, renting, leasing, etc.) the video game. As another example, the block dependency data 116 generated at block 506 may represent new data (or updated data) relative to a previous version of the block dependency data 116 of the video game, and in response to generating the new / updated block dependency data 116 at block 506, the remote system 106 may transmit the block dependency data 116 to client machines 104 known to be associated with the owner of the video game. As yet another example, a user may select to have a local prefetching feature implemented on their client machine 104, and in response to the selection, the remote system 106 may send block dependency data 116 to the selected user's client machine 104.

[0060] FIG. 6 is a flow diagram of an example process 600 for determining unused blocks 124 of game data 126 based on access data 110 received from a client machine 104 and for instructing the client machine 104 to discard the unused blocks 124 of game data 126.

[0061] At 602, the remote system 106 may receive access data 110 related to a video game from a client machine 104. The access data 110 received at block 602 may specify (i) an accessed block 124 of game data 126 associated with the video game that was accessed by the game executable file 122 of the video game during execution of the game executable file 122 on the client machine 104, and (ii) a time during execution of the game executable file 122 at which the accessed block 124 of the game data 126 was accessed by the game executable file 122. It should be understood that the remote system 106 may have previously received access data 110 from the same client machine 104 at some time in the past. Thus, the remote system 106 may have access to access data 110 generated over multiple game sessions played on the client machine 104. As indicated by subblock 604, the access data 110 may be received along with the configuration of the client machine 104 that sent the access data 110 and / or the game identifier of the video game that was running on the client machine 104 when the access data 110 was generated.

[0062] At 606, the remote system 106 may determine, based on the access data 110 (and possibly additional access data 110 previously received from the client machine 104), whether any blocks 124 of game data 126 of a video game currently stored in non-volatile memory (e.g., first memory 132(1)) of the client machine 104 can be classified as “unused” blocks 124 of game data 126. As indicated by sub-block 608, this determination may include determining whether individual blocks 124 have not been accessed by the game executable file 122 of the video game on the client machine 104 for a threshold period of time or for a threshold number of game sessions. For example, blocks X-Z of game data 126 may be determined to be unused blocks if they have not been accessed for the past P game sessions (“P” is any suitable integer) or for the last Q weeks (“Q” is any suitable integer, such as the past 10 weeks).

[0063] In some embodiments, other factors are considered when classifying a block 124 of game data 126 as an unused block. For example, the remote system 106 may determine that, across N users of a particular video game, a particular block 124 of game data 126 has been accessed once by the game executable file 122 and has not been accessed again; the remote system 106 may determine that the particular block 124 has already been accessed once, in which case it may designate the block 124 as unused, regardless of how recently the block 124 was accessed by the game executable file 122. Similarly, other heuristics may be used to determine an unused block 124.

[0064] If, at block 606, it is determined that none of the blocks 124 of the game data 126 stored in the non-volatile memory (e.g., the first memory 132(1)) of the client machine 104 can be classified as unused blocks 124, the process 600 may follow a “no” route from block 606 back to block 602, and the remote system 106 may receive (or wait to receive) additional access data 110 from the client machine 104. If, at block 606, it is determined that one or more blocks 124 of the game data 126 stored in the non-volatile memory of the client machine 104 can be classified as unused blocks 124, the process 600 may follow a “yes” route from block 606 to block 610.

[0065] At 610, the remote system 106 may send instructions 118 to the client machine 104 to delete unused blocks 124 of game data 126 from non-volatile memory of the client machine 104. These instructions 118 may include identifiers of the deleted blocks 124. In response to the deletion, local memory resources 132 of the client machine 104 may be freed up, increasing local memory capacity for potentially storing other data therein.

[0066] 7 is a flow diagram of an example process 700 for discarding unused blocks of game data from non-volatile memory of a client machine 104. As indicated by off-page reference "A" in FIGS. 2 and 7, process 700 may continue from block 224 of process 200 after the client machine 104 transmits access data 110 to the remote system 106.

[0067] At 702, the client machine 104 may receive instructions 118 from the remote system 106 to delete one or more blocks 124 of game data 126 of a video game from non-volatile memory. The remote system 106 may determine from access data 110 previously sent by the client machine that the blocks 124 to be deleted represent unused blocks 124 of game data 126 that have not been accessed for a threshold period of time or a threshold number of game sessions.

[0068] At 704, the client machine 104 may delete one or more blocks 124 of game data 126 from non-volatile memory (e.g., first memory 132(1)) based on the instructions 118 received from the remote system 106. As indicated by sub-block 706, the client machine 104 may be configured to wait until the client machine 104 is rebooted before discarding the blocks 124 of game data 126. In this manner, deleting the blocks 124 does not pose any problems, for example, if the user 102 is currently playing a video game (or a different video game). It should be understood that the remaining blocks 124 of game data 126 remain in non-volatile memory after the deletion of the unused blocks 124. Thus, local memory resources 132 may be freed by discarding blocks 124 of game data 126 that are unlikely to be accessed in the future. In an exemplary use case, user 102 may install video game X on their client machine 104, and since installation, user 102 has only ever played video game X online, meaning that user 102 has never played video game X in single-player mode. From access data 110 reported by client machine 104 to remote system 106, remote system 106 may determine that user 102 has not accessed block 124 of game data 126 for single-player mode of video game X over several weeks and / or over a certain number of game sessions since video game X was installed on client machine 104. In this case, the remote system 104 may send an instruction 118 to discard the single-player game data 126 (by identifying one or more blocks 124 corresponding to this game data 126), the client machine 104 may receive the instruction, and the client machine 104 may delete those blocks 124 to free up space in the client machine's 104's non-volatile memory (e.g., first memory 132(1)).

[0069] After deletion, the video game may run normally, and read operations performed by the game executable file 122 continue to occur. In the unlikely event that the game executable file 122 requests to read blocks 124 of game data 126 that were deleted from the non-volatile memory of the client machine 104, the file system proxy component 218 may retrieve such blocks on demand from the remote system 106. In some embodiments, if the deleted blocks 124 are requested to be read by the game executable file 122, such blocks 124 may be re-downloaded to the non-volatile memory of the client machine 104. Implementations of process 700, in conjunction with other processes and / or techniques described herein, may reclaim valuable disk space (e.g., on the order of tens of gigabytes of disk space) on the client machine 104.

[0070] 8 is a flow diagram of an example process 800 for running a video game on a client machine 104 before the game download is complete. The process 800 may be referred to herein as an “instant play” 128 feature because it may allow a user 102 to play a video game upon acquisition of the video game without waiting for game data 126 to be downloaded to the client machine 104.

[0071] At 802, a client machine 104 may send a request 120 to a remote system 106 to acquire (e.g., purchase, rent, lease, etc.) a video game. As indicated by sub-block 804, the request 120 may include configuration of the client machine 104 such that the remote system 106 retrieves the correct download sequence data 114 for the client system configuration.

[0072] At 806, the client machine 104 may receive from the remote system 106 a game executable file 122 of the video game, such as executable code (e.g., one or more files) that is executable by its processor 202 to play the video game on the client machine 104. As indicated by sub-block 808, the client machine 104 may also receive download sequence data 114 associated with the configuration of the client machine 104. This download sequence data 114 may specify a sequence of blocks 124 of game data 126 of the video game.

[0073] At 810, the client machine 104 may begin downloading blocks 124 of game data 126 of the video game to a non-volatile memory (e.g., a first memory 132(1)) of the client machine 104 according to a sequence specified in the download sequence data 114.

[0074] At 812, the client machine 104 may execute the game executable file 122 to start the video game. It should be understood that the user 102 may begin playing the video game, and the game executable file 122 may begin execution, even before the first block 124 of game data 126 has completed downloading. The execution of the game executable file may occur in response to a user input detected by the client machine 104 to start the video game. For example, a user of the client machine 104 may select a user interface element of the video game client 212 to start a video game that the user just obtained via the remote system 106. As mentioned, in some embodiments, the remote system 106 may send data to the client machine 104 to output a recommendation to the user 102 via the client machine 104, such as by displaying a recommendation stating, "For the best user experience, we recommend waiting T minutes after starting the download of [video game X] before playing." In some embodiments, the video game client 212 may prevent the game executable file 122 from running until a threshold period of time has elapsed and / or until a threshold number of blocks 124 have completed downloading in order to provide an optimal user experience. Alternatively, if the video game is particularly well-suited for the instant play 128 feature, the remote system 106 may instruct the client machine 104 to output a notification stating, "This game is ready for instant play, so you can start playing right away. Have fun!" and / or the video game client 212 may not impose any restrictions on when the user 102 can begin playing the video game. In practice, this may be preferable at the beginning of the video game (e.g., to explore the world and configure settings) to begin playing immediately, and perhaps for some players who don't mind a short wait before any game data 126 download is complete.

[0075] At 814, the file system proxy component 218 of the client machine 104 may receive a first read operation made by the game executable file 122 to the file system 220 of the client machine 104. This first read operation may request to read a first block 124(1) of game data 126 of a video game. Because downloading of the game data 126 is in progress (assuming a sizable video game) at the time the read operation is received at block 814, it is possible that the game executable file 122 may request to read an unrealized block 124 of the game data 126, where "unrealized" means that the block 124 of game data has not yet been downloaded to non-volatile memory (e.g., first memory 132(1)) of the client machine 104. In some embodiments, the file system proxy component 218 may temporarily (e.g., for a short period of time) block the read operation in order to make a determination as to whether the requested block 124 is realized in non-volatile memory or if the block 124 still requires downloading (e.g., completion of download).

[0076] Thus, at 816, the file system proxy component 218 may determine whether the first block 124(1) of the game data 126 has been downloaded to non-volatile memory (NVM) of the client machine 104 (i.e., whether the first block 124(1) is “embodied” in non-volatile memory). If the first block 124(1) of the game data 126 is embodied in non-volatile memory of the client machine 104, then upon receiving the read operation at block 814, the process 800 may follow the “yes” route from block 816 to block 818.

[0077] At 718, file system proxy component 218 of client machine 104 may unblock the read operation, and file system 220 may be used to read first block 124(1) of game data 126 from local memory resource 132. If, by chance, first block 124(1) was implemented and prefetched by caching in second memory 132(2) or third memory 132(3) that offers faster read access speeds than first memory 132(1), first block 124(1) may be read from the faster memory 132(2) / (3) in which it is cached. If, at block 816, the first block 124(1) of game data 126 has not been implemented in non-volatile memory of client machine 104, meaning that the first block 124(1) has not completed downloading to non-volatile memory (e.g., first memory 132(1)), process 800 may follow the "No" route from block 816 to block 820.

[0078] At 820, the client machine 104 may send a second request for the first block 124(1) of the game data 126 to the remote system 106. As mentioned, the file system proxy component 218 may intercept and block the read operation. In some embodiments, the call associated with the read operation may be intercepted and blocked within the kernel of the client machine 104, and the file system proxy component 218 may make a callback to the video game client 212 to download the first block 124(1) if it determines that the first block 124(1) has not been implemented.

[0079] At 822, the client machine 104 may receive the first block 124(1) of game data 126 from the remote system 106 over the computer network 108. Following receipt of the first block 124(1) of game data 126, the first block 124(1) of game data 126 may be read using the file system 220. Accordingly, the file system proxy component 218 may temporarily block read operations for at least the unrealized block 124 of the game data 126 until the block 124 is received from the remote system 106. While this may add latency in reading the unrealized block 124 compared to the latency of reading a block 124 that is already realized in the non-volatile memory of the client machine 104, this configuration still enables playing of a video game without downloading all of the game data 126 of the video game. In effect, it enables playing of a video game without storing any game data 126 on the client machine 104. However, because retrieving blocks 124 of game data 126 over computer network 108 adds latency, downloading game data 126 in parallel with game execution ensures that at least some, if not all, of blocks 124 of game data 126 are realized in non-volatile memory by the time game executable file 122 requests that blocks 124 be read, thereby reducing latency. That is, because remote system 106 intelligently determines the download sequence based on access data 110 received from other client machines 104 with the same client system configuration, the likelihood of receiving a read operation requesting that an unrealized block 124 of game data 126 be read is relatively low, and even if possible, is not expected to occur frequently.Instead, by the time a read operation for a given block 124 is performed by the game executable file 122, the given block 124 may already have been downloaded and implemented in non-volatile memory, and thus the game executable file 122 can read the block 124 from the local memory resources 132 of the client machine 104 with less latency than would be involved in retrieving the same block 124 from the remote system 106 over the computer network 108.

[0080] At 824, a determination is made whether the game session of the video game should be ended. For example, if the user 102 quits the video game, process 800 may follow the “Yes” route from block 824 to block 826, and the video game client 212 may stop execution of the game executable file 122. If the game session should not be ended at block 824 (e.g., if the user 102 continues to play the game), process 800 may follow the “No” route from block 824 to block 814, and an additional read operation may be received. As the user 102 continues to play the game, portions of process 800 may be repeated in this manner, with unrealized blocks 124 of game data 126 being retrieved from the remote system 106 on-demand, as needed. This technique of the file system proxy component 218 “lying” to the video game about the blocks 124 available in non-volatile memory can be understood such that, from the video game's frame of reference, the game's content appears to be stored in first memory 132(1). The video game may expect game data 126 to be available from local memory resources 132, and based on various factors (e.g., resources consumed by other running processes, etc.), variable read access speeds may be habitual between client machines 104 and client systems 104, or there may be variations in read access speeds on a single client machine 104. All this means that the approach of process 800 will not crash the video game, even though it may perhaps be a little slower due to retrieving unrealized blocks 124 of game data 126 across wide area network 108.

[0081] Using process 800, users 102 can begin playing a video game as soon as they wish after acquiring the game. Additionally, the technique of process 800 is game agnostic, meaning that no work needs to be done by game developers to enable the instant play 128 feature, but rather enhances the value of all games on a video game distribution platform that distributes video games to a heterogeneous population of client system configurations.

[0082] FIG. 9 is a flow diagram of an example process 900 for pre-fetching blocks 124 of game data 126 to reduce latency during game play.

[0083] At 902, the client machine 104 may receive block dependency data 116 associated with the configuration of the client machine 104 from the remote system 106. This block dependency data 116 may specify individual relationships between two or more blocks 124 of game data 126 of a video game.

[0084] At 904, the client machine 104 may execute a game executable file 122 of the video game to start the video game on the client machine 104. The game executable file 122 may already be available on the client machine 104 because the video game is installed on the client machine 104. The execution of the game executable file 122 allows the user 102 of the client machine 104 to begin playing the game. Furthermore, the execution of the game executable file 122 occurs in response to a user input to start the video game detected by the client machine 104. For example, the user 102 of the client machine 104 may select a user interface element of the video game client 212 to start the video game.

[0085] At 906, a determination may be made as to whether a capacity exceeding a threshold exists in the “prefetch cache.” “Prefetch cache,” as used herein, refers to a cache allocated (or reserved) for prefetched blocks 124 of game data 126. As described herein, second memory 132(2) and / or third memory 132(3)—which provide faster read access speeds than first memory 132(1)—may provide the prefetch cache, and either or both of local memories 132(2) / (3) may be configured for any suitable amount of data, such as 100 megabytes. In this example, as much as 100 megabytes of game data 126 may be prefetched during a game session before game executable file 122 requests that the prefetched game data 126 be read. 100 megabytes is merely an example; the prefetch cache may be configured for a smaller or larger amount of data. Thus, in block 906, the prefetch cache can be monitored to determine how full it is, and if the cache capacity meets or exceeds a threshold amount, additional prefetching of game data 126 can be triggered. This threshold capacity of the prefetch cache, evaluated in block 906, can be set to any suitable amount. For example, if the size of each block 124 of game data 126 is 4096 bytes, the threshold capacity can be set to a capacity of only 4096 bytes, which is enough space to prefetch the block 124 of game data 126. However, the threshold capacity can be set to a larger number of bytes / megabytes to ensure that multiple blocks 124 can be prefetched during a run through the prefetch algorithm.

[0086] In an exemplary use case, a user 102 of a client machine 104 may navigate to a library page of a game, and a set of blocks 124 of game data 126 may be prefetched to fill a 100 megabyte prefetch cache in the second memory 132(2) and / or the third memory 132(3) of the client machine 104. As the user 102 continues to play the video game, the file system 220 may receive calls associated with read operations made by the game executable file 122 to retrieve one or more of the prefetched blocks 124. Instead of accessing the first memory 132(1) of the client machine 104 to retrieve the blocks 124, the file system 220 may access at least one of the second memory 132(2) or the third memory 132(3), where the prefetched blocks 132 are cached, such that the capacity of the prefetch cache begins to increase. If the capacity of this prefetch cache meets or exceeds a threshold, additional prefetching may be triggered to fill the prefetch cache. Thus, at block 906, if there is capacity in the prefetch cache that exceeds the threshold, process 900 may follow the "Yes" route from block 906 to block 908.

[0087] At 908, logic on the client machine 104 may detect an event that is used to determine what blocks 124 of game data 126 to prefetch. For example, at sub-block 910, the detected event may be a context cue (e.g., a user navigating to a video game library page). As another example, at sub-block 912, the detected event may be the file system proxy component 218 receiving a read operation performed by the game executable file 122 to read a particular block 124 of game data 126.

[0088] At 914, logic at client machine 104 may use block dependency data 116 to identify one or more blocks 124 of game data 126 associated with the detected event. For example, if the event detected at block 908 is game executable file 122 requesting to read block A of game data 126, and if block dependency data 116 indicates that block B is likely to be accessed by game executable file 122 within a threshold period of accessing block A, then logic at block 914 may identify block B.

[0089] At 916, the identified blocks 124 may be cached in a local memory 132 that offers faster read access speeds than the first memory 132(1) (e.g., a non-volatile memory such as an HDD, an SD card, etc.), while the game data 126 remains on the client machine 104. Thus, the identified blocks 124 may be cached in at least one of a second memory 132(2) (e.g., an additional non-volatile memory such as an SSD) or a third memory 132(3) (e.g., a volatile working memory such as RAM). As indicated by sub-block 918, if multiple blocks 124 of the game data 126 were identified at 914, the blocks 124 may be cached in multiple different prefetch caches, such as by caching the second blocks 124(2) in the second memory 132(2), caching the third blocks 124(3) in the third memory 132(3), etc. In this manner, prefetched blocks 124 of game data 126 may be distributed across multiple prefetch caches of multiple local memory resources 132 using load balancing techniques, such that some game data 126 is cached in second memory 132(2) and an approximately equal amount of game data 126 is cached in third memory 132(3), even though third memory 132(3) offers faster read access speeds than second memory 132(2). In this manner, prefetched game data 126 may be load balanced to improve the overall throughput of the system in that game data 126 may be accessed in parallel from any and all local memory resources 132 during game play. In this load balancing scheme, it may be the case that 1% of read operations are predicted to access game data 126 from the first memory 132(1), 9% of read operations are predicted to access game data 126 from the second memory 132(2), and 90% of read operations are predicted to access game data 126 from the third memory 132(3).

[0090] At 920, the file system proxy component 218 of the client machine 104 may receive a read operation made to the file system 220 by the game executable file 122, the read operation requesting to read a specific block 124 of the game data 126 of the video game.

[0091] At 922, a determination may be made as to whether the requested block 124 (e.g., by file system 220) is cached in a prefetch cache of a local memory resource (e.g., second memory 132(2) or third memory 132(3)) that offers relatively fast read access speeds. If block 124 is cached in the prefetch cache, process 900 may follow the "yes" route from block 922 to block 924, and block 124 may be read from the prefetch cache. For example, game executable file 122 may read block 124 of game data 126 from second memory 132(2) or third memory 132(3), depending on where block 124 is cached. If block 124 is not cached in the prefetch cache, process 900 may follow the "No" route from block 922 to block 926, where block 124 may be read from first memory 132(1), and game data 126 may remain on client machine 104.

[0092] At 928, a determination is made as to whether the game session of the video game should be ended. For example, if the user 102 quits the video game, process 900 may follow the “Yes” route from block 928 to block 930, and the video game client 212 may stop execution of the game executable file. In some embodiments, if the user 102 restarts the game session and the client machine 104, the game data 126 prefetched to second memory 132(2) may remain stored in a prefetch cache of second memory 132(2) upon restart if second memory 132(2) represents additional non-volatile memory (e.g., an SSD). In this way, if the user 102 starts another game session after restart, the blocks of game data 126 that remain cached in second memory 132(2) can be retrieved therefrom if blocks 124 are required by the game executable file 122 during the subsequent game session. If, at block 928, the game session should not have ended (e.g., the user 102 continues playing the game), the process 900 may follow the "No" route from block 928 to block 906, and the capacity of the prefetch cache is evaluated again, as part of the process 900 repeats starting from block 906. If, at 906, a capacity above the threshold does not exist in the prefetch cache (e.g., the prefetch cache is deemed overfilled with prefetched game data 126), the process 900 may follow the "No" route directly from block 906 to block 920, and the read operation is received by the file system proxy component 218 without prefetching the game data 126 from the prefetch cache.

[0093] Process 900 can reduce loading times during game execution by reducing overall latency compared to accessing game data 126 exclusively from first memory 132(1), with game data 126 remaining on client machine 104. In this manner, a relatively large video game can be stored in first memory 132(1) (e.g., HDD, SD card, etc.), and yet, by the time game executable file 122 requests to read block 124 of game data 126, game data 126 can be intelligently pre-fetched by caching block 124 of game data 126 in third memory 132(2) (e.g., working memory such as RAM, non-volatile memory) and / or in second memory 132(2) (e.g., SSD) in advance of when block 124 is requested by game executable file 122, so that block 124 is likely already cached in a pre-fetch cache to reduce read access time.

[0094] Although the present subject matter has been described in language specific to structural features, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the particular features described. Rather, the particular features are disclosed as exemplary forms of implementing the claims. The inventions described in the claims at the time of filing of this application are as follows: [1] a client machine, one or more processors; A non-transitory computer-readable medium storing computer-executable instructions, the instructions, when executed by the one or more processors, causing the one or more processors to: executing a game executable file of the video game to play the video game on the client machine; determining a first read operation and a second read operation performed by the game executable file to a file system of the client machine, the first read operation requesting to read a first block of game data of the video game and the second read operation requesting to read a second block of game data; generating access data based at least in part on the read operation, the access data comprising: a first identifier for the first block of game data; a first time during execution of the game executable file at which the first block of game data was accessed based at least in part on the first read operation; a second identifier for the second block of game data; and generating a second time during the execution of the game executable file at which the second block of game data was accessed based at least in part on the second read operation; and and transmitting to a remote system the access data, an identifier of the video game, and a configuration of the client machine. [2] 10. The client machine of claim 1, wherein the configuration of the client machine specifies the type, version, or characteristics of hardware, software, or firmware associated with the client machine. [3] The computer-executable instructions further include a non-volatile memory, wherein the video game is a first video game, the game executable file is a first game executable file of the first video game, and the game data is first game data of the first video game, and the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: sending a request to the remote system to obtain a second video game, the request including the configuration of the client machine; From the remote system: a second game executable file for the second video game; and receiving download sequence data associated with the configuration of the client machine, the download sequence data specifying a sequence of blocks of second game data for the second video game; commencing downloading the blocks of the second game data into the non-volatile memory according to the sequence specified in the download sequence data; The client machine described in [1], further configured to execute the second game executable file for playing the second video game on the client machine. [4] The computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving a third read operation performed by the second game executable file to the file system, the third read operation requesting to read a block of the second game data; determining that the block of the second game data has been downloaded to the non-volatile memory; The client machine described in [3], further comprising: reading the block of the second game data using the file system. [5] The computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving a third read operation performed by the second game executable file to the file system, the third read operation requesting to read a block of the second game data; determining that the download of the block of the second game data to the non-volatile memory is not complete; sending a second request for the block of the second game data to the remote system; receiving the block of the second game data from the remote system; The client machine described in [3], further comprising: reading the block of the second game data using the file system. [6] a non-volatile memory configured to store the game data, wherein the plurality of first blocks of game data includes at least the first block of game data and the second block of game data, and wherein the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving instructions from the remote system to delete one or more second blocks of the game data from the non-volatile memory, the one or more second blocks of the game data representing unused blocks of the game data that have not been accessed by the game executable file on the client machine for a threshold period of time or a threshold number of game sessions; The client machine described in [1], further comprising: deleting the one or more second blocks of the game data from the non-volatile memory. [7] a first memory configured to provide read access at a first rate, the first memory storing the game data; a second memory configured to provide read access at a second rate that is faster than the first rate; The computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving, from the remote system, block dependency data associated with the configuration of the client machine, the block dependency data specifying individual associations between two or more of the blocks of the game data; Detecting an event; caching in the second memory the first block of game data or at least one of the two blocks of game data specified in the block dependency data as being associated with the event; receiving at least one of the first read operation or the second read operation; The client machine described in [1], further comprising: reading at least one of the first block of the game data or the second block of the game data from the second memory. [8] a first non-volatile memory configured to provide read access at a first rate, the first non-volatile memory storing the game data; a second non-volatile memory configured to provide read access at a second rate that is faster than the first rate; a volatile memory configured to provide read access at a third rate that is faster than the second rate; The computer-executable instructions, when executed by the one or more processors, cause the one or more processors to: receiving, from the remote system, block dependency data associated with the configuration of the client machine, the block dependency data specifying individual associations between two or more of the blocks of the game data; Detecting an event; caching in the second non-volatile memory the first block of the game data designated in the block dependency data as being associated with the event; caching in the volatile memory the second block of the game data designated in the block dependency data as being associated with the event; receiving the first read operation; reading the first block of the game data from the second non-volatile memory; receiving the second read operation; The client machine described in [1], further comprising: reading the second block of the game data from the volatile memory. [9] 1. A method comprising: executing, by a processor of a client machine, a game executable file of the video game for playing the video game on the client machine; determining, by the processor, a first read operation and a second read operation performed by the game executable file to a file system of the client machine, the first read operation requesting to read a first block of game data of the video game and the second read operation requesting to read the second block of game data; generating, by the processor, access data based at least in part on the read operation, the access data comprising: a first identifier for the first block of game data; a first time during execution of the game executable file at which the first block of game data was accessed based at least in part on the first read operation; a second identifier for the second block of game data; and generating a second time during the execution of the game executable file at which the second block of game data was accessed based at least in part on the second read operation; and transmitting the access data, the video game identifier, and the client machine configuration to a remote system.

[10] the plurality of first blocks of game data include at least the first block of game data and the second block of game data, and the method further comprises: receiving instructions from the remote system to delete one or more second blocks of the game data from non-volatile memory of the client machine, the one or more second blocks of the game data representing unused blocks of the game data that have not been accessed by the game executable file on the client machine for a threshold period of time or a threshold number of game sessions; [9] The method of [9], further comprising deleting the one or more second blocks of the game data from the non-volatile memory.

[11] the video game is a first video game, the game execution file is a first game execution file of the first video game, the game data is first game data of the first video game, and the method comprises: sending a request to the remote system to obtain a second video game, the request including the configuration of the client machine; From the remote system: a second game executable file for the second video game; and receiving download sequence data associated with the configuration of the client machine, the download sequence data specifying a sequence of blocks of second game data for the second video game; commencing downloading the blocks of the second game data into non-volatile memory of the client machine according to the sequence specified in the download sequence data; [9] The method described in [9], further comprising: executing, by the processor, the second game executable file for playing the second video game on the client machine.

[12] receiving, by the processor, a third read operation performed by the second game executable file to the file system, the third read operation requesting reading a block of the second game data; determining that the block of the second game data has been downloaded to the non-volatile memory;

[11] The method of

[11] , further comprising: reading, by the processor, the block of the second game data using the file system.

[13] receiving, by the processor, a third read operation performed by the second game executable file to the file system, the third read operation requesting reading a block of the second game data; determining that the block of the second game data has not completed downloading to the non-volatile memory; sending a second request for the block of the second game data to the remote system; receiving the block of the second game data from the remote system;

[11] The method of

[11] , further comprising: reading, by the processor, the block of the second game data using the file system.

[14] The game data is stored in a first memory of the client machine, the first memory configured to provide read access at a first rate, and the method further comprises: receiving, from the remote system, block dependency data associated with the configuration of the client machine, the block dependency data specifying individual associations between two or more of the blocks of the game data; detecting, by the processor, an event; caching the first block of game data or at least one of the two blocks of game data designated in the block dependency data as being associated with the event in a second memory of the client machine configured to provide read access at a second rate faster than the first rate; receiving, by the processor, at least one of the first read operation or the second read operation; [9] The method described in [9], further comprising reading, by the processor, at least one of the first block of game data or the second block of game data from the second memory.

[15]

[14] The method of

[14] , wherein the detecting the event includes detecting that the game executable file has requested to read the first block of the game data, and the caching includes caching the second block of the game data in the second memory based at least in part on the block dependency data specifying that the second block of the game data is associated with the first block of the game data.

[16] 1. A method comprising: receiving, by a remote system, access data associated with a video game from a plurality of client machines having a common client system configuration, the access data including, for each of the plurality of client machines, at least: a first identifier of a first block of game data of the video game accessed by the game executable file of the video game during execution of the game executable file on a respective client machine; a first time during the execution of the game executable file on the respective client machine that the first block of game data was accessed by the game executable file; a second identifier of a second block of the game data accessed by the game executable file during the execution of the game executable file on the individual client machine; and receiving, specifying a second time during the execution of the game executable file on the respective client machine, at which the second block of game data was accessed by the game executable file; analyzing the access data; generating data by a processor of the remote system and based at least in part on the analyzing the access data, the data comprising: download sequence data that specifies the sequence in which at least the first block of game data and the second block of game data are downloaded to a client machine having the client system configuration; or generating block dependency data including at least one of block dependency data specifying an association between the first block of game data and the second block of game data, or an association between the first block of game data or the second block of game data and an event; transmitting, by the remote system, the data to one or more client machines having the client system configuration.

[17] the data includes the download sequence data, and the method comprises: receiving a request by the remote system and from a client machine having the client system configuration to obtain the video game; transmitting, by the remote system, the game executable file of the video game to the client machine;

[16] The method described in

[16] , further comprising downloading at least the first block of the game data and the second block of the game data to the client machine according to the sequence specified in the download sequence data.

[18] the data includes the download sequence data, and analyzing the access data includes: calculating a first statistic associated with the first block of game data and a second statistic associated with the second block of game data; and determining the sequence based at least in part on the first statistic and the second statistic.

[19] the data includes the block dependency data, and analyzing the access data includes: determining an association between the first block of game data and the second block of game data; or

[16] The method described in

[16] , comprising at least one of determining an association between a context cue and at least one of the first block of game data or the second block of game data.

[20] determining, based at least in part on the access data received from one of the plurality of client machines, that one or more blocks of the game data have not been accessed by the game executable file on the one of the plurality of client machines for a threshold time period or a threshold number of game sessions;

[16] The method described in

[16] further includes sending, by the remote system, to one of the plurality of client machines an instruction to delete the one or more blocks of the game data from non-volatile memory of the one of the plurality of client machines.

Claims

1. 1. A method comprising: sending, by the computing device, a request to a remote system to obtain the program; receiving, by the computing device, executable code of the program from the remote system; initiating downloading, by the computing device, of a plurality of blocks of data of the program into a non-volatile memory of the computing device; executing, by a processor of the computing device, the executable code; until a certain time has elapsed since the download of the plurality of blocks began, or Blocking until a certain event occurs, and executing, by the processor, the executable code on the computing device while at least some of the plurality of blocks are still downloading in response to at least one of the passage of time and the occurrence of the event.

2. The method further comprises: receiving, by the computing device, download sequence data from the remote system specifying a sequence of the plurality of blocks; The method of claim 1 , wherein the plurality of blocks begin downloading in the sequence.

3. the request includes a configuration of the computing device; The method of claim 2 , wherein the download sequence data is associated with the configuration.

4. The method further comprises: receiving, by the processor, a read operation performed by the executable code to a file system of the computing device, the read operation being a request to read one of the plurality of blocks; determining, by the processor, that the block has been downloaded to the non-volatile memory; 2. The method of claim 1, further comprising: reading, by the processor, the block using the file system.

5. The method of claim 1 , wherein the event occurs when a threshold number of blocks have been downloaded to the non-volatile memory.

6. the program comprises a video game; The method of claim 1 , wherein the method comprises outputting, by the computing device, a notification stating that the video game is ready for instant play.

7. 1. A computing device comprising: a processor; a non-transitory computer-readable medium storing computer-executable instructions; The instructions, when executed by the processor, cause the computing device to: sending a request to a remote system to obtain a program; receiving executable code for the program from the remote system; Initiating downloading of a plurality of blocks of data of the program into non-volatile memory of the computing device; Executing the executable code using the processor A certain time has elapsed since the download of the plurality of blocks began, or the occurrence of an event; and in response to at least one of the passage of time and the occurrence of the event, causing the processor to execute the executable code on the computing device while at least some of the blocks are still being downloaded.

8. The computer-executable instructions include: When executed by the processor, further causing the computing device to receive download sequence data from the remote system specifying a sequence of the plurality of blocks; The computing device of claim 7 , wherein the plurality of blocks begin downloading in accordance with the sequence.

9. 9. The computing device of claim 8, wherein the sequence positions the blocks more likely to be accessed first toward the beginning of the sequence and the blocks less likely to be accessed first toward the end of the sequence.

10. The computer-executable instructions, when executed by the processor, further cause the computing device to: receiving, via the processor, a read operation performed by the executable code to a file system of the computing device, the read operation being a request to read one of the plurality of blocks; determining, using the processor, that the block has not completed downloading to the non-volatile memory; sending a second request for the block to the remote system; receiving the block from the remote system; and reading the block using the file system.

11. The computer-executable instructions, when executed by the processor, further causing the computing device to receive instructions from the remote system to wait for at least one of the time to elapse or the event to occur before allowing the executable code to be executed; The computing device of claim 7 , wherein not executing the executable code is based, at least in part, on receiving the instruction from the remote system.

12. the program comprises a video game; The computer-executable instructions, when executed by the processor, The computing device of claim 7 , further causing the computing device to output a notification indicating that the video game is ready for instant play.

13. The computing device of claim 7 , wherein the event occurs when a threshold number of the blocks have finished downloading to the non-volatile memory.

14. The computer-executable instructions, when executed by the processor, the computing device; receiving, via the processor, a read operation performed by the executable code to a file system of the computing device, the read operation being a request to read one of the plurality of blocks; determining, using the processor, that the block has been downloaded to the non-volatile memory; and reading the block using the file system.

15. One or more non-transitory computer-readable media storing computer-executable instructions, The instructions, when executed by a processor of a computing device, cause the computing device to: sending a request to a remote system to obtain a program; receiving executable code for the program from the remote system; Initiating downloading of a plurality of blocks of data of the program into non-volatile memory of the computing device; Executing the executable code using the processor A period of time has elapsed since the blocks began downloading; or the occurrence of a certain event, and one or more non-transitory computer-readable media that cause the processor to execute executable code on the computing device while at least some of the blocks are still downloading in response to at least one of the passage of the time period and the occurrence of the event.

16. The computer-executable instructions include: When executed by the processor, further causing the computing device to receive download sequence data from the remote system specifying a sequence of the plurality of blocks; The one or more non-transitory computer-readable media of claim 15 , wherein the blocks begin downloading according to the sequence.

17. The sequence is 17. The one or more non-transitory computer-readable media of claim 16, wherein the one or more non-transitory computer-readable media are specific to a user of the computing device based at least in part on unique access patterns exhibited in access data associated with the user.

18. the program comprises a video game; 16. The one or more non-transitory computer-readable media of claim 15, wherein the computer-executable instructions, when executed by the processor, further cause the computing device, after initiating the block for playing the video game, to display a recommendation to wait for the time period or a different time period.

19. the program comprises a video game; The computer-executable instructions, when executed by the processor, 16. The one or more non-transitory computer-readable media of claim 15, further causing the computing device to output a notification indicating that the video game is ready for instant play.

20. 16. The one or more non-transitory computer-readable media of claim 15, wherein the event occurs when a threshold number of the blocks have finished downloading to the non-volatile memory.

Images