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 .
EXAMINER’S AMENDMENT
Authorization for this examiner’s amendment was given in an interview with Robert Lord on 3/26/2026.
The application has been amended as follows:
(Currently Amended) A method for improving client-side cybersecurity, the method comprising:
generating scan results by executing a scan by a server-side web browser, wherein:
the scan comprises a behavior pattern that defines a simulated use, by a client-side web browser, of the server-side web browser to access a web service,
executing the scan comprises causing the server-side web browser to access the web service, on behalf of the client-side web browser, according to the behavior pattern,
the scan results comprise monitoring information generated by monitoring execution of the scan;
detecting, using the scan results, a vulnerability of data accessed during the simulated use of the server-side web browser, wherein the vulnerability comprises a data access vulnerability of the client-side web browser;
determining, responsive to detecting the vulnerability, an access mode for the data, wherein the access mode comprises a permission state for a script, function, or program executable by the client-side web browser; and
applying, by the server-side web browser, the access mode to the client-side web browser by injecting replacement code in the client-side web browser, wherein the replacement code is executable by the client-side web browser to add the permission state for the script, function, or program.
(Previously Presented) The method of claim 1, wherein the replacement code is further executable to block access to the data and permit access to the data.
(Currently Amended) The method of claim 1, wherein the data is provided by the server-side web browser to the web service, is provided by the web service to the server-side web browser, or a combination thereof.
(Previously Presented) The method of claim 1, wherein the access mode is specific to a script type of the script attempting to access the data, and wherein the access mode blocks execution of the script.
(Original) The method of claim 4, wherein the script type comprises at least one of a first party script, a third party script, an Nth party script, a first party tracker, a relationship between the script and the web service, and combinations thereof.
(Currently Amended) The method of claim 1, wherein the server-side web browser executes in a monitored environment, and wherein the method further comprises:
determining that the server-side web browser accesses the data using native code of the monitored environment; and
replacing the native code with modified native code comprising functionality to (i) observe an attempt to access the data, and (ii) comply with the access mode when the attempt to access the data is executed.
(Original) The method of claim 1, further comprising:
determining, using a machine learning model, an asset class of the data.
(Previously Presented) The method of claim 7, wherein the access mode comprises the permission state for the script, the method further comprising:
attempting, by the script, to access the data; and
determining the access mode using the asset class and a script type of the script attempting to access the data.
(Currently Amended) The method of claim 1, further comprising:
detecting, using the scan results, malware in the data accessed by the server-side web browser.
(Original) The method of claim 9, further comprising:
generating, responsive to detecting the malware, a threat model; and
presenting the threat model in a graphical user interface (GUI).
(Currently Amended) The method of claim 10, wherein the threat model comprises a data flow corresponding to malware data used by the malware.
(Currently Amended) The method of claim 10, wherein presenting the threat model comprises at least one of:
presenting a data flow diagram of a data flow used by the malware; and
presenting an attack surface map corresponding to one or more portions of the server-side web browser targeted by the malware.
(Currently Amended) The method of claim 1, further comprising automatically remediating the server-side web browser by taking an action selected from at least one of:
presenting a list of mitigation recommendations against unauthorized data access,
presenting a change log describing a change in the server-side web browser,
setting a content security policy,
initiating tag control,
applying a compliance requirement to the server-side web browser, and
enabling disabling, pausing, or configuring a security setting.
14-20. (Canceled)
(New) A system for improving client-side cybersecurity, the system comprising:
a server;
a repository in communication with the server and storing:
data,
scan results,
monitoring information,
an access mode for the data, wherein the access mode comprises a permission state for an executable script, function, or program, and
replacement code;
a client-side web browser executable by the server to add the permission state for the executable script, function, or program;
a web service executable by the server;
a server-side web browser executable by the server to generate scan results by executing a scan, wherein:
the scan comprises a behavior pattern that defines a simulated use, by the client-side web browser, of the server-side web browser to access the web service,
executing the scan comprises causing the server-side web browser to access the web service, on behalf of the client-side web browser, according to the behavior pattern,
the scan results comprise the monitoring information, generated by monitoring execution of the scan; and
a server application executable by the server to:
detect, using the scan results, a vulnerability of the data accessed during the simulated use of the server-side web browser, wherein the vulnerability comprises a data access vulnerability of the client-side web browser,
determine, responsive to detecting the vulnerability, the access mode for the data, and
apply, by the server-side web browser, the access mode to the client-side web browser by injecting the replacement code in the client-side web browser, wherein the replacement code is executable by the client-side web browser to add the permission state for the executable script, function, or program.
(New) The method of claim 21, wherein the replacement code is further executable to block access to the data and permit access to the data.
(New) The method of claim 21, wherein the data is provided by the server-side web browser to the web service, is provided by the web service to the server-side web browser, or a combination thereof.
(New) The method of claim 21, wherein the access mode is specific to a script type of the executable script attempting to access the data, and wherein the access mode blocks execution of the executable script.
(New) The method of claim 21, wherein the server-side web browser executes in a monitored environment, and wherein the method further comprises:
determining that the server-side web browser accesses the data using native code of the monitored environment; and
replacing the native code with modified native code comprising functionality to (i) observe an attempt to access the data, and (ii) comply with the access mode when the attempt to access the data is executed.
(New) The method of claim 21, further comprising:
detecting, using the scan results, malware in the data accessed by the server-side web browser.
(New) The method of claim 21, further comprising automatically remediating the server-side web browser by taking an action selected from at least one of:
presenting a list of mitigation recommendations against unauthorized data access,
presenting a change log describing a change in the server-side web browser,
setting a content security policy,
initiating tag control,
applying a compliance requirement to the server-side web browser, and
enabling disabling, pausing, or configuring a security setting.
Herein ends the Examiner’s Amendment to the claims. Examiner’s note: The Examiner has changed the dependencies of claims 22-27 from depending on claim 1 to depending on claim 21.
Response to Arguments
Applicant’s arguments, see Remarks, filed 3/11/2026, with respect to the rejection of claims 1-13 under 35 USC §103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of WO 2021/014208 to Hod et al. provided by the Applicant in the IDS of 4/13/2026.
Response to Amendment
Claims 14-20 have been cancelled.
Claims 1-4, 6, 8, 9, and 11-12 have been amended.
Claims 21-27 have been added.
Claims 1-13 and 21-27 are pending.
Claim Rejections - 35 USC § 112
In light of Applicant’s/Examiner’s Amendment, the previous 35 USC §112(b) rejection of claim 3 has been withdrawn.
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 pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Claims 1-3, 6, 13, 21, 22, and 25-27 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over US PG Pub. No. 2017/0013008 to Carey et al. (hereinafter Carey) in view of WO 2021/014208 to Hod et al. (hereinafter Hod).
As to claims 1 and 21, Carey teaches method for improving client-side cybersecurity, the method comprising:
a. Generating scan results by executing a scan by a server-side web browser, (security assessor central server) (Carey, [0049]) wherein:
i. The scan comprises a behavior pattern that defines a simulated use, by a client-side web browser, of the server-side web browser to access a web service (scan includes simulated techniques, tactics, and practices (TTP) (behavior patterns) using a headless browser that simulates end user device activity from a non-user end device (server-side web browser)) (Carey, [0019, 0049, and 0061]).
ii. Executing the scan comprises causing the server-side web browser to access the web service, on behalf of the client-side web browser, according to the behavior pattern (executing various security threat simulations on the web service) (Carey, [0051]).
iii. The scan results comprise monitoring information generated by monitoring execution of the scan (monitoring results of the scan) (Carey, [0092]-[0093]).
iv. Detecting, using the scan results, a vulnerability of data accessed during the simulated use of the server-side web browser, wherein the vulnerability comprises a data access vulnerability of the client-side web browser (results of executing TTP are gathered and assessed including data access) (Carey, [0019 and 0086]).
Carey as modified does not express an access mode. However, in an analogous art, Hod teaches:
v. Determining, responsive to detecting the vulnerability, an access mode for the data, wherein the access mode comprises a permission state for a script, function, or program executable by the client-side web browser (there are two access modes for code: allow or deny) (Hod, p. 13:25-30).
Therefore, one of ordinary skill in the art would have been motivated to implement the simulated vulnerability testing of websites of Carey with the application of access modes of Hod in order to secure the user from nefarious intent when interacting with the Internet as suggested by Hod (Hod, p. 3:6-11).
Carey as modified further teaches:
vi. Applying, by the server-side web browser, the access mode to the client-side web browser by injecting replacement code in the client-side web browser, wherein the replacement code is executable by the client-side web browser to add the permission state for the script, function, or program (mitigation of detected vulnerabilities includes applying the appropriate access modes to interactions with the client-side browser) (Hod, pp. 13:25-14:2).
As to claims 2 and 22, Carey as modified teaches the replacement code is further executable to block access to the data and permit access to the data (mitigation of detected vulnerabilities includes applying the appropriate access modes to interactions with the client-side browser) (Hod, pp. 13:25-14:2).
As to claims 3 and 23, Carey as modified teaches the data is provided by the server-side web browser to the web service, is provided by the web service to the server-side web browser, or a combination thereof (executing various security threat simulations on the web service) (Carey, [0051]).
As to claims 6 and 25, Carey as modified teaches:
a. Determining that the server-side web browser accesses the data using native code of the monitored environment (Native Client used) (Carey, [0073]). Using a specific code for accessing data is not seen as particularly patentable as the specific code, in general, is available to users.
b. Replacing the native code with modified native code comprising functionality to (i) observe an attempt to access the data, and (ii) comply with the access mode when the attempt to access the data is executed (monitoring results of the scan) (Carey, [0092]).
As to claims 13 and 27, Carey as modified teaches automatically remediating the server-side web browser by taking an action selected from at least one of: presenting a list of mitigation recommendations against unauthorized data access, presenting a change log describing a change in the server web browser, setting a content security policy, initiating tag control, applying a compliance requirement to the server web browser, and enabling disabling, pausing, or configuring a security setting (a plethora of data about the simulation is maintained for further analyses) (Carey, [0081]).
As to claim 26, Carey as modified teaches detecting, using the scan results, malware in the data accessed by the server-side web browser (Carey, [0091]).
Claims 4 and 5 and claim 24 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over US PG Pub. No. 2017/0013008 to Carey et al. (hereinafter Carey) in view of WO 2021/014208 to Hod et al. (hereinafter Hod) as applied to claim 1 and claim 21 respectively above, and further in view of US PG Pub. No. 2013/0145437 to Zaitev.
As to claims 4 and 24, Carey as modified does not expressly mention blocking a script type. However, in an analogous art, Zaitev teaches the access mode is specific to a script type of the script attempting to access the data, and wherein the access mode blocks execution of the script ((blocking execution of a malicious (type) script) (Zaitev, [0032 and 0077]).
Therefore, one of ordinary skill in the art before the effective filing date of the instant application would have been motivated to implement the simulation of attacks of Carey as modified with the blocking execution of malicious scripts of Zaitev in order to protect assets from malware and virus attacks as suggested by Zaitev (Zaitev, [0005]).
As to claim 5, Carey as modified teaches the script type comprises at least one of a first party script, a third party script, an Nth party script, a first party tracker, a relationship between the script and the web service, and combinations thereof (the examples (first-, third-, or Nth-party script) of the script type can be applied to essentially any script) (Carey, [0073]).
Claims 7-12 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over US PG Pub. No. 2017/0013008 to Carey et al. (hereinafter Carey) in view of WO 2021/014208 to Hod et al. (hereinafter Hod) as applied to claim 1 above, and further in view of US PG Pub. No. 2018/0375892 to Ganor.
As to claim 7, Carey as modified teaches using machine learning (machine learning) (Hod, p. 12:19-21).
Carey as modified does not expressly mention determining an asset class of the data. However, in an analogous art, Ganor teaches determining, using a machine learning model, an asset class of the data an asset class of the data (asset types are considered) (Ganor, [0058, 0066, and 0068]).
Therefore, one of ordinary skill in the art before the effective filing date of the instant application would have been motivated to implement the simulation of attacks of Carey as modified with the use of machine learning models of Ganor in order to build a robust security risk management of a system as suggested by Ganor (Ganor, [0002]).
As to claim 8, Carey as modified teaches attempting, by the script, to access the data and determining the access mode using the asset class and a script type of the script attempting to access the data (data type and scripts (malicious executables) determine remediation response including blocking of execution of the script) (Ganor, [0086-0088] and fig. 6B).
As to claim 9, Carey as modified teaches detecting, using the scan results, malware in the data accessed by the server-side web browser (Ganor, [0086-0088] and fig. 6B).
As to claim 10, Carey as modified teaches generating, responsive to detecting the malware, a threat model and presenting the threat model in a graphical user interface (GUI) (results presented on GUI) (Ganor, [0066]).
As to claim 11, Carey as modified teaches the threat model comprises a data flow corresponding to malware data used by the malware (flow diagrams illustrate a part of the vulnerability scanning) (Ganor, [0079]).
As to claim 12, Carey as modified teaches presenting the threat model comprises at least one of: presenting a data flow diagram of a data flow used by the malware and presenting an attack surface map corresponding to one or more portions of the server web browser targeted by the malware (results presented on GUI) (Ganor, [0066]).
Conclusion
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 WILLIAM S POWERS whose telephone number is (571)272-8573. The examiner can normally be reached M-F 7:30-17: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, Jorge L Ortiz-Criado can be reached at (571) 272-7624. 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.
/WILLIAM S POWERS/Primary Examiner, Art Unit 2496
Prosecution Insights