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 .
This Non-Final Office Action is in response to the application 18/738,572 filed on 03/20/2026.
Status of Claims:
Claims 1, 7, 12-13, 15, 17, and 19-20 are amended in this Office Action.
Claims 1-20 are pending in this Office Action.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/07/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 03/20/2026 has been entered.
Response to Arguments
Rejection of claims under 35 USC § 112(a)
Applicant’s arguments filed on 02/19/2026 (pages 7-8) regarding claim
rejections under 35 U.S.C 112(a) and the amendments submitted have been fully
considered. The rejections made under 35 U.S.C 112(a) in the previous office action are
now withdrawn after considering the applicant’s remarks and amendments.
Rejection of claims under 35 USC § 101
Applicant’s arguments filed on 02/19/2026 (pages 8-13) regarding claim
rejections under 35 U.S.C 101 and the amendments submitted have been fully
considered. The rejections made under 35 U.S.C 101 in the previous office action are
now withdrawn after considering the applicant’s remarks and amendments.
CLAIM REJECTIONS UNDER 35 U.S.C. § 102/103
Applicant’s arguments filed on 02/19/2026 (pages 13-15) regarding claim rejections under 35 U.S.C 102/103 have been fully considered. However, after further examination and consideration, the Examiner respectfully submits that the arguments are not persuasive.
The applicant argues that the cited references do not teach or suggest “based on (i) the constructed hierarchical tree and (ii) the identified multiple non-duplicate chunks, constructing two or more datapacks, wherein each datapack is a respective file and each the at least one datapack includes (a) one or more non-duplicate chunks of the identified at-least-one multiple non-duplicate chunks and (b) one or more leaf nodes of the generated plurality of nodes, the one or more leaf nodes corresponding to the one or more non-duplicate chunks”, of claims 1, 19, and 20. The examiner respectfully disagrees with the Applicant; the Examiner respectfully submits that Parekh discloses “Col 6 line 62-67 & col 7 line 1-12: Thus, replicator 116 descends down the mismatched branch of the tree and compares L1 segment 211 (or 213) against L1 segment 211′ (or 213′), and L1 segment 212 (or 213) against L2 segment 212′ (or 213′). In these examples, replicator 116 determines that L1 segments 211 and 211′ are mismatched (or 213 and 213′ are mismatched), while L1 segments 212 and 212′ match (or 214 and 214′ match). Replicator 116 continues to descend down the mismatched branch of the trees and compares L0 segment 201 against 201′ (or 203 against 203′), and L0 segment 202 against 202′ (or 204 and 204′). In this example, replicator 116 determines that L0 segments 201 and 201′ are different (or 203 and 203′ are different), while L0 segments 202 and 202′ match (or 204 and 204′ match). As a result, replicator 116 replicates mismatched L3 segment 261, L2 segment 221, L1 segment 211, and L0 segment 201 (or 262, 223, 213, and 203), by sending them to the target storage system.”. The system of Parekh is directed to utilizing the segment trees to compare the segments between the trees to find the mismatched segments. The results of the comparisons are then collected and sent to a particular location such as a target storage system. The identified mismatched segments between the trees can correspond to multiple non-duplicate chunks. Thus, each mismatched L3 segment 261, L2 segment 221, L1 segment 211, and L0 segment 201 can be a datapack of its own because each segment can be constructed based on the tree and identified mismatched segments. Also, each segment can include (a) one or more non-duplicate chunks, which is the mismatched segment itself, and (b) one or more leaf nodes, which each segment belongs to a node at particular L level such as L0-L3 in figure 2. Therefore, Parekh at least teaches “based on (i) the constructed hierarchical tree and (ii) the identified multiple non-duplicate chunks, constructing two or more datapacks, wherein each datapack is a respective file and each the at least one datapack includes (a) one or more non-duplicate chunks of the identified at-least-one multiple non-duplicate chunks and (b) one or more leaf nodes of the generated plurality of nodes, the one or more leaf nodes corresponding to the one or more non-duplicate chunks”.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4-7, 9-10, 12-17, and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Parekh (US Patent 10,331,362) “Parekh”.
Regarding claim 1, Parekh teaches a computer-implemented method for storing a datafile, the computer-implemented method comprising: partitioning a datafile into a plurality of chunks (Col 8 line 25-33: The system may segment a file to be stored on a source storage system into fixed size segments (e.g. as represented in segment tree 201 of FIG. 2). In one embodiment, the system may segment the file into fixed size segments or variable size segments. For example, a size of the fixed-size boundary for segments may be approximately 4 megabytes, and a size of the fixed size segments may be approximately 8 kilobytes, and a size of the variable size segments may be between approximately 4-12 kilobytes…Examiner’s note: Thus, the file is equivalent to the datafile of the application wherein the file is segmented/partitioned into segments/chunks); generating a plurality of nodes representing the plurality of chunks (Col 5 line 51-67 & col 6 line 1-3: Segment trees 200 and 201 include multiple hierarchies/levels of segments of a file, each level including segments that are further segmented into two or more segments of a lower level. For example, Segment tree 200 includes four levels: L3, L2, L1, and L0. L3 includes one segment 261 representing an entire file, a directory of one or more files, or a virtual machine, stored on the system; L3 segment 261 is segmented into two or more L2 segments (e.g., L2 segments 221-222); each L2 segment, in turn, is segmented into two or more L1 segments (e.g., L1 segments 211-212), and each L1 segment is further segmented into two or more L0 segments (e.g., L0 segments 201-202); constructing a hierarchical tree representing the datafile, the hierarchical tree including the generated plurality of nodes (Col 2 line 56-65: According to some embodiments, a data object, such as a file, is stored on a source storage system and the data object is represented by a segment tree that includes one or more levels of segments (e.g., deduplicated segments). In some embodiments, each level of the segment tree includes one or more segments of the file. Each segment of a level is further segmented into multiple segments and stored at a lower level of the same segment tree.. Examiner’s note: The segments of the segment tree can be equivalent to plurality of nodes of the application and the tree is equivalent to the hierarchical tree that represents a datafile or file); generating respective chunk identifiers (IDs) corresponding to the plurality of chunks (Col 2 line 63-65: In one embodiment, fingerprints are generated for each segment using a collision-resistant hash function, e.g., a SHA-1 hash…Col 6 line 47-52: A new fingerprint would be generated for L0 segment, which would have a ripple effect up the segment tree, causing L1 segment , L2 segment , and L3 segment, to all have new fingerprints… Thus, fingerprints are equivalent to chunk IDs); identifying multiple non-duplicate chunks from among the plurality of chunks based on the generated respective chunk IDs (Col 6 line 52-67 and col7 line 1-12 : System compares L3 fingerprints of 200 and 201 with a previous segment tree 200′ and 201′ respectively that may, for example, represent a backup copy of the file or a basefile, and determines that they are different, indicating the file has been modified since the last replication. However, rather than replicating the entire segment tree, replicator 116 compares the L2 segments of the source and target segment trees. In this example, replicator determines that L2 segments 221 and 221′ (or 213 and 213′) are different,... In these examples, replicator 116 determines that L1 segments 211 and 211′ are mismatched (or 213 and 213′ are mismatched),… In this example, replicator 116 determines that L0 segments 201 and 201′ are different (or 203 and 203′ are different),… Examiner’s note: Thus, the determined mismatched segments between two trees are equivalent to the non-duplicate chunk and they are identified based on comparing the fingerprints of the segments which is equivalent to the generated respective chunk IDs );based on (i) the constructed hierarchical tree and (ii) the identified multiple non-duplicate chunks, constructing two or more datapacks, wherein each datapack is a respective file and each the at least one datapack includes (a) one or more non-duplicate chunks of the identified at-least-one multiple non-duplicate chunks and (b) one or more leaf nodes of the generated plurality of nodes, the one or more leaf nodes corresponding to the one or more non-duplicate chunks (Col 6 line 62-67 & col 7 line 1-12: Thus, replicator 116 descends down the mismatched branch of the tree and compares L1 segment 211 (or 213) against L1 segment 211′ (or 213′), and L1 segment 212 (or 213) against L2 segment 212′ (or 213′). In these examples, replicator 116 determines that L1 segments 211 and 211′ are mismatched (or 213 and 213′ are mismatched), while L1 segments 212 and 212′ match (or 214 and 214′ match). Replicator 116 continues to descend down the mismatched branch of the trees and compares L0 segment 201 against 201′ (or 203 against 203′), and L0 segment 202 against 202′ (or 204 and 204′). In this example, replicator 116 determines that L0 segments 201 and 201′ are different (or 203 and 203′ are different), while L0 segments 202 and 202′ match (or 204 and 204′ match). As a result, replicator 116 replicates mismatched L3 segment 261, L2 segment 221, L1 segment 211, and L0 segment 201 (or 262, 223, 213, and 203), by sending them to the target storage system… Examiner’s note: The system utilizes the segment trees to compare the segments between the trees to find the mismatched segments. The identified mismatched segments between the trees can correspond to multiple non-duplicate chunks. The identified mismatched segments are also used to send to a particular location such as a target storage system. Thus, each mismatched L3 segment 261, L2 segment 221, L1 segment 211, and L0 segment 201 can be a datapack of its own because each segment can be constructed based on the tree and identified mismatched segments. Also, each segment can include (a) one or more non-duplicate chunks, which is the mismatched segment itself, and (b) one or more leaf nodes, which each segment belongs to a node at particular L level such as L0-L3 in figure 2.); and storing the two or more datapack in memory (col 9 line 3-5: The system may send the modified segments from the source storage system to the target storage system for replication… Examiner’s note: Thus, the modified segments or datapacks can be stored in a corresponding memory such as a storage system).
Regarding claim 2, Parekh teaches all of limitations of claim 1. Parekh further teaches wherein constructing the data structure includes: generating the hierarchical tree by iteratively partitioning the generated plurality of nodes until a condition is met, the iteratively partitioning being based on a criterion (Col 5 line 51-67 & col 6 line 1-3: Segment trees 200 and 201 include multiple hierarchies/levels of segments of a file, each level including segments that are further segmented into two or more segments of a lower level. For example, Segment tree 200 includes four levels: L3, L2, L1, and L0. L3 includes one segment 261 representing an entire file, a directory of one or more files, or a virtual machine, stored on the system; L3 segment 261 is segmented into two or more L2 segments (e.g., L2 segments 221-222); each L2 segment, in turn, is segmented into two or more L1 segments (e.g., L1 segments 211-212), and each L1 segment is further segmented into two or more L0 segments (e.g., L0 segments 201-202). Accordingly, in one embodiment, the L0 segments may be referred to as data segments (e.g. represent the actual data of a file), and L1-L3 segments may be referred to as metadata segments (e.g. represent fingerprints of a lower level of data)… Col 6 line 13-27: Variable size anchoring segment tree and fixed size anchoring segment tree differ with respect to type of segmentation used for L0 segments (e.g. data segments). For example, as shown the variable size anchoring segment tree 200 includes variable size segments for the data segments including segment 201, which is larger than segment 202. In other words, each L0 segment in segment tree 200 may have a different size. In contrast, as shown the fixed size anchoring segment tree 201 includes fixed size (e.g. uniform size) segments for data segments 203 and 204. In one embodiment, where the sizes of the L0 segments are different in segment trees 200 and 201, the L1 segments may still be fixed at a particular size boundaries… Examiner’s note: Thus, each tree that represents a file is built with node edge relationship and in a hierarchical structure. The nodes at each level of the hierarchical tree can be partitioned based on a condition such as that each node is segmented into two or more segments to the lower level).
Regarding claim 4, Parekh teaches all of limitations of claim 2. Parekh further teaches wherein the criterion is based on a target average number of child nodes for a given parent node of the plurality of nodes (Col 5 line51-66: FIG. 2 is a block diagram illustrating segment trees according to an embodiment of the disclosure. Shown is a variable size anchoring segment tree 200 and a fixed size anchoring segment tree 201. Segment trees 200 and 201 include multiple hierarchies/levels of segments of a file, each level including segments that are further segmented into two or more segments of a lower level. For example, Segment tree 200 includes four levels: L3, L2, L1, and L0. L3 includes one segment 261 representing an entire file, a directory of one or more files, or a virtual machine, stored on the system; L3 segment 261 is segmented into two or more L2 segments (e.g., L2 segments 221-222); each L2 segment, in turn, is segmented into two or more L1 segments (e.g., L1 segments 211-212), and each L1 segment is further segmented into two or more L0 segments (e.g., L0 segments 201-202)… Examiner’s note: Thus, each level including segments that are further segmented into two or more segments of a lower level can be equivalent to a criterion of a target average number of child nodes for a given parent node).
Regarding claim 5, Parekh teaches all of limitations of claim 2. Parekh further teaches wherein the criterion is based at least in part on a given node ID for a given node of the plurality of nodes, the given node ID being calculated based upon one or more chunk IDs associated with the given node (Col 4 line 26-30: Fingerprints are mapped to a particular data object via metadata 110, enabling the system to identify the location of the data object containing a segment represented by a particular fingerprint… Col 6 line 28-32: A fingerprint is generated for each segment of the segment tree, e.g., by using a collision-resistant hash function such as SHA-1 hash function. In such an embodiment, the fingerprints are arranged/structured in a format that is identical to its segment tree format… Examiner’s note: Thus, each segment or node in a tree is assigned with a fingerprint/ID that represents the particular segment or node in a tree).
Regarding claim 6, Parekh teaches all of limitations of claim 2. Parekh further teaches wherein at least one of the condition and the criterion is based on user input (Col 1 line 36-42: MTrees are user-defined logical partitions of the storage systems that enable granular management of the file system. MTree replication creates periodic snapshots at a source system and sends the differences between two consecutive snapshots to a target storage system. MTree replication supports all the topologies supported by directory replication.).
Regarding claim 7, Parekh teaches all of limitations of claim 1. Parekh further teaches wherein the datafile is a first datafile, wherein the hierarchical tree is a first hierarchical tree, and where identifying the multiple non-duplicate chunks includes: comparing the first hierarchical tree with a second hierarchical tree associated with a second datafile (Col 6 line 52-67 & col 7 line 112: The system compares L3 fingerprints of 200 and 201 (first hierarchical tree) with a previous segment tree (second hierarchical tree) 200′ and 201′ respectively that may, for example, represent a backup copy (second datafile) of the file or a basefile, and determines that they are different, indicating the file has been modified since the last replication. However, rather than replicating the entire segment tree, the system compares the L2 segments of the source and target segment trees. In this example, system determines that L2 segments 221 and 221′ (or 213 and 213′) are different, but L2 segments 222 and 222′ (or 224 and 224′) are the same. Thus, replicator 116 descends down the mismatched branch of the tree and compares L1 segment 211 (or 213) against L1 segment 211′ (or 213′), and L1 segment 212 (or 213) against L2 segment 212′ (or 213′). In these examples, replicator 116 determines that L1 segments 211 and 211′ are mismatched (or 213 and 213′ are mismatched), while L1 segments 212 and 212′ match (or 214 and 214′ match). Replicator 116 continues to descend down the mismatched branch of the trees and compares L0 segment 201 against 201′ (or 203 against 203′), and L0 segment 202 against 202′ (or 204 and 204′). In this example, replicator 116 determines that L0 segments 201 and 201′ are different (or 203 and 203′ are different), while L0 segments 202 and 202′ match (or 204 and 204′ match). As a result, replicator 116 replicates mismatched L3 segment 261, L2 segment 221, L1 segment 211, and L0 segment 201 (or 262, 223, 213, and 203), by sending them to the target storage system… Examiner’s note: Thus, comparisons are made between different hierarchical trees to identify mismatched or non-duplicate data).
Regarding claim 9, Parekh teaches all of limitations of claim 1. Parekh further teaches wherein partitioning the datafile into the plurality of chunks includes: partitioning the datafile into the plurality of chunks based on a target chunk size (Col 6 line 13-27: Variable size anchoring segment tree 200 and fixed size anchoring segment tree 201 differ with respect to type of segmentation used for L0 segments (e.g. data segments). For example, as shown the variable size anchoring segment tree 200 includes variable size segments for the data segments including segment 201, which is larger than segment 202. In other words, each L0 segment in segment tree 200 may have a different size. In contrast, as shown the fixed size anchoring segment tree 201 includes fixed size (e.g. uniform size) segments for data segments 203 and 204. In one embodiment, where the sizes of the L0 segments (e.g. data segments) are different in segment trees 200 and 201, the L1 segments (e.g. metadata segments) may still be fixed at a particular size (e.g., fixed at 4-megabyte (MB) boundaries)… Examiner’s note: Thus, the partitioned file into a plurality of segments can be based on a target chunk/segment size.).
Regarding claim 10, Parekh teaches all of limitations of claim 9. Parekh further teaches wherein the target chunk size is based on user input (Col 1 line 36-42: MTrees are user-defined logical partitions of the storage systems that enable granular management of the file system. MTree replication creates periodic snapshots at a source system and sends the differences between two consecutive snapshots to a target storage system. MTree replication supports all the topologies supported by directory replication…Col 8 line 25-33: The system may segment a file to be stored on a source storage system into fixed size segments (e.g. as represented in segment tree 201 of FIG. 2). In one embodiment, the system may segment the file into fixed size segments or variable size segments. For example, a size of the fixed-size boundary for segments may be approximately 4 megabytes, and a size of the fixed size segments may be approximately 8 kilobytes, and a size of the variable size segments may be between approximately 4-12 kilobytes… Examiner’s note: Thus, a tree can have user-defined logical partitions where a size of a chunk or segment can be specified to a specific size such as 8 kilobytes, so the size can be based on a user input).
Regarding claim 12, Parekh teaches all of limitations of claim 1. Parekh further teaches wherein identifying the multiple non-duplicate chunks includes: querying a data repository index to identify at least one unique chunk ID corresponding to at least one non-duplicate chunk of the multiple non-duplicate chunks (Col 9 line 52-59: File system control processes information to indicate the segment(s) association with a file. A list of fingerprints is used to indicate segment(s) associated with a file. File system control passes segment association information (e.g., representative data such as a fingerprint) to an index. The index is used to locate stored segments in storage units via storage unit interface…Col 10 line 11-26: File system control communicates with an index (not shown) to locate appropriate segments stored in storage units via storage unit interface 1012. File system control utilizes a tree (e.g., a segment tree) of content-based identifiers (e.g., fingerprints) to associate a file with data segments and their locations in storage unit(s). In the event that a segment associated with a given file or file changes, the content-based identifiers will change and the changes will ripple from the bottom to the top of the tree associated with the file efficiently since the appropriate content-based identifiers are easily identified using the tree structure… Thus, the system uses an index to store fingerprints/ID relating to the segments/chunks and the fingerprints/ID of the chunks change when the segments/chunks change their data. The non-duplicate chunks can be identified based on the identifiers of the chunks stored in an index).
Regarding claim 13, Parekh teaches all of limitations of claim 1. Parekh further teaches generating a metadata segment corresponding to a given datapack of the two or more datapacks, the metadata segment including information regarding content of the given datapack (Col 4 line 23-30: In one embodiment, metadata may include fingerprints contained within data objects , where a data object may represent a data segment, a compression region (CR) of data segments, or a container of one or more CRs. Fingerprints are mapped to a particular data object via metadata, enabling the system to identify the location of the data object containing a segment represented by a particular fingerprint…col 4 line 52-54: Metadata information further includes index information (e.g., location information for segments in storage units, identifying specific data objects)… Examiner’s note: Thus, each chunk or segment contains a respective metadata that contain information such as fingerprint, index information, location information for segments in storage units, identifying specific data objects).
Regarding claim 14, Parekh teaches all of limitations of claim 13. Parekh further teaches updating a data repository index based on the generated metadata segment (Col 9 line 52-58: File system control processes information to indicate the segment(s) association with a file. In some embodiments, a list of fingerprints is used to indicate segment(s) associated with a file. File system control passes segment association information (e.g., representative data such as a fingerprint) to an index (not shown). The index is used to locate stored segments in storage units 1010 via storage unit interface… Examiner’s note: Thus, an index can be updated with association information such as fingerprint information of each segment of a file).
Regarding claim 15, Parekh teaches all of limitations of claim 1. Parekh further teaches wherein the memory is associated with a cloud-based server and the computer-implemented method further comprises: prior to the storing, transferring the constructed two or more datapacks to the cloud-based server (Fig.1 & Col 3 line 33-34: Storage systems 104-105 may include any type of server or cluster of servers (e.g., cloud servers)… Col 9 line 3-5: The system may send the modified segments (datapack) from the source storage system to the target storage system for replication… Examiner’s note: Thus, the modified segments or datapack is transferred to a cloud server and subsequently stored within the particular cloud server).
Regarding claim 16, Parekh teaches all of limitations of claim 15. Parekh further teaches wherein the datafile is a newly-versioned file in a revision control system (RCS) and the cloud-based server includes a repository of the RCS, and further comprising: performing the transferring as part of committing the newly-versioned file into the repository (Col 8 line 34-41: The system may compare a first segment tree of the file (e.g. current version of the file) with a second segment tree representing a basefile of the file (e.g. backup copy of the file), wherein the first and second segment trees each include at least a first level representing the segments of the file, and a second level representing fingerprints of segments within a fixed size boundary (e.g. as shown in FIGS. 4A and 4B)... Fig.1 & Col 3 line 33-34: Storage systems 104-105 may include any type of server or cluster of servers (e.g., cloud servers)… Examiner’s note: Thus, newly-versioned file can be included as part of the process and datapack/modified segments can be identified based on the newly version file and stored in a cloud server).
Regarding claim 17, Parekh teaches all of limitations of claim 15. Parekh further teaches performing the transferring in parallel by instantiating at least two respective transfer threads corresponding to the two or more datapacks (Col 10 line 62-67 & col 11 line 1-4 : The processes or methods depicted in the preceding figures may be performed by processing logic that comprises hardware (e.g. circuitry, dedicated logic, etc.), software (e.g., embodied on a non-transitory computer readable medium), or a combination of both. Although the processes or methods are described above in terms of some sequential operations, it should be appreciated that some of the operations described may be performed in a different order. Moreover, some operations may be performed in parallel rather than sequentially).
Regarding claim 19, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claim 20, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Parekh (US Patent 10,331,362) “Parekh” in view of Westbrooke (US PGPUB 20120290651) “Westbrooke”.
Regarding claim 3, Parekh teaches all of limitations of claim 2. Parekh does not explicitly teach wherein the condition includes a first number of nodes at a first level of the hierarchical tree not being less than a second number of nodes at a second level of the hierarchical tree, the first level being higher than the second level in a hierarchical order of the hierarchical tree.
Westbrooke teaches the condition includes a first number of nodes at a first level of the hierarchical tree not being less than a second number of nodes at a second level of the hierarchical tree, the first level being higher than the second level in a hierarchical order of the hierarchical tree ([0042]: In the illustrated embodiment of FIG. 1 there are a smaller number of nodes in higher levels of the hierarchical structure. This is expected to be the most common arrangement in practice. However, this is not essential. A higher level of the hierarchical structure may have an equal number of nodes, or even a greater number of nodes, compared to a lower level of the hierarchical structure.). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Westbrooke teachings in the Parekh system. Skilled artisan would have been motivated to incorporate variation in number of nodes at each level of a tree taught by Westbrooke in the Parekh system so a particular tree can achieve an expected level of efficiency such as reaching a certain tree height and broadening the tree to improve searching efficiency. This close relation between both of the references highly suggests an expectation of success.
Claims 8 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Parekh (US Patent 10,331,362) “Parekh” in view of Ponnala et al. (US PGPUB 20210191640) “Ponnala”.
Regarding claim 8, Parekh teaches all of limitations of claim 2. Parekh does not explicitly teach wherein partitioning the datafile into the plurality of chunks includes: partitioning the datafile into the plurality of chunks based on at least one of a Rabin-Karp function and a FastCDC function.
Ponnala teaches partitioning the datafile into the plurality of chunks based on at least one of a Rabin-Karp function and a FastCDC function ([0119]: FIG. 3 is a flow diagram of a segmenting module 300 configured to segment a data stream. In FIG. 3, the segmenting module 300 may begin by receiving a data stream at block 302. The data stream may be a file or another type of object that can be deduplicated. At block 302, the segmenting module 300 may pre-chunk the data stream to create segments of chunks… [0122] The variable segment sizing module 500 may compute an offset from the beginning of the data steam at block 506. The variable segment sizing module 500 may compute an offset that may be within a 4 kb to 16 kb range that may be used to find chunks. For example, the variable segment sizing module 500 may randomly compute an offset that may be within 4 kb 16 kb range from the beginning of the data stream. At block 508, may select a region for an analysis. The variable segment sizing module 500 may select a 16-byte region to determine if there is a natural break in the data stream. Step 500 may compute a region hash at block 510. The variable segment sizing module 500 may use a rolling hash to compute the region hash (e.g., Rabin-Karp, Rabin fingerprint, Cyclic fingerprint, Addler rolling hash, and/or some other type of rolling hash)… Examiner’s note: Thus, the system segments a stream of data into chunks and uses Rabin-Karp function as part of the chunking process). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Ponnala teachings in the Parekh system. Skilled artisan would have been motivated to incorporate segmenting data streams with Rabin-Karp taught by Ponnala in the Parekh system to improve the chunk segmenting and hashing of the chunks. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 11, Parekh teaches all of limitations of claim 1. Parekh does not explicitly teach wherein generating the respective chunk IDs includes: generating the respective chunk IDs using a SHA-256 function.
Ponnala teaches generating the respective chunk IDs using a SHA-256 function ([0082] The hashing algorithm described herein may include any method that can be used to map data of arbitrary size to fixed-size values. The values returned by a hash function may be called hash values, hash codes, digests, or hashes. The values may be used to index a fixed-size table called a hash table. In some cases, a cryptographic grade hash functions may be used to generate a fingerprint (chunk ID). The cryptographic grade hash function may be keyed, unkeyed, or use a combination thereof. The hash functions may be selected from the group consisting of SHA-0, SHA-1, SHA-2, SHA-3, SHA-224, SHA-256,…). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Ponnala teachings in the Parekh system. Skilled artisan would have been motivated to incorporate SHA-256 function in generating fingerprint for data chunks taught by Ponnala in the Parekh system to improve security and efficiency in creating chunk IDs/fingerprints. This close relation between both of the references highly suggests an expectation of success.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Parekh (US Patent 10,331,362) “Parekh” in view of Pandit et al. (US PGPUB 20230137443) “Pandit”.
Regarding claim 18, Parekh teaches all of limitations of claim 1. Parekh does not explicitly teach responsive to detecting a failure of a given transfer thread of the instantiated at least two transfer threads, restarting the given transfer thread.
Pandit teaches responsive to detecting a failure of a given transfer thread of the instantiated at least two transfer threads, restarting the given transfer thread ([0105] Failure Module 406A/406B: This module rehosts migrate operation threads if a failure is detected during the migrate operation… [0182] The method further includes undoing, by the processor, any tasks executed during a setup phase of the migrate operation, in response to a failure condition occurring during the setup phase; and restarting, by the processor, the migrate operation. The method also includes undoing, by the processor, any tasks executed during a transfer phase and a setup phase of the migrate operation, in response to a failure condition occurring during the transfer phase; and restarting, by the processor, the migrate operation… Examiner’s note: Thus, the system detects failure of a thread or processor relating to a transfer operation and restart the particular operation). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Pandit teachings in the Parekh system. Skilled artisan would have been motivated to incorporate restarting of failed transfer operation taught by Pandit in the Parekh system to improve operational efficiency of the system. This close relation between both of the references highly suggests an expectation of success.
Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bondureant (US PGPUB 20090013129) is directed to an embodiment for storing data on a removable storage cartridge where the chunk module breaks the original data stream into stream of data chunks. Once the chunk module creates the stream of chunks, the hash module calculates an identifier for each of the chunks. Different hash algorithms such as message digest algorithm (MD5), secure hash algorithm-1 (SHA-1), and secure hash algorithm-2 (SHA-2) may be used in various embodiments. The identifiers are then stored into an identifier database. A determination is made, as to whether each chunk is unique in that the same chunk has not been found in the previous chunks. The search module is used to determine if each chunk is unique by searching the identifier database. If the chunk is determined to be unique, the stream of unique chunks and descriptors are stored on the removable medium. If the chunk is not unique, the redundant data chunk is discarded and a reference to the existing unique chunk is created.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAO DANG VUONG whose telephone number is (571)272-1812. The examiner can normally be reached M-F 7:30-5 EST.
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.
/C.D.V./ Examiner, Art Unit 2153 07/23/2026
/KAVITA STANLEY/ Supervisory Patent Examiner, Art Unit 2153
Prosecution Insights