DETAILED ACTION
This action is in response to the amendments filed on April 28, 2026. Claims 1, 3, 6, 7, 9-13, 18, and 20 have been amended. Claims 2 and 14-16 have been canceled. Claims 21-25 are new. Claims 1-20 are pending. Claims 1, 3-12, and 21-25 represent a method, claims 13 and 17-18 represent a system, and claim 20 represent a non-transitory computer-readable storage medium directed to application-integrated security.
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 .
Response to Arguments
Applicant’s arguments and amendments, see remarks and amended claims filed on April 28, 2026, with respect to the rejection(s) of claim(s) 1-20 under 35 USC 102 and 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Al Hamami, Larusson, Anand, and Rosenthal.
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.
Claim(s) 1, 3-4, 6-13, 18, 20 and 22-25 are rejected under 35 U.S.C. 103 as being unpatentable over Al Hamami, Ahmad (US 20150052607), hereinafter referred to as Al Hamami, in view of Larusson et al. (US 20240320321), hereinafter referred to as Larusson.
Regarding Claim 1, Al Hamami discloses:
A method comprising: embedding a first set of code of a local security controller in a second set of code of a particular application (In ¶ 36 Al Hamami discloses “The in-app agent 150 is either included as a library by the developer or may be injected into the protected application 160 via the runtime environment.”), wherein the particular application runs on an operating system of a device (In ¶ 48, Al Hamami discloses “Each server is a computing device having a processor coupled to a memory and to a data communication port (e.g. modem, network adapter, etc.) for data communication with a network to which the server is connected”) with other applications that provide a plurality of different functions and services to other requesting devices (In ¶ 30, Al Hamami discloses “Furthermore, more than one application can be protected by the same set of policies (detection/action), managed by the same user interface, regardless of where the different applications reside.”); executing the particular application in response to a request that is directed to a function or service of the particular application, wherein executing the particular application comprises intercepting the request by the local security controller based on the first set of code executing before the second set of code associated with the function or service in the particular application (In ¶ 47, Al Hamami discloses “it injects code (a hook) into the database interface layer (DB API) that allows it to process requests before the DB API call is made at block 530.” And further discloses in ¶ 11 “the hooking mechanism may use "monkey patching" techniques or utilize a plugin/middleware mechanism provided by the language, framework or runtime of the particular application.”); analyzing, within the secure environment, parameters of the request that call or invoke the function or service against a set of application-specific security rules configured in the first set of code (In ¶ 10, Al Hamami discloses “those hooks call functions (rules) to determine if the query string matches a SQL injection (attack) pattern.” And further in ¶ 29 “Complicated policies can be built using generic detection functions, real-time threat intelligence information, application-specific developer customization”); resuming execution of the second set of code in response to the request not violating any of the set of application-specific security rules, wherein resuming execution of the second set of code comprises invoking the function or service of the particular application with the request (In ¶ 47, Al Hamami discloses “it injects code (a hook) into the database interface layer (DB API) that allows it to process requests before the DB API call is made at block 530.” Wherein because the hook sits directly before the DB API call, the next sequential step would be to execute the code if no violation to the rules are triggered); and performing a protective action that is defined as part of a security rule from the set of application-specific security rules in response to the request violating the security rule, wherein performing the protective action comprises blocking execution of the second set of code (In ¶ 14, Al Hamami discloses “additional automated analysis is performed before deciding on denying the user application access.” And further in ¶ 13 “a filter based on known-malicious-IP addresses or IP reputation, can be updated in real time as the cloud side learns about these malicious IPs and blocks application access to these IP addresses.”).
However, Al Hamami does not explicitly disclose the generation of a secure environment.
Larusson discloses:
generating a secure environment within the particular application based on execution of the first set of code embedded in the particular application, wherein the secure environment prevents access to memory and resources allocated to execution of the second set of code associated with the function or service (In ¶ 3, Larusson discloses “the Wasm instructions are part of a sandboxed environment, which prevents the instructions from affecting anything external to the sandboxed environment by default.” And further discloses in ¶ 16 “a portable executable program is only able to access resources provided by a host in which the portable executable program is executing… a malicious portable executable program on its own (i.e., without assistance from the host) cannot affect other aspects of the computing system outside of the portable executable program.” And further in ¶ 22 “host 102 may be part of another application executing on computing hardware 103 (e.g., may be a component of a web browser application).”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Al Hamami’s approach by implementing an in-application request analysis as a sandboxed WebAssembly module created within the application as disclosed by Larusson as the motivation would be to ensure the Wasm instructions are part of a sandboxed environment, which prevents the instructions from affecting anything external to the sandboxed environment (See Larusson, ¶ 3)
Regarding Claim 3, the combination of Al Hamami and Larusson disclose:
The method of claim 1, wherein embedding the local security controller comprises: defining the first set of code for the local security controller in the particular application before the second set of code associated with the function or service (In ¶ 36, Al Hamami discloses “The in-app agent 150 is either included as a library by the developer or may be injected into the protected application 160 via the runtime environment. For example, this may be done by wrapping the application or by injecting the library directly into the application via available runtime methods.” And further in ¶ 47 “process requests before the DB API call is made at block 530.”)
Regarding Claim 4, the combination of Al Hamami and Larusson disclose the limitations of Claim 1.
However, Al Hamami does not explicitly disclose converting a format.
Larusson discloses:
The method of claim 1 further comprising: converting a first format of the request to a second format of the function or service. (In ¶ 26, Larusson discloses “translation by the abstraction layer enables API 121 to use a single convention that is translated to whatever format file system 104 happens to be by the abstraction layer.”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Al Hamami’s approach by implementing an in-application request analysis as a sandboxed WebAssembly module created within the application as disclosed by Larusson as the motivation would be to ensure the Wasm instructions are part of a sandboxed environment, which prevents the instructions from affecting anything external to the sandboxed environment (See Larusson, ¶ 3)
Regarding Claim 6, the combination of Al Hamami and Larusson disclose:
The method of claim 1, wherein performing the protective action further comprises: preventing the request from calling or invoking the function or service. (In ¶ 14, Al Hamami discloses “A security function can be provided where an attacker sets off a trigger. For example, if there is an attempted SQL injection string, or a session modification attack, then extra logging for that user is performed and that user session is streamed to the cloud service for further inspection by the application developer or additional automated analysis is performed before deciding on denying the user application access.”).
Regarding Claim 7, the combination of Al Hamami and Larusson disclose:
The method of claim 1, wherein performing the protective action comprises: presenting a violation of the security rule in one or more of a log of the particular application or a diagnostic display created during execution of the particular application. (In ¶ 14, Al Hamami discloses “extra logging for that user is performed and that user session is streamed to the cloud service for further inspection by the application developer or additional automated analysis is performed before deciding on denying the user application access.” And further in ¶ 38 “The real-time web dashboard 120 is provided to give the application developer or security operator an insight into the known vulnerabilities, attacks, and general state of security of the web application. ”)
Regarding Claim 8, the combination of Al Hamami and Larusson disclose:
The method of claim 1 further comprising: determining that the request violates the security rule based on data from the request being mismatched with context of the particular application. (In ¶ 14, Al Hamami discloses “if there is an attempted SQL injection string, or a session modification attack, then extra logging for that user is performed and that user session is streamed to the cloud service for further inspection by the application developer or additional automated analysis is performed before deciding on denying the user application access.”)
Regarding Claim 9, the combination of Al Hamami and Larusson disclose:
The method of claim 1 further comprising: customizing the set of application-specific security rules based on threats or attacks that are specific to the function or service and other functions or services of the particular application. (In ¶ 15, Al Hamami discloses “The cloud service is then able to alert the developer of the application about known security issues relating to these software components, and where applicable, prevent known types of attacks against vulnerable components, for example, remote command execution attacks using object serialization features of certain web frameworks.” And further in ¶ 29 “application-specific developer customization”)
Regarding Claim 10, the combination of Al Hamami and Larusson disclose:
The method of claim 1 further comprising: forwarding the request from the local security controller to a remote security controller executing on a different device than the particular application (In ¶ 44, Al Hamami discloses “When the in-app agent 150 detects suspicious activity at step 340, it generates a report and sends it to the cloud service 110 via the agent manager 130 at step 350.”); and activating a protection at the local security controller in response to the remote security controller detecting a violation of a particular security rule that is not part of the set of application-specific security rules (In ¶ 44, Al Hamami discloses “The cloud service analyzes the report and generates new rules to deal with the suspicious activity at step 360 and sends the new rules to the in-app agent 150, via the agent manager 130, at step 370. Finally, the in-app agent applies the new rules to deal with the suspicious activity at step 380. This example represents a reactive situation.” And further in ¶ 14 “that user session is streamed to the cloud service for additional automated analysis is performed before deciding on denying the user application access.”).
Regarding Claim 11, the combination of Al Hamami and Larusson disclose:
The method of claim 10, wherein activating the protection comprises: enforcing the protection against subsequent requests that arrive after the request and that contain an attack signature that is specified as part of activating the protection. (In ¶ 47, Al Hamami discloses “The In-App agent 150 requests an updated rule set for these interfaces at block 540. The In-App agent 150 receives the rules from cloud service 110. Finally, the in-app agent 150 applies the new rules to protect the web application in an enhanced way, as represented by block 570.”).
Regarding Claim 12, the combination of Al Hamami and Larusson disclose:
The method of claim 10, wherein activating the protection comprises: intercepting a second request that arrives after the request (In ¶ 47, Al Hamami discloses “The In-App Agent 150 technology injects hooks into the various interfaces: for example, it injects code (a hook) into the database interface layer (DB API) that allows it to process requests before the DB API call is made at block 530.”); and screening the second request against the set of security rules and an attack signature that is associated with the protection activated by the remote security controller (In ¶ 47, Al Hamami discloses “The In-App agent 150 receives the rules from cloud service 110. Finally, the in-app agent 150 applies the new rules to protect the web application in an enhanced way, as represented by block 570.”)
Claims 13 and 18 are directed to a system having functionality corresponding to the method of Claim 1 and 6, and is rejected by a similar rationale, mutatis mutandis.
Claim 20 is directed to a non-transitory computer readable medium having functionality corresponding to the method of Claim 1 and is rejected by a similar rationale, mutatis mutandis.
Regarding Claim 22, the combination of Al Hamami and Larusson disclose:
The method of claim 1, wherein resuming execution of the second set of code comprises: asynchronously forwarding the request from the local security controller to a remote security controller executing on a different device than the particular application while calling or invoking the function or service of the particular application in response to the request not violating the set of application-specific security rules (In ¶ 44, Al Hamami discloses “it generates a report and sends it to the cloud service 110 via the agent manager 130 at step 350” and further discloses in ¶ 43 “All processing is handled locally based on the rules 170 supplied by the agent manager 130. No additional network latency is added to the application stack shown in FIG. 2.”).
Regarding Claim 23, the combination of Al Hamami and Larusson disclose:
The method of claim 1, wherein resuming execution of the second set of code comprises: forwarding the request from the local security controller to a remote security controller executing on a different device than the particular application; and executing the second set of code in response to the remote security controller verifying that the request does not violate a different second set of rules or the remote security controller not providing a response within a specific amount of time after said forwarding of the request (In ¶ 44, Al Hamami discloses “The cloud service analyzes the report and generates new rules to deal with the suspicious activity at step 360 and sends the new rules to the in-app agent 150, via the agent manager 130, at step 370.” And further discloses in ¶ 14 “additional automated analysis is performed before deciding on denying the user application access.”).
Regarding Claim 24, the combination of Al Hamami and Larusson disclose:
The method of claim 1, wherein resuming execution of the second set of code comprises: and providing the request as input to the second set of code (In ¶ 47, Al Hamami discloses “The In-App Agent 150 technology injects hooks into the various interfaces: for example, it injects code (a hook) into the database interface layer (DB API) that allows it to process requests before the DB API call is made at block 530.”).
However, Al Hamami does not explicitly disclose a secure environment.
Larusson discloses:
releasing the request from the secure environment back to the particular application (In ¶ 27, Larusson discloses “As such, while the abstraction layer isolates portable executable program 101 from interacting with file system 104 directly, the abstraction layer is still enabling access to file system 104 by presenting file system 104 (or a projection thereof) to API 121”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Al Hamami’s approach by implementing an in-application request analysis as a sandboxed WebAssembly module created within the application as disclosed by Larusson as the motivation would be to ensure the Wasm instructions are part of a sandboxed environment, which prevents the instructions from affecting anything external to the sandboxed environment (See Larusson, ¶ 3)
Regarding Claim 25, the combination of Al Hamami and Larusson disclose the limitations of Claim 1.
However, Al Hamami does not explicitly disclose a secure environment.
Larusson discloses:
The method of claim 1, wherein generating the secure environment comprises: initiating a WebAssembly module within the particular application (In ¶ 4, Larusson disclose “includes directing the portable executable program to create a module therein” and further in ¶ 22 “A popular type of portable executable program 101 is a Wasm application, although, other portable formats may be used for portable executable program 101.”) that analyzes the request using first resources allocated to execution of the first set of code without accessing the second set of code or second resources allocated to execution of the second set of code (In ¶ 16, Larusson discloses “WebAssembly (Wasm) formatting, a portable executable program is only able to access resources provided by a host in which the portable executable program is executing.”).
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Al Hamami’s approach by implementing an in-application request analysis as a sandboxed WebAssembly module created within the application as disclosed by Larusson as the motivation would be to ensure the Wasm instructions are part of a sandboxed environment, which prevents the instructions from affecting anything external to the sandboxed environment (See Larusson, ¶ 3)
Claim(s) 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Al Hamami, Ahmad (US 20150052607), hereinafter referred to as Al Hamami, in view of Larusson et al. (US 20240320321), hereinafter referred to as Larusson, in further view of Anand, Kunal et al. (US 11100218), hereinafter referred to as Anand.
Regarding Claim 5, the combination of Al Hamami and Larusson discloses the limitations of Claim 1.
However, Al Hamami does not disclose determining if a SQL injection has occurred.
Anand discloses:
The method of claim 1 further comprising: determining that the request violates the security rule based on the request comprising code in a first language that is different from a second language used to define the function or service (In Col 1, Lines 39-43, Anand discloses “ This is accomplished by providing fragments of a SQL query into an input variable, supplied by a web application user. When the input is evaluated by the application, the tainted SQL query is executed” Further in Col 7, Lines 62-66 “ receiving the SQL string and tokenizing it into a token stream (at 302), iterating over the token stream to generate lexical nodes (at 304), and parsing the lexical nodes to determine query structure and validity (at 306).”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Al Hamami’s approach by utilizing Anand’s approach of utilizing a SQL injection analysis as one of the security rules as the motivation would be ensure tainted SQL queries are not executed by attackers to tamper or steal sensitive information. (See Anand, Col 1, Background)
Claim 17 is directed to a system having functionality corresponding to the method of Claim 5 and is rejected by a similar rationale, mutatis mutandis.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Al Hamami, Ahmad (US 20150052607), hereinafter referred to as Al Hamami, in view of Larusson et al. (US 20240320321), hereinafter referred to as Larusson, in further view of Rosenthal et al. (US 20170104756), hereinafter referred to as Rosenthal.
Regarding Claim 21, the combination of Al Hamami and Larusson discloses the limitations of Claim 1.
However, Al Hamami does not disclose sensitive data.
Rosenthal discloses:
The method of claim 1, wherein performing the protective action further comprises: removing sensitive data from the request before executing the second set of code and calling or invoking the function or service with the request (In ¶ 33, Rosenthal discloses “The injected code is executed before and/or after sensitive user requests (such as a URI request) and data requests (such as a SQL “Select” request) are executed” and further in ¶ 32 “the present invention can replace or delete one or more (or even all) request context and variables in one or more (or even all) instrumented stages of the run-time program… perform one of the following: encrypt/decrypt, tokenize/detokenize, hide, redact, delay or block the sensitive-data-flows and high value transactions of end-users and/or external program interface (API calls).”)).
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Al Hamami’s approach by implementing request level redaction of sensitive data as disclosed by Rosenthal as the motivation would be to ensure protection against exposure of sensitive data (See Rosenthal, ¶¶ 2-4)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Durham et al. (US 20240333501) discloses a method for using an isolated environment and application security when performing a function.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHADI H KOBROSLI whose telephone number is (571)272-1952. The examiner can normally be reached M-F 9am-5pm ET.
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, Rupal Dharia can be reached at 571-272-3880. 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.
/SHADI H KOBROSLI/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights