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 .
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 5/11/2026 have been fully considered, and are partially persuasive. While the amended claim language overcomes the previously presented grounds of rejection, it also introduces new issues regarding written description support and definiteness and clarity when evaluating the claims for compliance under 35 USC 112. Responsive to the amended language, and after further search and consideration, new grounds of rejection are responsively presented below.
Specification
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter for the reasons given below in the 35 USC 112 written description rejection. The Examiner notes that the entirety of the specification was reviewed when evaluating written description support, including paragraphs [31-39] (referenced by Applicant on page 7 of their 5/11/2026 response).
See 37 CFR 1.75(d)(1) and MPEP § 608.01(o).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 and 7 – 25 are rejected under 35 U.S.C. 112, first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention. Regarding claim 1, said claim has been amended to recite, at the conclusion of page 2 through line 2 of page 3, a: “device without an Internet Protocol (IP) address configured on a proxy side of the transparent DNS proxy”.
The specification lacks written description support for this language. For example, there is no discussion of what may correspond to a “proxy side” of a “proxy”. Continuing on page 2, claim 1 has been amended to recite: “a DNS query corresponding to the DNS resolver on behalf of the client”.
The specification lacks written description support for this language. For example, there is no discussion of how a DNS query can be “corresponding to” a “DNS resolver”.
Next on page 2, claim 1 has been amended to recite: “wherein the DNS resolver receives the UD [sic] DNS query without supporting DNS over TCP for the TCP connection established between the client and the transparent DNS proxy”.
The specification lacks written description support for this language. [36] of Applicant’s specification discusses how a “real DNS server no need to support DNS over TCP”, but the disclosed “real DNS server” discusses in [36] does not correspond to the claim language noted above. Regarding claims 7 and 8, each of said claim recites language analogous to the language noted above appearing in claim 1, and thus suffers from issues corresponding to those addressed above.
Regarding claim 9, said claim has been amended to recite a “DNS proxy” that is “deployed inline between the client and the DNS resolver”. There is no written description support for such an “inline” deployment. Regarding claim 10, said claim has been amended to recite a “without requiring IP-layer addressing of the transparent DNS proxy by the client”. There is no written description support for the absence of a requirement for “IP-layer addressing of the transparent DNS proxy by the client”. Regarding claims 11 and 12, each of said claims depends on claim 1 and fails to clarify the issues noted above.
Regarding claim 13, said claim has been amended to recite where a “client is unaware of existence of the transparent DNS proxy”. There is no written description support for any particular device or endpoint (such as the claimed client) being “unaware” of any particular item.
Regarding claim 14, said claim has been amended to recite where a “DNS resolver is unaware that the TCP connection was established”. There is no written description support for any particular device or endpoint being “unaware” of any particular step or action (such as the claimed TCP connection establishment).
Regarding claim 15, said claim has been amended to recite “determining whether the client is capable”. There is no written description support for client capability determination.
Regarding claim 16, said claim has been amended to recite “failing to receive . . . within a timeout period causes authentication of the client to fail”. There is no written description support for this language. While [4] and [33] of the specification utilize the word “fail”, neither does so in the context utilized by claim 16 (i.e., failing to receive a TCP SYN frame, and causing the claimed “authentication failure”.
Regarding claim 17, said claim has been amended to recite “authenticates a client as a real client rather than a scripted attack source”. There is no written description support for this language. For example, while [49] of the specification notes “malicious scripts”, there is no discussion of a “scripted attack source” as claimed, and no discussion of identification of a client as “real client” in contrast with such a “scripted attack source” as claimed.
Regarding claim 18, said claim has been amended to recite “a TCP three-way handshake”. There is no written description support for this language.
Regarding claim 19, said claim has been amended to recite use of various TCP frames “to complete the TCP connection”. There is no written description support for this language, and no discussion with regards to what construes a “complete” TCP connection.
Regarding claim 20, said claim depends on claim 1 and fails to clarify the issues noted above.
Regarding claim 21, said claim has been amended to recite “generating the UDP DNS query to the DNS resolver”. There is no written description support for this language, and no discussion regarding how a “query” can be generated “to” an item, endpoint, device, etc.
Regarding claim 22, said claim depends on claim 1 and fails to clarify the issues noted above.
Regarding claim 23, said claim has been amended to recite “encapsulating DNS answer information”. There is no written description support for this language, and no mention whatsoever of any “encapsulating” operations.
Regarding claims 24 - 25, said claims depends on claim 1 and fails to clarify the issues noted above.
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 and 7 – 25 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.
Regarding claim 1, said claim has been amended to recite a “proxy side . . . of the proxy”. It is unclear and indefinite how a proxy can have a “proxy side”. Further regarding claim 1, said claim has been amended to recite “receiving from the client. . . a DNS query corresponding to the DNS resolver on behalf of the client”. It is unclear and indefinite how a query can be both “from the client” and be received “on behalf of the client”; these two requirements appear to conflict with each other. In addition, it is unclear and indefinite how such a query can be “corresponding to the DNS resolver”; i.e., the scope of a query “corresponding” to a resolver and the relationship implied is unclear and indefinite.
Claim 1 additionally recites “responsive to the successful TCP connection”, reception of a DNS query over the TCP connection, but continues to recite “without supporting DNS over TCP”. It is unclear how the claimed TCP connection can be established and utilized in the manner claimed while also including the limitation that TCP is not supported. Note that just after the lack of TCP support is claimed, a TCP connection between the client and DNS proxy is again recited in the claim.
Regarding claims 7 and 8, each of said claim recites language analogous to the language noted above appearing in claim 1, and thus suffers from issues corresponding to those addressed above.
Regarding claim 9, said claim depends on claim 1 and fails to clarify the issues noted above. Regarding claim 10, said claim recites “without requiring IP-layer addressing of the transparent DNS proxy by the client”. It is unclear how “IP-layer addressing” may be considered “required” (or not required).
Regarding claims 11 - 15, said claims depend on claim 1 and fails to clarify the issues noted above.
Regarding claim 16, said claim recites “wherein failing to receive the TCP synchronize frame from the client. . .”. However, parent claim 1 specifically requires being “responsive to the client sending back a TCP synchronize frame . . .”. Thus the “failing to receive” specified by claim 16 directly conflicts with a requirement of its parent claim, resulting in an unclear and indefinite recitation.
Regarding claim 17, said claim recites “authenticates the client as a real client”. Claim 17 and parent claim 1 each reference a “client”, but now also recite the potential that this “client” is not “real”. It is unclear how the client required by claims 1 and 17 can exist but not be considered “real”. While claim 17 does conclude with the “rather than a scripted attack source” language, a “scripted attack source” appears to be within the broadest reasonable interpretation of a type of client (and thus a “real” client), and thus this concluding recitation fails to clarify the issues with the “real” client language.
Regarding claims 18 - 20, said claims depend on claim 1 and fails to clarify the issues noted above.
Regarding claim 21, said claim recites “generating the UDP DNS query to the DNS resolver”. It is unclear how a query can be generated “to” any item or endpoint.
Regarding claim 22, said claim recites reception of “the UDP DNS query as if the transparent DNS proxy had not intercepted the UDP DNS query”. It is unclear what scope is intended for the “as if the transparent DNS proxy had not intercepted” language. The lack of written description support for this language (noted in the rejections presented above) exacerbates the clarity issues with this language.
Regarding claim 23, said claim recites “encapsulating DNS answer information”. There is no antecedent basis for “DNS answer information”. It is unclear how “DNS answer information” that has not been introduced to the claim can also be said to be “encapsulated”.
Regarding claims 24 - 25, said claims depend on claim 1 and fails to clarify the issues noted above.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 7 – 15, 18 – 22, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Pazi (US-20030070096-A1) in view of Gauvin (US-7735116-B1) and Dillon (US-20040073707-A1).
Regarding claim 1, Pazi shows a computer-implemented method in a transparent domain name system (DNS) proxy ([63] discussing DNS request interception) on a data communication network, for protecting against ([18,30,63] discussing a “guard device”) distributed denial of service (DDOS) attacks on a DNS resolver from a client without notification to the DNS resolver or the client, the method comprising: receiving a user datagram protocol (UDP) DNS query from a client ([64] discussing support for passing packets absent any notifications; also note the previously recited behavior in the preamble is considered anticipated via showing the steps positively recited in the body of the claim) , the method comprising: receiving a user datagram protocol (UDP) DNS query from a client ([32,114]); challenging the client by sending back a DNS response with a truncated (TC) bit set to 1 ([115]);
responsive to the client sending back a TCP synchronize (SYN) frame ([20,32,115-116]), attempting to establish a transmission control protocol (TCP) connection with the client from the transparent DNS proxy ([115-116]); responsive to a successful TCP connection ([115], see “the client initiates a TCP three-way handshake”), receiving from the client over the TCP connection ([118] see “a TCP connection is established” and the client can “resend its original DNS request over the TCP connection”), a DNS query corresponding to the DNS resolver on behalf of the client, wherein the DNS resolver receives the UDP DNS query ([118] where the guard device receives the client request an then “the guard device submits a DNS request to DNS server 22, asking for the information requested by the client” which may use UDP); responsive to receiving a DNS response from the DNS resolver, converting the UDP DNS response to a TCP response forwarded to the client ([15,32,118], where conversion is implicit given the existing TCP connection with the client and both the traditional use of UDP discussed in communication with the DNS sever and the explicit support for use of UDP in the DNS exchange noted in the cited paragraphs, also as noted in [118], “the guard device returns an appropriate DNS response to the client over the existing TCP connection”); and closing the TCP connection ([118]; “the TCP connection may then be closed”) with the client (as [118] notes the TCP connection “is established between the client and the guard device”). Pazi does not show: wherein the DNS proxy is implemented as a proxy that is deployed as a layer-2 device without an Internet Protocol (IP) address configured on a proxy side of the transparent DNS proxy. Gauvin shows wherein the DNS proxy is implemented as a proxy that is deployed as a layer-2 device without an Internet Protocol (IP) address configured on a proxy side of the transparent DNS proxy (col. 11 lines 1 – 15 and lines 45 – 60; note that if there is no IP address configured then there is implicitly no address configured on any particular “side” of the proxy).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the proxy implementation of Pazi with the layer-2 implementation of Gauvin in order to simplify the resultant disclosure by avoiding unrequired steps such as assignment of unutilized or otherwise unrequired addresses.
The above combination does not show: without supporting DNS over TCP for the TCP connection established between the client and the transparent DNS proxy. Dillon shows without supporting DNS over TCP for the TCP connection established between the client and the transparent DNS proxy ([78,136]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the connection and address distribution logic of the above combination with Dillon’s supported protocols and thus avoid TCP support in order to simplify the operation of the resultant disclosure by avoiding support for unnecessary or unrequired protocols.
Regarding claims 7 and 8, the limitations of each of said claims is addressed in the rejection of claim 1. Regarding claim 9, the above combination further shows wherein the transparent DNS proxy is deployed inline between the client and the DNS resolver (Fig. 1 showing guarid 28 between clients 24 and DNS server 22).
Regarding claim 10, the above combination further shows wherein the transparent DNS proxy (Pazi, [115]) operates as a layer-2 network appliance that forwards traffic without requiring IP-layer addressing of the transparent DNS proxy by the client (Gauvin, col. 11 lines 24-58).
Regarding claim 11, the above combination further shows wherein the transparent DNS proxy is included in a DDOS mitigation network appliance (Pazi, [63,114-116]).
Regarding claim 12, the above combination further shows wherein the transparent DNS proxy acts as a TCP proxy (Pazi, [115]) representing the DNS resolver to the client during establishment of the TCP connection (Pazi, [20,32,115-118]).
Regarding claim 13, the above combination further shows wherein the client is unaware of existence of the transparent DNS proxy during the TCP connection (Pazi, [115]).
Regarding claim 14, the above combination further shows wherein the DNS resolver is unaware that the TCP connection was established between the client and the transparent DNS proxy (Pazi, 115,118]).
Regarding claim 15, the above combination further shows wherein challenging the client comprises determining whether the client is capable of transferring a DNS query process from UDP to TCP in response to the DNS response with the truncated bit set to 1 (Pazi, [115]).
Regarding claim 18, the above combination further shows wherein the TCP connection is established by completing a TCP three-way handshake with the client (Pazi, [15,20,115-118]).
Regarding claim 19, the above combination further shows wherein the transparent DNS proxy sends a TCP SYN-ACK frame to the client and receives a TCP ACK frame from the client to complete the TCP connection (Pazi, [115-118]).
Regarding claim 20, the above combination further shows wherein the DNS query received from the client over the TCP connection includes DNS request information corresponding to the UDP DNS query initially received from the client (Pazi, [114-118]).
Regarding claim 21, the above combination further shows wherein generating the UDP DNS query to the DNS resolver comprises generating the UDP DNS query using DNS request information received from the client over the TCP connection (Pazi, [114-118]).
Regarding claim 22, the above combination further shows wherein the DNS resolver receives the UDP DNS query (Pazi, [114-118]) as if the transparent DNS proxy had not intercepted the UDP DNS query from the client (the “as if” limitation is interpreted as an intended use/result implicitly achieved via showing the previously claimed reception of the UDP DNS query).
Regarding claim 24, the above combination further shows wherein closing the TCP connection comprises gracefully closing the TCP connection after sending the TCP response to the client (Pazi, [118]).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Pazi in view of Gauvin and Dillon, as applied to claim 1 above, further in view of Goranson (US-20070067438-A1).
Regarding claim 16, the above combination shows claim 1. The above combination does not show: wherein failing to receive the TCP synchronize frame from the client within a timeout period causes authentication of the client to fail. Goranson shows wherein failing to receive the TCP synchronize frame from the client within a timeout period causes authentication of the client to fail ([55,59-60]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the TCP implementation of Goranson in order to ensure unutilized or incomplete TCP connections are not left open or partially open in order to avoid wasting system resources, and thus improving operational efficiency.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Pazi in view of Gauvin and Dillon, as applied to claim 1 above, further in view of Pandrangi (US-20120170753-A1).
Regarding claim 17, the above combination shows claim 1, including wherein successful establishment of the TCP connection authenticates the client as a real client rather than an attack source (Pazi, [65], see “sent by a real client and not a spoofed source”).. The above combination does not show a scripted attack source. Pandrangi shows a scripted attack source ([28]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the scripting awareness of Pandrangi in order to ensure additional potential sources of attacks or resource wastage are anticipated and mitigated.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Pazi in view of Gauvin and Dillon, as applied to claim 1 above, further in view of Ashutosh (US-20160094645-A1).
Regarding claim 23, the above combination shows converting the UDP DNS response to the TCP response (Pazi, [118]). The above combination does not show: encapsulating DNS answer information received from the DNS resolver in a TCP response transmitted over the TCP connection to the client. Ashutosh shows encapsulating DNS answer information received from the DNS resolver in a TCP response transmitted over the TCP connection to the client ([33]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the encapsulation support of Ashutosh in order to use an old and well-known technique (encapsulation) to support the use of additional type of protocols and thus improve system implementation flexibility and utilization options.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over Pazi in view of Gauvin and Dillon, as applied to claim 1 above, further in view of Childers (US-20240121214-A1).
Regarding claim 25, the above combination shows claim 1, including wherein the DNS resolver comprises a DNS resolver protected by the transparent DNS proxy (Pazi, [63-64,71-73,114-118]). The above combination does not show use of a recursive resolver. Childers shows use of a recursive resolver (Abstract, [16-17]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination in order to utilize an old and well-known technique (recursive DNS resolution) for its intended purpose (resolving domain names) and thus ensure end users such as web-browsing clients can utilize domain names in the manner intended by system designers and expected by system users.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454
Prosecution Insights