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 .
Detailed Action
Office Action is in response to the reply by Applicant filed on 8/13/2026. Claims 1-19 are pending. This Office Action is Final.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 8/13/2026, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
A) Applicant’s arguments regarding Claim 1 and the 35 USC 101 rejection for being an Abstract idea has been considered and deemed not persuasive. Under the 2-prong analysis, Step 2A is that the claims as written could be a performed using mental steps. Applicant’s limitations recite steps that can still be performed in the mind. For example, deploying a sensor on a workload, detecting an event, inspecting code, associating a runtime process and generating an event. Examiner deems that these steps can all be performed mentally or with the help of a generic computer.
Further, with respect to Step 2B, is that the claims do not contain any improvement to the current technology. As previously stated above, Examiner deems that the claims can all be performed by a generic computer. And that there is nothing argued that these needs to be done by a special computer that requires special hardware components which would be required to perform the mental steps. The claim language and limitations setup for a detecting of a runtime process associated with an event and generating an enriched event in response. Examiner does not see in the limitations as written a practical application. The limitation of generating an enriched event is vague, and the claim would benefit with an amendment to further explain what an enriched event is. As a result, the 35 USC 101 rejection for Abstract Idea stands.
B) Applicant argues that Aziz fails to disclose, teach or even suggest “deploying a sensor on a workload in a cloud computing environment, the sensor configured to detect a runtime process utilizing an identity on the workload from runtime data of the workload,” as recited in claim 1. Examiner respectfully disagrees.
Examiner submits that Aziz teaches the limitations above. Applicant argues “A monitor inside a malware-analysis virtual machine that observes the behavior of
an object under analysis is not the claimed sensor deployed on a cloud workload.” Unfortunately, Examiner does not find this persuasive. Examiner finds that Aziz’s monitoring of virtual machines with software components, is synonymous with recited limitations. Aziz’s Virtual machines are connected by cloud computing and the monitoring software components appear to be very similar with the recited sensor. Perhaps limitations to make a distinction between the sensor and monitoring software components would be proper. However, at this time, Examiner finds that Aziz teaches the limitations argued above.
C) Applicant argues that Joyce fails to disclose, teach or even suggest “detecting in a log of the cloud computing environment an event based on an identifier of the workload, the log including a plurality of events; inspecting a code object for the identity, the code object utilized in deploying the workload in the cloud computing environment; and associating the runtime process with the event based on an identifier of the workload and the identity,” as recited in claim 1. Examiner respectfully disagrees.
Examiner submits that Aziz teaches the limitations above. Applicant argues:
First, Joyce does not disclose detecting an event in a cloud-computing log based
on an identifier of a workload. Examiner’s cites Joyce, to teach the above limitation. While the cited portion does not explicitly recite the term “log,” Examiner relies on the runtime analysis, which one of ordinary skill in the art would know that log data is typically part of the runtime analysis.
Second, Joyce does not disclose inspecting a code object for an identity, where
that code object was used to deploy the workload. Examiner feels that Joyce’s static analysis is explicit in teaching the inspection of code data, “agent/test modules 12 may include static analysis tools, system state monitors, active monitors, platform configuration test modules, and external probes. The static analysis tools are operable to analyze any available application or library source code for processes that are executable on runtime computing systems 20”.
Third, Joyce does not disclose associating a runtime process with a cloud-log
event based jointly on a workload identifier and an identity. Examiner’s interpretation of this language is that when runtime analysis is being performed, one of ordinary skill in the art would know that when a runtime process is deemed to raise any flags from the analysis then it would be identified. Again, as argued above the log portion is part of the analysis process. As a result, Joyce teaches the limitations argued above.
D) Applicant argues that Mantin fails to disclose, teach or even suggest “generating an enriched event based on an identifier of the runtime process associated with the event and an identifier of the identity,” as recited in claim 1. Examiner respectfully disagrees.
Examiner submits that Mantin teaches the limitations above. Applicant argues:
Mantin's enriched audit logs concern API traffic. The cited passage explains that such logs may include information about data types in API responses and users associated with the API traffic. As Examiner has argued above in the 101 argument response, as written the term “enriched event,” is open to interpretation. Mantin is creating an enriched log in response to a detection. Which Examiner feels reads on the recited limitations. As a result, Mantin teaches the limitations argued above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 5-11, 15-19 are rejected under 35 USC 101 as being directed to an abstract idea without being integrated into a practical application or being significantly more.
Regarding claims 1, 10 and 11, the claim recites the limitations “detecting in a log …;” “inspecting a code …”. “associating the runtime process with the event …” and “generating an enriched event …” Broadly interpreted, the aforementioned steps are directed to mental processes as said steps could be performed in the human mind. Therefore, the claims recite an abstract idea.
Said abstract idea and/or judicial exception is not integrated into a practical application as the claim does not recite any other active steps that could be considered that the abstract idea is being integrated into a practical application. It’s noted that the claim recites the operations “deploying a sensor …” and “generating an enriched event …”. However, said operations are not sufficient to consider that the abstract idea is being interpreted into a practical application. Said operations are recited at a high level of generality in gathering/processing/storing information, which are a form of insignificant extra-solution activity.
It’s also noted that the claims recite additional limitation/elements (i.e., system, processing circuitry, processor, memory, etc.,). However, said additional elements are recited at a high-level of generality (i.e., as a generic computing device performing a generic computer functions) such that it amounts no more than mere instructions to apply the exception or abstract idea using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements/limitations/embodiments that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea. As mentioned above, although the claims recite additional elements, said elements taken individually or as a combination, do not result in the claim amounting to significantly more than the abstract idea because as the additional elements perform generic computer content distributing functions routinely used in information technology field. As discussed above, the additional elements recited at a high-level of generality such that they amount no more than mere instructions to apply the exception using a generic computer component. Therefore, the claim is directed to non-statutory subject matter.
Regarding claims 5-9 and 15-19, claims 5-9 and 15-19 are also rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter for the same reasons addressed above as the claims recite an abstract idea and the claims do not positively recite any other operations that could be considered as the abstract idea is being integrated into a practical application or significantly more. It’s noted that claims 5-9 recites the limitations: “detecting in the log …”, “accessing an infrastructure” and “matching ….” Said steps are either directed to mental processes and/or in a form of insignificant extra-solution activities; The aforementioned steps are not sufficient to consider that the abstract idea is being integrated into a practical application or significantly more. Therefore, claims 5-9 and 15-19 are also rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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, 10 and 11 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 10 and 11 of U.S. Patent No. 12,225,037. Although the claims at issue are not identical, they are not patentably distinct from each other because all the limitations of claims 1, 10 and 11 of the instant Application are anticipated by the limitations recited in 1, 10 and 11 of U.S. Patent No. 12,225,037.
Regarding claims 2-9 and 12-19; claims 2-9 and 12-19 are also rejected under Double Patenting for similar reasons respectively and are dependent on claims 1, 10 and 11 and therefore inherit the rejection from issues of the independent claims.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-5, 7-15 and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Aziz et al (US 10,462,173) in view of Joyce et al. (US 10,558,809) and Mantin et al. (US 10,917,401).
As per claim 1, Aziz teaches method for associating an event in a cloud computing log to a process running on a workload, comprising: deploying a sensor on a workload in a cloud computing environment, the sensor configured to detect a runtime process utilizing an identity on the workload from runtime data of the workload (Aziz, Col. 12 Lines 1-10 recites “Each of the one or more virtual machine(s) 360 may further include one or more monitors (not separately shown), namely software components that are configured to observe, capture and report information regarding run-time behavior of an object under analysis during processing within the virtual machine. The observed and captured run-time behavior information as well as effects on the virtual machine, otherwise known as features, along with related metadata may be provided to a scoring logic 370.”).
But fails to teach detecting in a log of the cloud computing environment an event based on an identifier of the workload, the log including a plurality of events; inspecting a code object for the identity, the code object utilized in deploying the workload in the cloud computing environment; associating the runtime process with the event based on an identifier of the workload and the identity.
However, in an analogous art Joyce teaches detecting in a log of the cloud computing environment an event based on an identifier of the workload, the log including a plurality of events; inspecting a code object for the identity, the code object utilized in deploying the workload in the cloud computing environment; associating the runtime process with the event based on an identifier of the workload and the identity (Joyce, Col. 6 Line 63 – Col. 7 Line 18 recites “Risk analysis module 10 utilizes the information provided by test agents 12 based on the monitoring of runtime computing systems 20. Using the information provided by import/export module 14 and test agents 12, risk analysis module 10 is capable of performing risk modeling and analysis operations to determine whether events are occurring, have occurred, potentially may occur, identify any potential vulnerabilities, risks, or malicious code (e.g., malware) associated with execution of processes in runtime computing systems 20, and so on. Risk analysis module 10 may utilize graphical user interface module 8 to provide graphical representations, such as graphical representations of vulnerabilities and risks, within a graphical user interface that is output to a user (e.g., analyst). Based on the output provided by GUI module 8, a user may determine what corrective or preventive actions to take. In some examples, such actions make take place in a software development process (e.g., modifying code or configuration information to mitigate or eliminate such vulnerabilities or risks), by updating software, making configuration changes, removing system nodes from distributed computing system 3, and so on.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Joyce’s Software Assurance For Heterogeneous Distributed Computing Systems with Aziz’s Malware Detection Verification And Enhancement By Coordinating Endpoint And Malware Detection Systems because it offers the advantage of thoroughly analysis events to prevent the spread of malicious code to the connected system.
And fails to teach generating an enriched event based on an identifier of the runtime process associated with the event and an identifier of the identity.
However, in an analogous art Mantin teaches generating an enriched event based on an identifier of the runtime process associated with the event and an identifier of the identity (Mantin, Col. 8 Lines 20-44 recites “The enriched log generator component 160 generates enriched audit logs for API traffic. The enriched logs may log information regarding the data types of the data values included in the API traffic (e.g., as determined by the data type detection component 150). In some embodiments, the enriched audit logs also log information regarding the users associated with the API traffic (e.g., as determined by the user detection component 155). In one embodiment the enriched audit logs log, for each API response, at least a timestamp for that API response, information regarding the user associated with that API response, and the number of data values having a given data type included in that API response. In one embodiment, the enriched audit logs log the actual data values included in the API response (e.g., if those data values are not considered sensitive) and/or masked versions of the data values included in the API responses (e.g., if those data values are considered sensitive (e.g., passwords, social security number, and/or other personal/sensitive information)). The enriched audit logs are enriched in the sense that they include additional information (e.g., information regarding the data types of the data values included in the API traffic and/or the users associated with the API traffic) that is typically not included in standard audit logs.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date to use Mantin’s Data Leakage Prevention Over Application Programming Interface with Aziz’s Malware Detection Verification And Enhancement By Coordinating Endpoint And Malware Detection Systems because it offers the advantage of a log that has additional data or metadata added to it to provide more context and clarity.
As per claim 2, Aziz in combination with Joyce and Mantin teaches the method of claim 1, Mantin further teaches configuring the sensor to detect a cloud API call, the cloud API call including an identifier of the identity (Mantin, Col. 8 Lines 20-44 recites “The enriched log generator component 160 generates enriched audit logs for API traffic. The enriched logs may log information regarding the data types of the data values included in the API traffic (e.g., as determined by the data type detection component 150). In some embodiments, the enriched audit logs also log information regarding the users associated with the API traffic (e.g., as determined by the user detection component 155). In one embodiment the enriched audit logs log, for each API response, at least a timestamp for that API response, information regarding the user associated with that API response, and the number of data values having a given data type included in that API response. In one embodiment, the enriched audit logs log the actual data values included in the API response (e.g., if those data values are not considered sensitive) and/or masked versions of the data values included in the API responses (e.g., if those data values are considered sensitive (e.g., passwords, social security number, and/or other personal/sensitive information)). The enriched audit logs are enriched in the sense that they include additional information (e.g., information regarding the data types of the data values included in the API traffic and/or the users associated with the API traffic) that is typically not included in standard audit logs.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Mantin’s Data Leakage Prevention Over Application Programming Interface with Aziz’s Malware Detection Verification And Enhancement By Coordinating Endpoint And Malware Detection Systems because it offers the advantage of a log that has additional data or metadata added to it to provide more context and clarity.
As per claim 3, Aziz in combination with Joyce and Mantin teaches the method of claim 1, Aziz further teaches detecting a disk of the workload; generating an inspectable disk based on the detected disk; inspecting the inspectable disk to detect a cybersecurity object; and storing a representation of the workload, a representation of the identity and a representation of the event in a security database (Aziz, Col. 20 Lines 26-52 recites “In step 812 the security logic engine, in response to receiving an indication of suspiciousness from the processing of the object by the endpoint, triggers the processing of the object by a malware detection system. The security logic engine may receive, from the endpoint (directly via a communication interface or indirectly via one or more intermediary devices such as a USB flash drive, network connected appliance, etc.) the object or an object identifier that may be used to retrieve the object. The indication of suspiciousness received by the security logic engine from the endpoint may result from applying a heuristic, at the endpoint, to features detected during processing of the object by the endpoint. In some embodiments, the indication of suspiciousness may result from a correlation of the features detected, during processing by the endpoint, with known malicious or benign objects. The SLE may receive from the endpoint an indication of suspiciousness resulting from a heuristic or correlation of the features detected, employed at the endpoint, and an identifier of the object or the object itself. The SLE may send a message to trigger, in step 815, in response to receiving the indication of suspiciousness, a malware detection system to process the object in a monitored runtime environment such as a virtual machine. The security logic engine may provide the object (or the object identifier) to the static analysis logic 320 and to dynamic analysis logic 340 of the malware detection system so that the object may be processed.”).
As per claim 4, Aziz in combination with Joyce and Mantin teaches the method of claim 3, Joyce further teaches initiating a mitigation action in response to detecting the cybersecurity object (Joyce, Col. 6 Line 63 – Col. 7 Line 18 recites “Risk analysis module 10 utilizes the information provided by test agents 12 based on the monitoring of runtime computing systems 20. Using the information provided by import/export module 14 and test agents 12, risk analysis module 10 is capable of performing risk modeling and analysis operations to determine whether events are occurring, have occurred, potentially may occur, identify any potential vulnerabilities, risks, or malicious code (e.g., malware) associated with execution of processes in runtime computing systems 20, and so on. Risk analysis module 10 may utilize graphical user interface module 8 to provide graphical representations, such as graphical representations of vulnerabilities and risks, within a graphical user interface that is output to a user (e.g., analyst). Based on the output provided by GUI module 8, a user may determine what corrective or preventive actions to take. In some examples, such actions make take place in a software development process (e.g., modifying code or configuration information to mitigate or eliminate such vulnerabilities or risks), by updating software, making configuration changes, removing system nodes from distributed computing system 3, and so on.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Joyce’s Software Assurance For Heterogeneous Distributed Computing Systems with Aziz’s Malware Detection Verification And Enhancement By Coordinating Endpoint And Malware Detection Systems because it offers the advantage of thoroughly analysis events to prevent the spread of malicious code to the connected system.
As per claim 5, Aziz in combination with Joyce and Mantin teaches the method of claim 1, Joyce further teaches detecting in the log an event only of a predetermined event type (Joyce, Col. 9 Lines 28-37 recites “The disclosed techniques may also improve software assurance by providing more thorough analysis against the types of threats and runtime environments seen in modern computing architectures, providing an increased visibility to threats specific to code running on certain types of components (e.g., GPU's) in heterogeneous platforms or in a distributed/cloud environment. By providing alerts in context, the present techniques enable an analyst to prioritize important changes and see the impact of potential vulnerabilities or malicious code.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Joyce’s Software Assurance For Heterogeneous Distributed Computing Systems with Aziz’s Malware Detection Verification And Enhancement By Coordinating Endpoint And Malware Detection Systems because it offers the advantage of thoroughly analysis events to prevent the spread of malicious code to the connected system.
As per claim 7, Aziz in combination with Joyce and Mantin teaches the method of claim 1, Aziz further teaches matching runtime data received from the sensor to a result of a static analysis of any one of: a code object, a disk of the workload, and any combination thereof (Aziz, Col. 12 Lines 1-10 recites “Each of the one or more virtual machine(s) 360 may further include one or more monitors (not separately shown), namely software components that are configured to observe, capture and report information regarding run-time behavior of an object under analysis during processing within the virtual machine. The observed and captured run-time behavior information as well as effects on the virtual machine, otherwise known as features, along with related metadata may be provided to a scoring logic 370.”).
As per claim 8, Aziz in combination with Joyce and Mantin teaches the method of claim 7, Aziz further teaches matching the data received from the sensor and the result of the static analysis to an event detected in a log of the computing environment (Aziz, Col. 12 Lines 1-10 recites “Each of the one or more virtual machine(s) 360 may further include one or more monitors (not separately shown), namely software components that are configured to observe, capture and report information regarding run-time behavior of an object under analysis during processing within the virtual machine. The observed and captured run-time behavior information as well as effects on the virtual machine, otherwise known as features, along with related metadata may be provided to a scoring logic 370.”).
As per claim 9, Aziz in combination with Joyce and Mantin teaches the method of claim 1, Joyce further teaches matching the identity to the runtime process and the code object (Joyce, Col. 6 Line 63 – Col. 7 Line 18 recites “Risk analysis module 10 utilizes the information provided by test agents 12 based on the monitoring of runtime computing systems 20. Using the information provided by import/export module 14 and test agents 12, risk analysis module 10 is capable of performing risk modeling and analysis operations to determine whether events are occurring, have occurred, potentially may occur, identify any potential vulnerabilities, risks, or malicious code (e.g., malware) associated with execution of processes in runtime computing systems 20, and so on. Risk analysis module 10 may utilize graphical user interface module 8 to provide graphical representations, such as graphical representations of vulnerabilities and risks, within a graphical user interface that is output to a user (e.g., analyst). Based on the output provided by GUI module 8, a user may determine what corrective or preventive actions to take. In some examples, such actions make take place in a software development process (e.g., modifying code or configuration information to mitigate or eliminate such vulnerabilities or risks), by updating software, making configuration changes, removing system nodes from distributed computing system 3, and so on.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Joyce’s Software Assurance For Heterogeneous Distributed Computing Systems with Aziz’s Malware Detection Verification And Enhancement By Coordinating Endpoint And Malware Detection Systems because it offers the advantage of thoroughly analysis events to prevent the spread of malicious code to the connected system.
Regarding claims 10 and 11, claims 10 and 11 are directed to a non-transitory readable medium and a system associated with the method of claim 1. Claims 10 and 11 are of similar scope to claim 1, and are therefore rejected under similar rationale.
Regarding claim 12, claim 12 is directed to a similar system associated with the method of claim 2 respectively. Claim 12 is similar in scope to claim 2, respectively, and are therefore rejected under similar rationale.
Regarding claim 13, claim 13 is directed to a similar system associated with the method of claim 3 respectively. Claim 13 is similar in scope to claim 3, respectively, and are therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a similar system associated with the method of claim 4 respectively. Claim 14 is similar in scope to claim 4, respectively, and are therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a similar system associated with the method of claim 5 respectively. Claim 15 is similar in scope to claim 5, respectively, and are therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to a similar system associated with the method of claim 7 respectively. Claim 17 is similar in scope to claim 7, respectively, and are therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a similar system associated with the method of claim 8 respectively. Claim 18 is similar in scope to claim 8, respectively, and are therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a similar system associated with the method of claim 9 respectively. Claim 19 is similar in scope to claim 9, respectively, and are therefore rejected under similar rationale.
Claim(s) 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Aziz et al (US 10,462,173), Joyce et al. (US 10,558,809) and Mantin et al. (US 10,917,401) and in further view of Copty et al. (US 2022/0318002).
As per claim 6, Aziz in combination with Joyce and Mantin teaches the method of claim 1, but fails to teach accessing an infrastructure as code (laC) platform to detect the code object.
However, in an analogous art Copty teaches accessing an infrastructure as code (laC) platform to detect the code object (Copty, Paragraph 0016 recites “Embodiments may monitor for changes in key features of the IaC, and propagate them into models of the infrastructure, and anomaly detection mechanism in order to detect suspicious changes. Embodiments may build models of the infrastructure based on IaC, and propagate changes into the models to detect how a change can affect the infrastructure. Embodiments may learn the standard state of a feature from the history of commits to a code repository, as well as the user activity in post-deployment.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Copty’s user and entity behavior analytics of infrastructure as code in pre deployment of cloud infrastructure with Aziz’s Malware Detection Verification And Enhancement By Coordinating Endpoint And Malware Detection Systems because it offers the advantage of thoroughly analysis events to prevent the spread of malicious code to the connected system.
Regarding claim 16, claim 16 is directed to a similar system associated with the method of claim 6 respectively. Claim 16 is similar in scope to claim 6, respectively, and are therefore rejected under similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm.
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, Luu Pham can be reached on 571-270-5002. 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.
RODERICK . TOLENTINO
Examiner
Art Unit 2439
/RODERICK TOLENTINO/Primary Examiner, Art Unit 2439
Prosecution Insights