Automatic hydration of feature file batches

Abstract

Computing devices save storage space by pre-writing payloads for multiple batches of feature files to local storage and then automatically downloading payloads for individual batches of feature files when the associated feature is invoked. In various embodiments, an operating system (OS) comprising both frequently used and infrequently used features executes on the computing device. Batches of feature files for frequently used features of the OS can be hydrated on the computing device, while batches of feature files for infrequently used features of the OS can be kept dehydrated on the computing device. When an infrequently used feature is requested, the computing device automatically downloads the corresponding batch of feature files. The computing device can then satisfy the request by implementing the infrequently used feature. Therefore, unless invoked, pre-defined batches of feature files remain immediately accessible on the computing device without consuming storage space.

Description

Background Technology

[0001] Computing devices are typically configured with software components that provide access to a vast number of features far exceeding those used regularly. Providing access to features that are rarely used is beneficial in maximizing the versatility of a computing device. For example, a typical operating system (OS) may include hundreds or even thousands of features that may be rarely, or even never, used by any given user. Installing the OS entirely onto the computing device provides maximum versatility because knowing in advance which features will be used—let alone when—is impractical. Unfortunately, implementing all the feature files needed for both regularly used and rarely used features locally consumes a significant amount of drive space. This is particularly problematic in computing devices with limited storage capacity.

[0002] Some techniques reduce the overall software footprint on computing devices by removing rarely used feature files. Such techniques allow users to manually select feature files to remove to free up storage space. However, even for experienced users, these techniques are cumbersome and error-prone because many OS features and applications are incrementally developed over time and include dependencies on a large number of feature files. For this reason, users may not fully understand which feature files are required to run certain applications and may inadvertently flag and remove feature files needed to achieve a desired function—making the desired function inoperable. Therefore, while it is desirable to prevent rarely used feature files from consuming storage space, conventional devices cannot achieve this while simultaneously providing access to these feature files when they are invoked.

[0003] It is in light of these and other considerations that the disclosures made in this article are presented. Summary of the Invention

[0004] The techniques described herein enable computing devices to save storage space by pre-writing payloads for predetermined batches of feature files to local storage and then automatically downloading payloads for individual batches of feature files when the associated feature is invoked. Exemplary embodiments include a computing device initially configured with some batches of feature files in a hydrated state and others in a dehydrated state. For illustrative purposes, it is assumed that an operating system (OS) runs on the computing device and that the OS includes many features—some frequently used and some rarely used. Batches of feature files associated with frequently used features of the OS can be hydrated on the computing device. Conversely, other batches of feature files associated with rarely used features of the OS can remain dehydrated on the computing device. In the event of a rarely used feature being invoked via a request, the computing device can automatically download and locally store a specific batch of feature files associated with this rarely used feature. Then, once the specific batch of feature files is written to local storage, the computing device can satisfy the request by implementing the rarely used feature. In this way, predetermined batches of feature files remain immediately accessible on the computing device without consuming storage space on the computing device unless invoked.

[0005] As a specific but non-limiting example, a computing device may run an OS that includes legacy applications (e.g., Microsoft Internet Explorer) that have been superseded by new default applications (e.g., Microsoft Edge). The original equipment manufacturer (OEM) of the computing device may determine that while local storage of the payload for the legacy application is necessary from a resource usage perspective unless required, continued availability of the legacy application is desirable from a versatility perspective (e.g., some users may prefer the legacy application over the new default). Based on these competing considerations, the OEM may initially configure the computing device using a predetermined batch of feature files that enable the implementation of the legacy application in its dehydrated state. This may include writing individual placeholder files to the computing device in place of each actual feature file in the predetermined batch. For example, suppose the predetermined batch of feature files includes three individual feature files, each specifically associated with a legacy application (e.g., ie.dll, ie.exe, and ie.xxx). In this example, the computing device may initially be configured with three placeholder files, and each individual placeholder file may include metadata indicating an address from which the payload for the corresponding feature file can be downloaded.

[0006] Because of the presence of placeholder files, legacy applications may appear locally available from the perspective of the user of the computing device and even other applications running on the device. For example, an icon for a legacy application might appear in the operating system's application menu. However, when a user (or another application) generates a request for a legacy application, the computing device can quickly determine that it is currently dehydrated. Based on this determination, the computing device can then respond by performing an intermediate step (i.e., the step between receiving the request and serving it) to fully download and hydrate a pre-defined batch of feature files. After completing this intermediate step, the computing device can then fulfill the request as if the pre-defined batch of feature files had been hydrated when the request was initially received. In this way, certain OS features can be dehydrated to reduce the OS footprint without affecting how users and applications interact with the OS.

[0007] In an exemplary embodiment, the computing device has a storage medium comprising several batches of feature files stored in a hydrated state and several other batches of feature files stored in a dehydrated state. As used herein, the term "hydrated state," when used to describe the state of an individual feature file and / or a batch of feature files, refers to a state in which the payload of the individual feature file and / or batch of feature files is locally stored on the storage medium of the computing device. For example, if a specific batch of feature files for a particular feature is stored in a hydrated state on the computing device, then all binaries unique to that particular feature, as well as any other portion of the payload of that particular feature (e.g., permissions, registry settings, etc.), are actually written to the storage medium and occupy space (e.g., bytes) on the storage medium. In contrast, the term "dehydrated state," when used to describe the state of an individual feature file and / or a batch of feature files, refers to a state in which the payload of the individual feature file and / or batch of feature files is not locally stored on the storage medium of the computing device. For example, if a specific batch of feature files for a particular feature is stored in a dehydrated state on the computing device, then the binaries unique to that particular feature and / or other portions of the payload of that particular feature are not written to the storage medium and do not occupy space on the storage medium.

[0008] It should be understood that the primary benefit of storing individual feature files or batches thereof in a dehydrated state is saving disk space. Take, for example, a Windows mixed reality feature with a payload size of 1.93GB (e.g., a CAB file named: Microsoft-Windows-Holographic-Desktop-FOD-Package~31bf3856ad364e35~amd64~~.cab). As described herein, storing this particular feature in a dehydrated state will effectively reduce the OS's storage footprint by 1.93GB – minus the size of any metadata and / or placeholder files stored in place of the payload. It should also be understood that if the feature(s) that enable a computing device to implement a particular feature are dehydrated, then these feature(s) will need to be hydrated by downloading these feature(s) and / or their payloads from a valid installation source.

[0009] Regarding the automatic hydration of multiple batches of individual feature files to a local drive as needed, a computing device can receive requests to access currently dehydrated feature files—but only when hydrated and available to implement aspects of the desired feature. In other words, the payload portion of the feature file that is actually available to implement the desired feature is not currently stored on the computing device's local storage medium. The feature file requested for access (also referred to herein as the "requested feature file") can be included in a batch of feature files that includes one or more other feature files. As a concrete example, the requested feature file could be a feature file named "feature_name.exe" that is batched together with another feature file named "feature_name.dll".

[0010] Upon receiving a request, the computing device can retrieve at least some metadata associated with the requested feature file that has been written to the storage medium. For example, in some embodiments, placeholder files may be written to the storage medium in place of the actual feature file associated with the dehydration feature. Placeholder files may include metadata indicating the address from which the feature file can be downloaded. In some embodiments, placeholder files also indicate the feature provider of the feature file. Simply put, individual placeholder files may point to the actual feature file they use as a placeholder.

