3865DETAILED 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 .
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.
Claims 1-20 are pending of which claims 1 and 20 are independent claims.
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 filed on 03/17/2026 has been entered.
Response to Arguments
The applicant's arguments filed on 02/15/2026 regarding claims 1-21 have been fully considered but the arguments are essentially directed towards the newly introduced limitations, and they are addressed in this Office Action, below.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 18 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR).
Regarding claim 1: LASHVICHER teaches: A method for identifying a vulnerability in a software application, the method comprising:
receiving a specification of a plurality of application programming interface (API) endpoints in the software application (LASHVICHER - [0013]: The application generally makes API requests from the user computer to the host server to retrieve desired information. [0053]: The API described herein may be implemented as one or more calls in program code that send or receive one or more parameters through a parameter list or other structure based on a call convention defined in an API specification document);
detecting a first API endpoint of the software application that exposes user information (LASHVICHER - [0012]: The API security system analyzes a group of API requests to determine how unique or common each field value is with respect to multiple users. The uniqueness of a field value may be an indicator that it is a sensitive field (i.e., a field that has values unique to each user or a small group of users));
However, LASHVICHER doesn’t explicitly teach, but ACAR discloses:
identifying in the software application an execution path comprising an ordered sequence of two or more of the API endpoints, wherein output generated by a given API endpoint in the ordered sequence is used as an input parameter for a next API endpoint in the ordered sequence, the ordered sequence starting with a second API endpoint and ending with the first API endpoint (ACAR - [0017]: As shown in call flow pattern 200, service instance 102(1) can receive the service request from client 202, which includes an invocation of an API “A1” exposed by front-end service layer 204. In response, service instance 102(1) can execute API A1 and issue two downstream API calls to business logic layer 204: a first call of an API “A2” to service instance 102(2) and a second call of the same API A2 to service instance 102(3). [0016]: Since software system 100 is a “layered” system, service instances 102(1)-(N) are generally configured to invoke each other according to ordered API call sequences (i.e., call flows) in order to carry out various tasks);
simulating an attack on the software application that exploits the identified execution path (ACAR - [0026]: consider a scenario in which an attacker compromises service instance 102(2) and causes instance 102(2) to issue of a number of calls of API A3 to service instance 102(4) for some malicious purpose (e.g., collecting sensitive/confidential data via data access service layer 208));
issuing an alert when the simulated attack is found to have been successful (ACAR - [0047]: Threat discovery 105 generates an API security report that inventories the discovered APIs and indicates and discovered API threats. API security service 102 transfers the security report for delivery to operator environment 120 if CF observer 110 determines that call flow Cis not an allowed flow (block 510), CF observer 110 can conclude that an anomaly has been detected and can identify one or more actions to take in response to the detected anomaly (block 512) … The following is a non-exhaustive list of possible actions (other actions not on this list are believed to be within the scope of the present disclosure and will be evident to one of ordinary skill in the art): Raise an alert to a human for review/intervention).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER with ARCA so that evaluate is based on user privacy values. The modification would have allowed the system to include user privacy values in the database for secure communication.
Regarding claim 2: LASHVICHER as modified discloses wherein the vulnerability comprises a vulnerability to broken object level authorization (BOLA) attacks, and wherein the attack comprises a given BOLA attack (LASHVICHER - [0026]: the object level authorization (e.g., authorization of a JSON object) performed by sending the user account number from the user computer to the host to access the user profile information is broken because the user account number suffers from a weakness (e.g., a format that can be used to determine other user account numbers)).
Regarding claim 18: LASHVICHER as modified discloses wherein the user information comprises sensitive data (LASHVICHER - [0012]: the field may be categorized as a sensitive field (e.g., userID, account number, etc.) that may require further protection).
Regarding claim 20: this claim defines a apparatus that corresponds to system claim 1 and does not define beyond limitations of claim 1. Therefore, claim 20 is rejected with the same rational as in the rejection of claim 1. Furthermore, LASHVICHER in para. [0047] discloses a processor and a memory.
Regarding claim 21: this claim defines a produce, i.e. a computer-readable medium claim that corresponds to system claim 1 and does not define beyond limitations of claim 1. Therefore, claim 20 is rejected with the same rational as in the rejection of claim 1. Furthermore, LASHVICHER in para. [0044] discloses a Computer-readable medium 710.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR) and Jeevagunta et al. (US 2024/0403444, hereinafter Jeevagunta).
Regarding claim 3: LASHVICHER as modified discloses wherein the specification comprises an OpenAPI specification (Jeevagunta - [0021]: commonly used API endpoints in publicly available open API specifications associated with organization 110).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER, ACAR with Jeevagunta so that openAPI specification is used.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR) and Mohan et al. (US 2022/0188161, hereinafter Mohan).
Regarding claim 4: LASHVICHER as modified discloses wherein identifying the execution path comprises identifying, in the specification, dependencies between the API endpoints (ACAR - [0021]: at a time a given service instance 102 receives an invocation of an API, CF collector 106 of service instance 102 can create a log entry that comprises information regarding the API call (e.g., service instance identifier, API name, API input parameters, etc.) and a “call flow tag.” In various embodiments, this call flow tag is a data structure (e.g., a vector, array, string, etc.) that includes (1) an identifier of a call flow to which the API call belongs and (2) an ordered series of sub-identifiers that indicate the position of the API call within that call flow).
However, LASHVICHER as modified doesn’t explicitly teach but Mohan discloses generating a dependency tree based on the identified dependencies, and identifying the execution path in the dependency tree (Mohan - [0033]: The orchestrator may generate an execution dependency tree that can describe an execution queue of the resources).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR with Mohan so that an execution dependency tree that can describe an execution queue of the resources.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR) and Mohan et al. (US 2022/0188161, hereinafter Mohan) and Berger et al. (US 2025/0148001).
Regarding claim 5: LASHVICHER as modified doesn’t explicitly teach but Berger discloses wherein identifying the dependencies comprises applying a large language model classifier to the specification (Berger - [0063]: a code parsing pipeline CPP processes an API definition of Amesim AMEGetLibrarylconGeometry, resulting in the structured data for training of the large language model LLM).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR with Mohan and Berger so that LLM is used with specification to get a data structure.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR) and Shelke et al. (US 2025/0007943, hereinafter Shelke).
Regarding claim 6: LASHVICHER as modified doesn’t explicitly teach but Shelke discloses wherein simulating the attack comprises generating a shell script for the software (Shelke - [0078]: the systems and methods may also be extended to include models that can further auto-generate scripts for device platforms based on the simulation schemes and the underlying grammar. The target language, for example, may be any suitable shell script (e.g., Bash, Perl, Python, etc.) for accurate simulation of events).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR with Shelke so that scripts for device platforms based on the simulation schemes can be generated. The modification would have allowed the system to generate script for simulating schemes.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR) and NARAYANAN (US 2025/0278315).
Regarding claim 7: LASHVICHER as modified doesn’t explicitly teach but NARAYANAN discloses wherein detecting the first API endpoint comprises applying a set of rules to the specification, and detecting that a given rule applies to the first API endpoint (NARAYANAN - [0085]: The API portal can be used to describe the rules that an API gateway applies to each API invocation. The gateway can provide the URL for an API, apply rules (sometimes also called policies) to the use of that API, and then direct the API call to the back-end implementation. Typically, the gateway can be given both the API specification and details of the rules it should apply).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR with NARAYANAN so that rules can be applied to API endpoint. The modification would have allowed the system to be more secure.
Regarding claim 10: LASHVICHER as modified discloses wherein a given rule comprises detecting if an input parameter for the first API endpoint comprises a session ID (LASHVICHER - [0028]: API security system 604 may monitor the command fields, host field, session token field and account number field in the API request 102).
Regarding claim 11: LASHVICHER as modified discloses wherein a given rule comprises detecting if an input parameter for the first API endpoint comprises a JavaScript Object Notation (JSON) Web Token (JWT) (LASHVICHER - [0018]: Once the endpoint device (e.g., host server) receives the API request, the information in the API request (e.g., session token, account number and HTTP command) are unpacked (e.g., a JSON token is analyzed) to access the user account and retrieve the desired user profile information).
Regarding claim 12: LASHVICHER as modified discloses wherein a given rule comprises detecting if an input parameter for the first API endpoint comprises an authentication token (LASHVICHER - [0017]: The information in API request 102 may include an HTTP GET command that identifies the host server URL, the host identity, a session token generated during user authentication).
Regarding claim 14: LASHVICHER as modified discloses wherein a given rule comprises detecting if an input parameter for the first API references a user or a group of users of the software application (LASHVICHER - [0012]: a field that has values unique to each user or a small group of users).
Regarding claim 15: LASHVICHER as modified discloses wherein a given rule comprises detecting if an input parameter for the first API (LASHVICHER - [0053]: API calls and parameters may be implemented in any programming language. The programming language may define the vocabulary and calling convention that a programmer will employ to access functions supporting the API).
Regarding claim 16: LASHVICHER as modified discloses wherein the first given API endpoint comprises a schema having a path, and wherein a given rule comprises detecting that the path accesses a unique data object in the software application (ACAR - [0026]: with respect to call flow pattern 200 of FIG. 2, consider a scenario in which an attacker compromises service instance 102(2) and causes instance 102(2) to issue of a number of calls of API A3 to service instance 102(4) for some malicious purpose (e.g., collecting sensitive/confidential data via data access service layer 208)).
The reason to combine is similar as claim 7.
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR), NARAYANAN (US 2025/0278315) and Brown et al. (US 2018/0367557, hereinafter Brown).
Regarding claim 8: LASHVICHER as modified doesn’t explicitly teach but Brown discloses wherein a given rule comprises detecting if an input parameter for the first API endpoint comprises a universally unique identifier (Brown - [0099]: an entry-point node 348 can be a node representing a detection, e.g., of malicious activity. Such nodes can have out-edges to the process(es) or other node(s) involved in or related to the detected malicious activity. Accordingly, an entry-point specifier can include an identifier (e.g., a UUID, hash, or other unique identifier) of a detection).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR, NARAYANAN with Brown so that entry point specifier can include UUID. The modification would have allowed the system to detect malicious activities.
Regarding claim 9: LASHVICHER as modified doesn’t explicitly teach but Brown discloses wherein a given rule comprises detecting if an input parameter for the first API endpoint comprises a globally unique identifier (Brown - [0099]: an entry-point node 348 can be a node representing a detection, e.g., of malicious activity. Such nodes can have out-edges to the process(es) or other node(s) involved in or related to the detected malicious activity. Accordingly, an entry-point specifier can include an identifier (e.g., a UUID, hash, or other unique identifier) of a detection).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR, NARAYANAN with Brown so that entry point specifier can include globally unique identifier. The modification would have allowed the system to detect malicious activities.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR), NARAYANAN (US 2025/0278315) and DUGGAN (US 20230359739).
Regarding claim 13: LASHVICHER as modified doesn’t explicitly teach but DUGGAN discloses wherein a given rule comprises detecting if an input parameter for the first API endpoint comprises a text string having high entropy (DUGGAN - [0036]: if the high entropy string is a parameter of a predetermined function call (e.g., an API call indicative of authentication check), the high entropy string can be a potential backdoor).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR, NARAYANAN with DUGGAN so that high entropy string parameter is detected. The modification would have allowed the system to find potential attack.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR) and Berger et al. (US 2025/0148001, hereinafter Berger).
Regarding claim 17: LASHVICHER as modified doesn’t explicitly teach but Berger discloses wherein identifying the dependencies comprises applying a large language model classifier to the specification (Berger - [0063]: a code parsing pipeline CPP processes an API definition of Amesim AMEGetLibrarylconGeometry, resulting in the structured data for training of the large language model LLM).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR with Berger so that LLM is used with specification to get a data structure.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over LASHVICHER et al. (US 2025/0181756, hereinafter LASHVICHER) in view of ACAR et al. (US 2018/0373865, hereinafter ACAR) and Lal (US 2024/0414190).
Regarding claim 19: LASHVICHER as modified doesn’t explicitly teach but Lal discloses wherein issuing the alert when the simulated attack is found to have been successful comprises analyzing, using a large language model classifier, calls to the API endpoints and their respective responses while simulating the attack (Lal - [0153]: the cyber-attack simulation engine 160 includes a first orchestrator (mitigation) module 400 deployed as an LLM, using AI algorithms coded and trained to perform AI-based simulations of cyber-attacks, to assist in determining 1) how a simulated cyber-attack might occur in a selected computing device protected by the AI-based cybersecurity system 100, and 2) how to use the simulated cyber-attack information to preempt possible escalations of an ongoing actual cyber-attack. Stated differently, the first orchestrator module 400 may be triggered during a training session or another prescribed period of time, either synchronous or asynchronous, to establish a communication session (e.g., series of API calls and returned responses) with the selected computing device to acquire information associated with its operability and the operability of certain components that, if adjusted, may improve device and network security).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of LASHVICHER and ACAR with Lal so that LLM is used to analyze API endpoint calls and responses. The modification would have allowed the system to enhance security.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG LI whose telephone number is (571)272-8729. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/MENG LI/
Primary Examiner, Art Unit 2437
Prosecution Insights