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 September 2025 response:
The mechanism dynamically searches a repository of observability data to identify observability data associated with the metric of interest specified in the query for generating 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 repository may be created and/or maintained by aggregating the observability data in the repository from various sources of telemetry, instrumentation, and metrics across different management protocols and/or updating the observability data in the repository responsive to updates to the various sources of telemetry, instrumentation, and metrics across the different management protocols. Further, output code can be automatically generated for use for various purposes such as input into context of monitoring, data storage, data visualization, etc. tools (e.g., InfluxDB, Grafana, etc.) for implementation, etc. of the functionality further also improves the operations related to maintaining networks and services. Because automated solutions capable of network and service monitoring cannot find, validate, and use telemetry, instrumentation, and metrics from multiple sources having multiple types of data nor generate output code for obtaining or querying a metric, the features of claim 1 clearly cannot be practically performed in the human mind, especially at the speed required to effectively maintain networks and services.
As can be clearly seen from the above claim language, the above claims provide a process that provides for For example, the claims provide for various technological improvements including those in network operations, device operations, and observability intelligence operations. The claims provide for dynamic searching of a repository and generating output code that improves how and when data is processed for monitoring networks and services. That is, the application of the claims fundamentally alters the operation of devices, networks, monitoring operations, and applications in distributed computing environments to dynamically improve application monitoring, network resource utilization and allocation, computational resource utilization and allocation, application operation, latency, LLM operation, etc. Therefore, even if the claims embody an abstract idea, the abstract idea is indeed integrated into a practical application.
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. The repository of observability data can include data from many sources and of many types such as information, metrics, telemetry data, business data, network data, etc. For example, "[t]he repository may be created and/or maintained by aggregating the observability data in the repository from various sources of telemetry, instrumentation, and metrics across different management protocols and/or updating the observability data in the repository responsive to updates to the various sources of telemetry, instrumentation, and metrics across the different management protocols." Specification, pg. 20 line 26 - pg. 21 line 2.
Claim 1 also recites in part, "generating, 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; and providing, by the device, the output code for export via a user interface." The output code is executable code that "facilitates rapid metric identification and use, without additional 'how-to-use' research." Specification, pg. 9 line 17-19. For example, "one or more code generators [can be] configured to provide a code sample associated with a given answer. For instance, in the case of user 428 asking about a particular API, API code generator 418 may generate and provide a code sample calling that API as part of the answer from metric search engine 422. Similarly, a code generator 420 may provide a code sample in Python, or other language, that suggests the authentication method and any payload definition for that management protocol (e.g., sensor path, SNMP MIB object, command, etc.). Specification, pg. 19, line 1-8. 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. This is not output code. The Office Action further cites to metamodels. The metamodels capture the relationships between domains such as NFV, Openstack, OSS/BSS, and other concepts. Duggal, para. [0505]. The metamodel is not output code. Because Duggal does not teach or suggest generating output code, Duggal cannot teach or suggest providing the output code for export via a user interface. Duggal does not teach or suggest these features of claim 1. For at least these reasons, claim 1 is allowable over Duggal. Claims 11 and 20 recite the same or similar features and are allowable at least for similar reasons.
Claim 5 recites in part, "wherein the protocol-specific implementation details include a payload definition for the management protocol associated with the metric of interest specified in the query. The method 2300 of Duggal is for coordinating resources between an enterprise web agent and VIM. Step 2304 includes determining communication requirements for the enterprise web agent to communicate with VIM by querying a VIM object. This method is not related to generating output code, let alone generating 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 protocol-specific implementation details include a payload definition for the management protocol associated with the metric of interest specified in the query.
Examiner presents the following responses to Applicant’s arguments:
With respect to applicant’s argument A, Applicant's arguments have been fully considered but they are not persuasive. Applicant argues features which are not claimed, such as dynamically searching the repository, the observability data being aggregated from various sources of telemetry, instrumentation and metrics across different management protocols and/or updating the observability data in the repository responsive to updates to the various sources of telemetry, instrumentation, and metrics across the different management protocols, and output code can be automatically generated for use for various purposes such as input into context of monitoring, data storage, data visualization, etc. tools (e.g., InfluxDB, Grafana, etc.) for implementation, etc. of the functionality further also improves the operations related to maintaining networks and services. The features cannot be weigh in view of the current claim language of the independent claims until the claims are amended to include such features. Furthermore, support within the specification is non-limiting and does not narrowly limit the current claim language to such interpretations required to go beyond the judicial exception itself. Furthermore, while the improvement of the technological environment itself does not need to be explicitly and thoroughly laid out in the claim language, the features that present such an improvement need to be present before claim interpretation could be limited in such a way to amount to significantly more than the abstract idea or integrate the abstract idea into a practical application. Such clarifications made in the arguments should be reflected in the claim language to a reasonable degree to present the application into a practical application or amount to significantly more. The claim language of the independent claims are silent as to how the repository is formed, as well as what the observability data comprises. Furthermore, the claim language does not disclose processes that utilize the output code in a manner that would be directed to the improvement, and using broadest reasonable interpretation (BRI), the protocol-specific implementation details for a management protocol associated with the selected observability data is not itself generated but details associated with data that is being output via the generated “code” for output via a user interface.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., see above) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Including such features via amendment of the claim language would allow for consideration of the features with respect to both analysis of the mental process designation itself, as well as the implementation into a practical application.
The claim currently discloses obtaining a query specifying a metric of interest for a [sic] network infrastructure, a human may reasonably read a query specifying a metric of interest. The claim also discloses searching a repository of observability data (which the specification said can “include information, metrics, telemetry data, business data, network data, etc.” on Page 11 lines 20 - 22) to identify observability data associated with the metric of interest specified in the query. A human may reasonably search a repository of “information”, “metrics”, “telemetry data”, “business data”, “network data”, etc. to identify data associated with the metrics of the query. This may be done both manually reading through a repository of undefined size and format, or through use of human mind to generate specific searches for a repository within a particular technological environment or field of use and using generic computer components. The claim further discloses generating output code providing protocol-specific implementation details for a management protocol associated with selected observability data for the metric of interest specific in the query. However, the output code itself if not clarified in the claim language and is merely disclosed has providing said details associated with the selected data, and in the final limitation providing via a user interface. The specification is non-limiting of the output code itself. Various sections of the specification discloses API code generations, generators providing code in Python or “other language”, etc. Fig. 5 does show samples of a code snippet. However, even should the output code be interpreted as being limited to such example code snippets, a human mind is fully capable of generating a code snippet, as humans have done in the field of computer programming, and doing so in a user interface using generic computing components to type such. The claimed protocol-specific implementation details for a management protocol is not disclose as being generated in response to the search and selection of observability data, but merely details for a protocol associated with the data, such as details which may be stored within the repository and read by a human. Therefore, the current claim language is non-limiting in view of the features which are not claimed, and further is reasonably performed in the human when interacting with a particular technological environment or field of use, and in the use of generic computing components. See MPEP 2106.05(f) and see MPEP 2106.05(h).
Applicant further argues “Because automated solutions capable of network and service monitoring cannot find, validate, and use telemetry, instrumentation, and metrics from multiple sources having multiple types of data nor generate output code for obtaining or querying a metric, the features of claim 1 clearly cannot be practically performed in the human mind, especially at the speed required to effectively maintain networks and services”, however, in addition to the features which are not claimed as stated above, Applicant appears to be arguing a particular technological environment, such as multiple data sources having multiple types of data or the network infrastructure and services thereof. Applicant also appears to be arguing against their own proposed invention in stating that “automated solutions capable of network and service monitoring cannot” perform the actions. If automated solutions cannot perform such actions, then the alternative would be manual or hybrid solutions involving human interaction based on processing such actions within the human mind and performed within a particular technological environment, which would fall under the current 35 USC 101 rejection. Further clarification of this argument is needed for further consideration. Furthermore, clarification of the features being argued within the claim language itself may make such clarification of the argument moot.
With respect to applicant’s argument B, Applicant's arguments have been fully considered but they are not persuasive. In addition to the above response to arguments with respect to features not claimed, the arguments appear to be arguing a particular technological environment and performing of the processes within said technological environment (networking infrastructure). However, generally linking the use of the judicial exception to a particular technological environment or field of use does not necessarily integrate the judicial exception into a practical application, see MPEP 2106.05(h). As stated above, further clarification of such argued features and others potentially able to rise to the level of integration of the judicial exception into a practical application would need to be amended within the claim language for consideration and withdraw of the current 35 USC 101 claim rejection and mapping.
With respect to applicant’s argument C, Applicant's arguments have been fully considered but they are not persuasive. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., The repository of observability data can include data from many sources and of many types such as information, metrics, telemetry data, business data, network data, etc. For example, "[t]he repository may be created and/or maintained by aggregating the observability data in the repository from various sources of telemetry, instrumentation, and metrics across different management protocols and/or updating the observability data in the repository responsive to updates to the various sources of telemetry, instrumentation, and metrics across the different management protocols." Specification, pg. 20 line 26 - pg. 21 line 2.) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Furthermore, Applicant’s specification states observability data can “include information, metrics, telemetry data, business data, network data, etc.” on Page 11 lines 20 – 22, underlined for emphasis of non-limiting language. Duggal’s searching and collection of state data for KPI metrics is the that of “information”, “metrics”, “network data”, and can be interpreted under BRI as “telemetry data”. Furthermore, the resource monitor’s holding of state information may reasonably be interpreted in view of the current claim language as a “repository” of observability data. Duggal further discloses in Para. 0073 that “Context may include the current state of one or more elements, whether they are reflecting on state of solution elements (direct through interfaces or indirect through monitoring tools or probes) during processing or “looking-up” state of one or more referenced system objects. Context may also include querying past state of one or more system objects for comparison, change history, audit or analytical purposes, etc. Further, context may include the sum of correlating the state of two or more elements or objects.” Monitoring tools such as the resource monitor having current state and past state information discloses a repository of observability data both as claimed and as supported by Applicant’s specification.
As discussed during the interview on 11 September 2025, clarifications within the claim language itself as to the repository may help distinguish from the querying of the resource monitor state data.
With respect to applicant’s argument D, Applicant's arguments have been fully considered but they are not persuasive. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e. The output code is executable code that "facilitates rapid metric identification and use, without additional 'how-to-use' research." Specification, pg. 9 line 17-19. For example, "one or more code generators [can be] configured to provide a code sample associated with a given answer. For instance, in the case of user 428 asking about a particular API, API code generator 418 may generate and provide a code sample calling that API as part of the answer from metric search engine 422. Similarly, a code generator 420 may provide a code sample in Python, or other language, that suggests the authentication method and any payload definition for that management protocol (e.g., sensor path, SNMP MIB object, command, etc.). Specification, pg. 19, line 1-8.) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
The cited portion of specification is non-limiting as to the output code of the claim language. Further disclosures of the output code and non-claimed code generators are non-limiting as to what the code comprises or how the code is generated. Limiting of such within the language itself may help in overcoming the current rejection as cited, but is not limiting on the current language using BRI.
Further, Duggal discloses:
“[0518] In this example, the Metamodel results in a software object, which is a rich metadata description of a Virtual Function package, using a consistent pattern. Instead of manually integrating a set of components together in a siloed solution with all relationships statically defined, each Metamodel-based object can be composed into any number of solutions. The business specifies “what” it wants—the objects it wants to use and the policies that govern them (i.e. an intent-based interface) and the “how”, implementation and assurance, is automated. Since nothing is hard-coded, the business can rapidly configure and easily modify their applications using Metadata without worrying about the technical details. This is not magic, it's just advanced computer science. However, it does suggest sophisticated Platform technology to bind the right objects, at the right time, for the right people based on interaction-context.
[0519] The Metamodel may allow integration effort to be shifted from upfront human decisions to run-time system decisions. In this way, the Metamodel may automate interoperability in order to liberate developers from tedious and redundant work, while enabling a new-class of ‘smart’ applications. Developers can express their intent in policies and delegate responsibility to the platform to evaluate conditions, make decisions and configure a service for a real-time interaction context. It may support a shift from imperative, procedural programming to goal-oriented, event-driven software design, where the platform handles the complexity so CSPs can focus on the business.“
Therefore, the metamodel objects and resulting “shift from imperative, procedural programming to goal-oriented, event-driven software design, where the platform handles the complexity” of Duggal, using BRI of the current claim language sufficiently discloses the output code providing protocol specific implementation details for a management protocol associated with the selected observability data.
As discussed in the 11 September 2025 interview, clarification of the code being generated and output within the claim language itself may help in differentiating the claims from the current broadest reasonable interpretation and aid in overcoming the current prior art rejection as cited. However, the current claim language in view of the non-limiting language of the specification is sufficiently disclose by Duggal.
With respect to applicant’s argument E, Applicant's arguments have been fully considered but they are not persuasive. Applicant’s specification discloses examples of the payload definition for the management protocol as “e.g., sensor path, SNMP MIB object, command, etc.”. While this is non-limiting language for the payload definition, it can range from a “sensor path” to a mere “command” as well as other formats/types. Duggal’s disclosure of a JSON payload format for the HTTP/REST protocol for the communication requirements, such as those of generated the metamodel objects and commands thereafter sufficiently disclose the current disclosure of claim 5 without further differentiation within the claim language of claim 5 or parent claim 1 which has been addressed above.
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 claim(s) recite(s) obtaining a query specifying a metric, searching a repository to identify observability data, generating output code providing protocol-specific implementation details, and providing the output code for export, which is directed to a mental process. Querying a repository and generating (ex. Writing) output code for obtaining details for a metric of interest and exporting the code may be manually performed by a user using concepts performed in the human mind, such as searching a repository and writing code.
This judicial exception is not integrated into a practical application because the limitations generally linking the use of the judicial exception to a particular technological environment or field of use, see MPEP 2106.05(h). Searching a repository and writing code for obtaining metrics of interest as a mental process being linked to a technological environment and field of use, such as monitoring network metrics and performance data, does not integrate the abstract idea itself into a practical application but is merely execution of the mental process within a technological environment and field of use.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements such as a device, network infrastructure, user interface, protocols, etc. are generally linking the use of the judicial exception to a particular technological environment or field of use, see MPEP 2106.05(h). The devices, user interface and network infrastructure are mere elements of a technological environment and generic computer components thereof. Furthermore, specific protocols for are part of the technological environment and field of use. Writing specific code to be exported to such a technological environment is not significantly more than the metal process of writing code itself.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1 – 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication 2019/0052549 issued to Duggal et al (hereinafter Duggal)
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);
generating, 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).
As to claim 2, Duggal 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 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 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 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 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 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 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 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 discloses the method as in claim 1, further comprising:
aggregating the observability data in the repository from various sources of telemetry, instrumentation, and metrics across 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
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
THIS ACTION IS MADE FINAL. 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 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