[0011] The computing device can then use the metadata to generate a download request associated with the requested feature file. In some embodiments, the computing device may provide metadata to the synchronization engine to identify the requested feature file and indicate the appropriate feature provider from which the requested feature file can be obtained. Based on the metadata, the synchronization engine can then generate a download request and send it to the appropriate feature provider. In some implementations, the download request includes an identifier for the requested feature file that has already been requested for access, but does not explicitly indicate other feature files from that batch of feature files. That is, the download request may be limited to (multiple) requested feature files. Continuing with the specific example above, upon receiving a request to access the file “feature_name.exe”, the synchronization engine may generate a download request only for the feature file specifically requested and then transmit that download request to the appropriate feature provider.

[0012] On the server side of this implementation, upon receiving a download request, the feature provider can identify the entire predefined batch of feature files to which the requested feature file belongs. Then, instead of simply returning the requested feature file, the feature provider can return a download package including the entire predefined batch of feature files. For example, if the download request identifies the file "feature_name.exe", the feature provider can retrieve not only the "feature_name.exe" file, but also the "feature_name.dll" file and / or any portion of the payload for the feature currently being dehydrated on the computing device. After identifying the entire predefined batch of feature files, the feature provider can respond to the download request by providing the computing device with a download package including all feature files from the entire predefined batch of feature files.

[0013] Returning to the client side of this implementation, the computing device receives a download package containing all feature files from a predefined batch of feature files. The computing device then reads the download package to write each of the included feature files to a storage medium (e.g., a hard disk, solid-state drive, or any other suitable volatile or non-volatile storage medium) to hydrate these feature files from a dehydrated state. Thus, based on an initial request for access to only a single feature file (e.g., the "feature_name.exe" file), the computing device and the feature provider work together to fully hydrate the entire batch of feature files (even those not yet requested) by writing the entire payload for the feature to the local storage medium. Then, once the entire batch of feature files is fully hydrated (or when the batch is actively hydrated), the computing device serves the request by supplying access to the requested feature file using its most recently downloaded payload.

[0014] These and various other features will become apparent upon reading the following detailed description and examining the accompanying drawings. This "Summary" is provided to introduce, in a simplified form, the selection of concepts further described in the following "Detailed Description." This "Summary" is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to the implementation of solutions to any or all the shortcomings pointed out in any part of this disclosure. Attached Figure Description

[0015] Refer to the accompanying drawings for a detailed description. In the drawings, the leftmost number of the reference numeral(s) indicates the figure in which the reference numeral(s) first appears. Identical reference numerals in different figures indicate similar or identical items. References to individual items among multiple items can be made using reference numerals with another number in parentheses (and / or letters without parentheses) to refer to each individual item. General references to items can use specific reference numbers, rather than alphabetical order.

[0016] Figure 1 An exemplary system is shown that enables a computing device to store predetermined batches of feature files in a dehydrated state on a local drive, while maintaining on-demand accessibility of the predetermined batches of feature files at the computing device.

[0017] Figure 2A An exemplary data stream scenario is illustrated, in which a computing device performs an open request for a requested feature file that is currently stored on a local drive in a dehydrated state.

[0018] Figure 2B An exemplary data stream scenario is illustrated, in which a computing device responds to read and / or write requests by transmitting download requests to an appropriate feature provider.

[0019] Figure 2C An exemplary data stream scenario is illustrated, in which a computing device responds after downloading and hydrating the requested feature file. Figure 2B Read and / or write requests.

[0020] Figure 3 This is a flowchart of an example method for dynamically hydrating an individual feature file or multiple batches of feature files to the local drive of a computing device when invoked by a software component at the computing device.

[0021] Figure 4 It is a flowchart that monitors attributes associated with individual or batch feature files to dynamically dehydrate individual or batch feature files when automatic dehydration parameters are met.

[0022] Figure 5It is a flowchart for generating a download package for an overinclusive download request based on the state of the computing device that sent the download request. Detailed Implementation

[0023] The following "Detailed Description" describes a technique that enables a computing device to save storage space by pre-writing payloads for predetermined batches of feature files to local storage and then automatically downloading payloads for individual batches of feature files when associated features are invoked. Generally, a computing device may initially be configured with some batches of feature files in a hydrated state and other batches of feature files in a dehydrated state. As a specific example, an operating system (OS) running on the computing device may include some frequently used features and others that are rarely used. To save storage space, the relative usage frequency of various features can be weighted as a factor for selecting some batches of feature files to be stored in a hydrated state on the computing device and selecting other batches of feature files to remain dehydrated. For example, batches of feature files with implementations enabling frequently used features may be fully hydrated, while other batches of feature files with implementations enabling rarely used features may remain dehydrated. Then, when a request to access an individual dehydrated feature file is received, the computing device can automatically retrieve a specific batch of feature files associated with that dehydrated feature file from the appropriate feature provider. After receiving a specific batch of feature files from the appropriate feature provider, the computing device can fulfill the request by providing full access to features that are now hydrated but were dehydrated before the initial request was received. In this way, the pre-ordered batches of feature files remain immediately accessible at the computing device without permanently consuming large amounts of storage space on the computing device. That is, such pre-ordered batches of feature files only consume significant storage space when actually invoked in the request—otherwise, they are stored merely as metadata that does not occupy a large amount of storage space.

[0024] As used herein, the term "hydrated" when used to describe the state of an individual feature file indicates that the payload of that individual feature file is locally stored on a computing device. Conversely, the term "dehydrated" when used to describe the state of an individual feature file indicates that the payload of that individual feature file is not locally stored on a computing device. As described in more detail below, in some embodiments, placeholder files are stored individually for dehydrating feature files in place of the full versions of those feature files (i.e., the payload and all). Exemplary such placeholder files may include metadata indicating from which the feature provider of the corresponding feature file can be readily obtained and / or from which the address of the corresponding feature file can be readily obtained. The metadata may also indicate whether the payload associated with the requested feature file is currently written to a local drive.

[0025] As used herein, the term "feature" refers to a specific computational function that a computing device can perform by using one or more individual feature files and / or multiple batch feature files. Payloads for individual batch feature files can be downloaded and written to the local storage of the computing device to enable the computing device to support additional features, such as, for example, additional hardware use cases or additional software use cases. As a specific example, the computing device may be equipped with a camera suitable for performing facial recognition technology, and a batch feature file may include software code that enables the computing device to implement this technology via the camera. Therefore, a batch feature file may include drivers and / or any other suitable type of computer-readable instructions that can be used to implement the desired functionality. Exemplary features include, but are not limited to, various computational functions that can be added to or removed from the computing device via on-demand features (often referred to as "FOD") that can be used on the Microsoft Windows 10 operating system.

[0026] As used herein, the term "feature file" refers to any computational file that, individually and / or in combination with one or more other computational files, can be used to enable a functional computing device (e.g., a general-purpose computer running a typical operating system) to implement the "feature" defined herein. For example, an individual computational file among a set of computational files or a batch of computational files that enables a general-purpose computer to perform facial recognition features may be appropriately referred to as a feature file.

