CTFR 18/527,513 CTFR 79446 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. DETAILED ACTION Response to Amendment This office action is in response to applicant’s amendment filed, 02 February 2026 August 2025, of application filed, with the above serial number, on 04 December 2023 in which claims 2, 11 have been amended. Claims 1-20 are pending in the application. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim( s) 1-3, 8, 10-12, 17, 19 i s/are rejected under 35 U.S.C. 103 as being unpatentable over D ickinson (hereinafter “Dickinson”, 10,243,920) in view of Mason et al (hereinafter “Mason”, 2010/0306391). A s per Claim 1, Dickinson discloses a method performed by a Dynamic Host Configuration Protocol (DHCP) server in a network access point for configuring one or more communication devices communicatively coupled to a local area network, comprising: determining that one or more network configuration parameters have been updated (at least col. 6:60-7:34; DHCP server 130 in this example issues a RECONFIGURE message to Instance X. The RECONFIGURE message informs the instance that the DHCP server has new or updated configuration parameters, and the instance is to initiate a REQUEST/REPLY transaction with the DHCP server 130 in order to receive the updated information), asynchronously sending, in response to the one or more network configuration parameters having been updated, a network configuration parameters update to one or more communication devices attached to the local area network (at least col. 6:60-7:34; DHCP server 130 in this example issues a RECONFIGURE message to Instance X. The RECONFIGURE message informs the instance that the DHCP server has new or updated configuration parameters, and the instance is to initiate a REQUEST/REPLY transaction with the DHCP server 130 in order to receive the updated information. Instance X then returns a REQUEST message to the DHCP server 130 requesting the update configuration information); and communicating with the attached communication devices using the updated one or more network configuration parameters (at least col. 6:60-7:34; instance using new parameters including at least the address and lease time). Dickinson fails to explicitly disclose wherein the updated one or more network configuration parameters comprise: an updated maximum transmission unit (MTU) network parameter; updated Session Initiation Protocol (SIP) server information; or any combination thereof; and the network configuration parameters update comprising the updated one or more network configuration parameters. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Mason. Mason discloses, in an analogous art, devices retrieving updated MTU values when they expire from a repository that is designated by a DHCP server (at least paragraph 41-43). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Mason’s MTU configuration with Dickinson, as Mason teaches it being well known that devices use the maximum MTU they can accept for communication (at least paragraph 1-4) and a host typically has a default MTU, but if that is empty or not known as a host is brought online, Mason teaches the DHCP process configuring the host with a network configuration, address, etc and MTU configuration also being a parameter to load from the DHCP server. This would be beneficial for all devices in a local network that as they are configured initially on the network to have their MTU be set to the maximum that devices on that network can handle, and if that updates, updating the clients in the network from the gateway of Dickinson as a network configuration parameter change that affects all clients. As per Claim 2. The method of claim 1, wherein the updated one or more network configuration parameters further comprise one or more of V4 Internet Protocol (IP), Netmask, lease time, time zone, or domain name system (DNS) server (at least col. 6:60-7:34; DHCP server 130 issues a REPLY message to the instance, and the REPLY message includes two IP addresses—the originally assigned IP address of 2601:1F::1 and a newly assigned IP address of 2601:1F::1:3. In this example, the DHCP server 130 also has included a valid lifetime for each IP address of 7 days). As per Claim 3. The method of claim 1, further comprising receiving the updated MTU network parameter; and determining that the updated MTU network parameter requires a change to one or more communication devices. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Mason. Mason discloses, in an analogous art, MTU information being loaded and updated from DHCP transmissions (at least paragraph 41-43). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Mason’s MTU configuration with Dickinson as Mason teaches it being well known that devices use the maximum MTU they can accept for communication (at least paragraph 1-4) and a host typically has a default MTU, but if that is empty or not known as a host is brought online, Mason teaches the DHCP process configuring the host with a network configuration, address, etc and MTU configuration also being a parameter to load from the DHCP server. This would be beneficial for all devices in a local network that as they are configured initially on the network to have their MTU be set to the maximum that devices on that network can handle, and if that updates, updating the clients in the network from the gateway of Dickinson as a network configuration parameter change that affects all clients. As per Claim 8. The method of claim 1, wherein the network configuration parameters update is sent using a connection between the DHCP server and the one or more communication devices attached to the local area network, the connection comprising at least one of a wireless communication link, an Ethernet link, or a universal serial bus (USB) link (at least col. 12:61-67). Claims 10-12, 17, 19 do not, in substance, add or define any additional limitations over claims 1-3, 8 and therefore are rejected for similar reasons, supra . 07-21-aia AIA Claim (s) 4, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dickinson in view of Mason, further in view of Ono et al (hereinafter “Ono”, 2006/0271664) . Dickinson/Mason fails to disclose further comprising receiving the updated SIP server information from a remote server. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Ono. Ono discloses a SIP server and DHCP server communicating and exchanging a SIP URI that is updated and transmitted to a terminal in a lease response message (at least paragraph 48-51). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Ono’s SIP messaging with Dickinson/Mason as Ono teaches in the background par. 5-6 that such a SIP URI/IP correspondence would be beneficial in order to allowing the client calls to be received as the client address changes, for example, the SIP server will continue to be able to communicate with the phone or vice versa, if the SIP URI changes due to a DHCP change, the phone will be updated with the new configuration . 07-21-aia AIA Claim (s) 5, 6, 7, 9, 14-16, 18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dickinson in view of Mason, further in view of Chanda et al (hereinafter “Chanda”, 2015/0052262) . As per Claim 5. Dickinson/Mason fails to explicitly disclose wherein asynchronously sending the network configuration parameters update to communication devices attached to the local area network comprises sending a single command to all communication devices attached to the local area network. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Chanda. Chanda discloses, in an analogous DHCP art, the DHCP implementation follows the standard discovery/offer/request/acknowledgement multi-stage process whereby the DHCP server responds by broadcasting a DHCP offer message that includes an offered IP address and configuration options as well as broadcasts an acknowledgment that the IP address has been assigned to that VM (at least Chandra paragraph 44, 131-138, 158, 166-170). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Chanda’s DHCP configuration with Dickinson/Mason, as Chanda discloses the standard process of IP configuration with DHCP being that the server sends one command broadcasted to all nodes for the device requesting to actually use the command and the other nodes discarding as the broadcast is not intended for them, this ensures all nodes receive the configuration assignment and be aware of the configuration changes. As per Claim 6. The method of claim 5, wherein the network configuration parameters update comprises a DHCP ACK message (at least Chandra paragraph 44, 131-138, 158, 166-170; configuration file generator first defines the option in the configuration file along with an option code, then defines for the DHCP module exactly how to specify the desired value in a DHCP offer or acknowledgment packet). As per Claim 7. Dickinson/Mason fails to explicitly disclose wherein asynchronously sending the network configuration parameters update comprises sending a broadcast message for reception by all communication devices attached to the local area network. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Chanda. Chanda discloses, in an analogous DHCP art, the DHCP implementation follows the standard discovery/offer/request/acknowledgement multi-stage process whereby the DHCP server responds by broadcasting a DHCP offer message that includes an offered IP address and configuration options as well as broadcasts an acknowledgment that the IP address has been assigned to that VM (at least Chandra paragraph 44, 131-138, 158, 166-170). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Chanda’s DHCP configuration with Dickinson/Mason as Chanda discloses the standard process of IP configuration with DHCP being that the server sends one command broadcasted to all nodes for the device requesting to actually use the command and the other nodes discarding as the broadcast is not intended for them, this ensures all nodes receive the configuration assignment and be aware of the configuration changes. As per Claim 9. Dickinson/Mason fails to explicitly disclose wherein asynchronously sending a network configuration parameters update to one or more communication devices attached to the local area network comprises: sending a network message configured to cause the one or more communication devices attached to the local area network to initiate a Discover, Offer, Request and Acknowledgement (DORA) connection process with the DHCP server; and responding to the DORA connection process to asynchronously send the network configuration parameters update to the one or more communication devices attached to the local area network. However, the use and advantages for using such a system was well known to one skilled in the art before the effective filing date of the claimed invention as evidenced by the teachings of Chanda. Chanda discloses, in an analogous DHCP art, the DHCP implementation follows the standard discovery/offer/request/acknowledgement multi-stage process whereby the DHCP server responds by broadcasting a DHCP offer message that includes an offered IP address and configuration options as well as broadcasts an acknowledgment that the IP address has been assigned to that VM (at least Chandra paragraph 44, 131-138, 158, 166-170). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the use of Chanda’s DHCP configuration with Dickinson/Mason as Chanda discloses the standard process of IP configuration with DHCP being that the server sends one command broadcasted to all nodes for the device requesting to actually use the command and the other nodes discarding as the broadcast is not intended for them, this ensures all nodes receive the configuration assignment and be aware of the configuration changes. Claims 14-16, 18, 20 do not, in substance, add or define any additional limitations over claim 5-7, 9 and therefore are rejected for similar reasons, supra . Response to Arguments 07-37 AIA Applicant's arguments filed 02 February 2026 have been fully considered but they are not persuasive. Applicant argues that Mason does disclose prior amended claim 1 limitations of A [DHCP] server…sending, in response to the one or more network configuration parameters having been updated , a network configuration parameters update 07-37-13 AIA In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller , 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Applicant argues Dickinson individually on p. 8, and then argues Mason individually on p. 8-11. Regarding the prior argument wherein the response indicated the DNS server was in the preamble, the DNS server was a typo with the DHCP server having been recited in the preamble: Applicant’s arguments rely on language solely recited in preamble recitations in claim(s) 1. When reading the preamble in the context of the entire claim, the recitation DHCP server is not limiting because the body of the claim describes a complete invention and the language recited solely in the preamble does not provide any distinct definition of any of the claimed invention’s limitations. Thus, the preamble of the claim(s) is not considered a limitation and is of no significance to claim construction. See Pitney Bowes, Inc. v. Hewlett-Packard Co. , 182 F.3d 1298, 1305, 51 USPQ2d 1161, 1165 (Fed. Cir. 1999). See MPEP § 2111.02. Dickinson is relied on for teaching a DNS server sending , in response to network configuration parameters being updated , a reconfigure message to devices (at least col. 6:60-7:34). Applicant argues that Dickinson’s teachings relate to a newly assigned IP address and the reconfigure message is not sent in response to any combination of an updated MTU network parameter or updated SIP server information. Mason is relied on for any combination of an updated MTU network parameter or updated SIP server information. Mason is only relied on for updated MTU parameters to be sent. Applicant continues to argue only paragraph 41 of Mason and is not responsive to the rejection’s mapping of par. 41-43 . Examiner cites par. 41-42 for context, with par. 43 in particular describing that MTU values expire and have a TTL, after which “the values must be updated because they are no longer valid”. Thus, at least the source host 202 would be sent new MTU values by the central repository 218 as instructed and in cooperation with the DNS server. The DNS is involved with the network parameter(s) update, however, Dickinson is relied on and discloses that the DHCP server specifically send the parameters and it would align and be obvious with Mason that the Mason central repository may be the DHCP server the device is already in communication with for configuration parameters. Applicant additionally has not responded to the rejections in view of Ono or Chanda. Examiner requests the consideration and reply to Mason par. 43 and Ono and Chanda for the next response. Conclusion 07-39 AIA THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action. The prior art made of record and not relied upon considered pertinent to applicant's disclosure is indicated in PTO form 892. Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY TODD whose telephone number is (303)297-4763. The examiner can normally be reached 8:30-5 MST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Nicholas Taylor can be reached on 571-272-3889. 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 http://pair-direct.uspto.gov. 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. /GREGORY TODD/ Primary Examiner, Art Unit 2443 Application/Control Number: 18/527,513 Page 2 Art Unit: 2443 Application/Control Number: 18/527,513 Page 3 Art Unit: 2443 Application/Control Number: 18/527,513 Page 4 Art Unit: 2443 Application/Control Number: 18/527,513 Page 5 Art Unit: 2443 Application/Control Number: 18/527,513 Page 6 Art Unit: 2443 Application/Control Number: 18/527,513 Page 7 Art Unit: 2443 Application/Control Number: 18/527,513 Page 8 Art Unit: 2443 Application/Control Number: 18/527,513 Page 9 Art Unit: 2443 Application/Control Number: 18/527,513 Page 10 Art Unit: 2443 Application/Control Number: 18/527,513 Page 11 Art Unit: 2443
Prosecution Insights