Tracking file system read operation for instant play of video game, and for client-side discarding and prefetching of game data

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 specification 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 on March 17, 2020, the entire contents of which are incorporated herein by reference.

Background Art

[0002] Services for delivering personal computer (PC) video games can utilize a network-accessible computing platform to deliver a digital copy of a video game to a PC. For example, a user can purchase a video game available via a delivery service, and this video game can be downloaded from a remote computing system to the user's PC over the Internet. Many of today's video games are relatively large, and as a result, it can take a significant amount of time to download a video game, and once the video game is downloaded to the user's PC, it can use a significant amount of disk storage on the PC to store all of its game data. For example, a video game can include over 100 gigabytes (GB) of game data, which can take several hours to download using existing techniques depending on the download speed of the user's network connection. Unless the video game developer has written the game code in such a way that the video game can be played with only a portion, rather than all, of the game data downloaded to the PC, the user must wait to play the game until the download of the game is complete. Further, because most games are very large, users often choose to store the game on a hard disk drive (HDD) that provides the most storage space on the PC. However, despite the current usefulness of large-capacity HDDs, local storage capacity is still limited, and the HDD provides a relatively slow read access speed, which can result in latency when the PC loads game data from the HDD during a game session.

[0003] This specification provides technical solutions for improving and enhancing these systems and other systems.

Brief Description of the Drawings

[0004] A detailed description will be given with reference to the attached drawings. In each drawing, the leftmost digit of the reference number identifies the drawing in which the reference number first appears. The use of the same reference number in different drawings indicates similar or identical components or features.

[0005]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Modes for Carrying Out the Invention

[0006] A video game delivery platform may enable users to obtain video games, download digital copies of the video games to each user's client machine, and execute the video games using the installed client application. When a user plays a video game on their client machine, the game execution file of the video game running on each client machine may continuously request to read blocks of the game data of the video game using the file system of the client machine. As used herein, "game execution file" means the execution code of a video game (e.g., one or more executable files), and when this execution code is executed, it enables the user to play the video game on the client machine by rendering frames based on user input provided via the input device of the client machine. As used herein, "game data" means the data read by the game execution file during the execution of the game execution file of a video game through a series of frames. Game data can be used, among other things, to render the graphics of a video game, calculate game play logic, and / or calculate the physical characteristics of a video game. 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 can be stored in memory by dividing the game data into several 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 local memory of the client machine. Each request to read a block of game data made by the game execution file of a video game when the video game is played on a client machine is referred to herein as a "read operation".Therefore, the game execution file of a video game can perform a series of read operations on the file system throughout the 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 execution 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 exemplary process implemented by the client machine can include executing a game execution file of a video game to play the video game on the client machine, determining read operations performed by the game execution file on the 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 execution file can require reading blocks of game data of the video game. Thus, the access data generated by the client machine can specify (i) identifiers of blocks of game data accessed during the game session and (ii) times during the execution of the game execution 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 configurations, and analyze the access data to generate data that can be used by client machines to implement various game-related features, including, but not limited to, "instant play" of video games, discarding unused blocks of game data to free local memory resources, and / or locally prefetching game data to reduce latency during game play. An exemplary process implemented by the remote system can include receiving access data related to a video game from multiple client machines having a common client system configuration, analyzing the access data, generating data at least in part based 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 can specify, for an individual client machine, (i) identifiers of blocks of game data of the video game accessed by the game execution file of the video game during execution of the game execution file on the individual client machine, and (ii) the time during execution of the game execution file at which the block of game data was accessed by the game execution file. Further, based at least in part on analyzing the access data, the data generated by the remote system can include at least one of (i) download sequence data specifying a sequence in which at least a portion of a block of game data is to be downloaded to a client machine having the 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 the "Instant Play" feature. The Instant Play feature described herein enables a user who acquires a video game to start playing the video game in response to acquiring the video game and before the download of the game data to the user's client machine is complete. Thus, the user does not need to wait for the download of the video game to complete before starting a game session of the video game. To enable the Instant Play feature, the remote system may receive access data (as described herein) regarding a particular video game from a plurality of client machines, and the remote system may generate download sequence data that specifies a sequence of blocks of the game data of the video game based on the access data. This sequence may position blocks that are more likely to be accessed first towards the beginning of the sequence and blocks that are less likely to be accessed first towards the end of the sequence. In this way, when a block of the game data starts to be downloaded to the client machine, the block of the game data that is most likely to be accessed initially during the game session is stored in the non-volatile memory of the client machine before other blocks of the game data that are less likely to be accessed initially during the game session are downloaded. This enables the user to start playing the video game in response to acquiring the video game even while blocks of the game data are still being downloaded to the non-volatile memory of the client machine. In practice, the techniques and systems described herein enable the user to start playing the video game even before the first block of the game data has completed downloading to the user's client machine.This is at least partially enabled by using a file system proxy component on the client machine, which is configured to receive read operations performed by the game execution file and to determine whether a requested block of game data has been downloaded to the non-volatile memory or whether the block still needs to complete the download. If a block is "realized" within the non-volatile memory, this means that the download of the block of game data to the non-volatile memory has been completed and the game execution file can read the block of game data using the file system. If the block has not completed the download to the non-volatile memory, the file system proxy component may block 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, be able to read the block using the file system. While the unrealized block of game data is being retrieved from the remote system, there may be a short interruption in the execution of the video game, but assuming that the download of the game data starts in response to the acquisition of the video game and also assuming that the blocks of game data are downloaded in a sequence that aligns with the sequence in which the game execution file accesses the blocks of data during the game session, this is likely to occur infrequently or not at all.

[0010] Another exemplary game-related feature that can be enabled is to free up local memory resources on the client machine by discarding unused blocks of game data. By freeing up local memory resources, the client machine can reuse valuable memory capacity that can be utilized for game data of other video games and / or other data in general. To enable the discarding of client-side game data, the client machine - on which the game data of the video game is stored in non-volatile memory - can execute the game execution file of the video game and can generate access data through one or more game sessions when a read operation is performed on the file system of the client machine by the game execution file. This access data can specify a first subset of blocks of game data that were accessed over one or more game sessions, as well as the times at which these blocks were accessed during the game session. The 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 were not accessed by the game execution file on the client machine over at least a threshold period or a threshold number of game sessions. In this case, the remote system can send an instruction to the client machine instructing the client machine to delete one or more second blocks of game data from the non-volatile memory. If the client machine deletes these unused blocks from the non-volatile memory, the storage capacity on the client machine can be increased. Further, if the game execution file requests to read a deleted block of game data, the file system proxy component of the client machine can request a block of game data from the remote system in an on-demand manner, with some additional latency compared to storing the block on local memory.

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

