DETAILED ACTION
The following claims are pending in this office action: 1-20
Claims 1, 7 and 14 are independent claims.
The following claims are amended: 1-9 and 14-16
The following claims are new: -
The following claims are cancelled: -
Claims 1-20 are rejected.
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 .
Continued Examination Under 37 CFR 1.114
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/20/2026 has been entered.
RESPONSE TO ARGUMENTS
Applicant’s arguments in the amendment filed 01/20/2026 have been fully considered but are moot in view of new grounds of rejection.
Applicant notes: Independent claim 1 is amended to recite “determining that the location of the IoT device is logically located on a secure side of the network relative to the network device.” This limitation is disclosed by Wesselius (US Pub. 2021/0258720) as explained below and rejected accordingly.
Independent claims 7 and 14 are amened in a similar way to claim 1. The amended limitations are disclosed by Wesselius (US Pub. 2021/0258720) as explained below and rejected accordingly.
Dependent claims 2-6, 8-13 and 15-20 depend on independent claims 1, 7 and 14. The amended elements in the claims are disclosed Wesselius (US Pub. 2021/0258720) as explained below, and so any additional features to the dependent claims are rejected accordingly.
In interest of advancing prosecution, Examiner notes that the recited claims are broadly interpreted to recite a general, generic concept of determining that a location of the a device is logically located on the secure side. For example, claim 1 simply recites that the location is logically located on a secure side “relative to the network device.” It is unclear how it is or in what way it is “relative to the network device.” Claims 7 and 14 recite a first location and a second location, the first location “of the intercepting node” and the second location “of the intercepting node.” However, neither of these nodes are associated to an IoT device nor a networking device/router/switch that ties it to the DNS query and metadata of the DNS query which appears to be the inventive concept. This allows for a much broader reasonable interpretation for what the devices may be. Furthermore, there are no real constraints on the “first location” and “second location” other than that the first location is “of the intercepting node” and the second location “of the querying device” is “logically located on a secure side of a network.” The “relative to the intercepting node” appears to be overly broad for the same reasons as explained above in the same way as above, but even more so as a “intercepting node” is much broader than a network device/router/switch that handles location inserted DNS queries in the manner claimed in claim 1, but may be anything that receives the DNS query, without performing any other operations related to the DNS query. The specification, and Fig. 1A, for example, clearly marks that the router 104 is located within the secure area 116, as are the various IoT devices, where the DNS service/server are located outside the area 116. Aside from this geographic relationship, the claims do not clearly establish that the IoT device, the router, and the DNS service are different entities performing specific tasks. As so, the claims allow for a broad interpretation and the combination as explained below.
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.
Claims 1-6 are rejected under 35 U.S.C. 103 as being unpatentable over Wilson et al. (US Pub. 2021/0281575) (hereinafter “Wilson”) in view of Buck et al. (US Pub. 2021/0029074) (hereinafter “Buck”) and in view of Wesselius (US Pub. 2021/0258720) (hereinafter “Wesselius”)
As per claim 1, Wilson teaches a computer-implemented method performed by a network device, comprising: ([Wilson, 0212] “A computer-readable medium 922 … embodying any one or more of the methodologies or functions described herein”; [Fig. 1A] The Third-Party Server is a device connected to networks 190 and so is a network device)
receiving a domain name system (DNS) query ([Wilson, para. 0074] “the third-party server 140 may receive an authentication query from a message recipient”; [para. 0075] “the authentication query may be a DNS query”) from an Internet-of-Things (IoT) device ([Fig. 1A] shows the Recipient Device 180; [para. 0054] “recipient device 180 may be described as … a message recipient”; [para. 0081] “An IoT device … may transmit an authentication query”) in a network, ([para. 0048] “a user device 160 …. may transmit and receive data via the network 190 … recipient devices 180 may also be examples of user devices 160”) the DNS query intended for delivery to a DNS service; ([para. 0027] “To manage its namespace 112, an organization 110 may include and control a namespace server … a domain owner DNS server [a DNS service] … A namespace 112 [a DNS service] … answer queries”; [para. 0074] “the third-party server 140 may receive an authentication query [the DNS query] from a message recipient … the third-party server 140, as an operator of the delegated namespace zone 142 [DNS service], provides the identity record 146 or part of the identity record 146 to the message recipient as the authentication response”; as the namespace answers the DNS query, the DNS query is necessarily intended for delivery to the namespace/DNS service to receive an answer to the query).
verifying an identity of the IoT device; and ([Wilson, para. 0080] “The third-party server 140 may authenticate [verifying an identity of] the message recipient [the IoT device]”)
responsive to determining that the location of the IoT device is secure, producing metadata, the metadata including a location code ([Wilson, para. 0080] “The third-party server 140 may authenticate the message recipient [in response to verifying the identity of the IoT device] before any authentication context information [metadata] is forwarded [produced] to the message recipient for the recipient”; [para. 0077] “Authentication context information may include … contextual metadata … such as … location [location of the IoT device]”; although Wilson teaches producing metadata that is digitally signed, see para. 0067 where “authentication context information … may include information that is signed by the private key 132”’; responsive to determining that the location of the IoT device is logically located on the secure side, producing a location code describing the location of the IoT device is more clearly taught by Wesselius below; the metadata being “digitally signed metadata” is more clearly taught by Buck below) describing the location of the IoT device ([para. 0080] “the third-party server 140 may verify the location information metadata ... [the metadata including a location code] of the sending location of the message [describing the location of the IoT device] in order to confirm that the message was sent from a legitimate beacon”)
Wilson does not clearly teach producing digitally signed metadata; inserting the digitally signed metadata into the DNS query; and forwarding the DNS query with the digitally signed metadata to the DNS service.
However, Buck teaches producing digitally signed metadata; ([Buck, para. 0053] “En route to server 210, DNS query message 208 is received 462 by router 404 in which a security component 406 creates [producing] authentication data 212 (a signature) [digitally signed metadata] by taking a hash of payload data 340 using a key”)
inserting the digitally signed metadata into the DNS query; and ([Buck, para. 0053] “Router security component 406 then combines authentication data (a signature), the payload data, and the key ID with the DNS query message using EDNS(0) 336 options as discussed earlier… the router adds [inserts] the payload [the digitally signed metadata] to the request [into the DNS query] sent from a client”; [Fig. 4] the figure shows that the EDNS(0) fields/metadata [as they are not part of the main data sent by the client] are inserted into the DNS query message)
forwarding the DNS query with the digitally signed metadata to the DNS service. ([Buck, para. 0054; Fig. 4] “Transmission 464 sends [forwarding] DNS query message 208 [DNS query with the digitally signed metadata] to server 210 which proceeds … to resolve IP address 211 … with DNS server 214 [to the DNS service]”; as shown by the figure, the DNS Query message is sent to the DNS server for a DNS service/to resolve the DNS)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson with the teachings of Buck to include producing digitally signed metadata; inserting the digitally signed metadata into the DNS query; and forwarding the DNS query with the digitally signed metadata to the DNS service. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of providing the protective service to have a method for identifying and authenticating the client that initiated the DNS query where the method does not increase the number of related queries from the client or increase the number of related responses sent to the client. (Buck, para. 0018)
Wilson in view of Buck does not clearly teach producing a location of the IoT device; determining that the location of the IoT device is logically located on a secure side of the network relative to the network device; responsive to determining that the location of the IoT device is logically located on the secure side, producing a location code describing the location of the IoT device.
However, Wesselius teaches producing a location of the IoT device; ([Wesselius, para. 0056] “the server ... determines ... the current location of the mobile device”)
determining that the location of the IoT device is logically located on a secure side of the network relative to the network device; ([Wesselius, para. 0005] “A geofence may thus be set up ... an expected (secure) location [secure side of the network, as the location is referred to as inside a navigable network – see para. 0029]”; [para. 0054] “geofencing ... refers to the activity of checking in which predefined zone(s) of interest a device is currently located within”; [para. 0056] “once the server has received the current location of the mobile device ... determines from the current location a current status of the mobile device with respect to one or more zones of interest [secure side] that have been previously defined within the geographic region and whose positions are stored, or at least can be accessed by, the server [relative to the network device]”)
responsive to determining that the location of the IoT device is logically located on the secure side, producing a location code describing the location of the IoT device. ([Wesselius, para. 0034] “where the current location of the device [location of the IoT device] falls within a perimeter of a particular predefined zone [logically located on the secure side], the status will indicate that the device is currently located within that zone [location code] ... may thus be generated [producing] ... predefined zone(s) which the device is currently located within [location]”; [para. 0035] “the current status of the device may be output to processing circuitry on a server”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck with the teachings of Wesselius to include producing a location of the IoT device; determining that the location of the IoT device is logically located on a secure side of the network relative to the network device; responsive to determining that the location of the IoT device is logically located on the secure side, producing a location code describing the location of the IoT device. One of ordinary skill in the art would have been motivated to make this modification because this may help to reduce the battery and bandwidth usage of the device by eliminating useless calls resulting in lower cost for the service and a faster response time for calls that are made. (Wesselius, para. 0071)
As per claim 2, Wilson in view of Buck and Wesselius teaches claim 1.
Wilson in view of Wesselius does not clearly teach wherein the IoT device is eDNS unaware.
However, Buck teaches wherein the IoT device is eDNS unaware. ([Buck, para. 0053; Fig. 4] “client 205 [IoT device – see para. 0051] does not add information to EDNS(0) options”; Fig. 4 shows that the client/IoT device does not utilize EDNS options, as opposed to both the router and Authenticating and Recursive DNS server, and therefore is “eDNS unaware”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Wesselius with the teachings of Buck to include wherein the IoT device is eDNS unaware. One of ordinary skill in the art would have been motivated to make this modification because few mobile/IoT device browsers support extensions, and using an extended DNS, for example in the router, permits larger response capabilities. (Buck, para. 0033; and para. 0102)
As per claim 3 Wilson in view of Buck and Wesselius teaches claim 1.
Wilson also teaches wherein the network device that performs the method is a switch, router, or security device of the network. ([Wilson, para. 0207-0208] “The structure of a computing machine described in FIG. 9 may correspond to … servers … shown in Fig. 1A [the network device that performs the method] … a computing machine may be ... a network router … a switch”; [para. 0212-0213] “The computer system 900 [the computing machine in Fig. 9] may include … The storage unit 916 includes a computer-readable medium 922 … embodying any one or more of the methodologies or functions described herein”)
As per claim 4, Wilson in view of Buck and Wesselius teaches claim 1.
Wilson does not clearly teach wherein the location of the IoT device refers to a security boundary in the network.
However, Wesselius teaches wherein the location of the IoT device refers to a security boundary in the network. ([Wesselius, para. 0003] “A geofence is ... a virtual boundary that can be used for defining a zone of interest ... to a device”; [para. 0005] “the location of a device [an IoT device as it is a mobile phone] relative to a geofence ... set up around ... an expected (secure) location [security boundary in the network]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck with the teachings of Wesselius to include wherein the location of the IoT device refers to a security boundary in the network. One of ordinary skill in the art would have been motivated to make this modification because in this way, the IoT device may be tracked to provide alerts to the user if it deviates from an expected location. (Wesselius, para. 0005)
As per claim 5, Wilson in view of Buck and Wesselius teaches claim 1.
Wilson in view of Buck does not clearly teach wherein the logical location includes information regarding positioning of the IoT device relative to a security barrier.
However, Wesselius teaches wherein the logical location includes information regarding positioning of the IoT device relative to a security barrier. ([Wesselius, para. 0003] “A geofence is ... a virtual boundary that can be used for defining a zone of interest ... to a device”; [para. 0034] “where the current location of the device [positioning of the IoT device] falls within [relative to] a perimeter of a particular predefined zone [a security barrier], the status will indicate [the logical location includes] that the device is currently located within that zone [information regarding positioning of the IoT device relative to a security barrier]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to combine the teachings of Wilson, Buck and Wesselius for the same reasons as disclosed above.
As per claim 6, Wilson in view of Buck and Wesselius teaches claim 1.
Wilson also teaches wherein the digitally signed metadata includes a flag indicating a presence of the digitally signed metadata. ([Wilson, para. 0067] “the identity record 146 [metadata – see para. 0077: “contextual metadata … may also be an example of … identify records”] … is signed by the private key 132 of the named entity device 130; [para. 0069] “A unique identifier [flag] … may be used as a record locator for retrieving … key-value pairs [indicating a presence of the digitally signed metadata]”; [para. 0074] “The identifier [a flag] in the authentication query may be the same as … the data metadata [digitally signed metadata includes a flag] that allows the third-party server 140 to retrieve the identifier stored [indicating a presence of the digitally signed metadata] in the identity record”)
Claims 7-9, 11, 14-16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Wilson in view of Buck, Wesselius, and in view of Negm (US Patent No. 11,729,142) (hereinafter “Negm”)
As per claim 7, Wilson teaches a computer-implemented method comprising: ([Wilson, para. 0213] “A computer-readable medium 922 … embodying any one or more of the methodologies or functions described herein”)
detecting metadata in the DNS query; ([Wilson, para. 0081] “An IoT device, upon receiving the message, may transmit an authentication query [in the DNS query see para. 0075: “the authentication query may be a DNS query”] to the third-party server 140 … the third-party server 140 may verify [detecting] the location information metadata [metadata]”; [para. 0072] the metadata is metadata in the DNS query as “the third-party server 140 may determine a proper response to the query based on the query content and the metadata of the query”)
verifying a signature of the metadata; and ([Wilson, para. 0080] “The third-party server 140 may verify the digital signature of the message recipient [verify a signature of the metadata as the message recipient is data that defines the query/metadata] that may be included in an authentication query”)
comparing the location code to an expected location of the node; and ([Wilson, para. 0081] “third-party server 140 may verify [comparing] the location information metadata [the location code] … an example of contextual evaluation … of the sending location of the message in order to confirm that the message was sent from a legitimate beacon [an expected location]”; the node as an intercepting node is more clearly by Buck below)
based at least in part on the comparing, sending a response to the querying device. ([Wilson, para. 0081] “The third-party server 140 may transmit a response that includes the … contextual evaluation result [based on the comparing] … to the IoT device”; [para. 0081] the IoT device is a querying device as “An IoT device … may transmit an authentication query”)
Wilson does not clearly teach receiving, via an intercepting node, a domain name system (DNS) query from a querying device; extracting the metadata from the DNS query; the location code indicating a first location of the intercepting node and indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node; comparing the second location of the querying device to an expected location of the intercepting node; and based at least in part on verifying the signature, extracting a location code from the metadata.
However, Buck teaches receiving, via an intercepting node, a domain name system (DNS) query from a querying device; ([Buck, para. 0053] “client 206 [querying device as it transmits the query] addresses DNS query message 208 … En route to server 210 [intercepting], DNS query message 208 is received 462 by router [via an intercepting node]”)
extracting the metadata from the DNS query; and ([Buck, para. 0031] “On receiving DNS query message 208 [the DNS query], server 210 may use [extracting] authentication data 212 [the metadata]”; authentication data 212 is metadata as it is data that contextualizes the query data, which is “to authenticate client 206” that sends the DNS query message)
based at least in part on verifying the signature, extracting a location code from the metadata. ([Buck, para. 0039] “With client 206 authenticated, security component 335 may proceed to resolve DNS query 209 and retrieve [extract] … data 226 that is included in an EDNS(0) [a location code] option 328”; [para. 0075] “EDNS client subnet (ECS) standard is used along with EDNS(0) to include some limited information about client 206 location [a location code] in DNS query message 208”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson with the teachings of Buck to include extracting the metadata from the DNS query; and based at least in part on verifying the signature, extracting a location code from the metadata. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of providing the protective service to have a method for identifying and authenticating the client that initiated the DNS query where the method does not increase the number of related queries from the client or increase the number of related responses sent to the client. (Buck, para. 0018)
Wilson in view of Buck does not clearly teach extracting a location code, the location code indicating a first location of the intercepting node and indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node; and comparing the second location of the querying device to an expected location of the intercepting node.
However, Negm teaches extracting a location code, ([Negm, col. 13, ln. 57-62] “the network gateway modifies the DNS query to include location parameters ... the DNS resolver receives the modified DNS query and extracts the location information of the destination location”) the location code indicating a first location of the intercepting node ([col. 10, ln. 44-55] “the network gateway modifies the DNS query to include location parameters [location code] ... Additionally ... the general location of the client device may be the location of the network gateway device [a first location of the intercepting node]”) and a second location of the querying device relative to the intercepting node; and ([col. 10, ln. 44-49] “the network gateway modifies the DNS query to include location parameters ... a location of the client device as detected by [relative to] the network gateway device [the intercepting node – see col. 5, ln. 49-51]”)
comparing the second location of the querying device to an expected location of the intercepting node. ([Negm, col. 13, ln. 57-60] “the network gateway modifies the DNS query to include location parameters indicative of the new location of the client device, referred to herein at the destination location”; [col. 14, ln. 6-9] “suitable for handling the client request ... due to a large distance between the destination location [second location of the querying device] and the first edge platform [an expected location of the intercepting node – see col. 9, ln. 24-27: “suitability of an edge platform ... may depend at least in part on a distance between ... the edge platform and a network gateway device”] as compared”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck with the teachings of Negm to include extracting a location code, the location code indicating a first location of the intercepting node and indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node; comparing the second location of the querying device to an expected location of the intercepting node. One of ordinary skill in the art would have been motivated to make this modification because such a system optimal use of edge resources while also ensuring the user information is kept private and secure. (Negm, col. 1, ln. 57-62)
Wilson in view of Buck and Negm does not clearly teach the location code indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node.
However, Wesselius teaches the location code indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node. ([Wesselius, para. 0005] “A geofence may thus be set up ... an expected (secure) location”; [para. 0054] “geofencing ... refers to the activity of checking in which predefined zone(s) of interest [secure side of a network] a device is currently located within [logically located on]”; [para. 0056] “the device [querying device] may ... send ... a request for its current status ... the server then actions this request and determines from the current location a current status of the mobile device with respect to one or more zones of interest that have been previously defined within the geographic region and whose positions are stored ... by, the server [relative to the intercepting mode] ... which predefined zones [logically located on a secure side of a network] the device is currently located [a second location of the querying device] within”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck and Negm with the teachings of Wesselius to include the location code indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node. One of ordinary skill in the art would have been motivated to make this modification because this may help to reduce the battery and bandwidth usage of the device by eliminating useless calls resulting in lower cost for the service and a faster response time for calls that are made. (Wesselius, para. 0071)
As per claim 8, Wilson in view of Buck, Negm and Wesselius teaches claim 7.
Wilson in view of Buck and Negm does not clearly teach wherein the second location is within a security boundary.
However, Wesselius teaches wherein the second location is within a security boundary. ([Wesselius, para. 0003] “A geofence is ... a virtual boundary that can be used for defining a zone of interest ... to a device”; [para. 0034] “where the current location of the device [second location] falls within [is within] a perimeter of a particular predefined zone [a security boundary]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck and Negm with the teachings of Wesselius to include wherein the location of the IoT device refers to a security boundary in the network. One of ordinary skill in the art would have been motivated to make this modification because in this way, the IoT device may be tracked to provide alerts to the user if it deviates from an expected location. (Wesselius, para. 0005)
As per claim 9, Wilson in view of Buck, Negm and Wesselius teaches claim 7.
Wilson in view of Buck and Negm does not clearly teach wherein the location code indicates that the logical location of the querying device is in a logically secure position relative to a security barrier.
However, Wesselius teaches wherein the location code indicates that the logical location of the querying device is in a logically secure position relative to a security barrier. ([Wesselius, para. 0005] “A geofence may thus be set up ... an expected (secure) location”; [para. 0003] “A geofence is ... a virtual boundary [security barrier] that can be used for defining a zone of interest ... to a device”; [para. 0034] “where the current location of the device [logical location of the querying device] falls within [is in a logically secure position relative to] a perimeter of a particular predefined zone [a security barrier], the status [location code] will indicate that the device is currently located within that zone”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to combine the teachings of Wilson, Buck, Negm and Wesselius for the same reasons as disclosed above.
As per claim 11, Wilson in view of Buck and Negm teaches claim 7.
Wilson also teaches in an instance where the location code matches the expected location, the response indicates that the DNS query is verified. ([Wilson, para. 0081] “An IoT device, upon receiving the message, may transmit an authentication query [DNS query] … the third-party server 140 can authenticate the message [verify the DNS query] … third-party server 140 may verify the location information metadata [location code] … an example of contextual evaluation … of the sending location of the message in order to confirm [matches] that the message was sent from a legitimate beacon [an expected location] … The third-party server 140 may transmit a response that includes the … contextual evaluation result … to the IoT device”; as the result indicates the location code/location metadata matches the expected location of the beacon which is a verification of the context of the DNS query, the result indicates that the DNS query is verified)
As per claim 14, Wilson teaches a server device comprising: ([Wilson, 0207] “The structure of a computing machine described in FIG. 9 may correspond to … servers”)
one or more processors; and ([Wilson, para. 0209] “The example computer system 900 includes one or more processors 902”)
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: ([Wilson, para. 0212] “The computer system 900 may include … a storage unit 916 [one or more non-transitory computer-readable media]” [para. 0213] “The storage unit 916 includes a computer-readable medium 922 on which is stored instruction 924 [computer-executable instructions] embodying any one or more of the methodologies or functions described herein”; [para. 0214] “The computer-readable medium may include any medium that is capable of storing instructions (e.g., instructions 924) for execution by the processors (e.g., processors 902) and that causes the processors to perform any one or more of the methodologies disclosed herein”)
detect metadata in the DNS query; ([Wilson, para. 0081] “An IoT device, upon receiving the message, may transmit an authentication query [in the DNS query see para. 0075: “the authentication query may be a DNS query”] to the third-party server 140 … the third-party server 140 may verify [detecting] the location information metadata [metadata]”; [para. 0072] the metadata is metadata in the DNS query as “the third-party server 140 may determine a proper response to the query based on the query content and the metadata of the query”)
verify a signature of the metadata; and ([Wilson, para. 0080] “The third-party server 140 may verify the digital signature of the message recipient [verify a signature of the metadata as the message recipient is data that defines the query/metadata] that may be included in an authentication query”)
comparing the location code to an expected location of the intercepting node; and ([Wilson, para. 0081] “third-party server 140 may verify [comparing] the location information metadata [the location code] … an example of contextual evaluation … of the sending location of the message in order to confirm that the message was sent from a legitimate beacon [an expected location]”; the node as an intercepting node is more clearly by Buck below)
based at least in part on the comparing, sending a response to the querying device. ([Wilson, para. 0081] “The third-party server 140 may transmit a response that includes the … contextual evaluation result [based on the comparing] … to the IoT device”; [para. 0080] the IoT device is a querying device as “An IoT device … may transmit an authentication query”)
Wilson does not clearly teach receive, via an intercepting node, a domain name system (DNS) query from a querying device; extract the metadata from the DNS query; the location code indicating a first location of the intercepting node and indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node; comparing the second location to an expected location of the intercepting node; and based at least in part on verifying the signature, extract a location code from the metadata.
However, Buck teaches receive, via an intercepting node, a domain name system (DNS) query from a querying device; ([Buck, para. 0053] “client 206 [querying device as it transmits the query] addresses DNS query message 208 … En route to server 210 [intercepting], DNS query message 208 is received 462 by router [via an intercepting node]”)
extract the metadata from the DNS query; and ([Buck, para. 0031] “On receiving DNS query message 208 [the DNS query], server 210 may use [extracting] authentication data 212 [the metadata]”; authentication data 212 is metadata as it is data that contextualizes the query data, which is “to authenticate client 206” that sends the DNS query message)
based at least in part on verifying the signature, extract a location code from the metadata. ([Buck, para. 0039] “With client 206 authenticated, security component 335 may proceed to resolve DNS query 209 and retrieve [extract] … data 226 that is included in an EDNS(0) [a location code] option 328”; [para. 0075] “EDNS client subnet (ECS) standard is used along with EDNS(0) to include some limited information about client 206 location [a location code] in DNS query message 208”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson with the teachings of Buck to include receive, via an intercepting node, a domain name system (DNS) query from a querying device; extract the metadata from the DNS query; and based at least in part on verifying the signature, extract a location code from the metadata. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of eliminating the risk of executing untrusted code/interpreting untrusted data when two or more corporate entities have different policies towards managing the risk of the untrusted code/data. (Buck, para. 0035)
Wilson in view of Buck does not clearly teach extracting a location code, the location code indicating a first location of the intercepting node and indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node; and comparing the second location to an expected location of the intercepting node.
However, Negm teaches teach extracting a location code, ([Negm, col. 13, ln. 57-62] “the network gateway modifies the DNS query to include location parameters ... the DNS resolver receives the modified DNS query and extracts the location information of the destination location”) the location code indicating a first location of the intercepting node ([col. 10, ln. 44-55] “the network gateway modifies the DNS query to include location parameters [location code] ... Additionally ... the general location of the client device may be the location of the network gateway device [a first location of the intercepting node]”) and a second location of the querying device relative to the intercepting node; and ([col. 10, ln. 44-49] “the network gateway modifies the DNS query to include location parameters ... a location of the client device as detected by [relative to] the network gateway device [the intercepting node – see col. 5, ln. 49-51]”)
comparing the second location to an expected location of the intercepting node. ([Negm, col. 13, ln. 57-60] “the network gateway modifies the DNS query to include location parameters indicative of the new location of the client device, referred to herein at the destination location”; [col. 14, ln. 6-9] “suitable for handling the client request ... due to a large distance between the destination location [second location of the querying device] and the first edge platform [an expected location of the intercepting node – see col. 9, ln. 24-27: “suitability of an edge platform ... may depend at least in part on a distance between ... the edge platform and a network gateway device”] as compared”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck with the teachings of Negm to include extracting a location code, the location code indicating a first location of the intercepting node and a second location of the querying device relative to the intercepting node; and comparing the second location of the querying device to an expected location of the intercepting node. One of ordinary skill in the art would have been motivated to make this modification because such a system optimal use of edge resources while also ensuring the user information is kept private and secure. (Negm, col. 1, ln. 57-62)
Wilson in view of Buck and Negm does not clearly teach the location code indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node.
However, Wesselius teaches the location code indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node. ([Wesselius, para. 0005] “A geofence may thus be set up ... an expected (secure) location”; [para. 0054] “geofencing ... refers to the activity of checking in which predefined zone(s) of interest [secure side of a network] a device is currently located within [logically located on]”; [para. 0056] “the device [querying device] may ... send ... a request for its current status ... the server then actions this request and determines from the current location a current status of the mobile device with respect to one or more zones of interest that have been previously defined within the geographic region and whose positions are stored ... by, the server [relative to the intercepting mode] ... which predefined zones [logically located on a secure side of a network] the device is currently located [a second location of the querying device] within”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck and Negm with the teachings of Wesselius to include the location code indicating that a second location of the querying device is logically located on a secure side of a network relative to the intercepting node. One of ordinary skill in the art would have been motivated to make this modification because this may help to reduce the battery and bandwidth usage of the device by eliminating useless calls resulting in lower cost for the service and a faster response time for calls that are made. (Wesselius, para. 0071)
As per claim 15, the claim language is identical or substantially similar to that of claim 8. Therefore, it is rejected under the same rationale applied to claim 8.
As per claim 16, the claim language is identical or substantially similar to that of claim 9. Therefore, it is rejected under the same rationale applied to claim 9.
As per claim 18, the claim language is identical or substantially similar to that of claim 11. Therefore, it is rejected under the same rationale applied to claim 11.
Claims 12-13 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wilson in view of Buck, Negm and Wesselius as applied to claims 7 and 14 above, and further in view of Rodriguez Bravo et al. (US Pub. 2021/0218751) (hereinafter “Rodriguez”).
As per claim 12, Wilson in view of Buck, Negm and Wesselius teaches claim 7.
Wilson in view of Buck, Negm and Wesselius does not clearly teach wherein, in an instance where the location code does not match the expected location, the response includes instructions for the querying device to shut down.
However, Rodriguez teaches wherein, in an instance where the location code does not match the expected location, the response includes instructions for the querying device to shut down. ([Rodriguez, para. 0040-0044; Fig. 3] “For the case in which protection program 300 determines that the smartphone is not located within the pre-determined location [in an instance where the location code does not match the expected location] … Protection program 300 performs a protective action [the response] directed to the smartphone [for the querying device] … protection program 300 disables all access function of the device [for the querying device to shut down], effectively “bricking” the device such that it is no longer usable”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck, Negm and Wesselius with the teachings of Rodriguez to include wherein, in an instance where the location code does not match the expected location, the response includes instructions for the querying device to shut down. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of resulting in a non-functional, data-cleansed device, totally worthless to a perpetrator of theft, and thus providing a deterrence. (Rodriguez, para. 0016)
As per claim 13, Wilson in view of Buck, Negm and Wesselius teaches claim 7.
Wilson also teaches sending a message indicating a contextual validation. ([Wilson, para. 0081] “The third-party server 140 may transmit a response that includes the … contextual evaluation result [a message indicating a contextual validation]”; [para. 0080] the IoT device is a querying device as “An IoT device … may transmit an authentication query”)
Wilson in view of Buck, Negm and Wesselius does not clearly teach determining via the comparing that the location code does not match the expected location; and responsive to determining that the location code does not match the expected location, sending a message indicating a failed validation to a management device.
However, Rodriguez teaches determining via the comparing that the location code does not match the expected location; and ([Rodriguez, para. 0040] “protection program 300 determines that the smartphone is not located within the pre-determined location”)
responsive to determining that the location code does not match the expected location, sending a message indicating a failed validation to a management device. ([Rodriguez, para. 0042] “Protection program 300 recognizes that smartphone 110 may be in a compromised condition, based on the location of smartphone 110 being outside of the pre-determined location [responsive to determining that the location code does not match the expected location]… Protection program 300 includes the current location information of smartphone 110 [a message indicating a failed validation as the validation of the current location failed] in a message and sends the information [sending a message] to … a trusted user's device [a management device] previously designated by the user of smartphone 110”; [para. 0026] the trusted user’s device is a “management device” as “the user identifies authorized devices … which enable [manage] privileged operations of smartphone 110”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck, Negm and Wesselius with the teachings of Rodriguez to include teach determining via the comparing that the location code does not match the expected location; and responsive to determining that the location code does not match the expected location, sending a message indicating a failed validation to a management device. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing to perform additional locking of access to features and data of the IoT device, thereby protecting from unauthorized access that may compromise the user. (Rodriguez, para. 0016)
As per claim 19, the claim language is identical or substantially similar to that of claim 12. Therefore, it is rejected under the same rationale applied to claim 12.
As per claim 20, the claim language is identical or substantially similar to that of claim 13. Therefore, it is rejected under the same rationale applied to claim 13.
Claims 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Wilson in view of Buck, Negm and Wesselius as applied to claims 7 and 14 above, and further in view Earnhart et al. (US Patent No. 9,838,259) (hereinafter “Earnhart”).
As per claim 10, Wilson in view of Buck, Negm and Wesselius teaches claim 7.
Wilson in view of Buckl, Negm and Wesselius does not clearly teach detecting a flag in the DNS query, the flag indicating a presence of metadata in the DNS query; and extracting the metadata from the DNS query at least partly responsive to detecting the flag.
However, Earnhart teaches detecting a flag in the DNS query, the flag indicating a presence of metadata in the DNS query; and ([Earnhart, col. 5, ln. 66 to col. 6, ln. 6] “In step 310, the application traffic manager computing device 14 determines if the received DNS query includes the metadata in form of a domain name with the value indicating the type of internet protocol version [a flag] … the application traffic manager computing device 14 parses the received DNS query to identify the value [the flag] indicating the type of internet protocol version thereby determining the presence of the metadata [indicating a presence of metadata in the DNS query]”)
extracting the metadata from the DNS query at least partly responsive to detecting the flag. ([Earnhart, col. 6, ln. 59-62] “in step 330 [responsive to detecting a flag, as step 330 occurs in response to step 310], the application traffic manager computing device 14 processes the query by truncating [extracting] the appended domain name with the value [the metadata]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Wilson in view of Buck, Negm and Wesselius with the teachings of Earnhart to include detecting a flag in the DNS query, the flag indicating a presence of metadata in the DNS query; and extracting the metadata from the DNS query at least partly responsive to detecting the flag. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of this technology provides the flexibility to alter the received response, reject the received response or provide the response to the querying client device. (Earnhart, col. 2, ln. 53-55)
As per claim 17, the claim language is identical or substantially similar to that of claim 10. Therefore, it is rejected under the same rationale applied to claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Colon et al. (US Patent No. 11,509,642) discloses a computer server that receives location data form a mobile client device and may compare the location data to predefined secure location definitions and determine, using the result of comparing, an authentication process.
Ashok et al. (US Pub. 2020/0334931) discloses a access control device that determines a first location of individual based on a Bluetooth signal, and then transmits the location data to a gateway device. Then, a second location of the individual is determined and this location is also transmitted. This process is used to provide access to a restricted/secure area.
Schoner et al. (US Pub. 2014/0035726) discloses entity tracking where a geographic location of a wireless identification component is determined to ascertain whether the component is in a secure area, and a report is sent depending on whether it is in the secure area.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHE LIU whose telephone number is (571) 272-3634. The examiner can normally be reached on Monday - Friday: 8:30 AM to 5:30 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, Carl Colin can be reached on (571) 272-3862. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (IN USA OR CANADA) or (571) 272-1000.
/ZHE LIU/Examiner, Art Unit 2493