DETAILED ACTION
This office action is responsive to request for continued examination filed on February 2, 2026 in this application Roizman et al., U.S. Patent Application No. 18/297,797, (Filed April 10, 2023) (“Roizman”). Claims 1 - 21 were pending. Claims 2 and 13 are cancelled. Claims 1, 11, and 12 are amended. Claims 1, 3 – 12, and 14 – 21 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission of on February 2, 2026 has been entered.
Response to Arguments
1. With respect to Applicant’s argument on pgs. 13 – 17 of the Applicant’s Remarks (“Remarks”) stating that Zhu fails to teach clustering the call flows, examiner respectfully disagrees. See infra § Claim Rejections - 35 USC §103 § Claim 1.
Zhu teaches that each identified API call flow pattern may be grouped into a plurality of sets of similar API call patters and stored in a memory. Id. at ¶¶ 0045-0047, 0060. Therefore, Zhu teaches clustering the call flows. To the extent a particular type of cluster is supported in the specification applicant is encouraged to amend the claims accordingly to potentially distinguish over the art of record.
2. With respect to Applicant’s argument on pgs. 17 – 18 of the Applicant’s Remarks (“Remarks”) stating that the current prior art fails to teach the newly added limitations, examiner respectfully agrees, however, in light of applicant’s amendments prior art reference Twohig is added which teaches these limitations. See infra § Claim Rejections - 35 USC §103 § Claim 1. Twohig teaches blocking and/or rate limiting the anomalous API. Twohig at Abstract; id. at ¶¶ 0020, 0042, 0056, 0058, 0065; id. at ¶ 0031 (API “calls”). Therefore, the current combination of references teaches the amended claims.
Claim Rejections 35 U.S.C. §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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3 – 12, and 14 – 21 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al., United States Patent Application Publication No. 2015/0128156 (Published May 7, 2015, filed November 7, 2013) (“Zhu”) in view of Tiwari et al., United States Patent Application Publication No. 2022/0382617 (Published December 1, 2022, filed July 12, 2021) (“Tiwari”) and Twohig, United States Patent Application Publication No. 2024/0256179 (Published August 1, 2024, filed February 1, 2023) (“Twohig”)
Claims 1, 11, and 12
With respect to claims 1, 11, and 12, Zhu teaches the invention as claimed including a method for securing computing interfaces based on [call flows], comprising:
identifying a plurality of computing interface calls, wherein each computing interface call is identified as being associated with a user of a plurality of users; grouping instances of the plurality of computing interface calls that have differing parameters or contents yet terminate at a same endpoint in the at least one computing environment into at least one computer interface call cluster; identifying at least one computing interface [call flow] with respect to the plurality of computing interface calls based on identifying the user with which each computing interface call is associated and the at least one computer interface call cluster, wherein each computing interface call flow includes an ordered sequence of computing interface calls among the plurality of computing interface calls; detecting, based on the at least one computing interface [call flow], at least one abnormality with respect to the plurality of computing interface calls; and securing the at least one computing environment by performing at least one mitigation action to mitigate the detected at least one abnormality, {A set of API calls from client devices to server-based APIs [computing interface] and for performing a transaction with an endpoint such as an online store are captured and analyzed in real-time to determine a cluster of calls as a call structure (flow) for the endpoint transaction, identify user usage patterns, create graphs from the usage patterns (610), and to compare the usage patterns to frequently occurring API usage patterns to identify similarity or differences using a “frequent subgraph mining algorithm”. Zhu at Abstract; id. at ¶¶ 0017 – 0021, 0023 – 0028 (types of API usage monitored), 0030, 0031, 0039, 0042, 0045-0047, 0060 (monitoring based on endpoint transaction use cases and user ID, cluster creation, and pattern comparisons), 0049 – 0052 & 0065 – 0068 & 0070 - 0072 (Graphs are created for frequent call flows and for monitored call flows where the graph nodes represent APIs and graph edges represent calls between the APIs and where subgraphs are compared to identify if monitored call flows match the frequent call flows); id. at ¶¶ 0074, 0076 & 0077 (identify abnormal activities and generate visual alert, alert message, or log event); id. at fig. 6.}
However, Zhu doesn’t explicitly teach the limitation:
call flow {Tiwari does teach this limitation. Tiwari teaches that user API call sequences, as taught in Zhu, may be a call flow the calls from a client accessing interfaces of applications/microservices on a cloud service are monitored and are reconstructed into a call flow which is analyzed to detect anomalies in the call flow by assembling calls to various interfaces, for example based on transaction ids, into a call flow service graph showing the interfaces called as nodes and the calls between the interfaces as edges representing API keywords such as “HTTP GET or HTTP POST” to identify “outliers in the edges” of the graph and determine the “anomalous call flows” which are identified in part by comparing the call flow graph under analysis to “a set of known call flows to identify the anomalous call flow with a higher degree of confidence.” Tiwari at ¶¶ 0003, 005 – 0007, 0033, 0051 – 0054, 0064 – 0066, 0076; id. at fig. 3 (call flow graph); id. at fig. 4 (identifying API access methods used in call flows); id. at ¶¶ 0047, 0048, 0068 - 0070 (The interface access methods used in the call flows that are analyzed may be API interface access requests for authentication, security certificates, and/or keys); id. at ¶¶ 0030, 0031, 0036, 0037, 0040.
Zhu and Tiwari are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of application monitoring, and both are trying to solve the problem of how to detect anomalous application usage.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine identifying anomalous user API call sequences, as taught in Zhu, with where the call sequences are call flows, as taught in Tiwari. Tiwari teaches that identifying call flows can reveal anomalous usage of an interface. Id. at ¶ 0003. Therefore, one having ordinary skill in the art would have been motivated to combine identifying anomalous user API call sequences, as taught in Zhu, with where the call sequences are call flows, as taught in Tiwari, for the purpose of using a known method to identify call sequences as a call flow for anomaly detection with a method that analyzes ordered call sequences to detect anomalies.}
However, Zhu and Tiwari don’t explicitly teach the limitation:
wherein the at least one mitigation action is one of: blocking traffic to or from a given computing interface, blocking traffic to or from one or more components using the given computing interface, reconfiguring the given computing interface, lowering a rate limit number associated with the given computing interface, and combinations thereof. {Twohig does teach this limitation. Twohig teaches that the method to determine anomalous API call flows, as taught in Zhu and Tiwari, may include blocking and/or rate limiting the anomalous calls to the APIs. Twohig at Abstract; id. at ¶¶ 0020, 0042, 0056, 0058, 0065; id. at ¶ 0031 (API “calls”).
Zhu, Tiwari, and Twohig are analogous art because they are from the “same field of endeavor” and are both from the same “problem-solving area.” Specifically, they are both from the field of application monitoring, and both are trying to solve the problem of how to detect anomalous application usage.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine determining anomalous API call flows, as taught in Zhu and Tiwari, with blocking and/or throttling the calls, as taught in Twohig. Tiwari teaches that identifying call flows can reveal anomalous usage of an interface. Id. at ¶ 0003. Therefore, one having ordinary skill in the art would have been motivated to combine determining anomalous API call flows, as taught in Zhu and Tiwari, with blocking and/or throttling the calls, as taught in Twohig, for the purpose of using a known method to remedy anomalous API usage with a method that detects anomalous API usage.}
Claims 3 and 14
With respect to claims 3 and 14, Zhu, Tiwari, and Twohig teach the invention as claimed including:
creating at least one graph, wherein each graph includes nodes and edges, wherein each node represents a respective computing interface of a plurality of computing interfaces, wherein each edge represents at least one of the plurality of computing interface calls, wherein the at least one computing interface call flow is identified based on the at least one graph. {A set of API calls from client devices to server-based APIs [computing interface] are captured and analyzed in real-time to determine a call structure (flow), identify user usage patterns, create graphs from the usage patterns (610), and to compare the usage patterns to frequently occurring API usage patterns to identify similarity or differences using a “frequent subgraph mining algorithm”. Zhu at Abstract; id. at ¶¶ 0017 – 0021, 0023 – 0028 (types of API usage monitored), 0030, 0031, 0039, 0042, 0045 (monitoring based on user ID and pattern comparisons), 0049 – 0052 & 0065 – 0068 & 0070 - 0072 (Graphs are created for frequent call flows and for monitored call flows where the graph nodes represent APIs and graph edges represent calls between the APIs and where subgraphs are compared to identify if monitored call flows match the frequent call flows); id. at ¶¶ 0074, 0076 & 0077 (identify abnormal activities and generate visual alert, alert message, or log event); id. at fig. 6.}
Claims 4 and 15
With respect to claims 4 and 15, Zhu, Tiwari, and Twohig, teach the invention as claimed including:
wherein the at least one graph includes a plurality of first graphs and a second graph, further comprising: creating the plurality of first graphs, wherein each first graph includes a plurality of computing interface calls corresponding to a respective user of the plurality of users; and combining the plurality of first graphs to create the second graph, wherein the at least one [call flow] is identified based on the second graph. {A set of API calls from client devices to server-based APIs [computing interface] are captured and analyzed in real-time to determine a call structure (flow), identify user usage patterns, create graphs from the usage patterns (610), and to compare the usage patterns to frequently occurring API usage patterns to identify similarity or differences using a “frequent subgraph mining algorithm”. Zhu at Abstract; id. at ¶¶ 0017 – 0021, 0023 – 0028 (types of API usage monitored), 0030, 0031, 0039, 0042, 0045 (monitoring based on user ID and pattern comparisons), 0049 – 0052 & 0065 – 0068 & 0070 - 0072 (Graphs are created for frequent call flows and for monitored call flows where the graph nodes represent APIs and graph edges represent calls between the APIs and where subgraphs are compared to identify if monitored call flows match the frequent call flows); id. at ¶¶ 0074, 0076 & 0077 (identify abnormal activities and generate visual alert, alert message, or log event); id. at fig. 6.}
call flow {Call flows the calls from a client accessing interfaces of applications/microservices on a cloud service are monitored and are reconstructed into a call flow which is analyzed to detect anomalies in the call flow by assembling calls to various interfaces, for example based on transaction ids, into a call flow service graph showing the interfaces called as nodes and the calls between the interfaces as edges representing API keywords such as “HTTP GET or HTTP POST” to identify “outliers in the edges” of the graph and determine the “anomalous call flows” which are identified in part by comparing the call flow graph under analysis to “a set of known call flows to identify the anomalous call flow with a higher degree of confidence.” Tiwari at ¶¶ 0003, 005 – 0007, 0033, 0051 – 0054, 0064 – 0066, 0076; id. at fig. 3 (call flow graph); id. at fig. 4 (identifying API access methods used in call flows); id. at ¶¶ 0047, 0048, 0068 - 0070 (The interface access methods used in the call flows that are analyzed may be API interface access requests for authentication, security certificates, and/or keys); id. at ¶¶ 0030, 0031, 0036, 0037, 0040.}
Claims 5 and 16
With respect to claims 5 and 16, Zhu, Tiwari, and Twohig, teach the invention as claimed including:
wherein each of the plurality of first graphs is created for a respective session of a plurality of sessions. {A set of API calls from client devices to server-based APIs [computing interface] are captured and analyzed in real-time to determine a call structure (flow), identify user usage patterns, create graphs from the usage patterns (610), and to compare the usage patterns to frequently occurring API usage patterns to identify similarity or differences using a “frequent subgraph mining algorithm”. Zhu at Abstract; id. at ¶¶ 0017 – 0021, 0023 – 0028 (types of API usage monitored), 0030, 0031, 0039, 0042, 0045 (monitoring based on user ID and pattern comparisons), 0049 – 0052 & 0065 – 0068 & 0070 - 0072 (Graphs are created for frequent call flows and for monitored call flows where the graph nodes represent APIs and graph edges represent calls between the APIs and where subgraphs are compared to identify if monitored call flows match the frequent call flows); id. at ¶¶ 0074, 0076 & 0077 (identify abnormal activities and generate visual alert, alert message, or log event); id. at fig. 6.}
Claims 6 and 17
With respect to claims 6 and 17, Zhu and Tiwari, teach the invention as claimed including:
filtering at least one edge from the second graph based on a number of instances of the computing interface call represented by each edge among the second graph. {Graph may be reduced to filter out repeated calls to a particular API. Zhu at ¶¶ 0048 & 0050.}
Claims 7 and 18
With respect to claims 7 and 18, Zhu, Tiwari, and Twohig, teach the invention as claimed including:
wherein filtering the at least one edge from the second graph further comprises: identifying at least one pair of opposite edges in the second graph, wherein each pair of opposite edges includes an edge representing a call from a first computing interface to a second computing interface and an edge representing a call from the second computing interface to the first computing interface, wherein the at least one edge filtered from the second graph includes any of the first edge and the second edge from each pair of opposite edges. {The frequently occurring usage patterns may be transformed into a tree representation that removes cyclic edges. Zhu at ¶ 0073; id. at fig. 4 compared with fig. 5.}
Claims 8 and 19
With respect to claims 8 and 19, Zhu, Tiwari, and Twohig, teach the invention as claimed including:
determining a user identifier for each of the plurality of computing interface calls by analyzing a plurality of packets of computing interface call data indicating the plurality of computing interface calls, wherein each user identifier corresponds to one of the plurality of users, wherein the plurality of computing interface [call flows] are identified based on the user identified determined for each of the plurality of computing interface calls. {A set of API calls from users of client devices having respective user IDs or where the calls are determined to correlate to a user ID based request that are sent to server-based APIs [computing interface] are captured and analyzed in real-time to determine a call structure (flow), identify user usage patterns, create graphs from the usage patterns (610), and to compare the usage patterns to frequently occurring API usage patterns to identify similarity or differences using a “frequent subgraph mining algorithm”. Zhu at Abstract; id. at ¶¶ 0017 – 0021, 0023 – 0028 (types of API usage monitored), 0030, 0031, 0039, 0042, 0045 (monitoring based on correlating user ID with requests and pattern comparisons), 0049 – 0052 & 0065 – 0068 & 0070 - 0072 (Graphs are created for frequent call flows and for monitored call flows where the graph nodes represent APIs and graph edges represent calls between the APIs and where subgraphs are compared to identify if monitored call flows match the frequent call flows); id. at ¶¶ 0074, 0076 & 0077 (identify abnormal activities and generate visual alert, alert message, or log event); id. at fig. 6; id. at ¶¶ 0070 & 0071 (scoring for matching).}
packets…call flows {Call flows the calls from a client accessing interfaces of applications/microservices on a cloud service are monitored and are reconstructed into a call flow which is analyzed to detect anomalies in the call flow by assembling calls to various interfaces, for example based on transaction ids, into a call flow service graph showing the interfaces called as nodes and the calls between the interfaces as edges representing API keywords such as “HTTP GET or HTTP POST” to identify “outliers in the edges” of the graph and determine the “anomalous call flows” which are identified in part by comparing the call flow graph under analysis to “a set of known call flows to identify the anomalous call flow with a higher degree of confidence.” Tiwari at ¶¶ 0003, 005 – 0007, 0033, 0051 – 0054, 0064 – 0066, 0076; id. at fig. 3 (call flow graph); id. at fig. 4 (identifying API access methods used in call flows); id. at ¶¶ 0047, 0048, 0068 - 0070 (The interface access methods used in the call flows that are analyzed may be API interface access requests for authentication, security certificates, and/or keys); id. at ¶¶ 0030, 0031, 0036, 0037, 0040; id. at ¶ 0002 (packets).}
Claims 9 and 20
With respect to claims 9 and 20, Zhu, Tiwari, and Twohig, teach the invention as claimed including:
wherein determining the user identifier for each of the plurality of computing interface calls further comprises: extracting data from at least one portion of a first [packet] of the plurality of [packets]; and generating a score for each portion of the first [packet], wherein the score for each portion indicates a likelihood that the portion contains user-identifying information, wherein the user identifier for each of the plurality of computing interface calls is determined to be the data extracted from the portion of the first [packet] having the highest score. {A set of API calls from users of client devices having respective user IDs or where the calls are determined to correlate to a user ID based request that are sent to server-based APIs [computing interface] are captured and analyzed in real-time to determine a call structure (flow), identify user usage patterns, create graphs from the usage patterns (610), and to compare the usage patterns to frequently occurring API usage patterns to identify similarity or differences using a “frequent subgraph mining algorithm”. Zhu at Abstract; id. at ¶¶ 0017 – 0021, 0023 – 0028 (types of API usage monitored), 0030, 0031, 0039, 0042, 0045 (monitoring based on correlating user ID with requests and pattern comparisons), 0049 – 0052 & 0065 – 0068 & 0070 - 0072 (Graphs are created for frequent call flows and for monitored call flows where the graph nodes represent APIs and graph edges represent calls between the APIs and where subgraphs are compared to identify if monitored call flows match the frequent call flows); id. at ¶¶ 0074, 0076 & 0077 (identify abnormal activities and generate visual alert, alert message, or log event); id. at fig. 6; id. at ¶¶ 0070 & 0071 (scoring for matching).}
packets {Tiwari at ¶ 0002 (packets).}
Claims 10 and 21
With respect to claims 10 and 21, Zhu, Tiwari, and Twohig, teach the invention as claimed including:
identifying at least one pair of parallel computing interface calls, wherein each pair of parallel computing interface calls has two computing interface calls which overlap, wherein the at least one computing interface call flow is identified based further on the at least one pair of parallel computing interface calls. {Graph may consider equivalent overlapping interface calls for purpose of matching such as AAABC matching AAABDC. Zhu at ¶¶ 0070.}
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEODORE E HEBERT whose telephone number is (571)270-1409. The examiner can normally be reached on Monday to Friday 9:00 a.m. to 6:00 p.m..
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, Lewis Bullock can be reached on 571-272-3759. 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.
/T.H./ February 16, 2026
Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199