[0027] Turn now Figure 1An exemplary system 100 is illustrated, which enables a computing device 106 to store predetermined batches of feature files in a dehydrated state on a local drive 124 while maintaining on-demand accessibility of the predetermined batches of feature files at the computing device 106. In the illustrated example, the first batch of feature files corresponding to a feature titled "Feature_Name1" is stored in a hydrated state such that the payload of each individual feature file within this first batch is stored on the local drive 124 of the computing device 106. The respective payload of an individual feature file may include, for example, binary files, permissions, registry settings, and other data that can be used to implement a particular feature. Similarly, in the illustrated example, a second batch of feature files corresponding to a feature titled "Feature_Name2" is stored in a dehydrated state such that placeholder files are stored in place of the actual feature files in this batch. In some embodiments, the placeholder files are stored in a local directory 126 of the computing device 106, with the same storage path as the actual feature files that would be stored when hydrated (e.g., where the payload is written to local storage) onto the computing device 106. In this way, user interaction with computing device 106 at a specific file path will open either the actual feature file (if it exists) or a corresponding placeholder (if the called feature file is not hydrated to computing device 106). The placeholder file does not include the payload of the associated actual feature file, but instead includes metadata indicating the attributes of the corresponding actual feature file (e.g., a complete feature file with the corresponding payload). The metadata associated with any particular feature file can indicate from the feature provider that the specific feature file, including the corresponding payload, can be obtained. As described in more detail below, when a particular batch of feature files is dehydrated, when a single feature file associated with a placeholder file from that batch of feature files is requested, computing device 106 can use the metadata from the placeholder files in that particular batch to retrieve all actual feature files for that particular batch on demand.

[0028] To fully convey the concepts and technical advantages described herein, it may be beneficial to specify the data size for the corresponding payloads of the actual feature files and the metadata for the placeholder files. Thus, as illustrated, the second batch of files comprises two actual feature files named “Feature_Name2.exe” and “Feature_Name2.dll”, with payloads of 91MB and 15MB respectively (shown in the cloud data layer of feature provider 102(1)). As further shown, the two placeholder files corresponding to these two actual files are each only 1KB (shown in the local data layer on local drive 124). Therefore, in these specific but non-limiting cases, the second batch of feature files will consume only 2KB of local storage space when stored in a dehydrated state, compared to 106MB of local storage space when stored in a hydrated state.

[0029] As shown in the figure, computing device 106 may include an operating system (OS) 108 installed on a local drive 124. To facilitate the operation of computing device 106, at least some batches of feature files that can be used to implement various "kernels" and / or frequently used features of OS 108 may be fully hydrated on computing device 106. To reduce the total amount of storage space consumed on computing device 106, at least some batches of other feature files that can be used to implement other features of OS 108 may be kept dehydrated on computing device 106, except as described below. OS 108 may be any suitable system software for managing computer hardware and / or software resources and for providing services to various applications(s)110. Exemplary OS 108 may include, but is not limited to, various versions of Microsoft Windows (e.g., Windows 8.1 or 10, Windows Embedded Standard 7, etc.) and / or various versions of macOS (e.g., macOS Sierra, macOS X, etc.) and / or various versions of Google Chrome OS.

[0030] The computing device 106 may also include an application 110 mounted on a local drive 124. In some embodiments, at least some batch feature files that can be used to implement various features of the application 110 may be stored on the local drive 124 in a dehydrated state. In particular, it should be understood that the techniques described herein can be used to reduce the software footprint of the OS 108 and / or the application 110. This reduction in software footprint is achieved by selectively storing individual batch feature files that can be used to implement selected features of the OS 108 and / or the application 110 in a dehydrated state. The computing device 106 is configured according to the techniques described herein to enable users and / or software components to make requests (e.g., invocations) for dehydrated feature files and to have these requests served, as if the dehydrated feature files were fully hydrated when the requests were generated. This is achieved by automatically hydrating the requested feature file (and other typically batched feature files in some embodiments) immediately upon receiving the request. Then, after this intermediate step of hydrating the requested feature file, the computing device 106 can then respond to the request by providing access to the payload of the newly hydrated feature file. That is, computing device 106 receives a request when the payload is not locally available and slightly delays its response to the request until after the payload has been downloaded and / or written to local drive 124.

[0031] In some implementations, computing device 106 may utilize synchronization engine 112 to retrieve download packets when a request is made seeking access to a feature file currently being dehydrated on computing device 106. For example, when OS 108 receives a request identifying a specific feature file currently being dehydrated, OS 108 may retrieve metadata stored in a placeholder file for that specific feature file. OS 108 may then provide the metadata to synchronization engine 112 so that download request 128 is transmitted to the feature provider 102 (1) associated with the specific feature file. As described above, the metadata stored in the placeholder file may include identifications of feature providers (among numerous potential feature providers) from which the requested feature file can be obtained. As used herein, the term “metadata” specifically refers to a dataset that provides information about the corresponding feature file and, more specifically, about how computing device 106 obtains the payload associated with the corresponding feature file. In some embodiments, the metadata may also indicate whether the payload of the requested feature file is currently being written to the local drive of the computing device. In other words, the metadata may include an indication of whether a particular requested feature file is currently being hydrated at the computing device.

[0032] Download request 128 may include the identifier of the requested feature file that has been requested for access. In some instances, download request 128 may omit any specific identifiers of other feature files—such as those feature files that are typically batched together with the requested feature file. For example, a request may be generated based on a user-input run command to launch the currently dehydrated feature and / or application by accessing an associated executable file (e.g., “.exe”). In this example, the run command may specifically reference a file named “Feature_Name2.exe”, but not a related file named “Feature_Name2.dll”. Thus, the run command may cause OS 108 to generate a request to access a file named “Feature_Name2.exe”. In response to this request, synchronization engine 112 may generate download request 128 only for the feature file specifically requested, but not for the related file named “Feature_Name2.dll”—even if these files are typically batched. One reason why synchronization engine 112 may not be able to identify all these commonly batched feature files in download request 128 is that the various components of computing device 106 may lack visibility into which files are batched together. For example, OS 106 could be designed to simply fulfill requests on a per-file basis, and the requested characteristic files could omit any indication of their relationship to other files they may have. Exemplary synchronization engine 112 includes, but is not limited to, the synchronization API developed by DROPBOX, backup and synchronization developed by Google, and the OneDrive Universal Windows Platform (UWP) app for Microsoft Windows 10. Therefore, it can be understood that synchronization engine 112 could be a native component of OS 108, or it could be an add-on component downloaded separately from OS 108 and installed on client device 106.

[0033] Upon receiving download request 128, the first feature provider 102(1) can identify the complete predefined batch of feature files to which the requested feature file belongs. For example, as shown, the first feature provider 102(1) can determine that the requested feature file (e.g., a file named "Feature_Name2.exe") belongs to a batch of feature files named "File Batch: Feature_Name2". Instead of simply returning the requested feature file, the first feature provider 102(1) can return a download package 130 that includes the entire identified batch of feature files. Thus, in the illustrated example, in response to download request 128 identifying a single file named "Feature_Name2.exe", the first feature provider 102(1) returns both the requested "Feature_Name2.exe" file and the "Feature_Name2.dll" file, as well as any other feature files that are typically batched. In some embodiments, the first feature provider 102(1) can return the download package 130 as a compressed archive file to improve the speed at which the entire batch of feature files becomes hydrated on the computing device 106. Since computing device 106 may request access to other feature files in the batch of feature files even though the desired features are achieved, delivering the download package 130 as a compressed archive folder also reduces the total network bandwidth that would have been consumed if each feature file had been delivered individually when requested by computing device 106.

[0034] Upon receiving download package 130, computing device 106 may write each individual feature file in the individual feature files to local drive 124 (e.g., hard disk, solid-state drive, or any other suitable volatile or non-volatile storage medium) to convert the individual feature files from a dehydrated state to a hydrated state. In some embodiments, once the entire batch of feature files is fully hydrated (or when the batch of feature files is actively hydrated), computing device 106 serves the request by providing access to the requested feature files using its newly downloaded payload. Alternatively, computing device 106 may serve the request by providing access to a newly downloaded payload of the requested feature files even before the payload is written to local drive 124. For example, the request may be served by loading the payload directly from the download package into the memory or cache of computing device 106.

