Method, system, and program for predictive provisioning of remote files

Abstract

A computer system having access to a remote file stored on a remote system predicts that a portion of the remote file is likely to be needed, and the computer system downloads this portion of the remote file to a local file and updates the metadata of the local file to reflect the downloaded portion.

Description

[Technical field]

[0001] The present invention relates to storage, and more particularly to predictively downloading remotely stored files to a local file system. [Background technology]

[0002] Cloud storage has become increasingly popular in both commercial and personal environments. Cloud sync storage applications allow a user's cloud-stored files and / or data to be automatically downloaded to local storage when the user installs the cloud sync storage application on a new computer.

[0003] However, automatically downloading all files stored in the user's cloud is likely to consume bandwidth and local storage space unnecessarily. For example, if the user's cloud contains several important documents and several terabytes (TB) of video files, automatically downloading all files may take hours or days (or even longer) depending on the configuration of the user's new local machine and Internet connection, and may even completely fill up the local storage of the user's new machine before the important documents are downloaded. Therefore, many cloud sync storage applications implement various methods to prevent unnecessary downloading of large amounts of data, such as providing a list of files and downloading files only when a read command is received (e.g., when the user tries to open a file that is currently only in the cloud, i.e., a file for which no local copy currently exists).

[0004] These methods also allow the cloud system to act as "remote storage": a user may upload a file to the cloud and delete the local copy of the file, thus freeing up storage space on the user's local system. When the user wants to use the file again, the cloud sync storage application initiates a download of the file "back" to local storage, making the file available.

[0005] However, many types of read commands do not require access to the entire file. For example, many file explorer systems automatically generate a thumbnail image of a video file by simply using a default frame of the video (e.g., the fifth frame). This single frame may be read from the video file (a process initiated by the read request), possibly compressed and / or resized, and then displayed as the thumbnail, at which point no further information about the file may be needed. Thus, a read request requesting access to a large video file (e.g., a multi-GB file) may actually only require reading a few kilobytes (kB).

[0006] Conventional systems may respond to a read request that targets a file by initiating a download of the entire file, which can result in a significant waste of computational resources. Continuing with the example above, a conventional system may download an entire video file even if only a single frame of the video is needed at the time. Summary of the Invention

[0007] According to one aspect of the present invention, a method is provided that includes identifying a remote file stored on a remote computing system, predicting that a predicted portion of the remote file is likely to be the target of a future read request, downloading the predicted portion of the remote file to a local file, and updating metadata of the local file to map local portions of the local file to the predicted portions of the remote file. The method advantageously improves the efficiency of a remote file storage computing system by predictively downloading portions of the remotely stored file when the remotely stored file is requested, potentially reducing the size of the data downloaded.

[0008] The method may further include receiving a first read request, where the identifying is based at least on a target of the first read request and the predicting is based at least on the first read request. The method advantageously improves efficiency of a remote file storage computing system by downloading portions of a remotely stored file predicted to be needed (rather than the entire file) in response to a request to read the file.

[0009] The method may further include determining a requesting application that initiated the first read request based at least on an application profile database, and the predicting is further based at least on the requesting application. The method advantageously improves accuracy in the prediction by predicting the portion to download based on the application requesting the file.

[0010] The method may further include receiving a second read request targeting the targeted portion of the remote file and updating the application profile database based at least on the predicted portion and the targeted portion. The method also advantageously enables increased accuracy in determining a correlation between the application identification information and the predicted portion.

[0011] Another aspect of the invention is provided in the form of a computer program product comprising a computer readable storage medium having program instructions embodied thereon that are executable by a computer to cause the computer to perform any of the methods described above that advantageously improves the efficiency of a remote file storage computing system by predictively downloading portions of a remotely stored file when the remotely stored file is requested, thereby reducing the size of the data downloaded.

[0012] Another aspect of the invention is provided in the form of a system including a memory and a central processing unit (CPU), which may be configured to perform any of the methods described above, which advantageously improves the efficiency of remote file storage computing systems by predictively downloading portions of a remotely stored file when the remotely stored file is requested, thereby reducing the size of the data downloaded.

[0013] The above summary is not intended to describe each example embodiment or every implementation of the present disclosure.

[0014] The drawings contained in this application are incorporated herein and form a part of this specification. The drawings, together with the description, illustrate embodiments of the present disclosure and serve to explain the principles of the disclosure. The drawings are merely examples of particular embodiments and do not limit the disclosure. As the following Detailed Description proceeds, features and advantages of various embodiments of the claimed subject matter will become apparent when referring to the drawings in which like numerals indicate like parts. [Brief description of the drawings]

[0015] [Figure 1] FIG. 1 illustrates a method for predictively provisioning files stored in the cloud in response to a read request targeting one of the files stored in the cloud, according to embodiments of the present disclosure. [Diagram 2] 1 is a block diagram of an exemplary cloud-stored file and an exemplary locally-stored file after downloading an identified portion of the cloud-stored file in accordance with embodiments of the present disclosure. [Diagram 3] FIG. 1 illustrates a method for identifying an application responsible for initiating a read request, consistent with embodiments of the present disclosure. [Figure 4] FIG. 1 illustrates a method for predictive provisioning of cloud-synced files consistent with embodiments of the present disclosure. [Diagram 5] FIG. 1 illustrates a cloud computing environment in accordance with an embodiment of the present disclosure. [Figure 6] FIG. 1 illustrates an abstract model layer according to an embodiment of the present disclosure. [Figure 7] FIG. 1 is a high-level block diagram of an exemplary computer system that may be used to implement embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] While the invention is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that it is not intended to limit the invention to the particular embodiments described. On the contrary, it is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

[0017] Aspects of the present disclosure relate to systems and methods for predictively provisioning files stored in one or more clouds. More particular aspects relate to a system for detecting a read request, classifying a type of the read request, predicting portions of a cloud-stored file required to satisfy the read request, and downloading the predicted portions of the cloud-stored file.

[0018] Throughout this disclosure, reference is made to a "cloud sync storage application." As used herein, a "cloud sync storage application" refers to an application that runs on a client computing system ("client device") to enable the client device to upload one or more files to a cloud-based computing system ("cloud") and download files from the cloud, e.g., via the Internet. After the files are uploaded, the client device may delete the local copy of the uploaded file, but may later download the cloud-stored file back to local storage. This allows the client device to free up local storage space while still being able to access the files when needed. As will be appreciated by those skilled in the art, the systems and methods described herein are not necessarily limited to use with cloud-based systems, and remote file storage in general may be improved in accordance with the present disclosure.

