Prosecution Insights
Last updated: August 17, 2026
Application No. 18/643,112

Processing DHCP Renewals in an SDA Environment

Non-Final OA §103
Filed
Apr 23, 2024
Examiner
MCBETH, WILLIAM C
Art Unit
2449
Tech Center
2400 — Computer Networks
Assignee
Cisco Technology Inc.
OA Round
3 (Non-Final)
67%
Grant Probability
Favorable
3-4
OA Rounds
4m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 67% — above average
67%
Career Allowance Rate
197 granted / 294 resolved
+9.0% vs TC avg
Strong +57% interview lift
Without
With
+57.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
21 currently pending
Career history
315
Total Applications
across all art units

Statute-Specific Performance

§101
9.2%
-30.8% vs TC avg
§103
49.8%
+9.8% vs TC avg
§102
5.7%
-34.3% vs TC avg
§112
30.6%
-9.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 294 resolved cases

Office Action

§103
DETAILED ACTION The amendment to Application Ser. No. 18/643,112 filed on January 20, 2026, has been entered. Claims 1, 8 and 15 are currently amended. Claims 1-20 are pending and are examined. 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 . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. Response to Arguments The amendment to Claims 1, 8 and 15 has overcome the rejection of Claims 1-20 under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or joint inventor regards as the invention set forth in the Non-Final Office Action mailed October 20, 2025. The rejection of Claims 1-20 under 35 U.S.C. 112(b) is hereby withdrawn. The arguments with respect to the rejection of Claims 1-20 under 35 U.S.C. 103 have been fully considered by the Examiner but are not persuasive. Specifically, on page 9 of the response filed January 20, 2026, Applicant argues, “The Chari-Mittal-Patrick combination does not disclose, teach, or suggest ‘receiving, by the first router, an acknowledgment communicated by the remote DHCP server, wherein the acknowledgment comprises the IP address of the first router,’ as recited in amended Claim 1. The Office Action maps the claimed ‘first router’ to Chari's access node 1021 and the claimed ‘remote DHCP server’ to Chari's home DHCP server 1010. Office Action at 7. While the cited portions of Chari disclose how a ‘home gateway then changes the giaddr field on the DHCP Renew packet to home gateways's IP address, and unicasts the packet to the home DHCP server’ see Chari at paragraph 187), Chari does not disclose ‘receiving, by the first router, an acknowledgment communicated by the remote DHCP server, wherein the acknowledgment comprises the IP address of the first router,’ as claimed, at least because Chari's home DHCP server is unaware of access node 1021's IP address and instead communicates the acknowledgement to the home gateway's IP address: ‘This DHCP Ack packet is unicast by the home DHCP server to the home gateways's IP address and contains an xid identifier that is identical to that in the DHCP Request packet. See Chari at paragraph 188.” The Examiner specifically disagrees. Chari discloses that the home DHCP server issues a DHCP Ack in response to receiving the DHCP Renew request and that the DHCP Ack is relayed to Node N, i.e., access node 121, via the home gateway, wherein the home gateway sets the giaddr field in the DHCP Ack to Node N’s IP address before relaying the DHCP ack to Node N. Specifically, paragraph 188 of Chari states, in part: “When this packet is received by the home gateway, the home gateway uses the xid-to-giaddr mapping to retrieve the IP address of node N. The home gateway then sets the giaddr field in the DHCP Ack to be the node N's IP address and unicasts this modified packet to node N. Node N receives the DHCP Ack and relays it to client device (emphasis added).” As shown, Chari explicitly discloses that the DHCP Ack, originated by the DHCP server comprises the IP address of Node N, i.e., access node 1021, in the giaddr field when the DHCP Ack is received by Node N. Additionally, as Chari discloses that the DHCP Ack is unicast from the home gateway to the Node N, inclusion of Node N’s IP address in the destination address field of the DHCP Ack is implied. In either case, the DHCP Ack originated by the DHCP server and relayed to Node N by the home gateway comprises Node N’s IP address when it is received by Node N, which is all that is required by the limitation. Claim Interpretation “The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met.” See MPEP 2111.04 II. Regarding method Claim 1, the following limitations recite steps that are performed only upon certain conditions being met: “adding, by the first router, an internet protocol (IP address of the first router and a DHCP option to the DHCP renewal request when it is determined that the gateway address and DHCP options are not present in the DHCP renewal request”. Given its broadest reasonable interpretation, Claim 1 does not require the action “adding, by the first router, an internet protocol (IP address of the first router and a DHCP option to the DHCP renewal request” to be performed as it is subject to a condition, i.e., a determination that a gateway address and DHCP options are not present in the DHCP renewal request, that is not required by the claim to occur. 8. While the broadest reasonable interpretation of Claim 1 does not require the performance of steps which are contingent upon conditions that are not required to be met, for the purposes of compact prosecution, insofar as the recited limitations are definite, prior art has been applied to each limitation in this Office Action as if each step is required to be performed. 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, 2, 4, 5, 8, 9, 11, 12, 15, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chari et al., Pub. No. US 2005/0074015 A1, hereby “Chari”, in view of Mittal et al., Pub. No. US 2013/0024553 A1, hereby “Mittal”, in further view of Patrick, RFC 3046, titled “DHCP Relay Agent Information Option”. Regarding Claim 1, Chari discloses “A method for performing dynamic host configuration protocol (DHCP) renewal (Chari fig. 10 and paragraphs 185 and 187: a process for preserving DCHP address assignment) comprising: intercepting, by a first router, a DHCP renewal request communicated by a local device to a remote DHCP server (Chari fig. 10 and paragraphs 40 and 186-187: DHCP relay agent on Node N, e.g., access node 1021, intercepts a DHCP Renew packet issued by a client device), wherein the first router is one of a plurality of routers positioned between the local device and the remote DHCP server and wherein the plurality of routers form a mesh network (Chari fig. 10 and paragraphs 28-32, 40, 44 and 186: access node 1021 and foreign gateway 1032 are part of a wireless mesh network and reside in the network path between the client device and home DHCP server 1010);” and “adding, by the first router, an internet protocol (IP address of the first router... to the DHCP renewal request... (Chari fig. 10 and paragraph 187: access node 1021 sets the GIADDR field, i.e., the gateway address, in the DCHP Renew packet to its IP address); forwarding, by the first router, the DHCP renewal request from the first router to the remote DHCP server (Chari fig. 10 and paragraphs 187: access node 1021 forwards the DHCP Renew packet towards home DHCP server 1010 via foreign gateway 1032); receiving, by the first router, an acknowledgment communicated by the remote DHCP server, wherein the acknowledgment comprises the IP address of the first router (Chari fig. 10 and paragraph 188: the home gateway sets the GIADDR field of the DHCP Ack packet issued by home DHCP server 1010 to the IP address of access node 1021 and unicasts the DCHP Ack packet to access node 1021); and forwarding, by the first router, the acknowledgment to the local device (Chari fig. 10 and paragraph 188: access node 1021, receives the DHCP ACK packet and relays it to the client device).” However, while Chari discloses that the access node sets the GIADDR field in the DHCP renew request (Chari fig. 10 and paragraph 187), Chari does not explicitly disclose “adding, by the first router, an internet protocol (IP) address of the first router and a DHCP option to the DHCP renewal request... (emphasis added)”. In the same field of endeavor, Mittal discloses inserting, by a DHCP relay agent, an IP address and a group identifier in the GIADDR (gateway IP address) and relay agent information option fields of a DCHP request (Mittal figs. 1, 3 and 5 and paragraphs 34 and 37: relay agent 10 modifies the DHCP request by inserting the relay agent's IP address in the GIADDR field and the group identifier in a sub-option of the relay agent information option).” It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Chari to insert a group identifier in a sub-option of the relay agent information option field of the DHCP renewal request as taught by Mittal. One of ordinary skill in the art would have been motivated to combine inserting a group identifier in a sub-option of the relay agent information option field of the DHCP renewal request to simplify configuration of the DHCP server in providing uniform policies to a group of end nodes (Mittal paragraphs 19 and 38). However, while Mittal discloses inserting, by a DHCP relay agent, an IP address and a group identifier in the GIADDR (gateway IP address) and relay agent information option fields of a DCHP request (Mittal paragraphs 34 and 37), the combination of Chari and Mittal does not explicitly disclose “determining, by the first router, if a gateway address and DHCP options are present in the DHCP renewal request, wherein the gateway address is an address of the first router; adding, by the first router, an internet protocol (IP) address of the first router and a DHCP option to the DHCP renewal request when it is determined that the gateway address and DHCP options are not present in the DHCP renewal request (emphasis added)”. In the same field of endeavor, Patrick discloses determining whether a gateway address and DCHP options are present in a received DHCP packet (Patrick § "2.1 Agent Operation" and "2.1.1 Reforwarded DHCP requests" – “Relay agents receiving a DHCP packet from an untrusted circuit with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count.” - While not explicitly stated, the relay agent necessarily determines if the GIADDR field has a non-zero value, i.e., a gateway address is present, and if the relay agent information option is present.) and further suggests inserting a gateway address and a DHCP option in the received DHCP packet when the gateway address and DCHP options are not already present (Patrick § "2.1 Agent Operation" and "2.1.1 Reforwarded DHCP requests": "Otherwise, the relay agent SHALL forward any received DHCP packet with a valid non-zero giaddr WITHOUT adding any relay agent options. Per RFC 2131, it shall also NOT modify the giaddr value." – While not explicitly stated, insertion of the relay agent’s IP address and relay agent information in the GIADDR and relay agent information option fields of the DHCP packet by the relay agent when those fields are set to zero, i.e., not present, in the received DHCP packet, is implied.)” It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Chari, as modified by Mittal, to insert, by the relay agent, its IP address and group identifier when values are not already present in the GIADDR and relay agent information option fields of the DHCP renewal request as taught by Patrick. One of ordinary skill in the art would have been motivated to combine inserting, by the relay agent, its IP address and group identifier when values are not already present in the GIADDR and relay agent option fields to preserve information inserted by a relay agent located closer to the client device. Regarding Claim 2, the combination of Chari, Mittal and Patrick discloses all of the limitations of Claim 1. Additionally, Chari discloses “receiving the acknowledgment from a second router, wherein the second router is positioned between the first router and the remote DHCP server (Chari fig. 10 and paragraphs 44 and 188: access node 1021 receives the DHCP ACK from a home gateway, i.e., a second router, which is positioned in the network path between the access node and the DHCP server).” Regarding Claim 4, the combination of Chari, Mittal and Patrick discloses all of the limitations of Claim 1. Additionally, Chari discloses “wherein the remote DHCP server and the local device have a different subnet (Chari fig. 10 and paragraphs 92 and 186: "FIG. 10 shows a mesh network in which DHCP packets can be routed between subnets." – While not explicitly stated, it is readily understood by one of ordinary skill in the art that the client device and DHCP server are located on different subnets).” Regarding Claim 5, the combination of Chari, Mittal and Patrick discloses all of the limitations of Claim 1. Additionally, Mittal discloses “wherein adding the DHCP option to the DHCP renewal request comprises setting option 82 in the DHCP renewal request (Mittal paragraphs 34 and 37: the group identifier is inserted as a sub-option of relay agent information option 82).” It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Chari to insert a group identifier in a sub-option of the relay agent information option field of the DHCP renewal request as taught by Mittal for the reasons set forth in the rejection of Claim 1. Regarding Claim 8, Chari discloses “A first router (Chari fig. 10 and paragraphs 40 and 186: access node 1021, which may be a router or any other networking device capable of attachment to a client) comprising: intercepting a DHCP renewal request communicated by a local device to a remote DHCP server (Chari fig. 10 and paragraphs 40 and 186-187: DHCP relay agent on node N such as access node 1021 intercepts a DHCP Renew packet issued by a client device); and “adding, by the first router, an internet protocol (IP) address of the first router and a DHCP option to the DHCP renewal request... to the DHCP renewal request... (Chari fig. 10 and paragraph 187: access node 1021 sets the GIADDR field, i.e., the gateway address, in the DCHP Renew packet to its IP address); forwarding, by the first router, the DHCP renewal request from the first router to the remote DHCP server (Chari fig. 10 and paragraphs 187: access node 1021 forwards the DHCP Renew packet towards home DHCP server 1010 via foreign gateway 1032); receiving, by the first router, an acknowledgment communicated by the remote DHCP server, wherein the acknowledgment comprises the IP address of the first router (Chari fig. 10 and paragraph 188: the gateway sets the GIADDR field of the DHCP Ack packet issued by home DHCP server 1010 to the IP address of access node 1021 and unicasts the DCHP Ack packet to access node 1021); and forwarding, by the first router, the acknowledgment to the local device (Chari fig. 10 and paragraph 188: access node 1021 receives the DHCP ACK packet and relays it to the client device).” However, while Chari discloses that the access node implementing the DHCP relay agent may be a router (Chari paragraph 40) and further discloses that the access node sets the GIADDR field in the DHCP renew request (Chari fig. 10 and paragraph 187), Chari does not explicitly disclose the access node comprising “one or more processors; and one or more computer-readable non-transitory storage media coupled to the one or more processors that stores instructions operable when executed by the one or more processors to cause the first router to perform operations...” and “adding, by the first router, an internet protocol (IP) address of the first router and a DHCP option to the DHCP renewal request... (emphasis added)”. In the same field of endeavor, Mittal discloses “A first router (Mittal figs. 1, 4 and 5 and paragraphs 29-30: network device 40 implementing relay agent 10), comprising: one or more processors (Mittal fig. 4 and paragraph 30: one or more processors 42); and one or more computer-readable non-transitory storage media coupled to the one or more processors that stores instructions operable when executed by the one or more processors to cause the first router to perform operations (Mittal fig. 4 and paragraphs 30-31: memory 44)”. Mittal further discloses inserting, by a DHCP relay agent, an IP address and a group identifier in the GIADDR (gateway IP address) and relay agent information option fields of a DCHP request (Mittal figs. 1, 3 and 5 and paragraphs 34 and 37: relay agent 10 modifies the DHCP request by inserting the relay agent's IP address in the GIADDR field and the group identifier in a sub-option of the relay agent information option). It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the access node of Chari to insert a group identifier in a sub-option of the relay agent information option field of the DHCP renewal request as taught by Mittal. One of ordinary skill in the art would have been motivated to combine inserting a group identifier in a sub-option of the relay agent information option field of the DHCP renewal request to simplify configuration of the DHCP server in providing uniform policies to a group of end nodes (Mittal paragraphs 19 and 38). However, while Mittal discloses inserting, by a DHCP relay agent, an IP address and a group identifier in the GIADDR (gateway IP address) and relay agent information option fields of a DCHP request (Mittal paragraphs 34 and 37), the combination of Chari and Mittal does not explicitly disclose “determining, by the first router, if a gateway address and DHCP options are present in the DHCP renewal request, wherein the gateway address is an address of the first router; adding an internet protocol (IP) address of the first router and a DHCP option to the DHCP renewal request when it is determined that the gateway address and DHCP options are not present in the DHCP renewal request (emphasis added)”. In the same field of endeavor, Patrick discloses determining whether a gateway address and DCHP options are present in a received DHCP packet (Patrick § "2.1 Agent Operation" and "2.1.1 Reforwarded DHCP requests" – “Relay agents receiving a DHCP packet from an untrusted circuit with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count.” - While not explicitly stated, the relay agent necessarily determines if the GIADDR field has a non-zero value, i.e., a gateway address is present, and if the relay agent information option is present.) and further suggests inserting a gateway address and a DHCP option in the received DHCP packet when the gateway address and DCHP options are not already present (Patrick § "2.1 Agent Operation" and "2.1.1 Reforwarded DHCP requests": "Otherwise, the relay agent SHALL forward any received DHCP packet with a valid non-zero giaddr WITHOUT adding any relay agent options. Per RFC 2131, it shall also NOT modify the giaddr value." – While not explicitly stated, insertion of the relay agent’s IP address and relay agent information in the GIADDR and relay agent information option fields of the DHCP packet by the relay agent when those fields are set to zero, i.e., not present, in the received DHCP packet, is implied.). It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the access node of Chari, as modified by Mittal, to insert, by the relay agent, its IP address and group identifier when values are not already present in the GIADDR and relay agent information option fields of the DHCP renewal request as taught by Patrick. One of ordinary skill in the art would have been motivated to combine inserting, by the relay agent, its IP address and group identifier when values are not already present in the GIADDR and relay agent option fields to preserve information inserted by a relay agent located closer to the client device. Insofar as it recites similar claim elements, Claim 9 is rejected for substantially the same reasons presented above with respect to Claim 2. Insofar as it recites similar claim elements, Claim 11 is rejected for substantially the same reasons presented above with respect to Claim 4. Insofar as it recites similar claim elements, Claim 12 is rejected for substantially the same reasons presented above with respect to Claim 5. Regarding Claim 15, Chari discloses “intercepting, by a first router, a DHCP renewal request communicated by a local device to a remote DHCP server (Chari fig. 10 and paragraphs 40 and 186-187: DHCP relay agent on node N such as access node 1021, i.e., a first router, intercepts a DHCP Renew packet issued by a client device), wherein the first router is one of a plurality of routers positioned between the local device and the remote DHCP server and wherein the plurality of routers form a mesh network (Chari fig. 10 and paragraphs 28-32, 40, 44 and 186: access node 1021 and foreign gateway 1032 are part of a wireless mesh network and reside in the network path between the client device and home DHCP server 1010);” and “adding, by the first router, an internet protocol (IP) address of the first router... to the DHCP renewal request... (Chari fig. 10 and paragraph 187: access node 1021 sets the GIADDR field, i.e., the gateway address, in the DCHP Renew packet to its IP address); forwarding, by the first router, the DHCP renewal request from the first router to the remote DHCP server (Chari fig. 10 and paragraphs 187: access node 1021 forwards the DHCP Renew packet towards home DHCP server 1010 via foreign gateway 1032); receiving, by the first router, an acknowledgment communicated by the remote DHCP server, wherein the acknowledgment comprises the IP address of the first router (Chari fig. 10 and paragraph 188: the gateway sets the GIADDR field of the DHCP Ack packet issued by home DHCP server 1010 to the IP address of access node 1021 and unicasts the DCHP Ack packet to access node 1021); and forwarding, by the first router, the acknowledgment to the local device (Chari fig. 10 and paragraph 188: access node 1021 receives the DHCP ACK packet and relays it to the client device).” However, while Chari discloses that the access node implementing the DHCP relay agent may be a router (Chari paragraph 40) and further discloses that the access node sets the GIADDR field in the DHCP renew request (Chari fig. 10 and paragraph 187), Chari does not explicitly disclose “One or more computer-readable non-transitory storage media embodying instructions that, when executed by a processor, cause the processor to perform operations...” and adding, by the first router, an internet protocol (IP) address of the first router and a DHCP option to the DHCP renewal request... (emphasis added)”. In the same field of endeavor, Mittal discloses “One or more computer-readable non-transitory storage media embodying instructions that, when executed by a processor, cause the processor to perform operations (Mittal fig. 4 and paragraphs 30-31: memory 44 comprises program instructions, that when executed by processor 42, cause the network device 40 to perform relay agent operations)”. Mittal further discloses inserting, by a DHCP relay agent, an IP address and a group identifier in the GIADDR (gateway IP address) and relay agent information option fields of a DCHP request (Mittal figs. 1, 3 and 5 and paragraphs 34 and 37: relay agent 10 modifies the DHCP request by inserting the relay agent's IP address in the GIADDR field and the group identifier in a sub-option of the relay agent information option). It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the access node of Chari to insert a group identifier in a sub-option of the relay agent information option field of the DHCP renewal request as taught by Mittal. One of ordinary skill in the art would have been motivated to combine inserting a group identifier in a sub-option of the relay agent information option field of the DHCP renewal request to simplify configuration of the DHCP server in providing uniform policies to a group of end nodes (Mittal paragraphs 19 and 38). However, while Mittal discloses inserting, by a DHCP relay agent, an IP address and a group identifier in the GIADDR (gateway IP address) and relay agent information option fields of a DCHP request (Mittal paragraphs 34 and 37), the combination of Chari and Mittal does not explicitly disclose “determining, by the first router, if a gateway address and DHCP options are present in the DHCP renewal request, wherein the gateway address is an address of the first router; adding, by the first router, an internet protocol (IP) address of the first router and a DHCP option to the DHCP renewal request when it is determined that the gateway address and DHCP options are not present in the DHCP renewal request (emphasis added)”. In the same field of endeavor, Patrick discloses determining whether a gateway address and DCHP options are present in a received DHCP packet (Patrick § "2.1 Agent Operation" and "2.1.1 Reforwarded DHCP requests" – “Relay agents receiving a DHCP packet from an untrusted circuit with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count.” - While not explicitly stated, the relay agent necessarily determines if the GIADDR field has a non-zero value, i.e., a gateway address is present, and if the relay agent information option is present.) and further suggests inserting a gateway address and a DHCP option in the received DHCP packet when the gateway address and DCHP options are not already present (Patrick § "2.1 Agent Operation" and "2.1.1 Reforwarded DHCP requests": "Otherwise, the relay agent SHALL forward any received DHCP packet with a valid non-zero giaddr WITHOUT adding any relay agent options. Per RFC 2131, it shall also NOT modify the giaddr value." – While not explicitly stated, insertion of the relay agent’s IP address and relay agent information in the GIADDR and relay agent information option fields of the DHCP packets by the relay agent when those fields are set to zero, i.e., not present, in the received DHCP packet, is implied.). It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the access node of Chari, as modified by Mittal, to insert, by the relay agent, its IP address and group identifier when values are not already present in the GIADDR and relay agent information option fields of the DHCP renewal request as taught by Patrick. One of ordinary skill in the art would have been motivated to combine inserting, by the relay agent, its IP address and group identifier when values are not already present in the GIADDR and relay agent option fields to preserve information inserted by a relay agent located closer to the client device. Insofar as it recites similar claim elements, Claim 16 is rejected for substantially the same reasons presented above with respect to Claim 2. Insofar as it recites similar claim elements, Claim 18 is rejected for substantially the same reasons presented above with respect to Claim 5. Claims 3, 7, 10, 14, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Chari, Mittal and Patrick in view of the article by ldanny, titled “DHCP in the Fabric”, hereby “ldanny”. Regarding Claim 3, the combination of Chari, Mittal and Patrick discloses all of the limitations of Claim 1. However, while Chari discloses that the access node, i.e., the first router, receives the DHCP ACK from the gateway, i.e., a second router located between the access node and the DHCP server, as a unicast transmission (Chari paragraphs 44 and 188), the combination of Chari, Mittal and Patrick does not explicitly disclose “receiving the acknowledgment as a unicast packet from a fusion router, wherein the fusion router is positioned between the first router and the remote DHCP server (emphasis added).” In the same field of endeavor, ldanny discloses a fusion router that resides in the network path between an edge router, i.e., a first router, and a remote DHCP server (ldanny § “DHCP Flow in The Fabric”: see figure on page 5 of PDF illustrating edge router “E”, fusion router, and DHCP server). It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Chari, as modified by Mittal and Patrick, to utilize a fusion router located between the access node and the remote DHCP server as taught by ldanny because doing so constitutes a simple substitution of one known element (a gateway) for another (a fusion router) to obtain predictable and desirable results (relaying of DHCP messages between the access node and the DHCP server). See KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007). Regarding Claim 7, the combination of Chari, Mittal and Patrick discloses all of the limitations of Claim 1. Additionally, Chari discloses wherein “the first router is an edge node of the mesh network (Chari fig. 10 and paragraphs 31 and 40: access nodes, such as access node 1021, provide a point of attachment of a client with the wireless mesh network, i.e., are edge nodes of the mesh network).” However, while Chari discloses that the access nodes and gateways are part of the wireless mesh network (Chari paragraph 31), the combination of Chari, Mittal and Patrick does not explicitly disclose wherein “the mesh network is a software-defined access (SDA) network.” In the same field of endeavor, ldanny discloses a software-defined-access (SDA fabric, i.e., mesh network, comprising a plurality of edge and border devices (ldanny § “DHCP Flow in The Fabric”: see figure on page 5 of PDF illustrating SDA fabric comprising edge device “E” and border device “B”).” It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Chari, as modified by Mittal and Patrick, to implement a software-defined access (SDA) fabric as taught by ldanny because doing so constitutes a simple substitution of one known element (a wireless mesh network ) for another (an SDA fabric) to obtain predictable and desirable results (enabling communication between client devices and the external network). See KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007). Insofar as it recites similar claim elements, Claim 10 is rejected for substantially the same reasons presented above with respect to Claim 3. Insofar as it recites similar claim elements, Claim 14 is rejected for substantially the same reasons presented above with respect to Claim 7. Insofar as it recites similar claim elements, Claim 17 is rejected for substantially the same reasons presented above with respect to Claim 3. Insofar as it recites similar claim elements, Claim 20 is rejected for substantially the same reasons presented above with respect to Claim 7. Claims 6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Chari, Mittal and Patrick in view of the Droms, RFC 2131 titled “Dynamic Host Configuration Protocol (DHCP)”. Regarding Claim 3, the combination of Chari, Mittal and Patrick discloses all of the limitations of Claim 1. However, while Chari discloses the access node, i.e., the first router, receiving the DHCP ACK unicast from the gateway and relaying the DHCP ACK to the client device (Chari paragraph 188), the combination of Chari, Mittal and Patrick does not explicitly disclose “wherein the first router receives the acknowledgment as a unicast message and forwards the acknowledgment to the local device as a broadcast (emphasis added).” In the same field of endeavor, Droms discloses that a DHCP relay agent may broadcast a DHCP ACK received from the DHCP server to the DHCP client (Droms § “4.1 Constructing and sending DHCP messages”: “A server or relay agent sending or relaying a DHCP message directly to a DHCP client (i.e., not to a relay agent specified in the ’giaddr’ field) SHOULD examine the BROADCAST bit in the ’flags’ field. If this bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address.”).” It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Chari, as modified by Mittal and Patrick, to broadcast the DHCP ACK from the access node to the client device as taught by Droms. One of ordinary skill in the art would have been motivated to combine broadcasting the DHCP ACK from the access node to the client device when unicasting the DHCP ACK is not possible due to client configuration (Droms § “4.1 Constructing and sending DHCP messages”). Insofar as it recites similar claim elements, Claim 13 is rejected for substantially the same reasons presented above with respect to Claim 6. Insofar as it recites similar claim elements, Claim 19 is rejected for substantially the same reasons presented above with respect to Claim 6. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Rong et al., Pub. No. US 2016/0344687 A1, discloses a DHCP relay that fills the GIADDR field of a DHCP message received from a DHCP client with the IP address of an IP interface of the DHCP relay if the GIADDR field of the received DHCP message is zero; Zheng et al., the IETF Internet Draft titled “DHCP Relay Agent Stacking” discloses that a DHCP Relay Agent does not add a “second” relay agent option when it receives a DHCP packet with a Relay Agent Information option already present from a trusted circuit; and Hewlett Packard Enterprise Development LP user guide, titled “Aruba 3810M/5400R Multicasting and Routing Guide for ArubaOS-Switch 16.10” discloses multiple DHCP relay agents within a path between a DHCP client and a DHCP server wherein, upon receiving a DHCP client request packet, a DHCP relay agent will add Option 82 if the incoming client request does not already have any Option 82 fields. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office Action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM C MCBETH whose telephone number is (571)270-0495. The examiner can normally be reached on Monday - Friday, 8:00AM - 4:30PM 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, Vivek Srivastava can be reached on 571-272-7304. 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. /WILLIAM C MCBETH/Examiner, Art Unit 2449 /VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
Read full office action

Prosecution Timeline

Show 1 earlier event
Oct 20, 2025
Non-Final Rejection mailed — §103
Jan 15, 2026
Applicant Interview (Telephonic)
Jan 15, 2026
Examiner Interview Summary
Jan 20, 2026
Response Filed
Apr 22, 2026
Final Rejection mailed — §103
Jul 22, 2026
Request for Continued Examination
Jul 26, 2026
Response after Non-Final Action
Aug 11, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12689683
CONTENT MANAGEMENT AND DELIVERY FOR A COMMUNICATION CHANNEL
2y 11m to grant Granted Jul 21, 2026
Patent 12676769
METHOD AND APPARATUS FOR ESTABLISHING CONNECTION, STORAGE MEDIUM AND SERVER
2y 8m to grant Granted Jul 07, 2026
Patent 12665821
SYSTEM AND METHOD TO DETERMINE CRITICALITY AND PRIORITIZE LIVE EVENTS TO IMPROVE PROACTIVE CUSTOMER SERVICE
3y 0m to grant Granted Jun 23, 2026
Patent 12659290
DOMAIN NAME SYSTEM QUERY HANDLING FOR AN EDGE APPLICATION SERVICE
2y 9m to grant Granted Jun 16, 2026
Patent 12652265
Application-Agnostic Puncturing of Network Address Translation (NAT) Services
2y 1m to grant Granted Jun 09, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
67%
Grant Probability
99%
With Interview (+57.1%)
2y 8m (~4m remaining)
Median Time to Grant
High
PTA Risk
Based on 294 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month