[0035] In some implementations, computing device 106 also includes an update service 114 configured to automatically update various components, such as, for example, OS 108 and / or application 110. For example, when a new version of OS 108 and / or application 110 becomes available from the corresponding provider, update service 114 may download an installation file (e.g., a compressed file with a ".cab" extension) and then install the downloaded installation file at an appropriately scheduled time (e.g., during off-peak usage). In some embodiments, update service 114 is also configured to automatically update metadata corresponding to a specific dehydration feature when an update to the dehydration feature becomes available from feature provider 102. For example, update service 114 may periodically communicate with feature provider(s)102 for various features currently being dehydrated on computing device 106 to determine when multiple new versions of feature files become available. Then, when new versions(of) feature files become available, update service 114 can update the metadata stored in placeholders for the feature files, such that the "updated" metadata now indicates how to obtain the updated feature file and its updated payload. For example, the metadata can be undated, such that a previous address in the metadata indicating where to download a previous version of the feature file is overwritten by a new address indicating where to download the new version of the feature file.

[0036] As further shown, computing device 106 includes a central processing unit (“CPU”) 116, which is connected via a bus ( Figure 1 (Not shown) Connected to various components such as local drive 124, memory 118, input / output (I / O) controller 120, and / or network interface 122. It will be understood that the system components described herein (e.g., applications 110, OS 108, and / or synchronization engine 112) can, when loaded into and executed by CPU 116, transform CPU 116 and the entire computing device 106 from a general-purpose computing system into a dedicated computing system tailored to facilitate the functions presented herein. CPU 116 can be composed of any number of transistors or other discrete circuit elements, which can individually or collectively present any number of states. More specifically, CPU 116 can operate as a finite state machine in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions can transform CPU 116 by specifying how CPU 116 transitions between states, thereby transforming the transistors or other discrete hardware elements constituting CPU 116.

[0037] Local drive 124 and associated computer-readable media provide non-volatile storage for computing device 106. While the description of computer-readable media included herein refers to mass storage devices such as solid-state drives and / or hard disks, those skilled in the art will understand that computer-readable media can be any available computer storage or communication medium that can be accessed by a computing architecture such as, for example, system 100. Communication media includes computer-readable instructions, data structures, program modules, and / or other data in modulated data signals such as carrier waves or other transmission mechanisms, and includes any delivery medium. The term “modulated data signal” refers to a signal whose characteristics are altered or set in a certain way to encode information in the signal. By way of example and not limitation, communication media includes wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the foregoing is also included within the scope of computer-readable media.

[0038] By way of example and not limitation, computer storage media can include volatile and non-volatile removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. For example, computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid-state storage technologies, CD-ROM, digital versatile disk (“DVD”), HD-DVD, BLU-RAY, or other optical storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible by computing device 106. For the purposes of the claims, the phrases “computer storage medium,” “computer-readable storage medium,” and variations thereof do not, by themselves, include wave, signal, and / or other transient and / or intangible communication media.

[0039] The I / O controller 120 can receive and process input from multiple other devices, including a keyboard, mouse, or electronic pen. Figure 1 (Not shown in the image). Similarly, the I / O controller 120 can output to a display screen (e.g., for displaying the file browser GUI described herein), a printer, or other types of output devices (also shown in the image). Figure 1 (Not shown in the image) provides output. Network interface 122 enables computing device 106 to connect to one or more networks 104, such as a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), or any other suitable network used to transfer information between computing device 106 and feature providers(s) 102.

[0040] Turn now Figure 2AAn exemplary data flow scenario 200 is illustrated, in which computing device 106 executes open request 208 for a requested feature currently stored in a dehydrated state on local drive 124. As shown, computing device 106 may receive user activity 216 generated based on user 220's interaction with input device 218 (e.g., keyboard, mouse, touchscreen, microphone, or any other suitable input component). User 220 may execute user activity 216 via input device 218 to request access to various features 204 of OS 108—regardless of whether these features are currently hydrated on computing device 106. As shown, OS 108 includes a feature interface 202 available for accessing each of the first feature 204(1) through the Nth feature 204(N). In various embodiments, feature interface 202 may represent one or more application programming interfaces (APIs) available for invoking a set of subroutines that can be used to implement the desired functionality of OS 108.

[0041] In various embodiments, feature interface 202 may be represented by computing device 106 to user 220 in a consistent manner for individual features 204 (e.g., displayed graphically), regardless of whether those individual features are currently hydrated on computing device 106. For example, a particular feature interface in feature interface 202 may be designed to display a button to user 220 that can be selected to enable computing device 106 to perform a specific function (e.g., translate the message body from the current dialect to the desired dialect). Feature interface 202 may expose this button to user 220 even when the underlying feature 204 performing the specific function is dehydrated on computing device 106. That is, the button is exposed to and / or selectable by user 220 even if the payload of the feature file 206 that actually enables computing device 106 to perform the specific function does not exist on local drive 124.

[0042] for Figure 2AFor the purpose of this, the state of computing device 106 enables feature interface 202 to expose representations of first feature 204(1), second feature 204(2), and Nth feature 204(N). The state of computing device 106 is also implemented such that first feature 204(1) and Nth feature 204(N) are fully hydrated on computing device 106. For example, as shown, multiple feature files 206 enabling the implementation of first feature 204(1) and Nth feature 204(N) are shown as being written to local drive(s) 124. Specifically, each feature file named “Feature_Name1.exe”, “Feature_NameN.exe”, “Feature_Name1.dll”, and “Feature_NameN.dll” is shown as having its payload fully written to local drive 124. Individual feature files 206 in feature files 206 may include various attributes such as filename, file path, payload size, metadata size, and / or automatic dehydration parameters. For the purposes of this discussion, values ​​are specified for each of these attributes in a table extending downwards from the black feature file frame marked 206. These values ​​are used only to convey aspects of this disclosure and are not intended to be limiting in any way.

[0043] In the example shown, the hydration state of the first feature 204(1) results in the consumption of 33MB of storage space to store a feature file named "Feature_Name1.exe", and also consumes an additional 12MB of storage space to store a feature file named "Feature_Name1.dll". As further shown, some additional 41MB of storage is consumed to maintain the hydration state of the Nth feature 204(N). In contrast to the first and Nth features, the second feature 204(2) in Figure 2AThe computing device 106 shown is dehydrated. That is, the individual feature file 206 uniquely corresponding to the second feature 204(2) is shown in a dehydrated state, such that the payload of these feature files is not locally stored on the local drive(s) 124. Thus, as shown, even if the second feature 204(2) is implemented using a batch of two feature files, these two feature files together would require 106 MB of local drive space to be fully hydrated on the computing device 106. However, these feature files are stored locally in a dehydrated state, which omits the actual payload but includes metadata, which has information that can be used to retrieve the payload upon request. These dehydrated feature files can be used as placeholders for hydrated feature files (e.g., including the payload), and the metadata can indicate the feature provider from which the corresponding hydrated feature file can be easily retrieved and / or the address from which the corresponding hydrated feature file can be easily retrieved. In the illustrated embodiment, the fully hydrated feature files are stored by feature provider 102 as a portion of the file batch uniquely corresponding to the second feature 204(2).

