DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sharma et al.(US 10728117 B1)(hereinafter Sharma) in view of Hendrey et al.(Pub. No. US 20230318911 A1)(hereinafter Hendrey) and further in view of LAWN et al.(Pub. No. US 20230412478 A1)(hereinafter LAWN).
Regarding Claim 1, Sharma teaches A method for providing monitoring and troubleshooting for services of a cloud-based system via a cloud observability framework(Sharma, Col. 3, Ln. 10-11 ) “FIG. 5 is a network diagram of a generalized cloud-based system;” Col. 3, Ln. 16-17 “FIG. 8 is a network diagram of a cloud system for digital experience monitoring”) (Col. 22, Ln. 38-43 “Thus, the cloud system 800(e.g. cloud observability framework)provides a unique architecture that can enable digital experience monitoring, network application monitoring, infrastructure component interactions, etc. Of note, these various monitoring aspects require no additional components—the cloud system 800(e.g. cloud observability framework) leverages the existing infrastructure to provide this service.”) (Col. 22 Ln. 57-63“The cloud system 800(e.g. cloud observability framework) can enable real-time performance and behaviors for troubleshooting in the current state of the environment, historical performance and behaviors to understand what occurred or what is trending over time, predictive behaviors by leveraging analytics technologies to distill and create actionable items from the large dataset collected across the various data sources, and the like.”)(Col. 22 Ln. 64-67 and Col. 23 Ln. 1-3 “The cloud system 800(e.g. cloud observability framework) includes the ability to directly ingest any of the following data sources network device generated health data, network device generated traffic data, including flow-based data sources inclusive of NetFlow and IPFIX, raw network packet analysis to identify application types and performance characteristics, HTTP request metrics, etc.”)(Col. 24 Ln. 46-53 “Due to the inline nature and the fact the cloud system 800 is an overlay (in-between users and services/applications), the cloud system 800(e.g. cloud observability framework) enables the ability to continuously capture user experience metric data and to historically log such data in the logging and analytics 804 service. As such, a network administrator can have a long-term detailed view of the network and associated user experience.”),
Sharma does not appear to explicitly disclose the method comprising steps of: receiving a request from a user, the request being for any of monitoring and troubleshooting one or more services provided by the cloud-based system; submitting a job to one or more observability agents associated with the one or more services of the cloud-based system;
However, Hendrey teaches the method comprising steps of:
receiving a request from a user, the request being for any of monitoring and troubleshooting one or more services provided by the cloud-based system(Hendrey ([0052] “The controller 320 is the central processing and administration server for the observability intelligence platform(e.g. cloud observability framework). The controller 320 may serve a browser-based user interface (UI) 330 that is the primary interface for monitoring, analyzing, and troubleshooting the monitored environment.
[0057] “Note further that in certain embodiments, in the application intelligence model(e.g. cloud-based system), a business transaction(e.g. one or more services) represents a particular service provided by the monitored environment. For example, in an e-commerce application, particular real-world services can include a user logging in, searching for items, or adding items to the cart. In a content portal, particular real-world services can include user requests for content such as sports, business, or entertainment news. In a stock trading application, particular real-world services can include operations such as receiving a stock quote, buying, or selling stocks.”) ([0058] “Each instance of a business transaction is an execution of that transaction in response to a particular user request (e.g., a socket call, illustratively associated with the TCP layer)e.g. receiving a request from a user wherein a business transaction represents a particular service provided by the monitored environment and Performance monitoring based on business transactions can provide information on whether a service is available (e.g., users can log in, check out, or view their data), response times for users, and the cause of problems when the problems occur.”(e.g. troubleshooting);
submitting a job to one or more observability agents associated with the one or more services of the cloud-based system([0047] “Specifically, as discussed with respect to illustrative FIG. 3 below, performance within any networking environment may be monitored, specifically by monitoring applications and entities (e.g., transactions, tiers, nodes, and machines) in the networking environment using agents installed at individual machines at the entities. As an example, applications may be configured to run on one or more machines (e.g., a customer will typically run one or more nodes on a machine, where an application consists of one or more tiers(i.e. services), and a tier consists of one or more nodes). The agents collect data associated with the applications of interest and associated nodes and machines where the applications are being operated. Examples of the collected data may include performance data (e.g., metrics, metadata, etc.) and topology data (e.g., indicating relationship information), among other configured information. The agent-collected data may then be provided to one or more servers or controllers to analyze the data.”) ([0048] Examples of different agents (in terms of location) may comprise cloud agents (e.g., deployed and maintained by the observability intelligence platform provider), enterprise agents (e.g., installed and operated in a customer's network), and endpoint agents, which may be a different version of the previous agents that is installed on actual users' (e.g., employees') devices (e.g., on their web browsers or otherwise). Other agents may specifically be based on categorical configurations of different agent operations, such as language agents (e.g., Java agents, .Net agents, PHP agents, and others), machine agents (e.g., infrastructure agents residing on the host and collecting information regarding the machine which implements the host such as processor usage, memory usage, and other hardware information), and network agents (e.g., to capture network information, such as data collected from a socket, etc.).
([0049] “Each of the agents may then instrument (e.g., passively monitor activities) and/or run tests (e.g., actively create events to monitor) from their respective devices, allowing a customer to customize from a suite of tests against different networks and applications or any resource that they're interested in having visibility into, whether it's visibility into that end point resource or anything in between, e.g., how a device is specifically connected through a network to an end resource (e.g., full visibility at various layers), how a website is loading, how an application is performing, how a particular business transaction (or a particular type of business transaction) is being effected, and so on, whether for individual devices, a category of devices (e.g., type, location, capabilities, etc.), or any other suitable embodiment of categorical classification”) ([0050] “FIG. 3 is a block diagram of an example observability intelligence platform 300 that can implement one or more aspects of the techniques herein. The observability intelligence platform is a system that monitors and collects metrics of performance data for a network and/or application environment being monitored. At the simplest structure, the observability intelligence platform includes one or more agents 310 and one or more servers/controllers 320. Agents may be installed on network browsers, devices, servers, etc., and may be executed to monitor the associated device and/or application, the operating system of a client, and any other application, API, or another component of the associated device and/or application, and to communicate with (e.g., report data and/or metrics to) the controller(s) 320 as directed. Note that while FIG. 3 shows four agents (e.g., Agent 1 through Agent 4) communicatively linked to a single controller, the total number of agents and controllers can vary based on a number of factors including the number of networks and/or applications monitored, how distributed the network and/or application environment is, the level of monitoring desired, the type of monitoring desired, the level of user experience desired, and so on.”)([0051] “For example, instrumenting an application with agents may allow a controller to monitor performance of the application to determine such things as device metrics (e.g., type, configuration, resource utilization, etc.), network browser navigation timing metrics, browser cookies, application calls and associated pathways and delays, other aspects of code execution, etc. Moreover, if a customer uses agents to run tests, probe packets may be configured to be sent from agents to travel through the Internet, go through many different networks, and so on, such that the monitoring solution gathers all of the associated data (e.g., from returned packets, responses, and so on, or, particularly, a lack thereof)i.e. submitting a job to one or more observability agents. Illustratively, different “active” tests may comprise HTTP tests (e.g., using curl to connect to a server and load the main document served at the target), Page Load tests (e.g., using a browser to load a full page—i.e., the main document along with all other components that are included in the page), or Transaction tests (e.g., same as a Page Load, but also performing multiple tasks/steps within the page (e.g., load a shopping website, log in, search for an item, add it to the shopping cart, etc.);
Sharma and Hendrey are analogues in they are both in the same field of cloud monitoring utilities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma to incorporate the teachings of Hendrey receiving a request from a user, the request being for any of monitoring and troubleshooting one or more services provided by the cloud-based system; submitting a job to one or more observability agents associated with the one or more services of the cloud-based system. Doing so would aid in how large scale data collection and custom endpoints are provided as platform services. [0026] Hendrey
Sharma and Hendrey do not appear to explicitly disclose receiving a response from the one or more observability agents, the response including metrics associated with the one or more services.
However, LAWN teaches receiving a response from the one or more observability agents, the response including metrics associated with the one or more services(LAWN [0022] “FIG. 1 is a schematic diagram illustrating a system for orchestrating deployment of network services. A system 100 comprises a network service (NS) 102, other network services 104, an observability framework 106, an orchestration agent 116, and three network functions (NFs(e.g. observability agents)) 110, 112, 114. A human operator 108 is able to access observability framework in order to view data and is able to access orchestration agent 116. However, it is not essential for human operator 108 to be present as in some cases the technology is fully automated without the involvement of a human operator.”)([0023] “As described above NSs may comprise one or more NFs. In the example of system 100 the NS 102 comprises at least three NFs 110, 112, 114. The NS 102 is a VoIP telephony or video telephony service or any other type of network service. The NFs 110, 112, 114 are virtual NFs, physical NFs or cloud NFs. The NF 110 is a router, load balancer or any other type of NF.”)([0024] “As part of general observability requirements NFs(e.g. observability agents) report log streams of events along with status and performance metrics. These allow an operator to observe the specific status of the individual NFs. Each type of NF produces this monitoring data with formatting and content specific to that type. As NSs often comprise many different types of NFs, the monitoring data from a NS will contain varying content and formatting. In the system 100 this monitoring data from the NFs of the NS is used to decide on actions in the system. For example the actions maybe to make decisions about further deployment. For example when deciding to further deploy other NSs 104. This could be at other sites, or for different operators at a same site. This is more efficient than existing systems because it makes use of the monitoring data that is already produced by the NFs. However, as discussed the monitoring data is specific to NFs and not all of the monitoring data will be useful to determine the actions on further deployment. As part of the deployment the NFs 110, 112, 114 are sometimes upgraded and therefore lead to unpredictable effects on the behavior of the NS.”)([0025] “The NFs(e.g. observability agents) 110, 112, 114 forward monitoring data, which is log streams and/or metrics, to the observability framework 106. The log streams each comprise of a stream of events (such as chronological events) that have been logged at the NF/s. A non-exhaustive list of examples of the metrics in the monitoring data is any one or more of: packet loss, error rates, peak or mean response times, requests per second, jitter, thread count.”); and providing the response to the user ([0026] “The observability framework allows an operator 108(i.e. user) to observe this monitoring data.”)
Sharma, Hendrey and LAWN are analogues in they are all in the same field of cloud monitoring utilities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma in view of Hendrey to incorporate the teachings of LAWN receiving a response from the one or more observability agents, the response including metrics associated with the one or more services; and providing the response to the user. Doing so would solve any or all of the disadvantages of known network service deployment and orchestration systems. [0004] LAWN
Regarding Claim 8, claim 8 is a non-transitory computer-readable medium of claim 8 that recites similar limitations as claim 1, therefore, is rejected based on the same rational as claim 1, outlined above, Sharma further teaches, a non-transitory computer-readable medium comprising instructions for providing monitoring and troubleshooting for services of a cloud-based system via a cloud observability framework that, when executed (Sharma Col. 30 Ln. 46-65 “a non-transitory computer-readable storage medium having computer readable code stored thereon for programming a computer, server, appliance, device, processor, circuit, etc. each of which may include a processor to perform functions as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by a processor or device (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause a processor or the device to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.”),
Regarding Claim 15, claim 15 is a cloud-based system of claim 15, that recites similar limitations as claim 1, therefore, is rejected based on the same rational as claim 1, outlined above, Sharma further teaches a cloud-based system comprising:
one or more processors(Sharma Col. 30 Ln. 20-23 “It will be appreciated that some embodiments described herein may include one or more generic or specialized processors (“one or more processors”) such as microprocessors;”); and
memory storing computer-executable instructions for providing monitoring and troubleshooting for services of the cloud-based system via a cloud observability framework that, when executed(Sharma, Col. 3, Ln. 10-11 ) “FIG. 5 is a network diagram of a generalized cloud-based system;” Col. 3, Ln. 16-17 “FIG. 8 is a network diagram of a cloud system for digital experience monitoring”) (Col. 22, Ln. 38-43 “Thus, the cloud system 800(e.g. cloud observability framework) (Sharma Col. 30 Ln. 46-65 “a non-transitory computer-readable storage medium having computer readable code stored thereon for programming a computer, server, appliance, device, processor, circuit, etc. each of which may include a processor to perform functions as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by a processor or device (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause a processor or the device to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.”)
Regarding Claim 2, Sharma in view of Hendrey and further in view of LAWN teaches the method of claim 1, outlined above.
Sharma further discloses wherein the steps further comprise:
providing a real-time status of the request to the user between receiving the request
and providing the response (Sharma Col. 27 Ln. 25-32 “The network dashboard can also include a network path trace criteria which specifies endpoints, destination, users, frequency, metrics, and threshold criteria (“alert in case”). Also, the network dashboard can include a real-time path trace view that illustrates a selected user to a selected application where real-time monitoring occurs which specifies endpoints, destination, users, frequency, metrics, and threshold criteria (“alert in case”). (Col. 21 Ln. 43-53) “FIG. 9 is a network diagram of a cloud system 800 for digital experience monitoring. The cloud system 800 brings aspects of FIGS. 1-8 into a single architecture that is leveraged by the systems and methods to provide real-time, continuous digital experience monitoring, as opposed to conventional approaches. A key aspect of the architecture of the cloud system 800 is the inline monitoring. This means data is accessible in real-time for individual users from end-to-end”(i.e. receiving the request and providing the response).
Regarding Claim 9, claim 9 is the non-transitory computer-readable medium of claim 8, that recites similar limitations as claim 2, therefore, is rejected based on the same rational as claim 2, outlined above.
Regarding Claim 16, claim 16 is the cloud-based system of claim 15, that recites similar limitations as claim 2, therefore, is rejected based on the same rational as claim 2, outlined above.
Regarding Claim 3, Sharma in view of Hendrey and further in view of LAWN teaches the method of claim 1, outlined above.
While Sharma discloses providing the response to the user is via a User Interface (UI) Col. 3 Ln. 22-25 “FIGS. 11-24 are various screenshots of a Graphical User Interface (GUI) associated with the analysis service to display, report, and provide a drill-down of the User Experience (UEX) scores, which indicate providing the response to the user is a User Interface (UI), however Sharma and LAWN do not appear to explicitly disclose wherein the response includes graphical representations of the metrics associated with the one or more services.
However, Hendrey teaches wherein providing the response to the user is via a User Interface (UI), and wherein the response includes graphical representations of the metrics associated with the one or more services(Hendrey [0052] “The controller 320 may serve a browser-based user interface (UI) 330 that is the primary interface for monitoring, analyzing, and troubleshooting the monitored environment. Specifically, the controller 320 can receive data from agents 310 (and/or other coordinator devices), associate portions of data (e.g., topology, business transaction end-to-end paths and/or metrics, etc.), communicate with agents to configure collection of the data (e.g., the instrumentation/tests to execute), and provide performance data and reporting through the interface 330. The interface 330 may be viewed as a web-based interface viewable by a client device 340. In some implementations, a client device 340 can directly communicate with controller 320 to view an interface for monitoring data. The controller 320 can include a visualization system 350 for displaying the reports and dashboards related to the disclosed technology. In some implementations, the visualization system 350 can be implemented in a separate machine (e.g., a server) different from the one hosting the controller 320.” [0060] “data/metrics collected relate to the topology and/or overall performance of the network and/or application (or business transaction) or associated infrastructure, such as, e.g., load, average response time, error rate, percentage CPU busy, percentage of memory used, etc. The controller UI can thus be used to view all of the data/metrics that the agents report to the controller, as topologies, heatmaps, graphs, lists, and so on.”).
Sharma, Hendrey and LAWN are analogues in they are all in the same field of cloud monitoring utilities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma further in view of LAWN to incorporate the teachings of Hendrey providing the response to the user is via a User Interface (UI), and wherein the response includes graphical representations of the metrics associated with the one or more services. Doing so would aid in a novel approach to solution composition, informed by elements of model-driven architecture, graph data models, and modern pull-based software lifecycle management. [0084] Hendrey
Regarding Claim 10, claim 10 is the non-transitory computer-readable medium of claim 8, that recites similar limitations as claim 3, therefore, is rejected based on the same rational as claim 3, outlined above.
Regarding Claim 17, claim 17 is the cloud-based system of claim 15, that recites similar limitations as claim 3, therefore, is rejected based on the same rational as claim 3, outlined above.
Regarding Claim 4, Sharma in view of Hendrey and further in view of LAWN teaches the method of claim 1, outlined above.
Sharma and LAWN do not appear to explicitly disclose the one or more observability agents are service- specific and tailored to specific requirements of their associated service.
However, Hendrey teaches wherein the one or more observability agents are service- specific and tailored to specific requirements of their associated service(Hendrey [0048] “Examples of different agents (in terms of location) may comprise cloud agents (e.g., deployed and maintained by the observability intelligence platform provider), enterprise agents (e.g., installed and operated in a customer's network), and endpoint agents, which may be a different version of the previous agents that is installed on actual users' (e.g., employees') devices (e.g., on their web browsers or otherwise). Other agents may specifically be based on categorical configurations of different agent operations, such as language agents (e.g., Java agents, .Net agents, PHP agents, and others), machine agents (e.g., infrastructure agents residing on the host and collecting information regarding the machine which implements the host such as processor usage, memory usage, and other hardware information), and network agents (e.g., to capture network information, such as data collected from a socket, etc.)”([0049] “Each of the agents may then instrument (e.g., passively monitor activities) and/or run tests (e.g., actively create events to monitor) from their respective devices, allowing a customer to customize from a suite of tests against different networks and applications or any resource that they're interested in having visibility into, whether it's visibility into that end point resource or anything in between, e.g., how a device is specifically connected through a network to an end resource (e.g., full visibility at various layers), how a website is loading, how an application is performing, how a particular business transaction (or a particular type of business transaction) is being effected, and so on, whether for individual devices, a category of devices (e.g., type, location, capabilities, etc.), or any other suitable embodiment of categorical classification.”).
Sharma, Hendrey and LAWN are analogues in they are all in the same field of cloud monitoring utilities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma further in view of LAWN to incorporate the teachings of Hendrey the one or more observability agents are service- specific and tailored to specific requirements of their associated service. Doing so would aid in how the solutions are available that allow customers to monitor networks and applications, whether the customers control such networks and applications, or merely use them, where visibility into such resources may generally be based on a suite of “agents” or pieces of software that are installed in different locations in different networks (e.g., around the world). [0046] Hendrey
Regarding Claim 11, claim 11 is the non-transitory computer-readable medium of claim 8, that recites similar limitations as claim 4, therefore, is rejected based on the same rational as claim 4, outlined above.
Regarding Claim 18, claim 18 is the cloud-based system of claim 15, that recites similar limitations as claim 4, therefore, is rejected based on the same rational as claim 4, outlined above.
Regarding Claim 5, Sharma in view of Hendrey and further in view of LAWN teaches the method of claim 4, outlined above.
Sharma and LAWN do not appear to explicitly disclose each of the one or more service-specific observability agents follow a unified protocol for interacting with the cloud observability framework.
However, Hendrey teaches wherein each of the one or more service-specific observability agents follow a unified protocol for interacting with the cloud observability framework(Hendrey [0026] “The platform provides some lambda functions of its own which serve as egress helper functions allowing Metrics, Events, Logs, and Traces (MELT) data to be easily transformed to OpenTelemetry Protocol (OTLP)(e.g. a unified protocol) and sent on to common ingestion. … The platform may include configurations of extensions to manage particular endpoints and data collectors for a particular tenant of the platform”)([0047] “The agents collect data associated with the applications of interest and associated nodes and machines where the applications are being operated. Examples of the collected data may include performance data (e.g., metrics, metadata, etc.) and topology data (e.g., indicating relationship information), among other configured information. The agent-collected data may then be provided to one or more servers or controllers to analyze the data.”).
Sharma, Hendrey and LAWN are analogues in they are all in the same field of cloud monitoring utilities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma further in view of LAWN to incorporate the teachings of Hendrey each of the one or more service-specific observability agents follow a unified protocol for interacting with the cloud observability framework. Doing so would aid how the platform may include configurations of extensions to manage particular endpoints and data collectors for a particular tenant of the platform. [0026] Hendrey
Regarding Claim 12, claim 12 is the non-transitory computer-readable medium of claim 11, that recites similar limitations as claim 5, therefore, is rejected based on the same rational as claim 5, outlined above.
Regarding Claim 19, claim 19 is the cloud-based system of claim 18, that recites similar limitations as claim 5, therefore, is rejected based on the same rational as claim 5, outlined above.
Regarding Claim 6, Sharma in view of Hendrey and further in view of LAWN teaches the method of claim 1, outlined above, Sharma further teaches wherein the steps include performing a registration procedure for each of the one or more observability agents, thereby ensuring that the cloud observability framework is aware of all available observability agents and their functionalities(Sharma Col. 17 Ln. 58-67 and Col. 18 Ln. 1-8 “The unified agent application(e.g. observability agents) 600 is communicatively coupled to an agent manager cloud 606, and a security cloud 608. Note, the security cloud 608 can be the distributed security system 100, the cloud system 500, etc. The unified agent application 600 enables communication to enterprise private resources 612 via the security cloud 608 and to the Internet 504 via the security cloud 608. The agent manager cloud 606 can communicate with enterprise asset management 614, an enterprise Security Assertion Markup Language (SAML) Identity provider (IDP) 616, and an enterprise Certificate Authority (CA) 618. The device 604 and the unified agent application 600 can perform a registration/identity 620 process through the agent manager cloud 606 where the user identity, the user's certificates, and a device fingerprint can uniquely identify the device 604. Once registered, the unified agent application 600 has an identity 622 which can include the user, certificates, device posture, etc. and which is shared with the security cloud 608.”)( Col. 18 Ln. 11-24 “The unified agent application 600 operates on a client-server model where an IT admin enables appropriate services for end users at a Cloud Administration Server (CAS) which can be part of an agent manager cloud 606, namely the enterprise asset management 614. Every client can make a unicast request to the agent manager cloud 606 (e.g., CAS) to discover all enabled services. On acknowledging the response, the client issues a request to authenticate to each service's cloud Identity Providers, the enterprise SAML IDP 616. Authentication can be multi-factor depending upon the nature of the service. On successful authentication, server contacts Mobile Device Management (MDM) or Inventory management provider to define access control rights for the device 604. Post authorization, the device 604 is successfully enrolled into the agent manager cloud 606 which tracks and monitors all behavior of the device 604.”)(Col. 17 Ln. 48-49 “The unified agent application 600 is executed on a mobile device 604.”).
Regarding Claim 13, claim 13 is the non-transitory computer-readable medium of claim 8, that recites similar limitations as claim 6, therefore, is rejected based on the same rational as claim 6, outlined above.
Regarding Claim 20, claim 20 is the cloud-based system of claim 15, that recites similar limitations as claim 6, therefore, is rejected based on the same rational as claim 6, outlined above.
Regarding Claim 7, Sharma in view of Hendrey and further in view of LAWN teaches the method of claim 1, outlined above.
Sharma and LAWN do not appear to explicitly disclose the cloud observability framework is adapted to submit jobs to specific observability agents based on the one or more services associated with the request.
However, Hendrey teaches wherein the cloud observability framework is adapted to submit jobs to specific observability agents based on the one or more services associated with the request(Hendrey [0047] “As an example, applications may be configured to run on one or more machines (e.g., a customer will typically run one or more nodes on a machine, where an application consists of one or more tiers, and a tier consists of one or more nodes). The agents collect data associated with the applications of interest and associated nodes and machines where the applications are being operated. Examples of the collected data may include performance data (e.g., metrics, metadata, etc.) and topology data (e.g., indicating relationship information), among other configured information. The agent-collected data may then be provided to one or more servers or controllers to analyze the data.”).
Sharma, Hendrey and LAWN are analogues in they are all in the same field of cloud monitoring utilities. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sharma further in view of LAWN to incorporate the teachings of Hendrey the cloud observability framework is adapted to submit jobs to specific observability agents based on the one or more services associated with the request. Doing so would aid in how the observability intelligence platform may then use these baselines to identify subsequent metrics whose values fall out of this normal range. [0059] Hendrey
Regarding Claim 14, claim 14 is the non-transitory computer-readable medium of claim 8, that recites similar limitations as claim 7, therefore, is rejected based on the same rational as claim 7, outlined above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Deliwala et al. (Pub. No. US 20230086473 A1) teaches smart retry policy for automated provisioning of online resources.
Shuvali et al. (US 10475090 B2) teaches calculating user experience scores.
AthuluruTlrumala et al. (US 10325102 B2) teaches real-time customer experience management systems and methods.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MALA BOYD whose telephone number is (571)272-6450. The examiner can normally be reached M-F 7:30-4:00.
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 Eleni Shiferaw can be reached at (571) 272-3867. 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.
/Mala Boyd/Patent ExaminerArt Unit 2497
/ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497
Prosecution Insights