DETAILED ACTION
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 .
Response to Amendment
This Action is in response to communications filed on 08/11/2026.
Independent claims 1, 21 and 28 have been amended.
Applicant previously cancelled claims 9-20 (non-elected). There are no new claims.
Claims 1-8 and 21-32 are presented for examination, and remain pending in application.
Specification
The amendment to abstract of the specification was received on 08/11/2026. These amendments are acceptable, and as a result, the respective specification objections made in the non-final Office Action have been withdrawn.
Response to Arguments Regarding Claim Objections
In the non-final office Action mailed on 06/15/2026, Claim 1 was objected to because of minor informalities. In the response filed on 08/11/2026, applicant amends the claim to obviate the objection. These amendments are acceptable, and as a result, the respective claim objection made in the non-final Office Action has been withdrawn.
Response to Arguments Regarding Claim Rejections - 35 USC § 103
The Applicant's amendment/ arguments, see page 7-11 of REMARKS, filed 08/11/2026, with respect to Claim Rejections - 35 USC § 103 have been fully considered but they are not persuasive. In the response filed on 08/11/2026, applicant puts forth in substance that:
“Nowhere does Cuavas or Zeng, whether taken alone or in combination, disclose or suggest Applicant's aforementioned claimed features. The Office acknowledges that Cuavas is deficient with respect to embedding information relating to a ZTP failure in a DHCP message, but relies on Zeng to cure Cuavas' severe deficiencies. However, Zeng fails to disclose or suggest a network element (e.g., a DHCP client and/or ZTP client device) that (i) experiences a ZTP failure occurring after completion of a first DHCP negotiation and (ii) embeds information relating to that ZTP failure in a DHCP message for transmission in a subsequent DHCP negotiation, as required by Applicant's amended claim 1. Zeng is directed to early authentication in cable modem initialization, where authentication control is shifted to a CMTS, and where DHCP is one step in a DOCSIS initialization sequence. See Zeng, paragraphs [0035] and [0036]. In particular, the Office cites Zeng for allegedly teaching "insert information in DHCP packets to notify a provisioning server (back-end) that the subject cable modem has failed authentication." See Zeng, paragraph [0056]. Although Zeng discusses inserting information into DHCP packets in the context of cable modem authentication failure, it is in no way the same as or similar to a ZTP failure reporting mechanism in which a ZTP failure occurs after completion of a first DHCP negotiation and is then carried forward by embedding the ZTP failure information in a DHCP message for transmission in a subsequent DHCP negotiation.
Further, Cuavas is directed to fallout handling, validation, and ticketing associated with ZTP workflows for O-RAN components and cell sites. See Cuavas, paragraphs [0044] and [0045]. Cuavas appears to be completely silent with respect to a ZTP failure that occurs after completion of a first DHCP negotiation, where failure information is embedded in a DHCP message for transmission in a subsequent DHCP negotiation. Indeed, Cuavas is concerned with workflow error handling and remediation routing (e.g., tickets and restarting workflow stages), and not DHCP negotiation retry-loop signaling in which ZTP failure information is carried forward via a modified DHCP message used in a subsequent DHCP negotiation.
It is submitted that, even if Zeng's technique of inserting status information into DHCP packets can be incorporated into Cuavas's system, the resulting modification would merely label or annotate DHCP traffic with a generic failure status, and not require the specific claimed post-DHCP timing relationship and subsequent DHCP negotiation. Contending that Cuavas teaches obtaining failure information and Zeng teaches putting failure information into DHCP packets, and thus combining them is a predictable use of DHCP to communicate failure status, would be tenuous since Cuavas's failure information is workflow-validation/fallout data that is generated by an orchestration platform (i.e., tickets, responsible party, stage restart), and not client-side DHCP failure info obtained by the device after DHCP; and Zeng's DHCP insertion is a CMTS-controlled DOCSIS mechanism that is tied to authentication failure, and not a device embedding ZTP failure data after a completed DHCP negotiation for use in a subsequent DHCP negotiation. Indeed, the recited "after completion of a first DHCP negotiation" and "for transmission in a subsequent DHCP negotiation" in Applicant's amended claim 1 impose a temporal sequence (i.e., DHCP succeeds, then ZTP attempt fails, and then next DHCP negotiation carries the failure payload) that the references neither teach nor suggest.” (See page 7-10 of REMARKS, filed 08/11/2026).
Applicant’s arguments with respect to the new limitation “the ZTP failure occurring after completion of a first Dynamic Host Configuration Protocol (DHCP) negotiation” of independent claim 1 have been considered but are moot because the new ground of rejection does not rely on references to Cuavas and ZENG applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “DHCP negotiation retry-loop signaling”, “post-DHCP timing relationship and subsequent DHCP negotiation”, “client-side DHCP failure info”, “device embedding ZTP failure data”, “next DHCP negotiation carries the failure payload” and/or “temporal sequence (i.e., DHCP succeeds)”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In response to applicant's argument with respect to the new limitation “for transmission in a subsequent DHCP negotiation”, a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim. see MPEP sections 2115, 2103.I.C, and 2114.II.
“Furthermore, Peng and Fitzpatrick, which the Office applied against various of Applicant's dependent claims, do not appear to render Applicant's aforementioned claimed features obvious. Peng is generally directed to ZTP over unnumbered interfaces and is patentably distinct from Applicant's claimed subject matter. Fitzpatrick is directed to parallel transmission of multiple device configuration request messages (e.g., DHCP messages) to more efficiently obtain configuration information such as an IP address in unknown environments. See Fitzpatrick, paragraphs [0041], [0042], and [0064] to [0066]. Fitzpatrick appears to be completely silent with respect to embedding ZTP failure information responsive to a ZTP failure that occurs after completion of a first DHCP negotiation for transmission in a subsequent DHCP negotiation.
Given the foregoing, Applicant respectfully traverses the Office's contention, in the Office Action, that Applicant's independent claim 1 is obvious over Cuavas and Zeng. Applicant respectfully submits that independent claim 1 recites features and structure nowhere described or suggested in any of the cited references, whether taken alone or in any combination, and that one of ordinary skill in the art would not be inclined, let alone equipped, to arrive at Applicant's claimed subject matter based on these references. Thus, this independent claim is patentable over these references. Notice to this effect is earnestly requested.” (See page 10-11 of REMARKS, filed 08/11/2026).
Applicant argues that Peng is generally directed to ZTP over unnumbered interfaces and is patentably distinct from Applicant's claimed subject matter. However, examiner contends that Peng is still relevant as it deals with zero touch provisioning (ZTP) of a network element. More specifically, Peng discloses systems and methods that operate the ZTP NE to learn a routing configuration using a DHCP Relay Agent (RA) and derive the routing configuration accordingly, which is similar to concept that the invention is pertaining to as disclosed in Fig.1 of the application.
Peng is particularly relevant as it clearly teaches ZTP failure occurring after completion of a first DHCP negotiation during script processing for ZTP provisioning (see [0140]-[0141] in view of Fig.25). More specifically, Fig.25 pertains to script processing for ZTP provisioning. The step 702 in Fig.25 depicts phase 1 for DHCP negotiation, after which, an error occurs in step 704 when requesting script such as Python (Vendor.py) file.
Applicant's arguments for independent claims 21 and 28 appear to stem from the applicant's assertion that the combination of cited references fails to disclose the similarly recited limitations of claim 1. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the independent claim persists.
Applicant's arguments for the dependent claims appear to stem from the applicant's assertion that the combination of cited references fails to disclose all the limitations of respective independent claims. However, as set forth above, this assertion does not hold ground, and therefore, the current rejections of record for the dependent claims persist.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence in the application indicating obviousness or nonobviousness.
Claim(s) 1-8, and 21-32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cuavas et al. (hereinafter, Cuavas, US 20250132971 A1) in view of Peng (US 20200044917 A1) in view of ZENG (US 20080028437 A1).
Regarding claim 1, Cuavas discloses an apparatus (see [0032]-[0034] for apparatus; also see [0161]-[0163] in view of Fig.11:10; computer system 10 can be configured to implement various features and/or functions described herein; computer system can be considered a client), comprising:
one or more processors (see [0162] in view of Fig.11:73 “central processor”); and
a memory (see Fig.11:72 “system memory” and/or 79 “storage devices”) that stores executable instructions that, when executed, cause the one or more processors (see [0162]; central processor to control the execution of instructions from system memory or the storage device(s) ) to
obtain information relating to a zero-touch provisioning (ZTP) failure based upon an occurrence of the ZTP failure (see [0040]; fallout handling for ZTP operations may be implemented into different stages of different workflows; As used herein, “fallout” refers to an error/failure/issue, which may collectively be referred to herein as an “error” that occurs before, during, or after a workflow; A fallout may be any type of error that causes, or may cause, a process to not complete successfully; also see [0044]-[0045]; the fallout engine identifies the occurrence of one or more errors that occur before, during, or after a stage such as a pre-check validation, a deployment validation (e.g., during an execution of operations of the stage), or a post-check validation after execution of the stage. The fallout engine is configured to receive an indication of an error; information about the status of an error, what device(s) are affected by the error…what systems are involved in an error; also see [0085] disclosing a GUI depicting a success/failure of a ZTP operation).
Although Cuavas further discloses Dynamic Host Configuration Protocol (DHCP) service (see [0084]), Cuavas does not explicitly disclose that the ZTP failure occurring after completion of a first Dynamic Host Configuration Protocol (DHCP) negotiation, and embed the information in a DHCP message, resulting in a modified DHCP message, for transmission in a subsequent DHCP negotiation.
However, in an analogous art, Peng discloses an occurrence of the ZTP failure (see failure in Phase 2 of Fig.25:704; also see [0141]; In the second phase 704, the ZTP network element 12 sends a packet requesting to download the script from the configuration server 602 based on DHCP option 66/67. The source IP address of the packet is the “borrowed” IP address. The packet can reach the configuration server 602. As a response, the configuration server 602 sends the script file (e.g., Vendor.py) towards the ZTP network element 12 (i.e., the “borrowed” IP address). Since no intermediary network element knows the route to the “borrowed” IP address, the packet is dropped), the ZTP failure occurring after completion of a first Dynamic Host Configuration Protocol (DHCP) negotiation (see [0140]-[0141]; in view of Fig.25:702 depicting phase 1- DHCP negotiation; ZTP NE initiates DHCP negotiation; the DHCP server 42 assigns an IP address to the unnumbered interface and the address can be used as the “borrowed” IP address of the interface; it is assumed that the DHCP server 42 assigns an IP address to the ZTP network element 12 successfully and the address is configured as the “borrowed” IP address of the interface).
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 teachings of Peng with Cuavas to obtain information relating to a ZTP failure occurring after completion of a first Dynamic Host Configuration Protocol (DHCP) negotiation.
One of ordinary skill in the art would have been motivated to provide operators with the maximal flexibility to choose where and when to download a configuration or software image through any protocol and security policy they choose, and to enable the communication to be established on the DCN for ZTP configuration such as via a script (Peng: [0039]), for automatic configuration of IP hosts (Peng: [0055]).
Cuavas-Peng does not explicitly disclose embed the information in a DHCP message, resulting in a modified DHCP message, for transmission in a subsequent DHCP negotiation.
However, in an analogous art, ZENG discloses embed the information in a Dynamic Host Configuration Protocol (DHCP) message, resulting in a modified DHCP message, for transmission in a subsequent DHCP negotiation (see [0056]; insert information in DHCP packets to notify a provisioning server (back-end) that the subject cable modem has failed authentication).
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 teachings of ZENG with Cuavas-Peng to embed the information in a DHCP message, resulting in a modified DHCP message, for transmission in a subsequent DHCP negotiation.
One of ordinary skill in the art would have been motivated to notify a provisioning server (back-end) regarding a failure (ZENG: [0056]).
Regarding claim 2, Cuavas (modified by Peng and ZENG) discloses the method of claim 1, as set forth above. Cuavas further discloses wherein the apparatus comprises a DHCP client (see [0161]-[0163] in view of Fig.11:10; computer system 10 can be configured to implement various features and/or functions described herein; computer system can be considered a client; also see [0084] regarding devices connected to the core network using DHCP service), and wherein one or more of the obtaining and the embedding are performed by the DHCP client (see [0044]-[0045]; the fallout engine identifies the occurrence of one or more errors that occur before, during, or after a stage such as a pre-check validation, a deployment validation (e.g., during an execution of operations of the stage), or a post-check validation after execution of the stage. The fallout engine is configured to receive an indication of an error; information about the status of an error, what device(s) are affected by the error…what systems are involved in an error; also see [0040]; fallout handling for ZTP operations; As used herein, “fallout” refers to an error/failure/issue, which may collectively be referred to herein as an “error” that occurs before, during, or after a workflow).
In addition, ZENG also teaches apparatus comprises a DHCP client (see [0057]; implied from disclosed client DHCPv4 messages and Option 16 in client DHCPv6 messages).
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 teachings of ZENG with Cuavas-Peng so that the apparatus comprises a DHCP client, and wherein one or more of the obtaining and the embedding are performed by the DHCP client.
One of ordinary skill in the art would have been motivated to notify a provisioning server (back-end) regarding a failure (ZENG: [0056]).
Regarding claim 3, Cuavas (modified by Peng and ZENG) discloses the method of claim 1, as set forth above. Cuavas further discloses wherein the apparatus comprises a ZTP client (see [0161]-[0163] in view of Fig.11:10; computer system 10 can be configured to implement various features and/or functions described herein; computer system can be considered a client; also see [0040]; fallout handling for ZTP operations), and wherein one or more of the obtaining and the embedding are performed by the ZTP client (see [0044]-[0045]; the fallout engine identifies the occurrence of one or more errors that occur before, during, or after a stage such as a pre-check validation, a deployment validation (e.g., during an execution of operations of the stage), or a post-check validation after execution of the stage. The fallout engine is configured to receive an indication of an error; information about the status of an error, what device(s) are affected by the error…what systems are involved in an error; also see [0040]; fallout handling for ZTP operations; As used herein, “fallout” refers to an error/failure/issue, which may collectively be referred to herein as an “error” that occurs before, during, or after a workflow).
Regarding claim 4, Cuavas (modified by Peng and ZENG) discloses the method of claim 1, as set forth above. Peng further discloses transmit the modified DHCP message to a DHCP Relay Agent (RA) (see [0131]-[0132]; receiving a DHCP packet with option 82 data… modifying addressing and the option 82 data of the DHCP packet… and forwarding the modified DHCP packet; The receiving from the network element and the forwarding to the network element are performed with a second DHCP Relay Agent between the network element and the first DHCP Relay Agent).
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 teachings of Peng with Cuavas and ZENG to transmit the modified DHCP message to a DHCP Relay Agent (RA).
One of ordinary skill in the art would have been motivated to provide operators with the maximal flexibility to choose where and when to download a configuration or software image through any protocol and security policy they choose, and to enable the communication to be established on the DCN for ZTP configuration such as via a script (Peng: [0039]), for automatic configuration of IP hosts (Peng: [0055]).
Regarding claim 5, Cuavas (modified by Peng and ZENG) discloses the method of claim 1, as set forth above. Cuavas further discloses wherein the information comprises a client identifier, a vendor class identifier, information regarding one or more errors that resulted in the ZTP failure, or a combination thereof (see [0044]-[0045]; the fallout engine identifies the occurrence of one or more errors that occur before, during, or after a stage such as a pre-check validation, a deployment validation (e.g., during an execution of operations of the stage), or a post-check validation after execution of the stage. The fallout engine is configured to receive an indication of an error; information about the status of an error, what device(s) are affected by the error…what systems are involved in an error; also see [0040]; fallout handling for ZTP operations; As used herein, “fallout” refers to an error/failure/issue, which may collectively be referred to herein as an “error” that occurs before, during, or after a workflow).
Regarding claim 6, Cuavas (modified by Peng and ZENG) discloses the method of claim 1, as set forth above. Peng further discloses wherein the DHCP message comprises a DHCPv4 Discover message (see [0070]; the network element 12-1 sends a DHCP discovery) or a DHCPv6 Solicit message.
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 teachings of Peng with Cuavas and ZENG so that the DHCP message comprises a DHCPv4 Discover message or a DHCPv6 Solicit message.
One of ordinary skill in the art would have been motivated to provide operators with the maximal flexibility to choose where and when to download a configuration or software image through any protocol and security policy they choose, and to enable the communication to be established on the DCN for ZTP configuration such as via a script (Peng: [0039]), for automatic configuration of IP hosts (Peng: [0055]).
Regarding claim 7, Cuavas (modified by Peng and ZENG) discloses the method of claim 1, as set forth above. Peng further discloses wherein the embedding comprises embedding at least a portion of the information in a Vendor-specific information option in the DHCP message (see [0058]; extracting the configuration from the configuration file and inserting it into a DHCP packet with option 43 – Vendor Specific information).
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 teachings of Peng with Cuavas and ZENG so that the embedding comprises embedding at least a portion of the information in a Vendor-specific information option in the DHCP message.
One of ordinary skill in the art would have been motivated to provide operators with the maximal flexibility to choose where and when to download a configuration or software image through any protocol and security policy they choose, and to enable the communication to be established on the DCN for ZTP configuration such as via a script (Peng: [0039]), for automatic configuration of IP hosts (Peng: [0055]).
Regarding claim 8, Cuavas (modified by ZENG) discloses the method of claim 1, as set forth above. Cuavas further discloses wherein the instructions, when executed, further cause the one or more processors to detect the ZTP failure, and wherein the obtaining is responsive to the detecting (see [0044]-[0045]; the fallout engine identifies the occurrence of one or more errors that occur before, during, or after a stage such as a pre-check validation, a deployment validation (e.g., during an execution of operations of the stage), or a post-check validation after execution of the stage. The fallout engine is configured to receive an indication of an error; information about the status of an error, what device(s) are affected by the error…what systems are involved in an error; also see [0040]; fallout handling for ZTP operations; As used herein, “fallout” refers to an error/failure/issue, which may collectively be referred to herein as an “error” that occurs before, during, or after a workflow).
As for Claim(s) 21 and 28, the claims list all the same elements of claim 1, but in a non-transitory machine-readable medium, comprising executable instructions executed by a processing system of an apparatus (see Cuavas [0005]) including a processor (see Cuavas [0005]); and a method form to carry out the steps of claim 1, rather than the apparatus form. Therefore, the supporting rationale of the rejection to claim 1 applies equally as well to claims 21 and 28.
As for Claim 22-23 and 29-30, the claims depend on claims 21 and 28 respectively, but do not teach or further define over the limitations in claims 2-3 respectively. Therefore, claims 22-23 are rejected for the same reasons as set forth in claims 2-3 respectively.
As for Claim 24 and 31, the claims depend on claims 21 and 28 respectively, but do not teach or further define over the limitations in claim 4. Therefore, claims 24 and 31 are also rejected for the same reasons as set forth in claim 4.
As for Claim 25 and 32, the claims depend on claims 21 and 28 respectively, but do not teach or further define over the limitations in claim 5. Therefore, claims 25 and 32 are also rejected for the same reasons as set forth in claim 5.
As for Claim 26, the claim depends on claim 21, but does not teach or further define over the limitations in claim 6. Therefore, claim 26 is also rejected for the same reasons as set forth in claim 6.
As for Claim 27, the claim depends on claim 21, but does not teach or further define over the limitations in claim 7. Therefore, claim 27 is also rejected for the same reasons as set forth in claim 7.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mutnuru et al. (US 20220217052 A1) discloses ZTP uses DHCP internally.
Peng (US 20180287873 A1) teaches ZTP script to provision network elements over unnumbered interfaces using DHCP packet with option 43 (Vendor Specific information).
Conclusion
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 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kamal B Divecha can be reached at 571-272-5863. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SANDARVA KHANAL/ Primary Examiner, Art Unit 2453