[0044] about Figure 2AThe specific data flow scenario 200 shown involves a user activity 216 received in association with the feature interface 202, resulting in a series of interactions between various components of the computing device 106 and the feature provider 102. For example, as shown, user activity 216 causes an open request 208 to be transmitted from the OS 108 to the filter driver 209. For the purposes of this discussion, it is assumed that the open request 208 is requesting data associated with a feature file named “Feature_Name2.exe”. The filter driver 209 may be a file system driver, such as the “cldflt.sys” driver, which is typically deployed with Microsoft OneDrive. As mentioned above, the feature file 206 includes both fully hydrated feature files and dehydrated feature files (e.g., placeholder files). The filter driver 209 assists in processing requests to access various feature files stored on the local drive 124. For example, as shown, when a user performs a computational action that results in the generation of an open request 208 associated with a specific feature file, the filter driver 209 transmits the open request 208 to the local drive 124. In some embodiments, open request 208 may include a re-parsing point that marks one or more fields of metadata 212 associated with the requested file. The re-parsing point may inform filter driver 212 which field of the metadata indicates the hydration status of the requested feature file. For example, filter driver 209 may query local drive 124 for data associated with the requested feature file based on open request 208. If the payload for the requested feature file is stored locally on local drive 124, filter driver 209 may simply serve open request 208 as usual. Conversely, if filter driver 209 queries local drive 124 and determines that the requested feature file is dehydrated such that the payload is not available from local drive 124, filter driver 209 may retrieve the metadata 212 stored associated with the dehydrated file and store that metadata 212 in cache 210.

[0045] Turn now Figure 2BAn exemplary data flow scenario 225 is illustrated, in which a computing device responds to a payload access request 211 by transmitting a download request 128 to the appropriate feature provider. As shown, after the filter driver 209 has cached metadata 212 in response to the open request 208, the OS 108 then transmits the payload access request to the filter driver 209. An exemplary payload access request 211 may be a read request associated with a requested feature file (e.g., the OS may request to read a portion of the payload for the requested feature file). As another example, the payload access request 211 may be a write request associated with a requested feature file (e.g., the OS may request to write data to a portion of the payload for the requested feature file).

[0046] In response to payload access request 211, synchronization engine 112 may then generate download request 128 based on metadata 212. In some embodiments, metadata 212 may include the address from which the requested feature file can be obtained. Additionally or alternatively, metadata 212 may indicate the appropriate feature provider from which the requested feature file can be obtained. For example, as described above, request 208 is requesting access to a feature file named “Feature_Name2.exe”. Therefore, download request 128 may include… Figure 2A The identifier for the specific feature provider 102 is shown because this specific feature provider 102 can provide access to a batch 213 of files titled "Feature_Name2". In some embodiments, a download request 128 is transmitted to feature provider 102 in response to a first payload access request 211 received after an initial open request 208 that causes a cache of metadata 212. It should be understood that such embodiments can reduce unnecessary network traffic because, in various cases, an open request 208 may be received that only requests data associated with file attributes without issuing any subsequent requests for actual access to the payload. Therefore, some embodiments may avoid hydrating the feature file upon receiving a corresponding open request and instead wait until a payload access request is received.

[0047] Turn now Figure 2C An exemplary data stream scenario 250 is illustrated, in which computing device 106 responds after downloading and hydrating the requested feature file by acquiring the corresponding payload and writing it to local drive 124. Figure 2BThe payload access request 211 is executed. As shown, computing device 106 receives download package 130 from feature provider 102. Download package 130 is provided in response to download request 128. Furthermore, download package 130 may include the entire batch of files to which the requested feature file belongs. For example, in this example, suppose download request 128 identifies “Feature_Name2.exe” as the specific file immediately requested in request 208. In these cases, feature provider 102 may identify the file named “Feature_Name2.exe” as part of the batch of files 213 titled “Feature_Name2”. Then, instead of simply returning the requested feature file, feature provider 102 may return the entire batch of files 213 within download package 130. In the current situation, since download request 128 identifies the "Feature_Name2.exe" file, feature provider 102 can retrieve not only the "Feature_Name2.exe" file, but also the "Feature_Name2.dll" file and / or any portion of the payload for the second feature 204(2) currently dehydrated on the computing device. Feature provider 102 then responds to download request 128 for a single file by providing a download package 130 comprising all feature files from the entire predefined batch of feature files 206. In the illustrated embodiment, download package 130 includes first to Nth payloads 252.

[0048] Upon receiving download package 130, synchronization engine 112 writes the payloads for individual feature files within file batch 213 to local drive 124. For example, computing device 106 and / or synchronization engine 112 may decompress download package 130 and write each of the included feature files to local drive 124 (e.g., hard disk, solid-state drive, or any other suitable volatile or non-volatile storage medium) to hydrate these feature files from a dehydrated state. Thus, based on an initial request 208 requesting access to only a single feature file (e.g., the “Feature_Name2.exe” file) of file batch 213, various system components such as filter driver 209, synchronization engine 112, and feature provider 102 work together to fully hydrate the entire batch of feature files (even those that have not yet been requested) by downloading and then locally storing all their corresponding payloads. Then, once the entire batch of feature files 213 is fully hydrated (or when the batch of feature files is actively hydrated), the computing device 106 serves the request 208 by providing a response 254 to the OS—where the response 254 provides access to the payload 252 that has been downloaded to the computing device and written to its local drive 124.

[0049] In some embodiments, the entire payload for a requested feature file may be fully hydrated in response to the initial receipt of any payload access request. In this way, whenever any portion of the payload is requested for a particular feature file, the entire payload becomes fully hydrated and available from the local drive. In other embodiments, specific portions of the payload for a requested feature file may be gradually hydrated to the local drive as a large number of increasing payload access requests are received. For example, a first payload access request may be received requesting access to a specific portion of the payload for a requested feature file. This first payload access request may trigger the hydration of one or more other portions of the payload adjacent to the requested portion. For example, if the requested feature file is a map file defining various rooms in a map of a 3D first-person video game, a payload access request for the portion of the payload defining a particular room may trigger the hydration of other portions of the payload defining adjacent rooms. In this way, if the player moves from a particular room to any other adjacent room, the data required to draw the corresponding adjacent room is fully hydrated and ready for use from the local drive.

[0050] like Figures 2A to 2B As shown, in some embodiments, even for fully hydrated feature files, metadata 212, which can be used to identify and contact the appropriate feature provider 102 from which individual feature file 206 can be obtained, is also stored on local drive 124. In this way, individual feature file 206 can be converted from a hydrated state to a dehydrated state simply by removing the associated payload from local drive 124. In this way, dehydrated individual feature files do not require computing device 106 to communicate with feature provider 102 to obtain and store metadata 212. Instead, in some embodiments, metadata 212 may be permanently stored on computing device 106 such that, in the event that payload 252 is corrupted or deleted (unintentionally or intentionally), computing device 106 retains the ability to make filter driver 209 and synchronization engine 112 work together to obtain and fully hydrate any desired feature file 206.

