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 .
Election/Restrictions
Claims 7-15 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected group, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 11/17/2025.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/17/2025 & 2/27/2025 were filed after the mailing date of the application on 1/17/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-6 and 16-29 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,229,010. Although the claims at issue are not identical, they are not patentably distinct from each other because both applications claim the same invention with very little differences in the claim language.
App. 19/030358
Pat. 12,229,010
1. A method comprising: receiving a request to perform a restore operation for a subset of data of a volume group backed up to an object store as a volume group backup composed of a plurality of constituent volume backups of a set of constituent volumes forming the volume group;
1. A method comprising: receiving a request to perform a restore operation for a volume group backed up to an object store as a volume group backup composed of a plurality of constituent volume backups of a set of constituent volumes forming the volume group;
evaluating a metafile to identify geometry information describing how the volume group is composed of the set of constituent volumes backed up to the object store as the plurality of constituent volume backups;
evaluating a metafile to identify geometry information describing how the volume group is composed of the set of constituent volumes backed up to the object store as the plurality of constituent volume backups;
generating a restore target based upon the geometry information;
generating a restore volume group comprising a set of restore constituent volumes according to the geometry information;
utilizing the metafile generate one or more constituent volume restore workflows; and
utilizing the metafile, comprising information related to the plurality of constituent volume backups and the volume group backup, to generate constituent volume restore workflows;
creating a group restore workflow to track and manage the constituent volume restore workflows;
implementing, by one or more nodes, the one or more constituent volume restore workflows to restore the subset of data of the volume group to the restore target.
executing, by a plurality of nodes, the constituent volume restore workflows to restore backup data from the plurality of constituent volume backups to the set of restore constituent volumes of the restore volume group, wherein a first node executes a first constituent volume restore workflow to restore a first consistent volume and a second node executes a second constituent volume restore workflow to restore a second constituent volume; and
in response to determining that the plurality of nodes successfully completed all constituent volume restore workflows to restore all restore constituent volumes of the restore volume group, indicating that the restore volume group has been successfully restored.
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 (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 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(s) 1, 4-5, 16, 28-19, 21, and 28-29 are rejected under 35 U.S.C. 103 as being unpatentable over Barnes et al (US Pub. 2015/0278034) (Eff filing date of app: 11/26/2014) (Hereinafter Barnes) and in view of Kuramkote et al (US Pub 2020/0128024) (Eff filing date of app: 10/19/2018) (Hereinafter Kuramkote).
As to claims 1, 16, and 21 Barnes teaches a method comprising:
receiving a request to perform a restore operation for a volume group backed up (see p. 4 and 11, “Many backup procedures use the file system as a starting point and perform the backup by writing the files to a backup storage system”) to an object store as a volume group backup composed of a plurality of constituent volume backups of a set of constituent volumes forming the volume group (see abstract, “Restoration of a backup of a first volume to a second volume on physical media.”);
evaluating a metafile to identify geometry information describing how the volume group is composed of the set of constituent volumes backed up to the object store as the plurality of constituent volume backups (see p. 93-95, “he volume identifier may be included to indicate for which volume the restore metadata is being used. In volumes where the restore metadata is stored on the volume, the volume identifier is implicit. However, the restore metadata may be stored in a file on another volume, with only a pointer to the restore metadata existing in the special boot identifier. In the case of a file, the volume identifier explicitly identifies which volume the restore metadata is for.”);
generating a restore target based upon the geometry information (see p. 93, “he restore
information block 460 comprise a set of restore metadata that may be used by a restore process”).
Barnes does not expressly teach utilizing the metafile generate one or more constituent
volume restore workflows; and implementing, by one or more nodes, the one or more constituent volume restore workflows to restore the subset of data of the volume group to the restore target.
Kuramkote teaches a method for securely facilitating data protection workflows and
devices, see abstract, in which he teaches utilizing the metafile generate one or more constituent volume restore workflows (see p. 43 and fig. 3, The backup service computing device 110 manages data protection workflows with registered ones of the node computing devices 106(1)-106(n), such as ingesting backup copies of data, cataloging the data, versioning, searching, and restore); and
implementing, by one or more nodes, the one or more constituent volume restore workflows to restore the subset of data of the volume group to the restore target (see p. 3-5, and 16, FIG. 4, in step 414, node computing device 106(1) executes instruction(s) received from a backup service computing device 110 to perform a data protection task. The instruction(s) can relate to the capture by the node computing device 106(1) of snapshots of volume 132(1), para 0062 and FIG. 4. The instruction(s) can be directed to another node computing device, e.g., node computing device 106(n). In this way, registration of only the node computing device 106(1) is required in order to manage data protection workflows for other node computing device in the same storage cluster, para 0063 and FIG. 4. Node computing devices 106(1)-106(n) can perform data storage in remote locations and cloud storage etc.,).
It would have been obvious to a person having ordinary skill in the art at the time the
invention was made to have modified Barnes by the teaching of Kuramkote, because utilizing the metafile generate one or more constituent volume restore workflows; and implementing, by one or more nodes, the one or more constituent volume restore workflows to restore the subset of data of the volume group to the restore target, would enable the method because, “the backup service can learn the topology of a storage cluster and manage data protection workflows via communications with one of the constituent nodes.” See abstract).
As to claims 4, 18, and 28, Barnes as modified teaches the method comprising:
incrementally restore the subset of data (see Barnes, p. 42, “Subsequent backups may also be incremental backups, each containing just the data for the blocks that were changed since the prior backup” and p. 58).
As to claims 5, 19, and 29, Barnes as modified teaches The method comprising:
restore a directory or qtree of the volume group as the subset of data (see Barnes, p. 57, “In addition, the discussion may relate to managing file and directory structures on storage volumes… references to files may include files, directories, and other similar data structures associated with mass storage devices.”).
Claims 2-3, 6, 17, 20, and 22-27 are rejected under 35 U.S.C. 103 as being unpatentable over Barnes in view of Kuramkote as applied above in claims 1, 4-5, 16, 28-19, 21, and 28-29 and further in view of George et al. (US Pub 2020/0285410) (Hereinafter George).
As to claims 2, 17, and 22, Barnes as modified does not teach the method comprising:
evaluating the metafile to identify:
a group root info object representing a volume group endpoint within the object store;
a constituent volume root info object per constituent volume endpoint within the object
store; and a group snapinfo object per constituent volume backup in the object store, wherein the
group snapinfo objects are populated with group properties of the volume group backup; and
utilizing the group root info object, the constituent volume root info objects, and the
group snapinfo object to generate the one or more constituent volume restore workflows.
George teaches transferring snapshot copy to object store with deduplication preservation, see abstract, in which he teaches a group root info object representing a volume group endpoint within the object store (p. 43, “A rel root object is derived from the UUID, which has pointers (names) to next level snapinfo objects.”);
a constituent volume root info object per constituent volume endpoint within the object
store (see George, p. 42, “A snapinfo object of a snapshot has a pointer to a root of a snapshot logical file system. A root object for each primary volume (e.g., a primary volume for which a snapshot is captured) is copied to the object store.”); and
a group snapinfo object per constituent volume backup in the object store, wherein the
group snapinfo objects are populated with group properties of the volume group backup (see George, p. 43, “a snapshot snapinfo is looked up within snapinfo objects”); and
utilizing the group root info object, the constituent volume root info objects, and the
group snapinfo object to generate the one or more constituent volume restore workflows (see George, p. 43, “A rel root object is derived from the UUID, which has pointers (names) to next level snapinfo objects. If a user is browsing a snapshot, a snapshot snapinfo is looked up within snapinfo objects. If no snapshot is provided, then latest snapshot info is used. The snapshot info has cloud block numbers for an inode file.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the scope of the invention of Barnes by the teaching of George, because a group root info object representing …, would enable the method because, “cost savings and scalability can be achieved by using a hybrid of primary storage systems and remote cloud computing storage..” See p. 2).
As to claim 3, Barnes as modified does not teach the method comprising:
restore a constituent volume or a single file of the volume group as the subset of data.
George teaches transferring snapshot copy to object store with deduplication preservation, see abstract, in which he teaches restore a constituent volume or a single file of the volume group as the subset of data (see p. 14, “a single file or any other amount of data can be restored”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the scope of the invention of Barnes by the teaching of George, because restore a constituent single file …, would enable the method save time in the process by restoring single file as a subset of data.
As to claims 6 and 20, Barnes as modified does not teach the method comprising:
restore the subset of data on-demand.
George teaches transferring snapshot copy to object store with deduplication preservation, see abstract, in which he teaches restore the subset of data on-demand (see p. 43, restoration orchestrating between client request and file system).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the scope of the invention of Barnes by the teaching of George, because restore the subset of data on demand…, would enable the method to instantly perform the process as needed.
As to claim 23, Barnes as modified teaches wherein the machine executable code causes the processor to:
evaluate the metafile to identify a constituent volume root info object per constituent volume endpoint within the object store; and utilize the constituent volume root info object to generate the one or more constituent volume restore workflows (see George, p. 42, “A snapinfo object of a snapshot has a pointer to a root of a snapshot logical file system. A root object for each primary volume (e.g., a primary volume for which a snapshot is captured) is copied to the object store.”).
The same motivation that was utilized for combining Barnes and George as set forth in claim 22 is equally applicable to claim 23.
As to claim 24, Barnes as modified teaches wherein the machine executable code causes the processor to:
evaluate the metafile to identify a group snapinfo object per constituent volume backup in the object store, wherein the group snapinfo objects are populated with group properties of the volume group backup (see George, p. 43, “a snapshot snapinfo is looked up within snapinfo objects”); and
utilize the group snapinfo object to generate the one or more constituent volume restore workflows (see George, p. 43, “A rel root object is derived from the UUID, which has pointers (names) to next level snapinfo objects. If a user is browsing a snapshot, a snapshot snapinfo is looked up within snapinfo objects. If no snapshot is provided, then latest snapshot info is used. The snapshot info has cloud block numbers for an inode file.”).
The same motivation that was utilized for combining Barnes and George as set forth in claim 22 is equally applicable to claim 24.
As to claim 25, Barnes as modified does not teach wherein the machine executable code causes the processor to:
George teaches transferring snapshot copy to object store with deduplication preservation, see abstract, in which he teaches restore a constituent volume of the volume group as the subset of data using a group root info object (see George, p. 43, “A rel root object is derived from the UUID, which has pointers (names) to next level snapinfo objects. …Data access can be used to restore a complete copy of a snapshot, part of a snapshot (e.g., a single file or directory), or metadata.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the scope of the invention of Barnes by the teaching of George, because restore a constituent volume of the volume group as the subset of data using a group root info object, would enable the method because, “cost savings and scalability can be achieved by using a hybrid of primary storage systems and remote cloud computing storage..” See p. 2).
As to claim 26, Barnes as modified teaches wherein the machine executable code causes the processor to:
restore a constituent volume of the volume group as the subset of data using a
constituent volume root info object (see George, p. 42, “A snapinfo object of a snapshot has a pointer to a root of a snapshot logical file system. A root object for each primary volume (e.g., a primary volume for which a snapshot is captured) is copied to the object store.” And p. 49, root info).
The same motivation that was utilized for combining Barnes and George as set forth in claim 25 is equally applicable to claim 26.
As to claim 27, Barnes as modified teaches wherein the machine executable code causes the processor to:
restore a constituent volume of the volume group as the subset of data using a
group snapinfo object (see George, p. 42, “Snapinfo objects comprise snapshot specific information. A snapinfo object of a snapshot has a pointer to a root of a snapshot logical file system” and p. 43, “A rel root object is derived from the UUID, which has pointers (names) to next level snapinfo objects. If a user is browsing a snapshot, a snapshot snapinfo is looked up within snapinfo objects. If no snapshot is provided, then latest snapshot info is used. The snapshot info has cloud block numbers for an inode file.”).
The same motivation that was utilized for combining Barnes and George as set forth in claim 25 is equally applicable to claim 27.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BELIX M ORTIZ DITREN whose telephone number is (571)272-4081. The examiner can normally be reached M-F 9am -5pm.
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, Amy Ng can be reached at 571-270-1698. 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.
BELIX M. ORTIZ DITREN
Primary Examiner
Art Unit 2164
/Belix M Ortiz Ditren/Primary Examiner, Art Unit 2164