[0012] The techniques and systems described herein can improve the game-play functionality of a client machine without requiring game developers to change how they create today's video games. For example, implementing client-side components such as the file system proxy component described herein enables a user of the client machine to play a video game in response to acquiring the video game, which means that the user does not need to wait (potentially for hours) for the game to download before starting a game session. It also enables intelligent downloading of game data 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 is being downloaded. The game-play functionality of the client machine can be improved additionally or alternatively by prefetching game data during a game session according to block-dependent data. This is because the client machine can predict which blocks of game data are likely to be accessed next in a sequence of read operations performed by the game executable file of the video game, and such blocks can be cached in local memory (e.g., volatile memory such as random access memory (RAM)) that provides a faster read access speed than the non-volatile memory in which the game data resides. 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, by 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, local memory resources on the client machines can be freed. For example, if the client machine and / or remote system determines from access data related to tracked file system read operations that the user has never played the game in single-player mode and has always played the game in multiplayer mode, single-player game data of the 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 or a threshold number of game sessions.

[0014] FIG. 1 is a diagram illustrating an exemplary environment 100 that includes a video game delivery platform configured to implement the techniques described herein. Community users 102 (sometimes referred to as "customers") may be associated with one or more client machines 104. Thus, client machines 104(1)-(N) shown in FIG. 1 represent computing devices that can be utilized by a user community (or customer base) to execute programs such as video games. Client machines 104 can be a PC, desktop computer, laptop computer, mobile phone (e.g., smartphone), tablet computer, portable digital assistant (PDA), wearable computer (e.g., virtual reality (VR) headset, augmented reality (AR) headset, smart glasses, etc.), in-vehicle (e.g., in an automobile) computer, television (smart TV), set-top box (STB), game console, and / or any similar computing device, not limited to these, and can be implemented as any suitable type of computing device configured to process graphics and render them on an associated display, and to send / receive data over a network.

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

[0016] Referring back to FIG. 1, client machine 104 may communicate with a remote computing system 106 (sometimes abbreviated as "remote system 106") through 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. Remote system 106 may, in some cases, be part of a network-accessible computing platform that is maintained and accessed via computer network 108. Such a network-accessible computing platform may be referred to using terms such as "on-demand computing", "software as a service (SaaS)", "platform computing", "network-accessible platform", "cloud service", "data center", etc. Generally, remote system 106 is configured to collect access data 110 from client machine 104 and also to catalog (e.g., systematize, categorize, classify, etc.) the access data 110 received within data store 112. Remote system 106 may also be configured to analyze the access data 110 to generate data that can be used by client machine 104 to implement various game-related features described herein. For example, as described herein, remote system 106 may be configured to generate download sequence data 114 and / or block dependency data 116, and remote system 106 may distribute this data to client machine 104.The remote system 106 may additionally or alternatively be configured to analyze access data 110 to determine unused blocks of game data on one or more client machines 104, and may also send instructions 118 to the client machines 104 to delete the 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 execute 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 through the computer network 108. For this purpose, any type of content distribution model can be utilized, such as a direct purchase model where programs (e.g., video games) can be individually purchased to be downloaded and executed on the client machine 104, a subscription-based model, or a content distribution model where the program is rented or leased over a period of time. Thus, an individual client machine 104 may include one or more installed video games that are executable by loading the client application, and these video games may render graphics on a display during execution. In one example, the user 102 may load a video game client, select a desired video game, and choose to play one of the multiple video games that the user has obtained (e.g., purchased, rented, leased, etc.) and downloaded from the remote system 106, such as by starting the execution of the video game.

[0018] Consider the example of FIG. 1, where some of the users 102 play video games made available to these users 102 by the remote system 106. When a video game is played on each client machine 104 of the users 102, the game execution file operating on each client machine 104 may continuously make requests to the file system to read blocks of game data of the video game. The read operations performed by the game execution file may be tracked by the file system proxy component of the client machine 104 to generate access data 110. For example, the game execution file operating on the client machine 104(1) may issue requests to the file system of the client machine 104(1) to read blocks of game data from sectors of a hard disk drive (HDD) or from sectors of a secure digital (SD) card removably attached to the client machine 104(1) during game execution, such as by reading blocks of game data from one or more local memory resources of the client machine 104(1). Thus, the game execution file of the video game executed on the client machine 104(1) can perform a series of read operations on the file system over the entire game session, and the file system proxy component of the client machine 104(1) can track the read operations and generate access data 110.

[0019] Access data 110 may specify (i) a block identifier that identifies a block of accessed game data of a video game (e.g., a block accessed by a game execution file during a game session), and (ii) the time at which the block of accessed game data was accessed by the game execution file during the execution of the game execution file. As mentioned, the game data of a video game may include textures, virtual objects, maps, game characters, etc. In some embodiments, the 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 within 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 when instructed by one or more device drivers. In some embodiments, the client machine 104 may create a mapping between blocks of game data and sectors of non-volatile memory to determine which blocks were accessed and from where (e.g., which sectors) based on read operations performed by the game execution file during game play. For example, if the game execution file performs a read operation to access game data stored in a first sector of non-volatile memory, the identifier of a particular block of game data stored in the first sector may be specified in the access data 110.Furthermore, the access time specified in the access data 110 can enable determination of the order (or sequence) in which blocks were accessed during a game session (e.g., block A was accessed first, followed by block D, and then followed by block F, etc.), as well as the relative time 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 can be cataloged in the data store 112 according to a unique client system configuration and / or according to the video game ID of the corresponding video game. The access data 110 can additionally be stored in association with the user account of the user logged into the video game client running on the client machine 104 that transmitted the access data 110. FIG. 1 shows 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 can 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 the access data 110 in the data store 112 can be associated with a particular program (e.g., a video game) and a particular client system configuration, as described herein.

