Tracking file system read operations for instant play video game play and for client discard and prefetch of game data

Abstract

A client machine running a video game executable can utilize a file system proxy component configured to track read operations performed by the game executable during a game session, generate access data based on the tracked read operations, and report this access data to a remote system. This telemetry method allows the remote system to: collect access data reported by multiple client machines, categorize the access data according to the client system configuration, and analyze the access data to generate data that the client machine can use to implement various game-related functions, including but not limited to "instant play" of the video game, discarding unused blocks of game data to free up local storage resources, and / or locally prefetching game data to reduce latency during gameplay.

Description

[0001] Cross-references to related applications

[0002] This PCT application claims priority to U.S. Patent Application Serial No. 16 / 821,716, filed March 17, 2020, entitled “TRACKING FILE SYSTEM READOPERATIONS FOR INSTANT PLAY OF VIDEO GAMES, AND FOR CLIENT-SIDE DISCARDING AND PREFETCHING OF GAME DATA”, the entire contents of which are incorporated herein by reference. Background Technology

[0003] Services that distribute personal computer (PC) video games utilize network-accessible computing platforms to distribute digital copies of video games to PCs. For example, a user can purchase a video game available through a distribution service and download it to their PC from a remote computing system via the internet. Many video games today are relatively large, so downloading them can take considerable time, and once downloaded to the user's PC, storing all the game data can consume significant amounts of disk storage space. For instance, a video game might contain over 100 gigabytes (GB) of game data, and using current technology, it could take several hours to download, depending on the user's network connection speed. Unless the video game developers write the game code in a way that allows the game to be played with only some, rather than all, of the game data downloaded to the PC, users must wait until the game is fully downloaded before they can play it. Furthermore, because most games are very large, users typically choose to store them on the hard drive (HDD) that provides the majority of the storage space on their PC. However, despite the availability of large-capacity HDDs, local storage capacity remains limited, and due to the relatively slow read access speeds offered by HDDs, delays can sometimes occur when a PC loads game data from an HDD during a gaming session.

[0004] This article provides technical solutions for improving and enhancing these and other systems. Attached Figure Description

[0005] Specific embodiments are described with reference to the accompanying drawings. In these drawings, the leftmost digit of the reference numeral indicates the drawing in which that reference numeral first appears. The same reference numerals are used in different drawings to indicate similar or identical components or features.

[0006] Figure 1This is an illustration of an exemplary environment including a video game distribution platform configured to implement the technologies described herein.

[0007] Figure 2 A block diagram illustrating exemplary components of a client machine is shown, along with a flowchart of an exemplary process for tracking file system read operations to generate access data and sending that access data to a remote system.

[0008] Figure 3 A block diagram illustrating exemplary components of a remote system is shown, along with a flowchart of an exemplary process for receiving access data from a client machine and analyzing access data across one or more users to implement the techniques described herein.

[0009] Figure 4 This is a flowchart illustrating an exemplary process for generating download sequence data based on access data received from multiple client machines, so that the client machines can use it to download game data in a specific sequence of blocks.

[0010] Figure 5 This is a flowchart of an exemplary process for generating block dependency data based on access data received from multiple client machines, so that client machines can use it to prefetch blocks of game data to reduce latency during gameplay.

[0011] Figure 6 This is a flowchart of an exemplary process for determining unused blocks of game data based on access data received from a client machine and instructing the client machine to discard the unused blocks of game data.

[0012] Figure 7 This is a flowchart of an exemplary process for discarding unused blocks of game data from the non-volatile memory of a client machine.

[0013] Figure 8 This is a flowchart of an exemplary process for executing a video game on a client machine before the game download is complete.

[0014] Figure 9 This is a flowchart of an exemplary process for prefetching blocks of game data to reduce latency during gameplay. Detailed Implementation

[0015] Video game distribution platforms allow users to acquire video games, download digital copies of the video games to their respective client machines, and execute the video games using the installed client applications. As users play the video games on their client machines, the game executable running on each client machine can continuously request blocks of game data from the video game using the client machine's file system. As used herein, "game executable" refers to the executable code (e.g., one or more executable files) of the video game that, when executed, allows the user to play the video game on the client machine by rendering frames based on user input provided via the client machine's input device. As used herein, "game data" refers to data read by the game executable during the execution of the video game's game executable over a series of frames. Among other things, game data can be used to render the video game's graphics, calculate game logic, and / or calculate the video game's physics. Examples of game data include, but are not limited to, textures, virtual objects, maps, game characters, parameters, and other features of virtual objects and / or virtual game worlds. This game data can be stored in memory by dividing it into multiple blocks (e.g., blocks of uniform size), and the client machine's file system is configured to control how these blocks of game data are stored in and retrieved from the client machine's local memory. Each request to read a block of game data issued by the video game's executable file when playing the video game on the client machine is referred to herein as a "read operation." Therefore, the video game's executable file can perform a series of read operations on the file system throughout the entire game session.

[0016] The techniques, apparatus, and systems described herein relate to using a file system agent component of a client machine to track read operations performed by a game executable of a video game during a game session, to generate access data based on the tracked read operations, and to report the access data to a remote system. An exemplary process implemented by the client machine may include: executing the game executable of the video game to play the video game on the client machine; determining read operations performed by the game executable on the client machine's file system; generating access data based at least in part on these read operations; and sending the access data, an identifier of the video game, and a configuration of the client machine to a remote system. Read operations performed by the game executable may request the reading of blocks of game data from the video game. Therefore, the access data generated by the client machine may specify: (i) an identifier of the block of game data accessed during the game session, and (ii) the time during which the block of game data was accessed based at least in part on the read operations while the game executable was executed.

[0017] This telemetry method allows the remote system to: collect access data reported by multiple client machines, categorize the access data according to the client system configuration, and analyze the access data to generate data that the client machines can use to implement various game-related functions, including but not limited to "instant play" of the video game, discarding unused blocks of game data to free up local storage resources, and / or locally prefetching game data to reduce latency during gameplay. An exemplary process implemented by the remote system may include: receiving access data associated with the video game from multiple client machines having a common client system configuration; analyzing the access data; generating data based at least in part on the analysis of the access data; and sending the data to one or more client machines having the client system configuration. The access data received by the remote system can specify for each client machine in the client machines: (i) identifiers of blocks of game data from the video game that are accessed by the game executable file during execution on the respective client machines; and (ii) the time during which the game executable file accesses the blocks of game data during execution. In addition, the data generated by the remote system based at least in part on the analysis of the access data may include at least one of the following: (i) download sequence data, which specifies the sequence of downloading at least some blocks of the game data to a client machine with a client system configuration, or (ii) block dependency data, which specifies various associations between two or more blocks of the game data.

[0018] As previously mentioned, one exemplary game-related feature that can be enabled is the "Instant Play" feature. The Instant Play feature described herein allows a user who acquires a video game to begin playing it immediately upon acquisition, before the game data download to the user's client machine is complete. Therefore, the user does not have to wait for the video game to finish downloading before starting a game session. To enable Instant Play, a remote system can receive access data (as described herein) related to a specific video game from multiple client machines, and the remote system can generate download sequence data based on this access data, specifying the sequence of blocks of game data for the video game. This sequence can position blocks more likely to be accessed first towards the beginning of the sequence, and blocks less likely to be accessed first towards the end of the sequence. In this way, as blocks of game data begin downloading to the client machine, the blocks of game data most likely to be accessed early in the game session are stored in the client machine's non-volatile memory, and then other blocks of game data less likely to be accessed early in the game session are downloaded. This allows the user to start playing the video game immediately upon acquisition, even while blocks of game data are still being downloaded to the client machine's non-volatile memory. In fact, the techniques and systems described herein allow users to begin playing a video game even before the first block of game data has been downloaded to the user's client machine. This is achieved, at least in part, by using a file system agent component on the client machine, configured to receive read operations performed by the game executable and determine whether the requested block of game data has already been downloaded to non-volatile memory or whether the block still needs to be downloaded. If the block "appears" in non-volatile memory, meaning that the download of the block of game data to non-volatile memory has been completed, the game executable can use the file system to read the block of game data. If the download of the block to non-volatile memory has not yet been completed, the file system agent component can intercept the read operation, request the unappeared block of game data from a remote system, and once the block is received from the remote system, it can be read using the file system. Although the execution of the video game may be briefly paused while retrieving the unappeared block of game data from the remote system, the likelihood of this happening frequently or not at all is low, assuming that the download of game data begins with the acquisition of the video game and that the blocks of game data are downloaded in a sequence consistent with the sequence of blocks of data accessed by the game executable during the game session.

[0019] Another exemplary game-related function that can be enabled is to free up local storage resources on the client machine by discarding unused blocks of game data. By freeing up local storage resources, the client machine can reclaim valuable storage capacity that could be used for game data in other video games and / or other general data. To achieve client-side discarding of game data, the client machine (which has game data for the video game stored in non-volatile memory) can execute the game executable file of the video game, and access data can be generated in one or more game sessions while the game executable file performs read operations on the client machine's file system. This access data can specify a first subset of blocks of game data accessed during one or more game sessions, and the time during which these blocks were accessed during the game sessions. A remote system can receive the access data from the client machine, and the remote system can determine one or more second blocks of game data based on the access data, classifying these blocks as "unused" blocks based on the fact that the one or more second blocks were not accessed by the game executable file on the client machine at least within a threshold time period or within 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 the one or more second blocks of game data from the non-volatile memory. When the client machine removes these unused blocks from non-volatile memory, the storage capacity on the client machine can be increased. Furthermore, if the game executable requests to read deleted blocks of game data, the client machine's file system agent component can request the blocks of game data from the remote system on demand, which adds some latency compared to storing the blocks on local storage.

