DETAILED ACTION
This office action is in response to the application filed on 07/28/2026. Claim(s) 1-2, 4-12, and 14-23 is/are pending and are examined. Claim(s) 3 and 13 are cancelled.
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 .
Response to Arguments
Applicant's arguments filed on 07/28/2026 have been fully considered but they are not persuasive for the following reasons:
Applicant' s Argument:
With regard to the generating claim element, the Office Action cites Yella's paragraphs 119 and 126.
With regard, to paragraph 119, the Office Action identifies Yella's another virtual disk as the claimed inspectable disk. That identification is not consistent with the teaching of Yella. Paragraph 119 expressly states that the newly created virtual disk has a tool to capture memory. The newly created disk is therefore a utility disk used to execute a memory-capture tool. It is not generated from the disk of the resource, but rather is generated independently to facilitate acquisition of RAM contents.
More specifically, paragraph 119 of Yella is really about capturing the contents of RAM, and it is not teaching or suggesting generating an inspectable disk from a disk as called for in the claim. In this regard, note that paragraph 119 is not describing the creation of a forensic copy of a resource disk. It is describing using a newly created utility disk to facilitate capturing RAM. First note that the first sentence of paragraph 119 explains what are the embodiments that are going to be described further in paragraph 119. This shows that the another virtual disk is essentially a memory capture tool which is attached to an instance to capture its memory. Nothing in that sequence says the newly created disk is generated from the disk of the resource, which is what is required by the claim language in that it specifically recites generating an inspectable disk from a disk of a resource from a disk of a resource.
It is clear from the claim language, and corroborated by the specification, that inspectable disk is a version of the resource disk itself, which is then mounted on the forensic analyzer for analysis. For example, the specification explains that the inspectable disk is mounted as a volume of the forensic analyzer and that the forensic finding is generated from analysis of the inspectable disk. Furthermore, the Office Action's parenthetical equating the another virtual disk of paragraph 119 to an inspectable disk is simply unsupported Office Action argumentation
(Applicant' s response filed on 07/28/2026, page 8-9).
Examiner' s Response:
The Examiner respectfully disagrees. While the example given in ¶ 119 of Yella does discuss the snapshot being of RAM early in Yella ¶ 97, “a virtual hard drive (or virtual hard disk drive (HDD)) is a software component that emulates a physical storage device such as a hard disk, optical disc drive, or a floppy disk drive, e.g., and is associated with a VM. In certain embodiments, virtual machine (VM) memory is a software component that emulates a physical random access memory (RAM), e.g., and is associated with a VM.” Which clearly establishes that virtual disk may contain a hard drive disk as such that portion of the limitation is taught by Yella. Further clarification that Yella does teach the claimed limitation can be seen in ¶ 113 of Yella, “The operations 1000 include, at block 1002, obtaining a list of one or more virtual instances that are to be analyzed. The operations 1000 further include, at block 1004, determining an operating system (e.g., and its version information) for the virtual instance(s), e.g., using API(s) of the cloud provider of that virtual instance. The operations 1000 further include, at block 1006, obtaining the virtual disk(s) information (e.g., a corresponding snapshot(s) thereof) of that virtual instance. The operations 1000 optionally include, at block 1008, taking a snapshot of the virtual hard disk(s) of that virtual instance (e.g., if it does not exist or if not latest (e.g., most current)). The operations 1000 further include, at block 1010, obtaining the virtual machine memory information (e.g., a capture of the RAM).” Which clearly states that a snapshot is taken of a virtual hard disk which as stated above is a disk and according to the applicant’s specification ¶ 29, “in an embodiment the inspectable disk 114 is generated in response to initiating a clone disk operation, which generates a clone of the disk 112. In some embodiments, the inspectable disk 114 is generated using a snapshot, copy, a clone, a combination thereof, and the like.”, clearly states that the snapshot of a disk is the claimed inspectable disk. As such Yella does teach the claimed limitation.
Applicant' s Argument:
In addition, with regard to paragraph 119 and also paragraph 126, it is clear that the object ultimately being is the memory captured by the tool on the newly created disk, not the newly created utility disk. In this regard, it appears that the utility disk merely carries the capture tool. The claims require the forensic analyzer to analyze content of the inspectable disk to generate the forensic finding, where the inspectable disk was generated from a disk of the resource, so that ultimately what is being analyzed is the content of the disk from which the inspectable disk was created. Such is not what is happening in paragraph 119. Rather, in paragraph 119, the content of the newly created disk, the memory-capture tool is not what is being analyzed. Instead, the tool is used to produce a separate memory capture, which may later be analyzed. Moreover, even if, arguendo, the memory that is captured is written to the virtual disk, such is still not a disk that is generated from a disk. Rather, that is a disk created from memory.
(Applicant' s response filed on 07/28/2026, page 9-10).
Examiner' s Response:
The Examiner respectfully disagrees. As is stated above clarification for the contents of the cited portion of ¶ 119 is expanded and further understood with ¶ 113, “The operations 1000 include, at block 1002, obtaining a list of one or more virtual instances that are to be analyzed. The operations 1000 further include, at block 1004, determining an operating system (e.g., and its version information) for the virtual instance(s), e.g., using API(s) of the cloud provider of that virtual instance. The operations 1000 further include, at block 1006, obtaining the virtual disk(s) information (e.g., a corresponding snapshot(s) thereof) of that virtual instance. The operations 1000 optionally include, at block 1008, taking a snapshot of the virtual hard disk(s) of that virtual instance (e.g., if it does not exist or if not latest (e.g., most current)). The operations 1000 further include, at block 1010, obtaining the virtual machine memory information (e.g., a capture of the RAM). The operations 1000 further include, at block 1014, attaching the virtual disk(s) and/or virtual machine memory information (e.g., snapshots and/or captures) to a trusted (e.g., virtual machine) instance (e.g., with the corresponding tools) for analysis” Where it is clear that a snapshot is being taken of a virtual hard disk and being shared for further analysis. As such it is clear that the snapshot is of a disk and is not just a memory capture tool to read memory, Yella as can be understood from the contents of ¶ 113 and ¶ 119 is able to perform both tasks for a more robust analysis of the various memory systems within the computing environment to uncover potential attacks within the system. As such Yella does teach the claimed limitation above.
Applicant's arguments with respect to amended claim(s) 1 and 10-11 have been fully considered but are moot in view of the new ground(s) of rejection.
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.
Claim(s) 1-2, 4-12, and 14-23 provisionally rejected on the ground of nonstatutory double patenting as being
unpatentable over Claim(s) 1-23 of co-pending Applications No. 18/179,194, and 18/179,202. Although the claims at issue
are not identical, they are not patentably distinct from each other for the following reason(s):
Claim 1 of co-pending U.S. Applications No. 18/179,194, and 18/179,202 is anticipated by the Claim(s) 1 of the instant application. This analysis is equally equivalent to Claim 11 of the co-pending U.S. Applications No. 18/179,194, and 18/179,202 in view of U.S. Application No. 16/128,485 and Claim(s) 10 and 11 of the instant application.
Claim(s) 2, 4-9, 12, 14-23 of the instant application are also rejected by virtue of their dependency from Claim 1 or 11. This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application
Co-pending Application: 18/179,202
A method for cybersecurity remediation based on a digital forensic finding, comprising: generating an inspectable disk from a disk of a resource deployed in a computing environment; mounting the inspectable disk at a mount point on a forensic analyzer; configuring the forensic analyzer to generate a forensic finding based on analysis by the forensic analyzer of content of the inspectable disk; and initiating a remediation action based on the forensic finding, wherein initiating the remediation action comprises generating, based on the forensic finding, an instruction that causes an inspector selected based on the forensic finding to inspect the inspectable disk for a cybersecurity object.
A method for iterative cybersecurity remediation based on a digital forensic finding, comprising:detecting a forensic finding, the forensic finding based on a forensic artifact detected on a disk of a resource in a computing environment;generating an inspectable disk based on the disk of the resource;inspecting the inspectable disk for a cybersecurity object based on the forensic artifact; andinitiating a remediation action on the disk based on the cybersecurity object detected on the inspectable disk.
10. A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process comprising: generating an inspectable disk from a disk of a resource deployed in a computing environment; mounting the inspectable disk at a mount point on a forensic analyzer; configuring the forensic analyzer to generate a forensic finding based on the inspectable disk; and initiating a remediation action based on the forensic finding based on analysis by the forensic analyzer of content of the inspectable disk; and initiating a remediation action based on the forensic finding, wherein initiating the remediation action comprises generating, based on the forensic finding, an instruction that causes an inspector selected based on the forensic finding to inspect the inspectable disk for a cybersecurity object.
10. A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process comprising:detecting a forensic finding, the forensic finding based on a forensic artifact detected on a disk of a resource in a computing environment; generating an inspectable disk based on the disk of the resource; inspecting the inspectable disk for a cybersecurity object based on the forensic artifact; and initiating a remediation action on the disk based on the cybersecurity object detected on the inspectable disk.
11. A system for cybersecurity remediation based on a digital forensic finding, comprising: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to: generate an inspectable disk from a disk of a resource deployed in a computing environment; mount the inspectable disk at a mount point on a forensic analyzer; configure the forensic analyzer to generate a forensic finding based on the inspectable disk; and initiate a remediation action based on the forensic finding based on analysis by the forensic analyzer of content of the inspectable disk; and initiating a remediation action based on the forensic finding, wherein initiating the remediation action comprises generating, based on the forensic finding, an instruction that causes an inspector selected based on the forensic finding to inspect the inspectable disk for a cybersecurity object.
11. A system for iterative cybersecurity remediation based on a digital forensic finding, comprising:a processing circuitry; anda memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to:detect a forensic finding, the forensic finding based on a forensic artifact detected on a disk of a resource in a computing environment;generate an inspectable disk based on the disk of the resource;inspect the inspectable disk for a cybersecurity object based on the forensic artifact; and initiate a remediation action on the disk based on the cybersecurity object detected on the inspectable disk.
U.S. Application 16/128,485
receive at least a plurality of process data from a next-generation endpoint protection software agent; analyze at least a portion of the process data; and transmit instructions to the next-generation endpoint protection software agent, the instructions being based at least in part on the results of the analysis.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 4-5 and 14-15 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim(s) 4-5 and 14-15 recites the limitation "an inspector" in line 2 which introduces ambiguity for this limitation in the claim. It is unclear if claims 4 and 14 are introducing a second inspector or are improperly introducing the same inspector recited in parent claim 1
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 7-14, 17-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yellapragada (US 2023/0208871 A1), hereinafter Yella in view of Mizrachi (US 2019/0028494 A1), hereinafter Mizrachi.
Regarding Claim(s) 1, 10, and 11 Yella teaches:
A method for cybersecurity remediation based on a digital forensic finding, comprising: (Yella ¶ 17 teaches, the present disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for predictive analysis of potential attack patterns based on contextual security information.)
generating an inspectable disk from a disk of a resource deployed in a computing environment; (Yella ¶ 119 teaches, (i) obtaining the ID of the instance(s) to be analyzed, (ii) creating another virtual disk (e.g., or a snapshot of a disk) that has a tool to capture memory, (i.e., inspectable disk). Yella ¶ 126 teaches, this includes preparing a sandbox environment where the artifacts are executed. In certain embodiments, this includes preparing an analyzer 822 virtual instance (e.g., as discussed in reference to FIGS. 11-12) that includes a corresponding analysis tool(s), e.g., where the processor attaches the artifacts to the analyzer instance(s). In certain embodiments, the analyzer(s) are running in the account where the security platform is running, e.g., where the artifacts are to be copied to or shared with the account of the security platform. (i.e., forensic analyzer))
mounting the inspectable disk at a mount point on a forensic analyzer; (Yella ¶ 119 teaches, (i) obtaining the ID of the instance(s) to be analyzed, (ii) creating another virtual disk (e.g., or a snapshot of a disk) that has a tool to capture memory, (i.e., inspectable disk) (iii) sharing/attaching this disk (e.g., or snapshot) with the instance(s) for which memory is to be captured (e.g., using the ID from (i)), (iv) mounting the attached virtual disk from within the instance(s) to be analyzed, (v) running the memory capture tool from the new disk against the instance(s) to be analyzed, and/or (vi) the memory capture can be directly analyzed using an additional tool(s) on the new disk (e.g., or the memory capture could be copied to a trusted source for further analysis).)
configuring the forensic analyzer to generate a forensic finding based on analysis by the forensic analyzer of content of the inspectable disk; and (Yella ¶ 136 teaches, the security platform described here also performs anomaly detection on network traffic associated with the monitored assets (e.g., where certain kinds of anomalies that are to be detected include unusual traffic targeted to the VM, unusual traffic targeted to particular services of the VM, suspicious user activity, and/or suspicious events such as security group changes), and any anomalous activity related to the VM is used to trigger the imaging process, e.g., where further analysis determines any malicious activity, and/or (iv) suspicious events such as network access changes, suspicious login activity, unauthorized access could be used as triggers for starting the imaging process. (i.e., forensic finding))
initiating a remediation action based on the forensic finding. (Yella ¶ 35 teaches, the countermeasures and/or remediations are enforced through the various security controls and/or tools existing in a particular environment.)
Yella does not appear to explicitly teach but in related art:
finding, wherein initiating the remediation action comprises generating, based on the forensic finding, an instruction that causes an inspector selected based on the forensic finding to inspect the inspectable disk for a cybersecurity object. (Mizrachi ¶31 and 37 teaches, A remediation server may then provide instruction to the NGEPP agent for handling any threats found (i.e., selecting an agent) During execution of an attack, malware often creates, modifies, or deletes system file or registry resources, or changes configuration settings. (i.e., remediation process) To handle these effects of an attack, a NGEPP agent may first detect a change, and then as part of a remediation process log the changes (i.e., inspecting) and send the log information to a remediation server for use in analyzing the threat. When remediation instructions are received, part of a remediation process then includes reversing the changes performed by the threat, returning any files or resources to their original state.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Yella with Mizrachi, to modify the system for vulnerability assessment for cloud assets of Yella with the inspecting agent of Mizrachi. The motivation to do so, Mizrachi ¶ 31, to perform host-based intrusion prevention and detection by monitoring files and processes.
Regarding Claim 2 and 12 Yella in view of Mizrachi teaches:
The method of claim 1, further comprising: (Yella in view of Mizrachi teaches the parent claim above.)
providing access to a forensic account for the forensic analyzer. (Yell ¶ 119 teaches, (ii), creating a machine image of the instance and share it with a trusted account (i.e., forensic account))
Regarding Claim 4 and 14 Yella in view of Mizrachi teaches:
The method of claim 3, further comprising: (Yella in view of Mizrachi teaches the parent claim above.) providing an inspector, configured to inspect for the cybersecurity object, access to the inspectable disk. ((Mizrachi ¶ 37 teaches, During execution of an attack, malware often creates, modifies, or deletes system file or registry resources, or changes configuration settings. (i.e., remediation process) To handle these effects of an attack, a NGEPP agent may first detect a change, and then as part of a remediation process log the changes (i.e., inspecting) and send the log information to a remediation server for use in analyzing the threat. When remediation instructions are received, part of a remediation process then includes reversing the changes performed by the threat, returning any files or resources to their original state.)
The motive given in Claim 1 is equally applicable to the above claim.
Regarding Claim 7 and 17 Yella in view of Mizrachi teaches:
The method of claim 1, wherein the forensic finding is any one of: (Yella in view of Mizrachi teaches the parent claim above.) a file containing metadata, a file containing content of a deleted file, a cookie, a content extracted from a cache memory, a content extracted from a cache storage, a website data, a disk image, a file attribute value, a record in a network log, a record in a cloud log, and any combination thereof. (Yella ¶ 119 teaches, (i) obtaining the ID of the instance(s) to be analyzed, (ii) creating another virtual disk (e.g., or a snapshot of a disk) that has a tool to capture memory, (i.e., inspectable disk) (iii) sharing/attaching this disk (e.g., or snapshot) with the instance(s) for which memory is to be captured (e.g., using the ID from (i)), (iv) mounting the attached virtual disk from within the instance(s) to be analyzed. ¶ 136 teaches, any anomalous activity related to the VM is used to trigger the imaging process, e.g., where further analysis determines any malicious activity, and/or (iv) suspicious events such as network access changes, suspicious login activity, unauthorized access could be used as triggers for starting the imaging process. (i.e., forensic finding of the mounted disk image))
Regarding Claim 8 and 18 Yella in view of Mizrachi teaches:
The method of claim 1, wherein the remediation action includes any one of: (Yella in view of Mizrachi teaches the parent claim above.)
generating a notification, generating a ticket in a ticketing system, adding a rule to a policy, updating a rule to a policy, deleting a cryptographic key, removing a permission associated with the resource, revoking network access to the resource, revoking network access from the resource, sandboxing the disk, and any combination thereof. (Yella ¶ 34 teaches, if the security platform 100 has determined that a web application firewall (WAF) is part of the network architecture, the remediation proposed is to have a rule that could be implemented through the WAF tool to prevent exploitation while the permanent fix is being developed and tested. (i.e., adding a rule))
Regarding Claim 9 and 19 Yella in view of Mizrachi teaches:
The method of claim 1, further comprising: (Yella in view of Mizrachi teaches the parent claim above.) spinning down the forensic analyzer and deprovisioning the inspectable disk, in response to determining that a forensic analysis of the inspectable disk is complete. (Yella ¶ 114 teaches, as part of continuous monitoring, the monitored list is amended based on whether each instance is active or suspended, new instances are being added, and/or instances are being deleted and/or terminated.)
Regarding Claim 20 Yella in view of Mizrachi teaches:
The method of claim 1, (Yella in view of Mizrachi teaches the parent claim above.) wherein the inspectable disk from the disk of the resource deployed in the. computing environment is a cloned disk created from the disk of the resource. (Yella ¶ 98 teaches, for such assets, a combination of the operating system, copy of the virtual hard disk(s), and a copy of the machine memory (e.g., RAM) defines the image of the assets.)
Regarding Claim 21 Yella in view of Mizrachi teaches:
The method of claim 1, (Yella in view of Mizrachi teaches the parent claim above.) wherein the inspectable disk from the disk of the resource deployed in the. computing environment is a disk created only from the disk of the resource. (Yella ¶ 102 teaches, the virtual hard disk might have one or more virtual snapshots associated with it, e.g., where the snapshot is a copy of the virtual hard disk at a certain point in time.)
Regarding Claim 22 Yella in view of Mizrachi teaches:
The method of claim 1, (Yella in view of Mizrachi teaches the parent claim above.) wherein initiating the remediation action based on the forensic finding is performed automatically. (Yella ¶ 35 teaches, the countermeasures and/or remediations are enforced through the various security controls and/or tools existing in a particular environment.)
Claim(s) 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yella in view of Mizrachi as applied to claim 1 above, and further in view of Maida (US 10,958,667 B1), hereinafter Maida.
Regarding Claim 5 and 15 Yella in view of Mizrachi teaches:
The method of claim 4, further comprising: (Yella in view of Mizrachi teaches the parent claim above.)
Yella in view of Mizrachi does not explicitly teach but in related art Maida:
generating a node in a security graph representing a cybersecurity threat corresponding to the cybersecurity object, in response to the inspector detecting a cybersecurity object on the inspectable disk, wherein the security graph includes a representation of the computing environment. (Maida Col. 3 Ln. 3-12 and 41-45 teaches, generate node graphs that represent computing systems, networks of computing resources, and/or other computing environments, and utilize the generated node graphs to identify and/or determine potential or current attacks and/or threats to the computing environments. the system and methods may access multiple threat artifacts associated with a network of computing resources, generate a single node graph for each of the multiple threat artifacts, build a composite node graph for the network of computing resources that represents a current threat status of the network of computing resources, identify one or more attacks to the network of computing resources based on an analysis of the composite node graph, and perform an action to mitigate the identified one or more attacks to the network of computing resources)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Yella in view of Mizrachi with Maida, to modify the system for vulnerability assessment for cloud assets of Yella with the inspecting agent of Mizrachi with the graph of Maida. The motivation to do so constitutes applying a known technique of displaying found threats to a system in a graph to known devices and/or methods for vulnerability assessments ready for improvement to yield predictable results a user being able to see a visual representation of the systems vulnerabilities.
Claim(s) 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yella in view of Mizrachi as applied to claim 1 above, and further in view of Dunn (US 2012/0179904 A1), hereinafter Dunn.
Regarding Claim 6 and 16 Yella in view of Mizrachi teaches:
The method of claim 1, further comprising: (Yella in view of Mizrachi teaches the parent claim above.)
generating the inspectable disk … (Yella ¶ 119 teaches, (i) obtaining the ID of the instance(s) to be analyzed, (ii) creating another virtual disk (e.g., or a snapshot of a disk) that has a tool to capture memory, (i.e., inspectable disk).)
Yella in view of Mizrachi does not appear to explicitly teach but in related art:
by re-encrypting the disk of the resource, wherein the disk is encrypted using a first key, and the inspectable disk is re-encrypted using a second key. (Dunn ¶ 45 teaches, one encrypted disk image 52 corresponds to one virtual machine 50, and is saved as a new encrypted disk image 52 when it shuts down. Alternatively, if no new data needs to be saved when virtual machine 50 is shut down, encrypted disk image 52 may be maintained permanently in cloud 22, and a new decrypted copy may be generated each time virtual machine 50 is launched, and simply discarded when virtual machine 50 is shut down. In that alternative, changing the encryption key requires explicitly deleting the encrypted disk image 52 and creating a new disk image 52 with the new key (not shown), or explicitly decrypting the disk image and re-encrypting it with the new key.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Yella in view of Mizrachi with Dunn, to modify the system for vulnerability assessment for cloud assets of Yella with the inspecting agent of Mizrachi with the encrypting and re-encrypting of a disk of Dunn. The motivation to do so constitutes applying a known technique to known devices and/or methods ready for improvement to yield predictable results.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2017/0289187 A1 - SYSTEM AND METHOD FOR VISUALIZING AND ANALYZING CYBER ATTACKS USING A GRAPH MODEL
US 2021/0303523 A1 - REPLICATING A FILE SYSTEM
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5: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, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights