DETAILED ACTION This action is in response to communication filed on 12/14/2023. Claims 1-16 and 20 -22 are pending. Claims 17-19 have been 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. Information Disclosure Statement The information disclosure statement (IDS) submitted on 12/14/2023 and 8/11/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Specification The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. The following title is suggested: Behavior-Based Intrusion Detection for Cloud Physical Nodes Using Kernel-Level Monitoring. 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. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because as a system claim reciting an “intrusion detection system” without hardware components (e.g., implemented via abstract modules like an “ acquisition module ” and “detection module”), is rejected as directed to ineligible subject matter . Claim Rejections - 35 USC § 102 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale , or otherwise available to the public before the effective filing date of the claimed invention. Claim s 9, 11, 13 - 14 and 21-22 are rejected under 35 U.S.C. 102( a ) (a) as being anticipated by Araujo et al. (US 2022/0121741 ). Regarding claim 9 , Araujo discloses a intrusion detection method, comprising: acquiring behavior benchmark data of a physical node of a cloud platform system, wherein the behavior benchmark data is behavior data of the physical node in a normal operating state of the cloud platform system ( see Araujo; [0070-0071]; the container image 604 has been previously processed by the automated binary analysis 600, preferably in an off-line manner, to generate an associated behavior model M. An IDS for this image is then defined by checking 606 (e.g., M|=T) whether the system call trace telemetry generated by the image's running container (in the example running in a hardware node 608 in a Container Orchestration Engine (COE) 610 (here, running Kubernetes)) satisfies its associated behavioral model ) ; ; and sending the behavior benchmark data to an agent module provided in the physical node (see Araujo; [0023]; t he gatherer module may initiate a collection of data to support or refute each of the one or more possible cyber threat hypotheses that could include this abnormal behaviour or suspicious activity by the one or more AI models trained on possible cyber threats ) . Regarding claim 11 , Araujo discloses the intrusion detection method of claim 9, before sending the behavior benchmark data to the physical node, the method further comprises: establishing a connection with the agent module (see Araujo; [0027]; c ommunications unit 210, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit 210 is a network interface card. Communications unit 210 may provide communications through the use of either or both physical and wireless communications links ), wherein sending the behavior benchmark data to the agent module provided in the physical node comprises: sending the behavior benchmark data to the agent module through the established connection (see Araujo; [0031]; program code 216 may be transferred to data processing system 200 from computer-readable media 218 through a communications link to communications unit 210 and/or through a connection to input/output unit 21 ) . Regarding claim 13 , Araujo discloses the intrusion detection method of claim 9, wherein the behavior benchmark data comprises at least one of: a list of information of legal processes on the physical node; a list of information of legal files on the physical node; a list of resources accessible to the legal processes on the physical node; a range of network ports capable of being created by the legal processes on the physical node; communication terminals capable of being communicated with the legal processes on the physical node: or a set of system call functions capable of being called by the legal processes on the physical node (see Araujo; [0083]; by examining its inter-procedural call-graph, and then finding all system calls reachable from this graph ) . Regarding claim 14 , Araujo discloses the intrusion detection method of claim 13, wherein the resources comprise at least one of: files, directories, network ports, destination network addresses, destination network domain names, or hardware devices (see Araujo; [0005]; a behavior model for a container image is generated by statically determining what library functions a given binary calls out to and, in particular, by examining its inter-procedural call-graph, and then finding all system calls reachable from this graph. The behavior model that results from this analysis is a graph data structure having a set of nodes, and a set of edges, wherein a node represents one of: a process, a file, or a network socket, and wherein an edge represents a system call made by at least one process represented in the graph data structure ) . Regarding claim(s) 21-22 , do(es) not teach or further define over the limitation in claim(s) 9 respectively. Therefore claim(s) 21-22 is/are rejected for the same rationale of rejection as set forth in claim(s) 9 respectively. 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 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 of this title, 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. The factual inquiries set forth in Graham v. John Deere Co. , 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determ ining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness . Claims 1-8, 10. 15-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Araujo et al. (US 2022/0121741 ) in view of Salji (US 2021/0273959 ). Regarding claim 1 , Araujo discloses a n intrusion detection method, comprising: acquiring behavior benchmark data of a physical node of a cloud platform system, wherein the behavior benchmark data is behavior data of the physical node in a normal operating state of the cloud platform system (see Araujo; [0070-0071]; the container image 604 has been previously processed by the automated binary analysis 600, preferably in an off-line manner, to generate an associated behavior model M. An IDS for this image is then defined by checking 606 (e.g., M|=T) whether the system call trace telemetry generated by the image's running container (in the example running in a hardware node 608 in a Container Orchestration Engine (COE) 610 (here, running Kubernetes)) satisfies its associated behavioral model ) ; acquiring runtime behavior data of the physical node in an actual operating process of the cloud platform system (see Araujo; [0073-0074]; The ELF is the executable file representing the process or application that will run in the container. The image 700 is input to a binary analysis platform (BAP) 702, which generates a static behavior model for the image. Typically, BAP 702 operates as an automated process or set of processes, executing as software in one or more hardware processors . Further, BAP 702 then explores each possible execution path in function ƒ, and observes the value of the RAX register (familiarity with Linux OS kernel semantics is presumed) when encountering a syscall instruction. BAP 702 then outputs a set of observed values for RAX as the set of system calls made by function ƒ ) . However, the prior art does not explicitly disclose generating alarm information in a case where the behavior benchmark data conflicts with the runtime behavior data, and reporting the alarm information to an intrusion detection apparatus or an intrusion detection subsystem . Salji in the field of the same endeavor discloses techniques for detecting a cyber threat may use a predictor, e.g. a Transformer deep learning model, which is configured to predict a next item in the sequence of events and to detect one or more anomalies in the sequence of events. In particular, Saliji teaches the following: generating alarm information in a case where the behavior benchmark data conflicts with the runtime behavior data, and reporting the alarm information to an intrusion detection apparatus or an intrusion detection subsystem (see Salji ; [ 0052 ]; The predictor may be configured to generate likelihoods for anomaly detection. In turn, the predictor may provide a notification comprising ( i ) information about the anomaly; and (ii) a prediction of what would have been expected and (iii) likelihoods for anomaly detection ) . Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Salji to incorporate techniques for detecting a cyber threat may use a predictor . One would have been motivated because this combination applies Salji’s known ML improvement (predictive notification on anomalies) to Araujo’s system, yielding predictable results of more accurate, proactive alerting in dynamic cyber threats. Regarding claim 2 , Araujo-Salji discloses t he intrusion detection method of claim 1, wherein acquiring the behavior benchmark data of the physical node of the cloud platform system comprises: receiving the behavior benchmark data sent by the intrusion detection apparatus or the intrusion detection subsystem (see Araujo; [0067]; FIG. 5 depicts a typical host-based Intrusion Detection System (IDS) 500 is implemented in association with a host operating system having a kernel space 502, and a user space 504. A System Call Table 506 is accessible in the kernel space 502. A program P 508 executes in user space 504 and makes system calls 510 to the host's kernel via the table 506 ) . Regarding claim 3 , Araujo-Salji discloses the intrusion detection method of claim 2, before receiving the behavior benchmark data sent by the intrusion detection apparatus or the intrusion detection subsystem, the method further comprises: establishing a connection with the intrusion detection apparatus or the intrusion detection subsystem (see Araujo; [ 0027 ]; c ommunications unit 210, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit 210 is a network interface card. Communications unit 210 may provide communications through the use of either or both physical and wireless communications links ) , wherein receiving the behavior benchmark data sent by the intrusion detection apparatus or the intrusion detection subsystem comprises: receiving the behavior benchmark data sent by the intrusion detection apparatus or the intrusion detection subsystem through the established connection (see Araujo; [0031]; program code 216 may be transferred to data processing system 200 from computer-readable media 218 through a communications link to communications unit 210 and/or through a connection to input/output unit 21 ) . Regarding claim 4 , Araujo-Salji discloses the intrusion detection method of claim 1, wherein the behavior benchmark data comprises at least one of: a list of information of legal processes on the physical node; a list of information of legal files on the physical node; a list of resources accessible to the legal processes on the physical node; a range of network ports capable of being created by the legal processes on the physical node; communication terminals capable of being communicated with the legal processes on the physical node; or a set of system call functions capable of being called by the legal processes on the physical node (see Araujo; [0083]; by examining its inter-procedural call-graph, and then finding all system calls reachable from this graph ) . Regarding claim 5 , Araujo-Salji discloses the intrusion detection method of claim 4, wherein the resources comprise at least one of: files, directories, network ports, destination network addresses, destination network domain names, or hardware devices (see Araujo; [0005]; a behavior model for a container image is generated by statically determining what library functions a given binary calls out to and, in particular, by examining its inter-procedural call-graph, and then finding all system calls reachable from this graph. The behavior model that results from this analysis is a graph data structure having a set of nodes, and a set of edges, wherein a node represents one of: a process, a file, or a network socket, and wherein an edge represents a system call made by at least one process represented in the graph data structure ) . Regarding claim 7 , Araujo-Salji discloses the intrusion detection method of claim 4, wherein the runtime behavior data comprises at least one of: information of processes running on the physical node; information of files on the physical node; resources accessed by the processes running on the physical node; network ports created by the processes running on the physical node; communication terminals communicated with the processes running on the physical node: or system call functions called by the processes running on the physical node (see Araujo; [0067]; FIG. 5 depicts a typical host-based Intrusion Detection System (IDS) 500 is implemented in association with a host operating system having a kernel space 502, and a user space 504. A System Call Table 506 is accessible in the kernel space 502. A program P 508 executes in user space 504 and makes system calls 510 to the host's kernel via the table 506. The IDS 500 implemented in this operating context traces system calls that the program makes to the host's kernel in order to detect activity that deviates from normal behavior ) . Regarding claim 8 , Araujo-Salji discloses the intrusion detection method of claim 7, wherein the behavior benchmark data conflicting with the runtime behavior data comprises at least one of conditions that the list of the information of the legal processes on the physical node in the behavior benchmark data comprises the information of the processes running on the physical node in the runtime behavior data; the list of the information of the legal files on the physical node in the behavior benchmark data comprises the information of the files on the physical node in the runtime behavior data; the list of resources accessible to the legal processes on the physical node in the behavior benchmark data comprises the resources accessed by the processes running on the physical node in the runtime behavior data; the range of the network ports capable of being created by the legal processes on the physical node in the behavior benchmark data comprises the network ports created by the processes running on the physical node in the runtime behavior data; the communication terminals capable of being communicated with the legal processes on the physical node in the behavior benchmark data comprise the communication terminals communicated with the processes running on the physical node in the runtime behavior data: or the set of system call functions capable of being called by the legal processes on the physical node in the behavior benchmark data comprises the system call functions called by the processes running on the physical node in the runtime behavior data (see Araujo; [0083]; t hese models preferably are generated by statically-determining what library functions a given binary calls out to and, in particular, by examining its inter-procedural call-graph, and then finding all system calls reachable from this graph. An IDS is then defined that checks whether the telemetry generated by an image's running container satisfies its associated behavior model. Behavior models are built from container images accessible from a registry. These models preferably are sufficiently compact that are co-located with running containers and detect anomalies in real-time (or substantially real-time) if and when they occur on the associated hardware node ) . Regarding claim 6 , Araujo-Salji discloses the intrusion detection method of claim 1, wherein acquiring the runtime behavior data of the physical node in the actual operating process of the cloud platform system comprises: acquiring the runtime behavior data with an extended Berkeley Packet Filter ( eBPF ) agent module provided in the physical node (see Araujo; [0078]; t he agent 1004 typically executes as software and consumes one or more sources of telemetry 1010 commonly used for host monitoring (e.g., Sysflow T, audit logs, system calls, etc.) for all the containers (not shown) running on a given hardware node ) . Regarding claim 10 , Araujo-Salji discloses the intrusion detection method of claim 9, further comprising: receiving alarm information sent by the agent module, and performing corresponding processing on the alarm information to obtain a processing result (see Salji; [0052]; the predictor may provide a notification comprising ( i ) information about the anomaly; and (ii) a prediction of what would have been expected and (iii) likelihoods for anomaly detection . Similar rationale to combine as in claim 1) ; and storing the alarm information and the processing result (see Salji; [0052]; For example, the likelihoods for anomaly detection may be a probability quantifying how certain the assessment is. This probability may be expressed in percent [%] ) . Regarding claim(s) 15-16 and 20 , do(es) not teach or further define over the limitation in claim(s) 1 respectively. Therefore claim(s) 15-16 and 20 is/are rejected for the same rationale of rejection as set forth in claim(s) 1 respectively. Claims 1-8, 10. 15-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Araujo et al. (US 2022/0121741 ) in view of Coffman et al. (US 7,739,211 ). Regarding claim 1 2 , Araujo disclose the invention substantially, however the prior art does not explicitly disclose the intrusion detection method of claim 9, wherein acquiring the behavior benchmark data of the physical node of the cloud platform system comprises: receiving the behavior benchmark data uploaded by a user . Coffman in the field of the same endeavor discloses techniques for enabling dynamic detection of anomalies occurring within an input graph representing a social network . In particular, Coffman teaches the following: receiving the behavior benchmark data uploaded by a user (see Coffman; col 10/lines 7- 26; a nalyze anomaly function 309 is performed under the direction of a human analyst. Utilizing the anomaly tolerances, the system is able to learn what is normal over a period of time (referred to as the baseline). The input to the entire system and particularly process input function 303 and establish normal function 305 is user supplied data source 308 ) . Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Coffman because this combination applies Coffman’s know techniques of user0supplied assumed normal data (e.g., for customizable baselines) to Araujo’s system, yielding predictable results of enhanced flexibility in acquiring benchmarks via user uploads, allowing administrators to tailor cloud IDS to site-specific application without relying solely on automated generation. Conclusion For the reason above, claims 1-16, and 19-22 have been rejected and remain pending. Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT JIMMY H TRAN whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)270-5638 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT Monday-Friday 9am-5pm PST . 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, FILLIN "SPE Name?" \* MERGEFORMAT Chris Parry can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT 571-272-8328 . 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. FILLIN "Examiner Stamp" \* MERGEFORMAT JIMMY H TRAN Primary Examiner Art Unit 2451 /JIMMY H TRAN/ Primary Examiner, Art Unit 2451