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
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
1. This action is responsive to communications: Application filed on September 27, 2024, and Drawings filed on September 27, 2024.
2. Claims 1–20 are pending in this case. Claim 1, 11, 16 are independent claims.
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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kapuram et al., Pub. No.: 2011/0238687 in view of Burnett et al., Pub. No.: 2020/0104402A1.
With regard to claim 1:
Kapuram discloses a method, comprising: accessing, using one or more processors, a bound system model comprising one or more associations between one or more model elements of an abstract system model that represents a deployed system infrastructure and one or more inventory elements included in an inventory (See paragraph 46 once system component instances are bound to model 210, MEM system 201 is capable of providing to a user 220 of MEM system 201 metric correlation and analysis functionality for the bound system component instances. Such functionality includes presenting to user 220 a user interface that allows the user 220 to visually compare metric data for the source metric obtained from a source system component instance with metric data for the related metric(s) obtained from related system component instance(s). ), wherein the inventory is populated based on one or more data sources associated with the deployed system infrastructure (See paragraph 60 Metric data for a metric available for a system component can be collected from the system component at regular time intervals. For example, every 15 minutes, once a day, once a week, etc. Accordingly, metric data of a metric data class 403 instance can comprise one or more data samples representing measurements of a property of the system component over a period of time. ); providing, using the one or more processors, a graphical user interface (GUI), wherein the GUI provides options to visually construct a metric pipeline template to be associated with the bound system model (See paragraph 96 For example, MEM system 201 can present a user interface charting the source metric against the related configuration metric for historical snapshot period of time or, alternatively, for an ongoing period of time. Such charting can aid the administrator in determining whether a change in the performance of the source metric is related to a change to the configuration parameter represented by the related configuration metric.”); determining, using the one or more processors, a definition for the metric pipeline template based at least in part on user input via the GUI (See paragraph 65 the model 210 describes administrator-defined metric dependencies, with each dependency being defined by a "source" metric and one or more metrics that are deemed by the administrator to be related to the source metric ("related metrics"). In addition, the source metric is defined by a type of system component for which the source metric is available ("source system component type") and each of the related metrics are defined by a type of a system for which the related metric is available ("related system component type").); establishing, using the one or more processors, a link between at least one data source associated with the deployed system infrastructure and the metric pipeline template based on user input via the GUI (See paragraph 65 and 66
As mentioned above, the MEM system 201 references a metric dependency model 210 for determining which metrics and system components are to be analyzed. In one embodiment, the model 210 describes administrator-defined metric dependencies, with each dependency being defined by a "source" metric and one or more metrics that are deemed by the administrator to be related to the source metric ("related metrics"). In addition, the source metric is defined by a type of system component for which the source metric is available ("source system component type") and each of the related metrics are defined by a type of a system for which the related metric is available ("related system component type"). ); and generating, using the one or more processors, one or more derived metrics based at least in part on metric data obtained based on the link established between the at least one data source and the metric pipeline template (See paragraph 65 and 66 At a high level, when model 210 is formatted as XML, a MetricDependency element identifies, for each unique source metric-related metric pair specified within the metric dependency element, one or more sets of system component instances each comprising a source system component instance and a related system component instance that fits the source metric-related metric pair. More particularly, within each metric dependency element a SourceMetric element is specified. Each metric dependency element has a TargetType attribute that specifies the source system component type.).
Kapuram does not disclose wherein the metric pipeline template comprises a plurality of nodes that process inputs to generate derived metrics.
However Burnett discloses the aspect of providing, using the one or more processors, a graphical user interface (GUI), wherein the GUI provides options to visually construct a metric pipeline template to be associated with the bound system model (see paragraph 433 and fig. 20B wherein the user define a set of metrics and corresponding data source, The input field 2018 corresponding to the Description of the metric is optional and may be utilized to provide a user with additional details as to the metric.); determining, using the one or more processors, a definition for the metric pipeline template based at least in part on user input via the GUI, wherein the metric pipeline template comprises a plurality of nodes that process inputs to generate derived metrics (See paragraph 437 In some embodiments, the design palette 2004 may receive user input of an empty node for which additional user input may be received corresponding to the addition or association of a metric to the empty node (e.g., by editing the metric properties of the node as seen in FIG. 20B).).; establishing, using the one or more processors, a link between at least one data source associated with the deployed system infrastructure and the metric pipeline template based on user input via the GUI (Kapuram see fig 20B, paragraph 437 wherein the node is a input node wherein the user can select input data source wherein the input field 2020 corresponding to the Data Source of the metric represents the data source ); and generating, using the one or more processors, one or more derived metrics based at least in part on metric data obtained based on the link established between the at least one data source and the metric pipeline template (see fig. 20B and paragraph 471 wherein the defined model element is Revenue by Hour, see fig. 25A wherein the defined model element is graphed based on the input data). It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claim 2 and 12 and 17:
Kapuram and Burnett disclose The method of claim 1, wherein the GUI provides options to define the metric pipeline template as one or more input nodes, one or more analysis nodes, and one or more output nodes (Burnett see fig 20B, paragraph 437 wherein the node is a input node wherein the user can select input data source wherein the input field 2020 corresponding to the Data Source of the metric represents the data source ). It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claims 3 and 13 and 18:
Kapuram and Burnett disclose The method of claim 2, wherein establishing the link between the at least one data source associated with the deployed system infrastructure and the metric pipeline template comprises: defining the at least one data source as a source connection for the at least one input node included in the metric pipeline template (Burnett see fig. 20B and paragraph 434 The input field 2020 corresponding to the Data Source of the metric represents the data source.). It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claims 4 and 14 and 19:
Kapuram and Burnett disclose The method of claim 3, wherein the at least one data source is an indicator that is defined to select a set of metrics from the one or more data sources associated with the deployed system infrastructure (Burnett see paragraph 433 and fig. 20B wherein the user define a set of metrics and corresponding data source, The input field 2018 corresponding to the Description of the metric is optional and may be utilized to provide a user with additional details as to the metric.). It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claims 5 and 15 and 20:
Kapuram and Burnett disclose The method of claim 2, wherein the one or more analysis nodes includes a metric operation node that is configured to apply a metric operation that converts a first time series to a second time series (Burnett see fig 20B, paragraph 437 wherein the node is a input node wherein the user can select input data source wherein the input field 2020 corresponding to the Data Source of the metric represents the data source ). It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claim 6:
Kapuram and Burnett disclose The method of claim 5, wherein the metric operation includes one of: a maximum value in a time window, a minimum value in a time window, a standard deviation over a time window, a percentile over a time window, an increase over a time window, or a rate of increase over a time window (Burnett see fig 20B, paragraph 437 wherein the node is a input node wherein the user can select input data source wherein the input field 2020 corresponding to the Data Source of the metric represents the data source ). It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claim 7:
Kapuram and Burnett disclose The method of claim 2, wherein the one or more analysis nodes includes a combiner node that is configured to apply a metric operation to combine multiple time series into a single value (Burnett see fig 20B, paragraph 437 wherein the node is a input node wherein the user can select input data source wherein the input field 2020 corresponding to the Data Source of the metric represents the data source ). It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claim 8:
Kapuram and Burnett disclose The method of claim 7, wherein the metric operation includes one of: a summation, an average, or converting a count into a rate (Burnett see fig 20B, paragraph 437 wherein the node is a input node wherein the user can select input data source wherein the input field 2020 corresponding to the Data Source of the metric represents the data source ). It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claim 9:
Kapuram and Burnett disclose The method of claim 1, wherein the link between at least one data source associated with the deployed system infrastructure and the metric pipeline template is defined for a first model element of the abstract system model (Burnett see fig. 20B and paragraph 433 wherein the defined model element is Revenue by Hour, see fig. 25A wherein the defined model element is graphed based on the input data) . It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
With regard to claim 10:
Kapuram and Burnett disclose The method of claim 9, further comprising: providing the one or more derived metrics in a GUI that visually depicts the one or more model elements of the abstract system model representing the deployed system infrastructure, wherein the one or more derived metrics are provided in association with the first model element of the abstract system model, and wherein the GUI provides one or more graphs that plot the one or more derived metrics over a window of time (Burnett see fig. 20B and paragraph 471 wherein the defined model element is Revenue by Hour, see fig. 25A wherein the defined model element is graphed based on the input data) . It would have been obvious to one of ordinary skill in the art, at the time the filing was made to apply Burnett to Kapuram so the system can use nodes to receive user input to configure metric pipeline and data source and other aspects of the bound system to give the user more control.
Claim 11 is rejected for the same reason as claim 1.
Claim 16 is rejected for the same reason as claim 1.
Pertinent Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Koodli et al., Pub. No.: 20230078246 A1, discloses a method that generates the policies using metric data characterizing each network node and respective streams of input data, and are generated based on a number of objectives, including model output quality of the deployed models, and operational cost to transmit and process streams of data across the distributed network.
Rossa, Pub. No.: US2022/0147349A1: discloses a method wherein for each data atom of a plurality of data atoms being input to the composite node, and for each node of the plurality of nodes, at least one value may be generated for a per-node metric with respect to the data atom. A value for the overall metric with respect to the data atom may be generated based on the per-node metric values of the plurality of nodes. A
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DI XIAO whose telephone number is (571)270-1758. The examiner can normally be reached 9Am-5Pm est M-F.
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, Stephen Hong can be reached at (571) 272-4124. 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.
/DI XIAO/Primary Examiner, Art Unit 2178
