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/12/2026 have been fully considered but they are not persuasive.
Applicant’s argument:
As an initial matter, Applicant respectfully submits that Pintiyski in view of Jubran does not teach or suggest "when executed, instantiate at least one object of a class defined in the application code assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object and wherein the executable instructions and the application code together enable resolution of at least one dependency introduced by the external initialization code component during the static analysis" as recited in independent claim 1.
Examiner response:
During emulation/simulation of an application, a call to an external function is made:
[0042] and [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.”;
In order to simulate the API( No source code is available or accessible), the emulator generates code instructions that can return a response according to the called API:
[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 of the corresponding API function according to the virtual implementation of the API function which may be generated using the execution module 440. ……. As a result, at step 505, the emulation module 403 may continue the emulation of the execution of the process 420 from the instruction located at the return address of the API function. In other words, at step 505, the emulation module 403 may utilize the result of the emulation of the execution of the API function.”;
In order to return the result, the execution module generate code instruction that will return such result:
[0080] “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.”
The result generated for example may be:
[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. …... It should be further noted that the code generated by the execution module 440 may be either a virtual code or a native code”;
What returned is assigned back at the return address(transfer of control to the return address) of the invoked API within the process of executing the application: assign the value to an object of the application under simulation.
[0073] “As a result, at step 505, the emulation module 403 may continue the emulation of the execution of the process 420 from the instruction located at the return address of the API function. In other words, at step 505, the emulation module 403 may utilize the result of the emulation of the execution of the API function.”;
Applicant’s argument:
Regarding the feature "the executable instructions and the application code together enable resolution of at least one dependency introduced by the external initialization code component during the static analysis," the Office action relied on Jubran to supply the static analysis element, but Jubran's static analysis is fundamentally different from what the claim requires. Jubran uses pre-built, documentation-derived models to check whether an API is invoked properly, verifying syntax, dependency conditions, and initialization status of arguments. Jubran does not generate executable instructions that, together with the application code, resolve dependencies introduced by an external initialization code component. Instead, Jubran flags errors in API usage without resolving any dependency.
Examiner response:
During source code static analysis, the disclosure of Jubran detect and to evaluate errors that may arise as a result of improper invocation or operation of other external function calls for which source code is not available to static source code analyzer, by creating a model(emulation) for the API call.(Jubran abstract).
The API call is made whthin an application (file, executable ) for external services, whthin the disclosure, the external functions invoked are described as APIs.
Among the errors is dependency error:
[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. API simulator 360 can include that dependency rule, so that an error will be generated by static source code analyzer 300 if the dependent function is not invoked before the API is invoked. Similarly, if it is necessary that an API invoke another function or API after it is called, API simulator 360 also can include that rule to generate an error if the function or API is not called as required”
[0054]“For example, the dependency rules may specify whether certain arguments or memory indicated by pointers passed to the API must be initialized, etc., as well as whether functions that must be invoked after the API. At a step 410, a state object is created to model the function and/or dependency of the API. API modeling ends at a step 412”. See also [0081].
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 limitations 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 from a hook triggered during execution of the application code:
a result of emulating a connection response to a call
within an external initialization code component, to a code object that is inaccessible to the simulator:
wherein the emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
generating, by processing circuitry, executable instructions based on the result received from the hook,
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
and performing static analysis on the application code based on the instructions.
wherein the executable instructions and the application code together enable resolution of at least one dependency introduced by the external initialization code component during the static analysis.
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 emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
Pintiysky discloses:
wherein the emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
[0062] “The emulation of the execution of the virtual code of API functions 441 may have already been done by the execution module 440 on the actual processor 301 of the computer 300. In other words, the virtual code does not perform a detailed simulation of the API function 441, but may merely generate the result of the execution of the API function 441. 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. For example, in response to the calling of a function for working with a file, the emulation module 403 may return the file handler of the requested file. It should be further noted that the emulation of further instructions may be carried out with respect to the changes in the state of registers and/or the stack of the processor.”;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object
[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”;
[0073] “As a result, at step 505, the emulation module 403 may continue the emulation of the execution of the process 420 from the instruction located at the return address of the API function. In other words, at step 505, the emulation module 403 may utilize the result of the emulation of the execution of the API function.”;
the executable instructions 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].
But not explicitly:
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
Jubran discloses:
wherein the executable instructions and the application code together enable resolution:
[0072] As previously described in connection with FIG. 3, in one embodiment of the present invention, API primitives are provided with static source code simulator in a modeling library that allow the static source code simulator to model the behavior of APIs. The API primitives relate to functions that deal with memory initialization, buffers, pointers, memory allocation, and other functions that may be performed by an API. The API primitives can be used to specify that certain conditions must hold when an API is called, and certain results are expected or hold true when the call to the API returns.
of at least one dependency introduced by the external initialization code component during the 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.”;
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 and Jubran 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 from a hook triggered during execution of the application code:
a result of emulating a connection response to a call
within an external initialization code component, to a code object that is inaccessible to the simulator:
wherein the emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
generating, by processing circuitry, executable instructions based on the result received from the hook,
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
and performing static analysis on the application code based on the instructions.
wherein the executable instructions and the application code together enable resolution of at least one dependency introduced by the external initialization code component during the static analysis.
1. A method of 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, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
Pintiysky discloses:
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object
[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”;
[0073] “As a result, at step 505, the emulation module 403 may continue the emulation of the execution of the process 420 from the instruction located at the return address of the API function. In other words, at step 505, the emulation module 403 may utilize the result of the emulation of the execution of the API function.”;
the executable instructions 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].
But not explicitly:
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
Jubran discloses:
wherein the executable instructions and the application code together enable resolution:
[0072] As previously described in connection with FIG. 3, in one embodiment of the present invention, API primitives are provided with static source code simulator in a modeling library that allow the static source code simulator to model the behavior of APIs. The API primitives relate to functions that deal with memory initialization, buffers, pointers, memory allocation, and other functions that may be performed by an API. The API primitives can be used to specify that certain conditions must hold when an API is called, and certain results are expected or hold true when the call to the API returns.
of at least one dependency introduced by the external initialization code component during the 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.”;
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 and Jubran 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 from a hook triggered during execution of the application code:
a result of emulating a connection response to a call
within an external initialization code component, to a code object that is inaccessible to the simulator:
wherein the emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
generating, by processing circuitry, executable instructions based on the result received from the hook,
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
and performing static analysis on the application code based on the instructions.
wherein the executable instructions and the application code together enable resolution of at least one dependency introduced by the external initialization code component during the static analysis.
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 emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
Pintiysky discloses:
wherein the emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
[0062] “The emulation of the execution of the virtual code of API functions 441 may have already been done by the execution module 440 on the actual processor 301 of the computer 300. In other words, the virtual code does not perform a detailed simulation of the API function 441, but may merely generate the result of the execution of the API function 441. 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. For example, in response to the calling of a function for working with a file, the emulation module 403 may return the file handler of the requested file. It should be further noted that the emulation of further instructions may be carried out with respect to the changes in the state of registers and/or the stack of the processor.”;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object
[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”;
[0073] “As a result, at step 505, the emulation module 403 may continue the emulation of the execution of the process 420 from the instruction located at the return address of the API function. In other words, at step 505, the emulation module 403 may utilize the result of the emulation of the execution of the API function.”;
the executable instructions 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].
But not explicitly:
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
Jubran discloses:
wherein the executable instructions and the application code together enable resolution:
[0072] As previously described in connection with FIG. 3, in one embodiment of the present invention, API primitives are provided with static source code simulator in a modeling library that allow the static source code simulator to model the behavior of APIs. The API primitives relate to functions that deal with memory initialization, buffers, pointers, memory allocation, and other functions that may be performed by an API. The API primitives can be used to specify that certain conditions must hold when an API is called, and certain results are expected or hold true when the call to the API returns.
of at least one dependency introduced by the external initialization code component during the 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.”;
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 and Jubran 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 from a hook triggered during execution of the application code:
a result of emulating a connection response to a call
within an external initialization code component, to a code object that is inaccessible to the simulator:
wherein the emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
generating, by processing circuitry, executable instructions based on the result received from the hook,
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
and performing static analysis on the application code based on the instructions.
wherein the executable instructions and the application code together enable resolution of at least one dependency introduced by the external initialization code component during the static analysis.
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 emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
Pintiysky discloses:
wherein the emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource;
[0062] “The emulation of the execution of the virtual code of API functions 441 may have already been done by the execution module 440 on the actual processor 301 of the computer 300. In other words, the virtual code does not perform a detailed simulation of the API function 441, but may merely generate the result of the execution of the API function 441. 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. For example, in response to the calling of a function for working with a file, the emulation module 403 may return the file handler of the requested file. It should be further noted that the emulation of further instructions may be carried out with respect to the changes in the state of registers and/or the stack of the processor.”;
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object
[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”;
[0073] “As a result, at step 505, the emulation module 403 may continue the emulation of the execution of the process 420 from the instruction located at the return address of the API function. In other words, at step 505, the emulation module 403 may utilize the result of the emulation of the execution of the API function.”;
the executable instructions 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].
But not explicitly:
wherein the executable instructions, when executed, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
Jubran discloses:
wherein the executable instructions and the application code together enable resolution:
[0072] As previously described in connection with FIG. 3, in one embodiment of the present invention, API primitives are provided with static source code simulator in a modeling library that allow the static source code simulator to model the behavior of APIs. The API primitives relate to functions that deal with memory initialization, buffers, pointers, memory allocation, and other functions that may be performed by an API. The API primitives can be used to specify that certain conditions must hold when an API is called, and certain results are expected or hold true when the call to the API returns.
of at least one dependency introduced by the external initialization code component during the 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.”;
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 and Jubran 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 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 from a hook triggered during execution of 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;
a result of emulating a connection response to a call
[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”.
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…”
wherein the emulating comprises injecting, without contacting an external resource corresponding to the code object, at least one of an emulated value or an emulated object in place of a response from the external resource:
[0062] “The emulation of the execution of the virtual code of API functions 441 may have already been done by the execution module 440 on the actual processor 301 of the computer 300. In other words, the virtual code does not perform a detailed simulation of the API function 441, but may merely generate the result of the execution of the API function 441. 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. For example, in response to the calling of a function for working with a file, the emulation module 403 may return the file handler of the requested file. It should be further noted that the emulation of further instructions may be carried out with respect to the changes in the state of registers and/or the stack of the processor.”;
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, instantiate at least one object of a class defined in the application code and assign at least one of a value or an object reference produced by the external initialization code component to a field of the instantiated object, the executable instructions corresponding to an initialization of the application code;
[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”;
[0073] “As a result, at step 505, the emulation module 403 may continue the emulation of the execution of the process 420 from the instruction located at the return address of the API function. In other words, at step 505, the emulation module 403 may utilize the result of the emulation of the execution of the API function.”;
[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, wherein the executable instructions and the application code together enable resolution of at least one dependency introduced by the external initialization code component during the static analysis.
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.
wherein the executable instructions and the application code together enable resolution:
[0072] As previously described in connection with FIG. 3, in one embodiment of the present invention, API primitives are provided with static source code simulator in a modeling library that allow the static source code simulator to model the behavior of APIs. The API primitives relate to functions that deal with memory initialization, buffers, pointers, memory allocation, and other functions that may be performed by an API. The API primitives can be used to specify that certain conditions must hold when an API is called, and certain results are expected or hold true when the call to the API returns.
of at least one dependency introduced by the external initialization code component during the 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.”;
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.”
Evaluate API behavior with inaccessible source code:
[0041]”Thus, using API primitives 370 and reviewing SDK/API documentation 380, even without access to the API source code, some rules can be derived to evaluate invocation and/or operation of API signature(s) 352 that may be included in source code 302 submitted to static source code analyzer 300”;
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
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
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
Prosecution Insights