DETAILED ACTION
This is a final Office action in response to communications received on 02/02/2026. Claims 1, 3, and 7 are amended. Claims 8-20 are canceled. Claims 21-33 are added. Claims 1-7, and 21-33 are examined and are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments filed 02/02/2026, to claim 1 have been fully considered.
Applicant’s Remarks regarding Claim Objections have been found persuasive; therefore, the Objection to claim 7 is withdrawn.
Applicant’s Remarks regarding 103 have been considered, but have not been found persuasive.
Consequently, the rejection of the claims under 35 U.S.C. § 103 is sustained.
Applicant argues on pages 8-9 on the Remarks that “Ermey fails to teach and/or suggest causing an API execution based on actively generating a call function”. However, the Examiner respectfully disagrees. Ermey in Paras. [0244]-[0251], shows “420 call, e.g., computational invocation of an entry point or other routine 504”, and “504 routine 506 in an API 502”, which shows a call, invokes a routine, and that routine belongs to an API. Therefore, the call function causes execution of an API routine. “424 analysis, e.g., static flow analysis, dynamic flow analysis, performance analysis, throughput analysis” shows that the execution is in runtime and the calls are real executions.
Applicant argues on pages 8-9 on the Remarks that “Ermey fails to teach and/or suggest any use of and/or identification of dependencies of one or more APIs on one or more other APIs based on its traffic pattern analysis of the call graph”. However, the Examiner respectfully disagrees. Ermey in Paras. [0071], [0090]-[0093], [0241]-[0252], shows parent-child relationship between service callers and service callees. Therefore, the dependencies between APIs are shown as caller API depends on callee API.
Applicant argues on pages 8-9 on the Remarks that “Ermey and/or Piel, either separately or in any combination, also fail to teach and/or suggest at least these additional amended features”. The argument is moot because newly added claim limitations, require new grounds of rejection necessitated by the amendments. [please see the rejections below]
Applicant argues on pages 8-9 on the Remarks that “Ermey fails to teach and/or suggest generating of any policy, or a change to an existing policy, that "causes restriction of access between at least part of the API, at least part of the at least one other API, and the computer system”. The argument is moot because newly added claim limitations, require new grounds of rejection necessitated by the amendments. [please see the rejections below]
The remaining arguments fail to comply with 37 C.F.R. 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
In addition, Applicant’s remaining arguments filed 02/02/2026, with respect to the rejection of claims 1-7 under 35 USC § 103 have been fully considered but are moot because newly added claim limitations requiring “analyzing system information relating to operation of an application programming interface (API) at a computer system relative to at least one other API other than the API”, and “generating a policy, or change to an existing policy, that causes restriction of access between at least part of the API, at least part of the at least one other API, and the computer system, the restriction of access corresponding to the impact”, require new grounds of rejection necessitated by amendments.
Claim Objections
Claims 4 and 24 are objected to because of the following informalities:
Claim 4 recites “initiated by execution of the API, ….”. It is not clear whether “execution of the API” refers to the execution of the API in claim 1 or is a different execution.
Appropriate correction is required.
Claim 24 is objected to because of the same informalities as claim 4.
Appropriate correction is required.
Claims 7, 27 and 33 are objected to because of the following informalities:
Claim 7 recites “…. the monitoring of the system over the defined period of time for outgoing system traffic ….”. It is not clear whether “outgoing system traffic” refers to the outgoing system traffic in previous step in claim 7 or is a different execution.
Appropriate correction is required.
Claims 27 and 33 are objected to because of the same informalities as claim 7.
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 7, 27 and 33 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7, recite “based on the data obtained from the monitoring of the system over the defined period of time for outgoing system traffic”, which lacks antecedent basis and therefore makes the claims indefinite.
Appropriate corrections are required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 are rejected under 35 U.S.C. 103 over Ermey (US 2023/0289444) in view of Piel (US 2023/0231899).
Regarding claims 1, Ermey teaches the limitations of claim 1 as follows:
A system, comprising: at least one processor; and at least one memory that stores executable instructions that, when executed by the processor, facilitate performance of operations, comprising: analyzing system information relating to operation of an application programming interface (API) at a computer system relative to at least one other API other than the API; (Ermey, Paras. [0071], [0090]-[0102], [0238]-[0252], Fig. 12, step 1202, teaches analyzing/normalizing call graphs which shows relationships between function calls (i.e., relating to operation of an API). Traffic patterns are analyzed (steps 1212, 1214, 1216), where each traffic pattern corresponds to API calls, request flows, and metadata and metadata collected. The system of Ermey describes obtaining traffic patterns that include aggregation of normalized call graphs, and an impact based on the traffic patterns. Therefore, the operation of one API is analyzed in relation to other APIs. “provide service insights from modeled traffic patterns using normalized call tree compositions”, and “use unique identifiers that are bookkept (e.g., correlation vectors) to build 1232 parent-child relationships 1234 between service callers and service callees” which explicitly shows one API operation depends on another API other that the API. Para. [0241], discloses an impact region as a “downstream portion from a node in a call graph or a traffic pattern, e.g., a sub-graph; an impact region of a node X includes calls or routines whose behavior is dependent on the system's behavior at node X” which explicitly describes how operations of one API affect and is related to other APIs).
based on monitoring a data flow of the system with respect to the execution of the API, generating impact data representative of an impact of the execution of the API; (Ermey, Paras. Paras. [0071]-[0079], [0090]-[0102], Fig. 12, teaches analyzing traffic data, and generating impact region 414 (i.e., impact data) to show how execution of an API, affects the system).
and determining that the impact is counter to historical functioning of the system as represented by historical functioning data. (Ermey, Paras. [0071]-[0079], [0087]-[0100], teaches comparing a current deployment traffic pattern to a requisite deployment traffic pattern (i.e., historical functioning data), detecting a malicious act when the behavior is not consistent with historical functioning data).
Ermey does not explicitly disclose:
based on a result of the analyzing of the system information, constructing a call function for execution of the API and executing the call function;
generating a policy, or change to an existing policy, that causes restriction of access between at least part of the API, at least part of the at least one other API, and the computer system, the restriction of access corresponding to the impact.
However, Piel in the same field of endeavor discloses:
based on a result of the analyzing of the system information, constructing a call function for execution of the API and executing the call function; (Piel, Paras. [0079], [0085]-[0089], [0146], [0154]-[0155], Fig. 6A, step 1306, teaches invoking non-public REST APIs to start sessions, and reconstructing API calls via wrappers (i.e., constructing a call function). Sending the request when the session starts, which proceed to server session link 1308, and proxify data 1310).
generating a policy, or change to an existing policy, that causes restriction of access between at least part of the API, at least part of the at least one other API, and the computer system, the restriction of access corresponding to the impact. (Piel, Paras. [0098], [0156], and claim 14, “a Content Security Policy (CSP)within the proxy server 11 may be configured to block requests which are trying to escape the sandbox”, and “the co-browsing server further comprises a content security policy (CSP) in computer-readable memory itemizing requests which are to be blocked” explicitly shows policy configuration/generation. Paras. [0102]-[0103], [0154]-[0155], shows an API-to-API access control system. Paras. [0100]-[0102], [0159]-[0161], shows that the restriction is enforced by system components. Paras. [0096]-[0098], [0100]-[0102], [0154]-[0156], shows that the restriction of access corresponds directly to an impact (APIs cannot access external resources directly, or the API executions are changed as part of reconfiguration (i.e., corresponding to the impact)).
Piel is combinable with Ermey, because both are from the same field of identifying security vulnerabilities in APIs. It would have been obvious to a person having ordinary skill in the art before the effective filling date of the invention to constructing and executing a call function of the API, as taught by Piel with Ermey’s method in order to provide a high-level synchronous API, and avoid inconsistent API usage. [see Piel Para. 0144]
As per claims 21 and 28, claims 21 and 28 encompass same or similar scope as claim 1. Therefore, claims 21 and 28 are rejected based on the reasons set forth above in rejecting claim 1.
Regarding claim 2, Ermey modified by Piel teach the limitations of claim 1. Piel teaches the limitations of claim 2 as follows:
The system of claim 1, wherein the analyzing of the system information comprises analyzing source code corresponding to the API or analyzing a schema document associated with the API. (Piel, Paras. [0079], [0085]-[0089], [0095]-[0102], [0114]-[0118], [0146], [0154]-[0155], teaches parsing and modifying JavaScript code (i.e., analyzing source code…. Or …..) corresponding to APIs).
The same motivation to combine utilized in claim 1 is equally applicable in the instant claim.
As per claims 22 and 29, claims 22 and 29 encompass same or similar scope as claim 2. Therefore, claims 22 and 29 are rejected based on the reasons set forth above in rejecting claim 2.
Regarding claim 3, Ermey modified by Piel teach the limitations of claim 1. Ermey modified by Piel teach the limitations of claim 3 as follows:
The system of claim 1, wherein the generating the impact data comprises monitoring outgoing system traffic, initiating a system process and generating a system file. (Ermey, Paras. [0071]-[0079], [0092]-[0102], [0142], [0181]-[0185], teaches monitoring traffic patterns which includes outgoing calls, and generating test coverage/usage data, initiating/executing system level processes).
Piel in the same field of endeavor teaches the remaining limitations of claim 3 as follows:
(Piel, Paras. [0114], [0146]-[0149], [0152]-[0155], teaches initiating system processes such as Node.js server processes, proxy server operations, cashing services based on the session/impact data).
The same motivation to combine utilized in claim 1 is equally applicable in the instant claim.
As per claims 23 and 30, claims 23 and 30 encompass same or similar scope as claim 3. Therefore, claims 23 and 30 are rejected based on the reasons set forth above in rejecting claim 3.
Regarding claim 5, Ermey modified by Piel teach the limitations of claim 1. Ermey teaches the limitations of claim 5 as follows:
The system of claim 1, wherein the operations further comprise: in response to the determining indicating that the impact is counter to the historical functioning of the system, determining a vulnerability of the system resulting from the executing of the call function, (Ermey, Paras. [0092]-[0102], [0181]-[0185], Fig. 12, teaches executing generated call functions (using generated traffic for testing), where the constructed calls reveal vulnerabilities in the system. The vulnerability related information is generated).
Piel in the same field of endeavor discloses:
and transmitting [vulnerability] information defining the vulnerability to a device associated with an administrator entity of the system. (Piel, Paras. [0079]-[0082], [0118]-[0120], [0163]-[0172], teaches transmitting information (JavaScript, DOM data, bootstrap code, session data) to users (i.e., administrator entity), servers, proxies).
Piel is combinable with Ermey, because both are from the same field of identifying security vulnerabilities in APIs. It would have been obvious to a person having ordinary skill in the art before the effective filling date of the invention to transmit vulnerability information to an administrator, as taught by Piel with Ermey’s method in order to improve system security and reliability.
As per claims 25 and 31, claims 25 and 31 encompass same or similar scope as claim 5. Therefore, claims 25 and 31 are rejected based on the reasons set forth above in rejecting claim 5.
Regarding claim 6, Ermey modified by Piel teach the limitations of claim 1. Ermey modified by Piel teach the limitations of claim 6 as follows:
The system of claim 1, wherein the operations further comprise: in response to the determining indicating that the impact is counter to the historical functioning of the system, remediating a vulnerability of the system comprising initiating execution of instructions that block access to the API via modification of a markup language configuration associated with the API or of a service server configuration corresponding to the API. (Ermey, Paras. [0071]-[0079], [0087], [0092]-[0103], teaches remediation by identifying bad usage patterns, which could trigger blocking (anomaly detection which causing rollback)).
Piel in the same field of endeavor teaches the remaining limitations of claim 6 as follows:
(Piel, Paras. [0098], [0115]-[0118], [0154]-[0155], teaches modifying/parsing API calls with wrappers and reconstructed implementations. Blocking/alerting API access or modifying content as part of security enforcement (policy rules), and modifying the structure/behavior of JavaScript/HTML code (i.e., modification of a markup language configuration), and reconstructing proxified code to enforce policy).
The same motivation to combine utilized in claim 1 is equally applicable in the instant claim.
As per claims 26 and 32, claims 26 and 32 encompass same or similar scope as claim 6. Therefore, claims 26 and 32 are rejected based on the reasons set forth above in rejecting claim 6.
Regarding claim 7, Ermey modified by Piel teach the limitations of claim 1. Ermey modified by Piel teach the limitations of claim 7 as follows:
The system of claim 1, wherein the operations further comprise: in response to determining that the analyzing of the system information has failed due to an inability to analyze source code corresponding to the API or a schema document associated with the API, conducting monitoring of the system over a defined period of time for outgoing system traffic, initiating a system process or generating a system file; (Ermey, Paras. [0069]-[0071], [0089]-[0093], [0181]-[0185], Fig. 12, teaches monitoring of the API call traffic over time which require monitoring over a time window, and fallback analysis when certain usage patterns are not covered. Shows Coverage/signoff gaps, and actively initiating system process in response to analysis results).
and based on the data obtained from the monitoring of the system over the defined period of time for outgoing system traffic, performing the constructing of the call function. (Ermey, Paras. [0069]-[0071], [0089]-[0092], [0181]-[0185], Fig. 12, step 1236, teaches constructing the call function (construct caller, set of call trees). Describes obtaining traffic data over time to form traffic patterns across a time window (not a single obtaining process), and the traffic patterns include aggregations of normalized call graphs (obtained … over a defined period of time). The system uses collected identifiers to form a parent-child relationship between service callers and service callees, and construct a call tree).
Piel in the same field of endeavor teaches the remaining limitations of claim 7 as follows:
(Piel, Paras. [0098], [0115]-[0118], [0147]-[0149], [0154]-[0155], teaches proxies/wrappers to handle failures or non-standard API expressions (proxified JavaScript calls). The system rewrites JavaScript source code to wrap or proxify API calls using sandboxing engine and object wrappers to monitor/alert API usage (monitoring outgoing requests via CSP and proxy). Node.js server process configured to keep the current DOM state active for all active sessions (i.e., initiating system processes)).
The same motivation to combine utilized in claim 1 is equally applicable in the instant claim.
As per claims 27 and 33, claims 27 and 33 encompass same or similar scope as claim 7. Therefore, claims 27 and 33 are rejected based on the reasons set forth above in rejecting claim 7.
Claim 4 is rejected under 35 U.S.C. 103 over Ermey (US 2023/0289444) in view of Piel (US 2023/0231899), and further in view of Tatarinov (US 2014/0366137).
Regarding claim 4, Ermey modified by Piel teach the limitations of claim 1. They do not explicitly teach the limitations of claim 4. However, Tatarinov in the same field of endeavor teaches the limitations of claim 4 as follows:
The system of claim 1, wherein the determining whether the impact is counter to the historical functioning of the system comprises comparing data associated with an initiated system process or a generated system file, initiated by execution of the API, to a selected database comprising data defining known malicious processes, malicious files or both. (Tatarinov, Paras. [0021]-[0032], [0051]-[0052], teaches analyzing executable file 210, extracting its resources such as icons, scripts, dialogue windows, etc., and sending them to the comparison module 230 for evaluation. A database 250 stores known resources of malicious executable files to check similarity between resources and the ones stored in the database. The verification module 240, determines whether the executable file is malicious)
Tatarinov is combinable with Ermey and Piel, because all are from the same field of identifying security vulnerabilities. It would have been obvious to a person having ordinary skill in the art before the effective filling date of the invention to compare data with known malicious process/files, as taught by Piel with Ermey-Piel’s method in order to monitor system processes/files besides API behavior to enhance security.
As per claim 24, claim 24 encompass same or similar scope as claim 4. Therefore, claim 24 is rejected based on the reasons set forth above in rejecting claim 4.
References Considered But Not Relied Upon
Copty (US 12,481,487) teaches building dependency graphs that map pipeline sources to API calls, and pipeline targets to find root causes of vulnerabilities.
Duplys (US 12,353,930) teaches transmitting intrusion messages from decoy APIs to an intrusion detection system (IDS) as an administrator.
Shevchenko (US 2009/0049550) discloses a method of analyzing source codes related to files, and suspend/delete the process with early system calls.
Conclusion
Accordingly, claims 1-7, and 21-33 are rejected.
THIS ACTION IS MADE FINAL. 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PEGAH BARZEGAR whose telephone number is (703)756-4755.
The examiner can normally be reached M-F, 9:00 - 5:30. Examiner interviews are available via telephone, 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, Taghi T Arani can be reached on 571-272-3787. The fax phone number for the Application/Control Number: 17/470,067 Page 17 Art Unit: 2438 organization where this application or proceeding is assigned is 571-273- 8300. Application/Control Number: 17/386,076 Page 25 Art Unit: 2438 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/patentcenter 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.
/P.B./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights