DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
With respect to Applicant’s amendment of Claims 4 and 14 with regards to 35 U.S.C. 112(b), the claim rejections with respect to the same have been withdrawn.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite methods and systems for performing control flow analysis based on telemetry data.
The limitation in Independent Claims 1, 11 and 20 of associating telemetry data and generating a control flow graph, as drafted, are processes that, under their broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations of “associating the instruction-level telemetry with a microservice of an application executed by the compute node” and “generating, based on the instruction-level telemetry, a control flow graph for the microservice associated with the telemetry,” in Claims 1, 11 and 20, as drafted, are processes that, under their broadest reasonable interpretation, recite the abstract idea of mental processes. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. Claims 1, 11 and 20 recite the following additional elements “obtaining, at runtime, telemetry regarding processor hardware of a compute node in a containerized system, wherein the telemetry is instruction-level telemetry that is decoded and converted into a common data format” and “providing an alert for display at runtime based on the control flow graph for the microservice,” these limitations do nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering and outputting the results of the abstract idea, see MPEP 2106.05(g).
Further, the “one or more network interfaces to communicate with a network,” “processor coupled to the one or more network interfaces and configured to execute one or more processes” and “memory configured to store a process that is executable by the processor” elements of Claim 11; as well as the “tangible, non-transitory, computer-readable medium having computer-executable instructions stored thereon…” element of Claims 20 are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, see MPEP 2106.05(f). Accordingly, the 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, thus failing to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements which recite “obtaining, at runtime, telemetry…,” and “providing an alert for display…,” in Claims 1, 11 and 20; “one or more network interfaces…,” a “processor…” and a “memory…” in Claim 11; and a “tangible, non-transitory, computer-readable medium…” in Claim 20, amount to no more than mere instructions to apply the exception using well-known, routine and conventional generic computer component, and merely gathering data and outputting the results of the judicial exception which cannot provide an inventive concept. See MPEP 2106.05(d). Thus, Claims 1, 11 and 20 are not patent eligible under 35 U.S.C.101.
With regard to the individual dependent claims:
Claims 2 and 12 recite, “wherein the common data format is Open Telemetry.”
Claims 3 and 13 recite, “wherein the containerized system is a Kubernetes platform that hosts the application.”
Claims 4 and 14 recite, “wherein the telemetry from the processor hardware of the compute node is captured by a processor tracing interface compliant with an instruction-level tracing protocol.”
Claims 7 and 17 recite, “wherein nodes of the control flow graph represent instruction addresses called by the processor hardware and edges of the control flow graph represent transitions between the instruction addresses.”
Claims 8 and 18 recite, “wherein the alert indicates that a particular workload of the application consumes an indicated percentage of total processor cycles consumed by the application.”
These limitations of Claims 2-4, 7-8, 12-14 and 17-18 do nothing more than generally link the judicial exception to a particular technological environment, see MPEP 2106.05(h). 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.
Claims 5 and 15 recite, “wherein the alert indicates an anomaly based on a comparison between the control flow graph and a baseline control flow graph associated with the application.”
Claim 6 and 16 recite, “wherein generating, based on the telemetry, the control flow graph for the microservice comprises: correlating a timestamp associated with starting of the microservice by the compute node with the telemetry.”
Claim 10 recites, “wherein the telemetry is normalized when converted into the common data format.”
These limitations of Claims 5-6, 10 and 15-16, as drafted, are processes that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out this function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas. 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.
Claims 9 and 19 recite, “wherein providing the alert for display comprises: providing the alert or the control flow graph to a plugin for a continuous integration and continuous delivery platform.”
These limitations of Claims 9 and 19 amount to no more than mere instructions to apply the exception using well-known, routine and conventional generic computer components, and merely gathering data and outputting the results of the judicial exception which cannot provide an inventive concept, see MPEP 2106.05(d). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
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.
Claims 1, 4, 7, 11, 14, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Parker et al. (US PGPUB 2022/0156123; hereinafter “Parker”) in view of Sultana et al. (US PGPUB 2018/0095764; hereinafter “Sultana”).
Claim 1: (Currently Amended)
Parker teaches a method, comprising:
obtaining, at runtime, telemetry regarding processor hardware of a compute node in a containerized system ([0035] “multiple instances of the same telemetry data collected at different times during the execution of the same workload may be included in the one dataset with different date and time information for each instance of telemetry data.” [0057] “telemetry agent 322 may collect telemetry data at defined intervals… for a particular… container.” [0073] “At 602, a telemetry data platform… receives a dataset from an infrastructure processing unit (IPU) of a plurality of IPUs… in a computing infrastructure… The dataset may contain an IPU ID representing the sending IPU and one or more instances of telemetry data collected by the sending IPU,” wherein the “infrastructure processing unit (IPU)… in a computing infrastructure” is the claimed “processor hardware of a compute node”.),
wherein the telemetry is converted into a common data format ([0074] “At 604, the dataset received by telemetry data platform 140 is transformed according to a standard format that accommodates one or more data collections.”); and
associating the telemetry with a microservice of an application executed by the compute node ([0061] “Each instance of telemetry data in telemetry data store 400 may be linked, mapped, or otherwise associated with one or more of an IPU ID… and a job ID representing a particular job or workload (e.g., … microservice…) that was running when the telemetry data was collected or generated”).
With further regard to Claim 1, Parker does not teach the following, however, Sultana teaches:
wherein the telemetry is instruction-level telemetry that is decoded ([0013] “An apparatus, method and/or system are configured to utilize processor trace (PT) data captured from PT circuitry and a control flow graph (CFG) to determine whether a control flow violation exists in an executing target application, in real time.” [0015] “Control flow integrity circuitry includes collector circuitry, decoder circuitry and control flow validator circuitry, as will be described in more detail below. The collector circuitry is configured to capture processor trace (PT) data from a PT driver that is configured to capture PT packets from the PT circuitry. The PT data may include a target instruction pointer (TIP) packet that includes a runtime target address of an indirect branch instruction of an executing target application. The decoder circuitry is configured to extract the TIP packet from the PT data and to decode the TIP packet to yield the runtime target address of the branch instruction.”);
generating, based on the instruction-level telemetry, a control flow graph for the microservice associated with the telemetry ([0013] “utilize processor trace (PT) data captured from PT circuitry and a control flow graph (CFG) to determine whether a control flow violation exists in an executing target application, in real time. PT circuitry and PT data are configured to provide runtime control flow information (i.e., an execution trace).” [0021] “CFG generator circuitry 120 may be further configured to generate a library CFG, e.g., library CFG 129, for library 119 based, at least in part, on library binary code. Including library CFG 129 is configured to enhance control flow integrity validation operations. For example, CFG generator circuitry 120 is configured to generate a CFG for the target application binary code (i.e., executable code) and any library binary code used by the target application binary code. When an application executes, application instructions and associated library functions, etc., execute. In other words, during application execution, the control flow transfer may occur in the application as well as library instructions.” [0037] “the CFGs 128, 129 may be generated during preprocessing operations utilizing… dynamic analysis… at least a subset of identifiable possible target addresses may be identified during preprocessing operations utilizing PT circuitry 124 and CFI circuitry 102, i.e., dynamic analysis.”); and
providing an alert for display at runtime at based on the control flow graph for the microservice. ([0044] “control flow validator circuitry 134 may be configured to notify, e.g., an administrator, of the control flow violation and may then halt the execution of target application 118,” wherein the notification to an administrator necessarily includes use of some form of “display”.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker with the telemetry and control flow graph functionality as taught by Sultana in order “to detect control flow integrity violations in real time” (Sultana [0014]).
Claim 4:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker does not teach the following, however, Sultana teaches:
wherein the telemetry from the processor hardware of the compute node is captured by a processor tracing interface compliant with an instruction-level tracing protocol ([0004] “An instruction trace tool (PT circuitry), e.g., Intel Processor Trace (PT) available from Intel Corp., may be configured to capture information (i.e., PT data) related to execution of a target application, a plurality of applications, selected memory ranges and/or an entire system. The PT data is collected in data packets and may include, e.g., timing information, program flow information (e.g., branch targets, branch taken/not taken indicators, function return addresses).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker with the processor tracing interface as taught by Sultana in order “to detect control flow integrity violations in real time” (Sultana [0014]).
Claim 7:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker does not teach the following, however, Sultana teaches:
wherein nodes of the control flow graph represent instruction addresses called by the processor hardware and edges of the control flow graph represent transitions between the instruction addresses ([0009] “A control flow graph (CFG) is a representation, using graph notation, of control flow, i.e., execution, paths that may be traversed through an application during execution of the application. In a control flow graph, each node in the graph corresponds to a basic block. A basic block is a sequence of instructions where control enters only at the beginning of the sequence and control leaves only at the end of the sequence… Edges between two basic blocks (e.g., a first block and a second block) represent control flow transfer from the end of the first block to the beginning of the second block. A node may thus include a start address of the basic block, an end address of the basic block and a next possible start address of a next basic block i.e., a beginning address of a next/reachable basic block.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker with the control flow graph functionality as taught by Sultana in order “to detect control flow integrity violations in real time” (Sultana [0014]).
Claims 11, 14 and 17:
With regard to Claims 11, 14 and 17, these claims are equivalent in scope to Claims 1, 4 and 7 rejected above, merely having a different independent claim type, and as such Claims 11, 14 and 17 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1, 4 and 7.
With further regard to Claim 11, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Parker reference also anticipates these additional elements of Claim 11, for example, wherein the apparatus comprises:
one or more network interfaces to communicate with a network; a processor coupled to the one or more network interfaces and configured to execute one or more processes; and a memory configured to store a process that is executable by the processor ([0045] “telemetry data platform 140 includes a processor 148, a memory 149, a communication interface 147… and a telemetry data store 150. Processor 148 may include any suitable combination of characteristics described herein with respect to processors of compute node 111 and/or accelerators of accelerator node 112.”).
Claim 20:
With regard to Claim 20, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 20 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 20, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Parker reference also anticipates these additional elements of Claim 20, for example, wherein Parker teaches:
A tangible, non-transitory, computer-readable medium having computer-executable instructions stored thereon that, when executed by a device, cause the device to perform a method ([0093] “The embodiments of methods, hardware, software, firmware, or code set forth above may be implemented via instructions or code stored on one or more machine-accessible storage media, machine readable storage media, computer accessible storage media, or computer readable media that are executable by one or more processing elements. A non-transitory machine-accessible/readable medium includes any mechanism that provides (e.g., stores and/or transmits) information in a form readable by a machine, such as a computer or electronic system.”).
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Parker in view of Sultana as applied to Claims 1 and 11 above, and further in view of Hulick (US PGPUB 2022/0050902; hereinafter “Hulick”).
Claim 2:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker in view of Sultana does not teach the following, however, Hulick teaches:
wherein the common data format is Open Telemetry ([0099] “Metrics: a raw measurement about a service that are captured at runtime. OpenTelemetry defines three metric instruments: counter, measure, and observer. An observer supports an asynchronous API collecting metric data on-demand, once per collection interval.” [0167] “the process when executed configured to: instrument an application to generate OpenTelemetry trace data during execution of the application.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker in view of Sultana with the use of the OpenTelemetry data format as taught by Hulick since “OpenTelemetry represents a massive shift from proprietary application monitoring systems, such as application performance monitoring (APM) solutions, to an infrastructure that leverages application programming interfaces (APIs) that are standardized and open” (Hulick [0094]).
Claim 12:
With regard to Claim 12, this claim is equivalent in scope to Claim 2 rejected above, merely having a different independent claim type, and as such Claim 12 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 2.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Parker in view of Sultana as applied to Claims 1 and 11 above, and further in view of Kuriata et al. (US PGPUB 2022/0321434; hereinafter “Kuriata”).
Claim 3:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker in view of Sultana does not teach the following, however, Kuriata teaches:
wherein the containerized system is a Kubernetes platform that hosts the application ([0031] “The Cloud Service Operator can be Kubernetes and the workload that is analyzed is the Kubernetes pod. Metrics are correlated for the Kubernetes pod.” [0027] “A kubernetes pod is a group of one or more containers, with shared storage and network resources. Telemetry data can be collected for each container… An application can include a collection of containers (also referred to as microservices).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker in view of Sultana with the use of the Kubernetes platform as taught by Kuriata since the Kubernetes platform can be advantageously used “for automating software deployment, scaling, and management” (Kuriata [0027]).
Claim 13:
With regard to Claim 13, this claim is equivalent in scope to Claim 3 rejected above, merely having a different independent claim type, and as such Claim 13 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 3.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Parker in view of Sultana as applied to Claims 1 and 11 above, and further in view of Murthy (US PGPUB 2013/0055208; hereinafter “Murthy”) and Hulick.
Claim 5:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker in view of Sultana does not teach the following, however, Murthy teaches:
wherein the alert indicates an anomaly based on a comparison between the control flow graph and a [second] control flow graph associated with the application ([0037] “Comparing CFGs 500 and 600, there is an extra node 501 in CFG 500 that is not found in CFG 600… and thus the section of the function's code corresponding to node 501 has a bug.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker in view of Sultana with the control flow graph comparison as taught by Murthy in order to “analyze and validate software source code… using control flow graphs” (Murthy [0013]).
With further regard to Claim 5, Parker in view of Sultana and Murthy does not teach the following, however, Hulick teaches:
wherein the [second] data in the comparison is a baseline data ([0048] “The application intelligence platform uses both self-learned baselines and configurable thresholds to help identify application issues… the disclosed application intelligence platform can perform anomaly detection based on dynamic baselines or thresholds.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker in view of Sultana and Murthy with the use of the comparison to baseline data as taught by Hulick since “baselines can be used to automatically establish what is considered normal behavior for a particular application” (Hulick [0052]).
Claim 15:
With regard to Claim 15, this claim is equivalent in scope to Claim 5 rejected above, merely having a different independent claim type, and as such Claim 15 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 5.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Parker in view of Sultana as applied to Claims 1 and 11 above, and further in view of Igolnik et al. (US Patent 11,153,325; hereinafter “Igolnik”).
Claim 6:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker in view of Sultana does not teach the following, however, Igolnik teaches wherein generating, based on the telemetry, the control flow graph for the microservice comprises:
correlating a timestamp associated with starting of the microservice by the compute node with the telemetry (Col. 3 Ln. 65 – Col. 4 Ln. 1: “A trace is composed of one or more spans where a span represents a call within the request. It is appreciated that a call may be to a separate microservice or a function within a microservice,” wherein a “trace” is a type of “telemetry”. Col. 4 Ln. 6-10: “A span may also include a unique span ID, a service name (e.g., 'analytics’), an operation name (e.g., ‘start’), duration (latency), start and end timestamps and additional annotations and attributes (e.g., tags).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker in view of Sultana with timestamped telemetry as taught by Igolnik as this provides “valuable information about interactions as well as causality” (Igolnik Col. 3 Ln. 61-62).
Claim 16:
With regard to Claim 16, this claim is equivalent in scope to Claim 6 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 6.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Parker in view of Sultana as applied to Claims 1 and 11 above, and further in view of Liguori et al. (US Patent 10,931,741; hereinafter “Liguori”).
Claim 8:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker in view of Sultana does not teach the following, however, Liguori teaches:
wherein the alert indicates that a particular workload of the application consumes an indicated percentage of total processor cycles consumed by the application (Col. 13 Ln. 19-23: “At the telemetry service 406, one or more thresholds may be specified for the telemetry service alarm; and the customer 422 may specify that the telemetry service alarm should fire when processor utilization reaches 50 percent utilization.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker in view of Sultana with processor utilization alert as taught by Liguori “such that when the alarm fires (i.e., the measurement value exceeds the threshold), it may trigger the scaling policy” (Liguori Col. 13 Ln. 25-27), thereby improving system resource management.
Claim 18:
With regard to Claim 18, this claim is equivalent in scope to Claim 8 rejected above, merely having a different independent claim type, and as such Claim 18 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 8.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Parker in view of Sultana as applied to Claims 1 and 11 above, and further in view of Copty et al. (US Patent 11,409,501; hereinafter “Copty”).
Claim 9:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker in view of Sultana does not teach the following, however, Copty teaches wherein providing the alert for display comprises:
providing the alert or the control flow graph to a plugin for a continuous integration and continuous delivery platform (Col. 9 Ln. 4-15: “repository alert component 406 can perform the alert notification to the repository during the continuous integration (CI) phase of the development process. For example, on a repository's drift from other repositories or a drift from a ranking expectation, provided by either a user or an automated system. It should be noted that this can be as part of a code validation process before new code is added to the repository. In another embodiment of the present invention, repository alert component 406 can perform the alert notification to the repository during an asynchronous testing phase.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker in view of Sultana with the providing of an alert to a continuous integration and continuous delivery platform as taught by Copty in order “to ensure the changes haven't broken the app” (Copty Col. 9 Ln. 19-20).
Claim 19:
With regard to Claim 19, this claim is equivalent in scope to Claim 9 rejected above, merely having a different independent claim type, and as such Claim 19 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 9.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Parker in view of Sultana as applied to Claim 1 above, and further in view of Mortensen et al. (US PGPUB 2021/0028975; hereinafter “Mortensen”).
Claim 10:
Parker in view of Sultana teaches all the limitations of claim 1 as described above. Parker in view of Sultana does not teach the following, however, Mortensen teaches:
wherein the telemetry is normalized when converted into the common data format ([0103] “Once obtained, data collector 906 may combine and store the telemetry 914 and alerts 916 for consumption by raw data normalizer 904.” [0104] “During execution, raw data normalizer 904 may apply a normalization model to the collected telemetry 914 such as the configuration and operational state information for the device.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method as disclosed by Parker in view of Sultana with the normalizing of telemetry data as taught by Mortensen since “different devices, software versions, etc. may use different schemas for their telemetry 908, requiring raw data normalizer 904 to first put this data into a common format for review across devices” (Mortensen [0104]).
Response to Arguments
With respect to the Applicant’s arguments, see Pages 8-10 of the Remarks filed October 14, 2025, with respect to the rejections under 35 U.S.C. 101 of Claims 1-20 have been fully considered but they are not persuasive.
With respect to the Applicant’s first argument regarding the 101 rejection, Page 9 Paragraph 1, that Claims 1-20 are eligible under 35 U.S.C. 101 under Step 2A, Prong One, since “The operations [of Claims 1, 11 and 20] cannot be performed mentally or conceptually,” the Office respectfully disagrees. The Office first notes that only the “associating...” and “generating…” steps have been indicated as reciting the abstract idea of a mental process. The Office maintains that a person is capable of mentally associating data with a microservice and of creating a control flow graph based on the data, wherein the recitation that the data is ‘instruction-level telemetry’ data merely indicates a format that the data is in and further that a computer is being leveraged as a tool to perform the abstract idea. The Office also maintains that the recited exception has not been integrated into a practical application since the independent claims merely recite that an alert is displayed, which does not improve the functioning of the computer since it does nothing more than add insignificant extra solution activity to the judicial exception, i.e. outputting the results of the abstract idea. As such, the 101 rejection of Claims 1-20 is maintained in view of Step 2A, Prong One.
With respect to the Applicant’s second argument regarding the 101 rejection, Page 9 Paragraph 4, that Claims 1-20 are eligible under 35 U.S.C. 101 under Step 2A, Prong Two, since “These steps are tied to a specific machine (processor hardware with tracing facilities) and effect a technological improvement in the operation and monitoring of computer systems,” the Office respectfully disagrees. The Office contends that Claims 1, 11 and 20 recite only generic computer hardware (i.e. network interfaces, a processor and a memory) and do not recite any specific machine hardware, i.e. tracing-specific hardware. Further, as stated above, the independent claims do not recite a technological improvement in the operation and monitoring of computer systems, as they merely recite that an alert is displayed, which does not improve the functioning of the computer since it does nothing more than add insignificant extra solution activity to the judicial exception, i.e. outputting the results of the abstract idea. As such, the 101 rejection of Claims 1-20 is maintained in view of Step 2A, Prong Two.
With respect to the Applicant’s third argument regarding the 101 rejection, Page 10 Paragraph 2, that Claims 1-20 are eligible under 35 U.S.C. 101 under Step 2B, since “These are non-generic computer functions and cannot be reduced to routine or conventional data processing. Conventional telemetry systems report aggregated performance metrics; none decode instruction-level hardware telemetry in real time or generate CFGs for live workloads,” the Office respectfully disagrees. The Office maintains that the obtaining of otherwise unspecified instruction-level telemetry data from a processor and the providing an alert for display at runtime are examples of insignificant extra solution activity performed using generic computer hardware, such as data gathering and outputting the results of the abstract idea, see MPEP 2106.05(g). With respect to the Applicant’s related argument, Page 10 Paragraph 3, that conventional telemetry systems don’t decode telemetry data or generate CFGs for live workloads, the Office contends that the Applicant’s claims do not positively recite the “decoding” step, as the current claim language merely specifies the format of the telemetry data. With respect to the Applicant’s final related argument regarding the claims representing an improvement to a technological field, Page 10 Paragraph 4, the Office maintains, for the same reasons discussed above, that the current claim language does not result in an improvement to computer technology. As such, the 101 rejection of Claims 1-20 is maintained in view of Step 2B.
Therefore, for at least the reasons discussed above, the 35 U.S.C. 101 rejection of Claims 1-20 has been maintained.
Applicant's arguments, see Pages 8-16 of the Remarks, with respect to the rejections under 35 U.S.C. 103 of Claims 1-20 have been fully considered but they are not persuasive.
With respect to the Applicant’s arguments, Page 11 Paragraph 1 – Page 13 Paragraph 1, that the newly amended language of Claims 1, 11 and 20 is not taught by the previously cited prior art, these arguments have been fully considered but are moot in view of the newly cited Sultana et al. (US PGPUB 2018/0095764) reference as discussed above in the respective rejections.
With respect to the Applicant’s further argument that the Parker reference cannot be combined with the other references, Page 13 Paragraph 3, “Adapting Parker to operate at this level would require adding a hardware-trace interface, a decoding layer, and a graph-construction engine, fundamentally changing the nature of Parker's telemetry pipeline. Parker's ‘standard format’ is merely a metadata schema for performance datasets, not an instruction-trace decoding format,” the Office respectfully disagrees. The Office contends that Parker has been cited since it discloses obtaining telemetry data regarding processor hardware, wherein the telemetry is converted into a common data format, and associating the telemetry with a microservice of an application, see for example the following citations in Parker:
[0032] “IPUs 120(1)-120(6) are operable to capture telemetry data from devices (and their interfaces) of their respective nodes 111-116. For example, telemetry data can be collected from processors (e.g., CPUs) in compute node 111.”
[0057] “telemetry agent 322 may collect telemetry data at defined intervals… for a particular… container.”
[0061] “Each instance of telemetry data in telemetry data store 400 may be linked, mapped, or otherwise associated with one or more of an IPU ID… and a job ID representing a particular job or workload (e.g., … microservice…) that was running when the telemetry data was collected or generated.”
[0074] “At 604, the dataset received by telemetry data platform 140 is transformed according to a standard format that accommodates one or more data collections.”
As such, in view of at least the above citations, the Office maintains that the functionality of Parker could have been combined with the functionality disclosed in the newly cited Sultana reference (i.e. capturing and decoding instruction-level processor telemetry data, generating a CFG from the telemetry data and providing an alert based on the generated CFG). Although certain hardware may need to be added to the system in Parker, in order to incorporate the functionality and features disclosed in Sultana, there does not appear to be any disclosure in Parker which indicates that these changes would render the system of Parker inoperable. The Office also notes, with respect to the Applicant’s arguments regarding the “decoding” claim language, that the Applicant’s claims do not currently positively recite the “decoding” step, as explained above.
Therefore, for at least the reasons discussed above, the claim rejections which rely on the combination of Parker in view of additionally cited prior art, have been maintained.
With respect to the Applicant’s further arguments, Page 15 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to claims discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Chari et al. (US Patent 11,748,480) discloses an system and method wherein anomalous control and data flow paths in a program are determined by machine learning the program's normal control flow paths and data flow paths, including the receiving of trace data comprising instruction-level traces generated from multiple invocations of the application program.
Yagemann (“Hardware-Assisted Processor Tracing for Automated Bug Finding and Exploit Prevention,” 2022) discloses a control-oriented record and replay system and method, which combines concrete traces with symbolic analysis to uncover vulnerabilities and exploits.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.G.M/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197