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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 23 December 2025 has been entered.
Introductory Remarks
In response to communications filed on 23 December 2025, 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 rejections 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 23 December 2025 with respect to the rejection of the claims under 35 U.S.C. 112 (see Remarks, p. 8) have been fully considered. The amendments render the previous rejection moot; however, a new ground(s) of rejection has been raised for the amendments. See the 112 rejection below for further details.
Applicant’s arguments filed 23 December 2025 with respect to the rejection of the claims under 35 U.S.C. 103 (see Remarks, p. 8-12) have been fully considered but are moot, as Applicant’s arguments are not directed to the new references (and thus new combination of references) being used in the current rejection (i.e., Bodmer and Chung are not relied upon to reject the claimed features). See the 103 rejection below for further details.
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 amount of reclaimed storage capacity in the local data container is estimated using lower-level file information maintained by the local data container and unavailable to the remote data container”. As the remote data container does not appear to access this information, it is unclear where in the Specification support for this can be found. Furthermore, this also implies a broader possibility for the lower-level file information maintained by the local data container to be accessible to some other components, which does not appear to be supported by the Specification. Thus, there is a lack of support for such a limitation.
Furthermore, a relationship between the amount of reclaimed storage capacity in the local data container and the unavailability to the remote data container, as a result, is not supported.
Independent Claims 1, 8, and 15 further recite “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…and a second, independent selection dimension that ranks candidate files based on an estimated amount of reclaimed storage capacity in the local data container…”.
“Independent” selection implies that this is somehow separate from the consideration for the first selection dimension. However, the claim explicitly states that the selection occurs as part of a “multi-dimensional selection process”, meaning that multiple dimensions are considered, including the second selection dimension, which cannot be “independent” then. Therefore, the Specification lacks support for such a limitation.
The rest of the dependent claims are rejected for at least by virtue of their dependency on 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 amount of reclaimed storage capacity in the local data container is estimated using lower-level file information maintained by the local data container and unavailable to the remote data container”. Given that the Specification appears to be silent on the availability or unavailability of the remote data container (relative to either the amount of reclaimed storage capacity or lower-level file information maintained by the local data container), it is unclear what is meant by this limitation, e.g., whether this was meant to refer to, e.g., whether this was intended to mean that the amount of reclaimed storage capacity is not available on the remote data container (which would not appear to make sense), or whether this was meant to indicate that the lower-level file information maintained by the local data container is not available to the remote data container. However, the latter interpretation is not certain, given that the language “and” was used (i.e., using lower-level file information maintained by the local container “and” (instead of “that is”) unavailable to the remote data container).
Therefore, the metes and bounds of such a limitation cannot be established.
Independent Claims 1, 8, and 15 further recite “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…and a second, independent selection dimension that ranks candidate files based on an estimated amount of reclaimed storage capacity in the local data container…”.
“Independent” selection implies that this is somehow separate from the consideration for the first selection dimension. However, the claim explicitly states that the selection occurs as part of a “multi-dimensional selection process”, meaning that multiple dimensions are considered, including the second selection dimension. Therefore, the metes and bounds of “independent” within the context of the multi-dimensional selection process cannot be ascertained.
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 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 container in their respective independent claims.
Secondly, the second underlined portion already seems to be covered by the amended claim language in 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 this underlined portion, cannot be ascertained.
A potential amendment for claim 5 may be, e.g., “The rebalancing scanner of claim 1, wherein the the one or more files to transfer from the candidate files is further basedremote data container ”, or some other equivalent language.
A potential amendment for claim 12 may similarly be, e.g., “The non-transitory computer readable medium of claim 8 further comprising instructions that, when executed, cause the rebalancing scanner to perform the selecting the one or more files to transfer from the candidate files being further basedremote data container ”, or some other equivalent language.
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., “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 in response to the first query to identify files that satisfy the one or more transfer parameters … (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] if the query to the candidate file database does not return a file to be transferred to the remote data container; and at least a second, independent selection dimension that ranks candidate files based on of 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 maintained by the local data container and unavailable to the remote data container.
Bolik teaches [scanning storage] if the query to the candidate file database does not return a file to be transferred to the at least one remote data container (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. Se 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 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 upon the second list not having any more candidate data files to be migrated, 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 at least a second, independent selection dimension that ranks candidate files based on of 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 maintained by the local data container and unavailable to the remote data container.
Debnath teaches at least a second, independent selection dimension that ranks candidate files based on of 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 maintained by the local data container and unavailable to 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 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 “unavailable to 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 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
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, NEVEEN ABEL-JALIL can be reached at (571)270-0474. 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 2152
14 January 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.).