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 .
Claims 1 – 20 are pending.
Response to Arguments
Applicant presents the following arguments in the 16 April 2026 response:
In sum, the Applicant submits that the claims recite statutory subject matter pursuant to 35 U.S.C. § 101. Accordingly, reconsideration and withdrawal of these rejections are respectfully requested.
Amended claim 1 recites in part, "searching, by the device, a repository of observability data to identify observability data associated with the metric of interest specified in the query, wherein the repository aggregates observability data from a plurality of sources of telemetry, instrumentation, and metrics across a plurality of management protocols." Duggal describes a resource monitor capable of querying virtual network functions for measuring KPIs. Duggal, para. [0367]-[0368]. However, a resource monitor configured to query functions is not related to a repository, let alone a repository of observability data. Duggal does not teach or suggest a repository of information as claimed and therefore cannot teach or suggest searching, by the device, a repository of observability data to identify observability data associated with the metric of interest specified in the query.
Claim 1 also recites in part, "automatically generating, by the device and in response to the identifying the observability data, output code providing protocol-specific implementation details for a management protocol associated with selected observability data for the metric of interest specified in the query, wherein the output code comprises computer programming code for use as input into at least one of a monitoring tool, a data storage tool, or a data visualization tool." Nowhere does Duggal describe generating output code of any kind, let alone output code providing protocol-specific implementation details for a management protocol associated with selected observability data for the metric of interest specified in the query. The Office Action cites to an agent executing connections and processing details to create a context aware representation of an object. The agent's execution of connections and processing details is an internal runtime operation performed by Duggal's platform to orchestrate service delivery. The agent does not automatically generate computer programming code provided to a user for use as input into a monitoring, data storage, or data visualization tool. It is a platform-level service execution mechanism, not a code generation output.
Examiner presents the following responses to Applicant’s arguments:
With respect to applicant’s argument A, Applicant's arguments have been fully considered and are persuasive in view of the amended claim language. The 35 USC 101 rejection of claims 1 – 20 are withdrawn.
With respect to applicant’s argument B, Applicant's arguments have been fully considered in view of the amended claim language, see rejection below in view of Duggal modified by Tayeb.
With respect to applicant’s argument C, Applicant's arguments have been fully considered in view of the amended claim language, see rejection below in view of Duggal modified by Tayeb.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1 – 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication 2019/0052549 issued to Duggal et al (hereinafter Duggal) in view of U.S. Patent Application Publication No. 2022/0417117 issued to Tayeb et al (hereinafter Tayeb).
As to claim 1, Duggal discloses a method, comprising:
obtaining, by a device, a query specifying a metric of interest for network infrastructure (querying resource monitor for KPI metrics including CPU and Ram metrics, network events, etc. for the network, see Duggal: Para. 0375, see also 0327, 0338, 0393, 0407 – 0409, 0467);
searching, by the device, a repository of observability data to identify observability data associated with the metric of interest specified in the query (querying the resource monitor to determine KPIs and determine if they are within range, including current and past state information for comparison, see Duggal: Para. 0338, 0368, 0375, 0409, 0411, 0422 – 0427, and 0435, see also 0073),
aggregating observability data from a plurality of sources of telemetry, instrumentation, and metrics across a plurality of management protocols (types are comprised of a set of attached implementations, with conditional, policy-based, relationships for dynamic behavior based on identity (e.g., role-based access control) and real-time interaction-context (e.g., closed-loop autonomic behavior). Implementations may reference internal libraries or a set of external services, APIs, systems, databases and devices. Conditions may represent ‘decision gateways’ with declarative policies, which may declare simple parameters to be completed with in-band metadata or may specify reflective policies with embedded queries, atomic functions, complex algorithms (e.g., other objects) prompting a broader evaluation of system state at run-time to dynamically generate a schema for a given context. Policies may reference internal libraries (e.g., local objects) or a set of external services, APIs and systems (e.g., remote objects), see Duggal: Para. 0110);
automatically generating and in response to the identifying the observability data, by the device, output code providing protocol-specific implementation details for a management protocol associated with selected observability data for the metric of interest specified in the query (the agent executes all necessary connections and processing details of the underlying elements including license keys and certifications, protocol translations, data format transformations (e.g., bus, gateway, mediator like capabilities) to construct a ‘context-aware’ representation of the Object, in real-time; and providing monitoring of task objects for policy-based event detection and monitoring, see Duggal: Para. 0118 – 0121, 0128 – 0144, and use of metamodels to provide a design environment for onboarding and composing Metamodel-based objects and an execution environment for processing the requests for those objects. In response to a request (or event), Platforms may need to identify and interpret the relevant set of objects, handle all connections, perform all necessary translations and transformations, mediate the communications between elements of the solution, and orchestrate the overall service delivery while providing for scalable and secure transactions and lifecycle management of the service and each participating element, see Duggal: Para. 0518 – 0525 and 0534); and
providing, by the device, the output code for export via a user interface (presenting metamodel for the enterprise based on desired properties and behaviors based on a metamodel-driven questionnaire, and may support “intent-based” interfaces that translate policies into dynamic implementations based on complex real-time computations of interaction context and system state. Policies specify the relevant metadata and metrics at design-time, which are interpreted at run-time to configure and control Network Functions based on closed-loop behavior, see Duggal: Para. 0518 – 0525 and 0534).
However, Duggal does not explicitly disclose wherein the output code comprises computer programming code for use as input into at least one of a monitoring tool, a data storage tool, or a data visualization tool.
Tayeb teaches searching, by the device, a repository of observability data to identify observability data associated with the metric of interest specified in the query (message being a query for shared telemetry data, relevant access information, desired metrics/measurements, etc. from other collection agents and manifests, see Tayeb: Para. 0033 – 0034), wherein the repository aggregates observability data from a plurality of sources of telemetry, instrumentation, and metrics across a plurality of management protocols (collecting instrumentation data, telemetry data, performance counters, timer injections, etc., see Tayeb: Para. 0006 – 0007, 0015, and metrics aggregator part of the observability network including telemetry pipeline, collecting platform metrics, etc., see Tayeb: Para. 0026, 0059 – 0060);
wherein the output code comprises computer programming code for use as input into at least one of a monitoring tool, a data storage tool, or a data visualization tool (instructions are of a format of a particular code language, see Tayeb: Para. 0078 – 0079, 0088 – 0089, 0092, and creating a configuration for governing/monitoring the controlled entity, including actions to be taken based on indicated inputs, data, insights or other decisions, wherein actions may include an instruction, command or indication of how a system, device, component or other element/entity should be changed, see Tayeb: Para. 0020 – 0022 and 0023 – 0027).
Duggal and Tayeb are analogous due to their disclosure of agents for monitoring and analysis of performance metrics of a network, such as telemetry data, for making decisions for operation within the network.
Therefore, it would have been obvious to one of ordinary skill in the art to modify Duggal’s use of agents for monitoring of task objects for policy-based event detection and monitoring with Tayeb’s use of aggregating telemetry, metrics and instrumentation data stored by various collection agents for storage at the collection agent and output actions comprising computer code language formatted instructions based on the collected data for governing/monitoring of entities in order to provide a telemetry redundant measurement avoidance protocol that solves redundant data collection problems in telemetry systems (see Tayeb: Abstract and [0002]), which would provide an expected improvement in Duggal’s data monitoring and collection system.
As to claim 2, Duggal modified by Tayeb discloses the method as in claim 1, further comprising:
refining the observability data associated with the metric of interest to selectable observability data relevant to a specific platform (the agent executes all necessary connections and processing details of the underlying elements including license keys and certifications, protocol translations, data format transformations (e.g., bus, gateway, mediator like capabilities) to construct a ‘context-aware’ representation of the Object, in real-time; and providing monitoring of task objects for policy-based event detection and monitoring, see Duggal: Para. 0118 – 0121, 0128 – 0144, and use of metamodels to provide a design environment for onboarding and composing Metamodel-based objects and an execution environment for processing the requests for those objects. In response to a request (or event), Platforms may need to identify and interpret the relevant set of objects, handle all connections, perform all necessary translations and transformations, mediate the communications between elements of the solution, and orchestrate the overall service delivery while providing for scalable and secure transactions and lifecycle management of the service and each participating element, see Duggal: Para. 0518 – 0525 and 0534).
As to claim 3, Duggal modified by Tayeb discloses the method as in claim 2, wherein the selectable observability data relevant to the specific platform includes observability data compatible with one or more of an operating system version, a supported hardware platform, or a supported network data model associated with the network infrastructure (Metamodel example described herein is refreshingly un-opinionated (i.e. relaxed constraints). It conceptually allows for the modeling of any virtual function (e.g. NFV, IoT, Big Data, or Enterprise application), any protocol (e.g. NETCONF/YANG, SNMP/MIB, HTTP/REST, SOAP/WSDL), any components (e.g. orchestrators, controllers, databases, operating systems) and any target hosts (e.g. VMware, OpenStack, Docker, Bare Metal). Rather than constrain design, it supports the modeling of real-world complexity. Of course, the Metamodel is just a pattern. It doesn't do anything by itself. The onus falls on implementations to be able to process Metamodel-based object, see Duggal: Para. 0515 – 0525 and 0534).
As to claim 4, Duggal modified by Tayeb discloses the method as in claim 1, wherein the protocol-specific implementation details include an authentication method for the management protocol associated with the metric of interest specified in the query (communication requirements are determined. In some embodiments, the VIM object is queried to determine the correct management ports and connection policies. In this case, HTTP/REST will be used for the communication protocol, JSON will be the payload format and an XAuth authentication scheme is in place. An interaction model is determined. In some embodiments, based on the earlier generated plan and the VIM object, it is determined that the interaction model will consist of an initiate authentication request directed by the XAuth authentication scheme using REST, then a series of API calls translated directly from the network service instantiation plan configured per the details of each related VNF package object, see Duggal: Para. 0259 – 0266).
As to claim 5, Duggal modified by Tayeb discloses the method as in claim 1, wherein the protocol-specific implementation details include a payload definition for the management protocol associated with the metric of interest specified in the query (communication requirements are determined. In some embodiments, the VIM object is queried to determine the correct management ports and connection policies. In this case, HTTP/REST will be used for the communication protocol, JSON will be the payload format and an XAuth authentication scheme is in place, see Duggal: Para. 0259 – 0266, 0271 – 0277, 0306, 0329).
As to claim 6, Duggal modified by Tayeb discloses the method as in claim 1, wherein the observability data in the repository of observability data includes command line reference specifications ingested from command line reference repositories (configuration commands with specific format and protocol, including command line interface, see Duggal: Para. 0144, 0191 – 0196, 0234 – 0237, 0296 – 0321, 0445 – 0459 and 0469 – 0470).
As to claim 7, Duggal modified by Tayeb discloses the method as in claim 1, wherein the observability data in the repository of observability data includes application programming interface specifications ingested from associated definitions (types are comprised of a set of attached implementations, with conditional, policy-based, relationships for dynamic behavior based on identity (e.g., role-based access control) and real-time interaction-context (e.g., closed-loop autonomic behavior). Implementations may reference internal libraries or a set of external services, APIs, systems, databases and devices. Policies may reference internal libraries (e.g., local objects) or a set of external services, APIs and systems (e.g., remote objects), see Duggal: Para. 0110).
As to claim 8, Duggal modified by Tayeb discloses the method as in claim 1, wherein the observability data in the repository of observability data includes YANG model specifications imported from YANG model repositories (use of Yang model/protocol for metamodel based monitoring solution, see Duggal: Para. 0470 and 0515).
As to claim 9, Duggal modified by Tayeb discloses the method as in claim 1, wherein the observability data in the repository of observability data includes simple network management protocol management information base specifications imported from simple network management protocol management information base specification repositories (Conditions may represent ‘decision gateways’ with declarative policies, which may declare simple parameters to be completed with in-band metadata or may specify reflective policies with embedded queries, atomic functions, complex algorithms (e.g., other objects) prompting a broader evaluation of system state at run-time to dynamically generate a schema for a given context. Policies may reference internal libraries (e.g., local objects) or a set of external services, APIs and systems (e.g., remote objects), see Duggal: Para. 0110, 0140 – 0142).
As to claim 10, Duggal modified by Tayeb discloses the method as in claim 1, further comprising:
updating the observability data in the repository responsive to updates to the various sources of telemetry, instrumentation, and metrics across the different management protocols (types are comprised of a set of attached implementations, with conditional, policy-based, relationships for dynamic behavior based on identity (e.g., role-based access control) and real-time interaction-context (e.g., closed-loop autonomic behavior). Implementations may reference internal libraries or a set of external services, APIs, systems, databases and devices. Conditions may represent ‘decision gateways’ with declarative policies, which may declare simple parameters to be completed with in-band metadata or may specify reflective policies with embedded queries, atomic functions, complex algorithms (e.g., other objects) prompting a broader evaluation of system state at run-time to dynamically generate a schema for a given context. Policies may reference internal libraries (e.g., local objects) or a set of external services, APIs and systems (e.g., remote objects), see Duggal: Para. 0110, and objects may be updated and/or otherwise modified (e.g., based on additional real-time context), see Duggal: Para. 0155).
Claims 11 – 19 are rejected using similar rationale to the rejection of claims 1 – 9 above.
Claim 20 is rejected using similar rationale to the rejection of claim 1 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK E HERSHLEY whose telephone number is (571)270-7774. The examiner can normally be reached M-F: 9am-6pm.
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, Amy Ng can be reached at (571) 270-1698. 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.
/MARK E HERSHLEY/Primary Examiner, Art Unit 2164
Prosecution Insights