[0021] FIG. 1 shows a client machine 104(N) that sends a request 120 to obtain (e.g., purchase, rent, lease, etc.) a video game from a remote system 106. For example, a user of the client machine 104(N) who logs into his or her user account via an installed video game client may perform a transaction via the remote system 106 to purchase a video game. In response to the request 120, the client machine 104(N) may receive from the remote system 106 a game execution file 122 of the video game, and the client machine 104 may also receive download sequence data 114 and / or block dependency data 116 of the obtained video game and of the specific client system configuration of the client machine 104. Thus, it should be understood that the request 120 may include the configuration of the client machine 104(N), and this configuration tells the remote system 106 to look for download sequence data 114 and block dependency data 116 that may be available for that specific client system configuration.

[0022] FIG. 1 also depicts a remote system 106 that starts downloading blocks 124 of game data 126 of the obtained video game according to the sequence of blocks specified in the download sequence data 114. FIG. 1 shows an example where the first block 124(1) is downloaded, followed by the second block 124(2), followed by the third block 124(3), etc. Three blocks 124 are depicted in FIG. 1 as being downloaded to the client machine 104(N), but it should be understood that the download sequence may include any number of blocks 124, including additional blocks that are 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, an SD card, etc.

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

[0024] In some embodiments, the video game client operating on client machine 104(N) may be configured to prevent the game execution file 122 from starting until a predetermined time has elapsed since the download of block 124 began, or until a predetermined event occurs (e.g., by waiting until a threshold number of blocks 124 have been downloaded before allowing user 102 to start playing the game). The predetermined time or event may be determined by remote system 106 based on how well-suited the video game is for the instant play 128 feature, and remote system 106 may send the video game client an instruction to wait until a predetermined period has elapsed and / or until a predetermined event occurs before allowing the game execution file 122 to operate on client machine 104(N) in response to the acquisition of the video game. In some embodiments, remote system 106 may send the client machine 104(N) data for outputting a recommendation to user 102 via the client machine 104(N), such as by displaying a recommendation stating "For the best user experience, it is recommended to wait 5 minutes after starting the download of [Video Game X] before playing." In one example, if the video game is well-suited for the instant play 128 feature, 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 now. Have fun!"

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

[0026] As shown in FIG. 1, yet another client machine 104(1) may implement the unused game data deletion 134 feature, and the client machine 104(1) receives, from the remote system 106, an instruction 118 to delete one or more blocks 124 of game data 126 stored in the non-volatile memory of the client machine 104(1). In response, the client machine 104(1) can 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 access data 110 received from the client machine 104(1) that the user 102 of the client machine 104(1) has never played the single-player mode of a video game, and as a result, the blocks 124 of game data 126 of the video game that are available for playing the video game in single-player mode have not been accessed by the game execution file 122 over a threshold period or a threshold number of game sessions. Thus, the remote system 106 may send the instruction 118 to one or more client machines 104, such as the client machine 104(1), instructing the client machine 104 to delete one or more unused blocks 124 of game data 126 that were previously downloaded to the client machine 104 and determined to be classifiable as "unused" blocks 124 from the non-volatile memory therein. The instruction 118 may specify the identifier of the unused block 124 such that the client machine 104(1) can delete the correct block 124 of the game data 126, thereby freeing up local memory capacity without degrading the user experience of playing the game on the client machine 104(1).

[0027] FIG. 2 illustrates an exemplary block diagram of components of client machine 104, as well as a flowchart of an exemplary process 200 for tracking a file system read operation to generate access data 110 and for transmitting access data 110 to remote system 106. In the illustrated implementation, 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, local memory 132, and a communication interface 210.

[0028] The non-transitory computer-readable medium 208 can 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 technologies, 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 can be accessed by a computing device. The computer-readable medium 208 can be implemented as a computer-readable storage medium ("CRSM") that can 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 can include random access memory ("RAM") and flash memory. In other implementations, the CRSM can 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 can be accessed by the processor 202. Further, although the local memory 132 is shown as being separate from the computer-readable medium 208, it should be understood that in some implementations, the computer-readable medium 208, and any one or more of the local memories 132(1), 132(2), and / or 132(3) can represent the same memory or at least a portion of the same memory.

[0029] Now, refer to process 200 shown in FIG. 2. The processes described herein are illustrated as a group of blocks within a logic flow graph and represent an operational sequence that can be implemented in hardware, software, firmware, or a combination thereof (sometimes referred to herein as "logic"). In the context of software, a block represents computer-executable instructions, which perform the recited operations when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular abstract data type. The order in which the operations are described is not intended to be construed as a limitation, and any of the several described blocks may be combined in any order and / or in parallel to implement the process.

[0030] For purposes of the examination, assume that client machine 104 that performs process 200 already has video game client 212 installed thereon, which represents a client application stored on computer-readable medium 208 and configured to execute game execution file 122 for a video game. User 102 of client machine 104 may obtain (e.g., purchase, rent, lease, etc.) a video game, and in response to such obtaining, the video game may be installed (e.g., downloaded from remote system 106) and maintained in non-volatile memory. In some embodiments, first local memory 132(1) (which may also be referred to as "first memory 132(1)") may represent non-volatile memory (e.g., HDD, SD card, etc.), and first memory 132(1) may provide read access at a first speed. When block 124 of game data 126 is downloaded from remote system 106, block 124 of game data 126 may be downloaded to first memory 132(1). On the other hand, second memory 132(2) may represent additional non-volatile memory (e.g., solid state drive (SSD)), and second memory 132(2) may provide read access at a second speed that is faster than the first speed 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 132(3) may provide read access at a third speed that is faster than the second speed. It should be understood that client machine 104 may implement fewer local memory 132 resources than 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 can execute a game execution file 122 of a video game on the client machine 104. For example, the user 102 of the client machine 104 can load the video game client 212, and the loaded video game client 212 can provide the user 102 with the ability to execute a previously downloaded video game (via execution of the game execution file 122) and / or acquire a new video game from the remote system 106. The game execution file 122 can be loaded into a working memory such as a third memory 132(3), and in particular, it is executed to render graphics on the display of the client machine 104. During a game session, there can be a startup phase and a playtime phase. During the game session, the game execution file 122 can be configured to receive input data from an input device 204 (such as a mouse and / or keyboard, game controller, head-mounted display (HMD), microphone, etc.), and can also determine a block 124 of game data 126 to access in order to render the next frame of video game content on the display of the client machine 104 (i.e., the output device 206). For example, the game execution file 122 can be configured to determine which part of the game world to render in the current frame, as well as which objects and / or textures to render in the current frame, and can issue a read operation to read the corresponding block 124 of game data 126 for presenting the current frame.

[0032] In 216, the file system proxy component 218 running on the client machine 104 can determine (e.g., receive, monitor, block, etc.) the read operations (e.g., the first read operation, the second read operation, etc.) performed by the game execution file 122 on the file system 220 of the client machine 104. The file system 220 can be configured to control how data including the blocks 124 of the 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 realized in local memory resources such as the first memory 132(1), the file system proxy component 218 can be configured to "lie" to the video game regarding which blocks 124 (e.g., files) of any game data 126 are present in the non-volatile memory of the client machine 104 (e.g., in an HDD, an SD card, etc.). For example, the video game client 212 can, via the file system proxy component 218, know a list of game files that are thought to be stored in the non-volatile memory, the sizes of the game files, and, if possible, the sectors of the non-volatile memory in which the game files are stored, based on the identifier of the video game. This can make the video game (e.g., the game execution file 122) think that all of the blocks 124 of the game data 126 of the video game are stored in the first memory 132(1). The file system proxy component 218 can be an extension of the file system 220 for forging this information as needed and presenting it to the game execution file 122. In any case, consider an example where all of the blocks 124 of the game data 126 of the video game are stored in and accessible from the first memory 132(1) of the client machine 104. In this example, the file system proxy component 218 can act as a pass-through that simply monitors the read operations performed by the game execution file 122 on the file system 220.As will be described in more detail herein, certain blocks 124 of game data 126 can be prefetched from a first memory 132(1) and cached in at least one of a second memory 132(2) or a third memory 132(3), both of which provide a read access speed faster than the read access speed provided by the first memory 132(1). The file system 220 can track where a block 124 of game data 126 is stored at any given moment and access the block 124 of game data 126 from the appropriate memory resources 132 to provide the read operations performed by the game execution file 122 during a session.

[0033] In 222, the file system proxy component 218 may generate access data 110 received from the game execution file 122 based at least in part on a read operation. As described elsewhere in this specification, this access data 110 may include (i) an identifier of a block 124 of game data 126 accessed by the game execution file 122 during a game session, and (ii) the time during the execution of the game execution file 122 at which the accessed block 124 of game data 126 was accessed by the game execution 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 execution 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 execution 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 represented in the access data 110 as the 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, client machine 104 may send access data 110 to remote system 106 via communication interface 210 and through computer network 108, among other means. Communication interface 210 may implement multiple types of wired and / or wireless or radio technologies. For example, communication interface 210 may implement radios such as Bluetooth Low Energy (BLE) (registered trademark) radio, Wi-Fi radio, and / or cellular radio. It should be understood that 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, access data 110 can be transmitted along with the configuration of client machine 104 and the identifier of the video game. Further, access data 110 can be streamed to remote system 106 in real-time or substantially in real-time, etc., by streaming access data 110 to remote system 106 at any suitable time, when access data 110 is generated, and / or in response to an event (e.g., periodically, during relatively low idle times such as when the processing resource consumption is less than a threshold percentage of the resource consumption, when the network connection is resumed (e.g., after playing a game offline), after client machine 104 stops executing the game execution file 122 (e.g., after user 102 ends the game session by exiting the video game), etc.). Access data 110 can also be transmitted in any suitable format for transmitting metadata resulting from tracked read operations on client machine 104, such as by transmitting access data 110 to remote system 106 as an artifact. Process 200 represents a "telemetry" approach for collecting access data 110 at remote system 106. Considering that a number of client machines 104 can perform process 200, remote system 106 can collect access data 110 transmitted (e.g., uploaded, reported, etc.) from a very large number of client machines 104 having different client system configurations at block 224.

[0036] FIG. 3 illustrates an exemplary block diagram of components of a remote system 106 for implementing the techniques described herein, as well as a flowchart of an exemplary process 300 for receiving access data 110 from a client machine 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, a memory 304 (or non-transitory computer-readable medium 304), and a communication interface 306. The memory 304 (or non-transitory computer-readable medium 304) can 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 data. Such memory can include, by way of example and not limitation, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) 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 the desired information and that can be accessed by a computing device. The computer-readable medium 304 can be implemented as a computer-readable storage medium (“CRSM”), which can be any available physical medium that is accessible by a processor 302 for executing instructions stored on the memory 304. In one basic implementation, the CRSM can include random access memory (“RAM”) and flash memory. In other implementations, the CRSM can include, by way of example and not limitation, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium that can be used to store the desired information and that can be accessed by the 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 download sequence data 114 based on access data 110. As described herein, the block dependency component 310 may be configured to generate block dependency data 116 based on access data 110. As described herein, the game data usage component 312 may be configured to determine unused blocks 124 of game data 126 based on a per-user or per-client machine 104.

[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 radios such as Bluetooth Low Energy (BLE)® radio, Wi-Fi radio, and / or cellular radio. It should be understood that the communication interface 306 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.

[0038] Now, refer to process 300 shown in FIG. 3. At 314, remote system 106 may receive access data 110 from client machine 114 (e.g., as part of the "telemetry" approach using process 200 as described above). The received access data 110 can specify, for a particular client machine 104, an identifier of a block 124 of game data 126 of a video game accessed by a game execution file 112 of the video game on the particular client machine 104, and the time at which block 124 was accessed during a game session (e.g., during execution of the game execution file 122 of the video game). As indicated by sub - block 316, 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 executed during 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 a plurality of groups or buckets 320(1)-(M) classified by a unique combination of game ID and client system configuration. Taking as an example a first client machine 104(1) having a client system configuration "1", at block 314, when the first access data 110 is received from the first client machine 104(1), at block 318, the first access data 110 may be cataloged in the first bucket 320(1) (or group), and in 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 transmit second access data 110, and at block 318, this second access data 110 may be cataloged in the second bucket 320(2), which may be tagged in sub-block 316 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). This can continue across 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 being executed on the client machines 104.

[0040] At 322, the remote system 106 may analyze the access data 110 received at block 314 to generate data (e.g., the result of the analysis). Examples of such generated data may include, but are not limited to, download sequence data 114 for one or more video games, block dependency data 116 for one or more video games, and / or determination of unused blocks 124 of game data 126 based on per-user / client machines.

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