[0019] A cloud-synced storage application typically provides a list of files stored in the cloud, any of which may be stored locally. This list is typically implemented as a set of "placeholder" files (files that typically contain only minimal metadata about the actual files, such as filename, file size, last modified date, etc.). From the perspective of a user of a client device, the files may be presented as if they were all stored locally, or the files may be presented with a marker to distinguish files stored both in the cloud and locally, as opposed to files that currently exist in the "cloud only". As used herein, the phrase "cloud-only" refers to files that are stored in the cloud system but not on the local storage device (i.e., there is no local copy of a cloud-only file). A cloud-only file may typically be downloaded to local storage on demand via a cloud-synced storage application, after which the file is no longer referred to as "cloud-only" herein. Note that "cloud-only" is not synonymous with "placeholder". As a clarifying example, consider a 3GB video file that is stored in the cloud but not on the client device: the "cloud-only" file would refer to the 3GB video file itself, stored on the cloud, while an associated approx. 1kB "placeholder" file is stored locally on the client device to represent the video file (e.g., listing metadata such as filename, file type, etc.). Thus, if a user of a client device wanted to open the "cloud-only" file, the user could double-click on the "placeholder" file.

[0020] In particular, while this disclosure broadly refers to files stored in the cloud, some entities may utilize geographically distributed servers located at end-user premises. These and other similar use cases may be considered implementations of "private clouds." The present disclosure may advantageously improve the performance of such systems, as will be appreciated by those skilled in the art.

[0021] Throughout this disclosure, references are made to a "read request." As used herein, "read request" refers to a category of digital requests, all of which are requesting access to a file. A read request may be initiated by a user action, such as by a user double-clicking an icon representing a file (this action is sometimes referred to as an "open" request, which is a type of read request). A read request may also be initiated automatically by an application running on a client device, such as a file explorer program that attempts to automatically generate a thumbnail of a video file without direct user input.

[0022] A read request is typically the operating system's or file explorer's first step in the process of accessing a file. File explorer systems in particular do not necessarily disclose what portion of the file is required as part of the initial read request. Instead, in a standard computer system, a read request that identifies the relevant file may be sent to a storage controller. The storage controller may react to the read request by locating the identified file and responding with an acknowledgment indicating that the requested file is ready to be read. The file explorer may then proceed with a more specific request (i.e., "return bits 300 through 700 of the file").

[0023] Furthermore, many read requests do not require access to the entire file. For example, continuing with the "thumbnail" example above, many file explorer systems automatically generate a thumbnail image for a video file by simply using a default frame of the video (e.g., the 5th frame). This single frame may be read from the video file (a process initiated by the read request), possibly compressed and / or resized, and then displayed as the thumbnail, at which point no further information about the file may be needed. Thus, a read request requesting access to a large video file (e.g., a multi-GB file) may actually only require reading a few kilobytes (kB).

[0024] A cloud sync storage application may monitor for read requests requesting access to a cloud-only file. If a conventional cloud sync storage application detects a read request that is directed to a cloud-only file, it may respond by initiating a download of the file and subsequently responding to the request with an acknowledgment indicating that the file is ready to be read.

[0025] However, systems and methods consistent with this disclosure allow for determining, predicting, estimating, or otherwise estimating which portions of a file that is the subject of a read request are likely to actually be needed, and for those portions to be downloaded. By downloading only certain portions of a file based on a prediction, systems and methods consistent with this disclosure advantageously save significant resources (e.g., bandwidth, local storage space, processing resources, energy, time, etc.). For example, if it is determined that the file is a large video file and the read request only requires a single frame, downloading only that frame instead of the entire video file may save gigabytes of bandwidth.

[0026] To determine which portions of a file subject to a read request should be downloaded, aspects of a cloud sync storage application consistent with this disclosure may classify the read request based on contextual information, which may include, for example, information describing the application initiating the read request (e.g., file explorer, image editor, etc.) and / or the client system (uptime, recent activity such as downloads, installations, etc., etc.).

[0027] Upon detecting a request to read a cloud-only file (e.g., a request to read a placeholder file for the corresponding cloud-only file), the cloud sync storage application may utilize contextual information to determine and / or classify the nature of the read request to determine which portions of the cloud-only file should be downloaded. The contextual information may include, for example, information describing the application initiating the read request (e.g., file explorer, image editor, etc.) and / or the client system (uptime, recent activity such as downloads, installations, etc.). Examples of contextual information used by the cloud sync storage application include application identification information, system configuration information, past request data, pre-configured / hard-coded patterns, etc.

[0028] For example, a first application may frequently initiate read requests only to read a small, specific portion of a file, while a second application may frequently initiate read requests that require a large portion of the file or even the entire file. These profiles may develop over time and be monitored by an application profiler, as described in further detail below. Based at least in part on the information collected from the application profiler, the read requests may be classified into one of a number of categories. A read request initiated by a first application may be more likely to require access only to a small, specific portion of the file. In this case, a cloud sync storage application consistent with the present disclosure may anticipate that the entire file will not be needed to fulfill the request and may therefore initiate a download of the small, specific portion of the file. On the other hand, a read request initiated by a second application may be more likely to require the entire file. Thus, depending on the application from which the read request originates, the cloud sync storage application may identify and download the specific portion of the file (or the entire file, if deemed necessary).

[0029] It should be understood that the foregoing advantages and other advantages described herein are exemplary advantages and should not be construed as limiting, and embodiments of the present disclosure may include all, some, or none of the advantages while remaining within the spirit and scope of the present disclosure.

[0030] FIG. 1 illustrates a method 100 for predictive cloud-stored file provisioning consistent with embodiments of the present disclosure. In some embodiments, the method 100 may be performed by hardware, firmware, software running on a processor, or any combination thereof. For example, the method 100 may be performed by a cloud sync storage application consistent with the present disclosure. The method 100 includes, at operation 102, detecting a read request requesting (or directed to) a file stored in the cloud. Operation 102 may include, for example, the cloud sync storage application monitoring requests initiated by applications running on the client device. The cloud sync storage application may maintain a list of files stored in the cloud (particularly "cloud-only" files) with local storage of corresponding placeholder files. Additionally, the cloud sync storage application may be configured with a privilege level that allows it to monitor commands or requests initiated by relatively low-level applications, such as a file explorer or the operating system itself. When an application running on a client device (e.g., a file explorer, etc.) initiates a read request that includes a file identifier of a placeholder file that corresponds to a cloud-only file, the cloud synced storage application detects the request in operation 102. In some embodiments, the cloud synced storage application may be an application, a service, or a set of functionality included in an operating system.