[0051] In some embodiments, individual feature files 206 in feature files 206 include automatic dehydration parameters indicating one or more conditions under which computing device 106 will deallocate storage capacity of local drive 124 from payload 252 for any particular feature file 206. In some instances, deallocating storage capacity for payload 252 may include: actually deleting the payload from local drive 124. In some instances, deallocating storage capacity for payload 252 may include: allowing computing device 106 to overwrite the storage capacity currently used to store payload 252. As shown, for example, feature files 206 may be associated with automatic dehydration parameters that restrict individual files from being dehydrated, alternatively, setting an inactivity period after which the individual files will be dehydrated. For example, feature files 206 associated with first feature 204(1) have an automatic dehydration parameter "No" that restricts these feature files 206 from being dehydrated. Such parameters may be applied to "core" OS features or any other features or feature files thereof that will be permanently hydrated on computing device 106. As another example, feature files 206 associated with the second feature 204(2) and the Nth feature 204(N) each have corresponding automatic dehydration parameters that set an inactivity period after which these feature files will be dehydrated on the computing device 106. Figures 2A to 2B In the specific but not limiting example shown, the feature file titled "Feature_Name2.exe" will be automatically dehydrated if it has not been accessed for 5 days. Such parameters can be applied to feature files that correspond to features that are rarely used, such that these feature files are automatically hydrated when invoked and then automatically dehydrated if they have not been used for a specified period of time (e.g., 5 days in this example).

[0052] Figure 3 This is a flowchart of an example method 300 for dynamically hydrating an individual feature file or multiple batches of feature files to a local drive of a computing device when invoked by a software component at the computing device. Those skilled in the art will understand that the operations of the methods disclosed herein are not necessarily presented in any particular order, and that performing some or all of the operations in one of several alternative orders is possible and contemplated. For ease of description and illustration, these operations have been presented in the order of demonstration. Operations may be added, omitted, performed together, and / or performed simultaneously without departing from the scope of the appended claims.

[0053] At box 301, example method 300 begins.

[0054] At box 303, the system (e.g., computing device 106) receives a request to access a feature file that can be used to implement features of a software component. For example, as per [reference to...] Figures 1 to 2BThe operating system (OS) 108 may execute on the computing device 106 to manage computer hardware and / or software resources. OS 108 may also provide services to various applications 110 installed and / or executed on the computing device 106. In some embodiments, requests may be generated in association with a feature interface 202 of OS 108 and / or application 110. The feature interface 202 may be represented (e.g., displayed) by the computing device 106 to the user 220 in a consistent manner for individual features 204, regardless of whether those individual features are currently hydrated on the computing device 106. For example, a particular feature interface in feature interface 202 may be designed to display a button to the user 220 that can be selected to cause the computing device 106 to perform a specific function (e.g., translate a message body into a desired dialect) – even when the underlying feature 204 performing the specific function is dehydrated on the computing device 106. That is, the button is exposed to and / or selectable by user 220 even if the payload of the feature file 206 that actually enables computing device 106 to perform a specific function does not exist in local drive 124.

[0055] At box 305, the system can determine whether the requested feature file is currently hydrated to the local drive 124 of computing device 106. For example, as described above, upon receiving a request 208 for a specific feature file, the system (or a component thereof) can perform a hydration check 210 on the specific feature file on local drive 124. As a specific but not limiting example, a filter driver 209 on computing device 106 can query local drive 124 for the requested feature file and determine whether the corresponding payload is available.

[0056] If the system determines that the requested feature file is hydrated onto computing device 106, exemplary method 300 can proceed to block 307, where the system serves the request by providing access to the payload of the requested feature file. For example, as Figure 2B As shown, filter driver 209 can respond to request 208 with response 254, which includes a payload of any requested feature file. It should be understood that since the payload already exists on computing device 106, the request can be served immediately without the intermediate step of hydration of the requested feature file. Once the request is served, example method 300 ends at box 309.

[0057] Conversely, if the system determines that the requested feature file is not hydrated to computing device 106, exemplary method 300 can proceed from block 305 to block 311, where metadata associated with the requested feature file is retrieved from local drive 124. As described above, metadata 212 may include the address from which the requested feature file can be obtained and / or an indication of the appropriate feature provider 102 from which the requested feature file can be obtained.

[0058] At box 313, the system can transmit download request 128 to feature provider 102 corresponding to metadata 212. For example, the system can deploy synchronization engine 112 to generate download requests based on metadata. Synchronization engine 112 can transmit download requests to feature providers to obtain the requested feature file and / or the entire batch of feature files to which the requested feature file belongs.

[0059] At box 315, the system receives download package 130 from feature provider 102. Download package 130 includes at least a payload corresponding to the requested feature file. In some embodiments, download package 130 includes only the payload of the feature file requested at box 303. In some embodiments, download package 130 includes a whole batch of feature files—where at least some feature files were not requested at box 303.

[0060] At box 317, the system hydrates at least the specific feature file by writing the payload for that specific feature file requested at box 303 to local drive 124. In some embodiments, download package 130 includes payloads for the entire batch of feature files to which the requested feature file belongs. Then, after hydrating at least the requested feature file (and any other feature files) provided in the download request, exemplary method 300 proceeds from box 317 to box 307, where the system serves the request by providing access to the payload of the requested feature file—which has been hydrated to the computing device since the request was initially received at box 303. For example, as Figure 2B As shown, filter driver 209 can respond to request 208 with response 254, which includes any requested payload of the feature file. Once the request is served, example method 300 ends at box 309.

[0061] Turn now Figure 4 A flowchart 400 is shown for monitoring attributes associated with individual or batch feature files to dynamically dehydrate individual or batch feature files when automatic dehydration parameters are met.

[0062] At box 401, example method 400 begins.

[0063] At box 403, the system (e.g., computing device 106) identifies multiple batch feature files having payloads written to a local drive. Since the payloads are stored locally, multiple batch feature files can occupy a significant amount of storage space on the local drive. However, as stated above, the importance of keeping any individual batch feature file hydrated on the device may differ from that of other individual batch feature files. For example, the first batch feature file might enable the implementation of commonly used functions of the operating system (OS). In contrast, the second batch feature file might enable the implementation of rarely used functions of the OS. In this example, it can be understood that the importance of locally storing the payload(s) for the first batch feature file can be relatively higher than the importance of locally storing the payload(s) for the second batch feature file.

[0064] At box 405, the system can determine automatic dehydration parameters associated with multiple batches of feature files. As described above, the automatic dehydration parameters can specify an inactivity period after which individual feature files or batches of feature files will be dehydrated from a local drive on computing device 106. For example, an automatic dehydration parameter of 5 days specified in association with a particular feature file may cause the payload for that particular feature file to be deleted from the local drive after the specified automatic dehydration parameter is met.

[0065] At box 407, the system monitors attributes associated with multiple batches of feature files. Exemplary attributes that the system may monitor include, but are not limited to: a usage frequency attribute indicating how often an individual feature file is used on a computing device, a last usage attribute indicating the elapsed time period since an individual feature file was used, etc. As a specific example, the system may monitor the "Accessed" attribute, as is available in various versions of the Microsoft Windows operating system.

[0066] At box 409, in response to the condition monitored at box 407 that the attributes of a batch of individual feature files meet the automatic dehydration parameters, the system releases storage capacity from the individual batch of feature files. As a specific example, if the automatic dehydration parameters specify 5 days of inactivity as a condition for dehydrating a specific feature file or a batch of feature files, then in response to 5 days having elapsed since the last access to the specific feature file, the system can release storage capacity for the specific feature file or the batch of feature files. Once the storage capacity for feature files(s) has been dehydrated, example method 400 ends at box 411. Of course, after method 400 completes, the feature files(s) can be rehydrated on demand according to the techniques described herein. For example, at some point after method 400 completes, a request for newly dehydrated feature files(s) can be issued. Such a request can trigger method 300 to be executed to rehydrate the previously dehydrated feature files(s).

