DETAILED ACTION
This office action is in response to amendment filed on 3/16/2026.
Claims 1, 9 and 17 are amended.
Claims 1 – 20 are pending.
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 .
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.
Claim(s) 1 – 15 and 17 – 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dhandhania (USPAT 11366660), in view of Baer et al (USPAT 10574699, hereinafter Baer).
As per claim 1, Dhandhania discloses: A system for application programming interface (API) operation dynamic overwriting, the system comprising: one or more memories; and one or more processors, communicatively coupled to the one or more memories, configured to:
receive an indication, associated with an entity, to overwrite an API operation; (Dhandhania col 13, lines 33 – 35: “The system may then compare 612 the estimated latencies derived from the latency estimation model with their corresponding measured latencies.”; col 13, line 41 – col 14, line 3: “The system checks at 614 if any of the measured latencies exceed the estimated latencies by a defined amount (e.g., 10% or 20%), fail to meet the estimated latencies by a defined amount, or fall outside of a defined range with respect to the estimated latency… If no at 614, then the system outputs 618 an indication that an anomalous latency event has been detected. For example, the system may initiate an alarm with a notification that indicates subcomponents or subtasks that are associated with the anomalous latency event or specifies an estimated latency and an actual latency for a subcomponent. In another example, the indication that an anomalous latency event has occurred may be a notification dispatched to a server identifying a classification… In some implementations, a user may override an anomalous classification of API request fulfillment session data.”, Examiner notes that the indication of an anomalous latency is mapped to the claimed indication to overwrite API operations.)
receive a user prompt associated with the entity; (Dhandhania col 14, lines 20 – 25: “API request fulfillment analyzer may output 702 an alarm or indication of potential anomaly to a user indicating that a potential anomaly has been detected for a fulfillment of an API service request and obtain 704 a user indication of whether API request fulfillment session data is anomalous”.)
perform, based at least in part on the user prompt, a set of one or more operations, wherein the API operation is excluded from the set of the one or more operations based at least in part on the indication to overwrite the API operation being associated with the entity and the user prompt being associated with the entity; (Dhandhania col 14, lines 25 – 41: “If at 706 an API request fulfillment session is indicated to be anomalous, then API request fulfillment analyzer may exclude the API request fulfillment session data 710 from API request classification data that may be used to train an API latency estimation model… Process 700 allows users to override a false positive anomalous classification due to, for example, a new type of data being provided with an API service request or the user verifying using session logs, for example, that no anomaly occurred. The process of updating a latency estimation model with classification data that has been verified by a user allows for the model to have improved accuracy in making future estimates.”; col 14, lines 48 – 61: “the API request fulfillment session data 802 for a plurality of fulfilled API service requests may be classified with an identified classification (e.g., anomalous or not anomalous) using a latency estimation model or user inputs to obtain API request classification data, which may be used by training module 804 to generate or update a latency estimate model 806. An API request fulfillment analyzer may use the model to analyze API request fulfillment session data. In one or more implementations, a user input being received that is indicative of a potential anomaly not being an anomaly causes the latency estimation model to automatically update, based on an actual latency and the API request fulfillment session data, the latency estimation model.”)
and provide, based at least in part on performing the set of the one or more operations, a response to the user prompt. (Dhandhania col 7, lines 12 – 16: “For example, a measured (or “actual”) latency of API service 206 may indicate an amount of time from when API service 206 receives an API service request to when a response to an API service request is output (e.g. output from API service 206 provided to client 202).”)
Dhandhania did not explicitly disclose:
and refrain from performing the API operation;
However, Baer teaches:
and refrain from performing the API operation; (Baer col 8, line 55 – 63: “if the load balancer 206 determines that one or more policies explicitly forbid the user 202 from performing the requested operations, the load balancer 206 may determine that the user 202 is not authorized to perform the requested operations and, thereby, deny the API request. Similar to the authentication failure described above, the load balancer 206 may transmit a 400-series HTTP error message or a different error message in an alternative format the user 202 to indicate that its request has been denied.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Baer into that of Dhandhania in order to refrain from performing an API operation. Dhandhania col 13, line 33 – col 14, line 3 teaches detecting anomalous classification to API fulfillment request and allowing user to override the classification if needed. Baer teaches that it is commonly known in the field to also deny API requests if policy requires it. Combination of the reference would result in the API request that has an anomalous latency classification be modified and also denied from making the original request, such combination would result in better resource control and is therefore rejected under 35 USC 103.
As per claim 2, the combination of Dhandhania and Baer further teach:
The system of claim 1, wherein the indication to overwrite the API operation is an overwrite flag set to true. (Dhandhania figure 7, step 706.)
As per claim 3, the combination of Dhandhania and Baer further teach:
The system of claim 1, wherein no indication, associated with the entity, of data is received. (Dhandhania col 14, lines 29 – 34: “If at 706, an API request fulfillment session is indicated to not be anomalous, then API request fulfillment analyzer may include the API request fulfillment session data in API request classification data 708 that is used to train an API latency estimation model.”)
As per claim 4, the combination of Dhandhania and Baer further teach:
The system of claim 1, wherein the one or more processors are further configured to: receive an indication, associated with the entity, of data, wherein the one or more processors, to provide the response, are configured to provide the response based at least in part on the data. (Dhandhania col 7, lines 12 – 16: “For example, a measured (or “actual”) latency of API service 206 may indicate an amount of time from when API service 206 receives an API service request to when a response to an API service request is output (e.g. output from API service 206 provided to client 202).”)
As per claim 5, the combination of Dhandhania and Baer further teach:
The system of claim 1, wherein the API operation is a first API operation, wherein the set of one or more operations includes at least one second API operation, and wherein the one or more processors are further configured to: receive at least one indication, associated with the entity, to not overwrite the at least one second API operation. (Dhandhania col 7, lines 29 – 44.)
As per claim 6, the combination of Dhandhania and Baer further teach:
The system of claim 5, wherein the at least one indication to not overwrite the at least one second API operation is at least one overwrite flag set to false. (Dhandhania figure 7, step 706.)
As per claim 7, the combination of Dhandhania and Baer further teach:
The system of claim 1, wherein the API operation is a first API operation, and wherein the set of one or more operations includes at least one second API operation, and wherein the one or more processors, to perform the at least one second API operation, are configured to: perform the at least one second API operation based at least in part on not receiving at least one indication, associated with the entity, to not overwrite the at least one second API operation. (Dhandhania figure 7, step 706.)
As per claim 8, the combination of Dhandhania and Baer further teach:
The system of claim 1, wherein the one or more processors are further configured to: cache data associated with the response. (Dhandhania col 7, lines 45 – 59.)
As per claim 9, it is the method variant of claim 1 and is therefore rejected under the same rationale.
As per claim 10, it is the method variant of claim 2 and is therefore rejected under the same rationale.
As per claim 11, it is the method variant of claim 3 and is therefore rejected under the same rationale.
As per claim 12, it is the method variant of claim 4 and is therefore rejected under the same rationale.
As per claim 13, it is the method variant of claim 5 and is therefore rejected under the same rationale.
As per claim 14, it is the method variant of claim 7 and is therefore rejected under the same rationale.
As per claim 15, the combination of Dhandhania and Baer further teach:
The method of claim 9, wherein the indication to skip the API operation is a JavaScript object notation (JSON) payload. (Dhandhania col 15, line 51 – col 16, line 6,)
As per claim 17, it is the non-transitory computer-readable medium variant of claim 1 and is therefore rejected under the same rationale.
As per claim 18, the combination of Dhandhania and Baer further teach:
The non-transitory computer-readable medium of claim 17, wherein the API operation is an API call to fetch data. (Dhandhania col 4, lines 34 – 38.)
As per claim 19, it is the non-transitory computer-readable medium variant of claim 15 and is therefore rejected under the same rationale.
As per claim 20, it is the non-transitory computer-readable medium variant of claim 16 and is therefore rejected under the same rationale.
Claim(s) 16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dhandhania and Baer, in view of Bauer et al (US 20230286451, hereinafter Bauer).
As per claim 16, the combination of Dhandhania and Baer did not teach:
The method of claim 9, wherein the user prompt relates to an exchange involving a vehicle.
However, Bauer teaches:
The method of claim 9, wherein the user prompt relates to an exchange involving a vehicle. (Bauer [0068])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Bauer into that of Dhandhania and Baer in order to have the user prompt relates to an exchange involving a vehicle. The claimed limitation merely claims an intended usage of the user prompt, as demonstrated by Baur [0068], and is therefore rejected under 35 USC 103.
As per claim 20, it is the non-transitory computer-readable medium variant of claim 16 and is therefore rejected under the same rationale.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 – 20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
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 5712701014. 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.
/CHARLES M SWIFT/Primary Examiner, Art Unit 2196