[0020] Another exemplary game-related feature that can be enabled is local prefetching of blocks of game data to reduce latency when loading game data during a game session. To enable local prefetching, a remote system can receive access data (as described herein) related to a specific video game from multiple client machines, and the remote system can generate block dependency data based on this access data. This block dependency data specifies various associations between two or more blocks of game data. For example, the block dependency data could indicate that whenever a first block of game data is accessed during a game session, a second block of game data is typically accessed within a threshold time period. In this way, the block dependency data can describe inter-block relationships between sets of two or more blocks based on access patterns exhibited in the access data received at the remote system. The remote system can send the block dependency data to client machines on which the video game is installed, and when the client machines execute the game executable file of the video game, the client machines can prefetch blocks of game data by caching the blocks in local memory, which provides faster read access speeds than persistent storage for game data (e.g., non-volatile memory such as HDDs, SD cards, etc.). This local prefetching can reduce loading time delays when the game executable requests to read blocks of game data.

[0021] The techniques and systems described herein can improve gaming functionality on client machines without altering how game developers currently create video games. For example, implementing client components (such as the file system proxy component described herein) allows users on client machines to play video games as they acquire them, meaning users don't have to wait for the game to download (potentially for hours) before starting a game session. This also allows for the intelligent downloading of game data in a sequence of blocks, positioning the blocks most likely to be accessed first at the beginning of the sequence, which helps reduce latency during gameplay while game data download is in progress. Gaming functionality on client machines can be further improved, or alternatively, by prefetching game data based on block dependency data during a game session. This is because client machines can predict which blocks of game data are likely to be accessed next in a series of read operations performed by the game executable of the video game, and these blocks can be cached in local memory (e.g., volatile memory, such as random access memory (RAM)), which provides faster read access speeds than non-volatile memory that persistently stores game data. This "pre-prepares" the game data for fast access when the video game requests it.

[0022] The techniques and systems described herein may, in addition to or alternatively, allow one or more devices to conserve resources, at least relative to memory resources. For example, using access data generated by one or more client machines to identify and delete unused blocks of game data can free up local memory resources on the client machines. For instance, if a client machine and / or a remote system determine, based on access data related to tracked file system read operations, that a user never plays the game in single-player mode but always in multiplayer mode, then single-player game data for a video game can be deleted from the client machine's non-volatile memory based on the determination that these blocks were not used at least within a threshold time period or within a threshold number of game sessions.

[0023] Figure 1 This is an illustration of an exemplary environment 100 including a video game distribution platform configured to implement the technologies described herein. Users 102 (sometimes referred to as "clients") in the community may be associated with one or more client machines 104. Therefore, Figure 1 The client machines 104(1)-104(N) shown represent computing devices that a user community (or customer base) can use to execute programs such as video games. Client machines 104 can be implemented as any suitable type of computing device configured to process and render graphics on an associated display and send / receive data over a network. Such computing devices include, but are not limited to, PCs, desktop computers, laptop computers, mobile phones (e.g., smartphones), tablets, portable digital assistants (PDAs), wearable computers (e.g., virtual reality (VR) headsets, augmented reality (AR) headsets, smart glasses, etc.), in-vehicle (e.g., in-vehicle) computers, televisions (smart TVs), set-top boxes (STBs), game consoles, and / or any similar computing devices.

[0024] The configuration of client machine 104 can vary. For example, subsets of client machines 104 may each use specific types, versions, or features of hardware (e.g., a central processing unit (CPU) model, a graphics processing unit (GPU) model, etc.), and / or specific types, versions, or features of firmware and / or software (e.g., a version of a graphics driver, a downloadable content (DLC) package for installation scripts, a language for running the video game client, etc.). These and other aspects of the hardware, firmware, and / or software of client machine 104 constitute the “configuration” of client machine 104, which, as used herein, is sometimes referred to as the “client system configuration,” and these and other aspects may specify a limited set of libraries used to download game data (divided into blocks) of video games on a video game distribution platform. Therefore, subsets of client machines 104 may share a common client system configuration, and the client system configuration may differ between these subsets of client machines 104. Client machines 104 that differ in their client system configurations may download, store, and / or access blocks of game data in different ways, even for the same video game. Determining whether a pair of client machines 104 have a common client system configuration can be based on whether the machines 104 share a threshold amount of the same type, version, or feature of hardware, software, or firmware. For example, if two client machines 104 use at least the same DLC package for the installation script, then the two client machines can also be considered to have the same client system configuration, even if there are some differences in other aspects (e.g., different GPU models, etc.).

[0025] Refer again Figure 1Client machine 104 can communicate with remote computing system 106 (sometimes simply referred to as "remote system 106") via computer network 108. Computer network 108 can 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 connectivity technologies. In some cases, remote system 106 may be part of a network-accessible computing platform maintained and accessible via computer network 108. Such network-accessible computing platforms may be referred to by 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 is configured to classify (e.g., organize, categorize, classify, etc.) the access data 110 received within data repository 112. Remote system 106 may also be configured to analyze access data 110 to generate data that client machine 104 can use to implement the various game-related functions described herein. For example, 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, as described herein. Remote system 106 may also be configured, in addition to or alternatively, to analyze access data 110 to identify unused blocks of game data on one or more client machines 104, and may send instructions 118 to client machine 104 to delete unused blocks of game data in order to free up local memory resources on client machine 104.

[0026] In some implementations, remote system 106 acts as, or has access to, a distribution service to distribute (e.g., download) programs (and data) to client machine 104. In one example, client machine 104 may have a client application installed on it. A client application, which may be a video game client (e.g., game software for playing video games), may be configured to execute programs, such as video games, on client machine 104 on which the client application is installed. With the client application installed, client machine 104 may then have the ability to download programs (e.g., video games) from remote system 106 via computer network 108. Any type of content distribution model can be used for this purpose, such as a direct purchase model where programs (e.g., video games) can be purchased individually to be downloaded and executed on client machine 104, a subscription-based model, a content distribution model where programs are rented or leased for a period of time, etc. Thus, individual client machines 104 may include one or more installed video games that can be executed by loading the client application, and these video games may render graphics on a display during execution. In one example, user 102 may choose to play one of several video games that they have acquired (e.g., purchased, rented, leased, etc.) and downloaded from remote system 106, such as by loading a video game client and selecting the desired video game to begin playing that video game.

[0027] consider Figure 1 For example, some of users 102 play a video game provided to these users 102 by a remote system 106. When playing the video game on the corresponding client machine 104 of user 102, the game executable running on each client machine 104 can continuously request the file system to read blocks of game data from the video game. The file system agent component of client machine 104 can track the read operations performed by the game executable to generate access data 110. For example, the game executable running on client machine 104(1) can make a request to the file system of client machine 104(1) during game execution to read blocks of game data from one or more local storage resources of client machine 104(1), such as by reading blocks of game data from sectors of a hard disk drive (HDD) or from sectors of a security digital (SD) card that is detachably coupled to client machine 104(1). Therefore, the game executable file of the video game running on the client machine 104(1) can perform a series of read operations on the file system during the entire game session, and the file system agent component of the client machine 104(1) can track the read operations to generate access data 110.

[0028] Access data 110 may specify: (i) a block identifier, which identifies the accessed block of game data in the video game (e.g., a block accessed by the game executable during a game session), and (ii) the time when the accessed block of game data is accessed by the game executable through a read operation during execution of the game executable. As previously mentioned, game data in a video game may include textures, virtual objects, maps, game characters, etc. In some implementations, game data may be stored across sectors of non-volatile memory (e.g., sectors of an HDD, SD card, etc.) and organized in blocks of game data within these sectors. Using blocks is a flexible way to handle files of varying sizes while avoiding the need to use contiguous storage space in a file system to store each file. Block identifiers (e.g., numbers) may be used to reference and / or locate each block of game data. Generally, one or more processors of the client machine 104 may perform read, write, and / or other storage operations as instructed by one or more device drivers. In some implementations, client machine 104 can create a mapping between blocks of game data and sectors of non-volatile memory to determine which blocks were accessed and from which they were accessed (e.g., which sectors) based on read operations performed by the game executable during gameplay. For example, if the game executable performs a read operation to access game data stored in a first sector of non-volatile memory, an identifier for a specific block of game data stored in the first sector can be specified in access data 110. Furthermore, the access times specified in access data 110 can allow determination of the order (or sequence) of blocks accessed during a game session (e.g., accessing block A first, then block D, then block F, and so on), and the relative time of access (e.g., 4 minutes after entering a game session, 9 minutes after entering a game session, 1 hour after entering a game session, etc.).

[0029] Access data 110 received by remote system 106 can be categorized in data repository 112 based on unique client system configuration and / or the video game ID of the corresponding video game. Access data 110 can also be stored in association with the user account of the user logged into the video game client running on the client machine 104 that sent the access data 110. Figure 1 A data repository 112, maintained by a remote system 106, is shown for storing, classifying, or otherwise organizing access data 110 received from client machine 104. The data repository 112 can organize the access data 110 into groups (or buckets), each uniquely associated with a combination of client system configuration and video game ID. In other words, each bucket of access data 110 in the data repository 112 can be associated with a specific program (e.g., a video game) and a specific client system configuration, as described herein.

[0030] Figure 1 The illustration shows a client machine 104(N) sending a request 120 to obtain (e.g., purchase, rent, lease, etc.) a video game from a remote system 106. For example, a user of client machine 104(N) logged into his / her user account via an installed video game client can transact via remote system 106 to purchase the video game. In response to request 120, client machine 104(N) can receive the game executable file 122 of the video game from remote system 106, and client machine 104 can also receive download sequence data 114 and / or block dependency data 116 for the obtained video game and a specific client system configuration of client machine 104. Therefore, it should be understood that request 120 may include a configuration of client machine 104(N) instructing remote system 106 to search for download sequence data 114 and block dependency data 116 available for that specific client system configuration.

[0031] Figure 1 It also depicts the remote system 106 starting to download block 124 of the acquired video game data 126 according to the block sequence specified in the download sequence data 114. Figure 1 An example is shown where the first block 124 (1) is downloaded, followed by the second block 124 (2), then the third block 124 (3), and so on. Although the three blocks 124 are in... Figure 1 The blocks are depicted as being downloaded to client machine 104(N), but it should be understood that the download sequence may include any number of blocks 124, including additional blocks downloaded after block 124(3). Client machine 104(N) may download blocks 124 to non-volatile memory of client machine 104(N), such as HDD, SD card, etc.

[0032] like Figure 1As shown, client machine 104(N) can implement the instant play 128 function, wherein client machine 104(N) can start executing the game executable file 122 of the acquired video game before or during the download of block 124 of game data 126. For example, client machine 104(N) can start executing game executable file 122 even before the first block 124(1) of game data is downloaded. Game executable file 122 can start launching the newly acquired video game in response to user input received by client machine 104(N) (such as user 102 providing user input using a mouse and / or keyboard, game controller, etc.). In this sense, there may be no restriction on when user 102 can start playing the video game. Therefore, user 102 can start playing the game, and game executable file 122 can start executing before the first block 124(1) of game data is downloaded to client machine 104(N). If user 102 chooses to wait for a period of time after acquiring the video game, the game executable file 122 can begin execution after at least one block 124(1) of the game data 126 has been downloaded to the client machine 104(N).

[0033] In some implementations, the video game client running on client machine 104(N) can be configured to prevent game executable 122 from launching until a predetermined time has elapsed since the start of downloading block 124 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 can be determined by remote system 106 based on how suitable the video game is for instant play 128, and remote system 106 can send instructions to the video game client upon acquiring the video game to wait for the predetermined time period to elapse and / or wait for the predetermined event to occur before allowing game executable 122 to run on client machine 104(N). In some implementations, remote system 106 can send data to client machine 104(N) for outputting suggestions to user 102 via client machine 104(N), such as displaying the suggestion "For the best user experience, we recommend waiting 5 minutes after the start of downloading [Video Game X]". In one example, if the video game is well-suited for the Instant Play 128 function, the remote system 106 can instruct the client machine 104(N) to output a notification: "The game is ready for instant play, so you can start playing immediately. Have fun!"

[0034] like Figure 1As shown, another client machine 104(2) can implement the local prefetch 130 function, wherein the client machine 104(2) can prefetch one or more occurrence blocks 124 of game data 126 to reduce latency during gameplay. For example, the game data 126 of a video game can be stored in a first memory 132(1) that provides a first speed of read access. The first memory 132(1) can represent a non-volatile memory that persistently stores the game data 126, such as an HDD, SD card, etc. The client machine 104(2) may also include a second memory 132(2) that provides a second speed of read access that is faster than the first speed. The second memory 132(2) can be an additional non-volatile memory (e.g., an SSD) or can be volatile memory (e.g., working memory, such as RAM). In any case, client machine 104(2) can use block dependency data 116 to determine whether block 124 is likely to be read next by game executable 122. If so, block 124 can be cached in second memory 132(2), so that when game executable 122 eventually requests to read block 124, it can be accessed quickly from second memory 132(2) instead of from the relatively slower first memory 132(1). As will be described in more detail below, as part of the local prefetch 130 function, multiple different local memory resources 132 can be used to cache block 124 of game data 126, which can further improve overall bandwidth and reduce latency compared to caching block 124 only in working memory. This is based on the concept that game executable 122 can read from different local storage resources 132, including first memory 132(1), in parallel to improve overall bandwidth and reduce latency to an even greater extent.

[0035] like Figure 1As shown, another client machine 104(1) can implement the function of deleting unused game data 134, wherein the client machine 104(1) receives from the remote system 106 an instruction 118 for deleting one or more blocks 124 of game data 126 stored in the non-volatile memory of the client machine 104(1), and 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 can determine, based on the 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 the video game, and therefore, the blocks 124 of the game data 126 of the video game that can be used to play the video game in single-player mode have not been accessed by the game executable 122 within a threshold time period or within a threshold number of game sessions. Therefore, the remote system 106 can send instruction 118 to one or more client machines 104 (such as client machine 104(1)) to instruct the client machine 104 to delete one or more unused blocks 124 of game data 126 from its non-volatile memory, which are previously downloaded to the client machine 104 and identified as “unused” blocks 124. Instruction 118 can specify an identifier for the unused blocks 124 so that the client machine 104(1) can delete the correct blocks 124 of game data 126, thereby freeing up local memory capacity without impairing the user experience of playing the game on the client machine 104(1).

[0036] Figure 2 A block diagram illustrating exemplary components of client machine 104 is shown, along with a flowchart of an exemplary process 200 for tracking file system read operations to generate access data 110 and sending that access data 110 to remote system 106. In the illustrated embodiment, client machine 104 includes, among other components, one or more processors 202 (such as a central processing unit (CPU), graphics processing unit (GPU), etc.), 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.

[0037] Non-transitory computer-readable medium 208 may include volatile and non-volatile memory, removable and non-removable media implemented using any method or technology for storing information such as 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 disc (DVD) or other optical storage devices, magnetic tape, magnetic tape, disk storage devices or other magnetic storage devices, RAID storage systems, or any other medium that can be used to store desired information and is accessible by a computing device. Computer-readable medium 208 may be implemented as a computer-readable storage medium (“CRSM”), which may be any available physical medium accessible to processor 202 to execute instructions stored on computer-readable medium 208. In one basic embodiment, the CRSM may include random access memory (“RAM”) and flash memory. In other embodiments, the CRSM may include, but is not limited to, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium that can be used to store desired information and is accessible by processor 202. Furthermore, although local memory 132 is shown as separate from computer-readable medium 208, it should be understood that in some specific implementations, computer-readable medium 208 and any one or more local memories of local memory 132(1), 132(2) and / or 132(3) may represent the same memory or at least a portion of the same memory.

[0038] Now for reference Figure 2 The process 200 is shown herein. The processes described herein are illustrated as a collection of boxes in a logic flowchart, representing a series of operations that can be implemented in hardware, software, firmware, or a combination thereof (sometimes referred to herein as "logic"). In the context of software, these boxes represent computer-executable instructions that, when executed by one or more processors, perform the enumerated operations. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform a specific function or implement a specific abstract data type. The order in which the operations are described is not intended to be construed as limiting, and any number of the described boxes can be combined in any order and / or in parallel to implement these processes.

[0039] For discussion purposes, it is assumed that the client machine 104 executing process 200 has previously installed a video game client 212, which refers to a client application stored on computer-readable medium 208 and configured to execute a game executable file 122. The user 102 of client machine 104 can acquire (e.g., purchase, rent, lease, etc.) video games, and after acquisition, can install (e.g., download from remote system 106) these video games and store them in non-volatile memory. In some embodiments, a first local memory 132(1) (sometimes referred to as "first memory 132(1)") can represent non-volatile memory (e.g., HDD, SD card, etc.), and the first memory 132(1) can provide first-speed read access. When downloading blocks 124 of game data 126 from remote system 106, blocks 124 of game data 126 can be downloaded to the first memory 132(1). Simultaneously, the second memory 132(2) may represent additional non-volatile memory (e.g., a solid-state drive (SSD)), and the second memory 132(2) may provide a second speed of read access, which is faster than the first speed provided by the first memory 132(1). Furthermore, the third memory 132(3) may represent volatile memory (e.g., working memory, such as RAM), and the third memory 132(3) may provide a third speed of read access, which is faster than the second speed. It should be understood that the client machine 104 can implement a higher speed than... Figure 2 The local memory 132 resources shown are those with fewer resources (e.g., by omitting the second memory 132(2)) or additional local memory 132 resources.

[0040] At 214, the video game client 212 can execute the game executable file 122 of the video game on the client machine 104. For example, a 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 (via executing the game executable file 122) to execute previously downloaded video games and / or obtain new video games from the remote system 106. The game executable file 122 can be loaded into working memory (such as third memory 132(3)), in which the game executable file is executed to render graphics on the display of the client machine 104, among other things. There may be a startup phase and a game time phase during the game session. During a game session, the game executable 122 can be configured to receive input data from input device 204 (e.g., mouse and / or keyboard, game controller, head-mounted display (HMD), microphone, etc.) and can determine which block 124 of game data 126 to access for rendering video game content on the display of client machine 104 (i.e., output device 206). For example, the game executable 122 can be configured to determine which parts of the game world to render in the upcoming frame, and which objects and / or textures to render in the upcoming frame, and can issue a read operation to read the corresponding block 124 of game data 126 used to render the upcoming frame.