[0031] Method 100 further includes classifying the read request at operation 104. In general, operation 104 includes determining the "true" origin of the read request and determining the purpose of the read request to estimate what portion of the file actually needs to be downloaded to fulfill the request. For example, the read request may be classified as an "OPEN" request or an "AUX" request. An OPEN request may be associated with opening the file (which requires the entire file to be downloaded), while an AUX request may be associated with any other type of read request. Examples of AUX requests include a request to generate a thumbnail (a "thumbnail request") or a request for file metadata (a "metadata request" that requests information such as size, date, creator, etc.). Other and more specific classifications are possible (e.g., a first type of metadata request may require the creator and file size, while a second type of metadata request may require the creator, file name, and creation date).

[0032] The read request may be classified based on the context information at operation 104. "Context information," as used herein, may include the context of the read request collected from sources other than the read request itself. For example, the context information may include file metadata, an identification of the application initiating the read request (the "requesting application"), the hardware configuration of the client system from which the request originates, the time / date of the request, previous behavior, historical trends, etc. The context information may be determined, for example, based on the output of one or more profiles, as described in more detail below.

[0033] A classification may be selected from a list of possible classifications based on a weighted analysis. For example, various contextual information may be associated with different weights, resulting in a list of possible classifications, each having a predicted likelihood. As an example, if the requested cloud-only file is a video file and the requesting application is a file explorer, the contextual information may weight and / or bias the decision of operation 104 toward a thumbnail request. However, if the requesting application is a media player, a thumbnail request is deemed less likely.

[0034] In some embodiments, the classification with the highest predicted likelihood is selected. In some embodiments, if there is no "outright winner" (e.g., if no possible classification has a likelihood greater than a threshold or if no possible classification has a sufficiently significant "score difference" compared to the others), the system performing method 100 considers the classification to have failed and begins downloading the entire file (at which point method 100 ends). In some embodiments, if the classification attempt does not produce a perfect winner, a classification may be selected randomly. In some embodiments, if the classification attempt does not produce a perfect winner, the system performing method 100 may adjust and re-evaluate the weights of various types of contextual information.

[0035] Method 100 further includes identifying and / or predicting required file segments at operation 106. Operation 106 may include, for example, determining a range of bits of the cloud-only file that are likely to be required by the requesting application. For example, in some embodiments, a system performing method 100 may determine that the first 300 kB are most likely to be requested.

[0036] In some embodiments, the determination made in operation 106 may be based on the classification of the detected read request determined in operation 104. In some embodiments, the system performing method 100 may consider contextual information, such as the contextual information described above, as part of operation 106. For example, if the read request is classified as a thumbnail request, operation 106 may include analyzing the metadata of the file to determine the location of a particular keyframe. On the other hand, in some embodiments, the prediction of operation 106 is based solely on the classification of the request. For example, the system performing method 100 may be "hard-coded" to identify the required portion of the file as between bits 3,000 and 12,000 for all thumbnail requests.

[0037] Some requests may request multiple, non-contiguous portions of a file, and therefore multiple ranges may be identified in operation 106. For example, a metadata request may request the creator name and file name of a file. A file may store metadata in a particular order, e.g., the creator of a file may be stored in bits 13,384-13,415, the creation date of the file may be stored in bits 13,416-13,423, and the file name of the file may be stored in bits 13,424-13,511. Thus, to satisfy an exemplary metadata request, operation 106 may include identifying bits 13,384-13,415 and bits 13,424-13,511.

[0038] After the predicted portion of the file is identified, the method 100 further includes downloading the predicted portion at operation 108. This downloading may include, for example, sending a download request for the data identified at operation 106 to a cloud system and downloading the identified data. As described in further detail below with reference to FIG. 2, the downloaded data may be stored in local storage. In some embodiments, "placeholder" files in a directory may be replaced and / or modified based on the downloaded data. In some embodiments, the downloaded data may be stored in a separate cache and existing placeholder files may remain unchanged.

[0039] In some embodiments, a margin may be further added to the identified portion. In other words, operation 108 may include downloading additional data outside the range of bits predicted to be needed in operation 106. While this may consume additional resources, the beneficial improvement in fault tolerance may outweigh the cost (e.g., if the prediction is incorrect, more data may be downloaded that is actually needed). Referring to the previous example where bits 13,384-13,415 and bits 13,424-13,511 were identified as needed, operation 108 may add, for example, 8 bits of margin to one or more boundaries of the bit range. Thus, the system may, for example, download bits 13,376-13,415 and bits 13,424-13,511 (downloading the additional 8 bits located "before" the predicted range). The system may also download bits 13,384-13,519 (downloading the 8 bits between the two ranges plus the 8 bits at the "boundaries" for a total of 16 additional bits).

[0040] In some embodiments, the margins may be pre-determined. For example, in some embodiments, a system performing method 100 may always add a 5 kB margin to the download at each boundary of each range (if possible). In some embodiments, the margins may be selected based on various parameters, such as the classification and / or contextual information of the read request. For example, the system may download 3 kB "after" an identified range that is needed to satisfy a thumbnail request, but 1 kB "before" and 15 kB "after" a predicted range that is needed to satisfy a metadata request. As will be appreciated by one of ordinary skill in the art, other criteria for the selection of the margins are also possible.

[0041] Operation 108 may further include tracking, mapping, or otherwise recording which bits have been downloaded. As a clarifying example, if bits 235,016 through 235,023 and bits 235,032 through 235,039 are downloaded, these bits are stored in local storage as bits 1 through 16, but operation 108 may further include recording that local bit 1 corresponds to "actual" bit 235,016, local bit 12 corresponds to actual bit 235,035, etc. Such recording may advantageously enable a system performing method 100 to return the correct requested bits, since a read request and subsequent more specific bit requests may "assume" that the complete file is being accessed.

[0042] In some embodiments, operation 108 may include adjusting or otherwise modifying the download speed based on the current network configuration and usage. In some embodiments, operation 108 may include checking whether the predicted data has already been downloaded and stored locally, and if so, the system performing method 100 may not need to perform a download.

[0043] Once the data has been downloaded (or identified), method 100 further includes proceeding as if the complete file were available, at operation 110. Operation 110 may include, for example, sending an acknowledgement signal to the file explorer application and / or the operating system. The acknowledgement may be configured to "mimic" a standard acknowledgement that the requested file has been identified and is ready to be read (e.g., an acknowledgement sent by a storage controller, etc.).

