Prosecution Insights
Last updated: April 19, 2026
Application No. 18/760,946

TECHNIQUES FOR PERFORMING STATIC ANALYSIS ON DEPLOYED APPLICATION CODE

Non-Final OA §103§DP
Filed
Jul 01, 2024
Examiner
BOURZIK, BRAHIM
Art Unit
2191
Tech Center
2100 — Computer Architecture & Software
Assignee
Crowdstrike Inc.
OA Round
3 (Non-Final)
65%
Grant Probability
Favorable
3-4
OA Rounds
3y 7m
To Grant
99%
With Interview

Examiner Intelligence

Grants 65% — above average
65%
Career Allow Rate
245 granted / 376 resolved
+10.2% vs TC avg
Strong +45% interview lift
Without
With
+45.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 7m
Avg Prosecution
34 currently pending
Career history
410
Total Applications
across all art units

Statute-Specific Performance

§101
13.0%
-27.0% vs TC avg
§103
62.8%
+22.8% vs TC avg
§102
4.3%
-35.7% vs TC avg
§112
8.1%
-31.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 376 resolved cases

Office Action

§103 §DP
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 . Claims 1-20 are pending in this office action. Claims 1, 8 and 15 are amended. Response to Arguments Applicant's arguments filed 05/27/2025have been fully considered but they are not persuasive. Applicant’s argument: During the telephonic interview, the interview participants discussed Jubran's Fig. 8B, particularly "z=1.". However, the "z=1" in Fig. 8B arises from the source program state used to illustrate error reporting. Jubran does not generate executable assignment code that writes concrete values/object references into the application's variables/fields. Jubran's purpose is to detect improper invocation or unmet pre/post-requisites using state objects and model checks, not to produce init-encoding code derived from hook results. As such, Jubran does not teach or suggest "generating, by processing circuitry, executable instructions based on the result received from the hook, wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code" as recited in independent claim 1. Examiner response: the issue in the argument is that art of record do not generate code that based on the result and specifically Jubran and Pintiyski does not cure Jubran in such deficiencies. First let address the issue of the result and generation of code in view of specification and how this is addressed. What’s the returned result during simulation ? Using anchor point such as: [0046] “ For example, an anchor point may be a function that calls a database, a REST (REpresentational State Transfer) API (application programming interface) call, service request, and the like. These code objects are of interest as they indicate how an application communicates and with what other resources and principals it communicates with.”; Results are identified as: [0050] “In certain embodiments, the result may include any of: a value, a function name, a URL, a library, and the like. In some embodiments, results from the code hook may be stored in a memory or storage of the emulator, and read from there as part of the receiving step”; Making a call to a specific API(name of the API) identifies the API name. and because code is not available, the emulator identifies that specific API. Returning results that is the name of API, library function. Because the code is not available, the emulator generate the code for that corresponding API/library: [0051] “ In an embodiment, the set of instructions may be generated based on: the application code, a stored initialization action (i.e., result received from a code hook), and a combination thereof.; Pintiysky discloses an emulator where the system API calls are emulated and the emulated results of the execution of the function is returned. Starting the analysis, the system invoking the API call(specific API call=name of the API) as it reach that fork or system call, determine that the code for that API call does not exist: what returned by the hook in the language of the claim: API call does not have a source/code(or binary). The emulator generate the code that will return the result in order to continue the analysis. The code generated is based on the invoked API call and its parameters: [0021] In one aspect, the generated result depends on one or more parameters of the invoked API function call and/or depends on a convention for invoking the corresponding API function. [0080]”In yet another particular embodiment, at step 504 described above, the execution module 440 may generate the code configured to return the result of the execution of the invoked API function. The code generated by the execution module 440 may be a stub. Furthermore, the generated code may return a generated result. In various embodiments, the generated result may have arbitrary values or it may depend on the parameters of the API function call and may depend on the convention for invoking the corresponding API function. For example, in response to an invocation of an API function working with a file, the code generated by the execution module 440 may return an arbitrary file handler, as a result of the API function invocation. As another non-limiting example, if the invoked API function deals with integer numbers, the code generated by the execution module 440 may return an arbitrary integer, such as 0. In summary, what returned by the hook is a name of the API and its corresponding parameters that need to be evaluated , but such code and parameters do not exist. In fig. 5, when the execution method arrives at step 502 it makes a determination for existence and availability od the API/call specific code or source code. If the case does not exist( inaccessible, not available) [0080] , a code is generated . the code generated can return: [0080] “For example, in response to an invocation of an API function working with a file, the code generated by the execution module 440 may return an arbitrary file handler, as a result of the API function invocation. As another non-limiting example, if the invoked API function deals with integer numbers, the code generated by the execution module 440 may return an arbitrary integer, such as 0.”; Back to Jubran: Using a static analysis methods, Jubran uses an emulation system to solve(same as Pintiysky) the following: [0012]“Without the source code implementation of the API, a static source code analyzer may be able to evaluate the syntax of an API call by determining whether appropriate arguments are passed to the API in accordance with the API signature. However, without the source code, a static source code analyzer cannot semantically evaluate API signature(s) 152, their behavior, of their effect on source code that invokes API signature(s) 152. Upon encountering the "extern" designation, the static source code analyzer makes no attempt to semantically evaluate the expression that follows. To solve such issue the disclosure uses a simulation method to emulate such call for analyzing invocation of an external function for which function source code implementation is not available [0016]. In Jubran disclosure a static analyzer analyzes the code: [0018] “The source code analyzer includes a model repository configured to store the model created, such that the source code analyzer can access the model upon evaluating source code and identifying a reference to the external function.’; During an analysis some parameter may be needed to pass to an external API: that the result [0043] In addition, API models included in the API simulator may include dependency rules. For example, it is possible that before an API is called, an argument passed to the API must be initialized, or another API or some other function on which an API depends must be invoked.”; Based on the result the model is generated in order for the static analyzer to finish the analysis. While the model is generated is stored for future reference. And hence the call is to an API where the source code does not exist: [0039] “ Instead, for each API signature that is contemplated, expected, or desired to be used with source code 302, API simulator 360 includes a model for the evaluation of each API signature. For example, models may be developed for a group of APIs identified as the most likely to be called. As a result, most noise that would otherwise be included in error report 310 due to false positives can be eliminated without having to include models of every API that might be called.”; Example of code generated is: [0078]”Using the some of the API primitives, based on information about the API derivable from the API documentation, the API SomeFunctionAPI may be modeled to facilitate a more accurate evaluation of the source code by the static source code analyzer: bool SomeFunctionAPI(int a, int* b) { CheckIntegerIsInitialized(a); CheckIntegerBoundsGreaterEqual(a, 1, INT_MAX); CheckPointerIsValid (b); ReturnIntegerValueGreaterThan(&b, 0); } Thus, when the simulator identifies a call to SomeFunctionAPI, the simulator API searches a repository of models checked by the static source code simulator.Upon finding the model for SomeFunctionAPI, accesses the model to assist in evaluating behavior of the source code, including the behavior of the APIs represented by a model in the repository of models. Accordingly, as further described below, the static source code analyzer is able to identify semantic errors related to the use of APIs that might be missed, as well as to reduce noise and false positive error messages that might be generated by a static source code analyzer not able to access the source code implementations of APIs invoked by the source code.” And the report is generated based on static analysis: [0081] “ At state 506, it is determined if the dependency conditions of the API are met. If not, at a state 508, a dependency error is generated that is included in the error report produced by the static source code analyzer.”; Double Patenting The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. A- Claims 1, 8, 15 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 9, 10 of U.S. Patent No. 12045588 in view of Pintiyski et al US20210397708A1. Although the claims at issue are not identical, they are not patentably distinct from each other. Mapping of limitation from dependents claims 1 for example is as follow. The corresponding limitation from the claims have same cues while the bald limitation constitute the difference. Application: 18/760,946 Patent: 12,045,588 1.A method of detecting code initialization actions, comprising: executing application code on a simulator; receiving a result from a hook in response to the executing the application code, the hook corresponding to a call within an external initialization component to a code object that is inaccessible to the simulator, and the result is from an emulation of a connection response corresponding to the code object; generating, by processing circuitry, executable instructions based on the result received from the hook, wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code; and performing static analysis on the application code based on the instructions. 1. A method of detecting code initialization actions, comprising: receiving a result from the hook in response to executing the application code on a simulator, wherein the other code object is inaccessible to the simulator and the result is from an emulation of a connection response corresponding to the other code object; generating instructions based on the result; and performing static analysis on the application code based on the instructions. independent claim 8 Independent claim 9 Independent claim 15 Independent claim 10 But not explicitly: wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code; Pintiysky discloses: wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field: [0062] “This generated result may be indicative of the result of the execution of the API function.The generated result may include the returnable value and the change in state of the registers and/or the stack of the processor, depending on the implementation of the virtual code of that API function”; and comprise at least one instruction corresponding to an initialization of the application code: [0068] “For Win32 applications, it may be necessary to emulate the launching of smss.exe followed by the launching of csrss.exe, which initializes the Windows subsystem and makes it possible to create processes and threads.”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Pintiysky into teachings of the patent to provide a method and a system for evaluating external function calls, such as API calls, even when the source code implementation of the external function call is not available. Furthermore, for identifying potential error resulting from improper invocation of an application programming interface (API) call by source code and condition resulted in potential error [Jubran 0015]. B-Claims 1, 8, 15 provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 7, 6 of co-pending Application No. 17/804,063 in view of Pintiyski et al US20210397708A1. Although the claims at issue are not identical, they are not patentably distinct from each other. Mapping of limitation from dependents claims 1 for example is as follow. The corresponding limitation from the claims have same cues while the bald limitation constitute the difference. Application: 18/760,946 Application 17/804,063 1.A method of detecting code initialization actions, comprising: executing application code on a simulator; receiving a result from a hook in response to the executing the application code, the hook corresponding to a call within an external initialization component to a code object that is inaccessible to the simulator, and the result is from an emulation of a connection response corresponding to the code object; generating, by processing circuitry, executable instructions based on the result received from the hook, wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code; and performing static analysis on the application code based on the instructions. 1. A method for emulating application code in a simulated environment, comprising: receiving an application code including an external initialization code component, the application code deployed in a cloud computing environment; detecting a connection request in the external initialization code component; emulating a response to the connection request; emulating a response to the connection request, the emulating comprising injecting,within the simulated environment and without contacting the external resource, at least one of an emulated object or an emulated value in place of a response from the external resource; and storing the emulated response for generating a set of instructions for a static analyzer to perform static analysis on the application and the generated set of instructions. Independent claim 15 Independent claim 7 Independent claim 15 Independent claim 6 But not explicitly: wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code; Pintiysky discloses: wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field: [0062] “This generated result may be indicative of the result of the execution of the API function.The generated result may include the returnable value and the change in state of the registers and/or the stack of the processor, depending on the implementation of the virtual code of that API function”; and comprise at least one instruction corresponding to an initialization of the application code: [0068] “For Win32 applications, it may be necessary to emulate the launching of smss.exe followed by the launching of csrss.exe, which initializes the Windows subsystem and makes it possible to create processes and threads.”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Pintiysky into teachings of the patent to provide a method and a system for evaluating external function calls, such as API calls, even when the source code implementation of the external function call is not available. Furthermore, for identifying potential error resulting from improper invocation of an application programming interface (API) call by source code and condition resulted in potential error [Jubran 0015]. C- Claims 1, 8, 15 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 10, 11 of U.S. Patent No. 12032471 in view of Pintiyski et al US20210397708A1. Although the claims at issue are not identical, they are not patentably distinct from each other. Mapping of limitation from dependents claims 1 for example is as follow. The corresponding limitation from the claims have same cues while the bald limitation constitute the difference. Application: 18/760,946 Patent: 12,032, 471 1.A method of detecting code initialization actions, comprising: executing application code on a simulator; receiving a result from a hook in response to the executing the application code, the hook corresponding to a call within an external initialization component to a code object that is inaccessible to the simulator, and the result is from an emulation of a connection response corresponding to the code object; generating, by processing circuitry, executable instructions based on the result received from the hook, wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code; and performing static analysis on the application code based on the instructions. 1. receiving a result from a code hook, the code hook inserted into an application code at an anchor point, the application code deployed in a cloud computing environment, wherein the application code requires an external initialization framework; in response to emulating execution of the application code on an initialization emulator corresponding to the external initialization framework. and generating a set of instructions based on the result and the anchor point of the application code. A method of generating a set of instructions for static analysis, comprising: Independent claim 8 Independent claim 10 Independent claim 8 Independent claim 11 But not explicitly: wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code; Pintiysky discloses: wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field: [0062] “This generated result may be indicative of the result of the execution of the API function.The generated result may include the returnable value and the change in state of the registers and/or the stack of the processor, depending on the implementation of the virtual code of that API function”; and comprise at least one instruction corresponding to an initialization of the application code: [0068] “For Win32 applications, it may be necessary to emulate the launching of smss.exe followed by the launching of csrss.exe, which initializes the Windows subsystem and makes it possible to create processes and threads.”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Pintiysky into teachings of the patent to provide a method and a system for evaluating external function calls, such as API calls, even when the source code implementation of the external function call is not available. Furthermore, for identifying potential error resulting from improper invocation of an application programming interface (API) call by source code and condition resulted in potential error [Jubran 0015]. D-Claims 1, 8, 15 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 9, 13 of U.S. Patent No. 12169714 in view of Pintiyski et al US20210397708A1. Although the claims at issue are not identical, they are not patentably distinct from each other. Mapping of limitation from dependents claims 1 for example is as follow. The corresponding limitation from the claims have same cues while the bald limitation constitute the difference. Application: 18/760,946 Patent: 12,169, 714 1.A method of detecting code initialization actions, comprising: executing application code on a simulator; receiving a result from a hook in response to the executing the application code, the hook corresponding to a call within an external initialization component to a code object that is inaccessible to the simulator, and the result is from an emulation of a connection response corresponding to the code object; generating, by processing circuitry, executable instructions based on the result received from the hook, wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code; and performing static analysis on the application code based on the instructions. 1. A method comprising: receiving an application code comprising an external initialization code component, the application code deployed in a cloud computing environment; simulating a local computing environment in which to execute the application code; emulating the external initialization code component in the simulated local computing environment; recording, by a processing circuitry, an action by the external initialization code component to the application code during code initialization; and generating, based on the action, a set of instructions for a static analyzer to perform static analysis on the application code using the set of instructions. Independent claim 8 Independent claim 9 Independent claim 8 Independent claim 13 But not explicitly: wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field and comprise at least one instruction corresponding to an initialization of the application code; Pintiysky discloses: wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field: [0062] “This generated result may be indicative of the result of the execution of the API function.The generated result may include the returnable value and the change in state of the registers and/or the stack of the processor, depending on the implementation of the virtual code of that API function”; and comprise at least one instruction corresponding to an initialization of the application code: [0068] “For Win32 applications, it may be necessary to emulate the launching of smss.exe followed by the launching of csrss.exe, which initializes the Windows subsystem and makes it possible to create processes and threads.”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Pintiysky into teachings of the patent to provide a method and a system for evaluating external function calls, such as API calls, even when the source code implementation of the external function call is not available. Furthermore, for identifying potential error resulting from improper invocation of an application programming interface (API) call by source code and condition resulted in potential error [Jubran 0015]. 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 (i.e., changing from AIA to pre-AIA ) 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, 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, 7, 8, 14-15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Pintiyski et al US20210397708A1 and further in view of Jubran et al US20060190923A1. As per claim 1, Pintiysky discloses a method of detecting code initialization actions comprising: executing application code on a simulator: [0073] “At step 501, the emulation module 403 may be used to carry out an emulation of the execution of the instructions of the file 320 on the virtual processor 401 of the emulator 400. The emulation module 403 may halt the emulation of the execution of the process 420 in response to an invocation of an API function. receiving a result from a hook in response to the executing the application code: [0074] “It should also be noted that during the emulation steps described above a logging module 407 may record data on the invocations of the API functions and data on the returns from the API functions in a log process. Furthermore, during the emulation process or right after the completion of the emulation, the protection component 200 may use the results provided by the emulator 400 to perform a search for virus signatures using, for example, heuristic rules; the hook corresponding to a call, within an external initialization code component, to a code object that is inaccessible to the simulator: [0021] In one aspect, the generated result depends on one or more parameters of the invoked API function call and/or depends on a convention for invoking the corresponding API function. [0073] However, if the emulation module 403 does not find the invoked API function in one of the updatable modules 430 then, at step 504, the execution module 440 may generate the result of the execution…” and the result is from an emulation of a connection response corresponding to the code object: [0055] “ In other words, the emulation module 402 may emulate the execution of the driver file in the context of a system process. [0080]“In various embodiments, the generated result may have arbitrary values or it may depend on the parameters of the API function call and may depend on the convention for invoking the corresponding API function”. generating, by processing circuitry, executable instructions based on the result received from the hook: [0021] In one aspect, the generated result depends on one or more parameters of the invoked API function call and/or depends on a convention for invoking the corresponding API function. [0080] “In yet another particular embodiment, at step 504 described above, the execution module 440 may generate the code configured to return the result of the execution of the invoked API function. The code generated by the execution module 440 may be a stub. Furthermore, the generated code may return a generated result. In various embodiments, the generated result may have arbitrary values or it may depend on the parameters of the API function call and may depend on the convention for invoking the corresponding API function”; wherein the executable instructions, when executed, assign at least one of a value or an object reference produced by the external initialization code component to a variable or a field: [0062] “This generated result may be indicative of the result of the execution of the API function.The generated result may include the returnable value and the change in state of the registers and/or the stack of the processor, depending on the implementation of the virtual code of that API function”; and comprise at least one instruction corresponding to an initialization of the application code: [0068] “For Win32 applications, it may be necessary to emulate the launching of smss.exe followed by the launching of csrss.exe, which initializes the Windows subsystem and makes it possible to create processes and threads.”; But not explicitly: and performing static analysis on the application code based on the executable instructions. Jubran discloses: performing static analysis on the application code based on the instructions: [0015] From this descriptive information, a model can be developed to ensure that the API is properly invoked. A set of primitives included with the static source code analyzer according to an embodiment of the present invention provides a user with a way to model the function of the API so that the static source code analyzer can evaluate the behavior and effect of API calls. Jubran also discloses: generating, by processing circuitry, instructions based on the result: [0043] In addition, API models included in the API simulator may include dependency rules. For example, it is possible that before an API is called, an argument passed to the API must be initialized, or another API or some other function on which an API depends must be invoked.”; wherein the instructions comprise at least one instruction corresponding to an initialization of the application code; [0078]”Using the some of the API primitives, based on information about the API derivable from the API documentation, the API SomeFunctionAPI may be modeled to facilitate a more accurate evaluation of the source code by the static source code analyzer: bool SomeFunctionAPI(int a, int* b) { CheckIntegerIsInitialized(a); CheckIntegerBoundsGreaterEqual(a, 1, INT_MAX); CheckPointerIsValid (b); ReturnIntegerValueGreaterThan(&b, 0); } Thus, when the simulator identifies a call to SomeFunctionAPI, the simulator API searches a repository of models checked by the static source code simulator.Upon finding the model for SomeFunctionAPI, accesses the model to assist in evaluating behavior of the source code, including the behavior of the APIs represented by a model in the repository of models. Accordingly, as further described below, the static source code analyzer is able to identify semantic errors related to the use of APIs that might be missed, as well as to reduce noise and false positive error messages that might be generated by a static source code analyzer not able to access the source code implementations of APIs invoked by the source code.” It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Jubran into teachings of Pintiysky to provide a method and a system for evaluating external function calls, such as API calls, even when the source code implementation of the external function call is not available. Furthermore, for identifying potential error resulting from improper invocation of an application programming interface (API) call by source code and condition resulted in potential error [Jubran 0015]. As per claim 7, the rejection of claim 1 is incorporated and furthermore Pintiysky discloses: wherein the hook is an instruction that, when executed by the application code, stores a state of the application code in a predetermined location. [0005] During the emulation, a log of function calls is formed, to which the antivirus scan also has access. The log usually keeps data on the calls of API functions made by the process during the emulation of the execution, and also data on the returns from the API functions called (transfer of control to the return address).”; Claims 8, 14 are the non-transitory computer readable medium claim corresponding to method claims 1, 7 and rejected under the same rational set forth in connection with the rejection of claims 1, 7 above. Claims 15, 19 are the system claim corresponding to method claims 1, 7 and rejected under the same rational set forth in connection with the rejection of claims 1, 7 above. Claims 2-5, 9-12, 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Pintiyski et al US20210397708A1 and further in view of Jubran et al US20060190923A1 and Akavian et al US20050039187A1. As per claim 2, the rejection of claim 1 is incorporated and furthermore Pintiysky does not discloses: wherein, prior to receiving the result, the method further comprises: detecting an anchor point in the application code; and inserting the hook into the application code based on a location of the anchor point in the application code. Avakian discloses: wherein, prior to receiving the result, the method further comprises: detecting an anchor point in the application code; and inserting the hook into the application code based on a location of the anchor point in the application code: [0053] “By way of example, FIG. 2 schematically illustrates modification of an exemplary class C, and more specifically modification of one or more methods of class C, of a Java application by the BIC tool 26 of the invention as the class is being loaded by a JVM 28 running on an application server, e.g., a J2EE application server [0055]”The HookControl interface 34 can direct instrumentation of selected methods of software components, such as, servlets, JSP classes, EJB classes, and JDBC classes. For example, for JSP classes, the _jspService method can be identified for instrumentation. As another example, the service method or the doFilter, doGet, and doPost methods of servlet classes can be selected for instrumentation. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Avakian into teachings of Pintiysky and Jubran to allow monitoring performance of transactions that originate from a computer system and can invoke software components in other computer systems. Furthermore, a transaction receptor can receive the data from the transaction collector , and can forward the data to an analysis and presentation module . The module can analyze the data to determine the response time corresponding to the instrumented transaction, and can present the analyzed data in a variety of formats, to derive performance metrics associated with transactions executed by such applications [Avakian 0009]. As per claim 3, the rejection of claim 2 is incorporated and furthermore Pintiysky does not discloses: wherein the detecting the anchor point further comprises: determining that a plurality of software classes inherit a primary software class; and designating the primary software class as the anchor point ; Avakian discloses: wherein the detecting the anchor point further comprises: determining that a plurality of software classes inherit a primary software class; and designating the primary software class as the anchor point : [0154]”The correlator A, and subsequently generated correlators associated with Transactions B and C described below, can include a number of fields, each of which provides selected context information regarding the respective transaction. With reference to FIG. 18, in this exemplary embodiment, a correlator 66, e.g., the correlator A, includes a field 66 a that identifies the top-level transaction in a hierarchical transaction chain, and a second field 66 b that identifies the parent of a current transaction. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Avakian into teachings of Pintiysky and Jubran to allow monitoring performance of transactions that originate from a computer system and can invoke software components in other computer systems. Furthermore, a transaction receptor can receive the data from the transaction collector , and can forward the data to an analysis and presentation module . The module can analyze the data to determine the response time corresponding to the instrumented transaction, and can present the analyzed data in a variety of formats, to derive performance metrics associated with transactions executed by such applications [Avakian 0009]. As per claim 4, the rejection of claim 2 is incorporated and furthermore Pintiysky does not discloses: wherein the detecting the anchor point further comprises: determining that a software class name comprises at least one of a predetermined signature or a name having a predetermined alphanumeric string; and designating a software class corresponding to the software class name as the anchor point: Avakian discloses: wherein the detecting the anchor point further comprises: determining that a software class name comprises at least one of a predetermined signature or a name having a predetermined alphanumeric string; and designating a software class corresponding to the software class name as the anchor point: [0072] “FIG. 4 illustrates a prototype 400 of the hookClass method 33. The “classname” parameter 402 of the hookClass method 33 contains the name of the found class. The “methods” parameter 404 is an array of names of methods found in the class. Preferably, the instrumentation tool 38 identifies static and instance methods in the “methods” parameter 404. The instrumentation tool 38 could be easily modified to also identify other methods, such as constructors, for instrumentation, if desired. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Avakian into teachings of Pintiysky and Jubran to allow monitoring performance of transactions that originate from a computer system and can invoke software components in other computer systems. Furthermore, a transaction receptor can receive the data from the transaction collector , and can forward the data to an analysis and presentation module . The module can analyze the data to determine the response time corresponding to the instrumented transaction, and can present the analyzed data in a variety of formats, to derive performance metrics associated with transactions executed by such applications [Avakian 0009]. As per claim 5, the rejection of claim 2 is incorporated and furthermore Pintiysky discloses: wherein the anchor point is at least one of a function calling a database, a REST API (REpresentational State Transfer Application Programming Interface) call, a software library, an initialization code, an external configuration call, or a service request. [0005] During the emulation, a log of function calls is formed, to which the antivirus scan also has access. The log usually keeps data on the calls of API functions made by the process during the emulation of the execution, and also data on the returns from the API functions called (transfer of control to the return address). Examiner interpretation: The API call is to external services and Jubran also discloses the that call is to an external service/function/API where the source code is unreachable(not available [0015]). Claims 9, 10, 11, 12 are the non-transitory computer readable medium claim corresponding to method claims 2, 3, 4, 5 and rejected under the same rational set forth in connection with the rejection of claims 2, 3, 4, 5 above. Claims 16, 17, 18 are the system claim corresponding to method claims 2, 3, 4 and rejected under the same rational set forth in connection with the rejection of claims 2, 3, 4 above. Claims 6, 13, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pintiyski et al US20210397708A1 and further in view of Jubran et al US20060190923A1 and Doldy et al US20180121320A1. As per claim 6, the rejection of claim 1 is incorporated and furthermore Pintiysky does not discloses: wherein the application code is deployed in a cloud computing environment and uses an external initialization framework. Jubran discloses: wherein the application code uses an external initialization framework: [0015] “Accordingly, one advantage of the present invention is that it provides a method and a system for evaluating external function calls, such as API calls, even when the source code implementation of the external function call is not available.”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Jubran into teachings of Pintiysky to provide a method and a system for evaluating external function calls, such as API calls, even when the source code implementation of the external function call is not available. Furthermore, for identifying potential error resulting from improper invocation of an application programming interface (API) call by source code and condition resulted in potential error [Jubran 0015]. But not explicitly the application code is deployed in a cloud computing environment Doldy discloses: wherein the application code is deployed in a cloud computing environment : [0091]“Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. Also, Doldy discloses: [0065]:In some embodiments, a static debugging tool for checking source code that generates usage strings for accessing external services is provided. An external service is a service that is provided by an entity outside of the source code (e.g., another website, another program, another device, etc.) or a service that is not defined by the source code. The static web API invocation debugging tool described by reference to FIGS. 1-8 above is one embodiment of a static usage string debugging tool. A static usage strings debugging tool checks a program that generates usage strings for using external services by statically examining the program's source code. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Doldy into teachings of Pintiysky and Jubran for identifying an invocation statement in the source code for using a service provided by an entity outside of the source code (150), identifying data flow of string variables in the source code that lead to the identified invocation statement, assembling the usage strings formed at the invocation statement based on the identified data flow of string variables, and checking each assembled string based on a specification that describes permissible strings. One assembled usage string has a placeholder string to represent a string variable in the identified data flow [Doldy 0032]. Claim 13 is the non-transitory computer readable medium claim corresponding to method claim 6 and rejected under the same rational set forth in connection with the rejection of claim 6 above. Claim 20 is the system claim corresponding to method claim 6 and rejected under the same rational set forth in connection with the rejection of claim 6 above. Pertinent arts: US11030082B1: An application programming interface (API) simulator generates synthetic responses for use during development and testing of subsystems. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4: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, Wei Y Mui can be reached on 571-270-2738. 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. /BRAHIM BOURZIK/ Examiner, Art Unit 2191 /WEI Y MUI/ Supervisory Patent Examiner, Art Unit 2191
Read full office action

