DETAILED ACTION
Claim 1 is cancelled. Claims 2-21 are new. Claims 2-21 are pending in the application.
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 .
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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Specification
The disclosure is objected to because of the following informalities:
The instant application is a continuation of U.S. Patent Application No. 18/135,816 which is now issued as U.S. Patent No. 12,079,668 B2 on September 3, 2024. Both the patent number and the issue date must be disclosed in the first paragraph of the specification.
Appropriate corrections are required. Applicant is advised to review the entire disclosure for further needed corrections.
Claim Objections
Claims 2-21 are objected to because of the following informalities:
Claim 2: “Interfaces” (line 5) and “a root” (lines 20-21) should have been –Interface— and –the root—, respectively.
Claims 3-12 inherit the features of claim 2 and are objected to accordingly.
Claim 6: “the system” (line 9), “the plurality” (line 9), and “unhealthy status” (line 11) should have been –system—, --a plurality—, and –unhealthy operating status—, respectively.
Claim 7 inherits the features of claim 6 and is objected to accordingly.
Claim 8: “unhealthy status” (line 2) should have been –unhealthy operating status—.
Claim 9: “the system” (line 2) should have been –system—.
Claim 10: “the system” (line 2) should have been –system—.
Claim 11: “the system” (line 2) should have been –system—.
Claim 12: “a plurality” (line 5) should have been –the plurality—.
Claim 13: “Interfaces” (line 9) and “a root” (line 25) should have been –Interface— and –the root—, respectively.
Claims 14-18 inherit the features of claim 13 and are objected to accordingly.
Claim 17: “further comprises” (lines 1-2) should have been –comprises—.
Claim 18: “the system” (line 3) should have been –system—.
Claim 19: “Interfaces” (line 6) and “a root” (lines 21-22) should have been –Interface— and –the root—, respectively.
Claims 20-21 inherit the features of claim 19 and are objected to accordingly.
Appropriate corrections are required. Applicant is advised to review the entire claims for further needed corrections.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6 and 7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 recites the limitation "the plurality of dependencies" in line 5. There is insufficient antecedent basis for this limitation in the claim. Specifically, neither claim 6 nor claim 2 disclose “a plurality of dependencies” prior to this limitation. On the other hand, claim 2 discloses “a plurality of APIs that are dependencies of the first application”. As such, it is not clear the limitation “the plurality of dependencies” in claim 6 is referring to the “dependencies” recited in claim 2 or to a different “plurality of dependencies”.
Furthermore, claim 6 recites the limitation "the system state information" in line 9 and line 12. There is insufficient antecedent basis for this limitation in the claim. It is not clear these limitations are referring to “first system state information corresponding to the first application” recited in claim 6 or to “clustering system state information” recited in claim 2.
For the following analysis, the Examiner will consider the limitations “the plurality of dependencies” and “the system state information” as referring to –the dependencies— and –the first system state information corresponding to the first application—, respectively.
Claim 7 inherits the features of claim 6 and is rejected accordingly.
Double Patenting
The non-statutory 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. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); 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); 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) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) 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/apply/applying-online/eterminal-disclaimer.
Claims 2-21 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-10, 21, and 22 of U.S. Patent No. 12,079,668 B2 (hereinafter “reference patent-01”).
Instant Application
Reference patent-01
Claim
Limitation
Claim
Limitation
2
A computer-implemented method comprising: determining, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding a first application, that the first application has an unhealthy operating status; determining, using a machine learning model, a first Application Programming Interfaces (API) that is a dependency of the first application based on a pattern of performance indicating that the first application relies on a service of the first API, wherein the machine learning model is trained to determine the pattern of performance based on clustering system state information associated with past events where monitored applications had an unhealthy operating status; determining, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding a plurality of APIs that are dependencies of the first application, that the first API is a root cause of the first application having the unhealthy operating status; identifying a resource associated with the first API, wherein a first pattern of performance indicates that the first application depends on the first API to provide the resource to the first application; determining, by the monitoring application, that the resource provided by the first API is also available from a second API, such that a same service is available from the first API and the second API; and generating, by the monitoring application and based on determining that the first API is a root cause of the first application having the unhealthy operating status, a recommended action operable to cause the first application to retrieve the resource from the second API.
1
A computer-implemented method comprising: determining, using a machine learning model, a plurality of Application Programming Interfaces (APIs) that are dependencies of a first application based on a pattern of performance indicating that the first application relies on a service of a given API, wherein the machine learning model is trained to determine the pattern of performance based on clustering system state information associated with past events where the first application had an unhealthy operating status; determining a dependency map for the first application based on the plurality of APIs, wherein one or more first APIs of the plurality of APIs are dependencies of the first application, and wherein one or more second APIs of the plurality of APIs are dependencies of each respective first API; determining, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding the first application, that the first application has an unhealthy operating status; determining, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding the plurality of APIs, that a third API in the dependency map for the first application is a root cause of the first application having the unhealthy operating status; identifying a resource associated with the third API, wherein a first pattern of performance indicates that the first application depends on the third API to provide the resource to the first application; determining, by the monitoring application, that the resource provided by the third API is also available from a fourth API, such that a same service is available from the third API and the fourth API; and generating, by the monitoring application and based on determining that the third API is the root cause of the first application having the unhealthy operating status, a recommended action operable to cause the first application to retrieve the resource from the fourth API.
3
The method of claim 2, further comprising: generating, by the monitoring application, a notification that the first application can be reconfigured to obtain the resource from the second API.
2
The method of claim 1, further comprising: generating, by the monitoring application, a notification that the first application can be reconfigured to obtain the resource from the fourth API.
4
The method of claim 2, further comprising: automatically reconfiguring the first application to implement the recommended action, such that the first application obtains the resource from the second API.
3
The method of claim 1, further comprising: automatically reconfiguring the first application to implement the recommended action, such that the first application obtains the resource from the fourth API.
5
The method of claim 2, wherein determining that the resource provided by the first API is also available from the second API comprises: provisioning resources associated with the second API, such that the same service is available from the first API and the second API.
4
The method of claim 1, wherein determining that the resource provided by the third API is also available from the fourth API comprises: provisioning resources associated with the fourth API, such that the same service is available from the third API and the fourth API.
6
The method of claim 2, wherein determining the first API is a dependency of the first application based on the pattern of performance comprises: collecting, by one or more data collecting agents and during a prior incident where the first application had the unhealthy operating status, first system state information corresponding to the first application and one or more of the plurality of dependencies; adding the collected first system state information to a training data set as a first incident record; and training the machine learning model, based on the training data set, to determine one or more patterns of performance based on the system state information of the plurality of incident records, wherein a first pattern of performance of the one or more patterns of performance indicates a potential correlation between the first application entering the unhealthy status and a first attribute of the system state information corresponding to a first dependency of the plurality of dependencies.
5
The method of claim 1, wherein determining the plurality of APIs that are dependencies of the first application based on the pattern of performance comprises: collecting, by one or more data collecting agents and during a prior incident where the first application had the unhealthy operating status, first system state information corresponding to the first application and one or more of the plurality of dependencies; adding the collected first system state information to a training data set as a first incident record; and training the machine learning model, based on the training data set, to determine one or more patterns of performance based on the system state information of the plurality of incident records, wherein a first pattern of performance of the one or more patterns of performance indicates a potential correlation between the first application entering the unhealthy status and a first attribute of the system state information corresponding to a first dependency of the plurality of dependencies.
7
The method of claim 6, wherein the first incident record further comprises information indicating a corrective action taken in response to a corresponding first incident event, and wherein determining that the resource provided by the first API is also available from the second API is based on the corrective action taken in response to the first incident event.
6
The method of claim 5, wherein the first incident record further comprises information indicating a corrective action taken in response to a corresponding first incident event, and wherein determining that the resource provided by the third API is also available from the fourth API is based on the corrective action taken in response to the first incident event.
8
The method of claim 2, wherein the first application is determined to have the unhealthy status based on whether one or more metrics associated with the first application satisfy one or more operating status thresholds.
7
The method of claim 1, wherein the first application is determined to have the unhealthy status based on whether one or more metrics associated with the first application satisfy one or more operating status thresholds.
9
The method of claim 2, wherein the first pattern of performance is a pattern of failure and indicates a potential correlation between a first attribute of the system state information corresponding to the first API and the first application entering the unhealthy operating status.
8
The method of claim 1, wherein the first pattern of performance is a pattern of failure and indicates a potential correlation between a first attribute of the system state information corresponding to the third API and the first application entering the unhealthy operating status.
10
The method of claim 2, wherein the first pattern of performance is a pattern of risk and indicates a potential correlation between a first attribute of the system state information corresponding to the first API and a level of security risk to the first application.
9
The method of claim 1, wherein the first pattern of performance is a pattern of risk and indicates a potential correlation between a first attribute of the system state information corresponding to the third dependency and a level of security risk to the first application.
11
The method of claim 2, wherein the first pattern of performance is a pattern of latency and indicates a potential correlation between a first attribute of the system state information corresponding to the first API and a latency associated with requests to the first application.
10
The method of claim 1, wherein the first pattern of performance is a pattern of latency and indicates a potential correlation between a first attribute of the system state information corresponding to the third dependency and a latency associated with requests to the first application.
12
The method of claim 2, further comprising: determining a dependency map for the first application based on the plurality of APIs; and based on the dependency map, automatically configuring the monitoring application to utilize a plurality of monitoring interfaces configured to report one or more metrics corresponding to respective APIs of the plurality of APIs.
1
determining a dependency map for the first application based on the plurality of APIs, wherein one or more first APIs of the plurality of APIs are dependencies of the first application, and wherein one or more second APIs of the plurality of APIs are dependencies of each respective first API;
determining, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding the plurality of APIs, that a third API in the dependency map for the first application is a root cause of the first application having the unhealthy operating status;
13
A computing device, comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to: determine, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding a first application, that the first application has an unhealthy operating status; determine, using a machine learning model, a first Application Programming Interfaces (API) that is a dependency of the first application based on a pattern of performance indicating that the first application relies on a service of the first API, wherein the machine learning model is trained to determine the pattern of performance based on clustering system state information associated with past events where monitored applications had an unhealthy operating status; determine, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding a plurality of APIs that are dependencies of the first application, that the first API is a root cause of the first application having the unhealthy operating status; identify a resource associated with the first API, wherein a first pattern of performance indicates that the first application depends on the first API to provide the resource to the first application; determine, by the monitoring application, that the resource provided by the first API is also available from a second API, such that a same service is available from the first API and the second API; and generate, by the monitoring application and based on determining that the first API is a root cause of the first application having the unhealthy operating status, a recommended action operable to cause the first application to retrieve the resource from the second API.
21
A computing device, comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to: determine, using a machine learning model, a plurality of Application Programming Interfaces (APIs) that are dependencies of a first application based on a pattern of performance indicating that the first application relies on a service of a given API, wherein the machine learning model is trained to determine the pattern of performance based on clustering system state information associated with past events where the first application had an unhealthy operating status; determine a dependency map for the first application based on the plurality of APIs, wherein one or more first APIs of the plurality of APIs are dependencies of the first application, and wherein one or more second APIs of the plurality of APIs are dependencies of each respective first API; determine, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding the first application, that the first application has the unhealthy operating status; determine, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding the plurality of APIs, that a third API in the dependency map for the first application is a root cause of the first application having the unhealthy operating status; identify a resource associated with the third API, wherein a first pattern of performance indicates that the first application depends on the third API to provide the resource to the first application; determine, by the monitoring application, that the resource provided by the third API is also available from a fourth API, such that a same service is available from the third API and the fourth API; and generate, by the monitoring application and based on determining that the third API is the root cause of the first application having the unhealthy operating status, a recommended action operable to cause the first application to retrieve the resource from the fourth API.
14
The computing device of claim 13, wherein the instructions cause the computing device to: generate, by the monitoring application, a notification that the first application can be reconfigured to obtain the resource from the second API.
2
The method of claim 1, further comprising: generating, by the monitoring application, a notification that the first application can be reconfigured to obtain the resource from the fourth API.
15
The computing device of claim 13, wherein the instructions cause the computing device to: automatically reconfigure the first application to implement the recommended action, such that the first application obtains the resource from the second API.
22
The computing device of claim 21, wherein the instructions further cause the computing device to: automatically reconfigure the first application to implement the recommended action, such that the first application obtains the resource from the fourth API.
16
The computing device of claim 13, wherein the instructions cause the computing device to determine that the resource provided by the first API is also available from the second API by causing the computing device to: provision resources associated with the second API, such that the same service is available from the first API and the second API.
4
The method of claim 1, wherein determining that the resource provided by the third API is also available from the fourth API comprises: provisioning resources associated with the fourth API, such that the same service is available from the third API and the fourth API.
17
The computing device of claim 13, wherein a past incident record further comprises information indicating a corrective action taken in response to a corresponding past incident event, and wherein determining that the resource provided by the first API is also available from the second API is based on the corrective action taken in response to the past incident event.
6
The method of claim 5, wherein the first incident record further comprises information indicating a corrective action taken in response to a corresponding first incident event, and wherein determining that the resource provided by the third API is also available from the fourth API is based on the corrective action taken in response to the first incident event.
18
The computing device of claim 13, wherein: the first pattern of performance is a pattern of failure and indicates a potential correlation between a given attribute of the system state information corresponding to the first API and the first application entering the unhealthy operating status, the first pattern of performance is a pattern of risk and indicates a potential correlation between a given attribute of the system state information corresponding to the first API and a level of security risk to the first application, or wherein the first pattern of performance is a pattern of latency and indicates a potential correlation between a given attribute of the system state information corresponding to the first API and a latency associated with requests to the first application.
8, 9, 10
The method of claim 1, wherein the first pattern of performance is a pattern of failure and indicates a potential correlation between a first attribute of the system state information corresponding to the third API and the first application entering the unhealthy operating status.
The method of claim 1, wherein the first pattern of performance is a pattern of risk and indicates a potential correlation between a first attribute of the system state information corresponding to the third dependency and a level of security risk to the first application.
The method of claim 1, wherein the first pattern of performance is a pattern of latency and indicates a potential correlation between a first attribute of the system state information corresponding to the third dependency and a latency associated with requests to the first application.
19
One or more non-transitory computer-readable media storing instructions that, when executed by a computing device, cause the computing device to perform steps comprising: determining, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding a first application, that the first application has an unhealthy operating status; determining, using a machine learning model, a first Application Programming Interfaces (API) that is a dependency of the first application based on a pattern of performance indicating that the first application relies on a service of the first API, wherein the machine learning model is trained to determine the pattern of performance based on clustering system state information associated with past events where monitored applications had an unhealthy operating status; determining, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding a plurality of APIs that are dependencies of the first application, that the first API is a root cause of the first application having the unhealthy operating status; identifying a resource associated with the first API, wherein a first pattern of performance indicates that the first application depends on the first API to provide the resource to the first application; determining, by the monitoring application, that the resource provided by the first API is also available from a second API, such that a same service is available from the first API and the second API; and generating, by the monitoring application and based on determining that the first API is a root cause of the first application having the unhealthy operating status, a recommended action operable to cause the first application to retrieve the resource from the second API.
21
A computing device, comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to: determine, using a machine learning model, a plurality of Application Programming Interfaces (APIs) that are dependencies of a first application based on a pattern of performance indicating that the first application relies on a service of a given API, wherein the machine learning model is trained to determine the pattern of performance based on clustering system state information associated with past events where the first application had an unhealthy operating status; determine a dependency map for the first application based on the plurality of APIs, wherein one or more first APIs of the plurality of APIs are dependencies of the first application, and wherein one or more second APIs of the plurality of APIs are dependencies of each respective first API; determine, by a monitoring application and using a monitoring interface configured to provide one or more metrics regarding the first application, that the first application has the unhealthy operating status; determine, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding the plurality of APIs, that a third API in the dependency map for the first application is a root cause of the first application having the unhealthy operating status; identify a resource associated with the third API, wherein a first pattern of performance indicates that the first application depends on the third API to provide the resource to the first application; determine, by the monitoring application, that the resource provided by the third API is also available from a fourth API, such that a same service is available from the third API and the fourth API; and generate, by the monitoring application and based on determining that the third API is the root cause of the first application having the unhealthy operating status, a recommended action operable to cause the first application to retrieve the resource from the fourth API.
20
The non-transitory computer-readable media of claim 19, wherein the instructions cause the computing device to: generate, by the monitoring application, a notification that the first application can be reconfigured to obtain the resource from the second API; or automatically reconfigure the first application to implement the recommended action, such that the first application obtains the resource from the second API.
2, 22
The method of claim 1, further comprising: generating, by the monitoring application, a notification that the first application can be reconfigured to obtain the resource from the fourth API.
The computing device of claim 21, wherein the instructions further cause the computing device to: automatically reconfigure the first application to implement the recommended action, such that the first application obtains the resource from the fourth API.
21
The non-transitory computer-readable media of claim 19, wherein determining that the resource provided by the first API is also available from the second API comprises: provisioning resources associated with the second API, such that the same service is available from the first API and the second API.
4
The method of claim 1, wherein determining that the resource provided by the third API is also available from the fourth API comprises: provisioning resources associated with the fourth API, such that the same service is available from the third API and the fourth API.
With respect to claims 2-21: Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-10, 21, and 22 of the reference patent-01 anticipates the limitations recited in claims 2-21 as identified with the above mapping.
Claims 2-4, 6-15, and 17-20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-3, 6-12, 15, 16, and 19 of U.S. Patent No. 11,663,055 B2 (from IDS filed on 08/05/2024; hereinafter “reference patent-02”) in view of Gupta et al. (US 2018/0165177 A1; from IDS filed on 08/05/2024; hereinafter “Gupta”).
With respect to claims 2-4, 6-15, and 17-20: Claims 1-3, 6-12, 15, 16, 19 of the reference patent-02 anticipates the limitations recited in claims 2-4, 6-15, and 17-20 except for the features of determining an API as the root cause for the unhealthy operating status.
However, Gupta teaches:
determining, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding a plurality of APIs that are dependencies of the first application, that the first API is a root cause of the first application having the unhealthy operating status (see e.g. Gupta, paragraph 6: "collecting and analyzing historical debug log files from hundreds of nodes in a given cluster to discover the root cause (e.g., API call formatting, payload formatting, etc.) of a single failed request")
The reference patent-02 and Gupta are analogous art because they are in the same field of endeavor: monitoring and analyzing API operational data to identify corresponding API status. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify the reference patent-02 with the teachings of Gupta. The motivation/suggestion would be to improve status analysis for identifying and debugging errors.
Claims 2-4, 8, 12-15, 19, and 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-3, 10, 15, 16, and 19 of U.S. Patent No. 11,221,854 B2 (from IDS filed on 08/05/2024; hereinafter “reference patent-03”) in view of Gupta.
With respect to claims 2-4, 8, 12-15, 19, and 20: Claims 1-3, 10, 15, 16, and 19 of the reference patent-03 anticipates the limitations recited in claims 2-4, 8, 12-15, 19, and 20 except for the features of determining an API as the root cause for the unhealthy operating status.
However, Gupta teaches:
determining, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding a plurality of APIs that are dependencies of the first application, that the first API is a root cause of the first application having the unhealthy operating status (see e.g. Gupta, paragraph 6: "collecting and analyzing historical debug log files from hundreds of nodes in a given cluster to discover the root cause (e.g., API call formatting, payload formatting, etc.) of a single failed request")
The reference patent-03 and Gupta are analogous art because they are in the same field of endeavor: monitoring and analyzing API operational data to identify corresponding API status. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify the reference patent-03 with the teachings of Gupta. The motivation/suggestion would be to improve status analysis for identifying and debugging errors.
Claims 2-4, 8, 12-15, 19, and 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 2, 9, 14, 15, 18, and 20 of U.S. Patent No. 10,747,544 B1 (from IDS filed on 08/05/2024; hereinafter “reference patent-04”) in view of Gupta.
With respect to claims 2-4, 8, 12-15, 19, and 20: Claims 1, 2, 9, 14, 15, 18, and 20 of the reference patent-04 anticipates the limitations recited in claims 2-4, 8, 12-15, 19, and 20 except for the features of determining an API as the root cause for the unhealthy operating status.
However, Gupta teaches:
determining, by the monitoring application and using a plurality of monitoring interfaces configured to provide one or more metrics regarding a plurality of APIs that are dependencies of the first application, that the first API is a root cause of the first application having the unhealthy operating status (see e.g. Gupta, paragraph 6: "collecting and analyzing historical debug log files from hundreds of nodes in a given cluster to discover the root cause (e.g., API call formatting, payload formatting, etc.) of a single failed request")
The reference patent-04 and Gupta are analogous art because they are in the same field of endeavor: monitoring and analyzing API operational data to identify corresponding API status. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify the reference patent-04 with the teachings of Gupta. The motivation/suggestion would be to improve status analysis for identifying and debugging errors.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
MacLeod et al. (US 2020/0133744 A1) discloses an application interface governance analyzer to determine dependencies between APIs via an API topological graph and database of API definitions in order to determine validity of APIs using patterned data or to determine surface anomalies or errors (e.g., if one or more API definitions are out of synch with a service being called) (see paragraph 38).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194
Prosecution Insights