[0044] Thus, the application that sent the read request may proceed as if the complete file was available and may respond to the acknowledgment with a second read request that includes more specific read instructions (e.g., "seek 5,000 bits, then return the next 2,500 bits"). In essence, the prediction made in operation 106 is an attempt to predictively pre-obtain the data accessed by these more specific read instructions. If the prediction was accurate (or included a sufficient margin), the system performing method 100 may be able to return the requested bits without performing any additional downloads. Continuing with the "seek 5,000 bits, then return the next 2,500 bits" example, note that if the "local and actual locations" of the bits were tracked as part of operation 108, the system performing method 100 would not need to actually execute the instruction to "seek 5,000 bits." Instead, the system may proceed to verify that bits 5,001 through 7,500 have been downloaded and, if so, return those bits. Thus, the system can fulfill a read request without having to download the entire cloud-only file.

[0045] If the system determines that the requested bits have not been downloaded (e.g., if the prediction of operation 106 was incorrect), one of several different actions may be taken. For example, in some embodiments, the system may simply download the entire file. In some embodiments, the system may download the specifically requested bits. These and other responses to an incorrect prediction are described in further detail below (with reference to FIG. 4).

[0046] FIG. 2 illustrates a block diagram of an exemplary cloud-stored file 200 and an exemplary locally-stored file 220 after downloading identified portions 202 and 208 of the cloud-stored file 200, consistent with embodiments of the present disclosure. The cloud file 200 includes a number of bits (i.e., “0” or “1”). At a particular time, the cloud file 200 may be a cloud-only file in that there is no complete local copy of the file 200. The blocks depicted below the boundary 210 (i.e., blocks 222, 228, and 230) represent bits of the locally-stored file 220. The arrows 212 and 218 represent download operations, such as a download operation initiated by a cloud sync storage application. Although two separate arrows 212 and 218 are illustrated, it should be understood that the arrows do not necessarily represent two consecutive downloads. For example, the downloaded data referenced by the arrows 212 and 218 may be downloaded in a single download operation or multiple simultaneous download operations.

[0047] Various ranges of bits in local file 220 may contain identical data as compared to corresponding ranges of bits in cloud file 200. For example, a first range of local bits 222 may be identical to a first range of cloud bits 202 as a result of download 212, while a second range of local bits 228 may be identical to a second range of cloud bits 218 as a result of download 218. "Identical" as used herein refers to the logical state of the bits themselves, e.g., ranges 202 and 222 may both contain the same bits (e.g., both ranges may be 1000101011010010, etc.).

[0048] Not all bits of local file 220 are necessarily copied from cloud file 200; for example, local file 220 may include metadata, such as information mapping which bits of local file 220 correspond to which bits of cloud file 200. In FIG. 2, such metadata is shown as range 230. When performing a download, such as 212 or 218, metadata 230 (including mapping the local and cloud bits) may be generated (e.g., by a cloud sync storage application). Metadata 230 may be updated based on further downloads, deletions, etc.

[0049] The local file 220 may be stored on a local storage device such as a hard disk drive (HDD), a solid state drive (SSD), volatile memory, etc. Additionally, in some embodiments, the local file 220 may include additional tags and / or metadata depending on the nature of the cloud file 200 and the downloaded segments 222, 228.

[0050] For example, in at least one embodiment, the local system on which local file 222 is stored utilizes a "thumbnail database." A "thumbnail database," as used herein, refers to a typically hidden file in a directory that contains thumbnail images of the files in the directory to enable fast generation of thumbnails. If a thumbnail database does not exist in a directory on an exemplary local system, the system may generate a thumbnail database (e.g., by taking frames from video files in the directory, generating small copies of image files in the directory, etc.) and save the new thumbnail database in the directory for future use. In this example embodiment, cloud file 200 may be a video file and local bits 222 may include thumbnail images. Local file 220 may include metadata that identifies local file 220 as a standard thumbnail database. Thus, when a file explorer application running on the system attempts to access the directory, the application will find local file 220 and use local bits 222 as a thumbnail for a placeholder file representing cloud file 200. Because the local files 220 are generated outside of a read request, the cloud sync storage application can generate the thumbnail database before the file explorer application accesses the directory.

[0051] In some embodiments, local file 220 may include tags and / or metadata (e.g., in range 230) to make local file 220 appear to the user and / or file system as if it were the complete cloud file 200. Thus, when an application (that "believes" it is trying to read bits from a complete local copy of cloud file 200) requests bit ranges 202 and / or 208, the cloud sync storage application may be able to satisfy the read request without downloading the entire cloud file 200.

[0052] Depending on the nature of cloud file 200, different ranges of bits may store different data, for example, segment 202 (bits 13,000-13,511) of file 200 may store the name of the creator of file 200, segment 204 (bits 13,512-13,767) of file 200 may store the creation date of file 200, segment 206 (bits 13,768-14,023) may store the date file 200 was last modified, segment 208 (bits 14,024-14,535) may store the file name of file 200, etc. For clarity, the particular ranges of bits shown in FIG. 2 are for illustrative purposes only, and bits 13,000 through 13,511 of a different file (not shown in FIG. 2) may be used for a purpose entirely different from storing the name of the creator of that different file, or may not actually exist (i.e., the different file may contain fewer than 13,000 bits).

[0053] In some embodiments, the cloud sync storage application may determine that one or more portions (i.e., one or more bits) of the cloud file 200 may need to be downloaded to the local storage device. This may be accomplished in response to detecting a read request targeting the cloud file 200 (such as by operation 102 of method 100, as described with respect to FIG. 1). In some embodiments, the cloud sync storage application may determine that certain portions of the cloud file 200 should be downloaded even in the absence of a read request, for example, when the cloud sync storage application is installed on a new system and launched for the first time, as described in more detail below.

[0054] Local files 220 may be stored in a cloud-synced directory along with one or more placeholder files. As previously described, a placeholder file may be a locally stored file that represents a cloud-only file. The placeholder file may include minimal metadata to allow the file system to track which files are stored in the cloud (e.g., if a cloud-only file is permanently deleted or moved to a different directory, the corresponding placeholder file may also be deleted or moved, indicating to the file system accordingly that this file is no longer present in that directory).

[0055] In some embodiments, local file 220 may be a placeholder file (or may replace a placeholder file). For example, in some embodiments, the cloud sync storage application may download data from the cloud via download 212 and / or download 218 and modify an existing placeholder file to add data corresponding to ranges 202 and / or 208, respectively, to the placeholder file. In such embodiments, local file 220 is the placeholder file itself.

[0056] In some embodiments, local file 220 may be stored in a different directory (e.g., a separate directory from the cloud sync directory containing the placeholder files, such as in a compressed archive or database), but may be accessed (e.g., by the cloud sync storage application) upon detection of a read request targeted to cloud file 200. For example, the cloud sync storage application may have security privileges that allow it to monitor operations performed by the system on which it is running. Additionally, the cloud sync storage application may be able to intercept certain instructions.