[0042] In block 324, if the remote system 106 determines that no trigger event has occurred, the process 300 may follow the "no" route back from block 324 to block 314, and the remote system 106 may continue to collect / receive access data 110 from the client machine 104. In block 324, if 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 obtaining a video game, the remote system 106 may retrieve the download sequence data 114 for the video game and may also send the download sequence data 114 to the client machine 104 along with the game execution file 122 of the video game. Additionally or alternatively, the remote system 106 may retrieve the block dependency data 116 for the video game and may send the block dependency data 116 to the client machine 104. As yet another example, if the trigger event includes determining that there are unused blocks 124 of game data 126 present on the client machine 104, the remote system 106 may send an instruction to delete the unused blocks of the game data.

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

[0044] FIG. 4 is a flow diagram of an exemplary process 400 for generating download sequence data 114 that client machine 104 uses 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 a plurality of client machines 104. The access data 110 received at block 402 may, for each individual client machine 104, (i) the accessed block 124 of game data 126 associated with the video game, which was accessed by the game execution file 122 of the video game during the execution of the game execution file 122 on the individual client machine, and (ii) the time during the execution of the game execution file 122 when the accessed block 124 of game data 126 was accessed by the game execution file 122. As indicated by sub-block 404, the access data 110 may be received together with the configuration of the client machine 104 that sent the access data 110 and / or the game identifier of the video game executed on the client machine 104 when the access data 110 was generated.

[0046] At 406, the remote system 106 may generate download sequence data 114 associated with the client system configuration and the game identifier of the video game, based at least in part on the access data 110. The download sequence data 114 may specify a sequence of blocks 124 of the game data 126 of the video game, and this sequence may represent the order in which the blocks 124 of the game data are 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, the generation of the download sequence data 114 may include a plurality of sub-operations.

[0047] At 408, through N game sessions of the corresponding N users 102 who played the video game (where "N" is any positive integer), statistics (e.g., time, position / order / rank, etc.) can be calculated for at least some of the blocks 124 of the game data 126 of the video game, at least partially based on when the block 124 was accessed (as specified in the access data 110). For example, based on the access data 110 associated with the N users 102 who played the video game, the remote system 106 can determine statistics (e.g., average value) based on the time when the block 124 was accessed by each of the N users 102 during the game session (e.g., during the first game session). The remote system 106 can determine, for example, that the average access time of block A to the first game session was 30 minutes (e.g., based on multiple different times when block A was accessed by N different users), the average access time of block B to the first game session was 45 minutes, the average access time of block C to the first game session was 2 hours, etc. The remote system 106 can additionally or alternatively determine, for the N users, that block A was the first block accessed by user A during the first 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., and then the remote system 106 can determine statistics (e.g., average position / order / rank) of block A based at least partially on information regarding when the block was accessed by the N different users 102. This can be repeated for other blocks 124 accessed during the game session. These analyses can be performed for at least the initial game sessions. The analyses can also be performed similarly for any subsequent game sessions to determine which blocks 124 of the game data 126 are typically accessed during the game session.

[0048] At 410, based on the calculated statistics, a download sequence can be determined for a plurality of blocks 124 of game data 126 of a video game. The blocks 124 specified by 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 first few 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 unbalanced. In other words, 2 gigabytes of game data 126 can provide the first 6 hours of play time of a particular video game, and the remainder of the game data 126 can be less likely to be accessed during this first play period. This means that a particular game can be well-suited for the "instant play" 128 feature, and based on this ratio, these games can be flagged as "good instant play games" that are well-suited for instant play. In other words, a particular game can be flagged if it can be supported by a relatively small amount of game data 126 for a relatively long initial play period. As an example, a single-player game can be well-suited for the "instant play" 128 feature with little or no waiting time because new players may need to play the same level first. This means that for a single-player game, the remote system 106 can determine that all or almost all players playing the game for the first time will access the same blocks 124 within the first X hours of play time, and this pattern can be substantially linear and consistent across a group of N players - for example, all N players can access block A, then block H, block Q, etc. There may be discrepancies in the exact times at which the blocks 124 are accessed, but there can be a common order of blocks 124 accessed over the initial period of play time of a given video game.In contrast, a multiplayer game can have an open game world with a vast map. For example, across N users, the N users can first enter the game at different locations in the open world, and each game execution file 122 will access different blocks 124 of game data 126 corresponding to 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 that a video game can support the instant play 128 feature, the download sequence can specify an order such as 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 can determine that over at least a certain play time (e.g., the first 6 hours of play time), on average, user 102 is likely to access only a specific subset of blocks 124 of the game data and is likely to access the blocks 124 in a specific sequence during that play time. It should be understood that in some embodiments, the download sequence can be user-specific. That is, for the same video game and the same client system configuration, a first download sequence can be determined for a first user 102, a second download sequence can be determined for a second user 102, and the second download sequence can be different from the first download sequence. This can be based on the unique access pattern shown in the user-specific access data 110.

[0050] At 412, the remote system 106 may receive a request 120 from the client machine 104 to obtain a video game, and the request 120 includes the configuration of the client machine 104. For example, a user 102 of the client machine 104 who logs in to their user account via the video game client 212 may perform a transaction via the remote system 106 to purchase a video game.

[0051] At 414, the remote system 106 may send the game execution file 122 of the video game to the client machine 104. This game execution file 122 may be executable code (e.g., a file) that can be executed by the processor 202 of the client machine 104 to start playing the video game on the client machine 104. As shown by sub-block 416, the remote system 106 may send the download sequence data 114 to the client machine 104 so that the client machine 104 can start downloading the block 124 of the game data 126 of the obtained video game in the sequence specified by the download sequence data 114.

[0052] At 418, the remote system 106 may download the block 124 of the game data to the client machine 104 according to the sequence specified by the download sequence data 114. This may take some time depending on the achievable downlink data transfer speed of the client machine 104. Thus, since the sequence of blocks 124 is being downloaded, the block 124 that is most likely to be accessed first is realized in the local memory 132 of the client machine 104 before other blocks, and by the time the game execution file 122 of the video game requests to read other blocks, it is likely that the download of those blocks to the client machine 104 has been completed.

[0053] FIG. 5 is a flowchart of an exemplary process 500 for generating block dependency data 116 used by client machines 104 based on access data 110 received from a plurality of client machines 104 to prefetch blocks 124 of game data 126 and reduce waiting times during game play.