[0041] At 216, the file system agent component 218 executing on the client machine 104 can determine (e.g., receive, monitor, intercept, etc.) read operations (e.g., first read operation, second read operation, etc.) performed by the game executable 122 on the file system 220 of the client machine 104. The file system 220 can be configured to control how data, including blocks 124 of the video game's game data 126, are stored and retrieved. Regardless of whether all of the video game's game data 126 is present in local storage resources (such as first memory 132(1)), the file system agent component 218 can be configured to "falsely report" to the video game which blocks 124 (e.g., files) of the game data 126 exist on the client machine 104's non-volatile memory (e.g., on an HDD, SD card, etc.). For example, via the file system agent component 218, the video game client 212 can know, based on the video game's identifier, the list of game files that should be stored in non-volatile memory, the size of the game files, and the sectors of non-volatile memory where the game files may be stored. For example, this causes the video game (e.g., game executable 122) to believe that all blocks 124 of the video game's game data 126 are stored in the first memory 132(1). The file system agent component 218 may be an extension of the file system 220 to create this information when necessary and present it to the game executable 122. In any case, consider an example where all blocks 124 of the video game's game data 126 are stored in and accessible from the first memory 132(1) of the client machine 104. In this example, the file system agent component 218 may act as a pass-through interface that only monitors read operations performed by the game executable 122 on the file system 220. As described in more detail herein, specific blocks 124 of the game data 126 may be prefetched from the first memory 132(1) and cached in at least one of the second memory 132(2) and the third memory 132(3), both of which provide faster read access speeds than the first memory 132(1). The file system 220 can continuously track the location of the block 124 of game data 126 stored at any given time, and can access the block 124 of game data 126 from the appropriate storage resource 132 to serve read operations performed by the game executable file 122 during a game session.

[0042] At 222, the file system agent component 218 may generate access data 110 based at least in part on read operations it receives from the game executable 122. As described elsewhere herein, this access data 110 may specify: (i) identifiers of blocks 124 of game data 126 accessed by the game executable 122 during a game session, and (ii) the times at which the game executable 122 accesses the accessed blocks 124 of game data 126 during execution of the game executable. For example, with respect to two blocks 124 of game data 126, access data 110 may specify: (i) a first identifier of the first block of game data, (ii) a first time at which the first block of game data is accessed at least in part based on a first read operation during execution of the game executable, (iii) a second identifier of the second block of game data, and (iv) a second time at which the second block of game data is accessed at least in part based on a second read operation during execution of the game executable. In some implementations, the access time of each accessed block 124 can be represented in the access data 110 as the time measured from the start of the game session (e.g., block A is accessed 4 minutes after the start of the game session, block D is accessed 13 minutes after the start of the game session, etc.).

[0043] At 224, the client machine 104 can send access data 110 to the remote system 106, such as via communication interface 210 and through computer network 108. Communication interface 210 can implement various types of wired and / or wireless or radio technologies. For example, communication interface 210 can implement radio, such as Bluetooth Low Energy (BLE) radio, Wi-Fi radio, and / or cellular radio. It should be understood that communication interface 210 may also include physical ports to facilitate wired connections to networks, connected peripherals, or plug-in network devices communicating with other wireless networks.

[0044] As shown in subframe 226, access data 110 can be sent at 224 along with the configuration of client machine 104 and the identifier of the video game. Furthermore, access data 110 can be streamed to remote system 106 at any suitable time (e.g., in real-time or substantially real-time) by generating access data 110 and / or in response to events such as periodic, during idle periods when resource consumption is relatively low (e.g., below a threshold percentage of resource consumption), when network connectivity is restored (e.g., after playing the game offline), after client machine 104 stops executing the game executable 122 (e.g., after user 102 ends the game session by exiting the video game), etc. Access data 110 can also be used to transmit metadata generated due to tracked read operations on client machine 104 in any suitable format, such as by sending access data 110 as an output to remote system 106. Process 200 represents a “telemetry” method for collecting access data 110 at remote system 106. Considering that a large number of client machines 104 may be executing process 200, the remote system 106 can collect access data 110 sent (e.g., uploads, reports, etc.) from a large number of client machines 104 with different client system configurations at box 224.

[0045] Figure 3A block diagram illustrating exemplary components of a remote system 106 is shown, along with a flowchart of an exemplary process 300 for receiving access data 110 from a client machine 104 and analyzing access data 110 across one or more users 102 to implement the techniques described herein. In the illustrated embodiment, among other components, the remote system 106 includes one or more processors 302, memory 304 (or non-transitory computer-readable medium 304), and a communication interface 306. Memory 304 (or non-transitory computer-readable medium 304) may include volatile and non-volatile memory, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage devices, cassette tape, magnetic tape, disk storage devices or other magnetic storage devices, RAID storage systems, or any other medium that can be used to store desired information and is accessible by a computing device. Computer-readable medium 304 may be implemented as a computer-readable storage medium (“CRSM”), which may be any available physical medium accessible to processor 302 to execute instructions stored on memory 304. In one basic embodiment, the CRSM may include random access memory (“RAM”) and flash memory. In other embodiments, the CRSM may include, but is not limited to, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other tangible medium that may be used to store desired information and is accessible by processor 302. Download sequence component 308, block dependency component 310, and / or game data usage component 312 may represent instructions stored in memory 304 that, when executed by processor 302, cause remote system 106 to perform the techniques and operations described herein. For example, download sequence component 308 may be configured to generate download sequence data 114 based on access data 110, as described herein. 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 can be configured to determine the unused blocks 124 of game data 126 based on each user or each client machine 104, as described herein.

[0046] Communication interface 306 can implement various types of wired and / or wireless or radio technologies. For example, communication interface 306 can implement radio, such as Bluetooth Low Energy (BLE) radio, Wi-Fi radio, and / or cellular radio. It should be understood that communication interface 306 may also include physical ports to facilitate wired connections to networks, connected peripheral devices, or plug-in network devices communicating with other wireless networks.

[0047] Now for reference Figure 3 The process 300 is shown. At 314, the remote system 106 can receive access data 110 from the client machine 114 (e.g., as part of the “telemetry” method using process 200, as described above). The received access data 110 can specify for a particular client machine 104: identifiers of blocks 124 of game data 126 of the video game, which are accessed on the particular client machine 104 by the game executable 112 of the video game; and the time during which blocks 124 are accessed during a game session (e.g., during the execution of the game executable 122 of the video game). As shown in subbox 316, the access data 110 can be received together with the configuration of the particular client machine 104 and the identifier of the video game executed during the generation of the access data 110.

[0048] At 318, remote system 106 can categorize access data 110 received at box 314 according to (or based on) client system configuration and game identifier. For example, data repository 112 may include multiple groups or buckets 320(1)-320(M) categorized according to a unique combination of game ID and client system configuration. Tracking, for example, a first client machine 104(1) with client system configuration "1", when first access data 110 is received from the first client machine 104(1) at box 314, the first access data 110 may be categorized into a first bucket 320(1) (or group) at box 318, and the bucket 320(1) may be tagged with the game ID of the video game received from the first client machine 104(1) at subbox 316 and the client system configuration of the first client machine 104(1). Similarly, the second client machine 104(2) can send second access data 110, and this second access data 110 can be sorted into a second bucket 320(2) at box 318. This second bucket can be labeled with the game ID of the video game received from the second client machine 104(2) at subbox 316 and the second client system configuration "2" of the second client machine 104(2). This operation can continue for any number "M" buckets, depending on the number of client machines 104 reporting access data 110, whether those client machines 104 have different client system configurations, and / or the number of different video games being executed on those client machines 104.

[0049] At 322, remote system 106 can perform analysis on the access data 110 received at box 314 to generate data (e.g., the results of the analysis). The generated data may include, but is not limited to, download sequence data 114 of one or more video games, block dependency data 116 of one or more video games, and / or determination of unused blocks 124 of game data 126 for each user / each client machine.

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

[0051] If remote system 106 determines at box 324 that the triggering event has not occurred, process 300 may follow a "No" route from box 324 to box 314, where remote system 106 continues to collect / receive access data 110 from client machine 104. If remote system 106 determines at box 324 that the triggering event has occurred, process 300 may follow a "Yes" route from box 324 to box 326, where remote system 106 may send data to one or more client machines 104. For example, if the triggering event involves client machine 104 acquiring a video game, remote system 106 may retrieve download sequence data 114 of the video game and send the download sequence data 114 along with the game executable file 122 of the video game to client machine 104. Alternatively, remote system 106 may retrieve block dependency data 116 of the video game and send the block dependency data 116 to client machine 104. As another example, if the triggering event includes determining that there is an unused block 124 of game data 126 on the client machine 104, the remote system 106 can send an instruction to delete the unused block of game data.

[0052] It should be understood that in some implementation schemes, Figure 2At least some of the components of the client machine 104 shown can be implemented as components of the remote system 106. For example, the game executable 122 can be executed on the remote system 106 (e.g., as part of a video game streaming service), and the game executable 122 can receive data from the client machine 104 via network 108 indicating user input while playing the video game. In this case, the game data 126 of the video game can also be stored at the remote system 106, and the file system agent component 218 can be a component of the remote system 106 that receives read operations from the game executable 122 to monitor blocks 124 of the game data 126 accessed during gameplay. In this configuration, the client machine 104 can act as a thin client, where most of the processing during the video game session is performed in the cloud. In another example, the download sequence component 308, the block dependency component 310, and / or the game data usage component 312 can be components of the 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 perform analysis on 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.

[0053] Figure 4 This is a flowchart of an exemplary process 400 for generating download sequence data 114 based on access data 110 received from multiple client machines 104 for client machines 104 to download blocks 124 of game data 126 in a specific sequence of blocks 124.