[0057] For example, in some embodiments, while monitoring operations performed by the system, the cloud sync storage application may detect a read request submitted from a file explorer to the storage controller targeting cloud file 200. In response to detecting this read request, the cloud sync storage application may intercept the request and access local file 220 (even if local file 220 is stored in an entirely different location on the local drive) and respond to the read request as if it were the storage controller acknowledging ownership of cloud file 200. In response to intercepting and responding to the request, the cloud sync storage application may receive a follow-up request (a more specific request requesting the data stored in bits 202 and / or 208), at which point the cloud sync storage application may return local bits 222 and / or 228 from local file 220, respectively. Thus, the file explorer application may simply access a complete copy of file 200 and act as if the request was successfully fulfilled.

[0058] The follow-up read request may include instructions to instruct the recipient as to how to access the desired bits. For example, if a file explorer desires bits 14,024-14,535 (range 208), the follow-up read request may instruct the recipient to "seek bit 14,024 and return the following 512 bits." Based on the mapping stored in local bits 230, the cloud sync storage application may determine that desired range 208 corresponds to local range 228, and therefore may instead seek bit 512 and return the following 512 bits. In this manner, the request may be fulfilled and the requested bits may be returned without having to download an entire local copy of cloud file 200.

[0059] If the follow-up read request includes instructions indicating that the desired data is not stored in local file 220 (e.g., the follow-up read request instructs "seek 3,000 bits and return the subsequent 4,000 bits" but no local copy of the requested data exists), this may indicate that a previous prediction of the likely data to be requested was incorrect. There are several different responses to such a situation. For example, in some embodiments, the cloud sync storage application may respond by simply initiating a download of the specifically requested bits (in this example, bits 3,001 through 7,000) from cloud file 200 and returning those bits upon completion of the download (and possibly saving the newly downloaded bits in local file 220 and updating metadata 230 in case the particular data is requested again).

[0060] However, there is the possibility of multiple follow-up requests wanting additional data. While the cloud sync storage application could simply check for the requested data on a per-request basis and download it as necessary, initiating a download of data from the cloud involves a non-zero resource load. The computational cost of initiating dozens of small downloads can quickly consume more time and resources than simply downloading the entire file at one time. In addition, if a previous prediction fails to result in the currently desired data being downloaded, this may indicate that the prediction was incorrect, or misguided, or both, increasing the likelihood that additional follow-up requests will request data that is not present in the local file 220. Thus, in some embodiments, if a follow-up request requests data that is not included in the local file 220, the cloud sync storage application may respond by initiating a download of the entire cloud file 200. In some embodiments, the cloud sync storage application may update one or more definitions or parameters to represent that the previous prediction was incorrect.

[0061] 3 illustrates a method 300 for identifying an application responsible for initiating a read request consistent with embodiments of the present disclosure. Method 300 may be performed, for example, by a cloud sync storage application running on a client system. Generally, method 300 represents tracking behavior and invocation patterns of various systems over time, maintaining profiles of various applications based on these behaviors, and leveraging this information to attempt to identify applications initiating read requests (allowing for more accurate request classification / prediction of desired data).

[0062] The method 300 includes, at operation 302, monitoring system actions and requests. Operation 302 may include, for example, tracking calls (including associated data such as signature hashes, and what is returned in response to the calls). The method 300 also includes, at operation 304, maintaining and updating application profiles. This operation may include, for example, maintaining a database containing profiles of known applications and libraries. A particular profile may consist of application / library names, known file paths, known file signature hashes (e.g., message-digest (MD) 5, secure hash algorithm (SHA) 1, SHA256, etc.), exported functions (in the case of libraries), function signatures and names, and call order. Additionally, for each application and / or library, operation 304 may further include connecting a particular request from the application and / or library with a file location or portion. For example, operation 304 may include recording the application's file path, size, one or more calls / requests most frequently submitted by the application, and what portion of a particular file is being requested (e.g., "always the first 512 bytes").

[0063] The method 300 further includes, at operation 306, determining whether a read request is detected. Operation 306 may include, for example, analyzing the monitored actions to determine whether the actions include a read request. If a read request is not detected ("NO" at 306), the method 300 may continue monitoring and updating the application profile (by returning to operations 302 and 304). If a read request is detected ("YES" at 306), the method 300 further includes, at operation 308, identifying which application is responsible for the request. Note that while the request may include information labeling the application responsible for the request, this is not always the case. Furthermore, even if the request does include this information, the information may be misleading. For example, if a user of the system is using an image editing application and desires to open an image file, the image editing application may launch an embedded instance of a file explorer application to allow the user to browse for the file. If an embedded file explorer application attempts to access a file in order to generate a thumbnail for a file in a particular directory, this action will be detected as a read request for that file (YES at 306), but the request itself may include a signature indicating that the request originates from an image editing application. Act 308 may include leveraging the profile maintained at act 304 to determine that the "real" requesting application is the file explorer application (it is more likely that the file explorer application is attempting to generate a thumbnail, whereas it is more likely that the image editing application needs to open the entire file).

[0064] Operation 308 may consider highly reliable identifiers, such as checksums or signature hashes, before considering less reliable identifiers, such as file paths, sizes, or behaviors, to determine which profile is the best match (and therefore which application initiated the request). In some embodiments, operation 308 may terminate the analysis if a highly reliable match is found (e.g., a signature in the request matches a signature included in a profile).

[0065] In some embodiments, if no profile matches the request, or is within a certain threshold of similarity, operation 308 may conclude that no match was found. In some embodiments, if no match is found, the entire targeted file may be downloaded. However, in some embodiments, if no profile matches the request, operation 308 may select the "closest match" profile.

[0066] Method 300 further includes predicting and downloading portions of the file at operation 312. Operation 312 may include, for example, identifying a segment of the file that is likely needed (based on the identified profile) to satisfy the read request and downloading the segment (if a local copy does not already exist). Operation 312 may further include responding to the request to indicate that the complete file is available and ready to be read, even if only a relatively small portion of the file (i.e., the predicted portion) has been retrieved.

[0067] Note that operation 312 may include downloading one or more additional margins or additional data beyond the portion predicted to be needed. For example, even if the identified profile strongly indicates that the true target of the request is a specified range of bits, operation 312 may include downloading not only that range, but also an additional 1,024 bits before and / or after the specified range. Additionally, operation 312 may include downloading a predefined range regardless of the prediction, e.g., in some embodiments operation 312 may include downloading the first and / or last 4,096 bits of any file, even if it is not specifically expected that those bits will be needed. Doing so may consume additional resources, but in some embodiments may be deemed a worthwhile tradeoff since some portion of a file is typically required regardless of application / request.