[0054] At 502, remote system 106 may receive access data 110 related to a video game from a plurality of client machines 104. The access data 110 received at block 502 may, for each individual client machine 104, (i) the accessed blocks 124 of game data 126 associated with the video game that were accessed by the game execution file 122 of the video game during execution of the game execution file 122 on the individual client machine, and (ii) the time during execution of the game execution file 122 at which the accessed blocks 124 of game data 126 were accessed by the game execution 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 transmitted the access data 110 and / or the game identifier of the video game executed on the client machine 104 when the access data 110 was generated.

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

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

[0057] At 510, the remote system 106 can determine the relationship between pairs of blocks 124 of the game data 126 of the video game based on the access pattern (e.g., access time) shown in the access data 110 received from N users 102 who played the video game. For example, the remote system 106 can determine that when the first block 124(1) of the game data 126 is accessed during a game session, the second block 124(2) of the game data 126 is typically accessed during a threshold period, based on the access data 110 received from N users 102 who played the video game. In this way, the remote system 106 can determine the relationship between blocks of a group of two or more blocks 124 based on the access pattern shown in the access data 110.

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

[0059] At 512, the remote system 106 may send block - dependency data 116 to one or more client machines 104. The block - dependency data 116 may be sent in response to various trigger events. For example, the remote system 106 may send the block - dependency data 116 of a video game to the client machine 104 in response to a user 102 of the client machine 104 acquiring (e.g., purchasing, renting, leasing, etc.) a 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 new / updated block - dependency data 116 at block 506, the remote system 106 may send the block - dependency data 116 to the client machine 104 known to be associated with the owner of the video game. As yet another example, a user may select to have a local pre - fetching feature implemented on their client machine 104, and in response to the selection, the remote system 106 may send the block - dependency data 116 to the client machine 104 of the selected user.

[0060] FIG. 6 is a flowchart of an exemplary 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 the client machine 104. The access data 110 received at block 602 may be (i) the accessed block 124 of game data 126 associated with the video game, which was accessed by the game execution file 122 of the video game during the execution of the game execution file 122 on the client machine 104, and (ii) the time during the execution of the game execution file 122 when the accessed block 124 of the game data 126 was accessed by the game execution file 122. It should be understood that the remote system 106 may have access data 110 previously received at some point in the past from the same client machine 104. Thus, the remote system 106 may have access to access data 110 generated through multiple game sessions played on the client machine 104. As shown by sub-block 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 executed on the client machine 104 when the access data 110 was generated.

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

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

[0064] In block 606, if it is determined that none of the blocks 124 of the game data 126 stored in the non-volatile memory of the client machine 104 (e.g., the first memory 132(1)) can be classified as unused blocks 124, the process 600 may follow the "no" route that returns from block 606 to block 602, and the remote system 106 may receive (or wait to receive) additional access data 110 from the client machine 104. In block 606, if 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 the "yes" route from block 606 to block 610.

[0065] In block 610, the remote system 106 may send a command 118 to the client machine 104 to delete the unused blocks 124 of the game data 126 from the non-volatile memory of the client machine 104. These commands 118 may include identifiers of the blocks 124 to be deleted. In response to the deletion, the local memory resources 132 of the client machine 104 are freed, increasing the local memory capacity and potentially allowing other data to be stored therein.

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

[0067] At 702, the client machine 104 may receive from the remote system 106 an instruction 118 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 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., the first memory 132(1)) based on 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 restarted before discarding the blocks 124 of game data 126. In this way, for example, when the user 102 is currently playing a video game (or a different video game), deleting the blocks 124 does not cause any problems. It should be understood that the remaining blocks 124 of the game data 126 remain in the non-volatile memory after the deletion of the unused blocks 124. Thus, the 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, the user 102 may install video game X on their client machine 104, and after installation, the user 102 has only played video game X online so far, which means that the user 102 has never played video game X in single-player mode. From the access data 110 reported by the client machine 104 to the remote system 106, the remote system 106 may determine that the user 102 has not accessed the blocks 124 of the game data 126 for the 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 the 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 these blocks 124 to free up space in the non-volatile memory (e.g., the first memory 132(1)) of the client machine 104.

[0069] After deletion, the video game can be executed as normal, and the read operation performed by the game execution file 122 continues to occur. In the unlikely event that the game execution file 122 requests to read the block 124 of game data 126 deleted from the non-volatile memory of the client machine 104, the file system proxy component 218 can retrieve such blocks on demand from the remote system 106. In some embodiments, if the deleted block 124 is requested to be read by the game execution file 122, such block 124 can be redownloaded to the non-volatile memory of the client machine 104. Implementations of the process 700 can reuse beneficial disk space (e.g., disk space on the order of dozens of gigabytes) on the client machine 104, along with other processes and / or techniques described herein.

[0070] FIG. 8 is a flowchart of an exemplary process 800 for executing a video game on the client machine 104 before the game download is complete. Since the process 800 can allow the user 102 to play the video game in response to the acquisition of the video game without waiting for the game data 126 to be downloaded to the client machine 104, it may also be referred to herein as the "instant play" 128 feature.

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

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

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

[0074] At 812, client machine 104 may execute game execution file 122 to start a video game. It should be understood that the user 102 may start playing the video game and the game execution file 122 may start execution even before the first block 124 of game data 126 has completed downloading. Execution of the game execution file may occur in response to user input detected by client machine 104 to start the video game. For example, a user of client machine 104 may select a user interface element of video game client 212 to start the video game that the user just now obtained via remote system 106. As mentioned, in some embodiments, remote system 106 may send data to client machine 104 for outputting a recommendation to user 102 via client machine 104, such as by displaying a recommendation stating "For the best user experience, it is recommended to wait for T minutes after starting the download of [Video Game X] before playing." In some embodiments, video game client 212 may block execution of game execution file 122 until a threshold period has elapsed and / or until a threshold number of blocks 124 of the download have completed, in order to provide an optimal user experience. Alternatively, if the video game is particularly well-suited for the instant play 128 feature, remote system 106 may instruct 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 video game client 212 may impose no restrictions when user 102 becomes able to start playing the video game. In practice, this may be preferable for some players who do not mind a slight wait time at the start of the video game to start playing immediately (e.g., when exploring the world and making settings) and perhaps even before the download of any game data 126 has completed.

