DETAILED ACTION
This Office Action is in response to Applicants’ Application filed on March 15, 2024. Claims 1-20 are pending and presented for examination.
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 .
Claim Objections
Claims 1, 8 and 15 are objected to because of the following informalities: the acronym for OWASP and WAF must be spelled out before use. Appropriate correction is required.
Claim 12 is objected to because of the following informalities: the acronym for SQL must be spelled out before use. Appropriate correction is required.
Claim 20 is objected to because of the following informalities: the acronym for MODSEC must be spelled out before use. Appropriate correction is required
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claims 1, 8 and 15 recite “suspicious traffic to identify that traffic maybe allowed to reach the application” and “rejecting, at the one or more second filters, the traffic that should be prevented from reaching the application and passing at least portion of the traffic that is not rejected to the application”. The phrases “may be” and “should be” render the claims indefinite because it is unclear whether the limitations following the phrase is possibly permitted but there is a degree of uncertainty or doubt about it. It also unclear if the traffic that is identified is a part of the suspicious or the incoming traffic. Dependent claims 2-7, 9-14 and 16-20 are also rejected under 35 U.S.C 112(b) or 35 U.S.S 112 (pre-AIA ), second paragraph, as being indefinite based on their dependency of the rejected claims 1, 8 and 15, respectively.
Claim 1 recites the limitation "the traffic" in line 15. There is insufficient antecedent basis for this limitation in the claim.
Claim 1 recites the limitation "the traffic" in 16. There is insufficient antecedent basis for this limitation in the claim.
Claim 6 recites the limitation "the violating requests" in line 4. There is insufficient antecedent basis for this limitation in the claim.
Claim 8 recites the limitation "the traffic" in line 17. There is insufficient antecedent basis for this limitation in the claim.
Claim 8 recites the limitation "the traffic" in line 18. There is insufficient antecedent basis for this limitation in the claim.
Claim 15 recites the limitation "the traffic" in line 19. There is insufficient antecedent basis for this limitation in the claim.
Claim 15 recites the limitation "the traffic" in line 20. There is insufficient antecedent basis for this limitation in the claim.
Double Patenting
The nonstatutory 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 nonstatutory 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 nonstatutory 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 nonstatutory 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 eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/329,307 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-20 of the present application are similar in scope and thus encompass the subject matter.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Application 18/606,976
A method of filtering traffic for web applications, the method comprising:
receiving incoming traffic from one or more client devices, wherein the incoming traffic comprises a plurality of requests for an application hosted on a server, and the incoming traffic is received by a web application firewall between the one or more client devices and the application;
processing the incoming traffic using a first filter in the web application firewall, wherein the first filter is configured to apply rules that identify suspicious traffic in the incoming traffic;
passing the suspicious traffic from the first filter to one or more second filters in the web application firewall, and passing at least a portion of the incoming traffic that is not identified as suspicious traffic to the application;
processing the suspicious traffic using the one or more second filters, wherein the one or more second filters are configured to perform a OWASP compliant ruleset based on WAF on the suspicious traffic to identify traffic that may be allowed to reach the application; and
rejecting, at the one or more second filters, the traffic that should be prevented from reaching the application and passing at least a portion of the traffic that is not rejected to the application.
2. The method of claim 1, wherein the first filter and the second filter are integrated with a load balancer, and the first filter and the second filter are configured by the load balancer, wherein the load balancer configures a number of the second filters in the one or more second filters.
3. The method of claim 2, wherein the first filter, the second filter, and the load balancer are integrated into a single software process, and the first filter provides the second filter with the suspicious traffic within the software process.
4. The method of claim 1, wherein the first filter is configured to allow false positives in the suspicious traffic.
5. The method of claim 1, wherein the first filter is configured to apply the rules to identify suspicious traffic in dynamic content and static content.
6. The method of claim 1, wherein processing the incoming traffic using the first filter comprises identifying requests in the incoming traffic comprising payloads that are above a predetermined size threshold and rejecting the identified requests as rejected traffic without sending the violating requests to the second filter.
7. The method of claim 6, wherein the predetermined size threshold is dynamically adjusted based on a workload of the second filter at runtime.
8. One or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
receiving incoming traffic from one or more client devices, wherein the incoming traffic comprises a plurality of requests for an application hosted on a server, and the incoming traffic is received by a web application firewall between the one or more client devices and the application;
processing the incoming traffic using a first filter in the web application firewall, wherein the first filter is configured to apply rules that identify suspicious traffic in the incoming traffic;
passing the suspicious traffic from the first filter to one or more second filters in the web application firewall, and passing at least a portion of the incoming traffic that is not identified as suspicious traffic to the application;
processing the suspicious traffic using the one or more second filters, wherein the one or more second filters are configured to perform a OWASP compliant ruleset based on the suspicious traffic to identify traffic that may be allowed to reach the application; and
rejecting, at the one or more second filters, the traffic that should be prevented from reaching the application and passing at least a portion of the traffic that is not rejected to the application.
9. The one or more non-transitory computer-readable media of claim 8, wherein the first filter is configured to pass a predetermined percentage of the incoming traffic as suspicious traffic to the second filter.
10. The one or more non-transitory computer-readable media of claim 9, wherein the predetermined percentage of suspicious traffic is less than or about 10% of the incoming traffic.
11. The one or more non-transitory computer-readable media of claim 9, wherein the predetermined percentage of suspicious traffic is dynamically adjusted based on a workload of the second filter at runtime.
12. The one or more non-transitory computer-readable media of claim 8, wherein the rules applied by the first filter comprise regular expressions that are used to search the incoming traffic for SQL injections and cross-site scripting attacks.
13. The one or more non-transitory computer-readable media of claim 8, wherein the rules applied by the first filter comprise a pattern, a text description, a matching zone that identifies a portion of an incoming request to which the pattern is applied, and a score.
14. The one or more non-transitory computer-readable media of claim 8, wherein each of the rules applied by the first filter comprises a score, and scores for each rule violation of a request are aggregated and compared to one or more thresholds to determine whether the request is identified as suspicious traffic, allowed traffic, or rejected traffic.
15. A load balancer and firewall comprising: one or more processors; and one or more memory devices comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
receiving incoming traffic from one or more client devices, wherein the incoming traffic comprises a plurality of requests for an application hosted on a server, and the incoming traffic is received by a web application firewall between the one or more client devices and the application;
processing the incoming traffic using a first filter in the web application firewall, wherein the first filter is configured to apply rules that identify suspicious traffic in the incoming traffic;
passing the suspicious traffic from the first filter to one or more second filters in the web application firewall, and passing at least a portion of the incoming traffic that is not identified as suspicious traffic to the application;
processing the suspicious traffic using the one or more second filters, wherein the one or more second filters are configured to perform a OWASP compliant ruleset based on the suspicious traffic to identify traffic that may be allowed to reach the application; and
rejecting, at the one or more second filters, the traffic that should be prevented from reaching the application and passing at least a portion of the traffic that is not rejected to the application.
16. The load balancer and firewall of claim 15, wherein the rules applied by the first filter comprise a plurality of patterns comprising between two and five characters, and combined scores for violations of the plurality of patterns indicate suspicious traffic.
17. The load balancer and firewall of claim 15, wherein the one or more second filters comprises a single filter.
18. The load balancer and firewall of claim 15, wherein the one or more second filters comprises a plurality of additional filters.
19. The load balancer and firewall of claim 15, wherein the first filter is configured to pass allowed traffic to the application, to pass suspicious traffic to the one or more second filters, and to reject traffic that is not received by the one or more second filters or the application.
20. The load balancer and firewall of claim 15, wherein the OWASP compliant ruleset based WAF comprises a MODSEC process.
Co-Pending Application 18/329,307
A method of filtering traffic for web applications, the method comprising:
receiving incoming traffic from one or more client devices, wherein the incoming traffic comprises a plurality of requests for an application hosted on a server, and the incoming traffic is received by a web application firewall between the one or more client devices and the application;
processing the incoming traffic using a first filter in the web application firewall, wherein the first filter is configured to apply rules that identify suspicious traffic in the incoming traffic;
passing the suspicious traffic from the first filter to one or more second filters in the web application firewall, and passing at least a portion of the incoming traffic that is not identified as suspicious traffic to the application;
processing the suspicious traffic using the one or more second filters, wherein the one or more second filters are configured to perform a MODSEC process on the suspicious traffic to identify traffic that may be allowed to reach the application; and
rejecting, at the one or more second filters, the traffic that should be prevented from reaching the application and passing at least a portion of the traffic that is not rejected to the application.
2. The method of claim 1, wherein the first filter and the second filter are integrated with a load balancer, and the first filter and the second filter are configured by the load balancer, wherein the load balancer configures a number of the second filters in the one or more second filters.
3. The method of claim 2, wherein the first filter, the second filter, and the load balancer are integrated into a single software process, and the first filter provides the second filter with the suspicious traffic within the software process.
4. The method of claim 1, wherein the first filter is configured to allow false positives in the suspicious traffic.
5. The method of claim 1, wherein the first filter is configured to apply the rules to identify suspicious traffic in dynamic content and static content.
6. The method of claim 1, wherein processing the incoming traffic using the first filter comprises identifying large requests in the incoming traffic comprising payloads that are above a predetermined size threshold and rejecting the large requests as rejected traffic without sending the large requests to the second filter.
7. The method of claim 6, wherein the predetermined size threshold is dynamically adjusted based on a workload of the second filter at runtime.
8. One or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
receiving incoming traffic from one or more client devices, wherein the incoming traffic comprises a plurality of requests for an application hosted on a server, and the incoming traffic is received by a web application firewall between the one or more client devices and the application;
processing the incoming traffic using a first filter in the web application firewall, wherein the first filter is configured to apply rules that identify suspicious traffic in the incoming traffic;
passing the suspicious traffic from the first filter to one or more second filters in the web application firewall, and passing at least a portion of the incoming traffic that is not identified as suspicious traffic to the application;
processing the suspicious traffic using the one or more second filters, wherein the one or more second filters are configured to perform a MODSEC process on the suspicious traffic to identify traffic that may be allowed to reach the application; and
rejecting, at the one or more second filters, the traffic that should be prevented from reaching the application and passing at least a portion of the traffic that is not rejected to the application.
9. The one or more non-transitory computer-readable media of claim 8, wherein the first filter is configured to pass a predetermined percentage of the incoming traffic as suspicious traffic to the second filter.
10. The one or more non-transitory computer-readable media of claim 9, wherein the predetermined percentage is less than or about 10% of the incoming traffic.
11. The one or more non-transitory computer-readable media of claim 9, wherein the predetermined percentage is dynamically adjusted based on a workload of the second filter at runtime.
12. The one or more non-transitory computer-readable media of claim 8, wherein the rules applied by the first filter comprise regular expressions that are used to search the incoming traffic for SQL injections and cross-site scripting attacks.
13. The one or more non-transitory computer-readable media of claim 8, wherein the rules applied by the first filter comprise a pattern, a text description, a matching zone that identifies a portion of an incoming request to which the pattern is applied, and a score.
14. The one or more non-transitory computer-readable media of claim 8, wherein each of the rules applied by the first filter comprises a score, and scores for each rule violation of a request are aggregated and compared to one or more thresholds to determine whether the request is identified as suspicious traffic, allowed traffic, or rejected traffic.
15. A load balancer and firewall comprising: one or more processors; and one or more memory devices comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
receiving incoming traffic from one or more client devices, wherein the incoming traffic comprises a plurality of requests for an application hosted on a server, and the incoming traffic is received by a web application firewall between the one or more client devices and the application;
processing the incoming traffic using a first filter in the web application firewall, wherein the first filter is configured to apply rules that identify suspicious traffic in the incoming traffic;
passing the suspicious traffic from the first filter to one or more second filters in the web application firewall, and passing at least a portion of the incoming traffic that is not identified as suspicious traffic to the application;
processing the suspicious traffic using the one or more second filters, wherein the one or more second filters are configured to perform a MODSEC process on the suspicious traffic to identify traffic that may be allowed to reach the application; and
rejecting, at the one or more second filters, the traffic that should be prevented from reaching the application and passing at least a portion of the traffic that is not rejected to the application.
16. The load balancer and firewall of claim 15, wherein the rules applied by the first filter comprise a plurality of patterns comprising between two and five characters, and combined scores for violations of the plurality of patterns indicate suspicious traffic.
17. The load balancer and firewall of claim 15, wherein the one or more second filters comprises a single filter.
18. The load balancer and firewall of claim 15, wherein the one or more second filters comprises a plurality of additional filters.
19. The load balancer and firewall of claim 15, wherein the first filter is configured to pass allowed traffic to the application, to pass suspicious traffic to the one or more second filters, and to reject traffic that is not received by the one or more second filters or the application.
20. The load balancer and firewall of claim 15, wherein a machine-learning algorithm is trained to adjust the rules applied by the first filter based on logs of the application.
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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cantrell et al (hereinafter, “Cantrell”, U.S. Pub. No. 2004/0030776) in view of Qui et al (hereinafter, “Qui”, U.S. Pub. No. 2022/0279013).
As per claims 1, 8 and 15, Cantrell discloses a method, one or more non-transitory computer-readable media and a load balancer and firewall of filtering traffic for web applications, the method comprising:
receiving incoming traffic from one or more client devices, wherein the incoming traffic comprises a plurality of requests for an application hosted on a server, and the incoming traffic is received by a web application firewall between the one or more client devices and the application (paragraph 0017 discloses receiving packet traffic by a firewall);
processing the incoming traffic using a first filter in the web application firewall, wherein the first filter is configured to apply rules that identify suspicious traffic in the incoming traffic (paragraphs 0017, 0019 and 0020 discloses examining the packet traffic and determining if the packet traffic is suspicious);
passing the suspicious traffic from the first filter to one or more second filters in the web application firewall, and passing at least a portion of the incoming traffic that is not identified as suspicious traffic to the application (paragraphs 0017, 0019 and 0020 discloses sending the suspicious traffic to a first filter to a second filter that is not suspicious traffic);
processing the suspicious traffic using the one or more second filters, to identify traffic that may be allowed to reach the application (paragraphs 0017, 0019 and 0020 discloses sending the suspicious traffic to a first filter to a second filter that is not suspicious traffic); and
rejecting, at the one or more second filters, the traffic that should be prevented from reaching the application and passing at least a portion of the traffic that is not rejected to the application (paragraphs 0017 and 0019 discloses rejecting the received packet traffic at the second filter and passing the traffic through the second filter that is not rejected).
However, Cantrell does not explicitly disclose:
wherein the one or more second filters are configured to perform a OWASP compliant ruleset based on WAF on the suspicious traffic.
Qui discloses a flexible deterministic finite automata tokenizer for AI-based malicious traffic detection comprising:
wherein the one or more second filters are configured to perform a OWASP compliant ruleset based on WAF on the suspicious traffic (paragraph 0036).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of filing to modify Cantrell by incorporating or implementing performing a OWASP rules for the purpose of filtering requests according to defined rules to provide protection against vulnerabilities.
As per claim 2, Cantrell discloses:
wherein the first filter and the second filter are integrated with a load balancer, and the first filter and the second filter are configured by the load balancer, wherein the load balancer configures a number of the second filters in the one or more second filters (paragraphs 0026 and 0027).
As per claim 3, Cantrell discloses:
wherein the first filter, the second filter, and the load balancer are integrated into a single software process, and the first filter provides the second filter with the suspicious traffic within the software process (paragraphs 0026 and 0027).
As per claim 4, Cantrell discloses:
wherein the first filter is configured to allow false positives in the suspicious traffic (paragraphs 0019 and 0022).
As per claim 5, Cantrell discloses the invention substantially as claims discussed above.
However, Cantrell does not explicitly disclose:
wherein the first filter is configured to apply the rules to identify suspicious traffic in dynamic content and static content.
Qui discloses a flexible deterministic finite automata tokenizer for AI-based malicious traffic detection comprising:
wherein the first filter is configured to apply the rules to identify suspicious traffic in dynamic content and static content (i.e. HTML file) (paragraph 0087).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of filing to modify Cantrell by incorporating or implementing performing a OWASP rules for the purpose of identifying suspicious traffic in an HTML file in order to provide protection against vulnerabilities.
As per claim 6, Cantrell discloses:
wherein processing the incoming traffic using the first filter comprises identifying requests in the incoming traffic comprising payloads that are above a predetermined size threshold and rejecting the identified requests as rejected traffic without sending the violating requests to the second filter (paragraphs 0022 and 0050).
As per claim 7, Cantrell discloses:
wherein the predetermined size threshold is dynamically adjusted based on a workload of the second filter at runtime (paragraphs 0027 and 0028).
As per claim 9, Cantrell discloses:
wherein the first filter is configured to pass a predetermined percentage of the incoming traffic as suspicious traffic to the second filter (paragraph 0034).
As per claim 10, Cantrell discloses:
wherein the predetermined percentage of suspicious traffic is less than or about 10% of the incoming traffic (paragraph 0034).
As per claim 11, Cantrell discloses:
wherein the predetermined percentage of suspicious traffic is dynamically adjusted based on a workload of the second filter at runtime (paragraph 0034).
As per claim 12, Cantrell discloses the invention substantially as claims discussed above.
However, Cantrell does not explicitly disclose:
wherein the rules applied by the first filter comprise regular expressions that are used to search the incoming traffic for SQL injections and cross-site scripting attacks.
Qui discloses a flexible deterministic finite automata tokenizer for AI-based malicious traffic detection comprising:
wherein the rules applied by the first filter comprise regular expressions that are used to search the incoming traffic for SQL injections and cross-site scripting attacks (paragraphs 0031 and 0032).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of filing to modify Cantrell by incorporating or implementing performing a OWASP rules for the purpose of identifying SQL injection and Cross-site Script attacks in order to provide protection against vulnerabilities.
As per claim 13, Cantrell discloses:
wherein the rules applied by the first filter comprise a pattern, a text description, a matching zone that identifies a portion of an incoming request to which the pattern is applied, and a score (paragraph 0032).
As per claim 14, Cantrell discloses:
wherein each of the rules applied by the first filter comprises a score, and scores for each rule violation of a request are aggregated and compared to one or more thresholds to determine whether the request is identified as suspicious traffic, allowed traffic, or rejected traffic (paragraphs 0027 and 0028).
As per claim 16, Cantrell discloses:
wherein the rules applied by the first filter comprise a plurality of patterns comprising between two and five characters, and combined scores for violations of the plurality of patterns indicate suspicious traffic (paragraphs 0032).
As per claim 17, Cantrell discloses:
wherein the one or more second filters comprise a single filter (paragraphs 0017 and 0038).
As per claim 18, Cantrell discloses:
wherein the one or more second filters comprise a plurality of additional filters (paragraphs 0017 and 0038).
As per claim 19, Cantrell discloses:
wherein the first filter is configured to pass allowed traffic to the application, to pass suspicious traffic to the one or more second filters, and to reject traffic that is not received by the one or more second filters or the application (paragraphs 0017 and 0019).
As per claim 20, Cantrell discloses the invention substantially as claims discussed above.
However, Cantrell does not explicitly disclose:
wherein the OWASP compliant ruleset based WAF comprises a MODSEC process (paragraph 0036).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of filing to modify Cantrell by incorporating or implementing performing a OWASP rules for the purpose of filtering requests according to defined rules to provide protection against vulnerabilities.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LASHONDA T JACOBS-BURTON whose telephone number is (571)272-4004. The examiner can normally be reached M-F 8:30 am - 5:00 pm.
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, Ario Etienne can be reached at 571-272-4001. 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.
/LASHONDA JACOBS-BURTON/Primary Examiner, Art Unit 2457
ljb
September 18, 2025