[0054] At 402, remote system 106 can receive access data 110 associated with a video game from multiple client machines 104. The access data 110 received at block 402 can specify for each client machine among the client machines 104: (i) the accessed block 124 of game data 126 associated with the video game accessed by the game executable 122 during execution on each client machine, and (ii) the time during which the game executable 122 accesses the accessed block 124 of game data 126. As shown in subblock 404, the access data 110 can be received together with the configuration of the client machine 104 that sends the access data 110 and / or the game identifier of the video game executed on the client machine 104 at the time the access data 110 is generated.

[0055] At 406, remote system 106 can generate download sequence data 114 associated with the client system configuration and the game identifier of the video game, at least in part, based on access data 110. Download sequence data 114 can specify a sequence of blocks 124 of game data 126 of the video game, and this sequence can represent the order in which blocks 124 of the game data are downloaded to the client machine 104 with a specific client system configuration. The download sequence of the video game can be determined in any suitable manner. As shown in subboxes 408 and 410, the generation of download sequence data 114 can include multiple sub-operations.

[0056] At 408, statistics (as specified in access data 110) for at least some blocks 124 of the video game's game data 124 can be calculated, at least in part, based on the time (e.g., time, position / order / rank, etc.) of accessing the game data 124 of the video game in N game sessions of N corresponding users 102 playing the video game ("N" is any positive integer). For example, based on access data 110 associated with the N users 102 playing the video game, remote system 106 can determine statistics (e.g., averages) based on the time each of the N users 102 accesses these blocks 124 during a game session (e.g., during the initial game session). For example, remote system 106 can determine that the average access time for block A is 30 minutes after entering the initial game session (e.g., based on multiple different times when N different users accessed block A), the average access time for block B is 45 minutes after entering the initial game session, the average access time for block C is 2 hours after entering the initial game session, and so on. Remote system 106 may, in addition to or alternatively, determine that block A is the first block accessed by user A during the initial game session, block A is the fifth block accessed by user B during the initial game session, block A is the seventh block accessed by user C during the initial game session, and so on for N users. Remote system 106 can then determine statistics (e.g., average position / order / rank) of block A based at least in part on this information regarding the time when the N different users 102 accessed the block. This can be repeated for other blocks 124 accessed during the game session. These analyses can be performed at least for the initial game session. Analysis can also be performed for any subsequent game sessions to determine which blocks 124 of game data 126 are typically accessed during the game session.

[0057] At 410, based on the calculated statistics, a download sequence can be determined for multiple blocks 124 of the game data 126 of the video game. The blocks 124 specified in the download sequence can be some blocks of the game data 124 (e.g., a portion of the total number of blocks 124), or the download sequence can include all blocks 124 of the game data 126. It should be understood that for a given video game, the initial number of blocks 124 that may be accessed during the initial game time period may be somewhat unbalanced to the duration of that initial game time period. In other words, 2 gigabytes of game data 126 can provide the initial 6 hours of gameplay for a particular video game, and the remainder of the game data 126 may be unlikely to be accessed during this initial game time period. This means that some games may be very well-suited for the "instant play" 128 feature, and these games can be flagged as "excellent instant play games" based on this ratio. In other words, some games can be flagged where a relatively small amount of game data 126 can support a relatively long initial game time. For example, single-player games might be well-suited for the "instant play" 128 feature, which has virtually no latency, because new players might need to play the same levels first. This means that for a single-player game, the remote system 106 might determine that all or almost all players playing the game for the first X hours of the game time access the same block 124, 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, and so on. While the exact times of accessing block 124 may vary, the order in which blocks 124 are accessed within the initial game timeframe is likely to be the same for a given video game. In contrast, multiplayer games might have an open game world with a huge map. For example, with N users, the N users might initially enter the game at different locations in the open world, and each game executable 122 will access different blocks 124 of the game data 126, corresponding to the different locations in the open world where matched players enter the game. This is an example of a game that is not well-suited for the instant play 128 feature.

[0058] Assuming the video game supports instant play 128 functionality, the download sequence can specify the order of blocks A, D, G, C, F, E, etc. Therefore, for any video game and for any client system configuration, remote system 106 can determine that, at least for a game period (e.g., the first 6 hours of game time), a regular user 102 may only access a specific subset of blocks 124 of the game data, and during that game period, may access those blocks 124 in a specific sequence. It should be understood that in some implementations, 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, and a second download sequence can be determined for a second user 102, different from the first download sequence. This can be based on unique access patterns exhibited in user-specific access data 110.

[0059] At 412, remote system 106 can receive a request 120 from client machine 104 to acquire a video game, the request 120 including the configuration of client machine 104. For example, user 102, logged into his / her user account via video game client 212 on client machine 104, can transact to purchase the video game via remote system 106.

[0060] At 414, remote system 106 may send the game executable file 122 of the video game to client machine 104. The game executable file 122 may be executable code (e.g., a file) that can be executed by processor 202 of client machine 104 to begin playing the video game on client machine 104. As shown in subbox 416, remote system 106 may send download sequence data 114 to client machine 104 so that client machine 104 begins downloading blocks 124 of the acquired video game data 126 in the sequence specified by the download sequence data 114.

[0061] At 418, remote system 106 can download blocks 124 of game data to client machine 104 according to the sequence specified in download sequence data 114. This may take some time, depending on the downlink data transfer rate available to client machine 104. Therefore, because of the sequence of blocks 124 being downloaded, the blocks 124 most likely to be accessed first appear in local memory 132 of client machine 104 before other blocks, and the download of those blocks to client machine 104 may have already been completed before the game executable file 122 of the video game requests to read other blocks.

[0062] Figure 5This is a flowchart of an exemplary process 500 for generating block dependency data 116 based on access data 110 received from multiple client machines 104 for client machines 104 to prefetch blocks 124 of game data 126 to reduce latency during gameplay.

[0063] At 502, remote system 106 can receive access data 110 associated with a video game from multiple client machines 104. The access data 110 received at box 502 can specify for each client machine among the client machines 104: (i) the accessed block 124 of game data 126 associated with the video game accessed by the game executable 122 during execution on each client machine, and (ii) the time during which the game executable 122 accesses the accessed block 124 of game data 126. As shown in subbox 504, the access data 110 can be received together with the configuration of the client machine 104 that sends the access data 110 and / or the game identifier of the video game executed on the client machine 104 at the time the access data 110 is generated.

[0064] At 506, remote system 106 can generate block dependency data 116 associated with client system configuration and video game identifiers, at least in part, based on access data 110. Block dependency data 116 can specify various associations between two or more blocks 124 of game data 126 of the video game. In other words, remote system 106 can predict one or more blocks 124 of game data 126 that will be accessed in the event of a specific event. In this way, a mapping of dependencies (e.g., branching, tree-like dependencies) between blocks 124 of game data 126 and / or between blocks 124 and contextual cues can be constructed based on access data 110. As shown in subboxes 508 and 510, the generation of block dependency data 116 may include one or more sub-operations.

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

[0066] At 510, remote system 106 can determine the association between pairs of blocks 124 of game data 126 of the video game based on access patterns (e.g., access times) shown in access data 110 received from N users 102 playing the video game. For example, remote system 106 can determine, based on access data 110 received from N users 102 playing the video game, that whenever the first block 124(1) of game data 126 is accessed during a game session, the second block 124(2) of game data 126 is typically accessed within a threshold time period. In this way, remote system 106 can determine the inter-block relationship between groups of two or more blocks 124 based on the access patterns shown in access data 110.

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

[0068] At 512, remote system 106 can send block dependency data 116 to one or more client machines 104. Block dependency data 116 can be sent in response to various triggering events. For example, remote system 106 can send block dependency data 116 of a video game to client machine 104 in response to user 102 of client machine 104 having acquired (e.g., purchased, rented, leased, etc.) the video game. As another example, block dependency data 116 generated at box 506 can represent new (or updated) data relative to a previous version of block dependency data 116 of the video game, and in response to the generation of new / updated block dependency data 116 at box 506, remote system 106 can send block dependency data 116 to client machine 104 known to be associated with the owner of the video game. Furthermore, a user can opt in to implement local prefetching on his / her client machine 104, and in response to opting in, remote system 106 can send block dependency data 116 to the client machine 104 of the opting user.

[0069] Figure 6 This is a flowchart of an exemplary process 600 for determining unused blocks 124 of game data 126 based on access data 110 received from client machine 104 and instructing client machine 104 to discard the unused blocks 124 of game data 126.

[0070] At box 602, remote system 106 can receive access data 110 associated with the video game from client machine 104. The access data 110 received at box 602 may specify: (i) the accessed block 124 of game data 126 associated with the video game accessed by the game executable 122 during execution on client machine 104, and (ii) the time during which the game executable 122 accessed the accessed block 124 of game data 126. It should be understood that remote system 106 may have previously received access data 110 from the same client machine 104 at some point in the past. Therefore, remote system 106 may have access to access data 110 generated in multiple game sessions played on client machine 104. As shown in subframe 604, access data 110 can be received together with the configuration of the client machine 104 that sends access data 110 and / or the game identifier of the video game executed on the client machine 104 when access data 110 is generated.

