DETAILED ACTION
Remarks
Applicant presents a communication dated 5 June 2025 responsive to the 5 February 2025 non-final Office action (the “Previous Action”).
With the request, Applicant amends claims 1, 8 and 15.
Claims 1-5, 7-12, 14-17 and 19-20 are pending. Claims 1, 8 and 15 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
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 .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. 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 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.
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.
Response to Arguments
Rejections under 35 U.S.C. § 101
Applicant argues that the independent claims satisfy § 101. Applicant reasons that that the recited “traversing a the API environment using a test script of a potential user journey”, “generating an API dependency map to visually depict relationships”, “retrieving and monitoring success criteria associated with the functioning of the different APIs within the user journey” and “identifying APIs that are not functioning properly” recite “an explicit technological improvement to a technological problem – the mapping and identification of API errors within a complex and interconnected API environment.” (Remark, p. 10 par. 2).
Examiner respectfully disagrees and submits that retrieving and monitoring success criteria and identifying APIs that are not functioning properly are mental processes because they are forms of observation, evaluation and judgement. See M.P.E.P. § 2106.04(a). The generating an API dependency map is part of the same mental process at least because “collecting information, analyzing it and displaying certain results of the collection and analysis” is a mental process where, as here, the data analysis is recited at a high level of generality such that it can be practically performed in the human mind. M.P.E.P. § 2106.04(a)(2)(III)(A).
In other words, they are part of an abstract idea. “[A]n improvement in the abstract idea itself is (e.g., a recited fundamental economic concept) is not an improvement in technology.” M.P.E.P. § 2106.05(a)(II).
Rejections under 35 U.S.C. § 103
These arguments are moot in view of the new ground(s) of rejection below, necessitated by Applicant’s amendments.
Claim Objections
The Previous Action’s objections to claim 15 is withdrawn in view of Applicant’s amendments to that claim.
Claim Rejections - 35 USC § 112
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.
Claim 1-5, 7-12, 14-17 and 19-20 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.
As to claim 1, the claim refers to “the administrator associated with the identified developer” at line 3 page 7. There is insufficient antecedent basis for this limitation in the claim and it is unclear to which element the claim is referring. For the purposes of examination, “the administrator associated with the identified developer” will be construed as -the administrator, wherein the administrator is associated with the identified developer-.
As to claims 2-5 and 7, the claims are dependent on claim 1, do not cure the deficiencies of the claim and are rejected for the same reasons.
As to claim 8, the claim includes the same indefinite language as claim 1 and is rejected for the same reasons.
As to claims 9-12 and 14 the claims are dependent on claim 1, do not cure the deficiencies of the claim and are rejected for the same reasons.
As to claim 15, the claim includes the same indefinite language as claim 1 and is rejected for the same reasons.
As to claims 16-17 and 19-20 the claims are dependent on claim 15, do not cure the deficiencies of the claim and are rejected for the same reasons.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-5, 7-12, 14-17 and 19-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
As to claim 1, the claim recites:
[a] computer-implemented method for analyzing a test of a user journey, comprising:
receiving, at a graphical user interface (GUI), a test script representing a user journey within an application, wherein the test script specifies a sequence of application programming interfaces (APIs) that have been called as a user journeys through the application;
generating an API dependency map within the GUI, wherein the API dependency map comprises a sequential map of visual objects, the sequential map of visual objects illustrating (1) each of the APIs specified in the test script and (2) a sequence of the APIs accessed in the user journey and (3) a sequence of dependent APIs called by each of the APIs;
receiving API success criteria that defines whether an API is functioning properly, the API success criteria including latency, response time, status codes, and a failure rate;
executing the test script representing the user journey;
generating, for presentation within the GUI, a status corresponding to each of the APIs and the dependent APIs called when executing the test script, wherein the status of APIs correspond to respective visual objects selected by the user and includes a status code associated with the APIs indicative of a successful or failed operation of the APIs based on the received API success criteria;
receiving, from a user, a selection of the respective visual objects corresponding to one of the APIs or dependent APIs called when executing the test script; and
modifying the GUI to display the generated status of the selected API or dependent API within the GUI.
detecting an error in the sequence of APIs based on the API dependency map; and
generating an alert to an administrator that includes an error report identifying the error the generating including
identifying a developer associated with an API in which the error was detected;
retrieving contact information associated with the identified developer; and
transmitting the alert to the administrator associated with the developer;
retrieving data representing the status of the APIs;
transmitting a request to provide a notification of unavailable APIs corresponding to one of the visual objects in the API dependency map based on the data representing the status of the APIs
receiving an API request that specifies a service request action that specifies an intent of the API request, and a request payload that includes parameters and body data associated with the API request.
Under the broadest reasonable interpretation in light of the specification the above underlined elements recite a mental process because all steps underlined above are performable by the human mind with aid of pen and paper. Note that per MPEP § 2106.04(a)(2)(III)(A), mental processes can include collecting information, analyzing it and displaying certain results of the collection and analysis (e.g., the map, the alert and notification). The claim therefore recites an abstract idea.
None of the additional elements integrate the judicial exception into a practical application. Referring to the method as “computer-implemented”, steps being performed at or within a “graphical user interface”, providing a display by “modifying the GUI” and “retrieving” certain information amount to nothing more than implementing the abstract idea on a generic computing device. See M.P.E.P. § 2106.05(f). Referring to “executing the test script representing the user journey” only amounts to insignificant extra-solution data gathering. See M.P.E.P. § 2106.05(g). And referring to “transmitting a request” or “transmitting the alert” only appears to limit the abstract idea to a particular technological environment or field of use such as a network or the internet. See M.P.E.P. § 2106.05(h).
Looking at the claim limitations as an ordered combination yields the same conclusion as that reached when looking at the elements individually. Their collective function is merely to implement the abstract idea on a generic computing device with the necessary pre-solution data gathering in a particular technological environment.
The claim does not include additional elements that amount to significantly more than the judicial exception either, for substantially the same reasons discussed above with respect to a practical application. Note that reevaluation of the extra-solution “…executing a test script… per step 2B of the 2019 Patent Subject Matter Eligibility Guidance does not indicate that this element is anything more than what is well-understood, routine and conventional in the field, as evidenced by its incorporation into a commercially available product. (See, e.g., Hicks “Introducing Adaptive API Monitoring” at p. 5 pars. 1-2).
As to claim 2-5 and 7 the features of these claims do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because the functions of this claim are also mental and because referring to them as being performed by computer or presentation within a GUI (i.e., “test recorder”) amounts to merely implementing the steps on a generic computer.
As to claim 8, the claim recites an abstract idea without integrating the abstract idea into a practical application or amounting to significantly more for the same reasons as claim 1. The addition of a memory and processor coupled to the memory to perform the method only amounts to implementing the abstract idea on a generic computer.
As to claim 9-12 and 14, the claims recite an abstract idea without integrating the abstract idea into a practical application or amounting to significantly more for the same reasons as claim 1-7.
As to claim 15, the claim recites an abstract idea without integrating the abstract idea into a practical application or amounting to significantly more for the same reasons as claim 1. The addition of a non-transitory computer-readable medium having instructions executed by a computing device to perform the method only amounts to implementing the abstract idea on a generic computer.
The addition of the “…causing a display of the dependency map…” elements do not add integrate the abstract idea into a practical application or amount to significantly more at least because these features only further describe the abstract idea itself.
As to claim 16-17 and 19-20, the claims recite an abstract idea without integrating the abstract idea into a practical application or amounting to significantly more for the same reasons as claim 1-5 and 7.
Claim Rejections - 35 USC § 103
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.
Claims 1-4, 7-11, 14-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hicks “Introducing Adaptive API Monitoring” (art of record – hereinafter Hicks) in view of Nee et al. (US 10,924,410) (art of record – hereinafter Nee), Chauhan et al. (US 2020/0366572) (art of record – hereinafter Chauhan), Agarwal et al. (US 11,030,068) (art of record – hereinafter Agarwal) and Cooper et al. (US 2016/0103750) (art of record – hereinafter Cooper) in view of Chatterjee et al. (US 2020/0034283) (art made of record – hereinafter Chatterjee) in view of Yang et al. (WO 2020/088087) (art made of record – hereinafter Yang).
Notes: Hicks is a website and therefore has no page numbers. Page numbers cited herein refer to the copy of Hicks in the file record.
Yang is not an English document. Citations to Yang herein refer to the machine translation of the document in the file record.
As to claim 1, Hicks discloses a computer-implemented method for analyzing a test of a user journey, comprising:
receiving, at a graphical user interface (GUI), a test script representing a user journey within an application, wherein the test script specifies a sequence of application programming interfaces (APIs) that have been called as a user journeys through the application; (e.g., Hicks, p. 4: in this example an automotive e-commerce site [application] displays listings for all its vehicles but wants to ensure that any search filter applied by the user executes as expected. The workflow begins when the user connects to the website and enters their initial search criteria. The web app makes a connection to the backend to retrieve the initial results. At this point the user wants to refine the search. This generates a second API call to the backend. In this case the API calls are both iterative and conditional relative to the previous one. In this case an adaptive API framework can use the output from the first endpoint as input to the second API call; p. 5 pars 1 and 2: a synthetic transaction script emulating these API interactions can be valuable. The “node-fetch” library module provides a scripting API for creating HTTP requests. Using the module, a transaction script can make requests against one or more HTTP API endpoints, chaining data from one to the next if required [and see p. 3 Figure 3 on the right side, the script is received at a GUI]).
the APIs specified in the test script (see immediately above)
executing the test script representing the user journey (see immediately above)
each of the APIs and the dependent APIs called when executing the test script, (e.g., Hicks, p. 5 par. 1: a synthetic transaction script emulating these API interactions can be valuable in validating expected responses as well as the performance of every interaction in a workflow; p. 4 Figure 4 [see text under the figure]: performance timings for iterative calls across the complete workflow)
the APIs or dependent APIs called when executing the test script (see immediately above) and
detecting an error in the sequence of APIs (e.g., Hicks, p. 4 last par.: ThousandEyes can validate the API response and raise an alert if the check fails).
Hicks does not explicitly disclose: generating an API dependency map within the GUI, wherein the API dependency map comprises a sequential map of visual objects, the sequential map of visual objects illustrating (1) each of the APIs specified in the test script, (2) a sequence of the APIs accessed in the user journey and (3) a sequence of dependent APIs called by each of the APIs; receiving API success criteria that defines whether an API is functioning properly, the API success criteria including latency, response time, status codes, and a failure rate; generating, for presentation within the GUI, a status corresponding to each of the APIs; wherein the status of APIs correspond to respective visual objects selected by the user and include a status code associated with the APIs indicative of a successfully or failed operation of the APIs based on the received success criteria; receiving, from a user, a selection of the respective visual objects corresponding to one of the APIs or dependent APIs; modifying the GUI to display the generated status of the selected API or dependent API within the GUI; generating an alert to an administrator that includes an error report identifying the error, the generating including: identifying a developer associated with an API in which the error was detected; retrieving contact information associated with the identified developer; and transmitting the alert to the administrator associated with the developer; retrieving data representing the status of the APIs; transmitting a request to provide a notification of unavailable APIs corresponding to one of the visual objects in the API dependency map based on the data representing the status of the APIs; and receiving an API request that specifies a service request action that specifies an intent of the API request, and a request payload that includes parameters and body data associated with the API request.
However, in an analogous art, Nee discloses:
generating an API dependency map within the GUI, wherein the API dependency map comprises a sequential map of visual objects, the sequential map of visual objects illustrating (1) each of the APIs, (2) a sequence of the APIs accessed and (3) a sequence of dependent APIs called by each of the APIs; (e.g., Nee, col. 7 ll. 45-50: functionality 100 may analyze the trace data 125A-125N and generate visualization “(e.g., call graph visualizations)” based on the trace data; col. 7 l. 34-36: each call graph [map] may include a plurality of nodes [visual objects] representing [illustrating] services or APIs and one or more edges “(also referred to as call paths)” representing service interactions; col. 7 ll. 22-27: the service or APIs called to fulfill a request may be represented as a call graph that specifies [illustrates], for each particular service or API of multiple services or APIs called to fulfill the same root request, the service or API that called the particular service or API and any APIs called by the particular service or API [i.e., a sequence of APIs accessed]; col. 13 ll. 52-54: a first service that calls a second service is said to depend on the second service; col. 8 ll. 44-46: any service “(or API)” dependencies called directly or indirectly by a service “(or API)” [i.e., the called APIs noted above are dependent APIs, so a sequence of APIs called by another API is a sequence of dependent APIs]; Fig. 11 and associated text, col. 60-63: FIG. 11 illustrates a visual representation of such a call graph that may be generated [and note that although only nodes corresponding to services are shown, each node can instead represent an API as noted above]) and
APIs corresponding to one of the visual objects in the API dependency map (see immediately above).
It would have been obvious to one of ordinary skill in the art to modify the GUI, APIs specified in the test script and APIs accessed in the user journey of Hicks by generating an API dependency map within the GUI, wherein the API dependency map comprises a sequential map of visual objects, the sequential map of visual objects illustrating each of the APIs and any dependent API called by each of the APIs, as taught by Nee, as Nee would provide the advantage of a means of determining sources of errors or call patch anomalies. (See Nee, col. 27 ll. 25-40).
Further, in an analogous art, Chauhan discloses:
receiving API success criteria that defines whether an API is functioning properly, the API success criteria including latency, response time, and a failure rate (e.g., Chauhan, par. [0114]: the API monitor 601 can monitor any type of information from the APIs and/or the requests/calls. The API monitor 601 can for instance track the frequency of dropped requests/calls “(e.g., failure rate”), the latency or response time to a request/call; par. [0115]: the API monitor 601 may apply one or more policies or rules to the information, to detect breaches of the SLA [a breach of the SLA meaning the API not functioning properly]. The API 601 may apply one or more policies or rules to the information to compare against predefined thresholds. Such thresholds can be set according to metrics, thresholds, ranges, values and/or requirements in service level(s) specified in the SLA; par. [0116]: for example, service level definitions may set a maximum number of service/micro service failures over a period of time, a maximal latency in responding to a request/call, etc. [any value outside of a threshold meaning the API is not functioning properly]) and
an alert that includes an error report identifying the error (e.g., Chauhan, par. [0132]: the API monitor can provide a notification of whether the use of the APIs is within the acceptable or predetermined range. The API monitor may provide the report or notification in response to detecting a breach in the SLA or detecting a breach in the SLA beyond a certain threshold; par. [0101]: a notification or report to the consumer and/or service provider).
It would have been obvious to one of ordinary skill in the art to modify the API monitoring of Hicks by receiving API success criteria that defines whether an API is functioning properly, the API success criteria including latency, response time, and a failure rate and generating an alert to an administrator that includes an error report identifying the error, as taught by Chauhan, as Chauhan would provide the advantage of a means of defining a level of service desired or expected by a user of the API, a mean of determining when that level of service is not met and a means of informing an entity that action is needed to address the error. (See Chauhan, pars. [0002], [0004] and [0102]).
Further still, in an analogous art, Agarwal discloses:
the API success criteria including status codes (e.g., Agarwal, col. 26 ll. 13-17: an application owner is primarily interested in monitoring communication between services “(and not as interested in calls that a service makes to operations and functions within the same service)”; col. 7 ll. 60-63: services typically communicate with each other using APIs; col. 7 ll. 14-18: a span represents a call. A call may be to a separate microservice; col. 24 ll. 11-13: 7-11: the application owner can customize what constitutes an error span using a query language. For example, the owner or developer may want to consider exclusively spans that have an HTTP status code >500 as an error span).
wherein the status of APIs include[] a status code associated with the APIs indicative of a successful or failed operation of the APIs based on the received API success criteria (e.g., Agarwal, col. 24 ll. 11-13: 7-11: the application owner can customize what constitutes an error span using a query language. For example, the owner or developer may want to consider exclusively spans that have an HTTP status code >500 as an error span; Fig. 15 and associated text, col. 32 ll. 15-16: FIG. 15 illustrates the manner in which each span may be expanded; col. 32 ll. 35-39: tags 1506 “(comprising error status code values)” and 1504 “(error span flag)” are tags that comprise heuristic to identify an error span).
It would have been obvious to one of ordinary skill in the art to modify the API monitoring of Hicks by receiving API success criteria and API status monitoring of Hicks/Nee/Chauhan such that the API success criteria includes status codes and the status of APIs includes a status code indicative of successful or failed operation of the APIs based on that criteria, as taught by Agarwal, as Agarwal would provide the advantage of a means for a user to define which status codes are considered as errors and a means for a user to view the particular status code generated by an malfunctioning API. (See Agarwal, col. 24 ll. 7-11, Fig. 15 and col. 32 ll. 15-16).
Further still, in an analogous art, Cooper discloses:
generating, for presentation within the GUI, a status corresponding to each of the APIs (see immediately below)
wherein the status of APIs corresponds to respective visual objects selected by the user (e.g., Cooper, at step 910, par. [0087]: a first input “(selection via input device 130, FIG. 1)” may be detected on an API “(e.g., an API 510, FIG. 7)” in the displayed portion of the dashboard [see Figure 7, each displayed API 510 being a visual object]. At step 915, in response to detecting the first input, at least a portion of a first additional window may be opened that displays additional information for the API that was selected. The additional information may include a status of the API)
receiving, from a user, a selection of the respective visual objects corresponding to one of the APIs or dependent APIs; (see immediately above) and
modifying the GUI to display the generated status of the selected API or dependent API within the GUI (see immediately above)
retrieving data representing the status of the APIs; (see immediately below)
transmitting a request to provide a notification of unavailable APIs corresponding to one of the visual objects based on the data representing the status of the APIs; (e.g., Cooper, par. [0076]: mechanism 645 may be utilized by a user for subscribing to a notification service for receiving notifications regarding the operating status of the API; par. [0087]: for example, a notification may be configured for transmission to one or more devices of a particular person; par. [0038]: when the web server 255 has a notification or alert to be published, it posts the message to the notification server 270 via an API [the posted message being a request to provide a notification]. The notification server 270 will then determine which subscribers 275 should receive the alert. Once the subscribers 275 have been determined, the notification service 270 will deliver a copy of the notification or alert to each; par. [0079]: notification parameters may include, for examples, notify on API down [unavailable, so some indication of that status must be retrieved]).
It would have been obvious to one of ordinary skill in the art to modify the visual objects in a dependency map representing both APIs and dependent APIs called when executing a test script that and API display taught by Hicks/Nee, by incorporating displaying a status corresponding to each API including a status code indicative of a failed operation of the API in response to selecting a visual object corresponding to the API, retrieving data representing the status of the APIs; and transmitting a request to provide a notification of unavailable APIs corresponding to one of the visual objects based on the data representing the status of the APIs, as taught by Cooper, as Cooper would provide the advantages of a means for a user to view the status of whichever API a user desires, as a means of a means of displaying a failed status of an API of the user’s choice and a means of alerting appropriate persons of an API unavailable status (See Cooper, Fig. 10, par. [0087] and par. [0038]).
Further still, in an analogous art, Chatterjee discloses:
generating an alert to an administrator (see below) the generating including:
identifying a developer associated with code in which the error was detected; (e.g., Chatterjee, par. [0022]: controller 110 can identify the one or more development resources responsible for the code commit that is likely to be the cause of the problems experience. A development may include a development team)
retrieving contact information associated with the identified developer; (e.g., Chatterjee, par. [0022]: a development resource may include a development team having a designated contact person [contact information], an automated troubleshooter, or other development resources that can rectify errors detected. Controller 110 can generate an e-mail [an e-mail address also being contact information] or other electronic message to be sent to a designated contact person [i.e., the contact person or their e-mail address are retrieved]) and
transmitting the alert to the administrator associated with the developer (see immediately above)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to generation of alerts that include error reports identifying errors and APIs (i.e., code) in which errors are detected taught by Hicks/Nee/Chauhan/Agarwal and Cooper, such that the generating includes identifying a developer associated with the code in which the error was detected; retrieving contact information associated with the identified developer; and transmitting the alert to the administrator associated with the developer, as taught by Chatterjee, as Chatterjee would provide the advantage of a means of directly alerting a person that can rectify the error. (See Chatterjee, par. [0022]).
Finally, in an analogous art, Yang discloses:
receiving an API request that specifies a service request action that specifies an intent of the API request, and a request payload that includes parameters and body data associated with the API request (e.g., Yang, par. [0032]: the restful API is built on the HTTP protocol. It consists of two parts, the request part and the response part; par. [0033]: for HTTP requests you must specify: [0034]: request method [intent of the API request], such as GET/POST/PUT or other extended methods; [0037]: the request parameters; for some request methods, the parameters will be encoded into the request payload (body); par. [0038]: the request payload is stored in the request body of the HTTP protocol. For a RESTful API, it is generally text in JSON format, representing the business data).
It would have been obvious to one of ordinary skill in the art to modify the reception of requests of Hicks/Nee/Chauhan/Agarwal/Cooper/Chatterjee by incorporating receiving an API request that specifies a service request action that specifies an intent of the API request, and a request payload that includes parameters and body data associated with the API request, as taught by Yang, as Yang would provide the advantage of a means of specifying a RESTful API request, as suggested by at least Hicks (See Yang, par. [0032], Hicks at p. 2 par. 2).
As to claim 2, Hicks/Nee/Chauhan/Agarwal/Cooper/Chatterjee/Yang discloses the method of claim 1 (see rejection of claim 1 above), Hicks further discloses the APIs called when executing the test script (see rejection of claim 1) but Hicks does not explicitly disclose comprising: generating, for presentation within the GUI, the status of APIs called when executing the test script, wherein the status comprises an endpoint URL of the API and an API request.
However, in an analogous art, Cooper discloses:
generating, for presentation within the GUI, the status of APIs called, wherein the status comprises an endpoint URL of the API and an API request, (e.g., Cooper, par. [0073]: each API 510 within the API monitor 505 may be selectable to cause the web server or central management console to generates an additional window 600 that illustrates additional information for each API that includes a status 610 of the API and various measurements of performance of the API including response times 615 [i.e., the API has been called]; par. [0049]: methods of an API; par. [0082]: additional window 600 may further comprise: the request URL for each method).
It would have been obvious to one of ordinary skill in the art to modify the APIs called when executing the test script and display of API status taught by Hicks by incorporating generating, for presentation within the GUI, the status of APIs called, wherein the status comprises an endpoint URL of the API and an API request, as taught Cooper, as Cooper would provide the advantage of a means for a user to view endpoint URLs of the requested APIs. (See Cooper, pars. [0073], [0082]).
As to claim 3, Hicks/Nee/Chauhan/Agarwal/Cooper/Chatterjee/Yang discloses the method of claim 1 (see rejection of claim 1 above), Hicks further discloses the APIs that have been called in the user journey within the application and APIs called when executing the test script (see rejection of claim 1 above) but does not explicitly disclose further comprising: retrieving a response to an API request for the APIs that have been called in the user journey within the application; and generating, for presentation within the GUI, the status of APIs called when executing the test script, wherein the status comprises the response to the API request.
However, in an analogous art, Cooper discloses further comprising:
retrieving a response to an API request for the APIs that have been called; (e.g., Cooper, par. [0073]: a response from an API [if the API is responding, it has been called]; par. [0074]: additional window 600 may include details 630 of the status. For example, the details 630 may include a description of the HTTP response) and
generating, for presentation within the GUI, the status of APIs called, wherein the status comprises the response to the API request, (see immediately above).
It would have been obvious to one of ordinary skill in the art to modify the APIs called when executing the user journey and test script of Hicks by incorporating generating, for presentation within the GUI, the status of APIs called, wherein the status comprises the response to the API request, as taught Cooper, as Cooper would provide the advantage of a means for a user to view a description of the response. (See Cooper, par. [0074]).
As to claim 4, Hicks/Nee/Chauhan/Agarwal/Cooper/Chatterjee/Yang discloses the method of claim 1 (see rejection of claim 1 above), Hicks further discloses the APIs called in the user journey (see rejection of claim 1 above) does not explicitly disclose further comprising: retrieving data representing the status of the APIs; and causing a display of the API dependency map visually indicating, by the visual objects, which of the APIs called in the user journey are available or unavailable based on the data representing the status of the APIs.
However, in an analogous art, Nee discloses:
causing a display of the API dependency map, (e.g., Nee, col. 7 ll. 45-50: functionality 100 may analyze the trace data 125A-125N and generate visualization “(e.g., call graph visualizations)” based on the trace data [the call graphs of Nee being API dependency maps, generating a visualization being causing a display)
It would have been obvious to one of ordinary skill in the art to modify the GUI and APIs specified in the test script of Hicks by causing a display of an API dependency map comprising visual objects corresponding to the APIs, as taught by Nee, as Nee would provide the advantage of a means of determining sources of errors or call path anomalies. (See Nee, col. 27 ll. 25-40).
Further, in analogous art, Cooper discloses:
retrieving data representing the status of the APIs; (see below) and
causing a display visually indicating, by the visual objects, which of the APIs called in the user journey are available or unavailable based on the data representing the status of the APIs, (e.g., Cooper, par. [0061]: the web server or central management console may perform monitoring of the performance of the API for a status change “(e.g., a change in the performance status of the API, a change in the quantifiable health metric for the API and/or a change in one or more of the various measurements of performance provided for the API)”; Fig. 7 and associated text, par. [0069]: API monitor 505 including APIs 510 and visual indicators 515 of the quantifiable health metric for each API [each API entry in the GUI being a visual object]. The visual indicators 515 may be shown with lights such that viewing the lights provides a user with information regarding the health of each API, e.g., a red light may indicate to a user that the API has failed, a green light may indicate to the user that the API is fully functional).
It would have been obvious to one of ordinary skill in the art to modify APIs called in the user journey and visual objects in the API dependency map of Hicks/Nee to indicate, which of the APIs are available or unavailable based on retrieved data representing the status of the APIs, as taught by Cooper, as Cooper would provide the advantage of a means of for a user to see which of the displayed APIs are available or unavailable. (See Cooper, Fig. 7, par. [0069]).
As to claim 7, Hicks/Nee/Chauhan/Agarwal/Cooper/Chatterjee/Yang discloses the method of claim 1 (see rejection of claim 1 above), but Hicks does not explicitly disclose further comprising: retrieving requests to register the APIs, wherein the request comprises an endpoint URL of the API, a service type of the API, and an API request.
However, in an analogous art, Cooper discloses further comprising:
retrieving requests to register the APIs, wherein the request comprises an endpoint URL of the API, a service type of the API, and an API request, (e.g., Cooper, Fig. 11 and associated text, par. [0076]: a mechanism 645 that may be utilized by a user for subscribing to a notification service for receiving notifications regarding the operating status of the API. Selection of mechanism 645 may open an additional window 650 for entering and modifying subscription information [which must be retrieved if it is used]; par. [0077]: additional window 650 may be an interface. The interface may be in the form of a web-based interface having inputs to populate the subscription information. The configured subscription information may include what a user desires to be monitored with respect to the API “(e.g., host IDs/addresses [an endpoint URL of the API], host parameters, services [a service type of the API], expected parameter values, frequency of monitoring, etc.).” Additional parameters may include time between failed responses, response times and task processing times [specification of any or all of these items being a request, an API request since it all pertains to an API]).
It would have been obvious to one of ordinary skill in the art to modify the API monitoring of Hicks by incorporating retrieving requests to register the APIs, wherein the request comprises an endpoint URL of the API, a service type of the API, and an API request, as taught Cooper, as Cooper would provide the advantage of a means for a user to request notifications with respect to certain APIs and certain API parameters. (See Cooper, pars. [0076-0077]).
As to claim 8, it is a system claim whose limitations are substantially the same as claim 1. Accordingly, it is rejected for substantially the same reasons. Further limitations, disclosed by Hicks, include:
a memory; (see rejection of claim 1, a system executing scripts, APIs and presenting user interfaces would necessarily include memory) and
at least one processor coupled to the memory (see rejection of claim 1, a system executing scripts, APIs and presenting user interfaces would necessarily include a processor coupled to memory) and configured to: (see rejection of claim 1 above).
As to claim 9, it is a system claim whose limitations are substantially the same as claim 2. Accordingly, it is rejected for substantially the same reasons.
As to claim 10, it is a system claim whose limitations are substantially the same as claim 3. Accordingly, it is rejected for substantially the same reasons.
As to claim 11, it is a system claim whose limitations are substantially the same as claim 4. Accordingly, it is rejected for substantially the same reasons.
As to claim 14, it is a system claim whose limitations are substantially the same as claim 7. Accordingly, it is rejected for substantially the same reasons.
As to claim 15, it is a medium claim including limitations are substantially the same as claim 1. Those limitations are taught by or obvious over the cited art for substantially the same reasons. Further limitations, disclosed by Hicks, include:
a non-transitory computer-readable medium having instructions stored thereon that, when executed by at least one computing device, cause the at least one computing device to perform operations (see rejection of claim 1, operations such as executing scripts, APIs and presenting user interfaces would necessarily include such a medium storing instructions executed by a computer to perform the operations) comprising (see rejection of claim 1 above) and
APIs and the dependent APIs (e.g., Hicks, p. 4 last par. and Figure 5: the API calls are both iterative and conditional relative to the previous one. An adaptive API framework can use the output from the first endpoint as an input to the second API call).
Hicks does not explicitly disclose causing a display of the API dependency map visually indicating which one of the visual objects representing the APIs and the dependent APIs are available or unavailable based on the data representing the status of the APIs.
However, in an analogous art, Nee discloses:
causing a display of the dependency map (see rejection of claim 1 above)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the display of Hicks by incorporating an API dependency map, as taught by Nee, as Nee would provide the advantage of a means of determining sources of errors or call patch anomalies. (See Nee, col. 27 ll. 25-40).
Further, in an analogous art, Cooper discloses:
causing a display visually indicating which one of the visual objects representing the APIs are available or unavailable based on the data representing the status of the APIs (e.g., Cooper, Fig. 7 and associated text, par. [0069]: API monitor 505 including various APIs 510 [visual objects representing the APIs] and visual indicators 515 of the health metric for each API. The visual indicators 515 may be shown with lights such that viewing the lights provides a user with information regarding the health of each API, e.g., a red light may indicate to a user that the API has failed, a green light may indicate that the API is fully functional).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the display of a dependency map comprising visual object representing APIs comprising APIs and dependent APIs of Hicks/Nee such that the display visually indicates which ones of the visual objects representing the APIs are available or unavailable, as taught by Cooper, as Cooper would provide the advantage of a means of indicating the available or unavailable status of the APIs to a user. (See Cooper, par. [0069]).
As to claim 16, it is a medium claim whose limitations are substantially the same as claim 2. Accordingly, it is rejected for substantially the same reasons.
As to claim 17, it is a medium claim whose limitations are substantially the same as claim 3. Accordingly, it is rejected for substantially the same reasons.
As to claim 20, it is a medium claim whose limitations are substantially the same as claim 7. Accordingly, it is rejected for substantially the same reasons.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hicks (“Introducing Adaptive API Monitoring”) in view of Nee (US 10,924,410) in view of Chauhan et al. (US 2020/0366572) in view of Agarwal (US 11,030,068) in view of Cooper (US 2016/0103750) in view of Chatterjee (US 2020/0034283) in view of Yang (WO 2020/088087) in further view of Hale (US 2017/0090890) (art of record – hereinafter Hale).
As to claim 5, Hicks/Nee/Chauhan/Agarwal/Cooper/Chatterjee/Yang discloses the method of claim 1 (see rejection of claim 1 above), and further discloses one or more of the visual objects from the API dependency map (see rejection of claim 1 above) but does not further comprising: retrieving a request to add or remove one or more of the visual objects from the API dependency map.
However, in analogous art, Hale discloses further comprising:
retrieving a request to add or remove one or more of the visual objects from the dependency map, (e.g., Hale, Figs 6A-6C and associated text par. [0142]: aggregated dependency graph pane 620 shows nodes and links representing dependencies between them; par. [0145]: a user can choose different types of dependencies to be shown or hidden from the graph; par. [0147]: in response to the selection, the system updates the dependency graph to show only a graph having the selected nodes of the hierarchy. In this example, the aggregated dependency graph pane 620 no longer shows a node representing the “usr” system software code; par. [0149]: a user can choose to expand a node which can cause the system to display the immediate children nodes. Or the user can choose to collapse a node to hide its immediate children. Either of these actions triggers the system to recompute the aggregated dependencies for the nodes to be displayed).
It would have been obvious to one of ordinary skill in the art to modify the visual objects in the API dependency map of Hicks/Nee by retrieving a request to add or remove one or more visual objects from the dependency map, as taught Hale, as Hale would provide the advantage of a means of selectively hiding or showing certain dependencies in the map. (See Hale, par. [0145-0146]).
As to claim 12, it is a system claim whose limitations are substantially the same as claim 5. Accordingly, it is rejected for substantially the same reasons.
As to claim 19, it is a medium claim whose limitations are substantially the same as claim 5. Accordingly, it is rejected for substantially the same reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM EST.
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, April Blair can be reached at (571)270-1014. 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.
/TODD AGUILERA/Primary Examiner, Art Unit 2196