[0075] At 814, the file system proxy component 218 of the client machine 104 may receive a first read operation performed on the file system 220 of the client machine 104 by the game execution file 122. This first read operation may request to read a first block 124(1) of the game data 126 of the video game. Since the download of the game data 126 is in progress at the time the read operation is received at block 814 (assuming a fairly large video game), there is a possibility that the game execution file 122 requests to read an unrealized block 124 of the game data 126. "Unrealized" means that the block 124 of the game data has not yet been downloaded to the non-volatile memory (e.g., the 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 time) block the read operation to determine whether the requested block 124 is realized in the non-volatile memory or if the block 124 still requires a download (e.g., completion of the download).

[0076] Accordingly, 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 the non-volatile memory (NVM) of the client machine 104 (i.e., whether the first block 124(1) has been "realized" in the non-volatile memory). If the first block 124(1) of the game data 126 is realized in the non-volatile memory of the client machine 104, at the time the read operation is received at block 814, the process 800 may follow the "yes" route from block 816 to block 818.

[0077] At 718, the file system proxy component 218 of the client machine 104 can unblock a read operation, and the file system 220 can be used to read the first block 124(1) of the game data 126 from the local memory resource 132. Incidentally, if the first block 124(1) is realized and prefetched by caching it in a second memory 132(2) or a third memory 132(3) that provides a faster read access speed than the first memory 132(1), the first block 124(1) can be read from the faster memory 132(2) / (3) in which it is cached. At block 816, if the first block 124(1) of the game data 126 is not realized in the non-volatile memory of the client machine 104, this means that the download of the first block 124(1) to the non-volatile memory (e.g., the first memory 132(1)) is not complete, and the process 800 can follow the "no" route from block 816 to block 820.

[0078] At 820, the client machine 104 can 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 can block and prevent the read operation. In some embodiments, the call associated with the read operation can be blocked and prevented within the kernel of the client machine 104, and the file system proxy component 218 can make a callback to the video game client 212 to download the first block 124(1) if it is determined that the first block 124(1) is not realized.

[0079] At 822, client machine 104 may receive a first block 124(1) of game data 126 from remote system 106 via 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 file system 220. Accordingly, file system proxy component 218 may temporarily block the read operation, at least for the unrealized blocks 124 of game data 126, until block 124 is received from remote system 106. This may add latency when reading the unrealized blocks 124 compared to the latency of reading blocks 124 that have already been realized in the non-volatile memory of client machine 104, but this configuration still enables playing a video game without downloading all of the game data 126 of the video game. In fact, it enables playing a video game without actually storing any of the game data 126 on client machine 104. However, since latency is added by retrieving blocks 124 of game data 126 via computer network 108, the operation of downloading game data 126 in parallel with game execution ensures that at least some, if not all, of the blocks 124 of game data 126 are realized in non-volatile memory by the time the game execution file 122 requests to read block 124, thereby reducing latency. That is, since 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 that requests reading an unrealized block 124 of game data 126 is relatively low and is not expected to occur frequently, even if possible.Instead, before the read operation of a given block 124 is performed by the game execution file 122, the given block 124 may already have been downloaded to and realized in the non-volatile memory, and thus, the game execution file 122 can read the block 124 from the local memory resources 132 of the client machine 104 with a waiting time less than the waiting time involved when searching for the same block 124 from the remote system 106 through the computer network 108.

[0080] At 824, a determination is made as to whether the game session of the video game should end. For example, if user 102 stops the video game, process 800 may follow the "yes" route from block 824 to block 826, and video game client 212 may stop the execution of game execution file 122. At block 824, if the game session should not end (e.g., if user 102 continues to play the game), process 800 may follow the "no" route from block 824 to block 814, and additional read operations may be received. When user 102 continues to play the game, in this way, a portion of process 800 may be repeated, and the unfulfilled block 124 of game data 126 is retrieved from remote system 106 on demand if necessary. Using this technique where file system proxy component 218 "lies" to the video game regarding block 124 available in non-volatile memory, it can be understood that from the reference frame of the video game, the content of the game appears to be stored in first memory 132(1). The video game may expect that game data 126 is available from local memory resources 132, and based on various factors (e.g., resources consumed by other running processes, etc.), the read access speed that varies between client machine 104 and client system 104 may become accustomed, or there may be variations in the read access speed on a single client machine 104. All of this means that even though the technique of process 800 may be somewhat slower in retrieving the unfulfilled block 124 of game data 124 through wide area network 108, it does not crash the video game.

[0081] By using process 800, user 102 can start playing a video game immediately after obtaining it if desired. Further, the technology of process 800 is not game-dependent, which means that game developers do not need to perform any work to enable the instant play 128 feature. Instead, it enhances the value of all games on the video game distribution platform that distributes video games to a heterogeneous population of client system configurations.

[0082] FIG. 9 is a flowchart of an exemplary process 900 for prefetching blocks 124 of game data 126 to reduce latency during game play.

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

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

[0085] At 906, a determination can be made as to whether a capacity exceeding a threshold exists within a "prefetch cache". As used herein, a "prefetch cache" means a cache allocated (or reserved) to prefetch blocks 124 of game data 126. As described herein, the second memory 132(2) and / or the third memory 132(3) - which provides a faster read access speed than the first memory 132(1) - can provide a prefetch cache, and either or both of the local memories 132(2) / (3) can be set to any suitable data amount, such as 100 megabytes. In this example, the game execution file 122 can prefetch 100 megabytes of game data 126 during a game session before requesting to read the prefetched game data 126. 100 megabytes is merely an example, and the prefetch cache can be set to a lesser or greater amount of data. Thus, at block 906, the prefetch cache can be monitored to determine how full the prefetch cache 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 at block 906, can be set to any suitable amount. For example, if the size of an individual block 124 of game data 126 is 4096 bytes, the threshold capacity can be set to a mere 4096 bytes of capacity, which is sufficient space to prefetch a block 124 of game data 126. However, the threshold capacity can be set to a greater number of bytes / megabytes to ensure that multiple blocks 124 can be prefetched during execution through the prefetch algorithm.

[0086] In an exemplary use case, user 102 of client machine 104, the use case, can navigate to a game library page, and a set of blocks 124 of game data 126 can be prefetched to fill a 100 megabyte prefetch cache in a second memory 132(2) and / or a third memory 132(3) of client machine 104. As user 102 continues to play the video game, file system 220 can receive a call associated with a read operation performed by game execution file 122 to read one or more of the prefetched blocks 124. Instead of accessing the first memory 132(1) of client machine 104 to search for block 124, file system 220 can access at least one of the second memory 132(2) or the third memory 132(3) in which the prefetched block 132 is cached, as a result of which the capacity of the prefetch cache begins to increase. When the capacity of this prefetch cache meets or exceeds a threshold, additional prefetching can be triggered to fill the prefetch cache. Thus, at block 906, if a capacity exceeding the threshold exists in the prefetch cache, process 900 can follow the "yes" route from block 906 to block 908.

[0087] At 908, the logic of client machine 104 can detect an event used to determine which blocks 124 of game data 126 to prefetch. For example, at sub-block 910, the detected event can be a context queue (e.g., the user navigates to a game library page). As another example, at sub-block 912, the detected event can be file system proxy component 218 that receives a read operation performed by game execution file 122 to read a particular block 124 of game data 126.

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

[0089] At 916, the identified block 124 can be cached in a local memory 132 that provides a faster read access speed than a first memory 132(1) (e.g., a non-volatile memory such as an HDD, SD card, etc.), and the game data 126 remains on the client machine 104. Thus, the identified block 124 can 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, when multiple blocks 124 of game data 126 are identified at 914, the blocks 124 can be cached in multiple different prefetch caches, such as by caching a second block 124(2) in the second memory 132(2) and a third block 124(3) in the third memory 132(3). In this way, the blocks 124 of the prefetched game data 126 can be distributed across multiple prefetch caches of multiple local memory resources 132 using load balancing techniques, and some game data 126 can be cached in the second memory 132(2) and approximately equal amounts of game data 126 can be cached in the third memory 132(3), even though the third memory 132(3) provides a faster read access speed than the second memory 132(2). In this way, the prefetched game data 126 can improve the overall throughput of the system in that the game data 126 can be accessed in parallel from any and all local memory resources 132 during game play. In this load balancing scheme, it may be predicted that 1% of the read operations access game data 126 from the first memory 132(1), 9% of the read operations access game data 126 from the second memory 132(2), and 90% of the read operations 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 performed on the file system 220 by the game execution file 122, and the read operation requests 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 the file system 220) is cached in a prefetch cache of a local memory resource (e.g., the second memory 132(2) or the third memory 132(3)) that provides a relatively fast read access speed. If the block 124 is cached in the prefetch cache, the process 900 may follow the "yes" route from block 922 to block 924, and the block 124 may be read from the prefetch cache. For example, the game execution file 122 may read the block 124 of the game data 126 from the second memory 132(2) or the third memory 132(3) depending on where the block 124 is cached. If the block 124 is not cached in the prefetch cache, the process 900 may follow the "no" route from block 922 to block 926, and the block 124 may be read from the first memory 132(1), and the game data 126 may remain on the client machine 104.

[0092] At 928, a decision is made as to whether the game session of the video game should end. For example, if user 102 stops the video game, process 900 may follow the "yes" route from block 928 to block 930, and the video game client 212 may stop the execution of the game executable file. In some embodiments, if user 102 restarts the game session and the client machine 104, the game data 126 prefetched into the second memory 132(2) may remain stored in the prefetch cache of the second memory 132(2) when the second memory 132(2) represents additional non-volatile memory (e.g., SSD) during restart. In this way, if user 102 starts another game session after restart, blocks of the game data 126 that remain cached in the second memory 132(2) can be retrieved therefrom if block 124 is requested by the game executable file 122 during the subsequent game session. At 928, if the game session should not end (e.g., if user 102 continues to play the game), process 900 may follow the "no" route from block 928 to block 906, and the capacity of the prefetch cache is re-evaluated because a portion of process 900 repeats starting from block 906. At 906, if a capacity exceeding the threshold does not exist within the prefetch cache (e.g., if the prefetch cache is considered to be overly filled with prefetched game data 126), process 900 may directly follow the "no" route 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 of the prefetch cache.

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

[0094] Although the subject matter has been described in language specific to structural features, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features described. Rather, the specific features are disclosed as exemplary forms for implementing the claims.

Claims

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 the 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 the game data was accessed based at least in part on the second read operation; and a non-transitory computer readable medium that causes a remote system to transmit the access data, an identifier of the video game, and a configuration of the client machine.

2. The client machine of claim 1 , wherein the configuration of the client machine specifies a type, version, or characteristics of hardware, software, or firmware associated with the client machine.

3. and 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 of the second video game; initiating downloading of the blocks of the second game data into the non-volatile memory according to the sequence specified in the download sequence data; 2. The client machine of claim 1, further comprising: executing said second game execution file for playing said second video game on said 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; 4. The client machine of claim 3, further comprising: reading said block of said second game data using said 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; 4. The client machine of claim 3, further comprising: reading said block of said second game data using said file system.

6. a non-volatile memory configured to store the game data, the plurality of first blocks of game data including at least the first block of game data and the second block of game data, and 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; 2. The client machine of claim 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; and caching in the second memory at least one of the first block of game data or the two blocks of game data that are 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; 2. The client machine of claim 1, further comprising: reading at least one of the first block of game data or the second block of 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; and caching in the second non-volatile memory the first block of the game data that is specified in the block dependency data as being associated with the event; caching in the volatile memory the second block of the game data that is specified 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; and 2. The client machine of claim 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 the 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 the game data was accessed based at least in part on the second read operation; transmitting to a remote system the access data, an identifier of the video game, and a configuration of the client machine.

10. 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 the method further comprises: receiving instructions from the remote system to delete one or more second blocks of the game data from a 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; 10. The method of claim 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 of the second video game; commencing downloading of the blocks of the second game data into a non-volatile memory of the client machine according to the sequence specified in the download sequence data; 10. The method of claim 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 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 method of claim 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 to read 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; The method of claim 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, the method comprising: 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 at least one of the first block of game data or 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; 10. The method of claim 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. 15. The method of claim 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 wherein 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 that specifies the second block of the game data as being 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 for 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 for a second block of the game data accessed by the game executable file during the execution of the game executable file on the respective 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; and 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 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 further 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; 17. The method of claim 16, further comprising downloading to the client machine at least the first block of game data and the second block of game data 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 comprises: determining an association between the first block of game data and the second block of game data; or 20. The method of claim 16, comprising at least one of: determining an association between a contextual 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; 17. The method of claim 16, further comprising: transmitting, by the remote system, instructions to the one of the plurality of client machines to delete the one or more blocks of the game data from non-volatile memory of the one of the plurality of client machines.

Images