[0071] At 606, remote system 106 can determine, based on access data 110 (and any additional access data 110 received in the past from client machine 104), whether any block 124 of game data 126 of the video game can be classified as “unused” block 124 of game data 126, which is currently stored in non-volatile memory (e.g., first memory 132(1)) of client machine 104. As shown in subbox 608, this determination may include determining whether each block 124 has not been accessed by the game executable 122 of the video game on client machine 104 within a threshold time period or within a threshold number of game sessions. For example, if block XZ of game data 126 has not been accessed in the past P game sessions (“P” is any suitable integer) or in the last Q weeks (“Q” is any suitable integer, such as the last 10 weeks), block XZ can be determined to be an unused block.

[0072] In some implementations, other factors are considered when classifying block 124 of game data 126 as an unused block. For example, remote system 106 can determine, for N users of a particular video game, that certain blocks 124 of game data 126 have been accessed once by the game executable 122 and are not accessed again thereafter. Remote system 106 can determine that a particular block 124 has been accessed once, and if so, can designate block 124 as unused, regardless of how recently block 124 was accessed by the game executable 122. Other heuristics can also be used to determine unused blocks 124.

[0073] If at box 606 it is determined that none of the blocks 124 of game data 126 stored in the non-volatile memory (e.g., first memory 132(1)) of client machine 104 can be classified as unused blocks 124, then process 600 may follow the "No" route from box 606 to box 602, at which point remote system 106 may receive (or await receiving) additional access data 110 from client machine 104. If at box 606 it is determined that one or more blocks 124 of game data 126 stored in the non-volatile memory of client machine 104 can be classified as unused blocks 124, then process 600 may follow the "Yes" route from box 606 to box 610.

[0074] At 610, remote system 106 can send instructions 118 to client machine 104 to delete unused blocks 124 of game data 126 from client machine 104's non-volatile memory. These instructions 118 may include an identifier for the block 124 to be deleted. Once deleted, local memory resources 132 of client machine 104 can be freed up to increase local memory capacity and potentially store other data thereon.

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

[0076] At 702, client machine 104 can receive instruction 118 from remote system 106 to delete one or more blocks 124 of game data 126 of the video game from non-volatile memory. Remote system 106 may have determined, based on access data 110 previously sent by client machine, that the blocks 124 to be deleted represent unused blocks 124 of game data 126 that were not accessed within a threshold time period or within a threshold number of game sessions.

[0077] At 704, client machine 104 can delete one or more blocks 124 of game data 126 from non-volatile memory (e.g., first memory 132(1)) based on instruction 118 received from remote system 106. As shown in subbox 706, client machine 104 can be configured to wait until client machine 104 restarts before discarding blocks 124 of game data 126. In this way, deleting blocks 124 will not cause any problems if, for example, user 102 is currently playing a video game (or a different video game). It should be understood that after deleting unused blocks 124, the remaining blocks 124 of game data 126 remain persistently stored in non-volatile memory. Therefore, local memory resources 132 can be freed up by discarding blocks 124 of game data 126 that are unlikely to be accessed in the future. In an exemplary use case, user 102 may have installed video game X on his / her client machine 104, and since doing so, user 102 has only played video game X online, meaning user 102 has never played video game X in single-player mode. Based on access data 110 reported by client machine 104 to remote system 106, remote system 106 can determine that user 102 has never accessed blocks 124 of game data 126 for single-player mode of video game X since video game X was installed on client machine 104, and over several weeks and / or several game sessions. In this case, remote system 104 may send, and client machine 104 may receive, an instruction 118 for discarding single-player game data 126 (by identifying one or more blocks 124 corresponding to the game data 126), and client machine 104 may delete these blocks 124 to free up non-volatile memory of client machine 104 (e.g., first memory 132(1)).

[0078] After deletion, the video game can continue to run normally, and read operations performed by the game executable 122 continue. There is a very small chance that the game executable 122 may request to read blocks 124 of game data 126 that have been deleted from the non-volatile memory of the client machine 104; in such cases, the file system agent component 218 can retrieve these blocks from the remote system 106 as needed. In some implementations, if the game executable 122 requests to read the deleted blocks 124, those blocks 124 can be re-downloaded to the non-volatile memory of the client machine 104. Process 700, together with implementations of other processes and / or techniques described herein, can reclaim valuable disk space (e.g., approximately tens of gigabytes of disk space) on the client machine 104.

[0079] Figure 8 This is a flowchart of an exemplary process 800 for executing a video game on client machine 104 before the game download is complete. This is sometimes referred to herein as the “instant play” 128 function because process 800 allows user 102 to play the video game while it is being acquired, without waiting for the game data 126 to be downloaded to client machine 104.

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

[0081] At 806, client machine 104 can receive a game executable file 122 for a video game from remote system 106, such as executable code (e.g., one or more files) that can be executed by processor 202 of client machine 104 to play the video game thereon. As shown in subbox 808, client machine 104 can also receive download sequence data 114 associated with the configuration of client machine 104. This download sequence data 114 can specify a sequence of blocks 124 of game data 126 for the video game.

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

[0083] At 812, client machine 104 can execute game executable 122 to launch the video game. It should be understood that user 102 can start playing the video game, and game executable 122 can even begin execution before the first block 124 of game data 126 has finished downloading. Execution of the game executable can occur in response to user input detected by client machine 104 for launching the video game. For example, the user of client machine 104 can select a user interface element of video game client 212 to launch the video game that the user just acquired via remote system 106. As previously described, in some embodiments, remote system 106 can send data to client machine 104 for outputting suggestions to user 102 via client machine 104, such as by displaying the suggestion “For the best user experience, we recommend waiting T minutes after starting the download before playing [Video Game X].” In some embodiments, video game client 212 can block execution of game executable 122 until a threshold time period has elapsed and / or until a threshold number of blocks 124 have finished downloading to provide the best user experience. Alternatively, if the video game is particularly well-suited for the instant play 128 function, the remote system 106 may instruct the client machine 104 to output a notification “The game is ready for instant play, so you can start playing immediately. Have fun!”, and / or the video game client 212 may not impose any restrictions on when the user 102 can start playing the video game. In fact, it may be more preferable for some players who are not bothered by a little delay at the start of the video game (e.g., while exploring the world and setting things up) to start playing immediately and possibly before any game data 126 has finished downloading.

[0084] At 814, the file system agent component 218 of the client machine 104 may receive a first read operation on the file system 220 of the client machine 104 by the game executable 122. This first read operation may request to read the first block 124 (1) of the video game's game data 126. Because the download of the game data 126 is in progress when the read operation is received at box 814 (assuming it is a very large video game), the game executable 122 may request to read a non-present block 124 of the game data 126, where "non-present" means that the block 124 of the game data has not yet been downloaded to the client machine 104's non-volatile memory (e.g., first memory 132 (1)). In some embodiments, the file system agent component 218 may temporarily (e.g., briefly) block the read operation to determine whether the requested block 124 is present in the non-volatile memory or whether the block 124 still needs to be downloaded (e.g., to complete the download).

[0085] Therefore, at 816, the file system agent component 218 can determine whether the first block 124(1) of 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 "appeared" in the NVM). If the first block 124(1) of game data 126 appears in the NVM of the client machine 104 when a read operation is received at box 814, then process 800 can follow the "yes" route from box 816 to box 818.

[0086] At 718, the file system agent component 218 of the client machine 104 can unblock the read operation, and the file system 220 can be used to read the first block 124(1) of game data 126 from local storage resource 132. Incidentally, if the first block 124(1) appears and is 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 can be read from the faster memory 132(2) / (3) that caches the first block 124(1). If at box 816, the first block 124(1) of game data 126 does not appear in the non-volatile memory of the client machine 104, meaning that the download of the first block 124(1) to the non-volatile memory (e.g., the first memory 132(1)) has not yet been completed, process 800 can follow the "no" route from box 816 to box 820.

[0087] At 820, client machine 104 may send a second request to remote system 106 for the first block 124(1) of game data 126. As previously described, file system agent component 218 may intercept and block read operations. In some implementations, calls associated with read operations may be intercepted and blocked within the kernel of client machine 104, and file system agent component 218 may call back to video game client 212 to download the first block 124(1) if it determines that the first block 124(1) has not appeared.

[0088] At 822, client machine 104 can receive the first block 124 (1) of game data 126 from remote system 106 via computer network 108. After receiving the first block 124 (1) of game data 126, the first block 124 (1) of game data 126 can be read using file system 220. Therefore, file system proxy component 218 can temporarily block read operations at least for the unseen blocks 124 of game data 126 until these blocks 124 are received from remote system 106. Although this may increase the latency of reading the unseen blocks 124 compared to the latency of reading the blocks 124 that are already present in the non-volatile memory of client machine 104, this configuration still allows the video game to be played without downloading all of the game data 126 of the video game. In fact, this allows the video game to be played without any game data 126 being stored on client machine 104. However, since retrieving blocks 124 of game data 126 via computer network 108 increases latency, the action 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 will be present in non-volatile memory before the game executable 122 requests to read those blocks 124, thereby reducing latency. In other words, because remote system 106 intelligently determines the download sequence based on access data 110 received from other client machines 104 with the same client system configuration, the probability of receiving a read operation requesting to read non-present blocks 124 of game data 126 is relatively low, and if it does occur, it is not expected to happen frequently. Instead, before the game executable 122 performs a read operation on the given block 124, the given block 124 will most likely have already been downloaded and appear in non-volatile memory, so that the game executable 122 can read the block 124 from the local memory resource 132 of the client machine 104, where the latency is less than that involved in retrieving the same block 124 from the remote system 106 via the computer network 108.