[0068] Method 300 further includes determining whether the prediction was correct at operation 314. Operation 314 may include, for example, analyzing the follow-up read request to determine which portions of the file are actually needed and comparing the needed portions to the downloaded portions. If the prediction was correct ("YES" at 314) and the needed portions of the file were downloaded, method 300 further includes returning the requested data at operation 318.

[0069] If the prediction was incorrect ("NO" at 314) (e.g., the required portion was not downloaded), method 300 further includes downloading the portion of the file necessary to satisfy the request at operation 316. In some embodiments, operation 316 may include downloading the entire file. In some embodiments, operation 316 may include downloading only the missing portion of the file.

[0070] In some embodiments, operation 316 may include comparing the currently known required portion to the application profile and determining whether a different profile is a closer match based on this additional information, and if so, downloading the additional data indicated by the new profile may be necessary. For example, if operation 308 selected a first profile as the best match, but operation 314 revealed that this prediction was incorrect, operation 316 may include searching the profiles again and determining whether a second profile is a better match, taking into account the additional information. If a second match is found, operation 316 may further include downloading the remaining missing portion that is more likely to be needed based on the second profile. In some embodiments, operation 316 may simply include downloading the entire file.

[0071] Upon downloading the required portion of the file (either at operation 312 or at operation 316 if the prediction was incorrect), method 300 may further include returning the requested data at operation 318. Operation 318 may include returning a portion of the local file that corresponds to the requested portion of the cloud-only file, advantageously allowing the system performing method 300 to fulfill the request without downloading the entire file from the cloud.

[0072] Upon returning the requested data, method 300 may return to operation 304 and update the database of profiles based on the results of operation 314 (and, if necessary, operation 316). For example, if the initial download was successful in capturing the required data, but this success was only because the required data was included by a margin (meaning the prediction itself was still inaccurate), this information may be used to update the associated profile. In some embodiments, operation 304 may include updating various weights of the profile based on contextual information surrounding the request. If the prediction was incorrect ("No" at 314), operation 304 may include updating the selected profile (and a possible second "actually correct" profile) based on this error. In some embodiments, operation 304 may include creating a new profile based on the required portion of the file.

[0073] FIG. 4 illustrates a method 400 for predictively provisioning cloud sync files consistent with embodiments of the present disclosure. Method 400 includes, at operation 402, identifying portions of cloud files that are likely to be requested. Operation 402 may include analyzing system configuration information, such as, for example, the files stored in the cloud system, as well as the identity of various applications installed and / or running on the computing system, uptime, the identity of a user of the computing system, or the organization or entity (e.g., a business or workplace or both) that controls the computing system. In some embodiments, the system configuration information may be compared to a stored profile. Operation 402 may include leveraging this information to predict portions of one or more files that are likely to be the subject of a read request. For example, if one of the files stored in the cloud system is a video file, operation 402 may conclude that a particular frame of the video is likely to be requested to generate a thumbnail.

[0074] Operation 402 may analyze portions of a cloud file to determine a likelihood rating for some or all of the data contained in the file. In some embodiments, operation 402 may include identifying the most likely portion of the file having the greatest relative likelihood rating. In some embodiments, operation 402 may identify a portion as "likely" to be requested only if the likelihood rating exceeds a certain threshold. In some embodiments, operation 402 may include identifying the "top three" most likely portions, etc. In some embodiments, operation 402 may consider the size of some or all of the portions of the file in addition to the likelihood rating to determine whether the portion is worth downloading.

[0075] In particular, operation 402 may be performed upon intercepting or detecting a read request, or without detecting it. The system may perform operation 402, for example, when being installed on a new machine and / or device, when detecting new files being added to a newly linked cloud system or an existing cloud, when requested (e.g., by a user), while running in the background (possibly waiting during a period of relative downtime), when detecting the installation of a new application, at startup, etc.

[0076] Method 400 further includes downloading identified portions of the file not already stored locally at operation 404. Operation 404 may include, for example, checking one or more directories and / or files to determine whether portions predicted to be needed are already present in local storage and downloading some or all of the portions not found in local storage.

[0077] In some embodiments, operation 404 may include considering system settings to preclude downloading one or more of the identified portions. For example, if a video file in the cloud has a size of 5 GB, but operation 402 identifies that a particular 1 GB segment of the video is likely to be requested, downloading even a 1 GB segment may still consume significant bandwidth and storage. Thus, various settings are considered that may limit, throttle, or cap such downloads unless the file (or a segment thereof) is explicitly requested.

[0078] These portions may be saved in one or more files. In some embodiments, all identified portions may be bundled into a single "bulk" download and saved as a single file that includes metadata mapping bits (or ranges thereof) in the bulk file to corresponding bits (or ranges thereof) in the cloud file. Thus, when data is requested, the system performing operation 400 may search the bulk file (rather than checking multiple different files) and determine if the requested data has been downloaded.

[0079] Method 400 further includes intercepting and acknowledging the read request at operation 406. Operation 406 may include, for example, monitoring system operation to determine that a read request has been sent. The system performing method 400 may have permissions that allow the system to observe and intercept interactions between applications and the low-level file system. Upon detecting a read request, operation 406 may include responding with an acknowledgment (e.g., conveying to the sender of the request that the requested file is available for reading) regardless of whether the requested file is stored locally.

[0080] Method 400 further includes determining whether the requested data is stored locally at operation 408. Operation 408 may include, for example, receiving a follow-up to the acknowledged read request specifying the particular data being requested. Operation 408 may include comparing the specified data of the targeted file to the contents of one or more locally stored files (e.g., the files identified or downloaded at operation 404).

[0081] If operation 408 results in identifying the requested data in local storage ("Yes" at 408), method 400 further includes returning the requested data at operation 410, advantageously satisfying the read request with the correct data despite not downloading a local copy of the targeted file from the cloud. If the requested data is not found ("No" at 408), method 400 further includes downloading the data from the cloud at operation 412. In some embodiments, operation 412 may include downloading the entire targeted file to local storage. In some embodiments, operation 412 may include downloading only one or more portions of the targeted file (e.g., a file containing the requested data). After the requested data is obtained at operation 412, method 400 proceeds to operation 410 and returns the requested data in response to the request.

[0082] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the subject matter presented herein is not limited to a cloud computing environment. Rather, embodiments of the invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0083] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computational resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) and for rapidly provisioning and releasing these resources with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0084] The features are as follows:

