1Notice 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
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/13/2026 has been entered.
The amendment filed 01/13/2026 has been entered. Claims 1-8 and 13-20 are pending. Claims 1 and 13 have been amended.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/16/2026 was in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed 01/13/2026 have been fully considered but they are not persuasive.
In that remark, the applicant argued in substance:
That: The cited references fail to teach “without accessing a service-independent recursive DNS resolver; wherein a service endpoint hosts a service-specific DNS service that serves DNS requests, and the client computing system is connected directly to the service endpoint so that the DNS request is resolved by the service-specific DNS server,”
In response to the applicant’s argument LAIBLE in [0044] teaches a DNS request 301 related to a SIP service request 303 is sent from the SIP UA running on the end device 20 of the user 2 to the specific DNS server 110. The SIP UA may have been provided with the address of the specific DNS server 110 by a service provider or automatically via a DHCP server. For the SIP UA and generally for the network elements of the subnetwork, the specific DNS server 110 has the status of a regular DNS server which has to be contacted first in case of a DNS request, in [0039] the SIP UA sends a DNS request to the specific DNS server 110, directly, in [0039], the analysis of a service request or a DNS request associated with the service request may result in the detection that the service request must be processed by a specific network element, in [0015], using the SSVGDNSS, service specific requests are easily routed to specific network elements, in [0023], if the received DNS request is related to one of a set of pre-defined services or service types, the DNS server is able to generate a reply to the received DNS request. The reply may comprise the domain name/address of a network entity according to the resolution instructions retrieved from the memory, e.g., the address of a specific network element handling the service or the address of an SBC of the sub-network. The specific DNS server sends the reply to the network entity where the DNS request originated, and in [0035], it is also possible that the SIP45 UA 21 directly performs a DNS lookup without relaying to the proxy server 112.
Therefore, LAIBLE clearly teaches UA running on the end device of the user (corresponds to client device) sends a DNS request to the specific DNS server that serves specific service directly, service request is processed by a specific network element or specific network element handling the service (corresponds to service endpoint hosts a service-specific DNS service) and service specific requests are easily routed to specific network elements and UA directly performs a DNS lookup without relaying to a proxy server. LAIBLE also teaches if the received DNS request is related to one of a set of pre-defined services or service types, the DNS server is able to generate a reply to the received DNS request. The reply may comprise the address of a specific network element handling the service.
In response to the applicant’s argument “the combination lacks the claimed architecture”, the combination clearly teaches a direct connection between a user device and service specific DNS server to resolve a service specific DNS request instead of contacting a regular DNS server.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the motivation is in order to easily route service specific requests to specific network elements, (LAIBLE, [0015]).
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-5 and 13-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Clarke et al. (US 20190052658) hereinafter Clarke in view of LAIBLE (EP 1855446 A1) hereinafter LAIBLE and Metke et al. (US 20070211714) hereinafter Metke and further in view of Vixie (US 20210067493) hereinafter Vixie.
Regarding claim 1, Clarke teaches a computer system, comprising: a domain name system (DNS) server (i.e. a domain name system (DNS) server/service, [0042]); a data store storing computer executable instructions which, when executed by the service-specific DNS server, cause the service-specific DNS server to perform steps comprising (i.e. memory types, including various computer-readable media, may be used to store and execute program instructions, [0031] and device that implements a DNS service, may perform procedure by executing stored instructions, [0085]): receiving, from a client computing system, a DNS request, based on a service-specific domain name (i.e. the DNS service (server) may receive a DNS query sent by a node in a network, [0085] and if a user of a client node wishes to visit example-domain.test, the client may first send out a DNS query to a DNS service (server) for the IP address associated with this domain, [0033]); accessing, with the service-specific DNS server, a DNS routing policy based on the DNS request (i.e. a device in a network intercepts a Domain Name System (DNS) query sent by a node in the network to a DNS service. The DNS service processes the query to perform Domain Name resolution, [0037] and DNS service 302 may act as an index that relates domains to network addresses. For example, through the DNS mechanism, DNS service 302 may receive and store a network address that is associated with the domain of endpoint node, [0042]); and serving the DNS request using the service-specific DNS server by returning an internet protocol (IP) address of a service endpoint corresponding to the service-specific domain name based on the DNS routing policy (i.e. the DNS service may return the associated IP address to the client, which can then use this address to access the service(s) of the domain (e.g., a website, etc.), [0033]).
However, Clarke does not explicitly disclose a service-specific domain name system (DNS) server; wherein the DNS request is transmitted directly from the client computing system to the service-specific DNS server, without accessing a service-independent recursive DNS resolver; wherein a service endpoint hosts a service-specific DNS service that serves DNS requests, and the client computing system is connected directly to the service endpoint so that the DNS request is resolved by the service-specific DNS server.
However, LAIBLE teaches a service-specific domain name system (DNS) server (i.e. specific DNS server may be called a service specific DNS Server, [0013]); wherein the DNS request is transmitted directly from the client computing system to the service-specific DNS server, without accessing a service-independent recursive DNS resolver (i.e. a DNS request 301 related to a SIP service request 303 is sent from the SIP UA running on the end device 20 of the user 2 to the specific DNS server 110. The SIP UA may have been provided with the address of the specific DNS server 110 by a service provider or automatically via a DHCP server. For the SIP UA and generally for the network elements of the subnetwork, the specific DNS server 110 has the status of a regular DNS server which has to be contacted first in case of a DNS request, [0044] and the SIP UA sends a DNS request to the specific DNS server 110, directly, [0039]); wherein a service endpoint hosts a service-specific DNS service that serves DNS requests (i.e. the analysis of a service request or a DNS request associated with the service request may result in the detection that the service request must be processed by a specific network element, [0029]), and the client computing system is connected directly to the service endpoint so that the DNS request is resolved by the service-specific DNS server (i.e. using the SSVGDNSS, service specific requests are easily routed to specific network elements, [0015] and If the received DNS request is related to one of a set of pre-defined services or service types, the DNS server is able to generate a reply to the received DNS request. The reply may comprise the domain name/address of a network entity according to the resolution instructions retrieved from the memory, e.g., the address of a specific network element handling the service or the address of an SBC of the sub-network. The specific DNS server sends the reply to the network entity where the DNS request originated, [0023] and it is also possible that the SIP45 UA 21 directly performs a DNS lookup without relaying to the proxy server 112, [0035]).
Based on Clarke in view of LAIBLE, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of LAIBLE to the system of Clarke in order to easily route service specific requests to specific network elements, (LAIBLE, [0015]).
However, Clarke in view of LAIBLE do not explicitly disclose wherein the client computing system stores a service-specific DNS identifier corresponding to the service-specific domain name.
However, Metke teaches wherein the client computing system stores a service-specific DNS identifier corresponding to the service-specific domain name (i.e. A first Internet Protocol (IP) address of a Domain Name Server (DNS) that is initially stored in an operating system of a node, [0038]).
Based on Clarke in view of LAIBLE and further in view of Metke, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Metke to the system of Clarke and LAIBLE in order to easily determine a destination for a particular communication.
However, Clarke in view of LAIBLE and further in view of Metke do not explicitly disclose a secure, encrypted protocol.
However, Vixie teaches a secure, encrypted protocol (i.e. a DNS query is sent to the network address via HTTPS, the HTTPS session can be initiated using Transport Layer Security (TLS), [0054]).
Based on Clarke in view of LAIBLE and Metke and further in view of Vixie, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Vixie to the system of Clarke, LAIBLE, and Metke in order have a secure communication between a DNS server and a client.
Regarding claim 2, Clarke teaches a DNS traffic controller configured to obtain request metadata from the DNS request (i.e. a controller accesses metadata regarding the client node (e.g., node A) that was inserted into the DNS query issued by that client to make overall network routing and resource decisions, [0066] and extracting the metadata about the node from the DNS query, [0086] and the metadata includes address metadata may indicate the IP or other network address of the requesting node, [0057] and location metadata may indicate the location of the requesting node, [0058]).
Regarding claim 3, Clarke teaches the DNS traffic controller is configured to aggregate the request metadata with other traffic metadata to obtain aggregated metadata (i.e. traffic metadata inserted into the DNS query. In further embodiments, if the device inserting the metadata into the DNS query also has knowledge about the domain being queried, it can also encode this information in the metadata of the DNS query, [0056] and all of the metadata regarding the client node (e.g., node A) that was inserted into the DNS query issued by that client, [0066], (e.g., location metadata, [0058], address metadata, [0057], Time Window metadata, [0065] etc.)).
Regarding claim 4, Clarke teaches the DNS traffic controller is configured to modify the DNS routing policy based on the aggregated metadata (i.e. using all of the metadata regarding the client node that was inserted into the DNS query the controller can make overall network routing optimized, [0065] and based on the metadata in DNS query regarding node A, and potentially based on any additional policy elements configured in DNS service, generating appropriate network policy information to be used by local network, [0062]).
Regarding claim 5, Clarke teaches the DNS traffic controller is configured to generate a routing control signal based on the aggregated metadata (i.e. the metadata used for network policy signaling, both to and from the DNS service, [0039]).
Regarding claims 13-17, the limitations of claims 13-17 are similar to the limitations of claims 1-5. Therefore, the limitations of claims 13-17 are rejected in the analysis of claims 1-5 above, and the claims are rejected on that basis.
Claim(s) 6-8 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Clarke et al. (US 20190052658) hereinafter Clarke in view of LAIBLE (EP 1855446 A1) hereinafter LAIBLE and Metke et al. (US 20070211714) hereinafter Metke and Vixie (US 20210067493) hereinafter Vixie and further in view of MA et al. (CN 106911815 A) hereinafter MA.
Regarding claim 6, Clarke in view of LAIBLE and Metke and further in view of Vixie teach the limitations of claims 1 and 3 above.
However, Clarke in view of LAIBLE and Metke and further in view of Vixie do not explicitly disclose the DNS traffic controller is configured to aggregate the request metadata with server capacity metadata to obtain the aggregated metadata.
However, MA teaches the DNS traffic controller is configured to aggregate the request metadata with server capacity metadata to obtain the aggregated metadata (i.e. the controller collects the status information that includes DNS query status information and server status information for example CPU, Memory, Disk Space, Traffic, Delay, Number of Connections information such as CPU 40%, memory is 30%, the number of connections is 30%, page 17, paragraphs 1-6).
Based on Clarke in view of LAIBLE and Metke and Vixie and further in view of MA, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of MA to the system of Clarke, LAIBLE, Metke and Vixie in order to automatically route a DNS query to another available DNS server (MA, page 2, paragraph 1).
Regarding claim 7, Clarke in view of LAIBLE and Metke and further in view of Vixie teach the limitations of claims 1 and 3 above.
However, Clarke in view of LAIBLE and Metke and further in view of Vixie do not explicitly disclose the DNS traffic controller is configured to aggregate the request metadata with server availability metadata to obtain the aggregated metadata.
However, MA teaches the DNS traffic controller is configured to aggregate the request metadata with server availability metadata to obtain the aggregated metadata (i.e. the controller collects the status information that includes DNS query status information and server status information for example an abnormal status information includes: the server is unreachable and the DNS service is unavailable, page 17, paragraphs 1-6).
Based on Clarke in view of LAIBLE and Metke and Vixie and further in view of MA, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of MA to the system of Clarke, LAIBLE, Metke and Vixie in order to automatically route a DNS query to another available DNS server (MA, page 2, paragraph 1).
Regarding claim 8, Clarke in view of LAIBLE and Metke and further in view of Vixie teach the limitations of claim 1 above including the service-specific DNS server.
However, Clarke in view of LAIBLE and Metke and further in view of Vixie do not explicitly disclose the DNS server is configured to load a DNS identifier, identifying the DNS server deployed at the service endpoint, on the client computing system.
However, MA teaches the DNS server is configured to load a DNS identifier, identifying the DNS server deployed at the service endpoint, on the client computing system (i.e. send the flow table to the forwarder, where the flow table at least includes Internet Protocol (IP) addresses of DNS server and a port number that a DNS server is connected to on the forwarder and the forwarder uses the flow table to send the DNS request to a specific DNS server, page 8, paragraphs 1-6).
Based on Clarke in view of LAIBLE and Metke and Vixie and further in view of MA, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of MA to the system of Clarke, LAIBLE, Metke and Vixie in order to automatically route a DNS query to another available DNS server (MA, page 2, paragraph 1).
Regarding claims 18-20, the limitations of claims 18-20 are similar to the limitations of claims 6-8. Therefore, the limitations of claims 18-20 are rejected in the analysis of claims 6-8 above, and the claims are rejected on that basis.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYELE F WOLDEMARIAM whose telephone number is (571)270-5196. The examiner can normally be reached M_F 8:30AM-5:00PM.
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, Joon H Hwang can be reached on 571-272-4036. 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.
/AW/
AYELE F. WOLDEMARIAM
Examiner
Art Unit 2447
3/6/2026
/SURAJ M JOSHI/Primary Examiner, Art Unit 2447