DETAILED ACTION
This Office action is in response to Applicant’s reply filed 05/27/2026.
Claims 1-20 are pending. Independent claims 1, 10, and 19 have been amended.
Claims 1-20 are rejected.
Notice of AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/08/2026 was filed after the mailing date of the non-final Office Action on 03/11/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 10 and 19 are objected to for reciting “generating, on the a system,” and should likely recite “generating, on a file system,” to bring them in line with claims such as claim 1 reciting “generating, on the file system” (having introduced it in its preamble).
Appropriate correction is required.
Response to Arguments
35 U.S.C. 101
Applicant's arguments filed 05/27/2026 have been fully considered but they are not persuasive.
The Examiner appreciates the intention to amend the claims to recite “non-transitory”; however, as filed, the claims do not appear to have been amended to add the recitation. Appropriate correction may be required.
35 U.S.C. 103
Applicant’s arguments, see pp8-9, filed 05/27/2026, with respect to the rejection(s) of claim(s) 1, 10, and 19 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made under 35 U.S.C. 103.
Statutory Review under 35 USC § 101
Claims 1-9 are directed towards a method and have been reviewed.
Claims 1-9 appear to remain directed to patent-eligible subject matter as they perform an abstract idea (including at least generating a mapping) integrated into a practical application as per Step 2A, Prong Two of the patent subject matter eligibility determination.
Claims 10-18 are directed toward a system and have been reviewed.
Claims 10-18 initially appear to remain statutory, as the system includes hardware (one or more processors) as disclosed in ¶ 0062 of the applicant’s specification.
Claims 10-18 also appear to remain statutory as they perform an abstract idea (including at least generating a mapping) integrated into a practical application as per Step 2A, Prong Two of the patent subject matter eligibility determination.
Claims 19-20 are directed toward an article of manufacture and have been reviewed.
Claims 19-20 appear to remain non-statutory, as the article of manufacture can be interpreted to include non-statutory subject matter (i.e., transitory propagating signals).
Claims 19-20 would otherwise be statutory as they perform an abstract idea (including at least generating a mapping) integrated into a practical application as per Step 2A, Prong Two of the patent subject matter eligibility determination.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 19-20 remain rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The term utilized can be interpreted to include transitory signals.
Official Gazette Notice 1351 OG 212, dated February 23, 2010, states "the broadest reasonable interpretation of a claim drawn to a computer readable medium...typically covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of computer readable media."
"A transitory, propagating signal ... is not a 'process, machine, manufacture, or composition of matter.' Those four categories define the explicit scope and reach of subject matter patentable under 35 U.S.C. § 101; thus, such a signal cannot be patentable subject matter." In re Nuijten, 84 USPQ2d 1495, 1503 (Fed. Cir. 2007).
Because the full scope of the claim encompasses non-statutory subject matter (i.e., transitory propagating signals), the claim as a whole is non-statutory. The Examiner suggests adding the limitation "non-transitory" to the claims in question to limit the claim scope to encompass only statutory subject matter. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-9; 10-15, 17-18; and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Nichols et al., U.S. Patent Application Publication No. 2018/0084045 (shares assignee with instant application; published March 22, 2018; hereinafter Nichols) in view of Anderson et al., U.S. Patent Application Publication No. 2004/0024786 (hereinafter Anderson) in further view of Kumar et al., U.S. Patent Application Publication No. 2020/0387483 (hereinafter Kumar).
Regarding claim 1, Nichols teaches:
A computer-implemented method for implementing temporary file directories in a file system for managing data in a distributed computing system, the method comprising: (Nichols ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage ... To kernel-space or user-space, the VFS presents an interface that deals in terms of paths and file handles)
receiving information indicating one or more files that are associated with a context indicative of a user's computing activity in the distributed computing system; (Nichols ¶ 0032: In addition to determining when dehydration is needed, a system according to embodiments may also determine which data (e.g., files or folders) to dehydrate. Default, customizable, or dynamic rules for selecting data to dehydrate may be based on relevance to the user, usage history, size, time of hydration, and similar factors; see also Nichols FIG. 4, ¶ 0040: Algorithms may be used to determine a need for dehydration based on user or administrator defined limits (402) or heuristic determination (404). Based on the policies defining how to determine the need for dehydration (408), a detection may be based on a limit (e.g., amount of hydrated files, amount of total data, etc.) being approached or exceeded, files and/or folders may be selected for dehydration (406) based on one or more criteria)
based on the information, generating, on the file system, a temporary placeholder folder and placeholder files corresponding to the one or more files, (Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated)
…
the placeholder files are selected based on a threshold relevance to the context indicative of the user's computing activity, (Nichols FIG. 4, ¶ 0040-0042: with a detection mechanism and policy in place, one or more algorithms may be executed when the detection threshold is reached. In some examples, which files to dehydrate may be decided based on a last access time of a file, a number of times the file is opened by the user, a size of the file, a type of the file (some file types may be less frequently modified, or some may be excluded entirely, for example), a relevance or service ranking for the file, and similar parameters)
and the temporary placeholder folder and placeholder files are abstracted from … underlying storage locations … of the distributed computing system; (Nichols FIG. 3, ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage. VFS is designed to abstract the details of how files are accessed and stored from the rest of the system)
generating a mapping of the placeholder files to the underlying storage locations represented by the placeholder files; (Nichols ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage; see also Nichols ¶ 0079: a physical computer-readable memory device with instructions stored thereon to provide symbolic link based placeholders for cloud stored data synchronization is described ... dehydrating the one or more files by replacing the one or more files with placeholders indicating corresponding one or more files in a cloud storage and removing the one or more files in the local storage)
rendering the temporary placeholder folder and placeholder files on a user interface indicating the placeholder folder and placeholder files as folders and files within the file system, (Nichols FIG. 2, ¶ 0028: Placeholders may allow users to see the entire content of their cloud storage on their local disk. Some files, called placeholders, are metadata-only representations of their cloud stored counterpart; Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated [shows this can include temporary placeholder folders])
wherein the placeholder files are dehydrated in the temporary placeholder folder; (Nichols ¶ 0014: the synchronization and local, content dehydration may be performed on a per-folder basis. For example, a camera roll folder may be associated with a policy such that new photos are immediately uploaded and dehydrated, and stored only in the cloud; see also Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated)
based on the mapping, retrieving one of the placeholder files from a corresponding underlying storage location when selected via the temporary placeholder folder on the user interface; and (Nichols FIG. 2, ¶ 0028-0029: Placeholders may allow users to see the entire content of their cloud storage on their local disk. Some files, called placeholders, are metadata-only representations of their cloud stored counterpart When the user accesses, reads, or copies the file, the content is downloaded to the local disk “just in time” [relevant to retrieval] ... content 204 in cloud storage 202 such as files, folders [shows temporary placeholder folder], and other forms of data may be synchronized selectively to content 210 at local storage. In a system that uses placeholders, the synchronization may involve hydration 206, where selected placeholder files may be replaced with downloaded content [relevant to retrieval]; see also Nichols ¶ 0036-0037: This may provide the means to intercept file open, read, and write requests, hand then off to the synchronization engine, allow the synchronization engine to download the file [relevant to retrieval], and fulfill the original open, read, or write request... The user may activate a “.placeholder” file, the hydration application may open and hydrate the file [relevant to retrieval], and then launch the default application associated with the newly hydrated file; see also Nichols ¶ 0049: Such an algorithm may be designed to address a photo preview situation, where the user may browse to multiple files quickly within the same folder [also shows temporary placeholder folder]. The algorithm may also try to hydrate at least a minimum number of bytes, and may optionally hydrate files up to the target [relevant to retrieval])
based on the mapping, synchronizing changes to the retrieved file with an underlying storage location represented by the retrieved file. (Nichols ¶ 0014: the synchronization and local, content dehydration may be performed on a per-folder basis. For example, a camera roll folder may be associated with a policy such that new photos are immediately uploaded and dehydrated, and stored only in the cloud; see this being based on the mapping in at least Nichols ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage)
Nichols does not expressly disclose:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity,
and the … placeholder files are abstracted from and independent of underlying storage locations and a file system hierarchy of the distributed computing system;
However, Anderson teaches:
and the … placeholder files are abstracted from and independent of underlying storage locations and a file system hierarchy of the distributed computing system; (Anderson ¶ 0055-0057: This allows the referred-to file system to be replicated or moved without requiring updates to referring (i.e., referencing) file systems. These location-independent referrals are designed for use with file access protocols that support referrals, such as NFSv4... The present invention allows these two types of information (i.e., information used for name space construction and information used to determine a file system's location) to be decoupled, leveraging referral objects that reside in the file system; Anderson ¶ 0089: By leveraging referral objects, implementations of the present invention provide location-independent and client-independent views of a uniform name space)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file/folder hydration/dehydration of Nichols with the referral objects of Anderson.
In addition, both of the references (Nichols and Anderson) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file folder management.
Motivation to do so would be to improve the functioning of Nichols performing placeholder file operations with the ability in similar reference Anderson performing referral file operations but with the improvement of metadata automation.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to locate content in a nearly seamless and transparent manner as seen in Anderson (¶ 0028, ¶ 0039).
Nichols in view of Anderson does not expressly disclose:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity,
However, Kumar teaches:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity, (Kumar ¶ 0024: Categorization system 20 can generate (i.e., create, arrange and name) virtual folders using any technique … virtual folders can be generated automatically, e.g., using a machine learning tool. For example, machine learning can analyze data such as tagging information assigned to files, past search queries, usage patterns, file access history, tag usage, etc. ... files can grouped into virtual subfolders based on a criteria, such as recently accessed, recommended (determined using a Recommendation Algorithm), date/time (e.g., files saved last week, last month etc.). Using machine learning, the presentation space, i.e., layout, hierarchy (e.g., subfolder tree structure), and names of virtual folders can be regenerated periodically (e.g., once a day, once a week, etc.), or be generated dynamically on the fly (e.g., anytime a user views a virtual folder))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file/folder hydration/dehydration of Nichols with the folder management of Kumar.
In addition, both of the references (Nichols and Kumar) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file folder management.
Motivation to do so would be to improve the functioning of Nichols performing operations over folders with the ability in similar reference Kumar also performing operations over folders but with the improvement of machine learning techniques.
Regarding claim 10, Nichols teaches:
A device comprising: one or more processors; a memory in communication with the one or more processors, the memory having computer-readable instructions stored thereupon which, when executed by the one or more processors, cause the device to: (Nichols ¶ 0018: The computer program product may be a computer storage medium readable by a computer system and encoding a computer program that comprises instructions for causing a computer or computing system to perform example processes))
receive information indicating one or more files that are associated with a context indicative of a user's computing activity in the distributed computing system; (Nichols ¶ 0032: In addition to determining when dehydration is needed, a system according to embodiments may also determine which data (e.g., files or folders) to dehydrate. Default, customizable, or dynamic rules for selecting data to dehydrate may be based on relevance to the user, usage history, size, time of hydration, and similar factors; see also Nichols FIG. 4, ¶ 0040: Algorithms may be used to determine a need for dehydration based on user or administrator defined limits (402) or heuristic determination (404). Based on the policies defining how to determine the need for dehydration (408), a detection may be based on a limit (e.g., amount of hydrated files, amount of total data, etc.) being approached or exceeded, files and/or folders may be selected for dehydration (406) based on one or more criteria)
based on the information, generating, on the a system, a temporary placeholder folder and placeholder files corresponding to the one or more files, (Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated)
…
the placeholder files are selected based on a threshold relevance to the context indicative of the user's computing activity, (Nichols FIG. 4, ¶ 0040-0042: with a detection mechanism and policy in place, one or more algorithms may be executed when the detection threshold is reached. In some examples, which files to dehydrate may be decided based on a last access time of a file, a number of times the file is opened by the user, a size of the file, a type of the file (some file types may be less frequently modified, or some may be excluded entirely, for example), a relevance or service ranking for the file, and similar parameters)
and the temporary placeholder folder and placeholder files are abstracted from … underlying storage locations … of the distributed computing system; (Nichols FIG. 3, ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage. VFS is designed to abstract the details of how files are accessed and stored from the rest of the system)
generating a mapping of the placeholder files to the underlying storage locations represented by the placeholder files; (Nichols ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage; see also Nichols ¶ 0079: a physical computer-readable memory device with instructions stored thereon to provide symbolic link based placeholders for cloud stored data synchronization is described ... dehydrating the one or more files by replacing the one or more files with placeholders indicating corresponding one or more files in a cloud storage and removing the one or more files in the local storage)
rendering the temporary placeholder folder and placeholder files on a user interface indicating the placeholder folder and placeholder files as folders and files within the file system, (Nichols FIG. 2, ¶ 0028: Placeholders may allow users to see the entire content of their cloud storage on their local disk. Some files, called placeholders, are metadata-only representations of their cloud stored counterpart; Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated [shows this can include temporary placeholder folders])
wherein the placeholder files are dehydrated in the temporary placeholder folder; (Nichols ¶ 0014: the synchronization and local, content dehydration may be performed on a per-folder basis. For example, a camera roll folder may be associated with a policy such that new photos are immediately uploaded and dehydrated, and stored only in the cloud; see also Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated)
based on the mapping, retrieving one of the placeholder files from a corresponding underlying storage location when selected via the temporary placeholder folder on the user interface; and (Nichols FIG. 2, ¶ 0028-0029: Placeholders may allow users to see the entire content of their cloud storage on their local disk. Some files, called placeholders, are metadata-only representations of their cloud stored counterpart When the user accesses, reads, or copies the file, the content is downloaded to the local disk “just in time” [relevant to retrieval] ... content 204 in cloud storage 202 such as files, folders [shows temporary placeholder folder], and other forms of data may be synchronized selectively to content 210 at local storage. In a system that uses placeholders, the synchronization may involve hydration 206, where selected placeholder files may be replaced with downloaded content [relevant to retrieval]; see also Nichols ¶ 0036-0037: This may provide the means to intercept file open, read, and write requests, hand then off to the synchronization engine, allow the synchronization engine to download the file [relevant to retrieval], and fulfill the original open, read, or write request... The user may activate a “.placeholder” file, the hydration application may open and hydrate the file [relevant to retrieval], and then launch the default application associated with the newly hydrated file; see also Nichols ¶ 0049: Such an algorithm may be designed to address a photo preview situation, where the user may browse to multiple files quickly within the same folder [also shows temporary placeholder folder]. The algorithm may also try to hydrate at least a minimum number of bytes, and may optionally hydrate files up to the target [relevant to retrieval])
based on the mapping, synchronizing changes to the retrieved file with an underlying storage location represented by the retrieved file. (Nichols ¶ 0014: the synchronization and local, content dehydration may be performed on a per-folder basis. For example, a camera roll folder may be associated with a policy such that new photos are immediately uploaded and dehydrated, and stored only in the cloud; see this being based on the mapping in at least Nichols ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage)
Nichols does not expressly disclose:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity,
and the … placeholder files are abstracted from and independent of underlying storage locations and a file system hierarchy of the distributed computing system;
However, Anderson teaches:
and the … placeholder files are abstracted from and independent of underlying storage locations and a file system hierarchy of the distributed computing system; (Anderson ¶ 0055-0057: This allows the referred-to file system to be replicated or moved without requiring updates to referring (i.e., referencing) file systems. These location-independent referrals are designed for use with file access protocols that support referrals, such as NFSv4... The present invention allows these two types of information (i.e., information used for name space construction and information used to determine a file system's location) to be decoupled, leveraging referral objects that reside in the file system; Anderson ¶ 0089: By leveraging referral objects, implementations of the present invention provide location-independent and client-independent views of a uniform name space)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file/folder hydration/dehydration of Nichols with the referral objects of Anderson.
In addition, both of the references (Nichols and Anderson) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file folder management.
Motivation to do so would be to improve the functioning of Nichols performing placeholder file operations with the ability in similar reference Anderson performing referral file operations but with the improvement of metadata automation.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to locate content in a nearly seamless and transparent manner as seen in Anderson (¶ 0028, ¶ 0039).
Nichols in view of Anderson does not expressly disclose:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity,
However, Kumar teaches:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity, (Kumar ¶ 0024: Categorization system 20 can generate (i.e., create, arrange and name) virtual folders using any technique … virtual folders can be generated automatically, e.g., using a machine learning tool. For example, machine learning can analyze data such as tagging information assigned to files, past search queries, usage patterns, file access history, tag usage, etc. ... files can grouped into virtual subfolders based on a criteria, such as recently accessed, recommended (determined using a Recommendation Algorithm), date/time (e.g., files saved last week, last month etc.). Using machine learning, the presentation space, i.e., layout, hierarchy (e.g., subfolder tree structure), and names of virtual folders can be regenerated periodically (e.g., once a day, once a week, etc.), or be generated dynamically on the fly (e.g., anytime a user views a virtual folder))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file/folder hydration/dehydration of Nichols with the folder management of Kumar.
In addition, both of the references (Nichols and Kumar) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file folder management.
Motivation to do so would be to improve the functioning of Nichols performing operations over folders with the ability in similar reference Kumar also performing operations over folders but with the improvement of machine learning techniques.
Regarding claim 19, Nichols teaches:
A computer-readable storage medium comprising instructions that, when executed by a computing device, cause the computing device to perform operations comprising: (Nichols ¶ 0018: Some embodiments may be implemented as a computer-implemented process (method), a computing system, or as an article of manufacture, such as a computer program product or computer readable media. The computer program product may be a computer storage medium readable by a computer system and encoding a computer program that comprises instructions for causing a computer or computing system to perform example processes))
receive information indicating one or more files that are associated with a context indicative of a user's computing activity in the distributed computing system; (Nichols ¶ 0032: In addition to determining when dehydration is needed, a system according to embodiments may also determine which data (e.g., files or folders) to dehydrate. Default, customizable, or dynamic rules for selecting data to dehydrate may be based on relevance to the user, usage history, size, time of hydration, and similar factors; see also Nichols FIG. 4, ¶ 0040: Algorithms may be used to determine a need for dehydration based on user or administrator defined limits (402) or heuristic determination (404). Based on the policies defining how to determine the need for dehydration (408), a detection may be based on a limit (e.g., amount of hydrated files, amount of total data, etc.) being approached or exceeded, files and/or folders may be selected for dehydration (406) based on one or more criteria)
based on the information, generating, on the a system, a temporary placeholder folder and placeholder files corresponding to the one or more files, (Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated)
…
the placeholder files are selected based on a threshold relevance to the context indicative of the user's computing activity, (Nichols FIG. 4, ¶ 0040-0042: with a detection mechanism and policy in place, one or more algorithms may be executed when the detection threshold is reached. In some examples, which files to dehydrate may be decided based on a last access time of a file, a number of times the file is opened by the user, a size of the file, a type of the file (some file types may be less frequently modified, or some may be excluded entirely, for example), a relevance or service ranking for the file, and similar parameters)
and the temporary placeholder folder and placeholder files are abstracted from … underlying storage locations … of the distributed computing system; (Nichols FIG. 3, ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage. VFS is designed to abstract the details of how files are accessed and stored from the rest of the system)
generating a mapping of the placeholder files to the underlying storage locations represented by the placeholder files; (Nichols ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage; see also Nichols ¶ 0079: a physical computer-readable memory device with instructions stored thereon to provide symbolic link based placeholders for cloud stored data synchronization is described ... dehydrating the one or more files by replacing the one or more files with placeholders indicating corresponding one or more files in a cloud storage and removing the one or more files in the local storage)
rendering the temporary placeholder folder and placeholder files on a user interface indicating the placeholder folder and placeholder files as folders and files within the file system, (Nichols FIG. 2, ¶ 0028: Placeholders may allow users to see the entire content of their cloud storage on their local disk. Some files, called placeholders, are metadata-only representations of their cloud stored counterpart; Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated [shows this can include temporary placeholder folders])
wherein the placeholder files are dehydrated in the temporary placeholder folder; (Nichols ¶ 0014: the synchronization and local, content dehydration may be performed on a per-folder basis. For example, a camera roll folder may be associated with a policy such that new photos are immediately uploaded and dehydrated, and stored only in the cloud; see also Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated)
based on the mapping, retrieving one of the placeholder files from a corresponding underlying storage location when selected via the temporary placeholder folder on the user interface; and (Nichols FIG. 2, ¶ 0028-0029: Placeholders may allow users to see the entire content of their cloud storage on their local disk. Some files, called placeholders, are metadata-only representations of their cloud stored counterpart When the user accesses, reads, or copies the file, the content is downloaded to the local disk “just in time” [relevant to retrieval] ... content 204 in cloud storage 202 such as files, folders [shows temporary placeholder folder], and other forms of data may be synchronized selectively to content 210 at local storage. In a system that uses placeholders, the synchronization may involve hydration 206, where selected placeholder files may be replaced with downloaded content [relevant to retrieval]; see also Nichols ¶ 0036-0037: This may provide the means to intercept file open, read, and write requests, hand then off to the synchronization engine, allow the synchronization engine to download the file [relevant to retrieval], and fulfill the original open, read, or write request... The user may activate a “.placeholder” file, the hydration application may open and hydrate the file [relevant to retrieval], and then launch the default application associated with the newly hydrated file; see also Nichols ¶ 0049: Such an algorithm may be designed to address a photo preview situation, where the user may browse to multiple files quickly within the same folder [also shows temporary placeholder folder]. The algorithm may also try to hydrate at least a minimum number of bytes, and may optionally hydrate files up to the target [relevant to retrieval])
based on the mapping, synchronizing changes to the retrieved file with an underlying storage location represented by the retrieved file. (Nichols ¶ 0014: the synchronization and local, content dehydration may be performed on a per-folder basis. For example, a camera roll folder may be associated with a policy such that new photos are immediately uploaded and dehydrated, and stored only in the cloud; see this being based on the mapping in at least Nichols ¶ 0037: bidirectional links may be used in conjunction with the synchronization engine 312 and hydration daemon 314 to allow synchronization of files represented by placeholders at the local storage)
Nichols does not expressly disclose:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity,
and the … placeholder files are abstracted from and independent of underlying storage locations and a file system hierarchy of the distributed computing system;
However, Anderson teaches:
and the … placeholder files are abstracted from and independent of underlying storage locations and a file system hierarchy of the distributed computing system; (Anderson ¶ 0055-0057: This allows the referred-to file system to be replicated or moved without requiring updates to referring (i.e., referencing) file systems. These location-independent referrals are designed for use with file access protocols that support referrals, such as NFSv4... The present invention allows these two types of information (i.e., information used for name space construction and information used to determine a file system's location) to be decoupled, leveraging referral objects that reside in the file system; Anderson ¶ 0089: By leveraging referral objects, implementations of the present invention provide location-independent and client-independent views of a uniform name space)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file/folder hydration/dehydration of Nichols with the referral objects of Anderson.
In addition, both of the references (Nichols and Anderson) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file folder management.
Motivation to do so would be to improve the functioning of Nichols performing placeholder file operations with the ability in similar reference Anderson performing referral file operations but with the improvement of metadata automation.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to locate content in a nearly seamless and transparent manner as seen in Anderson (¶ 0028, ¶ 0039).
Nichols in view of Anderson does not expressly disclose:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity,
However, Kumar teaches:
wherein a characteristic of the temporary placeholder folder is indicative of the context indicative of the user's computing activity, (Kumar ¶ 0024: Categorization system 20 can generate (i.e., create, arrange and name) virtual folders using any technique … virtual folders can be generated automatically, e.g., using a machine learning tool. For example, machine learning can analyze data such as tagging information assigned to files, past search queries, usage patterns, file access history, tag usage, etc. ... files can grouped into virtual subfolders based on a criteria, such as recently accessed, recommended (determined using a Recommendation Algorithm), date/time (e.g., files saved last week, last month etc.). Using machine learning, the presentation space, i.e., layout, hierarchy (e.g., subfolder tree structure), and names of virtual folders can be regenerated periodically (e.g., once a day, once a week, etc.), or be generated dynamically on the fly (e.g., anytime a user views a virtual folder))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file/folder hydration/dehydration of Nichols with the folder management of Kumar.
In addition, both of the references (Nichols and Kumar) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file folder management.
Motivation to do so would be to improve the functioning of Nichols performing operations over folders with the ability in similar reference Kumar also performing operations over folders but with the improvement of machine learning techniques.
Regarding claims 2 and 11, Nichols in view of Anderson and Kumar teaches all the features with respect to claims 1 and 10 above respectively including being “…configured to intercept requests to access the placeholder files that requires a hydration of a selected placeholder file; and hydrating the selected placeholder file from its corresponding underlying location.” (Nichols ¶ 0036-0037: allow third parties to inject code between the file system and the user mode file system APIs. This may provide the means to intercept file open, read, and write requests, hand then off to the synchronization engine, allow the synchronization engine to download the file, and fulfill the original open, read, or write request ... The user may activate a “.placeholder” file, the hydration application may open and hydrate the file and then launch the default application associated with the newly hydrated file; see also Nichols FIG. 2, ¶ 0028-0029: In a system that uses placeholders, the synchronization may involve hydration 206, where selected placeholder files may be replaced with downloaded content)
Nichols also teaches running a filter configured to … access the … files… (Nichols ¶ 0043-0044: Dehydration determining algorithms may receive as input a list of files eligible for dehydration. This list may be an entire set of files in the user's scope, but may be filtered based on rules and other factors)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the request management of Nichols as modified with the rules of this embodiment of Nichols.
Motivation to do so would be to improve the functioning of Nichols as modified fielding file/folder requests with the ability in this embodiment of Nichols to also field file requests but with the improvement of rule filtering.
Regarding claims 3 and 12, Nichols in view of Anderson and Kumar teaches all the features with respect to claims 2 and 11 above respectively including:
wherein the filter is configured to synchronize placeholder files with its corresponding underlying files. (Nichols ¶ 0014: synchronization and/or dehydration actions may be performed automatically based on default and/or customizable rules (policies), user input, or a combination of both; Nichols FIG. 5, ¶ 0051: policies and rules 506 may control a synchronization and/or dehydration process 512 executed by a synchronization engine 510)
Regarding claims 4 and 13, Nichols in view of Anderson and Kumar teaches all the features with respect to claims 1 and 10 above respectively including:
wherein the information is received via an API. (Nichols FIG. 3, ¶ 0036: a typical stack may include applications 302, user mode file system application programming interfaces (APIs) 304, kernel file system APIs 306, virtual file system (VFS) 308, and disk 310. Placeholders (metadata files that include pointers to a cloud storage location of a file) may be implemented in a variety of ways in conjunction with a stack like the one shown in diagram 300; see this in light of Nichols ¶ 0032, "In addition to determining when dehydration is needed, a system according to embodiments may also determine which data (e.g., files or folders) to dehydrate. Default, customizable, or dynamic rules for selecting data to dehydrate may be based on relevance to the user, usage history, size, time of hydration, and similar factors" and Nichols FIG. 4, ¶ 0040, "Algorithms may be used to determine a need for dehydration based on user or administrator defined limits (402) or heuristic determination (404)")
Regarding claims 5 and 14, Nichols in view of Anderson and Kumar teaches all the features with respect to claims 1 and 10 above respectively including:
wherein the context comprises a topic associated with the user's activity. (Kumar ¶ 0024: virtual folders can be generated automatically, e.g., using a machine learning tool. For example, machine learning can analyze data such as tagging information assigned to files, past search queries, usage patterns, file access history, tag usage, etc., to determine the most useful virtual folder presentation space)
Regarding claims 6 and 15, Nichols in view of Anderson and Kumar teaches all the features with respect to claims 1 and 10 above respectively including:
wherein the context comprises files accessed by the user during a … time period. (Kumar ¶ 0024: virtual folders can be generated automatically, e.g., using a machine learning tool. For example, machine learning can analyze data such as tagging information assigned to files, past search queries, usage patterns, file access history, tag usage, etc., to determine the most useful virtual folder presentation space)
Nichols teaches files accessed by the user during a predefined time period. (Nichols ¶ 0033: An example policy may ... consider files not accessed for 7 days to be eligible for dehydration; consider files accessed fewer than 10 times in the last 30 days to be eligible for dehydration … Files to be dehydrated may be selected based on multiple criteria such as last access, frequency of access, file type, and a ranking; see also Nichols FIG. 8, ¶ 0069: At operation 820, content to be dehydrated may be determined based on one or more predefined criteria and/or user input. The content (files, folders, etc.) may be determined based on a relevance to the user, access history, size, and comparable factors)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the context of Nichols as modified with the policies of this embodiment of Nichols.
Motivation to do so would be to improve the functioning of Nichols as modified performing context-based automation with the ability in this embodiment of Nichols to also consider context in its automation policies but with the improvement of various criteria and factors.
Regarding claims 8 and 17, Nichols in view of Anderson and Kumar teaches all the features with respect to claims 1 and 10 above respectively including:
wherein settings for when and how the temporary placeholder folder and placeholder files are generated are configurable by the user. (Nichols ¶ 0014: synchronization and/or dehydration actions may be performed automatically based on default and/or customizable rules (policies), user input, or a combination of both; see also Nichols FIG. 4, ¶ 0040: Algorithms may be used to determine a need for dehydration based on user or administrator defined limits (402) or heuristic determination (404). Based on the policies defining how to determine the need for dehydration (408), a detection may be based on a limit (e.g., amount of hydrated files, amount of total data, etc.) being approached or exceeded, files and/or folders may be selected for dehydration (406) based on one or more criteria)
Regarding claims 9 and 18, Nichols in view of Anderson and Kumar teaches all the features with respect to claims 8 and 17 above respectively including:
wherein the settings include one or more of: whether to generate the temporary placeholder folder and placeholder files, when to generate the temporary placeholder and placeholder files, and how long to maintain the temporary placeholder folder and placeholder files. (Nichols ¶ 0048: an algorithm may also consider whether files should be hydrated, as well as dehydrated [fulfills requirements of the claim given language 'one or more of' being interpreted as 'one of']; see this involving folders in at least Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated; Nichols ¶ 0032: In addition to determining when dehydration is needed, a system according to embodiments may also determine which data (e.g., files or folders) to dehydrate; see Nichols ¶ 0040: Diagram 400 shows some example operations that may be employed in determining when to dehydrate local storage and which files/folders to select for dehydration. Algorithms may be used to determine a need for dehydration based on user or administrator defined limits (402) or heuristic determination (404))
Regarding claim 20, Nichols in view of Anderson and Kumar teaches all the features with respect to claim 19 above including:
wherein settings for when and how the temporary placeholder folder and placeholder files are generated are configurable by the user; (Nichols ¶ 0014: synchronization and/or dehydration actions may be performed automatically based on default and/or customizable rules (policies), user input, or a combination of both; see also Nichols FIG. 4, ¶ 0040: Algorithms may be used to determine a need for dehydration based on user or administrator defined limits (402) or heuristic determination (404). Based on the policies defining how to determine the need for dehydration (408), a detection may be based on a limit (e.g., amount of hydrated files, amount of total data, etc.) being approached or exceeded, files and/or folders may be selected for dehydration (406) based on one or more criteria)
and wherein the settings include one or more of: whether to generate the temporary placeholder folder and placeholder files, when to generate the temporary placeholder and placeholder files, and how long to maintain the temporary placeholder folder and placeholder files. (Nichols ¶ 0048: an algorithm may also consider whether files should be hydrated, as well as dehydrated [fulfills requirements of the claim given language 'one or more of' being interpreted as 'one of']; see this involving folders in at least Nichols FIG. 4, ¶ 0040: files and/or folders may be selected for dehydration (406) based on one or more criteria. Selected files folders may then be dehydrated, that is, replaced with placeholders and removed from local storage to make room for new files to be hydrated; Nichols ¶ 0032: In addition to determining when dehydration is needed, a system according to embodiments may also determine which data (e.g., files or folders) to dehydrate; see Nichols ¶ 0040: Diagram 400 shows some example operations that may be employed in determining when to dehydrate local storage and which files/folders to select for dehydration. Algorithms may be used to determine a need for dehydration based on user or administrator defined limits (402) or heuristic determination (404))
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Nichols in view of Anderson and Kumar in further view of Holt, U.S. Patent No. 10,223,506 (published March 5, 2019; hereinafter Holt).
Regarding claims 7 and 16, Nichols in view of Anderson and Kumar teaches all the features with respect to claims 1 and 10 above respectively but does not expressly disclose:
periodically removing previously generated temporary placeholder folder and placeholder files that are no longer in use.
However, Holt addresses this by teaching:
periodically removing previously generated temporary placeholder folder and placeholder files that are no longer in use. (Holt claim 16: the file deletion module is further configured to periodically examine metadata associated with the indirect-access policy storage container and conditionally remove the indirect-access policy storage container, the placeholder object, and the first data file from the computer-readable storage; see then Holt col. 18, lines 7-31: objects stored by the object service 208 that are scheduled to be deleted at a particular time (or based on other criteria) are stored in policy area 760. In this embodiment, a zero-length placeholder object is placed in the object storage system using the typical naming and routing scheme described above. An “object_path” attribute is associated with the placeholder, for example by using an extended attribute, that describes the path to a hidden partition where the object is actually stored on disk)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the deletion and placeholders of Nichols as modified with the deletion and placeholders of Holt.
In addition, both of the references (Nichols as modified and Holt) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as data placeholder management.
Motivation to do so would be to improve the functioning of Nichols as modified replacing removed data with placeholders with the ability in Holt also replacing removed data with placeholders but with the improvement of data retention policies.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to provide an improved scalable object storage system with support for self-deleting files as seen in Holt col. 2, lines 6-8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rosenberger et al., U.S. Patent Application Publication No. 2012/0143931; see Rosenberger ¶ 0449, "defining the name of a file or another attribute of a file automatically may help a user save time and/or avoid typing when storing a file or other data item in a folder" and ¶ 0473, "methods for automatically defining names or other attributes of files, data items and/or folders may be implemented in virtually any GUI-based operating system running on a data processing system,” relevant to at least the independent claim limitations involving a characteristic of the temporary placeholder folder being indicative of the context indicative of the user’s computing activity.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEDIDIAH P FERRER whose telephone number is (571)270-7695. The examiner can normally be reached Monday, Tuesday, Friday, 12:00pm-9:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached at (571)272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.P.F/Examiner, Art Unit 2153 August 25, 2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153
Prosecution Insights