[0085] On-Demand Self-Service: Cloud customers can automatically provision server time, network storage, and other computing power as they need it, without any unilateral, human interaction with the service provider.

[0086] Broad network access: Cloud capabilities are available over the network and can be accessed using standard mechanisms, facilitating usage by heterogeneous thin- or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0087] Resource Pool: The provider's computing resources are pooled and offered to multiple consumers using a multi-tenant model. Different physical and virtual resources are dynamically allocated and reallocated according to demand. There is a sense of location independence, consumers usually have no control or knowledge regarding the exact location of the resources offered, although at a higher level of abstraction they may be able to specify a location (e.g. country, state, or data center).

[0088] Rapid Elasticity: Cloud capacity can be provisioned quickly and elastically, in some cases automatically, to scale out quickly, and quickly released to scale in quickly. Capacity available for provisioning often appears to consumers as unlimited, available for purchase in any amount at any time.

[0089] Metered Services: Cloud systems leverage metering to automatically control and optimize resource usage at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services utilized.

[0090] The service model is as follows:

[0091] SaaS (Software as a Service): The capability provided to the consumer is the use of the provider's applications running on a cloud infrastructure. Those applications can be accessed from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functionality, except for the possibility of limited user-specific application configuration settings.

[0092] PaaS (Platform as a Service): The capability provided to a consumer is to deploy applications that the consumer creates or acquires, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the application hosting environment.

[0093] Infrastructure as a Service (IaaS): The capability provided to a consumer is the provisioning of processing, storage, network, and other basic computational resources over which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and in some cases, limited control over selected network components (e.g., host firewalls).

[0094] The deployment model is as follows:

[0095] Private Cloud: This cloud infrastructure is operated solely for the organization. It can be managed by the organization or a third party and can exist on-premise or off-premise.

[0096] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It can be managed by these organizations or a third party and can reside on-premise or off-premise.

[0097] Public Cloud: This cloud infrastructure is available for use by general users or large industry organizations and is owned by an organization that sells cloud services.

[0098] Hybrid cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique but are bound together by standardized or proprietary technologies that allow for the portability of data and applications (e.g., cloud bursting to balance the load between clouds).

[0099] A cloud computing environment is a service-oriented environment with an emphasis on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that contains a network of interconnected nodes.

[0100] Referring now to FIG. 5, an exemplary cloud computing environment 500 is illustrated. As illustrated, the cloud computing environment 500 includes one or more cloud computing nodes 510 with which local computing devices used by cloud consumers (e.g., personal digital assistant (PDA) or mobile phone 540A, desktop computer 540B, laptop computer 540C, and / or automobile computer system 540N) may communicate. The nodes 510 may communicate with each other. The nodes 510 may be physically or virtually grouped in one or more networks (not shown), such as a private cloud, community cloud, public cloud, or hybrid cloud, or combination thereof, as previously described herein. This allows the cloud computing environment 500 to provide an infrastructure, platform, and / or SaaS that does not require the cloud consumer to maintain resources on a local computing device. The types of computing devices 544A-N illustrated in FIG. 5 are intended as examples only, and it will be understood that the computing node 510 and cloud computing environment 500 may communicate with any type of computer-controlled device via any type of network and / or network-addressable connection (e.g., a connection using a web browser).

[0101] Referring now to Figure 6, a set of functional abstraction layers provided by cloud computing environment 500 (Figure 5) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 6 are intended to be illustrative only and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0102] Hardware and software layer 660 includes hardware and software components. Examples of hardware components include mainframe 661, Reduced Instruction Set Computer (RISC) architecture based servers 662, servers 663, blade servers 664, storage devices 665, and networks and network components 666. In some embodiments, software components include network application server software 667 and database software 668.

[0103] The virtualization layer 670 provides an abstraction layer that can provide virtual entities such as virtual servers 671 , virtual storage 672 , virtual networks including virtual private networks 673 , virtual applications and operating systems 674 , and virtual clients 675 .

[0104] As an example, the management layer 680 may provide the following functions: Resource provisioning 681 dynamically procures computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 682 tracks costs as resources are utilized within the cloud computing environment and sends bills or invoices for the utilization of those resources. As an example, those resources may include application software licenses. Security verifies identity of cloud users and tasks, and protects data and other resources. User portal 683 provides access to the cloud computing environment to users and system administrators. Service level management 684 allocates and manages cloud computing resources to meet required service levels. Service level agreement (SLA) planning and execution 685 pre-provisions and procures cloud computing resources in anticipation of upcoming demands and in accordance with SLAs.

[0105] The Workload Layer 690 illustrates examples of functionality available in a cloud computing environment. Examples of workloads and functionality provided by this layer include mapping and navigation 691, software development and lifecycle management 692, virtual classroom instruction delivery 693, data analytics processing 694, transaction processing 695, and predictive provisioning of files stored in the cloud 696.

[0106] 7, there is shown a high level block diagram of an exemplary computer system 700 configured to perform various aspects of the present disclosure including, for example, methods 100, 300, and 400, respectively. The exemplary computer system 700 may be used in implementing one or more of the methods or modules described herein and any associated functions or operations (e.g., using one or more processor circuits or computer processors of a computer) in accordance with embodiments of the present disclosure. In some embodiments, the main components of the computer system 700 may include one or more CPUs 702, a memory subsystem 708, a terminal interface 716, a storage interface 718, an I / O (Input / Output) device interface 720, and a network interface 722, all of which may be communicatively coupled, directly or indirectly, for communication between the components via a memory bus 706, an I / O bus 714, and an I / O bus interface unit 712.

[0107] Computer system 700 may include one or more programmable general purpose central processing units (CPUs) 702, some or all of which may include one or more cores 704A, 704B, 704C, and 704D, collectively referred to herein as CPUs 702. In some embodiments, computer system 700 may include multiple processors, as is typical for larger systems, while in other embodiments computer system 700 may alternatively be a single CPU system. Each CPU 702 may execute instructions stored in a memory subsystem 708 on the CPU cores 704, and may include one or more levels of on-board cache.

[0108] In some embodiments, memory subsystem 708 may include random access semiconductor memory, storage devices, or storage media (either volatile or non-volatile) for storing data and programs. In some embodiments, memory subsystem 708 may represent the entire virtual memory of computer system 700 and may include virtual memory of other computer systems coupled to computer system 700 or connected over a network. While memory subsystem 708 may conceptually be a single monolithic entity, in some embodiments memory subsystem 708 may be a more complex configuration, such as a hierarchy of caches and other memory devices. For example, memory may exist in multiple levels of caches, which may be further divided by function, such that some caches hold instructions while other caches hold non-instruction data used by one or more processors. Memory may be further distributed and associated with different CPUs or sets of CPUs, as known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures. In some embodiments, main memory or memory subsystem 804 may include elements for control and flow of memory used by CPU 702. This elements may include memory controller 710.

