DETAILED ACTION
This action is responsive to communications filed 28 October 2024.
Claims 1-20 are subject to 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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 28 October 2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 4, 11 and 18 objected to because of the following informalities: "the metadata registry record" is recited with insufficient antecedent basis and "the update metadata" is believed to be "the updated metadata". Appropriate correction is required.
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-3, 5-10, 12-17 and 19-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3-6, 8, 10-14 and 16-19 of U.S. Patent No. 12255868. Although the claims at issue are not identical, they are not patentably distinct from each other because of the following table below.
Instant Application
Patent 12255868
1. A method comprising: receiving on an encrypted channel, by a Domain Name System (DNS) service and from a client device, metadata associated with the client device; applying, by the DNS service, a cryptographic hash function to the metadata to determine a first hash value; storing, by the DNS service and in a metadata registry record, the first hash value and corresponding metadata associated with the client device; receiving, by the DNS service and from a DNS enhancement agent, a DNS query containing a second hash value in an additional records section; determining, by the DNS service, that the second hash value corresponds to the first hash value; based at least in part on the second hash value corresponding to the first hash value and the metadata associated with the client device, resolving the DNS query; and transmitting, by the DNS service, a DNS response including the second hash value.
3. The method of claim 2, further comprising: detecting, by the DNS service, a change in metadata associated with the client device based on a third hash value in an additional records section of a DNS query; and transmitting, to the client device, a REST API call requesting updated metadata for the client device.
8. A system comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving on an encrypted channel, by a Domain Name System (DNS) service and from a client device, metadata associated with the client device; applying, by the DNS service, a cryptographic hash function to the metadata to determine a first hash value; storing, by the DNS service and in a metadata registry record, the first hash value and corresponding metadata associated with the client device; receiving, by the DNS service and from a DNS enhancement agent, a DNS query containing a second hash value in an additional records section; determining, by the DNS service, that the second hash value corresponds to the first hash value; based at least in part on the second hash value corresponding to the first hash value and the metadata associated with the client device, resolving the DNS query; and transmitting, by the DNS service, a DNS response including the second hash value.
10. The system of claim 9, the operations further comprising: detecting, by the DNS service, a change in metadata associated with the client device based on a third hash value in an additional records section of a DNS query; and transmitting, to the client device, a REST API call requesting updated metadata for the client device.
15. One or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations comprising: receiving on an encrypted channel, by a Domain Name System (DNS) service and from a client device, metadata associated with the client device; applying, by the DNS service, a cryptographic hash function to the metadata to determine a first hash value; storing, by the DNS service and in a metadata registry record, the first hash value and corresponding metadata associated with the client device; receiving, by the DNS service and from a DNS enhancement agent, a DNS query containing a second hash value in an additional records section; determining, by the DNS service, that the second hash value corresponds to the first hash value; based at least in part on the second hash value corresponding to the first hash value and the metadata associated with the client device, resolving the DNS query; and transmitting, by the DNS service, a DNS response including the second hash value.
17. The one or more non-transitory computer-readable media of claim 16, the operations further comprising: detecting, by the DNS service, a change in metadata associated with the client device based on a third hash value in an additional records section of a DNS query; and transmitting, to the client device, a REST API call requesting updated metadata for the client device.
1. A method comprising: intercepting, by a Domain Name System (DNS) enhancement agent executing on a customer edge device, a first DNS query from a client device; applying, by the DNS enhancement agent, a cryptographic hash function to metadata associated with the client device to generate a hash value; adding, by the DNS enhancement agent, the hash value to an additional records section of the first DNS query to generate a second DNS query; transmitting, by the customer edge device, the second DNS query to a DNS service; transmitting, by the client device, the metadata associated with the client device to the DNS service on an encrypted channel, wherein the metadata is stored in a metadata registry record of the DNS service with a corresponding hash value such that a hash value received in the additional record section of a DNS query may be mapped, by the DNS service, to the corresponding metadata in the metadata registry record; receiving, by the DNS enhancement agent and from the DNS service, a DNS response including the hash value; transmitting, by the customer edge device, the DNS response to the client device; detecting, by the DNS service, a second hash value in a third DNS query indicating a change in the metadata associated with the client device; and transmitting, by the client device, the metadata associated with the client device, including the change, to the DNS service on the encrypted channel.
8. A system comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: intercepting, by a Domain Name System (DNS) enhancement agent executing on a customer edge device, a first DNS query from a client device; applying, by the DNS enhancement agent, a cryptographic hash function to metadata associated with the client device to generate a hash value; adding, by the DNS enhancement agent, the hash value to an additional records section of the first DNS query to generate a second DNS query; transmitting, by the customer edge device, the second DNS query to a DNS service; transmitting, by the client device, the metadata associated with the client device to the DNS service on an out-of-band encrypted channel, wherein the metadata is stored in a metadata registry record of the DNS service with a corresponding hash value such that a hash value received in the additional record section of a DNS query may be mapped, by the DNS service, to the corresponding metadata in the metadata registry record; receiving, by the DNS enhancement agent and from the DNS service, a DNS response including the hash value; transmitting, by the customer edge device, the DNS response to the client device; detecting, by the DNS service, a second hash value in a third DNS query indicating a change in the metadata associated with the client device; and transmitting, by the client device, the metadata associated with the client device, including the change, to the DNS service on the encrypted channel.
14. One or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations comprising: intercepting, by a Domain Name System (DNS) enhancement agent executing on a customer edge device, a first DNS query from a client device; applying, by the DNS enhancement agent, a cryptographic hash function to metadata associated with the client device to generate a hash value; adding, by the DNS enhancement agent, the hash value to an additional records section of the first DNS query to generate a second DNS query; transmitting, by the customer edge device, the second DNS query to a DNS service; transmitting, by the client device, the metadata associated with the client device to the DNS service on an out-of-band encrypted channel, wherein the metadata is stored in a metadata registry record of the DNS service with a corresponding hash value such that a hash value received in the additional record section of a DNS query may be mapped, by the DNS service, to the corresponding metadata in the metadata registry record; receiving, by the DNS enhancement agent and from the DNS service, a DNS response including the hash value; transmitting, by the customer edge device, the DNS response to the client device; detecting, by the DNS service, a second hash value in a third DNS query indicating a change in the metadata associated with the client device; and transmitting, by the client device, the metadata associated with the client device, including the change, to the DNS service on the encrypted channel.
2. The method of claim 1, wherein the metadata associated with the client device is received from an out-of-band Representational State Transfer (REST) Application Programming Interface (API).
9. The system of claim 8, wherein the metadata associated with the client device is received from an out-of-band Representational State Transfer (REST) Application Programming Interface (API).
16. The one or more non-transitory computer-readable media of claim 15, wherein the metadata associated with the client device is received from an out-of-band Representational State Transfer (REST) Application Programming Interface (API).
4. The method of claim 1, wherein the metadata associated with the client device is transmitted by an out-of-band Representational State Transfer (REST) Application Programming Interface (API), or transmitted inline through DNS, and stored in a registry at the DNS service.
11. The system of claim 8, wherein the metadata associated with the client device is transmitted by an out-of-band Representational State Transfer (REST) Application Programming Interface (API) and stored in a registry at the DNS service.
17. The one or more non-transitory computer-readable media of claim 14, wherein the metadata associated with the client device is transmitted by an out-of-band Representational State Transfer (REST) Application Programming Interface (API) and stored in a registry at the DNS service.
5. The method of claim 1, wherein the DNS query is an Extension Mechanisms for DNS (EDNS) query, the hash value is an option (OPT) type pseudo-Resource Record (pseudo-RR) in the additional records section of the EDNS query, the DNS response is an EDNS response, the hash value is an OPT type pseudo-RR in the additional records section of the EDNS response.
12. The system of claim 8, wherein the DNS query is an Extension Mechanisms for DNS (EDNS) query, the hash value is an option (OPT) type pseudo-Resource Record (pseudo-RR) in the additional records section of the EDNS query, the DNS response is an EDNS response, the hash value is an OPT type pseudo-RR in the additional records section of the EDNS response.
3. The method of claim 1, wherein the first DNS query is an Extension Mechanisms for DNS (EDNS) query and the hash value is added as an option (OPT) type pseudo-Resource Record (pseudo-RR) in the additional records section of the EDNS query.
10. The system of claim 8, wherein the first DNS query is an Extension Mechanisms for DNS (EDNS) query and the hash value is added as an option (OPT) type pseudo-Resource Record (pseudo-RR) in the additional records section of the EDNS query.
16. The one or more non-transitory computer-readable media of claim 14, wherein the first DNS query is an Extension Mechanisms for DNS (EDNS) query and the hash value is added as an option (OPT) type pseudo-Resource Record (pseudo-RR) in the additional records section of the EDNS query.
6. The method of claim 1, wherein a security policy is applied to the client device based on the metadata associated with the client device included in the hash value.
13. The system of claim 8, wherein a security policy is applied to the client device based on the metadata associated with the client device included in the hash value.
19. The one or more non-transitory computer-readable media of claim 15, wherein a security policy is applied to the client device based on the metadata associated with the client device included in the hash value.
5. The method of claim 1, further comprising applying a security policy based on the metadata associated with the client device included in the hash value.
12. The system of claim 8, further comprising applying a security policy based on the metadata associated with the client device included in the hash value.
18. The one or more non-transitory computer-readable media of claim 14, further comprising applying a security policy based on the metadata associated with the client device included in the hash value.
7. The method of claim 6, wherein the security policy is applied to a client device private IP address that is behind a Network Address Translation (NAT) public IP address.
14. The system of claim 13, wherein the security policy is applied to a client device private IP address that is behind a Network Address Translation (NAT) public IP address.
20. The one or more non-transitory computer-readable media of claim 19, wherein the security policy is applied to a client device private IP address that is behind a Network Address Translation (NAT) public IP address.
6. The method of claim 5, wherein the security policy is applied to a client device private IP address that is behind a Network Address Translation (NAT) public IP address.
13. The system of claim 12, wherein the security policy is applied to a client device private IP address that is behind a Network Address Translation (NAT) public IP address.
19. The one or more non-transitory computer-readable media of claim 18, wherein the security policy is applied to a client device private IP address that is behind a Network Address Translation (NAT) public IP address.
Although the claims are not identical, the elements of the instant application can be seen to be found within the elements of patent 12255868.
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-8, 12-15 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thornewell et al. (US-11019022-B1) hereinafter Thornewell in view of Buck et al. (US-11570144-B2) hereinafter Buck.
Regarding claim 8, Thornewell discloses:
A system ([1:50-2:36] system) comprising:
one or more processors ([2:16-36] processors); and
one or more non-transitory computer-readable media storing computer-executable instructions that ([2:16-36] computer programs recorded on one or more non-transitory computer readable media), when executed by the one or more processors ([2:16-36] executing the stored programmed instructions), cause the one or more processors to perform operations comprising:
receiving, by a Domain Name System (DNS) service and from a client device ([7:47-8:43] a DNS request 160 to the DNS server computer 150. The intermediary server computer 110 can intercept the DNS request 160), metadata associated with the client device ([7:47-8:43] client device 140 can address a DNS request 160 to the DNS server computer 150. The intermediary server computer 110 can intercept the DNS request 160 … parsed to identify returnable values … fields for the source network address, the source port, the DNS query identifier, and the case and/or value of the domain name requested (i.e. metadata associated with the client device and client DNS request));
applying, by the DNS service ([7:47-8:43] DNS packet processing logic 112), a cryptographic hash function to the metadata to determine a first hash value ([8:44-9:13] DNS packet processing logic 112 can use the returnable values of the DNS request 160 to generate a hash value);
storing, by the DNS service and in a metadata registry record ([8:44-9:13] DNS packet processing logic 112 … generate a hash value that can be used as an index into a hash data structure (i.e. registry record)), the first hash value and corresponding metadata associated with the client device ([7:47-9:13] source network address, source port, etc. as above … use the returnable values of the DNS request to generate a hash value (i.e. associated with the client device making the DNS request));
determining, by the DNS service ([8:44-9:13] DNS packet processing logic 112), that the second hash value corresponds to the first hash value ([8:44-9:13] When the hash data structure 116 indicates that the DNS response 170 is legitimate (e.g., packets 170 and 161 have matching hash values when the returnable values are used as inputs into the hash function));
transmitting, by the DNS service ([8:44-9:13] Intermediary server computer 110 can intercept the DNS response 170 (e.g., from DNS server 150)), a DNS response including the second hash value ([8:44-9:13] DNS response 170 and generate a hash value using the returnable values of the DNS response 170 (i.e. second hash)).
Thornewell does not explicitly disclose:
receiving on an encrypted channel, metadata associated with the client device;
receiving, by the DNS service and from a DNS enhancement agent, a DNS query containing a second hash value in an additional records section;
based at least in part on the second hash value corresponding to the first hash value and the metadata associated with the client device, resolving the DNS query; and
However, Buck discloses:
receiving on an encrypted channel ([18:1-17] when the first server initially receives the query, the URL is encrypted (i.e. on an encrypted channel)), metadata associated with the client device ([18:1-17] query also includes an encrypted client public key (i.e. metadata associated with the client device));
receiving, by the DNS service and from a DNS enhancement agent ([9:57-10:13] En route to server 210, DNS query message 208 is received 462 by router 404 (i.e. DNS enhancement agent) in which a security component 406 creates authentication data 212 (a signature) by taking a hash of payload data 340 using a key), a DNS query containing a second hash value in an additional records section ([9:57-10:13] combines … signature, the payload data and the key ID with the DNS query message using EDNS(0) options (i.e. additional records section));
based at least in part on the second hash value corresponding to the first hash value and the metadata associated with the client device ([7:63-8:14] server 210 then takes a hash of payload data 340 using retrieved key 344, creating new authentication data … compares the new signature to the received signature, when the signatures match, client is authenticated), resolving the DNS query ([4:37-5:21] server 210 may use authentication data 212 to authenticate client 206 and may resolve DNS query 209, creating a query response (i.e. authenticating DNS query from client, and then resolving it)); and
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Thornewell in view of Buck to have received metadata associated with the client device on an encrypted channel, receive a DNS query containing a second hash value in an additional records section, and resolving the DNS query based on at least the second hash value corresponding to the first hash value and the metadata associated with the client device. One of ordinary skill in the art would have been motivated to do so to have a protective service have a method for identifying and authenticating the client that initiated the DNS query (Buck, [2:21-25]).
Regarding claim 12, Thornewell-Buck disclose:
The system of claim 8, set forth above,
Thornewell does not explicitly disclose:
wherein the DNS query is an Extension Mechanisms for DNS (EDNS) query, the hash value is an option (OPT) type pseudo-Resource Record (pseudo-RR) in the additional records section of the EDNS query, the DNS response is an EDNS response, the hash value is an OPT type pseudo-RR in the additional records section of the EDNS response.
However, Buck discloses:
wherein the DNS query is an Extension Mechanisms for DNS (EDNS) query ([5:46-52] extension mechanisms for DNS (EDNS(0)), the hash value is an option (OPT) type pseudo-Resource Record (pseudo-RR) in the additional records section of the EDNS query ([6:5-23] EDNS(0) options … contents placed in within each option according to the embodiment are not defined by RFC 6891 (i.e. pseudo-RR as no definition)), the DNS response is an EDNS response ([5:46-52] extension mechanisms for DNS (EDNS(0)), the hash value is an OPT type pseudo-RR in the additional records section of the EDNS response ([6:5-23] EDNS(0) options … contents placed in within each option according to the embodiment are not defined by RFC 6891 (i.e. pseudo-RR as no definition)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Thornewell in view of Buck to have the DNS query and response by an EDNS query and EDNS response with the hash value as an OPT type pseudo-RR. One of ordinary skill in the art would have been motivated to do so to permit larger response capabilities in DNS (Buck, [5:46-52]).
Regarding claim 13, Thornewell-Buck disclose:
The system of claim 8, set forth above,
Thornewell does not explicitly disclose:
wherein a security policy is applied to the client device based on the metadata associated with the client device included in the hash value.
However, Buck discloses:
wherein a security policy is applied to the client device based on the metadata associated with the client device included in the hash value ([4:37-5:21] retrieved information may be compared at server 210 to an enterprise policy 222 associated with the client in a policy database 224 to determine whether client 206 should be allowed to access IP address 216 (i.e. security policy)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Thornewell in view of Buck to have a security policy applied to the client device based on the metadata associated with the client device included in the hash value. One of ordinary skill in the art would have been motivated to do so to indicate that IP address should be blocked or not as per policies (Buck, [4:37-5:21]).
Regarding claim 14, Thornewell-Buck disclose:
The system of claim 13, set forth above,
Thornewell discloses:
wherein the security policy is applied to a client device private IP address that is behind a Network Address Translation (NAT) public IP address ([19:63-20:59] communication network 740a can include public network … accessed using public network addresses; the communication network 740b can include a private network and devices attached to the network 740b can be accessed using private network address … 740a-b can communicate with each other, see [FIG. 7] e.g. network address translation required between public and private network, see [14:24-45] traffic is sent over a private or public network to a client or server (i.e. client can have private and public addresses)).
Regarding claims 1, 5-7 and 15, 19-20, they do not further define nor teach over the limitations of claims 8, 12-14, therefore, claims 1, 5-7 and 15, 19-20 are rejected for at least the same reasons set forth above as in claims 8, 12-14.
Claim(s) 2-4, 9-11 and 16-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Thornewell et al. (US-11019022-B1) hereinafter Thornewell in view of Buck et al. (US-11570144-B2) hereinafter Buck further in view of Szabó et al. (US-20250258612-A1) hereinafter Szabó.
Regarding claim 9, Thornewell-Buck disclose:
The system of claim 8, set forth above,
Thornewell-Buck do not explicitly disclose:
wherein the metadata associated with the client device is received from an out-of-band Representational State Transfer (REST) Application Programming Interface (API).
However, Szabó discloses:
wherein the metadata associated with the client device is received from an out-of-band Representational State Transfer (REST) Application Programming Interface (API) ([0092] Messaging between components of the system may in some examples use a representational state transfer (REST) application programming interface (API), … client 1310 sends initial information to the data storage control node).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Thornewell-Buck in view of Szabó to have the metadata associated with the client device received from an out-of-band REST API. One of ordinary skill in the art would have been motivated to do so to send initial information through messaging between components of the system using a REST API as a communication format. (Szabó, [0092]).
Regarding claim 10, Thornewell-Buck-Szabó disclose:
The system of claim 9, set forth above, the operations further comprising:
Thornewell does not explicitly disclose:
detecting, by the DNS service, a change in metadata associated with the client device based on a third hash value in an additional records section of a DNS query; and
transmitting, to the client device, a REST API call requesting updated metadata for the client device.
However, Buck discloses:
detecting, by the DNS service ([7:63-8:14] server 210), a change in metadata associated with the client device based on a third hash value in an additional records section of a DNS query ([7:63-8:14] server 210 then takes a hash of payload data 340 using retrieved key 344, creating new authentication data … compares the new signature to the received signature, when the signatures match, client is authenticated (i.e. when it does not match then a change is detected), see [9:57-10:13] combines … signature, the payload data and the key ID with the DNS query message using EDNS(0) options (i.e. additional records section));
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Thornewell in view of Buck to detect a change in metadata based on a third hash value in an additional records section of a DNS query. One of ordinary skill in the art would have been motivated to do so to have a protective service have a method for identifying and authenticating the client that initiated the DNS query (Buck, [2:21-25]).
Thornewell-Buck do not explicitly disclose:
transmitting, to the client device, a REST API call requesting updated metadata for the client device.
However, Szabó discloses:
transmitting, to the client device, a REST API call requesting updated metadata for the client device ([0092] Messaging between components of the system may in some examples use a representational state transfer (REST) application programming interface (API), for example with HTTP or HTTPS (i.e. request/response) … client 1310 sends initial information to the data storage control node … information may be stored by the data storage control node 1312, for example by updating a metadata database).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Thornewell-Buck in view of Szabó to transmit a REST API call requesting updated metadata. One of ordinary skill in the art would have been motivated to do so to send initial information through messaging between components of the system using a REST API as a communication format. (Szabó, [0092]).
Regarding claim 11, Thornewell-Buck-Szabó disclose:
The system of claim 10, set forth above, the operations further comprising:
Thornewell discloses:
receiving, by the DNS service and from the client device ([7:47-8:43] a DNS request 160 to the DNS server computer 150. The intermediary server computer 110 can intercept the DNS request 160), the updated metadata for the client device ([7:47-8:43] client device 140 can address a DNS request 160 to the DNS server computer 150. The intermediary server computer 110 can intercept the DNS request 160 … parsed to identify returnable values … fields for the source network address, the source port, the DNS query identifier, and the case and/or value of the domain name requested (i.e. metadata associated with the client device and client DNS request)); and
storing, by the DNS service and in the metadata registry record ([8:44-9:13] DNS packet processing logic 112 … generate a hash value that can be used as an index into a hash data structure (i.e. registry record)), the update metadata for the client device and corresponding third hash value ([7:47-9:13] source network address, source port, etc. as above … use the returnable values of the DNS request to generate a hash value (i.e. associated with the client device making the DNS request)).
Regarding claims 2-4 and 16-18, they do not further define nor teach over the limitations of claims 9-11, therefore, claims 2-4 and 16-18 are rejected for at least the same reasons set forth above as in claims 9-11.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Abed et al. (US-12009968-B1) MANAGING REGIONAL FAILOVER VIA DNS QUERIES;
Helfinstine et al. (US-20220385474-A1) SYSTEMS AND METHODS FOR SECURE COMMUNICATION;
Craciun et al. US-11552925-B1) SYSTEMS AND METHODS OF CONTROLLING INTERNET ACCESS USING ENCRYPTED DNS;
Jain et al. (US-20170064749-A1) ASSOCIATING SERVICE TAGS WITH REMOTE DATA MESSAGE FLOWS BASED ON REMOTE DEVICE MANAGEMENT ATTRIBUTES;
Kondamuru et al. (US-20150163245-A1) SYSTEMS AND METHODS FOR MANAGING DOMAIN NAME SYSTEM SECURITY (DNSSEC);
Lee (US-11601466-B2) IDENTIFYING MALWARE DEVICES WITH DOMAIN NAME SYSTEM (DNS) QUERIES;
McGarvey (US-20180173799-A1) DETERMINING A TOP LEVEL DOMAIN FROM A DOMAIN NAME;
Jungck et al. (US-9634943-B2) TRANSPARENT PROVISIONING OF SERVICES OVER A NETWORK;
Cebere et al. (US-20220140996-A1) PRIVACY-PRESERVING DOMAIN NAME SERVICE (DNS);
Barnett (US-20210392110-A1) SYSTEM AND METHOD FOR LEAK PREVENTION FOR DOMAIN NAME SYSTEM REQUESTS.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Alex Tran whose telephone number is (571)272-8173. The examiner can normally be reached Monday-Friday 10AM-6PM ET.
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, Kamal Divecha can be reached on (571)272-5863. 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.
/Alex Tran/Primary Examiner, Art Unit 2453