[0089] At 824, a determination is made regarding whether the video game session should be terminated. For example, if user 102 exits the video game, process 800 may follow a "yes" route from box 824 to box 826, where the video game client 212 may stop executing the game executable 122. If the game session should not be terminated at box 824 (e.g., if user 102 continues playing the game), process 800 may follow a "no" route from box 824 to box 814, where additional read operations may be received. As user 102 continues playing the game, a portion of process 800 may iterate in such a way that, if necessary, the unseen block 124 of game data 126 is retrieved from remote system 106. This method of using file system agent component 218 to "falsely report" the availability of block 124 in non-volatile memory to the video game can be understood to appear, from the perspective of the video game's reference frame, that the game's content is stored in first memory 132(1). The video game can be expected to obtain game data 126 from local storage resource 132, and the video game may be accustomed to read access speeds that are variable from client machine 104 to client system 104, or the access speed on a single client machine 104 may be variable based on various factors (e.g., resources consumed by other running processes, etc.). All of this means that the method of process 800 will not cause the video game to crash, although it may sometimes be a little slow to retrieve missing blocks 124 of game data 124 via wide area network 108.

[0090] Using process 800, user 102 can start playing the video game whenever he / she wants after acquiring the game. Furthermore, the technology of process 800 is game-agnostic, meaning game developers don't need to do anything to allow the instant play feature; instead, it enhances the advantages of all games on the video game distribution platform, which distributes video games to a heterogeneous group of client system configurations.

[0091] Figure 9 This is a flowchart of an exemplary process 900 for prefetching game data 126 in block 124 to reduce latency during gameplay.

[0092] At 902, client machine 104 can receive block dependency data 116 associated with the configuration of client machine 104 from remote system 106. This block dependency data 116 can specify various associations between two or more blocks 124 of the video game's game data 126.

[0093] At 904, client machine 104 can execute the video game executable file 122 to launch the video game on client machine 104. Since the video game is installed on client machine 104, the game executable file 122 may already be available on client machine 104. Execution of the game executable file 122 allows user 102 of client machine 104 to start playing the game. Furthermore, execution of the game executable file 122 may occur in response to user input detected by client machine 104 for launching the video game. For example, user 102 of client machine 104 may select a user interface element of video game client 212 to launch the video game.

[0094] At 906, a determination can be made regarding whether there is a capacity in the "prefetch cache" exceeding a threshold amount. As used herein, "prefetch cache" refers to a cache allocated (or reserved) for the prefetch block 124 of game data 126. As described herein, a second memory 132(2) and / or a third memory 132(3) providing faster read access speeds than the first memory 132(1) can provide a prefetch cache, and this prefetch cache on either or both of the local memories 132(2) / (3) can be set to any suitable amount of data, such as 100 megabytes. In this example, up to 100 megabytes of game data 126 can be prefetched during a game session before the game executable 122 requests to read the prefetched game data 126. 100 megabytes is just an example; the prefetch cache can be set to less or more amounts of data. Therefore, at box 906, the prefetch cache can be monitored to determine how full it is, and if the cache capacity reaches or exceeds the threshold amount, an additional prefetch of game data 126 can be triggered. The threshold amount of capacity in the prefetch cache evaluated at box 906 can be set to any suitable amount. For example, if the size of each block 124 of game data 126 is 4096 bytes, the capacity threshold amount can be set to as little as 4096 bytes, which is sufficient space to prefetch blocks 124 of game data 126. However, the capacity threshold amount can be set to a higher number of bytes / megabytes to ensure that multiple blocks 124 can be prefetched during the run of the prefetch algorithm.

[0095] In an exemplary use case, user 102 on client machine 104 may have navigated to the game's library page, and a set of blocks 124 of game data 126 may have been prefetched to fill a 100-megabyte prefetch cache in the second memory 132(2) and / or the third memory 132(3) of client machine 104. As user 102 continues playing the video game, file system 220 may receive calls associated with read operations performed by the game executable 122 to read one or more prefetch blocks 124. Instead of accessing the first memory 132(1) of client machine 104, file system 220 may access at least one of the second memory 132(2) or the third memory 132(3) of cached prefetch blocks 124 to retrieve those blocks 124, thus the capacity in the prefetch cache begins to increase. Once the capacity in the prefetch cache reaches or exceeds a threshold, additional prefetching may be triggered to fill the prefetch cache. Therefore, if there is a capacity above the threshold in the prefetch cache at box 906, process 900 can follow the "yes" route from box 906 to box 908.