[0109] 7, memory bus 706 is depicted as a single bus structure providing a direct communication path between CPU 702, memory subsystem 708, and I / O bus interface 712, memory bus 706 may in some embodiments include multiple different buses or communication paths, which may be arranged in any of a variety of configurations, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, redundant parallel paths, or any other suitable type of configuration. Additionally, while I / O bus interface 712 and I / O bus 714 are each depicted as single units, computer system 700 may in some embodiments include multiple I / O bus interface units 712, multiple I / O buses 714, or both. Additionally, while multiple I / O interface units are depicted separating I / O bus 714 from the various communication paths reaching the various I / O devices, in other embodiments some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0110] In some embodiments, computer system 700 may be a multi-user mainframe computer system, a single-user system, or a server computer, or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 700 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a mobile device, or any other suitable type of electronic device.

[0111] It is noted that Figure 7 is intended to illustrate major representative components of an exemplary computer system 700. However, in some embodiments, individual components may have greater or less complexity than those depicted in Figure 7, there may be other or additional components than those depicted in Figure 7, and the number, type, and configuration of such components may vary.

[0112] The present invention may be a system, method, and / or computer program product at any possible level of technical detail of integration. The computer program product may include a computer readable storage medium including computer readable program instructions for causing a processor to perform aspects of the present invention.

[0113] A computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridges in a groove on which instructions are recorded, and any suitable combinations of these. As used herein, computer-readable storage media should not itself be construed as being ephemeral signals such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0114] The computer readable program instructions described herein can be downloaded from a computer readable storage medium to each computing device / processing device or to an external computer or storage device over a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof) that may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing device / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage on a computer readable storage medium within each computing device / processing device.

[0115] The computer readable program instructions for carrying out the operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the invention, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer readable program instructions to customize the electronic circuitry by utilizing state information of the computer readable program instructions.

[0116] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks included in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0117] These computer readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / operations specified in the blocks of the flowcharts and / or block diagrams. These computer readable program instructions may be stored on a computer readable storage medium and capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer readable storage medium on which the instructions are stored comprises an article of manufacture including instructions for performing aspects of the functions / operations specified in the blocks of the flowcharts and / or block diagrams.

[0118] The computer readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operable steps to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in the flowchart and / or block diagram blocks.

[0119] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions shown in the blocks may occur in a different order than the order shown in the figures. For example, two blocks shown in succession may in fact be executed simultaneously as one step, or executed substantially simultaneously in a partially or fully overlapping manner in time, or executed in reverse order as the case may be, depending on the functionality involved. It is also noted that each block in the block diagrams and / or flowchart diagrams, as well as combinations of blocks included in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that executes the specified functions or operations, or executes a combination of dedicated hardware and computer instructions.

[0120] The description of various embodiments of the present disclosure is presented for illustrative purposes, but is not intended to be exhaustive and is not limited to the disclosed embodiments. Many changes and modifications that do not depart from the scope and spirit of the described embodiments will be apparent to those skilled in the art. The terms used in this specification are selected to explain the principles of the embodiments, practical applications, or technical improvements beyond the technology found in the market, or to allow other skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for information processing by a computer having a memory and a central processing unit (CPU), the method comprising: Identifying a remote file stored on a remote computing system; predicting that a predicted portion of the remote file is likely to be the subject of a future read request; downloading the predicted portion of the remote file to a local file; updating metadata of the local file to map local portions of the local file to the predicted portions of the remote file; receiving a first read request; the identifying is based at least on a target of the first read request; the predicting is based at least on the first read request; and and determining a requesting application that initiated the first read request based at least on an application profile database, wherein the predicting further comprises based at least on the requesting application.

2. receiving a second read request targeting the targeted portion of the remote file; and updating the application profile database based at least on the predicted portion and the targeted portion.

3. receiving a second read request targeting the targeted portion of the remote file; determining that the predicted portion of the remote file includes the targeted portion; 2. The method of claim 1, further comprising: in response to determining that the predicted portion includes the targeted portion, returning at least a portion of the local portion that is mapped to the predicted portion based on the metadata.

4. receiving a second read request targeting the targeted portion of the remote file; determining that the predicted portion of the remote file does not include the targeted portion; 2. The method of claim 1, further comprising: in response to determining that the predicted portion of the remote file does not include the targeted portion, downloading at least a second portion of the remote file that includes the targeted portion.

5. The method of claim 1 , further comprising monitoring read operations of a computing system, and wherein said prediction is based at least on said monitoring.

6. The method of claim 1 , wherein the prediction is based at least on system configuration information.

7. the remote computing system is a cloud computing system; The method of claim 1 , wherein the remote file is a cloud file.

8. 1. A system comprising: Memory, a central processing unit (CPU) including one or more CPU cores, said CPU comprising: Identifying a remote file stored on a remote computing system; predicting that a predicted portion of the remote file is likely to be the subject of a future read request; downloading the predicted portion of the remote file to a local file; updating metadata of the local file to map local portions of the local file to the predicted portions of the remote file; the CPU is configured to receive a first read request; the identifying is based at least on a target of the first read request; the predicting is based at least on the first read request; and The system, wherein the CPU is further configured to determine a requesting application that initiated the first read request based at least on an application profile database, and wherein the predicting is further configured to be based at least on the requesting application.

9. The CPU, receiving a second read request targeting the targeted portion of the remote file; and updating the application profile database based at least on the predicted portion and the targeted portion.

10. The CPU, receiving a second read request targeting the targeted portion of the remote file; determining that the predicted portion of the remote file includes the targeted portion; 10. The system of claim 8, further configured to: in response to determining that the predicted portion includes the targeted portion, return at least a portion of the local portion that is mapped to the predicted portion based on the metadata.

11. The CPU, receiving a second read request targeting the targeted portion of the remote file; determining that the predicted portion of the remote file does not include the targeted portion; 10. The system of claim 8, further configured to: in response to determining that the predicted portion of the remote file does not include the targeted portion, download at least a second portion of the remote file that includes the targeted portion.

12. 12. The system of claim 8, wherein the CPU is further configured to monitor read operations of the system, and wherein the prediction is based at least on said monitoring.

13. the remote computing system is a cloud computing system; The system of claim 8 , wherein the remote file is a cloud file.

14. A computer program product for causing a computer to carry out a method according to any one of claims 1 to 7.

15. 15. A computer readable storage medium having stored thereon the computer program of claim 14.

Images