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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on May 10, 2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 12 is objected to because of the following informalities:
Claim 12 is directed towards a “computer program product of claim 7”, however claim 7 is part of a “method” claim set. The Examiner is interpreting the claim 12 to depend upon the claim set of independent claim 8 that is of a “computer program product”. For examination purposes, the Examiner is interpreting dependent claim to depend upon claim 11 as is consistent with dependent claims 5 and 19 that are similar in scope.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 6-10, 13-17, and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Arumugam et al, U.S. Patent 12,306,722.
As per claim 1, it is taught of a method (col. 25, lines 53-64) comprising:
creating a snapshot of a data volume (snapshots of a virtual machine are created from a distributed file system (i.e., data volume), wherein the virtual machine includes one or more files, col. 16, lines 29-39);
during the creating of the snapshot, calculating a checksum for each file being included in the snapshot (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49);
creating a string by concatenating the checksums by ascending order in the snapshot (one or more versions of a file is mapped to an earliest point in time as well as a latest point in time version snapshot, that is being interpreted as a concatenated string of checksums in ascending order in the snapshot, wherein the hash value (i.e., checksum) is generated based upon the inputs col. 15, lines 33-45; col. 20, lines 6-12; and col. 21, lines 20-32);
inputting the string to a linear aggregation method, and receiving an aggregation checksum signature (each transaction is added/inputted and is stored on a blockchain (i.e., linear aggregation method), wherein each transaction is signed with a digital signature that is added to each block forming a ledger (i.e., aggregation of the previous checksums/hashes that were previously computed and added to the blockchain), col. 20, lines 6-12 and col. 21, lines 20-32); and
storing the snapshot and snapshot metadata (the snapshot data is stored as a history of snapshots on the blockchain, col. 2, lines 11-21 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1).
As per claim 2, it is disclosed wherein the snapshot is immutable (snapshot is an immutable template file, col. 20, lines 62-65).
As per claim 3, it is taught wherein the stored snapshot includes metadata (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1), the metadata comprising the aggregation checksum signature (the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1 and each transaction is added/inputted and is stored on a blockchain (i.e., linear aggregation method), wherein each transaction is signed with a digital signature that is added to each block forming a ledger (i.e., aggregation of the previous checksums/hashes that were previously computed and added to the blockchain), col. 20, lines 6-12 and col. 21, lines 20-32), and each checksum and filename in the snapshot (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1, furthermore the metadata includes the name of a file, col. 15, lines 48-57).
As per claim 6, it is disclosed of further comprising connecting a first cloud storage with a second cloud storage (networked computing environment provides cloud based work productivity connected to cloud-based management systems, col. 5, lines 43-50).
As per claim 7, it is taught wherein the immutable snapshot is stored in a second cloud storage (the snapshots are stored in a cloud storage system, col. 23, lines 55-67).
As per claim 8, it is disclosed of a computer program product, the computer program product comprising a non-transitory tangible storage device having program code embodied therewith, the program code executable by a processor of a computer to perform a method (col. 25, lines 53-64), the method comprising:
creating a snapshot of a data volume (snapshots of a virtual machine are created from a distributed file system (i.e., data volume), wherein the virtual machine includes one or more files, col. 16, lines 29-39);
during the creating of the snapshot, calculating a checksum for each file being included in the snapshot (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49);
creating a string by concatenating the checksums by ascending order in the snapshot (one or more versions of a file is mapped to an earliest point in time as well as a latest point in time version snapshot, that is being interpreted as a concatenated string of checksums in ascending order in the snapshot, wherein the hash value (i.e., checksum) is generated based upon the inputs col. 15, lines 33-45; col. 20, lines 6-12; and col. 21, lines 20-32);
inputting the string to a linear aggregation method, and receiving an aggregation checksum signature (each transaction is added/inputted and is stored on a blockchain (i.e., linear aggregation method), wherein each transaction is signed with a digital signature that is added to each block forming a ledger (i.e., aggregation of the previous checksums/hashes that were previously computed and added to the blockchain), col. 20, lines 6-12 and col. 21, lines 20-32); and
storing the snapshot and snapshot metadata (the snapshot data is stored as a history of snapshots on the blockchain, col. 2, lines 11-21 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1).
As per claim 9, it is taught wherein the snapshot is immutable (snapshot is an immutable template file, col. 20, lines 62-65).
As per claim 10, it is disclosed wherein the stored snapshot includes metadata (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1), the metadata comprising the aggregation checksum signature (the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1 and each transaction is added/inputted and is stored on a blockchain (i.e., linear aggregation method), wherein each transaction is signed with a digital signature that is added to each block forming a ledger (i.e., aggregation of the previous checksums/hashes that were previously computed and added to the blockchain), col. 20, lines 6-12 and col. 21, lines 20-32), and each checksum and filename in the snapshot (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1, furthermore the metadata includes the name of a file, col. 15, lines 48-57).
As per claim 13, it is taught of further comprising connecting a first cloud storage with a second cloud storage (networked computing environment provides cloud based work productivity connected to cloud-based management systems, col. 5, lines 43-50).
As per claim 14, it is disclosed wherein the immutable snapshot is stored in a second cloud storage (the snapshots are stored in a cloud storage system, col. 23, lines 55-67).
As per claim 15, it is taught of a computer system, comprising:
one or more processors (col. 25, lines 53-64);
a memory coupled to at least one of the processors (col. 25, lines 53-64);
a set of computer program instructions stored in the memory and executed by at least one of the processors in order to perform actions (col. 25, lines 53-64) of:
creating a snapshot of a data volume (snapshots of a virtual machine are created from a distributed file system (i.e., data volume), wherein the virtual machine includes one or more files, col. 16, lines 29-39);
during the creating of the snapshot, calculating a checksum for each file being included in the snapshot (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49);
creating a string by concatenating the checksums by ascending order in the snapshot (one or more versions of a file is mapped to an earliest point in time as well as a latest point in time version snapshot, that is being interpreted as a concatenated string of checksums in ascending order in the snapshot, wherein the hash value (i.e., checksum) is generated based upon the inputs col. 15, lines 33-45; col. 20, lines 6-12; and col. 21, lines 20-32);
inputting the string to a linear aggregation method, and receiving an aggregation checksum signature (each transaction is added/inputted and is stored on a blockchain (i.e., linear aggregation method), wherein each transaction is signed with a digital signature that is added to each block forming a ledger (i.e., aggregation of the previous checksums/hashes that were previously computed and added to the blockchain), col. 20, lines 6-12 and col. 21, lines 20-32); and
storing the snapshot and snapshot metadata (the snapshot data is stored as a history of snapshots on the blockchain, col. 2, lines 11-21 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1).
As per claim 16, it is disclosed wherein the snapshot is immutable (snapshot is an immutable template file, col. 20, lines 62-65).
As per claim 17, it is taught wherein the stored snapshot includes metadata (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1), the metadata comprising the aggregation checksum signature (the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1 and each transaction is added/inputted and is stored on a blockchain (i.e., linear aggregation method), wherein each transaction is signed with a digital signature that is added to each block forming a ledger (i.e., aggregation of the previous checksums/hashes that were previously computed and added to the blockchain), col. 20, lines 6-12 and col. 21, lines 20-32), and each checksum and filename in the snapshot (when a snapshot is generated, a hash value (i.e., checksum) is generated based upon the inputs (i.e., each file included in the snapshot), col. 16, lines 60-65 and col. 19, lines 47-49 and the hash value corresponding to the metadata is stored on the blockchain, col. 16, line 63 through col. 17, line 1, furthermore the metadata includes the name of a file, col. 15, lines 48-57).
As per claim 20, it is disclosed of further comprising connecting a first cloud storage with a second cloud storage (networked computing environment provides cloud based work productivity connected to cloud-based management systems, col. 5, lines 43-50), wherein the immutable snapshot is stored in a second cloud storage (the snapshots are stored in a cloud storage system, col. 23, lines 55-67).
Allowable Subject Matter
Claims 4, 5, 11, 12, 18, and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
As per claims 4, 11, and 18 it is disclosed by Arumugam of further comprising:
restoring the snapshot based on one or more files of the data volume being corrupted (a restore command restores a point in time snapshot to correct a corrupted version of a file from the data volume, col. 6, lines 7-14; col. 16, lines 53-59; and col. 17, lines 1-3);
searching each previous snapshot for replacement versions of the one or more corrupted files that is not infected (before recovering the object, a hash value associated with the snapshot is retrieved from the blockchain and compared to the hash value that is to be used for recovery to determine if they match (i.e., not infected or is a clean and authentic version) to replace the corrupted file, col. 17, lines 3-10); and
in response to locating the replacement version, restoring the replacement version (if the located snapshot (i.e., replacement version) is verified or validated, it is used for replacement of the corrupted file, col. 17, lines 3-10).
The closest prior art teachings of Quan, U.S. Patent 11,397,645 discloses removing a to be deleted marker that has been added to a snapshot data object, see column 23, lines 21-22. However, Arumugam in view Quan, and the prior art fails to disclose based on a scan of the restored data volume detecting one or more corrupted files from a snapshot, deleting one or more corrupted files, and replacing the deleted file with a marker place holder.
Conclusion
The relevant art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kumar et al, U.S. Patent 11,360,856 is relied upon for disclosing of a public snapshot service can compute the checksum (e.g. Base64 encoded SHA256 checksum) by concatenating the checksums of all sub-blocks in the increasing order by their offsets and then computing checksum of the concatenated checksums, see column 32, lines 38-42.
Moore et al, GB 2640113 A is relied upon for disclosing of a system includes a snapshot triggering component for triggering an immutable snapshot including a flush prevention component for preventing an active storage write cache flush, see abstract.
George et al, U.S. Patent 12,393,488 is relied upon for disclosing of snapshot data of a snapshot may be backed up into objects that are stored from a node to an object store, such as a cloud computing environment. A tracking object is created to identify which objects within the object store comprise the snapshot data of the snapshot, see abstract.
Aseev et al, U.S. Patent 11,334,443 is relied upon for disclosing of a request for data to be restored is send to archive storage or to a snapshot storage from a restoration module. The data files are retrieved from archive storage, or from a data snapshot. The authentication parameters such as a hash sum of the data is calculated by the restoration module, and the calculated hash sum is compared to a corresponding hash sum stored in a blockchain network. This comparison is used to determine if the data is the same as when it was stored or if the data has been modified and compromised. If the calculated hash sum and the corresponding hash sum in the blockchain network are equivalent, the data is authenticated. In turn, such data can be restored by the restoration module. If the calculated hash sum and the corresponding hash sum in the blockchain network are not equivalent, the restoration of the data is canceled, see column 8, line 60 through column 9, line 9.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER REVAK whose telephone number is (571)272-3794. The examiner can normally be reached 5:30am - 3:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Catherine Thiaw can be reached at 571-270-1138. 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.
/CHRISTOPHER A REVAK/Primary Examiner, Art Unit 2407
Prosecution Insights