DETAILED ACTION
Notice of Pre-AIA or 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 .
Introductory Remarks
In response to communications filed on 16 June 2026, claims 1, 8, and 15 are amended per Applicant's request. No claims were cancelled. No claims were withdrawn. No new claims were added. Therefore, claims 1-20 are presently pending in the application, of which claims 1, 8, and 15 are presented in independent form.
The previously raised 112(a), lack of written description rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
The previously raised 112(b), indefiniteness rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
The previously raised 103 rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
Response to Arguments
Applicant’s arguments filed 16 June 2026 with respect to the rejection of the claims under 35 U.S.C. 112 (see Remarks, p. 8) have been fully considered but are not persuasive. Applicant solely argues that the amendments overcome the 112 rejections. The Examiner respectfully disagrees, and the 112 rejections have been updated below to conform with the amended claim language.
Applicant did not attempt to address the issues raised by dependent claims 5 and 12, either explicitly in arguments or in amendments, and thus the rejection for these claims has been maintained.
Applicant’s arguments filed 16 June 2026 with respect to the rejection of the claims under 35 U.S.C. 103 (see Remarks, p. 8-13) have been fully considered but are not persuasive.
Applicant’s arguments are primarily based on the context in which the claimed steps are applied, e.g., for rebalancing, whereas the prior art is applied to file migration (see, e.g., Remarks, p. 8-9). However, the claimed steps perform the same steps as the prior art in terms of determining where to migrate data to. Thus, the prior art discloses the same claimed steps, and thus is, at the very least, analogous to the claimed application. See, e.g., MPEP § 2141.01(a) (“A reference is analogous prior art to the claimed invention if: (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention”).
Applicant’s argument that modifying Bolik in the manner described in the Non-Final Rejection “fundamentally changes the operational behavior of Bolik’s list-generation architecture and is entirely based on impermissible hindsight reconstruction using Applicant’s claims as a blueprint” (see Remarks, p. 10-11) is unpersuasive. Applicant’s argument appears to be based on attacking the references individually when the rejection was based on a combination of references. Suit discloses querying a candidate file database, i.e., files that are considered candidates for migration. Bolik discloses both a list of candidate data files for migration (the second list), as well as a list of candidate data files from scanning (the first list).
The only modification needed for Bolik is to populate the first list (from scanning) only when the second list does not return a file to be transferred, as opposed to Bolik’s current manner of having both lists (i.e., both a list from the results of scanning, and a list of candidate files for migration (i.e., similar to the claimed candidate file database)).
Indeed, Bolik discloses, in the cited portions, that the first list is gathered when the second list is, e.g., empty, or otherwise does not return a candidate file for migration. Thus, the only difference between the claimed invention and Bolik is that the scanning list is continually maintained in Bolik, but is utilized when the second list does not return a value, whereas the claimed invention only scans when the second list does not return a value.
Thus, the obvious rationale to modify Bolik to arrive at the claimed invention is to conserve resources that would otherwise have been used for scanning, e.g., no need to continually scan and populate the first list, if the second list already has candidate files meeting transfer parameter criteria. Thus, there is no “fundamental change” to the operational behavior of Bolik, as both lists are still maintained for carrying out the fundamental operations of Bolik, just in an obviously modified manner to arrive at the claimed invention.
Applicant’s argument that Suit does not disclose a multi-dimensional selection process (see Remarks, p. 11-12) is unpersuasive and incorrect. Suit discloses that multiple attributes may be considered prior to migration (see cited portion, Suit, [4:65-67]-[5:1-14]); they are simply different types of dimensions than that which is claimed. Therefore, to add Debnath’s disclosure to Suit’s various dimensional considerations is obvious, as Suit already discloses that multiple attributes (i.e., dimensions) may be considered. Thus, Applicant’s argument that Debnath does not disclose a multi-dimensional selection process is unpersuasive. Furthermore, Applicant’s argument that Debnath’s alleged “generalized storage management is materially different from the claimed rebalancing-selection process” (see Remarks, p. 11-12) is unpersuasive, as the rejection was based on the combination of references, and it has already been addressed above when discussing primary reference Suit above with respect to, e.g., the rebalancing aspect, the multi-dimensional aspect, etc.
Applicant’s argument that “The rejection improperly equates generalized free-space management with Applicant’s specifically claimed reclaimed-storage-capacity ranking mechanism” (see Remarks, p. 12) is unpersuasive. Reclaiming storage capacity and managing free space are intertwined; the claimed storage capacity can only be reclaimed when free space is available. Indeed, the claim language itself determines the estimated amount of reclaimed storage capacity (i.e., free space available) if the file were to be moved. Therefore, Debnath, which discloses determining that some space needs to be freed to lower the utilization percentage, and may select a larger number of files to clear the amount of space, accomplishes the same effect as the claimed invention.
Lastly, Applicant’s argument that Debnath does not disclose “lower-level filesystem structures” or “locally maintained metadata unavailable to remote containers” (see Remarks, p. 12) is unpersuasive.
Firstly, Applicant has incorrectly interpreted “lower-level file information” as being “lower-level filesystem structures”. Lower-level file information simply corresponds to certain file attributes, examples that include deduplication, compression, etc. (see Specification, [0105]). These are not data structures; rather, they are simply additional file attributes. Therefore, Applicant is arguing against limitations that do not exist.
Secondly, Applicant’s argument that the implication that Debnath discloses such a limitation is incorrect (see Remarks, p. 12) is unpersuasive, as Applicant has taken the rejection out of context. There is no actual support in the Specification for the idea that the metadata is “unavailable to remote containers”. Thus, when interpreting this in view of the Specification (which does not contain any explicit, implicit, or suggested indication of what this could possibly mean), such language constitutes, at best, an omission of remote storage containers accessing the metadata (i.e., the Specification at most supports the idea that the remote storage container implicitly does not access the metadata via omitting any mention of the remote storage container accessing the metadata).
In other words, Applicant’s own claim language, which has issues of support, can at best be interpreted such that any prior art that omits disclosing that the remote data container accesses the local data container metadata, then the prior art discloses this limitation. As such, Debnath implicitly discloses the limitation “not shared with the remote data container”, as claimed.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 1, 8, and 15 recite “wherein the one or more files to be transferred are selected via a multi-dimensional selection process comprising a first selection dimension…, and a second selection dimension independently evaluating reclaimed storage capacity…”. There is no support for an “independent evaluation”, e.g., such as by a separate thread, process or module. The only support is that there are multiple dimensions that may be considered, but does not indicate necessarily that these are performed “independently” of one another, e.g., by separate processes or modules, for example.
The dependent claims are rejected for at least by virtue of their dependency on their respective independent claims, and for failing to cure the deficiencies of their respective independent claims.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims 1, 8, and 15 recite “wherein the one or more files to be transferred are selected via a multi-dimensional selection process comprising a first selection dimension…, and a second selection dimension independently evaluating reclaimed storage capacity…”. The most the Specification states is that multiple dimensions may be considered, which is already implicit from the claim language of “first selection dimension” and “second selection dimension”. Adding the language “independently evaluating reclaimed storage capacity” appears to imply that there is, for example, a separate thread, process, or module that performs the second selection dimension evaluation, independent of the first selection dimension evaluation. However, there is no support for an “independent evaluation”, e.g., such as by a separate thread, process or module.
Therefore, it is unclear what is meant by “independently evaluating” reclaimed storage capacity within the context of the claimed invention, e.g., whether this is the same or different in scope from simply considering multiple selection dimensions.
The dependent claims are rejected for at least by virtue of their dependency on their respective independent claims, and for failing to cure the deficiencies of their respective independent claims.
Claims 2-4, 9-11, and 16-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 2, 9, and 16 recite “wherein scanning the file system of the local container to identify files that satisfy the one or more transfer parameters comprises…”. There is a lack of antecedent basis issue with these claims, as this language was removed from the independent claims.
For purposes of examination, the interpretation that this pertains to “scanning a file system of the local data container only if the query to the candidate file database fails to identify a transferable file” has been taken.
The claims further recite “analyzing metadata corresponding to files of the local data container”. Claims 4, 11, and 18 also recite “based on the analysis of the metadata corresponding to the files of the local data container…”. There is a lack of antecedent basis issue here, as the independent claims already recite “using lower-level file information comprising metadata information locally maintained by the local data container…”, i.e., it is unclear whether the metadata of the independent claims were meant to be the same or different from the metadata of the dependent claims.
For purposes of examination, the interpretation that these refer to the same metadata information has been taken.
Dependent claims 3-4, 10-11, and 17-18 are rejected for at least by virtue of their dependency on their respective parent claims, and for failing to cure the deficiencies of their respective parent claims.
Claims 5 and 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The claims recite that the selection of one or more files to transfer from the candidate files is “based at least on capacity available on the second data container and a determination of storage capacity to be gained in the first data container in response to movement of a selected file”.
Firstly, there is a lack of antecedent basis issue with “first” and “second” data containers, as these are referred to as “local” and “remote” data containers in their respective independent claims.
Secondly, the second underlined portion appears to be similar language to that already claimed by the independent claims, i.e., “rank[ing] candidate files based on an estimated amount of reclaimed storage capacity in the local data container after the one or more files to be transferred to the remote data container have been moved”. Thus, the differences in the metes and bounds of the independent claims’ limitations and those of claims 5, and 12, with respect to the second underlined portion, cannot be ascertained.
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-2, 6-9, 14-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Suit (“Suit”) (US 9,813,353 B1), in view of Bolik et al. (“Bolik”) (US 2002/0069280 A1), in further view of Debnath et al. (“Debnath”) (US 2019/0182137 A1).
Regarding claim 1: Suit teaches A rebalancing scanner in a local data container of a distributed file system having a plurality of data containers, the rebalancing scanner to facilitate rebalancing of files within the distributed file system, the rebalancing scanner to:
receive, from a rebalancing engine corresponding to the local data container, a first query for a file to be moved from the local data container to a remote data container as identified by the rebalancing engine; receive, from the rebalancing engine, one or more transfer parameters for use in selecting one or more files in the local data container to be transferred to the remote data container (Suit, [9:50-67]-[10:1-3] and [FIG. 5], where an application processing module 520 (i.e., analogous to the claimed “rebalancing engine”) may perform identifying at least one present allocation parameter being utilized by at least one virtual machine (VM) operating on the enterprise network to identify candidate data files for migration (implying that there a previously received command, i.e., “query” to migrate files).
(The migration is to a “remote” cloud storage server, i.e., which implies that the file is local (i.e., “for a file stored on the local data container”). See also, e.g., Suit, [10:4-33], where the data file(s) to be migrated may be physically stored in the enterprise network prior to selection or migration efforts, and also Suit, [FIG. 5] with respect to the application processing module 520, i.e., “rebalancing engine” within the cloud migration system, and the central database 540 also within the cloud migration system, i.e., “local” to. Thus, both the rebalancing engine and the files are located in the same localized system).
The migration module 520 may then perform requesting a directory file structure and identifying at least one data file for data migration to a remote cloud storage server based on predetermined criteria. See Suit, [4:65-67]-[5:1-14], where the attributes identified and considered prior to any cloud migration may include memory usage and capacity, storage usage and capacity, network device, etc., where these attributes may be used as a basis for selecting those VMs that can migrate their dependent files currently in the virtual storage allocation to cloud storage. See also, e.g., Suit, [5:50-51] and [6:45-56], where a virtual storage contains a directory file structure, and files are stored on virtual storage volumes. Certain paths, i.e., directories.
Although Suit does not appear to explicitly state that the predetermined criteria/attributes are “received”, Suit discloses that any of those factors may be used in consideration; therefore, it is implied that somehow, the system obtains such constraints in order to perform the assessments for files that are candidates for migration. Therefore, one of ordinary skill in the art would have found it obvious to modify Suit such that one or more transfer parameters are “received” with the motivation of enabling dynamic assessments, e.g., as the criteria/attributes that are required may change depending on the nature of the files, system environment considerations, etc., and thus potentially more optimized selections of files for migration);
query a candidate file database for files to be transferred to the remote data container in response to the first query and utilizing the one or more transfer parameters (Suit, [11:3-6], where data files may be migrated periodically and can be updated according to an audit procedure of updated list of files that are acceptable for migration. See Suit, [7:27-42], where the content parser 240 identifies volumes with directory attributes and parses for the “last modified” field to assemble a list of candidate files to be migrated to cloud storage. The list gathered by the parser engine is then added to the database. Recall from Suit, [9:50-67]-[10:1-3] and [FIG. 5] above, with respect to the implication that there was a query command received to perform such querying (i.e., “in response to the first query”). See Suit, [8:41-55], [9:19-49], and [FIGs. 4A and 4B] explanation below with respect to the limitation “utilizing the one or more transfer parameters received from the rebalancing engine”));
scan a file system of the local data container … [to identify a transferable file] (Suit, [8:41-55], where the storage content migration server (SCMS) 109 is responsible for accepting invitations or requests for file migration and identifying file locations, and file candidates for the migration. Recall from Suit, [9:50-67]-[10:1-3] and [FIG. 5] above, with respect to the implication that there was a query command received to perform such querying (i.e., “in response to the first query”). See Suit, [9:19-49] and [FIGs. 4A and 4B], where a directory file structure is requested, and at least one data file is identified for data migration to a remote cloud storage server based on predetermined criteria (i.e., “one or more transfer parameters for use in selecting one or more files in the local container to be transferred to the at least one remote container”), where the attributes identified and current operating conditions of the virtual machines may provide a basis for the specific data files that are candidates for data migration (i.e., “scan a file system of the local container to identify files that satisfy the one or more transfer parameters…”));
selecting from either the query to the candidate file database or the scan of the file system, one or more files to be transferred to the remote data container, wherein the one or more files to be transferred are selected via a multi-dimensional selection process comprising a first selection dimension based on a maximum file size that will fit in the remote data container (Suit, [4:65-67]-[5:1-14], where the attributes identified and considered prior to any cloud migration of the VM allocations include memory usage and capacity, storage usage and capacity, network device, CPU usage, etc. (i.e., “multi-dimensional selection process comprising at least a first selection dimension…”).
Although Suit does not appear to explicitly state that the storage usage and capacity pertains to a “maximum file” size, one of ordinary skill in the art would have recognized that considering storage usage and capacity would encompass maximum file size, e.g., if the storage only has remaining capacity of 5GB, and the file is 10GB, clearly such storage will not be considered as it would not be able to fit a file (i.e., the maximum file size it would be able to fit is 5GB). Therefore, one of ordinary skill in the art would have found it obvious to modify Suit to explicitly include a “maximum file size” with the motivation of ensuring that the storage would be able to store the entire file on that storage rather than breaking it up (which would require piecing it together), i.e., greater storage and retrieval efficiency) …;
transmit, to the rebalancing engine, a response to the first query having an indication of the selected files from either the candidate file database or the scan of the file system selected via the multi-dimensional selection process to be transferred to the remote data container (Suit, [10:4-33], where the file list of potential candidate files for the data migration to the cloud server, which is stored in the database, may be accessed to consider additional data files to migrate to the cloud storage server on a periodic basis, which implies that the list of identified candidate files is “transmitted” to the requesting module. Recall from Suit, [4:65-67]-[5:1-14] above where multiple attributes may be identified and considered prior to any cloud migration of the VM allocations (i.e., “selected via the multi-dimensional selection process”). See Suit, [11:3-6], [7:27-42], [9:50-67]-[10:1-3], [FIG. 5], [8:41-55], [9:19-49], and [FIGs. 4A and 4B] above with respect to the querying of “the candidate file database”; see Suit, [8:41-55], [9:50-67]-[10:1-3], [FIG. 5], [9:19-49], and [FIGs. 4A and 4B] above with respect to the “scan of the file system”); and
terminate operation of the rebalancing scanner until either subsequently queried by the rebalancing engine of the local data container or for a predetermined period of time (Suit, [7:27-42], where the content parser 240 identifies volumes with directory attributes and parses for the “last modified” field to assemble a list of candidate files to be migrated to cloud storage. The list gathered by the parser engine is then added to the database. The content rules engine routinely gathers the file list from the database based on a user definable interval (e.g., 30 minutes, twice a day, once a day, once a week, etc.). The content rules engine 250 then determines if the files are within the prescribed range or not. See Suit, [10:4-33], where the file list of potential candidate files for data migration to the cloud server is generated and stored in the database periodically. The method also includes accessing the file list to consider additional data files to migrate to the cloud storage server on a periodic basis (i.e., “terminate operation until…subsequently queried by the rebalancing engine of the local data container for a predetermined period of time”)).
Suit does not appear to explicitly teach [scanning storage] only if the query to the candidate file database fails to identify a transferable file; and a second selection dimension independently evaluating reclaimed storage capacity that ranks candidate files based on an estimated amount of reclaimed storage capacity in the local data container after the one or more files to be transferred to the remote data container have been moved, wherein the amount of reclaimed storage capacity in the local data container is estimated using lower-level file information comprising metadata information locally maintained by the local data container and not shared with the remote data container.
Bolik teaches [scanning storage] only if the query to the candidate file database fails to identify a transferable file (Bolik, [0030], where at least two lists for identifying candidate data files are provided, whereby the first list is generated and/or updated by the scanning process and whereby the second list is used by the automigration process. See, e.g., Suit, [7:27-42], [8:41-55], [9:19-49], and [11:3-6] in claim 1 above with respect to the “candidate file database”. The automigration process gathers the first list from the scanning process when all candidate data files of the second list are migrated (i.e., the second list not returning a file to be transferred, as all of them have already been transferred).
Although Bolik discloses that both lists are maintained at the same time, whereas the claimed invention scans only upon the candidate file database not returning a file to be transferred, one of ordinary skill in the art would have found it obvious to have modified Bolik such that the scanning (i.e., to generate the first list) is performed only upon the second list not having any more candidate data files to be migrated (i.e., “fails to identify a transferable file”), with the motivation of conserving scanning resources, e.g., reducing resource requirements and generating the first (scanned) list only when necessary).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Suit and Bolik (hereinafter “Suit as modified”) with the motivation of reducing resource and processing requirements for managing a candidate file list (Bolik, [0026]).
Suit as modified does not appear to explicitly teach a second selection dimension independently evaluating reclaimed storage capacity that ranks candidate files based on an estimated amount of reclaimed storage capacity in the local data container after the one or more files to be transferred to the remote data container have been moved, wherein the amount of reclaimed storage capacity in the local data container is estimated using lower-level file information comprising metadata information locally maintained by the local data container and not shared with the remote data container.
Debnath teaches a second selection dimension independently evaluating reclaimed storage capacity that ranks candidate files based on an estimated amount of reclaimed storage capacity in the local data container after the one or more files to be transferred to the remote data container have been moved, wherein the amount of reclaimed storage capacity in the local data container is estimated using lower-level file information comprising metadata information locally maintained by the local data container and not shared with the remote data container (Debnath, [0032-0034] and [0050], where the system creates or accesses a list of files stored in on-premise storage unit 1161 and orders such a list by a particular attribute (e.g., access (or use) time, file size, etc.), which is maintained by file system 106 (see Debnath, [0017]). (i.e., “lower-level file information comprising metadata information locally maintained by the local data container”). For example, the system determines that 1GB of space in the on-premise storage unit 1161 needs to be freed to lower the utilization percentage to the appropriate low-water-mark (LWM) representing levels or percentages of the storage utilization (Debnath, [0021]) The system may select a larger number of files than necessary to clear the amount of space determined at step 206. Note that Debnath does not disclose the cloud storage (i.e., corresponding to the claimed “remote data container”) accessing this information, thereby implying that the lower-level file information maintained by the local data container is “not shared with the remote data container” as claimed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Suit as modified and Debnath (hereinafter “Suit as modified”) with the motivation of with the motivation of improving storage efficiency and read performance of the source storage (see, e.g., Debnath, [0013]).
Regarding claim 2: Suit as modified teaches The rebalancing scanner of claim 1 wherein scanning the file system of the local container to identify files that satisfy the one or more transfer parameters comprises analyzing metadata corresponding to files of the local data container (Suit, [6:45-56], where the directory file structure offers information such as last accessed date, last modified date, last creation date, etc. (i.e., “metadata corresponding to files of the local container”). This provides helpful information used to determine whether files should be migrated).
Regarding claim 6: Suit as modified teaches The rebalancing scanner of claim 1 further comprising updating entries for the candidate files into the candidate file database (Suit, [11:3-6], where data files may be migrated periodically and can be updated according to an audit procedure of updated list of files that are acceptable for migration. See Suit, [10:4-33], where the file list of potential candidate files for data migration to the cloud server is generated and stored in the database periodically. The list will generally be dynamic and will update accordingly).
Regarding claim 7: Suit as modified teaches The rebalancing scanner of claim 1 wherein the scanning of the file system of the local data container in response to the query from the engine is selectively initiated based on evaluation of contents of the candidate file database and an amount of time that has elapsed since a previous scan (Suit, [7:27-42], where the content parser 240 identifies volumes with directory attributes and parses for the “last modified” field to assemble a list of candidate files to be migrated to cloud storage. The list gathered by the parser engine is then added to the database. The content rules engine routinely gathers the file list from the database based on a user definable interval (e.g., 30 minutes, twice a day, once a day, once a week, etc.). The content rules engine 250 then determines if the files are within the prescribed range or not (i.e., “an amount of time that has elapsed since a previous scan”).
See Bolik, [0030], where at least two lists for identifying candidate data files are provided, whereby the first list is generated and/or updated by the scanning process and whereby the second list is used by the automigration process. See, e.g., Suit, [7:27-42], [8:41-55], [9:19-49], and [11:3-6] in claim 1 above with respect to the “candidate file database”. The automigration process gathers the first list from the scanning process when all candidate data files of the second list are migrated (i.e., the second list not returning a file to be transferred, as all of them have already been transferred)).
Regarding claim 8: Claim 8 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Note that Suit teaches A non-transitory computer readable medium having stored thereon instructions that, when executed, cause [the disclosed steps] (Suit, [11:54-67]-[12:1-2], where a memory 610 and a processor 620 may be components of the disclosed network entity 600 that are used to execute an application or set of operations coded in a computer language understood by the processor 620 and stored in a computer readable medium such as memory 610, the computer readable medium being a non-transitory computer readable medium).
Regarding claim 9: Claim 9 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 14: Claim 14 recites substantially the same claim limitations as claim 7, and is rejected for the same reasons.
Regarding claim 15: Claim 15 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons, in addition to the reasons below:
Suit further discloses A distributed file system comprising: a plurality of containers each having at least a rebalancing engine and a rebalancing scanner, each of the plurality of containers to store one or more files and each of the plurality of data containers having corresponding container-level parameters for characteristics of files stored on the container (Suit, [5:50-51] and [6:45-56], where a virtual storage contains a directory file structure, and files are stored on virtual storage volumes. Certain paths, i.e., directories (i.e., “containers”) (see, e.g., Suit, [7:67]-[8:1-2]1) may also be contained within storage volumes. The directory file structure includes information such as last accessed data, last modified date, last creation date, etc. (i.e., “container-level parameters for characteristics of files stored on the container”)).
Regarding claim 16: Claim 16 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 19: Claim 19 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 20: Claim 20 recites substantially the same claim limitations as claim 7, and is rejected for the same reasons.
Claims 3-4, 10-11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Suit (“Suit”) (US 9,813,353 B1), in view of Bolik et al. (“Bolik”) (US 2002/0069280 A1), in further view of Debnath et al. (“Debnath”) (US 2019/0182137 A1), in further view of English (“English”) (US 7,984,259 B1).
Regarding claim 3: Suit as modified teaches The rebalancing scanner of claim 2 further comprising analyzing a [data structure] associated with the files of the local data container (Suit, [6:45-56], where the directory file structure offers information such as last accessed date, last modified date, last creation date, etc. (i.e., the directory file structure corresponding to a “data structure”). This provides helpful information used to determine whether files should be migrated).
Suit as modified does not appear to explicitly teach that the analyzed data structure is a buftree.
English teaches a buftree (English, [7:38-67]-[8:1-6] and [FIG. 4], where file system 280 maintains various data structures called buffer trees (i.e., “buftree”) to keep track of the organization of data blocks that store data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Suit as modified and English (hereinafter “Suit as modified”) with the motivation of keeping track of the organization of data blocks that store data in addition to its metadata (English, [7:38-67]-[8:1-6]), i.e., associating location information and metadata together for more optimal data retrieval operations.
Regarding claim 4: Suit as modified teaches The rebalancing scanner of claim 3 further comprising inserting entries for the candidate files into the candidate file database based on the analysis of the metadata corresponding to the files of the local data container and on the analysis of the buftree associated with the files of the local data container (Suit, [6:45-56], where the user may configure the content rules engine within the SCMS to only consider files on specific virtual storage volumes (i.e., “based on the analysis of the [buftree]2 associated with the files of the local container”), and the directory file structure offers information such as last accessed date, last modified date, last creation date, etc. (i.e., “metadata corresponding to files of the local container”). This provides helpful information used to determine whether files should be migrated. See Suit, [7:27-42], where the content parser 240 identifies volumes with directory attributes and parses for the “last modified” field to assemble a list of candidate files to be migrated to cloud storage. The list gathered by the parser engine is then added to the database. See English, [7:38-67]-[8:1-6] and [FIG. 4], where associated pointers 605 point to a lower-level block that it references, namely a Virtual Block Number (VBN) and a Virtual Volume Block Number (VVBN) (an address of the block in the volume). See English, [7:38-67]-[8:1-6] above with regards to the “buftree”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Suit as modified and English with the motivation of keeping track of the locations of virtual volumes which are restricted from being accessed such that the scanning of candidate files for migration will not take place on such restricted volumes, per the user’s configuration requirements.
Regarding claim 10: Claim 10 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 11: Claim 11 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 17: Claim 17 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 18: Claim 18 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Claims 5 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Suit (“Suit”) (US 9,813,353 B1), in view of Bolik et al. (“Bolik”) (US 2002/0069280 A1), in further view of Debnath et al. (“Debnath”) (US 2019/0182137 A1), in further view of Nidugala et al. (“Nidugala”) (US 2017/0315838 A1).
Regarding claim 5: Suit as modified teaches The rebalancing scanner of claim 1, but does not appear to explicitly teach further comprising selecting one or more files to transfer from the candidate files based at least on capacity available on the second data container and a determination of storage capacity to be gained in the first data container in response to movement of a selected file.
Nidugala teaches selecting one or more files to transfer from the candidate files based at least on capacity available on the second data container and a determination of storage capacity to be gained in the first data container in response to movement of a selected file (Nidugala, [0066], where capacity utilization of candidate servers is checked, and the server having a higher capacity utilization compared to the other servers is selected to be the destination server (i.e., “based at least on capacity available on the second container”). See Debnath, [0021], [0032-0034] and [0050] in claim 1 above with respect to the “determination of storage capacity to be gained in the first data container in response to movement of a selected file”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Suit as modified and Nidugala with the motivation of optimizing system performance by moving files to an appropriate destination target, e.g., for optimizing load balancing.
Regarding claim 12: Claim 12 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 13: Claim 13 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Conclusion
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 IRENE BAKER whose telephone number is (408)918-7601. The examiner can normally be reached M-F 8-5PM PT.
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, Boris Gorney can be reached at (571) 270-5626. 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.
/IRENE BAKER/Primary Examiner, Art Unit 2154
18 July 2026
1 The class path is in the form of “volume\path”, which indicates that the “\path” portion, i.e., a path, is a directory.
2 Because English’s buftree contains the location of the data within the virtual volume, thus in this manner, when taken in combination with Suit’s disclosure of only considering certain virtual storage volumes, Suit therefore analyzes both the “buftree” (i.e., corresponding to the location of the virtual volume) and the metadata (i.e., last accessed/modified information, etc.).
Prosecution Insights