Prosecution Timeline

Jul 01, 2024
Application Filed
Feb 20, 2025
Non-Final Rejection — §103, §DP
Apr 11, 2025
Applicant Interview (Telephonic)
Apr 14, 2025
Examiner Interview Summary
May 27, 2025
Response Filed
Sep 03, 2025
Final Rejection — §103, §DP
Oct 23, 2025
Examiner Interview Summary
Oct 23, 2025
Applicant Interview (Telephonic)
Nov 11, 2025
Response after Non-Final Action
Dec 08, 2025
Request for Continued Examination
Dec 18, 2025
Response after Non-Final Action
Feb 06, 2026
Non-Final Rejection — §103, §DP
Apr 15, 2026
Applicant Interview (Telephonic)
Apr 16, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12585459
UPDATING SYSTEM, ELECTRONIC CONTROL UNIT, UPDATING MANAGEMENT DEVICE, AND UPDATING MANAGEMENT METHOD
2y 5m to grant Granted Mar 24, 2026
Patent 12578931
INTELLIGENT AND EFFICIENT PIPELINE MANAGEMENT
2y 5m to grant Granted Mar 17, 2026
Patent 12566600
LIMITED USE LINKS FOR DATA ITEM DISTRIBUTION
2y 5m to grant Granted Mar 03, 2026
Patent 12561228
Optimal Just-In-Time Trace Sizing for Virtual Machines
2y 5m to grant Granted Feb 24, 2026
Patent 12554625
TESTING CONTINUOUS INTEGRATION AND CONTINUOUS DEPLOYMENT (CI/CD) PIPELINE
2y 5m to grant Granted Feb 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
65%
Grant Probability
99%
With Interview (+45.0%)
3y 7m
Median Time to Grant
High
PTA Risk
Based on 376 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month