[0067] Turn now Figure 5 The diagram illustrates a flowchart 500 for generating a download package that excessively includes the download request, based on the state of the computing device that sent the download request. In other words, a specific download package generated in response to a specific request can be compiled to include more data (e.g., more feature files and / or its payload) than required in the specific request.

[0068] At box 501, example method 500 begins.

[0069] At box 503, the system (e.g., feature provider 102) receives a download request from the computing device. For the purposes of this discussion, the download request received from the computing device identifies a first feature file associated with a feature of a software component (such as OS 108 and / or application 110). However, the download request does not explicitly identify one or more second feature files that are also associated with a feature of a software component. For example, as per [reference to...] Figures 2A to 2B The initial request can be generated for a single feature file (e.g., the "Feature_Name2.exe" file), and since there is no payload for the single feature file on the local drive, the computing device 106 can generate a download request 128 using one or more system components (e.g., filter driver 209 and / or synchronization engine 112), which specifically requests the single feature file to be provided from the feature provider 102.

[0070] At box 505, the system can identify a batch of feature files including the first feature file identified within the download request. In addition to the first feature file, the identified batch of feature files may also include one or more second feature files. Furthermore, the first feature file and one or more second feature files can be associated with features of the software component. Continuing from the above... Figures 2A to 2B As described in the example, a single feature file may be a file named "Feature_Name2.exe", and one or more second feature files may include at least the filename "Feature_Name2.dll" - wherein feature files formatted as executable (".exe") files and feature files formatted as dynamic link libraries (".dll") files may be used together to achieve the desired features of the OS and / or application.

[0071] At box 507, the system can generate a download package that includes at least a first feature file (specifically identified within the download request) and one or more second feature files associated with a batch of feature files related to the desired feature. In some embodiments, the download package can be generated at least in part based on the current state of the computing device at the time the download request is generated. For example, in some cases, one or more individual feature files may typically be included in two or more batches of feature files. As a particular but not limiting example, a particular feature file may serve as a master dynamic link library, which is available from multiple different features that are related to each other in some respects. Furthermore, a particular batch of feature files including the master dynamic link library may be fully hydrated onto the computing device, while another batch of feature files that also includes the master dynamic link library may be dehydrated on the computing device. A user activity can then be performed that results in the generation of a request for a particular dehydrated feature file belonging to the other batch of feature files. In these cases, when a download request is received associated with another batch of feature files currently being dehydrated on the computing device, the system can check the current state of the computing device to determine that the master dynamic link library has been fully hydrated onto the computing device. Based on this determination, the system can then customize the generated download package to exclude the main dynamic link library, even though it is a component of a batch of feature files associated with the desired features.

[0072] At box 509, the system can transmit a download package to the computing device to enable the first feature file and one or more second feature files to be locally hydrated. For example, the system can compress the download package into a suitable compression format (e.g., a compressed file with a ".cab" extension) and then transmit the download package to the computing device. Once the download package has been successfully transmitted to the computing device, example method 500 ends at box 511.

[0073] Example Terms

[0074] The disclosures proposed herein may be considered in light of the following provisions.

[0075] Example Clause A, a computing device for automatically hydrating multiple batches of feature files, includes: a local drive; one or more processors; and a memory communicating with the one or more processors, the memory storing computer-readable instructions that, when executed by the one or more processors, cause the computing device to: receive a request to access a first feature file, the first feature file being available for implementing features of a software component on the computing device; in response to receiving the request to access the first feature file, retrieve metadata written to the local drive of the computing device to indicate whether a first payload of the first feature file has been written to the local drive of the computing device; in response to the metadata indicating that the first payload of the first feature file has not been written to the local drive of the computing device, cause a download request to be transmitted to a feature provider associated with features of a software component, wherein the features of the software component correspond to a batch of feature files including at least the first feature file and a second feature file; based on the download request, receive a download package for the batch of feature files from the feature provider, wherein the download package includes: a first payload for the first feature file and a second payload for the second feature file; and based on the download package for the batch of feature files, write the first payload for the first feature file and the second payload for the second feature file to the local drive of the computing device; and service the request by providing access to the first payload of the first feature file.

[0076] Example Clause B, a computing device according to Example Clause A, wherein computer-readable instructions are also executable to cause the computing device to: determine, in response to a request to access a first feature file, whether a first payload has been written to a local drive, wherein causing a download request to be transmitted to the feature provider is in response to determining that the first payload does not exist in the local drive.

[0077] Example Clause C, a computing device pursuant to any one of Example Clauses A to B, wherein computer-readable instructions are also executable to cause the computing device to:

[0078] After the request is served, determine whether one or more conditions are met based on a batch of feature files; and

[0079] In response to determining that one or more conditions have been met, at least some storage capacity is released from a batch of feature files.

[0080] Example Clause D, a computing device pursuant to any one of Example Clauses A to C, wherein releasing at least some storage capacity includes at least one of: removing at least one of a first payload or a second payload from a local drive, or allowing the computing device to overwrite at least one of a first payload or a second payload on a local drive.

[0081] Example clause E, a computing device pursuant to any one of example clauses A to D, wherein a request is generated based on user activity received in association with a characteristic interface of a software component, and wherein the user activity causes the request to be transmitted to a filter driver configured to perform a hydration check on the computing device.

[0082] Example Clause F, a computing device pursuant to any one of Example Clauses A to E, wherein metadata indicates an address from which a first payload for a first feature file and a second payload for a second feature file can be downloaded.

[0083] Example clause G, a computing device pursuant to any one of example clauses A to F, wherein metadata indicates the identifier of a feature provider associated with a feature of a software component.

[0084] Example Clause H, a computing device pursuant to any one of Example Clauses A to G, wherein the software component is an operating system executed on the computing device.

[0085] Example Clause I, a computer-implemented method, includes: receiving, by a computing device, a request to access a first payload, the first payload corresponding to a first feature file in a batch of feature files, the first feature file being usable for implementing features of a software component on the computing device; retrieving metadata stored on a storage medium of the computing device in association with the first feature file; in response to the request, transmitting a download request to a feature provider associated with a feature of the software component, the download request including aspects of the metadata used to identify the first feature file; based on the download request, receiving a download package transmitted by the feature provider, the download package including: a first payload corresponding to the first feature file and at least one second payload corresponding to at least one second feature file in the batch of feature files; and based on the download package, serving the request by providing access to the first payload corresponding to the first feature file and the second payload corresponding to the second feature file.

[0086] Example clause J, the computer-implemented method according to example clause I, further includes: writing a first payload corresponding to a first feature file and at least one second payload corresponding to at least one second feature file into the storage medium of the computing device based on the downloaded package.

[0087] Example clause K, the computer-implemented method according to any one of example clauses I to J, further includes: in response to a request, performing a hydration check to determine whether a first payload corresponding to a first feature file is available from a storage medium of a computing device; and in response to determining that the first payload is not present in the storage medium, generating a download request.

[0088] Example clause L, the computer-implemented method according to any one of example clauses I to K, further includes: after serving a request by providing access to a first payload, in response to determining that a threshold time period has elapsed since the last use of the first feature file, releasing at least some storage capacity from the first feature file.

[0089] Example clause M, a computer-implemented method according to any one of example clauses I to L, wherein releasing at least some storage capacity from a first feature file comprises: deleting a first payload from the storage medium of a computing device.

