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 .
Response to Amendment
This office action is in response to amendment/reconsideration filed on 06/01/2026, the amendment/reconsideration has been considered. Claims 1-20 are pending for examination as cited below.
Response to Arguments
Applicant’s arguments, see remarks, filed on 06/01/2026, with respect to claim rejection have been fully considered and found not persuasive. In remarks applicant argues that:
I. Response to Applicant’s arguments regarding independent claims 1, 8 and 15
(A) “Injecting an XSS exploit payload…comprising a script that identifies a first URL and accesses a second URL.”
Applicant argues that Ben does not teach or suggest and exploit payload comprising a script that identifies a first URL and accesses a second URL, asserting that Ben only discusses generating a vulnerable URL and do not disclose two distinct URLs.
Examiner respectfully disagree because, Ben teaches:
Generating an exploit (Ben, [0126])
Injecting the exploit into a URL (Ben, [0130])
Communicating the vulnerable URL to a testing framework (Ben, [0134])
Validation via execution of the exploit payload (Ben, [0138-0139])
The “vulnerable URL” created by exploit injection necessarily contains:
The Original URL (the first URL), and
The injected exploit payload, which includes a script designed to execute and communicate with a second URL (e.g., a testing endpoint, validation server, or artifact-producing sink).
Ben teaches that the exploit payload is designed to trigger JavaScript execution (Ben, [0128, 0138]), and such payloads routinely include external communication endpoints. This is consistent with standard XSS exploit structure, which include:
A source URL containing the tainted parameter, and
A target URL contacted by the injected script to validate execution.
Thus, Ben disclosure of generating and injecting and exploit payload that triggers JavaScript execution reasonably suggests a script that identifies one URL (the vulnerable URL) and accesses another (the validation endpoint).
(B) “Sending the request to a web server.”
Applicant argues that Ben [0134] does not teach sending a request to a web server because the paragraph refers to communicating the vulnerable URL to a “testing framework 136.”
Examiner respectfully disagree because Ben teaches:
The testing framework (e.g., Selenium) loads the vulnerable URL [0134].
Loading a URL necessarily involves issuing an HTTP request to a web server hosting the security target [0114].
The testing framework is not itself the web server; however, the act of communicating the vulnerable URL to the testing framework causes the testing framework to send the HTTP request to the web server hosting the target website. This is inherent in the operation of Selenium and other browser-automation framework.
Thus, Ben teaches or at least suggests “sending the request to a web server.”
II. Response to applicant’s arguments regrading two-URL requirement
Applicant asserts that the office action did not map specific elements of Ben to the claimed “first URL” and “second URL.”
Examiner respectfully disagree because,
First URL -the vulnerable URL created by exploit injection [0130-0132]
Second URL -the endpoint contacted when the exploit payload executes, producing an artifact [0138-0139].
Ben teaches that the exploit payload is designed to trigger JavaScript execution and produce an artifact. Such payloads inherently contact a second URL (e.g., a callback endpoint) to validate execution. This is consistent with standard XSS validation techniques and is explicitly contemplated in Ben’s description of “artifact 138” resulting from payload execution.
III. Response to applicant’s arguments regarding depending claims
Applicant argues that depending claims 2-7, 9-14 and 16-20 are allowable because they depend from allegedly allowable independent claims.
Examiner respectfully disagree because the rejections of independent claims 1, 8 and 15 are maintained, the dependent claims remain unpatentable for the same reasons. Additionally, each dependent claim was individually addressed in the office action and remains properly rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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-2, 8-9 and 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bensalim et al. (Pub. No.: US 2023/0177166 A1), hereinafter “Ben” in view of Gupta et al. (Patent No.: US 12335287 B2), hereinafter “Gupta”.
As to claim 1. Ben discloses, a system for detecting cross-site scripting (XSS) vulnerabilities (Ben, fig.1, [0003], improving accuracy of security vulnerability detection by determining a context of a data flow from a target, generating an exploit, and injecting the exploit based upon the context to create a vulnerable Uniform Resource Locator (URL)), the system comprising:
a memory that stores instructions (Ben, fig.1, [0016], The vulnerability engine receives the data flow. With reference to a model 118, the engine stores the data flow as a document 120 within the storage medium.); and
one or more processors coupled to the memory and configured to execute the instructions to perform operations (Ben, fig.6, computer system comprises a processor 602) comprising:
injecting an XSS exploit payload into a request, the XSS exploit payload comprising a script that identifies a first uniform resource locator (URL) and accesses a second URL (Ben, [0018]-[0019], the vulnerability engine generates 125 an exploit 126. The exploit is stored within the storage layer and includes a payload 128, whose execution can reveal the existence of a security vulnerability such as a cross-site scripting attack and the vulnerability engine performs injection 130 of the generated exploit to create a vulnerable URL 132. Ben further describes in [0024], At 208, the exploit is injected into the data flow based upon the context to create a vulnerable URL and [0035], The exploits are then injected into the URL, in a position where it is most likely to result in successful code execution.).
sending the request to a web server (Ben, [0019], The vulnerability engine then communicates 134 the vulnerable URL to a testing framework 136);
based on receiving a request to access the second URL:
determining that an XSS vulnerability exists in the web server at the first URL (Ben, [0020], As part of this testing, the payload of the injected exploit may result an artifact 138 (such as JavaScript execution) whose presence reveals the existence of a security vulnerability (such as to a XSS attack) and [0021], The artifact is received by the vulnerability engine. Based upon receipt of the artifact, the vulnerability engine validates 139 the existence of a security vulnerability 140, and communicates that vulnerability back to the interface (e.g., to alert a user to the security issue). Also see [0035]-0036], validation of security vulnerabilities, generated URLs are tested to see whether they lead to arbitrary JavaScript execution.).
providing a user interface suitable for editing source code for a web application provided by the web server (Ben, fig.1, the vulnerability engine is configured to receive instructions 108 via a user interface 110. Also [0021], communicate the security vulnerability to an interface);
Ben however is silent to disclose explicitly, receiving, via the user interface, a correction for the XSS vulnerability in the source code; and
deploying the correction for the XSS vulnerability.
Gupta discloses a similar concept in the same field of endeavor including, sending the request to a web server (Gupta, col.2, lines 29-37, method may also implement a protection action in response to declaring the cross site scripting attack.); and
deploying the correction for the XSS vulnerability (Gupta, col.2, lines 29-37, method may also implement a protection action in response to declaring the cross site scripting attack. Example protection actions include (i) executing a user indicated, e.g., provided script, (ii) terminating an Internet Protocol (IP) connection, (iii) terminating a web session, (iv) providing a compensating control to a web application firewall, and/or (v) generating an alert of the cross site scripting attack to a user which is displayed to the user, amongst other examples.).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the ordinary skilled in the art to incorporate the teachings of “Gupta” into those of “Ben” to provide a system that detect cross site scripting attacks. Such a system captures a web request and captures a response to the captured web request. In turn, it is determined if one or more elements associated with the captured web request and one or more elements of the captured response, in combination, cause a malicious action. A cross site scripting attack is then declared in response to determining the one or more elements associated with the captured web request and the one or more elements of the captured response, in combination, cause a malicious action.
As to claim 2. The combined system of Ben and Gupta discloses the invention as in parent claims above including, wherein the injecting of the XSS payload into the request comprises replacing a parameter value in the request with the script (Ben, [0072], Using the calculated indices, the string “abcd” is identified as replaceable. It is therefore replaced with the generated exploit in a next step, allowing a precise injection into the query string value.).
Claims 8-9 and 15-16 are rejected for same rationale as applied to claims 1-2 above.
Claim(s) 3-6, 10-13 and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Ben and Gupta” as applied above in view of Caceres et al. (Pub. No.: US 2022/0014561 A1), hereinafter “Cac”.
As to claim 3. The combined system of Ben and Gupta discloses the invention as in parent claims above including, generating a list of URLs for the web server using a web crawler (Ben, [0015], a crawler 112 is configured to access a security target 114. The target produces a data flow 116 that is communicated back to the vulnerability engine);
wherein the sending of the request to the web server is part of sending a plurality of requests to the web server based on the list of URLs (Ben, fig.3, [0037]-[0039], illustrates an example architecture for a system 300 configured for detection of potential client-side XSS vulnerabilities. Ben further teaches, the crawler 301 visits specific web pages 302 to collect potentially insecure data flows using dynamic taint tracking implemented in the taint-aware browser 304.).
Ben and Gupta however are silent to disclose explicitly, generating a list of URLs for the web server using a web crawler.
Cac discloses a similar concept in the same field of endeavor, generating a list of URLs for the web server using a web crawler (Cac, [0022], herein a web crawler: retrieves a plurality of domains from a database, the plurality of domains being associated with the organization);
wherein the sending of the request to the web server is part of sending a plurality of requests to the web server based on the list of URLs (Cac, [0022], requests a web page associated with at least one of the retrieved domains; receives a response to the request from a web server; provides input to an interactive element of the web page; receives a result from the web server, the result being based on the provided input; indexes the result; and store the indexed results from the plurality of web crawlers).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the ordinary skilled in the art to incorporate the teachings of “Cac” into those of “Ben and Gupta” to provide a method for automated Internet-scale vulnerability scanning and enhanced security profiling. The system utilizes a scheduler that directs web crawlers to scan domains retrieved from a database, interact with the contents of any retrieved web pages using fuzz testing, index and store the results of the scan, and provide the indexed results via an API for inclusion in cybersecurity scoring.
As to claim 4. The combined system of Ben, Gupta and Cac discloses the invention as in parent claims above including, periodically accessing the web server based on the list of URLs (Cac, [0072]).
As to claim 5. The combined system of Ben, Gupta and Cac discloses the invention as in parent claims above including, wherein the sending of the request to the web server comprises sending a hypertext transport protocol (HTTP) request to the web server (Cac, [0075], Fuzz URL’s).
As to claim 6. The combined system of Ben, Guptan and Cac discloses the invention as in parent claims above including, wherein the sending of the request to the web server comprises sending a hypertext transport protocol secure (HTTPS) request to the web server (Cac, [0075], Fuzz URL’s. Additionally, it is implicit that given the topic or cybersecurity and secure access via HTTPS goes hand in hand.).
Claims 10 and 17 are rejected for same rationale as applied to claim 3 above.
Claims 11 and 18 are rejected for same rationale as applied to claim 4 above.
Claims 12-13 are rejected for same rationale as applied to claim 5-6 above.
Claims 20 is rejected for same rationale as applied to claim 5 and 12 above.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Ben” and “Gupta” as applied above in view of Gareth et al. “XSS in hidden input fields” publish on Nov 6, 2015, hereinafter “Gareth”.
As to claim 7. The combined system of Ben and Gupta discloses the invention as in parent claims above. Ben and Gupta however are silent to disclose explicitly, wherein the injecting of the XSS payload into the request comprises including the second URL in a hidden field.
Gareth however discloses a similar concept in the same field of endeavor, wherein the injecting of the XSS payload into the request comprises including the second URL in a hidden field (Gareth, At PortSwigger, we regularly run pre-release builds of Burp Suite against an internal testbed of popular webapplications to make sure it's behaving properly. Whilst doing this recently, Liam found a Cross-Site Scripting
(XSS) vulnerability in [REDACTED], inside a hidden input element:
<input type="hidden" name="redacted" value="default" injection="xss"/>
XSS in hidden inputs is frequently very difficult to exploit because typical JavaScript events like onmouseover and onfocus can't be triggered due to the element being invisible.).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the ordinary skilled in the art to incorporate the teachings of “Gareth” into those of “Ben and Gupta” to provide a protection against vulnerability and exploitation in world wide web environment from such attacks by malicious third parties. XSS in hidden inputs is frequently very difficult to exploit because typical JavaScript events are invisible to the third-party attackers.
Claim 14 are rejected for same rationale as applied to claim 7 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see the attached PTO-892.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAUQIR HUSSAIN whose telephone number is (571)270-1247. The examiner can normally be reached M-F 7:00 - 8:00 with IFP.
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, SRIVASTAVA VIVEK can be reached at 571 272-7304. 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.
/Tauqir Hussain/Primary Examiner, Art Unit 2449
Prosecution Insights