[0096] At 908, the logic of client machine 104 can detect events used to determine which blocks 124 of game data 126 to prefetch. For example, at subframe 910, the detected event might be a contextual prompt (e.g., the user navigating to the video game's library page). As another example, at subframe 912, the detected event might be that file system agent component 218 receives a read operation from game executable 122 to read specific blocks 124 of game data 126.

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

[0098] At 916, the identified block 124 can be cached in local memory 132, which provides faster read access speeds than the first memory 132(1) (e.g., non-volatile memory such as HDD, SD card, etc.), in which game data 126 is persistently stored on the client machine 104. Therefore, the identified block 124 can be cached in at least one of a second memory 132(2) (e.g., additional non-volatile memory such as SSD) or a third memory 132(3) (e.g., volatile working memory such as RAM). As shown in subbox 918, if 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 the second block 124(2) in the second memory 132(2) and the third block 124(3) in the third memory 132(3), and so on. In this way, the prefetch blocks 124 of game data 126 can be distributed across multiple prefetch caches of multiple local memory resources 132 using load balancing techniques. Some of the game data 126 is cached in the second memory 132 (2), and approximately an equal amount of the game data 126 is cached in the third memory 132 (3), although 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 be load balanced to improve the overall throughput of the system because the game data 126 can be accessed in parallel from any and all local memory resources 132 during gameplay. In this load balancing scheme, it is possible that 1% of read operations will access the game data 126 from the first memory 132 (1), 9% of read operations will access the game data 126 from the second memory 132 (2), and 90% of read operations will access the game data 126 from the third memory 132 (3).

[0099] At 920, the file system agent component 218 of the client machine 104 can receive a read operation on the file system 220 by the game executable file 122, which requests to read a specific block 124 of the video game's game data 126.

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

[0101] At 928, a determination is made regarding whether the video game session should be terminated. For example, if user 102 exits the video game, process 900 can follow a "yes" route from box 928 to box 930, where the video game client 212 can stop executing the game executable at box 930. In some implementations, if user 102 ends the game session and restarts client machine 104, then after the restart, if the second memory 132(2) represents additional non-volatile memory (e.g., SSD), the game data 126 prefetched into the second memory 132(2) can still be stored in the prefetch cache of the second memory 132(2). In this way, if user 102 starts another game session after the restart, then if blocks 124 of the game data 126 still cached in the second memory 132(2) are requested by the game executable 122 during a subsequent game session and are requested, these blocks can be retrieved from the second memory. If the game session should not be terminated at box 928 (e.g., if user 102 continues playing the game), then process 900 can follow the "No" route from box 928 to box 906, where the prefetch cache capacity is re-evaluated to iterate a portion of process 900 starting from box 906. At box 906, if there is no capacity in the prefetch cache exceeding a threshold amount (e.g., if the prefetch cache is considered to be full of too much prefetched game data 126), then process 900 can follow the "No" route directly from box 906 to box 920, where file system agent component 218 receives read operations without prefetching game data 126 from the prefetch cache.

[0102] Compared to simply accessing game data 126 from a first memory 132(1) where game data 126 is persistently stored on the client machine 104, process 900 can reduce loading time during game execution by reducing overall latency. In this way, relatively large video games can be stored in the first memory 132(1) (e.g., HDD, SD card, etc.). However, because game data 126 can be intelligently prefetched in a third memory 132(2) (e.g., working non-volatile memory, such as RAM) and / or a second memory 132(2) (e.g., SSD) before the game executable 122 requests blocks 124 of game data 126, blocks 124 may already be cached in the prefetch cache to reduce read access time.

[0103] 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 limited to the specific features described. Rather, specific features are disclosed as exemplary forms for implementing the claims.

Claims

1. A client machine, the client machine comprising: One or more processors; and A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to: The game executable file of the video game is executed to play the video game on the client machine; The system determines a first read operation and a second read operation performed by the game executable file on the file system of the client machine. The first read operation requests to read a first block of game data of the video game, and the second read operation requests to read a second block of game data. Access data is generated at least in part based on the first read operation and the second read operation, the access data specifying: The first identifier of the first block of the game data; During the execution of the game executable file, at least in part based on the first read operation, the first block of the game data is accessed at a first time; The second identifier of the second block of the game data; and During the execution of the game executable file, at least in part based on the second read operation, the second block of the game data is accessed at a second time. as well as The access data, the identifier of the video game, and the first client system configuration of the client machine are sent to a remote system, wherein the access data is grouped at the remote system based on a unique combination of the video game identifier and the first client system configuration of the client machine, wherein access data from other client machines having a common first client system configuration and other client machines having different second client system configurations are grouped into different groups for generating data at the remote system based on analysis of the grouped access data. The generated data includes download sequence data associated with the video game identifier and one of the first and second client system configurations, the download sequence data specifying a sequence in which at least the first block and the second block of the game data will be downloaded to a client machine having one of the first and second client system configurations. The analysis of the grouped access data includes: Calculate a first statistical statistic for the client machine associated with the first block of the game data and a second statistical statistic for the client machine associated with the second block of the game data; and The sequence is determined at least in part based on the first statistical data and the second statistical data.

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

3. The client machine according to claim 1, further comprising 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, 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, further cause the one or more processors to: Send a request to the remote system to obtain a second video game, the request including the first client system configuration of the client machine; Received from the remote system: a second game executable file of the second video game; and A second download sequence data associated with the first client system configuration of the client machine, the second download sequence data specifying a second sequence of blocks of second game data for the second video game; Begin downloading the blocks of the second game data to the non-volatile memory according to the second sequence specified in the second download sequence data; as well as Execute the second game executable file to play the second video game on the client machine.

4. The client machine of claim 3, wherein the computer-executable instructions, when executed by the one or more processors, further cause the one or more processors to: Receive a third read operation on the file system performed by the second game executable file, the third read operation requesting to read a block of the second game data; It is determined that the block of the second game data has been downloaded to the non-volatile memory; as well as Use the file system to read the block of the second game data.

5. The client machine of claim 3, wherein the computer-executable instructions, when executed by the one or more processors, further cause the one or more processors to: Receive a third read operation on the file system performed by the second game executable file, the third read operation requesting to read a block of the second game data; It has been determined that the download of the block of the second game data to the non-volatile memory has not yet been completed; Send a second request for the block of the second game data to the remote system; The block that receives the second game data from the remote system; as well as Use the file system to read the block of the second game data.

6. The client machine of claim 1, further comprising non-volatile memory storing the game data, wherein the plurality of first blocks of the game data include at least the first block of the game data and the second block of the game data, and wherein the computer-executable instructions, when executed by the one or more processors, further cause the one or more processors to: Receive 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 were not accessed by the game executable on the client machine within a threshold time period or within a threshold number of game sessions; and The game data is deleted from the one or more second blocks of the non-volatile memory.

7. The client machine according to claim 1, further comprising: A first memory, configured to provide read access at a first speed, stores the game data; and A second memory, configured to provide read access at a faster speed than the first memory, The computer-executable instructions, when executed by the one or more processors, further cause the one or more processors to: Receive from the remote system block dependency data associated with the first client system configuration of the client machine, the block dependency data specifying various associations between two or more blocks of the game data; Detect events; In the second memory, at least one of the first block of the game data or the second block of the game data that is specified in the block-dependent data as associated with the event is cached; Receive at least one of the first read operation or the second read operation; as well as Read at least one of the first block of the game data or the second block of the game data from the second memory.

8. The client machine according to claim 1, further comprising: A first non-volatile memory, configured to provide read access at a first speed, stores the game data; A second non-volatile memory is configured to provide a second speed read access that is faster than the first speed; and Volatile memory, configured to provide a third speed read access that is faster than the second speed. The computer-executable instructions, when executed by the one or more processors, further cause the one or more processors to: Receive from the remote system block dependency data associated with the first client system configuration of the client machine, the block dependency data specifying various associations between two or more blocks of the game data; Detect events; The first block of the game data designated as associated with the event is cached in the second non-volatile memory within the block-dependent data; The second block of the game data designated as associated with the event is cached in the volatile memory within the block-dependent data; Receive the first read operation; Read the first block of the game data from the second non-volatile memory; Receive the second read operation; as well as The second block of game data is read from the volatile memory.

9. A method, the method comprising: The video game's executable file is executed by the processor of the client machine to play the video game on the client machine; The processor determines a first read operation and a second read operation performed by the game executable file on the file system of the client machine, wherein the first read operation requests to read a first block of game data of the video game, and the second read operation requests to read a second block of game data; The processor generates access data based at least in part on the first read operation and the second read operation, the access data specifying: The first identifier of the first block of the game data; During the execution of the game executable file, at least in part based on the first read operation, the first block of the game data is accessed at a first time; The second identifier of the second block of the game data; and During the execution of the game executable file, at least in part based on the second read operation, the second block of the game data is accessed at a second time. as well as The access data, the identifier of the video game, and the first client system configuration of the client machine are sent to a remote system, wherein the access data is grouped at the remote system based on a unique combination of the video game identifier and the first client system configuration of the client machine, wherein access data from other client machines having a common first client system configuration and other client machines having different second client system configurations are grouped into different groups for generating data at the remote system based on analysis of the grouped access data. The generated data includes download sequence data associated with the video game identifier and one of the first and second client system configurations, the download sequence data specifying a sequence in which at least the first block and the second block of the game data will be downloaded to a client machine having one of the first and second client system configurations. The analysis of the grouped access data includes: Calculate a first statistical statistic for the client machine associated with the first block of the game data and a second statistical statistic for the client machine associated with the second block of the game data; and The sequence is determined at least in part based on the first statistical data and the second statistical data.

10. The method of claim 9, wherein the plurality of first blocks of game data includes at least the first block of game data and the second block of game data, the method further comprising: The remote system receives an instruction to delete one or more second blocks of the game data from the non-volatile memory of the client machine, wherein the one or more second blocks of the game data represent unused blocks of the game data that were not accessed by the game executable on the client machine within a threshold time period or within a threshold number of game sessions; as well as The game data is deleted from the one or more second blocks of the non-volatile memory.

11. The method of claim 9, 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, the method further comprising: Send a request to the remote system to obtain a second video game, the request including the first client system configuration of the client machine; Received from the remote system: The second video game's second executable file; and A second download sequence data associated with the first client system configuration of the client machine, the second download sequence data specifying a second sequence of blocks of second game data for the second video game; The download of the blocks of the second game data to the non-volatile memory of the client machine begins according to the second sequence specified in the second download sequence data. as well as The processor executes the second game executable file to play the second video game on the client machine.

12. The method of claim 11, further comprising: The processor receives a third read operation from the second game executable file on the file system, the third read operation requesting to read a block of the second game data; It is determined that the block of the second game data has been downloaded to the non-volatile memory; as well as The processor uses the file system to read the block of the second game data.

13. The method of claim 11, further comprising: The processor receives a third read operation from the second game executable file on the file system, the third read operation requesting to read a block of the second game data; It has been determined that the download of the block of the second game data to the non-volatile memory has not yet been completed; Send a second request for the block of the second game data to the remote system; The block that receives the second game data from the remote system; as well as The processor uses the file system to read the block of the second game data.

14. The method of claim 9, wherein the game data is stored in a first memory of the client machine, the first memory being configured to provide read access at a first speed, the method further comprising: Receive from the remote system block dependency data associated with the first client system configuration of the client machine, the block dependency data specifying various associations between two or more blocks of the game data; The processor detects the event; The first block or the second block of the game data designated as associated with the event in the block-dependent data is cached in a second memory of the client machine that is configured to provide read access at a second speed faster than the first speed; The processor receives at least one of the first read operation or the second read operation; as well as The processor reads at least one of the first block of the game data or the second block of the game data from the second memory.

15. The method of claim 14, wherein detecting the event includes detecting that the game executable requests to read the first block of the game data, wherein the caching includes caching the second block of the game data in the second memory by at least partially specifying that the second block of the game data is associated with the first block of the game data based on the block dependency data.

16. A method, the method comprising: Access data associated with a video game is received by a remote system from multiple client machines, including client machines with a common first client system configuration and client machines with different second client system configurations, wherein the access data specifies at least one of the multiple client machines: A first identifier for a first block of game data of the video game, the first block being accessed by the game executable of the video game during execution on various client machines; During the execution of the game executable file on each of the client machines, the first time the game executable file accesses the first block of the game data; The second identifier of the second block of the game data, the second block being accessed by the game executable file during execution on each client machine; and During the execution of the game executable file on each of the client machines, the game executable file accesses the second block of the game data at a second time; The access data is grouped at the remote system based on a unique combination of the video game's identifier and one of the first client system configurations and the second client system configurations of the plurality of client machines; The remote system analyzes the categorized access data from the multiple client machines; The remote system's processor generates data, at least in part, based on the analysis of the categorized access data, including the following: Download sequence data associated with the identifier of the video game and the first client system configuration and the second client system configuration, the download sequence data specifying the sequence for downloading at least the first block and the second block of the game data to the client machine; as well as The remote system distributes the downloaded sequence data to client machines in a heterogeneous group with client system configurations, wherein the heterogeneous group of client system configurations includes the first client system configuration and the second client system configuration; The analysis of the categorized access data includes: Calculate first statistics for the plurality of client machines associated with the first block of the game data and second statistics for the plurality of client machines associated with the second block of the game data; and The sequence is determined at least in part based on the first statistical data and the second statistical data.

17. The method of claim 16, wherein the method includes generating data by the processor of the remote system and at least in part based on the analysis of the access data, the generated data including block dependency data specifying an association between a first block of the game data and a second block of the game data, or an association between the first block of the game data or the second block of the game data and an event.

18. The method of claim 16, wherein the data generated based at least in part on the analysis of the classified access data includes the download sequence data, the method further comprising: The remote system receives a request to retrieve the video game from a client machine configured with the first client system. The remote system sends the executable file of the video game to the client machine; as well as At least the first block and the second block of the game data are downloaded to the client machine according to the sequence specified in the download sequence data.

19. The method of claim 17, wherein the data generated based at least in part on the analysis of the classified access data includes the block dependency data, and wherein the analysis of the access data includes at least one of the following: Determine the association between the first block of the game data and the second block of the game data; or Determine the association between the contextual hint and at least one of the first block of the game data or the second block of the game data.

20. The method of claim 16, further comprising: Based at least in part on the access data received from one of the plurality of client machines, it is determined that one or more blocks of the game data were not accessed by the game executable on the one of the plurality of client machines within a threshold time period or within a threshold number of game sessions; as well as The remote system sends an instruction to one of the plurality of client machines to delete one or more blocks of the game data from the non-volatile memory of the one of the plurality of client machines.

Images