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 .
Priority
This application is a continuation of U.S. Non-Provisional application Ser. No. 18/775,854, filed Jul. 17, 2024, now allowed, which is a continuation of U.S. Non-Provisional application Ser. No. 18/396,309 filed Dec. 26, 2023, now allowed, which itself is a continuation of U.S. Non-Provisional patent application Ser. No. 18/481,088 filed Oct. 4, 2023. The Ser. No. 18/481,088 application is itself a continuation in part of U.S. Non-Provisional patent application Ser. No. 17/664,508 filed on May 23, 2022, U.S. Non-Provisional patent application Ser. No. 18/146,074, filed Dec. 23, 2022, and U.S. Non-Provisional patent application Ser. No. 18/146,076, filed Dec. 23, 2022. The Ser. No. 18/146,074 and Ser. No. 18/146,076 applications claim priority from U.S. Provisional Patent Application No. 63/266,031 filed on Dec. 27, 2021.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/03/2025, 07/31/2025, 09/19/2025, 01/27/2026, 04/13/2026, and 06/19/2026 were filed along and after the mailing date of the Non-Provisional Patent Application on 02/03/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.
DETAILED ACTION
This Office Action is in response to a Non-Provisional Patent Application received on 02/03/2025. In the application, claims 1-19 have been received for consideration and have been examined.
Specification
Applicant’s submitted specification has been reviewed and found to be in compliance.
Drawings
Applicant’s submitted drawings have been reviewed and found to be in compliance.
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, 5, 8, 9, 10, 11, 15, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Shua, US 2022/0374520 A1 (“Shua”), in view of Dreier et al., US 2021/0405930 A1 (“Dreier”), and further in view of Chen, US 2018/0293374 A1 (“Chen”).
Regarding claim 1, the combination of Shua, Dreier, and Chen discloses:
A method for inspecting virtual instances in a cloud computing environment for cybersecurity threats comprising:
Shua discloses a cybersecurity scanning system for a cloud environment. The system accesses a block-storage volume belonging to a workload in a target cloud-storage environment and scans the volume from a secondary system (Shua ¶¶[0248], [0263]–[0268], [0271]–[0275]. Shua also identifies virtual machines and associated storage as cloud assets that may be scanned. Shua ¶¶[0081], [0094]–[0096]).
selecting a virtual instance in a cloud computing environment, wherein the virtual instance includes a disk having a disk descriptor with an address in a cloud storage system (Shua teaches accessing, through a cloud-provider API, a block-storage volume of a workload maintained in a target account of a cloud-storage environment. Shua ¶¶[0248], [0271]. Shua identifies virtual machines, storage, volumes, and snapshots among the cloud assets processed by the system. Shua ¶¶[0081]–[0082]).
Dreier teaches that source data resides in a source volume, that its metadata representation is identified using memory-address data, and that the metadata includes objects and reference information identifying the underlying source data (Dreier ¶¶[0151]–[0158]).
Thus, the combined teachings disclose or suggest a virtual-machine disk represented by metadata containing address or reference information identifying its cloud-stored data.
generating a cloned disk of the virtual instance by generating a cloned disk descriptor, the cloned disk descriptor having a data field including the address of the disk of the virtual instance (Shua teaches generating a snapshot of cloud storage, databases, and virtual machines. The snapshot may be produced by recording references to the underlying data blocks and using a copy-on-write operation. Shua ¶[0081]).
Dreier expressly teaches creating a copy or snapshot of a volume by creating metadata objects without duplicating the underlying data objects (Dreier ¶¶[0126]–[0128]. More particularly, Dreier generates a metadata object in a target volume containing a reference to the metadata representation of source data in the source volume. The metadata object corresponds to the memory-address range of the source data. Dreier ¶¶[0191]–[0193]). The created target-volume metadata object therefore corresponds to the claimed cloned-disk descriptor, while its reference to the source-volume memory-address range corresponds to the claimed data field containing the original disk address.
inspecting the cloned disk for a cybersecurity object (Shua performs vulnerability scanning against a snapshot, including extracting operating-system packages, installed software, libraries, and other objects and comparing them against known vulnerabilities. Shua ¶¶[0094]–[0095]. Shua also performs malware scanning across the filesystems of the snapshot and uses signatures, heuristics, hashes, whitelists, and sandboxing to detect malicious code. Shua ¶¶[0096], [0263]–[0267], [0274]–[0275]).
initiating remediation on the disk of the virtual instance, in response to detecting the cybersecurity object on the cloned disk (Shua teaches implementing a remedial action in response to identified vulnerabilities, including applying a cybersecurity patch, notifying an end user, recording the threat, or communicating the vulnerability to the server operator. Shua ¶¶[0202]–[0203]).
A person of ordinary skill in the art would have been motivated to implement Shua’s snapshot-based cloud-disk inspection using Dreier’s metadata-reference copying technique because both references concern making a separately accessible representation of storage data. Dreier expressly teaches that its approach: creates a snapshot or volume copy without actual duplication of the underlying data objects; makes the copied volume accessible in constant-order time; and permits the target volume to access the source data through a metadata object containing a reference to the source-volume metadata.
To the extent the combination of Shua and Dreier do not expressly disclose initiating remediation directly on the original disk, Chen teaches that, after a security inspection service detects a threatening modification, it issues an instruction causing the container engine to roll back the modification and restore an earlier snapshot of the persistent-storage layer (Chen ¶¶[0022], [0039]. Chen additionally teaches terminating the affected container and validating elimination of the threat by rescanning the host and persistent storage. Chen ¶¶[0040], [0044]. Applied to Shua’s target workload, Chen therefore teaches initiating remediation on the original workload storage in response to the cybersecurity object detected through inspection).
Shua already recognizes that detected vulnerabilities should produce remedial action. Shua ¶¶[0202]–[0203]. Chen provides specific automated responses to such detected threats, including rollback of malicious modifications, restoration of a clean snapshot, quarantine, termination, and subsequent validation. Chen ¶¶[0022], [0038]–[0040], [0044].
A person of ordinary skill would have been motivated to incorporate Chen’s automated remediation into Shua’s inspection system to promptly remove or neutralize a detected cybersecurity threat; restore affected persistent storage to a known safe state; reduce the delay and risk associated with exclusively manual intervention; and confirm that the threat was successfully removed.
The combination represents the predictable use of a known automated-remediation technique following Shua’s known detection of vulnerabilities or malicious code.
Regarding claim 10, it is a non-transitory computer-readable medium claim and recite similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 11, it is a system claim and recite similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 5, the combination of Shua, Dreier, and Chen, disclose:
The method of claim 1, further comprising:
dereferencing a pointer of the disk of the virtual instance; and generating a pointer for the cloned disk descriptor based on the dereferenced pointer of the disk of the virtual instance (Dreier teaches obtaining reference information identifying the source data and its address range and using that information to generate a reference in a target-volume metadata representation. Dreier ¶¶151–158. Dreier further teaches generating a reference within the target volume to the source-volume metadata representation and creating a metadata object corresponding to the source-data address range. Id. ¶¶191–193. Determining the source metadata representation or storage range identified by the original reference constitutes dereferencing the original pointer. Generating the target metadata reference to that identified representation constitutes generating the cloned-disk pointer based on the dereferenced source pointer).
It would have been obvious to employ this technique in Shua’s inspection copy because it permits the cloned disk to access the same source blocks without duplicating the blocks, thereby reducing clone-creation time and storage consumption.
Regarding claim 15, it is a system claim and recite similar subject matter as claim 5 and therefore rejected under similar ground of rejection.
Regarding claim 8, the combination of Shua, Dreier, and Chen disclose:
The method of claim 1, wherein the cybersecurity object indicates a cybersecurity threat (Shua teaches detecting malware and malicious code in a block-storage volume and generating a notification identifying the malicious-code target. Shua ¶¶263–268. Malware or malicious code is a cybersecurity object that indicates a cybersecurity threat.
Shua also teaches identifying cybersecurity vulnerabilities and connecting the identified security risk to an asset in the cloud environment. Id. ¶¶352–358).
Thus, Shua expressly teaches, or at minimum renders obvious, using the detected cybersecurity object as an indication of a cybersecurity threat.
Regarding claim 18, it is a system claim and recite similar subject matter as claim 8 and therefore rejected under similar ground of rejection.
Regarding claim 9, the combination of Shua, Dreier, and Chen disclose:
The method of claim 1, further comprising:
inspecting the cloned disk for a second cybersecurity object, wherein the cybersecurity object and the second cybersecurity object indicate together a cybersecurity threat (Shua teaches identifying a plurality of cybersecurity vulnerabilities and correlating the vulnerabilities with cloud assets. Shua ¶¶352–358. Shua further teaches aggregating multiple sources of cybersecurity risk information, displaying multiple risks and risk paths for a storage volume, and performing a visualization or analysis for “a combination of risks.” Id. ¶¶452–460, particularly ¶460).
It would have been obvious to apply Shua’s risk aggregation to two objects detected during the cloned-disk inspection and determine that their combination indicates a cybersecurity threat. Combining individual findings is a predictable cybersecurity technique because multiple conditions—such as a vulnerability combined with an exposed credential—may jointly establish an exploitable threat even when either finding alone receives a lower risk classification.
Regarding claim 19, it is a system claim and recite similar subject matter as claim 9 and therefore rejected under similar ground of rejection.
Claim(s) 2-3, 6-7, 12-13, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Shua, US 2022/0374520 A1 (“Shua”), in view of Dreier et al., US 2021/0405930 A1 (“Dreier”), in view of Chen, US 2018/0293374 A1 (“Chen”) and further in view of Veselov, US11,216,563 B1 (“Veselov”).
Regarding claim 2, the combination of Shua, Dreier, and Chen does not disclose:
The method of claim 1, further comprising:
releasing the cloned disk in response to completing the inspection of the cloned disk.
However, Veselov discloses:
releasing the cloned disk in response to completing the inspection of the cloned disk (performing a security assessment on a logical-volume snapshot or virtualized reproduction and, after producing or storing the assessment results, deleting the snapshot. See Veselov, col. 3, l. 55–col. 4, l. 10; see also the discussion accompanying Figs. 1–3B. Specifically, Veselov states that the scanning system may store or provide the assessment results and “may then delete the snapshot.”)
Shua likewise generates and tags an inspection snapshot and configures the scanning system to delete snapshots having the scanning-system tag. Shua ¶¶81–82.
It would have been obvious to release the cloned disk after the inspection was completed taught by Shua in view of Dreier, and further in view of Chen, as taught by Veselov, to reclaim cloud-storage resources, prevent stale inspection copies from accumulating, and reduce storage expense. Deleting or releasing Dreier’s metadata-based virtual copy would release the cloned disk without affecting the source disk.
Regarding claim 12, it is a system claim and recite similar subject matter as claim 2 and therefore rejected under similar ground of rejection.
Regarding claim 3, the combination of Shua, Dreier, and Chen discloses:
The method of claim 1, further comprising:
releasing the cloned disk prior to the cloud computing environment copying a content of the disk of the virtual instance into the cloned disk (Dreier teaches that a volume may be copied by creating a new metadata representation referencing an existing source-volume representation, without actual duplication of the source data. Dreier ¶¶125–128. Actual duplication is deferred until a subsequent write under the disclosed copy-on-write arrangement. Id. ¶126).
Veselov teaches releasing the inspection copy after completing the assessment (Veselov, col. 3, l. 55–col. 4, l. 10).
Applying Veselov’s post-inspection deletion to Dreier’s metadata-reference clone would result in the clone being released after inspection but before source content is copied into the clone, particularly where the inspection performs read operations and no write triggers copy-on-write duplication.
A person of ordinary skill would have done so to avoid unnecessary copying after the temporary inspection copy had served its purpose. This is a predictable use of Dreier’s reference-based clone and Veselov’s post-inspection cleanup.
Regarding claim 13, it is a system claim and recite similar subject matter as claim 3 and therefore rejected under similar ground of rejection.
Regarding claim 6, the combination of Shua, Dreier, and Chen disclose:
The method of claim 1, wherein inspecting the cloned disk for the cybersecurity object further comprises:
inspecting the cloned disk for any one of: an exposure, a vulnerability, a malware, a ransomware, a spyware, a bot, a weak password, an exposed password, an exposed certificate, a misconfiguration, a suspicious event, and any combination thereof (Shua teaches scanning snapshots and block-storage volumes for vulnerabilities and malware. Shua ¶¶94–96, 263–267. Shua explains that the malware scan can examine filesystems associated with virtual machines and storage devices using signatures, heuristic analysis, and sandboxing. Id. ¶96. Shua also outputs vulnerability, configuration, malware, risk-analysis, and sensitive-information metadata from block-storage scans. Id. ¶¶352–358.
Veselov separately teaches security assessments using CVE rules, CIS benchmarks, configuration assessments, static analysis, and runtime analysis. Veselov, col. 2, ll. 45–67).
Because claim 6 requires only “any one of” the enumerated objects, Shua’s express inspection for malware or vulnerabilities is sufficient. Extending the inspection to configuration weaknesses and other known security indicators would also have been an obvious use of known security-assessment rules.
Regarding claim 16, it is a system claim and recite similar subject matter as claim 6 and therefore rejected under similar ground of rejection.
Regarding claim 7, the combination of Shua, Dreier, and Chen disclose:
The method of claim 1, further comprising:
deprovisioning the cloned disk descriptor, in response to completing inspection (Dreier teaches that its virtual copy is represented by a created metadata object rather than a complete physical duplicate. Dreier ¶¶125–128, 191–193. Thus, the metadata object is the structure that provisions the virtual copy.
Veselov teaches deleting the inspection snapshot after the security assessment and associated results are completed. Veselov, col. 3, l. 55–col. 4, l. 10. Shua similarly teaches tagging inspection snapshots and configuring the scanner to delete tagged snapshots. Shua ¶82).
When Veselov’s deletion is applied to Dreier’s metadata-created clone, deletion or invalidation of the clone’s metadata object deprovisions the cloned-disk descriptor.
A skilled artisan would have done this to reclaim metadata and storage resources and prevent later access through an obsolete inspection descriptor.
Regarding claim 17, it is a system claim and recite similar subject matter as claim 7 and therefore rejected under similar ground of rejection.
Claim(s) 4, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Shua, US 2022/0374520 A1 (“Shua”), in view of Dreier et al., US 2021/0405930 A1 (“Dreier”), in view of Chen, US 2018/0293374 A1 (“Chen”) and further in view of Xie, US 2022/0407685 A1 (“Xie”).
Regarding claim 4, the combination of Shua, Dreier, and Chen disclose:
Claim 4 recites generating “a pointer for the cloned disk descriptor to an encryption key,” where the key encrypts the original disk.
Shua teaches accessing keys from cloud keystores and using the retrieved keys to encrypt cloud-infrastructure snapshots (Shua ¶¶80–82).
Dreier teaches creating the target or cloned volume as a new metadata object or descriptor that references source-volume information (Dreier ¶¶125–128, 191–193).
The combination of Shua, Dreier, and Chen does not disclose:
virtual-disk descriptor files that reference corresponding virtual-disk objects transmitting a KEK identifier and KMS addressing information to hosts.
However, Xie discloses:
virtual-disk descriptor files that reference corresponding virtual-disk objects and teaches transmitting a KEK identifier and KMS addressing information to hosts (Xie, description of Fig. 1 concerning virtual-disk descriptor files; Fig. 2, steps 212–218; Fig. 5, blocks 510–516; claims 5–6 and 14–15. The KEK identifier functions as a pointer because it identifies and is used to retrieve the corresponding encryption key from the KMS).
It would have been obvious to include in the cloned-disk metadata the key identifier or other reference identifying the key used for the source disk. This would allow the scanner to access and decrypt the encrypted source blocks referenced by the cloned descriptor while avoiding duplication of secret key material. The modification represents the predictable application of VMware’s key-reference arrangement to Dreier’s metadata-based clone.
Regarding claim 14, it is a system claim and recite similar subject matter as claim 4 and therefore rejected under similar ground of rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6:00 PM.
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, William Korzuch can be reached at 571-272-7589. 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.
/SYED M AHSAN/Primary Examiner, Art Unit 2491
Prosecution Insights