[0090] Example Clause N, a computer-implemented method according to any one of Example Clauses I to M, wherein the metadata indicates at least one of the following: an address from which a first payload for a first feature file can be downloaded; or a feature provider.

[0091] Example Clause O, a computer-implemented method according to any one of Example Clauses I to N, wherein the download request includes an identifier of a first feature file and lacks an identifier of a second feature file.

[0092] Example Clause P, a system comprising: one or more processors; and a memory communicating with the one or more processors, the memory storing computer-readable instructions that, when executed by the one or more processors, cause the system to: receive a download request from a computing device, the download request identifying a first feature file associated with a feature of a software component; based on the download request, identify a batch of feature files associated with a feature of the software component, wherein the batch of feature files includes the first feature file and one or more second feature files; generate a download package, the download package including at least: a first payload corresponding to the first feature file and one or more second payloads corresponding to the one or more second feature files; and transmit the download package to the computing device to enable implementation of a feature of the software component.

[0093] Example Clause Q, according to Example Clause P, a system in which a batch of feature files also includes a third feature file, and wherein computer-readable instructions are also executable by one or more processors to cause the system to: omit the third payload corresponding to the third feature file from the download package based on the state of the computing device corresponding to the state of the computing device on which the third payload is being written.

[0094] Example clause R, a system according to any one of example clauses P to Q, wherein the software component is an operating system executed on a computing device.

[0095] Example Clause S, a system according to any one of Example Clauses P to R, wherein the first feature file identified in the download request is a first file format, and wherein one or more second feature files provided in the download package are formatted according to one or more second file formats.

[0096] Example clause T, a system according to any one of example clauses P to S, wherein a download request identifying a first characteristic file lacks the identifier of one or more second characteristic files.

[0097] in conclusion

[0098] Finally, while various techniques have been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended representation is not necessarily limited to the specific features or actions described. Rather, specific features and actions are disclosed as exemplary forms of implementing the claimed subject matter.

Claims

1. A computing device for automatically hydrating multiple batches of feature files, comprising: Local drive; At least one processor; A memory, in communication with the at least one processor, on which the computer is stored. Computer-readable instructions, which, when executed by the at least one processor, cause the computing device to: Receive a request to access a first feature file, which can be used to implement the features of a software component on the computing device; In response to receiving the request to access the first feature file, metadata is retrieved from a placeholder file that is written to the local drive of the computing device. The metadata indicates whether a first payload of the first feature file has been written to the local drive of the computing device and also indicates the feature provider from which the first feature file is to be obtained. In response to the metadata indicating that the first payload of the first feature file has not been written to the local drive of the computing device, a download request is transmitted to the feature provider associated with the feature of the software component, wherein the feature of the software component corresponds to a batch of feature files that includes at least the first feature file and the second feature file, wherein the download request lacks an identifier for the second feature file; Based on the download request, a download package for the batch of feature files is received from the feature provider, wherein the download package includes: a first payload for the first feature file and a second payload for the second feature file; and Based on the downloaded package for the aforementioned batch of feature files: Write the first payload for the first feature file and the second payload for the second feature file to the local drive of the computing device; and The request is served by providing access to the first payload of the first feature file.

2. The computing device of claim 1, wherein the computer-readable instructions are further executable by the at least one processor to cause the computing device to: In response to the request to access the first feature file, it is determined whether the first payload has been written to the local drive, wherein the download request is transmitted to the feature provider in response to determining that the first payload does not exist in the local drive.

3. The computing device of claim 1, wherein the computer-readable instructions are further executable by the at least one processor to cause the computing device to: After the request is served, it is determined whether at least one condition is met regarding the batch of feature files; and In response to determining that at least one condition has been met, at least some storage capacity is released from the batch of feature files.

4. The computing device of claim 3, wherein deallocating the at least some of the storage capacity comprises at least one of the following: Delete at least one of the first payload or the second payload from the local drive, or The computing device is allowed to cover at least one of the first payload or the second payload on the local drive.

5. The computing device of claim 1, wherein the request is generated based on user activity received in association with a characteristic interface of the software component, and wherein the user activity causes the request to be transmitted to a filter driver configured to perform a hydration check on the computing device.

6. The computing device of claim 1, wherein the metadata indicates an address from which the first payload for the first feature file and the second payload for the second feature file can be downloaded.

7. The computing device of claim 1, wherein the metadata indicates an identifier of the feature provider associated with the feature of the software component.

8. The computing device of claim 1, wherein the software component is an operating system executed on the computing device.

9. A computer-implemented method, comprising: A computing device receives a request to access a first payload, the first payload corresponding to a first feature file in a batch of feature files, the first feature file being used to implement features of software components on the computing device; Metadata is retrieved from a placeholder file, which is stored on the storage medium of the computing device in association with the first feature file. The metadata indicates whether the first payload of the first feature file has been written to the local drive of the computing device and also indicates the feature provider from which to retrieve the first feature file. In response to the request, a download request is transmitted to the feature provider associated with the feature of the software component, the download request including aspects of the metadata that identify the first feature file and lacking an identifier for at least one second feature file; Based on the download request, a download package transmitted by the feature provider is received, the download package including: a first payload corresponding to the first feature file and at least one second payload corresponding to at least one second feature file in the batch of feature files; as well as Based on the download package, the request is served by providing access to the first payload corresponding to the first feature file and the at least one second payload corresponding to the at least one second feature file.

10. The computer-implemented method according to claim 9, further comprising: Based on the downloaded package, the first payload corresponding to the first feature file and the at least one second payload corresponding to the at least one second feature file are written into the storage medium of the computing device.

11. The computer-implemented method according to claim 9, further comprising: In response to the request, a hydration check is performed to determine whether the first payload corresponding to the first feature file is available from the storage medium of the computing device; as well as In response to determining that the first payload does not exist in the storage medium, the download request is generated.

12. The computer-implemented method according to claim 9, further comprising: After serving the request by providing access to the first payload, in response to determining that a threshold time period has elapsed since the last use of the first feature file, at least some storage capacity is released from the first feature file.

13. The computer-implemented method of claim 12, wherein releasing the at least some storage capacity from the first feature file comprises: The first payload is removed from the storage medium of the computing device.

14. The computer-implemented method of claim 9, wherein the metadata indicates at least one of the following: an address from which the first payload of the first feature file can be downloaded, or the feature provider.

15. The computer-implemented method of claim 9, wherein the download request includes an identifier of the first feature file and lacks an identifier of the second feature file.

16. A system comprising: At least one processor; A memory, in communication with the at least one processor, storing computer-readable instructions that, when executed by the at least one processor, cause the system to: A download request is received from a computing device, the download request identifying a first feature file associated with a feature of the operating system, and the download request lacking an identifier for at least one second feature file associated with the feature of the operating system; Based on the download request, a batch of feature files associated with the characteristics of the operating system are identified, wherein the batch of feature files includes the first feature file and the at least one second feature file; A download package is generated, the download package including at least: a first payload corresponding to the first feature file and at least one second payload corresponding to the at least one second feature file; as well as The download package is transmitted to the computing device to enable the implementation of the features of the operating system.

17. The system of claim 16, wherein the batch of feature files further comprises a third feature file, and wherein the computer-readable instructions are further executable by the at least one processor to cause the system to omit the third payload corresponding to the third feature file from the download package based on the state of the computing device corresponding to the state of the computing device on which the third payload is being written.

18. The system of claim 16, wherein the first feature file is formatted according to a first file format, and wherein the at least one second feature file is formatted according to at least one second file format.

Images