DETAILED ACTION
This action is in response to claims filed 25 February 2026 for application 17339988 filed 05 June 2021. Currently claims 1-6, 8-14 and 16-20 are pending.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 25 February 2026 has been entered.
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.
The factual inquiries for establishing a background for determining 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.
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-6, 8-14 and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chung et al. (US 2020/0293920 A1) in view of Arashanipalai et al. (US 20200409339 A1)(hereinafter “Arash”).
Claim(s) 1-6, 8-14 and 16-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by.
Regarding claims 1, 9 and 17, Chung discloses: A method for automatically generating and applying assertions, comprising:
receiving a first set of time series metrics with labels from one or more agents monitoring a client system in one or more computing environments (“A fact registry interface 2122 may register new data selectively or automatically with a knowledge base 2140 which includes a directed knowledge graph and a multidimensional time series database (MDTSDB), and communicate registered data and the result of attempts to register new data with the PRS engine 2121. An PRS engine 2121 operates the construction and evaluation protocols 2130 to parse data sent through the REST API 2111, and sends results and further queries for backend oracles 2150 to a PRS client 2112.” [0097] Chung);
automatically applying a set of rules to the time series metrics (“A client 2105 computer connects to a production rule system (PRS) 2110, via a REST API 2111 over a network. A PRS is a rule system which enables many different functionalities, including making external function calls to domain-specific oracles, providing for generalization of semantic and datastream processing rules and preventing rule creep when defining multiple transitivity properties, allowing for scalar value comparisons of data (comparing ages, distances, etc.), allowing for aggregation of facts and rules from different knowledge bases, graphs, or both, allowing for JSON conversion of rules to and from a GraphStack with a universally unique identifier (UUID), providing the ability to instantiate nodes with specified properties in a GraphStack, provide for a message queue through a Command-Line Interface (CLI) or Graphical User Interface (GUI), and rule building through an API, and allowing for new rules and modified rules to be updated with a real-time visualization…A fact registry interface 2122 may register new data selectively or automatically with a knowledge base 2140 which includes a directed knowledge graph and a multidimensional time series database (MDTSDB), and communicate registered data and the result of attempts to register new data with the PRS engine 2121. An PRS engine 2121 operates the construction and evaluation protocols 2130 to parse data sent through the REST API 2111, and sends results and further queries for backend oracles 2150 to a PRS client 2112.” [0097]);
automatically updating a knowledge graph generated from the time series metrics (“The pipeline enters an updated state 1905 either when changes are made to the existing graph defining the data flow within the pipeline or when a base docker image used to create the pipeline changes that requires changing to existing pipelines. The stopped pipeline is reconfigured in the update state to permit the new definition for the pipeline to operate on data when the pipeline returns to a running state 1903 from the update state 1905.” [0096], “A client 2105 computer connects to a production rule system (PRS) 2110, via a REST API 2111 over a network. A PRS is a rule system which enables many different functionalities, including making external function calls to domain-specific oracles, providing for generalization of semantic and datastream processing rules and preventing rule creep when defining multiple transitivity properties, allowing for scalar value comparisons of data (comparing ages, distances, etc.), allowing for aggregation of facts and rules from different knowledge bases, graphs, or both, allowing for JSON conversion of rules to and from a GraphStack with a universally unique identifier (UUID), providing the ability to instantiate nodes with specified properties in a GraphStack, provide for a message queue through a Command-Line Interface (CLI) or Graphical User Interface (GUI), and rule building through an API, and allowing for new rules and modified rules to be updated with a real-time visualization.” [0097]), wherein the knowledge graph includes system nodes within the client system being monitored and node relationships within the client system (“wherein the directed computational graph comprises nodes representing workflow stages and edges representing message outputs between the workflow stages; wherein the workflow stages comprise: one or more environmental orchestration stages, each configured to: set up data processing stages and data paths; and teardown data processing stages; and one or more data processing stages each comprising one or more data source stages, one or more data sink stages, and a plurality of transformation stages; and wherein the directed computational graph is used to produce a result of analysis of the first data stream.” [0008]); and
automatically generating one or more assertions based on time series metrics and the result of applying the rules, the results of applying the rules used to update the knowledge graph (“A client 2105 computer connects to a production rule system (PRS) 2110, via a REST API 2111 over a network. A PRS is a rule system which enables many different functionalities, including making external function calls to domain-specific oracles, providing for generalization of semantic and datastream processing rules and preventing rule creep when defining multiple transitivity properties, allowing for scalar value comparisons of data (comparing ages, distances, etc.), allowing for aggregation of facts and rules from different knowledge bases, graphs, or both, allowing for JSON conversion of rules to and from a GraphStack with a universally unique identifier (UUID), providing the ability to instantiate nodes with specified properties in a GraphStack, provide for a message queue through a Command-Line Interface (CLI) or Graphical User Interface (GUI), and rule building through an API, and allowing for new rules and modified rules to be updated with a real-time visualization.” [0097]); and
automatically reporting the assertions though a user interface (“An PRS client 2112 represents the PRS system 2110 communicating with backend oracles 2150 which in turn send the results of these modified queries to the client 2105, thus completing the cycle and allowing the rule system 2110 to act as a modular, integrable front-end to other systems for semantic data and API call processing. As an example of a type of rule that might be created by the PRS, the PRS may declaratively specify windowed rules, wherein rules may be established for events occurring within a given time window. For example, a windowed rule may be established that counts the number of login attempts made within a two-minute time window. The window may be a “tumbled” or “sliding” window that repeatedly refreshes on a periodic basis to apply the rule to the time window just prior to the refresh.” [0097], “An environmental workflow stage is utilized when environmental variables, settings, and initializations must be set, for instance initialization of other workflow stages, or of knowledge graph nodes, or other environmental attributes of interest. A source stage of workflow 2220 is where data is analyzed to determine, broadly speaking, the origin and acquisition of the data, before either returning the result of the workflow immediately to the client 2210 or continuing to a transformation stage 2240. A transformation stage of workflow 2240 is where data may be manipulated, and represents such workflow steps and functionality as starting a data pipeline, shutting down a data pipeline, and editing a data pipeline for the flow and processing of data as required.” [0101]).
Chung does not explicitly disclose, however, Arash teaches:
the agents installed within the architecture of the client system computing environments, the time series metrics collected and aggregated by the agent before being reported from within the architecture of the client system to a server remote and external to the client system (“The controllers 320 receive data from different agents 310 (e.g., Agents 1-4) deployed to monitor applications, databases and database servers, servers, and end user clients for the monitored environment. Any of the agents 310 can be implemented as different types of agents with specific monitoring duties. For example, application agents may be installed on each server that hosts applications to be monitored. Instrumenting an agent adds an application agent into the runtime process of the application.” [0037]);
a baseline of time series metrics … to the time series metrics (“For example, dynamic baselines can be used to automatically establish what is considered normal behavior for a particular application. Policies and health rules can be used against baselines or other health indicators for a particular application to detect and troubleshoot problems before users are affected. Health rules can be used to define metric conditions to monitor, such as when the “average response time is four times slower than the baseline”. The health rules can be created and modified based on the monitored application environment.” [0058], “Said differently, the techniques herein may prepare for its online anomaly detection by classifying the relevant metrics as time-series and employing near term prediction models in order to detect deviations from expected behavior.” [0114]).
Chung and Arash are in the same field of endeavor of monitoring client system with rules and are analogous. Chung discloses a system for monitoring a system using a knowledge graph. Arash discloses time-series monitoring of client systems. It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the monitoring system of Chung with the time series based metric monitoring as taught by Arash to yield predictable results.
Regarding claims 2, 10 and 18, Chung discloses: The method of claim 1, wherein an assertion is generated from one or more of saturation of a resource, an anomaly value in the metric data, a change to the software, a failure or fault, or an error rate or error budget (“For example, a windowed rule may be established that counts the number of login attempts made within a two-minute time window. The window may be a “tumbled” or “sliding” window that repeatedly refreshes on a periodic basis to apply the rule to the time window just prior to the refresh.” [0097]).
Regarding claims 3, 11 and 19, Chung discloses: The method of claim 1, wherein the set of rules is domain specific (“A novel, declarative domain-specific language (DSL) may be utilized in the workflow cycle. According to a preferred embodiment, several functions of a novel DSL may be utilized, including a capability for bidirectional dependencies on operations (for instance, “A->B” may be used to specify B depending on A before executing, or “B<-A” for the same), channel or domain-specific directional dependencies (for instance, “A->(“EXAMPLE”, B)” may be interpreted as B has a dependency on A's EXAMPLE signal, channel, or argument), multi-argument support (for instance, “A->(set(“EXAMPLE”, “EXAMPLE 2”), B)), and may be modular, for new language definitions and uses to be defined as needed.” [0102]).
Regarding claims 4, 12 and 20, Chung discloses: The method of claim 1, wherein generating the assertions includes generating graphical identifiers that indicate a rule failure (“present a graphical user interface to a user comprising modular building blocks, each comprising modular building blocks comprising either a declarative definition of an environmental orchestration stage of a streaming analytics workflow or a declarative definition of a data processing stage of a streaming analytics workflow; and receive and store input from the user through the graphical user interface,” [0008], “For example, a windowed rule may be established that counts the number of login attempts made within a two-minute time window. The window may be a “tumbled” or “sliding” window that repeatedly refreshes on a periodic basis to apply the rule to the time window just prior to the refresh.” [0097]).
Regarding claims 5 and 13, Chung discloses: The method of claim 1, wherein the first set of received metrics and labels having a universal nomenclature that is different than a native computing environment nomenclature associated with the client system being monitored for the metrics and labels (“FIG. 17 is a diagram of a computing architecture for a processing system according to one aspect of the present invention. An environmental orchestration and data processing engine 1700 permits domain experts to directly capture their knowledge via a user interface with domain agnostic building blocks. These modular components can be built and extended by programmers to satisfy a number of use cases without a need to understand how they will be used in a business specific implementation. An Environmental Orchestration component 1711 and Data Processing component 1712, coupled together 1701, allow for both flexibility and tight coupling between all the actions needed to set up resources and perform analytical tasks.” [0075], “An environmental workflow stage is utilized when environmental variables, settings, and initializations must be set, for instance initialization of other workflow stages, or of knowledge graph nodes, or other environmental attributes of interest. A source stage of workflow 2220 is where data is analyzed to determine, broadly speaking, the origin and acquisition of the data, before either returning the result of the workflow immediately to the client 2210 or continuing to a transformation stage 2240. A transformation stage of workflow 2240 is where data may be manipulated, and represents such workflow steps and functionality as starting a data pipeline, shutting down a data pipeline, and editing a data pipeline for the flow and processing of data as required.” [0101]).
Regarding claims 6 and 14, Chung discloses: The method of claim 1, wherein further comprising automatically identifying insights based on the one or more assertions (“An PRS client 2112 represents the PRS system 2110 communicating with backend oracles 2150 which in turn send the results of these modified queries to the client 2105, thus completing the cycle and allowing the rule system 2110 to act as a modular, integrable front-end to other systems for semantic data and API call processing. As an example of a type of rule that might be created by the PRS, the PRS may declaratively specify windowed rules, wherein rules may be established for events occurring within a given time window. For example, a windowed rule may be established that counts the number of login attempts made within a two-minute time window. The window may be a “tumbled” or “sliding” window that repeatedly refreshes on a periodic basis to apply the rule to the time window just prior to the refresh.” [0097], “The oracles 2150 may comprise any plurality or combination of services and technologies and components, which are utilized for database storage and data stream processing, which the PRS 2110 may communicate with to help with backend processing. According to an embodiment, a database may be included either in the oracles 2150 backend or in the knowledge base 2140, or both, to support the integration of fixed-point rule semantics, providing for analysis of data and semantic data especially by comparison to a fixed point after refinement using machine learning.” [0100]).
Chung does not explicitly disclose, however Arash teaches: And a detected failure state when the assertion is applied to received time series metrics (“Database agents, for example, may be software (e.g., a Java program) installed on a machine that has network access to the monitored databases and the controller. Database agents query the monitored databases in order to collect metrics and pass those metrics along for display in a metric browser (e.g., for database monitoring and analysis within databases pages of the controller's UI 330). Multiple database agents can report to the same controller. Additional database agents can be implemented as backup database agents to take over for the primary database agents during a failure or planned machine downtime. The additional database agents can run on the same machine as the primary agents or on different machines. A database agent can be deployed in each distinct network of the monitored environment. Multiple database agents can run under different user accounts on the same machine.” [0038]).
Regarding claims 8 and 16, Chung discloses: The method of claim 1, further comprising automatically generating a rule configuration file based on the received first set of metrics with labels, the rule configuration file transmitted to the agent installed within the architecture of the client system computing environments, the rule configuration file indicating what metrics and labels the agent should subsequently retrieve from the client system, the new set of metrics retrieved by the agent based on the rule configuration file, the rule configuration file generated at least in part on the assertions “A client 2105 computer connects to a production rule system (PRS) 2110, via a REST API 2111 over a network. A PRS is a rule system which enables many different functionalities, including making external function calls to domain-specific oracles, providing for generalization of semantic and datastream processing rules and preventing rule creep when defining multiple transitivity properties, allowing for scalar value comparisons of data (comparing ages, distances, etc.), allowing for aggregation of facts and rules from different knowledge bases, graphs, or both, allowing for JSON conversion of rules to and from a GraphStack with a universally unique identifier (UUID), providing the ability to instantiate nodes with specified properties in a GraphStack, provide for a message queue through a Command-Line Interface (CLI) or Graphical User Interface (GUI), and rule building through an API, and allowing for new rules and modified rules to be updated with a real-time visualization…A fact registry interface 2122 may register new data selectively or automatically with a knowledge base 2140 which includes a directed knowledge graph and a multidimensional time series database (MDTSDB), and communicate registered data and the result of attempts to register new data with the PRS engine 2121. An PRS engine 2121 operates the construction and evaluation protocols 2130 to parse data sent through the REST API 2111, and sends results and further queries for backend oracles 2150 to a PRS client 2112.” [0097].
Response to Arguments
Applicant's arguments filed 01 November 2023 have been fully considered but they are not persuasive. Applicant argue that Chung does not disclose elements of the claims. Examiner respectfully disagrees.
Please see the updated rejection under 35 USC 103 with the new Arash reference.
Applicant argues that Chung does not disclose an assertion, however, assertion is not defined in any way. Spec. [0035] provides several examples of assertions which the examiner is interpreting as a conclusion drawn from a standard rule. Chung discloses this as cited above. Applicant provides a definition of assertion in the arguments, however, a specific definition in the specification is not recited. Examiner will continue to use the broadest reasonable interpretation of the term in light of the specification.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC NILSSON whose telephone number is (571)272-5246. The examiner can normally be reached M-F: 7-3.
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, James Trujillo can be reached at (571)-272-3677. 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.
/ERIC NILSSON/ Primary Examiner, Art Unit 2151
Prosecution Insights