Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
1. This action is responsive to the application filed on August 15, 2024.
2. Claims 1-20 have been examined.
Claim Objections
3. Claims 4, 13, and 19 are objected to and considered to read as:
Claim 4. The method of claim 3, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system application.
Claim 13. The non-transitory computer-readable medium of claim 12, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system application.
Claim 19. The computing device of claim 18, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system application.
Claim Rejections - 35 USC 101
4. 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.
5. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 10, and 16 are within at least one of the four categories of patent eligible subject matter.
Prong 1, Step 2A: under its broadest reasonable interpretation, accessing, by a computing device, a target code for implementing an application; identifying, by the computing device, a plurality of respective addresses for one or more factors; generating, by the computing device, an interval tree comprising a root node and one or more function nodes corresponding to at least one of the one or more factors; in response to the target code invoking at least one of the one or more factors, intercepting, by the computing device, data communicated between the target code and the plurality of respective addresses; and storing, by the computing device, the data as a function node in the interval tree cover performance of the limitation in the mind but for the recitation of a generic processing device. Thus these claim limitations fall within the "Mental Processes" grouping of abstract ideas under Prong 1 Step 2A.
Prong 2, Step 2A: the judicial exception is not integrated into a practical application. Additional elements (computing device, non-transitory computer-readable medium, memories, processors) are recited at high level of generality. Accordingly, these elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea according to MPEP 2106.05(g).
Prong 2, Step 2B: the additional elements, considering them both individually and in combination, are not sufficient to amount to significantly more than the judicial exception itself. As discussed above, elements that are mere use of generic computer elements to implement the abstract idea, and the processes are insignificant extra-solution activity which are recognized as well-understood, routine, conventional activity, according to MPEP 2106.05(d). Accordingly, the claim does not appear to be patent eligible under 35 USC 101.
Claim 2: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 3: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 4: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 5: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 6: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 7: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 8: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 9: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 11: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 12: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 13: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 14: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 15: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 17: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 18: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 19: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Claim 20: as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
Double Patenting Rejection
6. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. See In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321 (c) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent is shown to be commonly owned with this application. See 37 CFR 1.131 (c). A registered attorney or agent of record may sign a terminal disclaimer.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/ file/efs/guidance/eTD-info-l.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims of U.S. Patent No. 12,099,436. Although the claims at issue are not identical, they are not patentably distinct from each other because claims of the present application are just broader versions of the patent claims.
US Patent 12,099,436
Present Application
1. A method, comprising: accessing, by a computing device, a target code for implementing an application; identifying, by the computing device, a plurality of respective addresses for one or more functions associated with the target code or one or more variables associated with the target code; generating, by the computing device, an interval tree comprising a root node and one or more function nodes corresponding to at least one of a function or one or more variables; and in response to the target code invoking at least one of the one or more functions or the one or more variables: generating, by the computing device, an intercept function, the intercept function being configured to intercept communication between the target code and a call address, the call address being a particular address, of the plurality of respective addresses, for the at least one of the one or more functions or the one or more variables invoked by the target code; intercepting, by the computing device, data communicated between the target code and the call address; storing, by the computing device, the intercepted data as a function node in the interval tree; and transmitting, by the computing device, the interval tree to a user device.
2. The method of claim 1, wherein the intercepted data comprises program runtime information.
3. The method of claim 1, wherein the application is either a monolithic application or a distributed system application.
4. The method of claim 3, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system.
5. The method of claim 4, wherein the interval tree further comprises one or more subtrees, a subtree comprising a service node and one or more function nodes.
6. The method of claim 1, wherein the intercept function is defined by a user at the user device.
7. The method of claim 1, wherein the target code is a Python code.
8. A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a computing device, cause the computing device to: access a target code for implementing an application; identify a plurality of respective addresses for one or more functions associated with the target code or one or more variables associated with the target code; generate an interval tree comprising a root node and one or more function nodes corresponding to at least one of a function or one or more variables; and in response to the target code invoking at least one of the one or more functions or the one or more variables: generate an intercept function, the intercept function being configured to intercept communication between the target code and a call address, the call address being a particular address, of the plurality of respective addresses, for the at least one of the one or more functions or the one or more variables invoked by the target code; intercept data communicated between the target code and the call address; store the intercepted data as a function node in the interval tree; and transmit the interval tree to a user device.
9. The non-transitory computer-readable medium of claim 8, wherein the intercepted data comprises program runtime information.
10. The non-transitory computer-readable medium of claim 8, wherein the application is either a monolithic application or a distributed system application.
11. The non-transitory computer-readable medium of claim 10, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system.
12. The non-transitory computer-readable medium of claim 11, wherein the interval tree further comprises one or more subtrees, a subtree comprising a service node and one or more function nodes.
13. The non-transitory computer-readable medium of claim 8, wherein the intercept function is defined by a user at the user device.
14. The non-transitory computer-readable medium of claim 8, wherein the target code is a Python code.
15. A computing device, comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to: access a target code for implementing an application; identify a plurality of respective addresses for one or more functions associated with the target code or one or more variables associated with the target code; generate an interval tree comprising a root node and one or more function nodes corresponding to at least one of a function or one or more variables; and in response to the target code invoking at least one of the one or more functions or the one or more variables: generate an intercept function, the intercept function being configured to intercept communication between the target code and a call address, the call address being a particular address, of the plurality of respective addresses, for the at least one of the one or more functions or the one or more variables invoked by the target code; intercept data communicated between the target code and the call address; store the intercepted data as a function node in the interval tree; and transmit the interval tree to a user device.
16. The computing device of claim 15, wherein the intercepted data comprises program runtime information.
17. The computing device of claim 15, wherein the application is either a monolithic application or a distributed system application.
18. The computing device of claim 17, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system.
19. The computing device of claim 18, wherein the interval tree further comprises one or more subtrees, a subtree comprising a service node and one or more function nodes.
20. The computing device of claim 15, wherein the intercept function is defined by a user at the user device.
1. A method, comprising: accessing, by a computing device, a target code for implementing an application; identifying, by the computing device, a plurality of respective addresses for one or more factors; generating, by the computing device, an interval tree comprising a root node and one or more function nodes corresponding to at least one of the one or more factors; in response to the target code invoking at least one of the one or more factors, intercepting, by the computing device, data communicated between the target code and the plurality of respective addresses; and storing, by the computing device, the data as a function node in the interval tree.
2. The method of claim 1, wherein the data comprises program runtime information.
3. The method of claim 1, wherein the application is either a monolithic application or a distributed system application.
4. The method of claim 3, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system.
5. The method of claim 4, wherein the interval tree further comprises one or more subtrees, a subtree comprising a service node and one or more function nodes.
6. The method of claim 1, wherein the data communicated between the target code and the plurality of respective addresses is intercepted by an intercept function.
7. The method of claim 1, wherein the target code is a Python code.
8. The method of claim 1, wherein the one or more factors comprise one or more functions associated with the target code.
9. The method of claim 1, wherein the one or more factors comprise one or more variable associated with the target code.
10. A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a computing device, cause the computing device to: access a target code for implementing an application; identify a plurality of respective addresses for one or more factors; generate an interval tree comprising a root node and one or more function nodes corresponding to at least one of the one or more factors; and in response to the target code invoking at least one of the one or more factors, intercept data communicated between the target code and the plurality of respective addresses; and store the data as a function node in the interval tree.
11. The non-transitory computer-readable medium of claim 10, wherein the data comprises program runtime information.
12. The non-transitory computer-readable medium of claim 10, wherein the application is either a monolithic application or a distributed system application.
13. The non-transitory computer-readable medium of claim 12, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system.
14. The non-transitory computer-readable medium of claim 13, wherein the interval tree further comprises one or more subtrees, a subtree comprising a service node and one or more function nodes.
15. The non-transitory computer-readable medium of claim 10, wherein the data communicated between the target code and the plurality of respective addresses is intercepted by an intercept function.
16. A computing device, comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to: access a target code for implementing an application; identify a plurality of respective addresses for one or more factors associated with the target code; generate an interval tree comprising a root node and one or more function nodes corresponding to at least one of the one or more factors; and in response to the target code invoking at least one of the one or more factors, intercept data communicated between the target code and the plurality of respective addresses; and store the data as a function node in the interval tree.
17. The computing device of claim 16, wherein the data comprises program runtime information.
18. The computing device of claim 16, wherein the application is either a monolithic application or a distributed system application.
19. The computing device of claim 18, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system.
20. The computing device of claim 19, wherein the interval tree further comprises one or more subtrees, a subtree comprising a service node and one or more function nodes.
Allowable Subject Matter
7. Based on intervening claims 3, 4, and claim 5, Examiner proposes allowable subject matter:
“wherein the application is a distributed system application, the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system application, and the interval tree further comprises one or more subtrees, a subtree comprising a service node and one or more function nodes”
Incorporating this allowable subject matter into claims 1, 10, and 16, resolving the double patenting issue, and resolving the U.S.C. 101 issue would put the case in condition for allowance.
Claim Rejections – 35 USC §102
8. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
9. Claims 1-4, 6, 8-13, and 15-19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 12,099,428 to Agarwal et al. (hereafter “Agarwal”).
Claim 1.
Agarwal discloses a method, comprising:
accessing, by a computing device, a target code for implementing an application;
(130) The monitoring mode also comprises an application topology graph 830. An application topology graph (or service graph) typically decomposes an application into all its component services and draws the observed dependencies between the services so a client can identify potential bottlenecks and get a better understanding of the manner in which data flows through the software architecture. The service graph 830 also facilitates visualizing cross-service relationships between services comprised within the application and external to the application (as will be discussed further in connection with the metric events modality). In an implementation, the service graph may be created using information gleaned from the metric time series data aggregated by the aggregation module 724 discussed in connection with FIG. 7.
(138) Implementations of the monitoring service disclosed herein use the aggregated rows of metrics data created in association with the metric events modality to generate a full-context application topology graph using the metric events data (e.g., by module 522 in FIG. 5). As noted above, an application topology graph (or service graph) typically decomposes an application into all its component services and draws the observed dependencies between the services so a client can identify potential bottlenecks and get a better understanding of the manner in which data flows through the software architecture. FIG. 9 illustrates an exemplary on-screen GUI comprising an interactive topology graph for an application created from the aggregated metric events data, in accordance with implementations of the monitoring service disclosed herein. The service graph facilitates visualizing cross-service relationships between services comprised within the application and external to the application. The exemplary GUI of FIG. 9 also enables customers to track the causal chain of operations resulting in an error.
(140) FIG. 9 illustrates an on-screen GUI comprising an interactive full-context service graph 900, which is constructed for an exemplary microservices-based application using the metrics data generated in connection with the metric events modality. Each circular node (e.g., nodes associated with services 902, 904 and 906 of FIG. 9) represents a single microservice. Alternatively, in an implementation, a circular node may also represent a group of multiple microservices, where the GUI for the monitoring platform (associated with, for example, the monitoring service 306) provides a client the ability to expand the node into its sub-components.
identifying, by the computing device, a plurality of respective addresses for one or more factors (FIG.18, respective endpoint addresses for services/functions)
generating, by the computing device, an interval tree comprising a root node and one or more function nodes corresponding to at least one of the one or more factors (FIG.18, root node 1810 and endpoint nodes corresponding services/functions);
in response to the target code invoking at least one of the one or more factors, intercepting, by the computing device, data communicated between the target code and the plurality of respective addresses (FIG.18, when services/functions are invoked); and
storing, by the computing device, the data as a function node in the interval tree
(144) In some implementations, the GUI comprising service graph 900 may be configured so that the nodes themselves provide a visual indication regarding the number of errors that originated at a particular node versus errors that propagated through the particular node but originated elsewhere. In an implementation, the high-cardinality metrics data aggregated in association with the metric events modality may be used to compute the number of errors that are used to render the nodes of the service graph.
(146) It is appreciated that conventional monitoring technologies would not provide adequate means for a client to distinguish between errors that originated at the recommendation service 904 versus errors that propagated through the recommendation service 904 but originated elsewhere. By performing computations using the metrics data associated with the metric events modality, implementations of the monitoring service disclosed herein are able to render a service graph that visually indicates critical information regarding the services in an architecture, e.g., number of requests between services, the number of errors generated by a service, number of errors for which the service was the root cause, etc. The service graph 900 allows clients the ability to visually distinguish between errors that originated at the recommendation service 904 as compared with errors that simply propagated through the recommendation service 904. As shown in FIG. 9, the node associated the recommendation service 904 comprises a solid-filled circular region 966 and a partially-filled region 962, where the region 966 represents errors that originated at the recommendation service 904 while the region 962 represents errors that propagated through the recommendation service 904 but originated elsewhere (e.g., at the product catalog service 906).
(150) FIG. 10 illustrates an exemplary on-screen displayed GUI showing the manner in which a client may access SLIs pertaining to a service within an interactive topology graph, in accordance with implementations of the monitoring service disclosed herein. As shown in FIG. 10, when a client hovers the cursor over the node associated with, for example, the recommendation service 1006, a pop-up window 1008 is overlaid on the service graph 1000 comprising SLIs pertaining to the recommendation service 1006. Specifically, SLIs pertaining to Requests 1010, Errors 1012 and Latency percentiles 1014 are provided. Furthermore, in an implementation, information pertaining to Root Cause 1016 is also provided to the client.
(242) As shown in service graph 1800, the page represented by node 1810 makes calls to several endpoints (e.g., endpoints associated with nodes 1820, 1830, 1840, etc.). The endpoints correspond to resources that the page (represented by node 1810) is attempting to access. Several different types of endpoints may be displayed in service graph 1800, e.g., endpoints associated with static resources, endpoints associated with third party providers, etc. This allows a client to gain insight into the manner in which different endpoints and endpoint providers (e.g., third party providers) are influencing the end user experience. In one implementation, the size of a node associated with either a page or an endpoint provider conveys the amount of traffic related to the node (as was discussed in connection with FIG. 9).
(257) In one implementation, aggregated metrics associated with a selected node (e.g. the /cart endpoint 1940) may be displayed in a side-panel 1902. For example, requests and errors 1931 and latency 1933 associated with the/cart endpoint 1940 may be displayed in the side-panel 1902. It should be noted that metrics shown in the side-panel 1902 may be aggregated and computed using the metric events modality (e.g., using aggregated metrics from the metric event aggregation module 1722). In a different implementation, real-time metrics may also be computed using the metric time series modality (e.g., using metrics aggregated from the metric time series module 1720).
Claim 2.
Agarwal discloses the method of claim 1, wherein the data comprises program runtime information.
(144) In some implementations, the GUI comprising service graph 900 may be configured so that the nodes themselves provide a visual indication regarding the number of errors that originated at a particular node versus errors that propagated through the particular node but originated elsewhere. In an implementation, the high-cardinality metrics data aggregated in association with the metric events modality may be used to compute the number of errors that are used to render the nodes of the service graph.
(146) It is appreciated that conventional monitoring technologies would not provide adequate means for a client to distinguish between errors that originated at the recommendation service 904 versus errors that propagated through the recommendation service 904 but originated elsewhere. By performing computations using the metrics data associated with the metric events modality, implementations of the monitoring service disclosed herein are able to render a service graph that visually indicates critical information regarding the services in an architecture, e.g., number of requests between services, the number of errors generated by a service, number of errors for which the service was the root cause, etc. The service graph 900 allows clients the ability to visually distinguish between errors that originated at the recommendation service 904 as compared with errors that simply propagated through the recommendation service 904. As shown in FIG. 9, the node associated the recommendation service 904 comprises a solid-filled circular region 966 and a partially-filled region 962, where the region 966 represents errors that originated at the recommendation service 904 while the region 962 represents errors that propagated through the recommendation service 904 but originated elsewhere (e.g., at the product catalog service 906).
(150) FIG. 10 illustrates an exemplary on-screen displayed GUI showing the manner in which a client may access SLIs pertaining to a service within an interactive topology graph, in accordance with implementations of the monitoring service disclosed herein. As shown in FIG. 10, when a client hovers the cursor over the node associated with, for example, the recommendation service 1006, a pop-up window 1008 is overlaid on the service graph 1000 comprising SLIs pertaining to the recommendation service 1006. Specifically, SLIs pertaining to Requests 1010, Errors 1012 and Latency percentiles 1014 are provided. Furthermore, in an implementation, information pertaining to Root Cause 1016 is also provided to the client.
(242) As shown in service graph 1800, the page represented by node 1810 makes calls to several endpoints (e.g., endpoints associated with nodes 1820, 1830, 1840, etc.). The endpoints correspond to resources that the page (represented by node 1810) is attempting to access. Several different types of endpoints may be displayed in service graph 1800, e.g., endpoints associated with static resources, endpoints associated with third party providers, etc. This allows a client to gain insight into the manner in which different endpoints and endpoint providers (e.g., third party providers) are influencing the end user experience. In one implementation, the size of a node associated with either a page or an endpoint provider conveys the amount of traffic related to the node (as was discussed in connection with FIG. 9).
(257) In one implementation, aggregated metrics associated with a selected node (e.g. the /cart endpoint 1940) may be displayed in a side-panel 1902. For example, requests and errors 1931 and latency 1933 associated with the/cart endpoint 1940 may be displayed in the side-panel 1902. It should be noted that metrics shown in the side-panel 1902 may be aggregated and computed using the metric events modality (e.g., using aggregated metrics from the metric event aggregation module 1722). In a different implementation, real-time metrics may also be computed using the metric time series modality (e.g., using metrics aggregated from the metric time series module 1720).
Claim 3.
Agarwal discloses the method of claim 1, wherein the application is either a monolithic application or a distributed system application (FIG.9 and related text).
Claim 4.
Agarwal discloses the method of claim 3, wherein the interval tree further comprises one or more service nodes, a service node corresponding to a service in the distributed system application.
(141) In an implementation, services that are part of the client's application may be represented differently from services that are external to the client's application. For example, circular nodes (e.g., nodes associated with services 902, 904 and 906) of the exemplary application represented by service graph 900 are associated with services comprised within the client's application. By contrast, squarish nodes (e.g., nodes associated with databases dynamodb 915, Cassandra 920, ad-redis 912) are associated with services or databases that are external to the client's application.
(245) The resources or endpoints may be either be internal or external with respect to a client of the monitoring platform. In one implementation, the endpoints may relate to external resources, e.g., an external service such as a payment processor, a content delivery network (CDN), etc. Alternatively, in one implementation of the monitoring platform, the resources may be part of a backend owned by the client. More specifically, the client may own existing backend infrastructure that supports one or more of the endpoints and can, therefore, exercise control over those endpoints. For example, nodes 1820 and 1840 may correspond to endpoints that a client's backend infrastructure supports. Because nodes 1820 and 1840 correspond to endpoints that a client controls, the client may be able to glean additional information regarding the behavior of those endpoints from its own backend, where the additional information may provide a client further insight into the performance of the endpoints.
Claim 6.
Agarwal discloses the method of claim 1, wherein the data communicated between the target code and the plurality of respective addresses is intercepted by an intercept function.
(68) In one implementation, the collector 304 may comprise a beacon module 388 configured to collect all data associated with RUM sessions, e.g., users' browsing sessions, users' interactions with an application or data generated by users' web browsers, etc. The beacon module 388 may, for example, be configured to collect all the spans generated by browser instrumentation configured on a client's device or a client's web-browser. The beacon may, among other functions, enrich the spans generated at the frontend (e.g., by a browser) with additional information (e.g., with HTTP client's IP address) before forwarding the information to be ingested by the monitoring service 306. Note that the beacon module 388 may not necessarily be a component within the collector 304 but may also be implemented as a standalone module. Further note that similar to the collector 304, the beacon module 388 may be implemented within a client's on-prem software or in the cloud computing environment (e.g., in the same environment in which monitoring service 306 is implemented).
(70) In one implementation, the monitoring service 306 may be a Software as a Service (SaaS) based service offering. Alternatively, in another implementation, it may also be implemented as an on-prem application. The monitoring service 306 receives the observability data collected by the collector 304 and provides critical insights into the collected trace data to a client of the monitoring service, who may be an application owner or developer. In an implementation, the monitoring service 306 may be hosted on a computing system that includes one or more processors, memory, secondary storage and input/output controller. The computing system used for hosting the monitoring service 306 is typically a server class system that uses powerful processors, large memory resources and fast input/output systems.
(106) In addition to a Trace ID, each trace also comprises a time-stamp; using the time-stamps and the Trace IDs, the APM sessionization module 506, which is associated with APM-related spans, creates traces 508 from the incoming spans in real time and sessionizes them into discrete time windows. For example, the sessionization process may consolidate traces (from spans) within a first time window (associated with time window Y 580) before transmitting the traces to modules 520, 522 or 524. Each of the modules 520, 522 and 524 support a different modality of analysis for APM. Thereafter, the sessionization process may consolidate traces within the subsequent time window (associated with time window “Y+M” 585) before transmitting those traces to the modules 520, 522, or 524. It should be noted that the time windows associated with each of the modules 520, 522, and 524 may be different. In other words, the metric time series data may be collected over short time windows of 10 seconds each. By comparison, traces for the metric events modality (associated with the module 522) may be collected over 10 minute time windows.
Claim 8.
Agarwal discloses the method of claim 1, wherein the one or more factors comprise one or more functions associated with the target code.
(143) Each edge in the service graph 900 (e.g., the edges 922, 924 and 926) represents a cross-service dependency (or a cross-service call). The front-end service 902 depends on the recommendation service 904 because it calls the recommendation service 904. Similarly, the recommendation service 904 depends on the product catalog service 906 because it makes a call to the product catalog service 906. The directionality of the edge represents a dependency of a calling node on the node that is being called. Each of the calls passes the Trace ID for the request to the respective service being called. Further, each service called in the course of serving the request could potentially generate several spans (associated with calls to itself or other services). Each of the spans generated will then carry the Trace ID associated with the request, thereby, propagating the context for the trace. Spans with the same Trace ID are, thereafter, grouped together to compose a trace.
(156) FIG. 11 illustrates an exemplary on-screen GUI showing the manner in which a client may access SLIs pertaining to an edge within an interactive topology graph, in accordance with implementations of the monitoring service disclosed herein. The SLIs pertaining to edges are also computed using the metrics data associated with the metric events modality. As shown in FIG. 11, if a client hovers over or selects a particular edge, e.g., the edge 924 (as shown in FIG. 9) (which represents the cross-service dependency of the front-end service 902 on the product catalog service 906) a pop-up dialog box 1108 opens up on-screen that reports SLIs specific to the dependency. The “From” field 1112 represents the service that executes the call and the “To” field 1114 represents the service that is called (the service that the calling service depends on). As shown in the dialog box 1108, SLIs pertaining to the number of requests (or calls) that were made, the number of those that returned in errors, and the latency associated with servicing the requests are provided. It should be noted that a latency value 1120 of 49 ms shown in FIG. 11 for this particular dependency may be annotated directly on the edge of the service graph. For example, as shown in service graph 900 of FIG. 9, edge 924 of the service graph 900 in FIG. 9 indicates the latency value 970 (e.g., 49 ms) directly on the edge in the service graph allowing a client to efficiently gather information regarding latency associated with the dependency.
Claim 9.
Agarwal discloses the method of claim 1, wherein the one or more factors comprise one or more variable associated with the target code.
(114) A client application associated with, for example, an online retailer's website may potentially generate millions of spans from which a monitoring platform may need to extract meaningful and structured information. To organize the significant amounts of incoming span data, in an implementation, incoming spans may be automatically grouped by mapping each span to a base “span identity,” wherein a base span identity comprises some key attributes that summarize a type of span. An exemplary span identity may be represented as the following exemplary tuple: {operation, service, kind, isError, httpMethod, isServiceMesh}, where the operation field represents the name of the specific operation within a service that made the call, the service field represents the logical name of the service on which the operation took place, the kind field details relationships between spans and may either be a “server” or “client,” the isError field is a “TRUE/FALSE” flag that indicates whether a span is an error span, the httpMethod field relates to the HTTP method of the request for the associated span and the isServiceMesh field is a flag that indicates whether the span is part of a service mesh. A service mesh is a dedicated infrastructure layer that controls service-to-service communication over a network. Typically, if software has been instrumented to send data from a service mesh, the trace data transmitted therefrom may generate duplicative spans that may need to be filtered out during monitoring. Accordingly, the ‘isServiceMesh’ flag allows the analytics engine to filter out any duplicative spans to ensure the accuracy of the metrics computations.
(115) In some implementations, the tuple used to represent the span identity may include other identifying dimensions as well. For example, if a client needs visibility into metadata tags from the spans in addition to the dimensions extracted for a base span identity by default (e.g., service, operation, kind, etc.), an extended identity may be created. An extended identity supports custom dimensionalization by a client, where dimensionalization refers to the ability to extract information pertaining to additional tags or metadata in a span. An extended identity provides a customer the ability to dimensionalize the span using pre-selected dimensions. Conventional methods of monitoring by comparison did not offer customers the flexibility to add custom dimensions to streams of metric data. An extended identity comprises the span's base identity and additionally a map of the span's tag key:value pairs that matched a client's configuration settings. An exemplary extended identity may be represented as the following exemplary tuple: {operation, service, kind, isError, httpMethod, isServiceMesh, keyValueMap . . . }, where the keyValueMap field represents one or more additional tags or dimensions configured by the client to be extracted as part of the span's identity, e.g., customer name, member ID, etc.
(120) As shown in FIG. 6, in an implementation, the initiating span A comprises a trace identity that is used to emit trace metrics 640. The initiating span A helps define an identity for a trace which allows the monitoring platform to logically group together all traces that represent the same flow through an endpoint of the application. The duration of the identity for a trace is calculated as the end time of the latest span in the trace minus the start time of its initiating span. An exemplary trace identity may be represented as the following exemplary tuple: {operation, service, isError, httpMethod, isServiceMesh}, where the operation field represents the name of the specific operation within a service that made the call, the service field represents the logical name of the service on which the operation took place, the isError field is a “TRUE/FALSE” flag that indicates whether the trace is associated with an error, the httpMethod field relates to the HTTP method of the request for the associated trace and the isServiceMesh field is a flag that indicates whether the trace is part of a service mesh. The trace metrics 640 are computed after the spans have been consolidated into a trace following a sessionization process. The trace metrics are also turned into streams of metric data similar to the metric time series associated with the spans.
Claims 10-13 and 15.
These claims are medium versions, which recite the same limitations as those of claims 1-4 and 6-9, wherein all claimed limitations have been addressed and/or set forth above. Therefore, as the reference teaches all of the limitations of the above claims, it also teaches all of the limitations of these claims.
Claims 16-19.
These claims are device versions, which recite the same limitations as those of claims 1-4 and 6-9, wherein all claimed limitations have been addressed and/or set forth above. Therefore, as the reference teaches all of the limitations of the above claims, it also teaches all of the limitations of these claims.
Claim Rejections – 35 USC §103
10. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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.
11. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Agarwal in view of US 2016/0269482 to Jamjoom et al. (hereafter “Jamjoom”).
Claim 7.
Agarwal does not disclose the method of claim 1, wherein the target code is a Python code.
However, Jamjoom discloses the target code is a Python code (0110).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Jamjoom’s teaching into Agarwal‘s teaching. One would have been motivated to do so to monitor components that use supported runtimes as suggested by Jamjoom (0110).
Conclusion
12. Any inquiry concerning this communication should be directed to examiner Thuy (Twee) Dao, whose telephone/fax numbers are (571) 272 8570 and (571) 273 8570, respectively. Examiner can normally be reached from Monday to Friday, 5:30am - 2:00pm ET.
If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Hyung (Sam) Sough, can be reached at (571) 272 6799.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273 8300.
Any inquiry of a general nature of relating to the status of this application or proceeding should be directed to the TC 2100 Group receptionist whose telephone number is (571) 272 2100.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Thuy Dao/Primary Examiner, Art Unit 2192
Prosecution Insights