DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to Applicant’s Amendment filed on 4/21/2026.
Claims 1-20 are presented for examination. Claims 1, 11, 13 and 18 have been amended.
Applicant’s amendments to the specification and claims have overcome specification objection and claim objections set forth in the non-Final Office Action mailed 1/30/2026.
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 entirely 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.
Claim Objections
Claims 8, 11-12, and 20 is objected to because of the following informalities:
“the one or more inserted parameter” at line 2 of claim 8 should be: the one or more inserted parameters.
“one or more performance metric values metrics” at line 3 of claim 11 should be: one or more performance metric values. Claim 12 is objected for failing to cure the deficiency from its respective parent claim by dependency.
“one or more inserted parameters” at line 2 of claim 20 should be: the one or more inserted parameters.
Appropriate correction is required.
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.
Claims 1-20 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 pre-AIA the applicant regards as the invention.
Regarding to Claim 1, the meaning of limitation “the parameters instructing the API” is not clear. It is not clear that Applicant intends to mean at least one parameter from the one or more parameters OR the one or more parameters as whole for the particular limitations. For the purpose of examination, examiner interprets the limitation above as: at least one parameter from the one or more parameters instructing the API.
Claims 2-12 are rejected for failing to cure the deficiency from their respective parent claim by dependency. In addition,
For claim 11, the meaning of limitation “calculate one or more performance metric values metrics based on the performance data and the API information” is not clear. First of all, claim 1 already includes “one or more performance metric values”. It is not clear that whether “one or more performance metric values” from claim 11 are same values/objects as the ones from claim 1 OR not. If different, then it is not clear to one with ordinary skill in the art would distinguish these two different “one or more performance metric values” (also it is not clear that whether the specification provides support for such two different “one or more performance metric values”). If same, then claim 1 already requires such “one or more performance metric values” are retrieved by the API, i.e., during execution of the API. In addition, according to claim 1, particularly the limitation “receive, from the target system, performance data based on each of the plurality of executions of the API and the inserted one or more parameters”, such “performance data” is retrieved or received after execution of the API (note: the particular examples of claimed “performance data” from claim 9 and claim 10 also prove such claimed “performance data” should be received after execution of the API). Thereby, the limitation above from claim 11 is conflict with claim 1 (claim 1 requires the claimed “one or more performance metric values” are retrieved during execution of the API but claim 11 requires the claimed “one or more performance metric values” are retrieved or calculated after execution of the API). For the purpose of examination, examiner will not consider this particular limitation.
Claim 12 is rejected for failing to cure the deficiency from its respective parent claim by dependency.
Regarding to Claim 13, the limitation “the parameters instructing the API” is rejected under the same reason set forth in the rejection of Claim 1 above. In addition, the limitation “calculating one or more performance metric values based on the received performance data and the received API information” is rejected under the same reason set forth in the rejection of Claim 11 above.
Claims 14-17 are rejected for failing to cure the deficiency from their respective parent claim by dependency.
Regarding to Claim 18, the limitation “the parameters instructing the API” is rejected under the same reason set forth in the rejection of Claim 1 above. In addition, the limitation “calculating one or more performance metrics based on the received performance data and the received API information” is rejected under the same reason set forth in the rejection of Claim 11 above.
Claims 19-20 are rejected for failing to cure the deficiency from their respective parent claim by dependency.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis 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.
Claims 1-3, 13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mamidela (US 10936384 B1) in view of Hulick, Jr. et al. (US 20230421651 A1, hereafter Hulick).
Regarding to claim 1, Mamidela discloses: A system comprising (see Fig. 1, lines 42-61 of col. 2. Also see claim 8):
an Application Programming Interface (API) source (see lines 61-67 of col. 3; “at 5210, API calls/entities based on OData are retrieved/extracted from a central catalog of APIs (e.g., an API Hub), and fetched, from a database”. Also see “a plurality of APIs stored in a database” from claim 8);
a memory storing processor-executable program code; and a processing unit to execute the processor-executable program code to cause the system to (see claim 8; “A system comprising: a processor; and a memory in communication with the processor, the memory storing program instructions, the processor operative with the program instructions to perform the operations of”):
receive an API from the API source (see lines 61-67 of col. 3; “at 5210, API calls/entities based on OData are retrieved/extracted from a central catalog of APIs (e.g., an API Hub), and fetched, from a database”);
insert one or more parameters into an endpoint of the API (see lines 20-24 of col. 4; “at 5230, an input specifying a desired number of iterations (e.g., main runs) to perform each of the selected one or more API calls is provided”. Also see lines 59-61 of col. 4; “the graphical user interface may include an option to specify the target system for triggering the execution”);
execute, for a plurality of iterations, the API on a target system (see lines 25-27 of col. 4; “performance testing for each of the selected one or more API calls is executed in a default target system for the specified number of iterations”);
receive, from the target system, performance data based on each of the plurality of executions of the API and the inserted one or more parameters (see lines 25-32 of col. 4; “Performance information, including an average response time of the iterations, is recorded and may be retrieved from the target system at 5250”. Also see lines 56-58 of col. 4; “the average response time may include a processing time of a request (e.g., OData request), an end-to-end (E2E) response time, and an elapsed time”);
receive API information based on the inserted one or more parameters and an execution of the API (see lines 25-32 of col. 4; “Performance information, including an average response time of the iterations, is recorded and may be retrieved from the target system at 5250”. Also see lines 28-34 of col. 3; “OData defines an abstract data model and a protocol which, together, enable any client to access data exposed by any data source via a Uniform Resource Indicator (URI). The data model provides a generic way to organize and describe data. A GET request may list details and URIs of the resources in a collection and retrieve a specific item in the collection”. Also see “No. of Items” column of the table shown by Fig. 6 and “No. of Items” indicated by column G of the table shown by Fig. 7. The performance information related to number of items is considered as claimed API information); and
display the performance data and the API information on a graphical user interface (see lines 25-32 of col. 4; “the performance information is displayed on the graphical user interface at 5260”. Also see the tables shown by Figs. 6-7).
Mamidela does not disclose: insert one or more parameters into an endpoint Uniform Resource Identifier (URI) of the API, the parameters instructing the API to retrieve one or more performance metric values for the endpoint URI.
However, Hulick discloses:
insert one or more parameters into an endpoint Uniform Resource Identifier (URI) of the API, the parameters instructing the API to retrieve one or more performance metric values for the endpoint URI (see [0022]-[0024]; “the user modifies the Uniform Resource Locator (URL) for a page request, or the user clicks a user interface element that automatically modifies the URL of a page request, and based on that, that triggers the performance metrics to be captured”. Also see similar descriptions on [0025]-[0031]. Also see [0044]-[0045]; “executes Navigation (Nav) timing API calls to obtain performance metrics … executes the Nav Timing API calls to obtain the performance metrics”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the generic API to retrieve data object from Mamidela by including a specific type of API to retrieve performance metric data object from Hulick, and thus the combination of Mamidela and Hulick would disclose the missing limitations from Mamidela, since it is understood and well-known to specify a generic API to specific type of API according to user’s interest (see [0022]-[0024] from Hulick).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further the combination of Mamidela and Hulick discloses: wherein the API is based on Open Data Protocol (OData) (see lines 9-14 of col. 2 from Mamidela; “The disclosed embodiments relate to performance testing of application-programming interfaces (APIs), and more specifically, APIs that are based on OData (“OData APIs”)”).
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further the combination of Mamidela and Hulick discloses: wherein execution of the API includes program code to cause the system to: transmit an API call from an initial point to the target system; and transmit an API response from the target system to the initial point (see lines 14-20 of col. 1, lines 50-61 of col. 2 from Mamidela; “after a user logs into the API hub and selects an API of type OData (based on OData), the user can perform a GET request (e.g., a read operation). While a response may be provided” and “a client 110 may execute a Web Browser to request and receive a Web page (e.g., in HTML format) via HTTP or HTTPS, and may render and present the Web page according to known protocols. Target system 130 may comprise a test environment used to test the performance of an API”. The execution of the API in generally involved with transmit an API call from the initial point or client device to the target system that the API is executed and return API response back from the target system to the initial point or the client device).
Regarding to Claim 13, Mamidela discloses: A computer-implemented method (see Fig. 1, lines 42-61 of col. 2. Also see claim 1) comprising:
receiving an Application Programming Interface (API) from an API source (see lines 61-67 of col. 3; “at 5210, API calls/entities based on OData are retrieved/extracted from a central catalog of APIs (e.g., an API Hub), and fetched, from a database”. Also see “a plurality of APIs stored in a database” from claim 1), wherein the API is based on Open Data Protocol (OData) (see lines 9-14 of col. 2; “The disclosed embodiments relate to performance testing of application-programming interfaces (APIs), and more specifically, APIs that are based on OData (“OData APIs”)”);
inserting one or more parameters into an endpoint of the API (see lines 20-24 of col. 4; “at 5230, an input specifying a desired number of iterations (e.g., main runs) to perform each of the selected one or more API calls is provided”. Also see lines 59-61 of col. 4; “the graphical user interface may include an option to specify the target system for triggering the execution”);
executing, for a plurality of iterations, the API (see lines 25-27 of col. 4; “performance testing for each of the selected one or more API calls is executed in a default target system for the specified number of iterations”);
receiving performance data from a target system based on the plurality of executions of the API and the inserted one or more parameters (see lines 25-32 of col. 4; “Performance information, including an average response time of the iterations, is recorded and may be retrieved from the target system at 5250”. Also see lines 56-58 of col. 4; “the average response time may include a processing time of a request (e.g., OData request), an end-to-end (E2E) response time, and an elapsed time”);
receiving API information based on the inserted one or more parameters and an execution of the API; calculating one or more performance metric values based on the received performance data and the received API information (see lines 25-32 of col. 4; “Performance information, including an average response time of the iterations, is recorded and may be retrieved from the target system at 5250”. Also see lines 28-34 of col. 3; “OData defines an abstract data model and a protocol which, together, enable any client to access data exposed by any data source via a Uniform Resource Indicator (URI). The data model provides a generic way to organize and describe data. A GET request may list details and URIs of the resources in a collection and retrieve a specific item in the collection”. Also see “No. of Items” column of the table shown by Fig. 6 and “No. of Items” indicated by column G of the table shown by Fig. 7. The performance information related to number of items is considered as claimed API information); and
displaying the performance data and the API information on a graphical user interface (see lines 25-32 of col. 4; “the performance information is displayed on the graphical user interface at 5260”. Also see the tables shown by Figs. 6-7).
Mamidela does not disclose: inserting one or more parameters into an endpoint Uniform Resource Identifier (URI) of the API, the parameters instructing the API to retrieve one or more performance metric values for the endpoint URI;
displaying the one or more performance metric values on a graphical user interface.
However, Hulick discloses:
inserting one or more parameters into an endpoint Uniform Resource Identifier (URI) of the API, the parameters instructing the API to retrieve one or more performance metric values for the endpoint URI (see [0022]-[0024]; “the user modifies the Uniform Resource Locator (URL) for a page request, or the user clicks a user interface element that automatically modifies the URL of a page request, and based on that, that triggers the performance metrics to be captured”. Also see similar descriptions on [0025]-[0031]. Also see [0044]-[0045]; “executes Navigation (Nav) timing API calls to obtain performance metrics … executes the Nav Timing API calls to obtain the performance metrics”);
displaying the one or more performance metric values on a graphical user interface (see [0065]-[0066], [0085]; “the injection entity sends the performance metrics obtained at 340 to the destination 315 … A monitoring session report is then created and sent to whatever destination the user configured to receive the report (the user, an IT Help Desk, etc.), as specified in an email address provided by the user, text message number, etc., along with some priority that may be assigned to raise the report to the appropriate level of attention of the recipient” and “The performance metrics that result from the monitoring session may be shared with the user, the IT Help Desk, and/or even the cloud-based application service that the user access (via text and/or email)”. Also see [0038]; “As a default, the metrics may be delivered to the same place (a browser) with which the user is interacting”. Note: it is understood that text and/or email discussed at [0085] can be considered as certain graphical user interface).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the generic API to retrieve data object from Mamidela by including a specific type of API to retrieve performance metric data object from Hulick, and thus the combination of Mamidela and Hulick would disclose the missing limitations from Mamidela, since it is understood and well-known to specify a generic API to specific type of API according to user’s interest (see [0022]-[0024] from Hulick).
Regarding to Claim 18, Mamidela discloses: A non-transitory computer readable medium having executable instructions stored therein to perform a method (see lines 66-8 of cols. 4-5 and claim 15), the method comprising:
receiving an Application Programming Interface (API) from an API source (see lines 61-67 of col. 3; “at 5210, API calls/entities based on OData are retrieved/extracted from a central catalog of APIs (e.g., an API Hub), and fetched, from a database”. Also see “a plurality of APIs stored in a database” from claim 15), wherein the API is based on Open Data Protocol (OData) (see lines 9-14 of col. 2; “The disclosed embodiments relate to performance testing of application-programming interfaces (APIs), and more specifically, APIs that are based on OData (“OData APIs”)”);
inserting one or more parameters into an endpoint of the API (see lines 20-24 of col. 4; “at 5230, an input specifying a desired number of iterations (e.g., main runs) to perform each of the selected one or more API calls is provided”. Also see lines 59-61 of col. 4; “the graphical user interface may include an option to specify the target system for triggering the execution”);
executing, for a plurality of iterations, the API on a target system (see lines 25-27 of col. 4; “performance testing for each of the selected one or more API calls is executed in a default target system for the specified number of iterations”);
receiving performance data from the target system based on the plurality of executions of the API and the inserted one or more parameters (see lines 25-32 of col. 4; “Performance information, including an average response time of the iterations, is recorded and may be retrieved from the target system at 5250”. Also see lines 56-58 of col. 4; “the average response time may include a processing time of a request (e.g., OData request), an end-to-end (E2E) response time, and an elapsed time”);
receiving API information based on the inserted one or more parameters and an execution of the API; calculating one or more performance metrics based on the received performance data and the received API information (see lines 25-32 of col. 4; “Performance information, including an average response time of the iterations, is recorded and may be retrieved from the target system at 5250”. Also see lines 28-34 of col. 3; “OData defines an abstract data model and a protocol which, together, enable any client to access data exposed by any data source via a Uniform Resource Indicator (URI). The data model provides a generic way to organize and describe data. A GET request may list details and URIs of the resources in a collection and retrieve a specific item in the collection”. Also see “No. of Items” column of the table shown by Fig. 6 and “No. of Items” indicated by column G of the table shown by Fig. 7. The performance information related to number of items is considered as claimed API information);
displaying the performance data and the API information on a graphical user interface (see lines 25-32 of col. 4; “the performance information is displayed on the graphical user interface at 5260”. Also see the tables shown by Figs. 6-7).
Mamidela does not disclose: inserting one or more parameters into an endpoint Uniform Resource Identifier (URI) of the API, the parameters instructing the API to retrieve one or more performance metric values for the endpoint URI;
displaying the one or more performance metric values on a graphical user interface.
However, Hulick discloses:
inserting one or more parameters into an endpoint Uniform Resource Identifier (URI) of the API, the parameters instructing the API to retrieve one or more performance metric values for the endpoint URI (see [0022]-[0024]; “the user modifies the Uniform Resource Locator (URL) for a page request, or the user clicks a user interface element that automatically modifies the URL of a page request, and based on that, that triggers the performance metrics to be captured”. Also see similar descriptions on [0025]-[0031]. Also see [0044]-[0045]; “executes Navigation (Nav) timing API calls to obtain performance metrics … executes the Nav Timing API calls to obtain the performance metrics”);
displaying the one or more performance metric values on a graphical user interface (see [0065]-[0066], [0085]; “the injection entity sends the performance metrics obtained at 340 to the destination 315 … A monitoring session report is then created and sent to whatever destination the user configured to receive the report (the user, an IT Help Desk, etc.), as specified in an email address provided by the user, text message number, etc., along with some priority that may be assigned to raise the report to the appropriate level of attention of the recipient” and “The performance metrics that result from the monitoring session may be shared with the user, the IT Help Desk, and/or even the cloud-based application service that the user access (via text and/or email)”. Also see [0038]; “As a default, the metrics may be delivered to the same place (a browser) with which the user is interacting”. Note: it is understood that text and/or email discussed at [0085] can be considered as certain graphical user interface).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the generic API to retrieve data object from Mamidela by including a specific type of API to retrieve performance metric data object from Hulick, and thus the combination of Mamidela and Hulick would disclose the missing limitations from Mamidela, since it is understood and well-known to specify a generic API to specific type of API according to user’s interest (see [0022]-[0024] from Hulick).
Claims 4-6, 9-11, 14-16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mamidela (US 10936384 B1) in view of Hulick, Jr. et al. (US 20230421651 A1, hereafter Hulick) and further in view of Hakim et al. (US 20230421562 A1, hereafter Hakim).
Regarding to Claim 4, the rejection of Claim 3 is incorporated, the combination of Mamidela and Hulick does not discloses: wherein execution of the API includes transmission of the API across a plurality of legs.
However, Hakim discloses: wherein execution of the API includes transmission of the API across a plurality of legs (see Fig. 1, 3C-3F, [0060]-[0069]; “the client device 110 may send, to the service provider system 102 and (in some instances) via the gateway device 140, a message including a request for access to the application 180 (e.g., the requested application/service referred to at step 302). The request may be an API request that complies with an API configured to interface with the requested application 180”, “at step 330, the gateway device 140 may receive the message including the API request along with the access token”, “the gateway device 140 may route the API request and/or corresponding message, via the application services device 150, to the appropriate API and/or application 180 … the applications services device 150 may receive the API request and the appropriate API and/or application 180 may be executed. The application 180 may generate a response to the API request. At step 346, the response may be routed, via the gateway device 140, for transmission to the client device 110. At step 348, the gateway device 140 may receive the response and route the response to the client device 110”. The operation flow path of the API described by [0060]-[0069] shows execution of the API includes transmission of the API across a plurality of legs between the initial point and the final API execution location).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the execution of the API from the combination of Mamidela and Hulick by including the execution of API across multiple devices via at least a gateway device from Hakim, and thus the combination of Mamidela, Hulick and Hakim would disclose the missing limitations from the combination of Mamidela and Hulick, since it would provide a security mechanism that allows a gateway device to determine whether transmitted API request is associated with potential hardware activity or not (see [0063] from Mamidela; “The gateway device 140 may determine whether the API request may be associated with potential harmful activity in one or more ways. For instance, the gateway device 140 may determine whether the API request is associated with potential harmful activity based on comparing information associated with the API request to stored information associated with potential harmful activity”).
Regarding to Claim 5, the rejection of Claim 4 is incorporated and further the combination of Mamidelam, Hulick and Hakim discloses: wherein each leg includes at least one intermediate point (see Fig. 1, 3C-3F, [0060]-[0069] from Hakim and the explanation of claim 4 above. At least the gateway device 140 and application services device 150 can be considered as the claimed intermediate points of the plurality of legs).
Regarding to Claim 6, the rejection of Claim 5 is incorporated and further the combination of Mamidela, Hulick and Hakim discloses: wherein the intermediate point comprises a gateway server and an application server (see Fig. 1, 3C-3F, [0060]-[0069] from Hakim and the explanation of claim 4 above. At least the gateway device 140 and application services device 150).
Regarding to Claim 9, the rejection of Claim 4 is incorporated and further the combination of Mamidela, Hulick and Hakim discloses: wherein the performance data includes an elapsed execution time for the API (see lines 25-32, 56-58 of col. 4 from Mamidela; “Performance information, including an average response time of the iterations” and “the average response time may include a processing time of a request (e.g., OData request), an end-to-end (E2E) response time, and an elapsed time”).
Regarding to Claim 10, the rejection of Claim 9 is incorporated and further the combination of Mamidela, Hulick and Hakim discloses: wherein the performance data includes an average over the plurality of iterations (see lines 25-32, 56-58 of col. 4 from Mamidela; “Performance information, including an average response time of the iterations” and “the average response time may include a processing time of a request (e.g., OData request), an end-to-end (E2E) response time, and an elapsed time”).
Regarding to Claim 11, the rejection of Claim 10 is incorporated and further the combination of Mamidela, Hulick and Hakim discloses: calculate one or more performance metrics based on the performance data and the API information (see the rejection of claim 1).
Regarding to Claim 14, the rejection of Claim 13 is incorporated, the combination of Mamidela and Hulick does not disclose: wherein execution of the API includes transmission of the API across a plurality of legs.
However, Hakim discloses: wherein execution of the API includes transmission of the API across a plurality of legs (see Fig. 1, 3C-3F, [0060]-[0069]; “the client device 110 may send, to the service provider system 102 and (in some instances) via the gateway device 140, a message including a request for access to the application 180 (e.g., the requested application/service referred to at step 302). The request may be an API request that complies with an API configured to interface with the requested application 180”, “at step 330, the gateway device 140 may receive the message including the API request along with the access token”, “the gateway device 140 may route the API request and/or corresponding message, via the application services device 150, to the appropriate API and/or application 180 … the applications services device 150 may receive the API request and the appropriate API and/or application 180 may be executed. The application 180 may generate a response to the API request. At step 346, the response may be routed, via the gateway device 140, for transmission to the client device 110. At step 348, the gateway device 140 may receive the response and route the response to the client device 110”. The operation flow path of the API described by [0060]-[0069] shows execution of the API includes transmission of the API across a plurality of legs between the initial point and the final API execution location).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the execution of the API from combination of Mamidela and Hulick by including the execution of API across multiple devices via at least a gateway device from Hakim, and thus the combination of Mamidela, Hulick and Hakim would disclose the missing limitations from the combination of Mamidela and Hulick, since it would provide a security mechanism that allows a gateway device to determine whether transmitted API request is associated with potential hardware activity or not (see [0063] from Mamidela; “The gateway device 140 may determine whether the API request may be associated with potential harmful activity in one or more ways. For instance, the gateway device 140 may determine whether the API request is associated with potential harmful activity based on comparing information associated with the API request to stored information associated with potential harmful activity”).
Regarding to Claim 15, the rejection of Claim 14 is incorporated and further the combination of Mamidela, Hulick and Hakim discloses: wherein each leg includes at least one intermediate point (see Fig. 1, 3C-3F, [0060]-[0069] from Hakim and the explanation of claim 14 above. At least the gateway device 140 and application services device 150 can be considered as the claimed intermediate points of the plurality of legs)
Regarding to Claim 16, the rejection of Claim 15 is incorporated and further the combination of Mamidela, Hulick and Hakim discloses: wherein the intermediate point comprises a gateway server and an application server (see Fig. 1, 3C-3F, [0060]-[0069] from Hakim and the explanation of claim 14 above. At least the gateway device 140 and application services device 150).
Regarding to Claim 19, the rejection of Claim 18 is incorporated, the combination of Mamidela and Hulick does not disclose: wherein execution of the API includes transmission of the API across a plurality of legs.
However, Hakim discloses: wherein execution of the API includes transmission of the API across a plurality of legs (see Fig. 1, 3C-3F, [0060]-[0069]; “the client device 110 may send, to the service provider system 102 and (in some instances) via the gateway device 140, a message including a request for access to the application 180 (e.g., the requested application/service referred to at step 302). The request may be an API request that complies with an API configured to interface with the requested application 180”, “at step 330, the gateway device 140 may receive the message including the API request along with the access token”, “the gateway device 140 may route the API request and/or corresponding message, via the application services device 150, to the appropriate API and/or application 180 … the applications services device 150 may receive the API request and the appropriate API and/or application 180 may be executed. The application 180 may generate a response to the API request. At step 346, the response may be routed, via the gateway device 140, for transmission to the client device 110. At step 348, the gateway device 140 may receive the response and route the response to the client device 110”. The operation flow path of the API described by [0060]-[0069] shows execution of the API includes transmission of the API across a plurality of legs between the initial point and the final API execution location).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the execution of the API from combination of Mamidela and Hulick by including the execution of API across multiple devices via at least a gateway device from Hakim, and thus the combination of Mamidela, Hulick and Hakim would disclose the missing limitations from the combination of Mamidela and Hulick, since it would provide a security mechanism that allows a gateway device to determine whether transmitted API request is associated with potential hardware activity or not (see [0063] from Mamidela; “The gateway device 140 may determine whether the API request may be associated with potential harmful activity in one or more ways. For instance, the gateway device 140 may determine whether the API request is associated with potential harmful activity based on comparing information associated with the API request to stored information associated with potential harmful activity”).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Mamidela (US 10936384 B1) in view of Hulick, Jr. et al. (US 20230421651 A1, hereafter Hulick) and Hakim et al. (US 20230421562 A1, hereafter Hakim) and further in view of Kaiser et al. (US 12014395 B1, hereafter Kaiser).
Regarding to Claim 7, the rejection of Claim 6 is incorporated and further the combination of the combination of Mamidela, Hulick and Hakim discloses: wherein the application server is configured to: retrieve data and generate the API response including the retrieved data (see lines 28-34 of col. 3 from Mamidela and [0069] from Hakim; “OData defines … A GET request may list details and URIs of the resources in a collection and retrieve a specific item in the collection” and “the applications services device 150 may receive the API request and the appropriate API and/or application 180 may be executed. The application 180 may generate a response to the API request”. At the combination system the application of application server retrieves specific item and generate the API response including the retrieved item).
The combination of Mamidela, Hulick and Hakim does not disclose: the application server is configured to: access a database; retrieve data from the database.
However, Kaiser discloses: the application server is configured to: access a database; retrieve data from the database; generate the API response including the retrieved data (see lines 3-36 of col. 18; “The offer API 146 receives 308 the request … The offer API 146 transmits 312 an API request to the database application 136 … The database application 136 retrieves 314 the offer recommendations from the deployed offer data set 138 for the user corresponding to the user identifier. For example, the database application 136 can retrieve the offer recommendations stored within the offer recommendation data structure for the user. The database application 136 can then transmit 316 a response to the API request to the offer API 146 … the database application 136 includes in the response to the API request the offer recommendation data structure”. Also see lines 40-42 of col. 4 and lines 12-36 of col. 10; “The API can retrieve the personalized offers from the database and provide the personalized offers to the delivery server” from and “The database server 130 operates a database for storage of offers generated by the offer recommendation server 110 … the database application 136 is configured to manage data stored at the database server 130, to receive and respond to requests for data, and to manage incoming data”. It is reasonable to consider the deployed offer data set 138 described at lines 3-36 as certain or part of database storing the requested data/item associated with the API).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify data retrieving operation for the API from the combination of Mamidela, Hulick and Hakim by including retrieving associated data from database in response to API request from Kaiser, and thus the combination of Mamidela, Hulick, Hakim and Kaiser would disclose the missing limitations from the combination of Mamidela, Hulick and Hakim, since a database is well-known data store concept to store data or information to allow retrieving the stored data or information.
Claims 8, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mamidela (US 10936384 B1) in view of Hulick, Jr. et al. (US 20230421651 A1, hereafter Hulick) and Hakim et al. (US 20230421562 A1, hereafter Hakim) and further in view of Hudzia et al. (US 20130132560 A1, hereafter Hudzia).
Regarding to Claim 8, the rejection of Claim 4 is incorporated, the combination of Mamidela, Hulick and Hakim does not disclose: record, based on the one or more inserted parameter, an elapsed time for API transmission for each leg.
However, Hudzia discloses: record an elapsed time for message transmission for each leg (see [0087]-[0090]; “the various messages may be transmitted between the node 702, 704 and the node 718, and each such intermediate node may, as described with respect to FIG. 1, incrementally add latency information to each transmitted message, as each such message traverses the node in question” and “update a message header of the message so as to include the previously-determined average transmission time between the nodes 706/714 as being representative of an actual transmission time that was experienced by the message in traversing from the node 706 to the node 714”. Also see [0009] and [0101]-[0104]; “extract latency information from the plurality of messages, the latency information characterizing a transmission duration experienced by each message in traveling from the one or more source nodes through the network” and “the update message 1204 includes a count field which has been incremented to one to reflect transmission of the message from the node 1110 to the node 1108, as well as a delay field which is updated to include the value 120 milliseconds representing the transmission delay experienced by the message during its transmission from the node 1110 to the node 1108”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the transmission of the API related messages among different nodes during API execution from the combination of Mamidela, Hulick and Hakim by including recording the transmission delay or latency information in each message transmitted during different nodes from Hudzia, and thus the combination of Mamidela, Hulick, Hakim and Hudzia would disclose the missing limitations from the combination of Mamidela, Hulick and Hakim (note: Hudzia alone may not disclose the feature of recording claimed elapsed time based on the one or more inserted parameter. However, Mamidela already discloses the transmission of the API is based on the inserted parameters, i.e., inserted/specified target system, and thus the elapsed time for API transmission for each leg at the combination system is recorded based on the inserted parameters), since it would provide “a particular timeframe, complex event processing techniques generally rely on complete, accurate, and timely transmission of events, e.g., within a computer network” (see [0006] from Hudzia).
Regarding to Claim 17, the rejection of Claim 14 is incorporated, the combination of Mamidela, Hulick and Hakim does not disclose: recording, based on the one or more inserted parameters, a time taken for API transmission for each leg.
However, Hudzia discloses: recording an elapsed time for message transmission for each leg (see [0087]-[0090]; “the various messages may be transmitted between the node 702, 704 and the node 718, and each such intermediate node may, as described with respect to FIG. 1, incrementally add latency information to each transmitted message, as each such message traverses the node in question” and “update a message header of the message so as to include the previously-determined average transmission time between the nodes 706/714 as being representative of an actual transmission time that was experienced by the message in traversing from the node 706 to the node 714”. Also see [0009] and [0101]-[0104]; “extract latency information from the plurality of messages, the latency information characterizing a transmission duration experienced by each message in traveling from the one or more source nodes through the network” and “the update message 1204 includes a count field which has been incremented to one to reflect transmission of the message from the node 1110 to the node 1108, as well as a delay field which is updated to include the value 120 milliseconds representing the transmission delay experienced by the message during its transmission from the node 1110 to the node 1108”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the transmission of the API related messages among different nodes during API execution from the combination of Mamidela, Hulick and Hakim by including recording the transmission delay or latency information in each message transmitted during different nodes from Hudzia, and thus the combination of Mamidela, Hulick, Hakim and Hudzia would disclose the missing limitations from the combination of Mamidela, Hulick and Hakim (note: Hudzia alone may not disclose the feature of recording claimed elapsed time based on the one or more inserted parameter. However, Mamidela already discloses the transmission of the API is based on the inserted parameters, i.e., inserted/specified target system, and thus the elapsed time for API transmission for each leg at the combination system is recorded based on the inserted parameters), since it would provide “a particular timeframe, complex event processing techniques generally rely on complete, accurate, and timely transmission of events, e.g., within a computer network” (see [0006] from Hudzia).
Regarding to Claim 20, the rejection of Claim 19 is incorporated, the combination of Mamidela, Hulick and Hakim does not disclose: recording, based on one or more inserted parameters, a time taken for API transmission for each leg.
However, Hudzia discloses: recording an elapsed time for message transmission for each leg (see [0087]-[0090]; “the various messages may be transmitted between the node 702, 704 and the node 718, and each such intermediate node may, as described with respect to FIG. 1, incrementally add latency information to each transmitted message, as each such message traverses the node in question” and “update a message header of the message so as to include the previously-determined average transmission time between the nodes 706/714 as being representative of an actual transmission time that was experienced by the message in traversing from the node 706 to the node 714”. Also see [0009] and [0101]-[0104]; “extract latency information from the plurality of messages, the latency information characterizing a transmission duration experienced by each message in traveling from the one or more source nodes through the network” and “the update message 1204 includes a count field which has been incremented to one to reflect transmission of the message from the node 1110 to the node 1108, as well as a delay field which is updated to include the value 120 milliseconds representing the transmission delay experienced by the message during its transmission from the node 1110 to the node 1108”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the transmission of the API related messages among different nodes during API execution from the combination of Mamidela, Hulick and Hakim by including recording the transmission delay or latency information in each message transmitted during different nodes from Hudzia, and thus the combination of Mamidela, Hulick, Hakim and Hudzia would disclose the missing limitations from the combination of Mamidela, Hulick and Hakim (note: Hudzia alone may not disclose the feature of recording claimed elapsed time based on the one or more inserted parameter. However, Mamidela already discloses the transmission of the API is based on the inserted parameters, i.e., inserted/specified target system, and thus the elapsed time for API transmission for each leg at the combination system is recorded based on the inserted parameters), since it would provide “a particular timeframe, complex event processing techniques generally rely on complete, accurate, and timely transmission of events, e.g., within a computer network” (see [0006] from Hudzia).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Mamidela (US 10936384 B1) in view of Hulick, Jr. et al. (US 20230421651 A1, hereafter Hulick) and Hakim et al. (US 20230421562 A1, hereafter Hakim) and further in view of Shrivastava et al. (US 20240330118 A1, hereafter Shrivastava) and Ahuja (US 20210406383 A1).
Regarding to Claim 12, the rejection of Claim 11 is incorporated and further the combination of Mamidela, Hulick and Hakim discloses: wherein the API information includes a number of items fetched from a database (see lines 28-34 of col. 3 from Mamidela; “OData defines an abstract data model and a protocol which, together, enable any client to access data exposed by any data source via a Uniform Resource Indicator (URI). The data model provides a generic way to organize and describe data. A GET request may list details and URIs of the resources in a collection and retrieve a specific item in the collection”. Also see “No. of Items” column of the table shown by Fig. 6 and “No. of Items” indicated by column G of the table shown by Fig. 7 from Mamidela).
The combination of Mamidela, Hulick and Hakim does not disclose: the API information further includes a total number of items in the database, and a service quality score.
However, Shrivastava discloses: wherein the API information includes a total number of items in the database (see [0060]; “issue a GetRecoveryStats function call (API) to a data service managing the database to compute the storage stats (e.g., total bytes) of data storage consumed by each vdisk 235 of the data set. The replication manager 320 may then consolidate the total data storage bytes of all vdisks in the data set for the UVM 210 to determine how much data needs to be transferred (replicated) to the secondary site B”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the API information from the combination of Mamidela, Hulick and Hakim by including API information of total data amount of a database from Shrivastava, since it would provide a specific database statistic information to help performing further database management operation (see [0060] from Shrivastava).
In addition, Ahuja discloses: wherein the API information includes a service quality score (see [0052] and [0058]; “determine the quality value 152-1 associated with the API 150 by calculating the weighted sum of the qualities associates with different portions of the source code of the API 150”. Also see [0042]-[0047]; “the quality associated with the API 150 may depend on a reliability of the source code of the API 150, where the reliability of the source code of the API 150 is represented by the probability that the task 124 will be performed using the API 150 without failure over a specific period of operation”, “the quality associated with the API 150 may depend on a maintainability of the source code of the API 150, where the maintainability of the source code of the API 150 is represented by how easily the API 150 can be maintained”, “ the quality associated with the API 150 may depend on a testability of the source code of the API 150, where the testability of the source code of the API 150 is represented by how easily potential defects or errors in the source code of the API 150 may be found by test cases and test points”, “the quality associated with the API 150 may depend on a portability of the source code of the API 150, where the portability of the source code of the API 150 is represented by whether the API 150 is platform-independent”, “the quality associated with the API 150 may depend on a reusability of the source code of the API 150. In one example, the reusability of the source code of the API 150 is represented by whether the classes, methods, function, and/or other portions of the source code of API 150 can be reused in developing other APIs 150 and/or web applications 140” and “the quality associated with the API 150 may depend on how much processing power it consumes to perform the particular task 124”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the API information from the combination of Mamidela, Hulick, Hakim and Shrivastava by including quality value of an API from Ahuja, and thus the combination of Mamidela, Hulick, Hakim, Shrivastava and Ahuja would disclose the missing limitations from the combination of Mamidela, Hulick and Hakim, since it would provide a mechanism to rate a given API at different levels including but not limited to reliability, maintainability, testability and reusability (see [0042]-[0047] from Ahuja).
Response to Arguments
Applicant’s arguments, filed 4/21/2026, with respect to rejections of claims 1-20 under 35 U.S.C. 102 or 35 U.S.C. 103 have been full considered. New grounds of rejections are made based on amended limitations from the independent claims. In addition, Applicant’s arguments for claim 8 are not persuasive. At 3rd paragraph of page 10 from the Remarks, Applicant argued that “in contrast to the invention set forth in claim 8, the proposed combination of Mamidela, and Hakim and Hudzia teaches against measuring exact/elapsed time. In particular, paragraph [0088] of Hudzia teaches ‘the node 714 need not be aware, or measured an exact transmission time of the message from node 706 to the node 714. Instead, in the example, the node 714 may rely on the previous-calculated average transmission time as a proxy which closely corresponds to the actual transmission time’ (Emphasis added). In response to such argument, Applicant is suggested to review the exact language used at claim 8 since claim 8 does not include any of “measuring”, “exact” language as Applicant argued. The exact claim language for claim 8 is “record, based on the one or more inserted parameter, an elapsed time for API transmission for each leg”. The term “record” is not necessary to be same as measure. In addition, the language used at claim 8 under BRI does not exclude the possibility of recording or even measuring claimed “elapsed time for API transmission for each leg” as same as [0088] from Hudzia, i.e., “reply on the previous-calculated average transmission time”.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sinha (US 20240073150 A1) discloses: Each NF can be provided with a status API or similar functionality responsive to invocation of the URL. That is, the network address can be associated with the status API on the NF. The NF can then invoke the URL to request or obtain updated load, priority, CPU utilization, memory utilization, and/or other resource utilization and performance metrics (collectively “resource metrics”) directly from the NF. In some implementations, the invocation can be based on a periodic or refresh timer, on-demand, and/or combinations thereof (see [0024]).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 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 an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights