DETAILED ACTION
This application has been examined. Claims 1-17,19,21-22 are pending. Claims 18,20 are cancelled.
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 .
Making Final
Applicant's arguments filed 8/19/2026 have been fully considered but they are moot in view of the new grounds for rejection.
The claim amendments regarding -- ‘wherein the hardware information is obtained from an authentication packet that is received by the network device’ -- clearly change the literal scope of the independent and dependent claims and/or the range of equivalents for such claims. The said amendments alter the scope of the claims but do not overcome the disclosure by the prior art as shown below.
The Examiner is presenting new grounds for rejection as necessitated by the claim amendments and is thus making this action FINAL.
Response to Arguments
Applicant's arguments filed 8/19/2026 have been fully considered but they are moot in view of the new grounds for rejection.
Sheth Figure 5,Paragraph 91 disclosed pre-configuration attestation of network devices.
Peng-Sheth-Kale disclosed (re. Claim 1) wherein the hardware information is obtained from an authentication packet that is received by the network device (Sheth-Paragraph 107, if at S604, destination node 116 determines that the result of verification at S602 indicates that the source node 202 is verified, then at S608, destination node 116 sends the MUD fetch URL… a MUD manager (can reside on a DHCP server or can be a separate server) receives the attestation information (verification or integrity information) of source node 202 (IoT), in response to which MUD manager fetches the MUD file from a MUD file server to the destination node 115), Peng- Paragraph 51, a DHCP relay agent is employed as a mediator to forward DHCP packets between clients and servers… network element 12 is identified by the identity of the DHCP Relay Agent 50 as well as the local port connecting to the network element 12. The DHCP Relay Agent 50 can report such information via option 82 along with the DHCP packets sent by the network element 12 to the DHCP server 42 so that the DHCP server 42 can reply with the specific configuration to the network element 12 in terms of the information.)
Priority
This application claims benefits of priority from Foreign Application CN202010519677.1 (CHINA) filed June 9, 2020.
The effective date of the claims described in this application is June 9, 2020.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-17,19,21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Peng (USPGPUB 2020/0044917) further in view of Sheth (USPGPUB 2020/0322356) further in view of Kale (USPGPUB 2019/0260751)
Regarding Claim 1
Peng Paragraph 51 disclosed wherein network elements 12 send out a request through DHCP to the DHCP server 42 to obtain the location of its configuration. The network element 12 then downloads and installs the configuration.
Peng Figure 7,Paragraph 67,Paragraph 70-71 disclosed wherein the network element 12-1 negotiates with the DHCP server 42 to obtain the configuration information through, for example, option 3 for receiving a default route, option 33 for receiving a static route, option 60 for identifying vendor type when communicating with DHCP servers, option 61 for identifying a DHCP client and configuration, option 66 for the address of the FTP server 44, and option 67 for the directory on the FTP server 44 that contains the configuration or command files.
Peng disclosed (re. Claim 1) method for obtaining a network address of an LTP/ZTP configuration file, wherein the method comprises:
obtaining, by a network device, (Peng-Figure 7,Paragraph 67,Paragraph 70-71, the network element 12-1 negotiates with the DHCP server 42 to obtain the configuration information ) hardware information of a terminal (Peng-Paragraph 77, A type/category of the network element 12-1 can be provided by DHCP option 60, and a unique client identifier can be provided via option 61. For example, the unique client identifier can be a serial number,Paragraph 51, network element 12 is identified by the identity of the DHCP Relay Agent 50 as well as the local port connecting to the network element 12. The DHCP Relay Agent 50 can report such information via option 82 along with the DHCP packets sent by the network element 12 to the DHCP server 42 so that the DHCP server 42 can reply with the specific configuration to the network element 12 in terms of the information.)
during initiation of authentication of the terminal, wherein the hardware information is at least one of an identifier of a first access device of the terminal, an access port number of the terminal, or a terminal type; (Peng-Paragraph 77, A type/category of the network element 12-1 can be provided by DHCP option 60, and a unique client identifier can be provided via option 61. For example, the unique client identifier can be a serial number,Paragraph 51, network element 12 is identified by the identity of the DHCP Relay Agent 50 as well as the local port connecting to the network element 12. The DHCP Relay Agent 50 can report such information via option 82 along with the DHCP packets sent by the network element 12 to the DHCP server 42 so that the DHCP server 42 can reply with the specific configuration to the network element 12 in terms of the information.) and
obtaining, by the network device, a network address of an LTP/ZTP configuration file of the terminal based on the hardware information of the terminal.(Peng-Paragraph 137, The DHCP requests, preferably, include a network element 12 identifier number that can be used on the DHCP server 42 to correlate the script with the network element 12. The DHCP response then contains a Uniform Resource Locator (URL) to a script that the network element 12 should download and execute in the execution environment.)
While Peng substantially disclosed the claimed invention Peng does not disclose (re. Claim 1) initiation of authentication of the terminal.
While Peng substantially disclosed the claimed invention Peng does not disclose (re. Claim 1) obtaining a network address of a manufacturer usage description (MUD) file.
Sheth Figure 5,Paragraph 91 disclosed pre-configuration attestation of network devices.
Sheth Paragraph 93-94 disclosed wherein upon receiving the first request from the source node, destination node 116 sends a second request to the source node 202 for attestation information (information such as a canary stamp, a hardware finger print (derived from SUDI for example) and PCR values that can be used to verify the integrity of source node 202. At S504, destination node 116 receives the attestation information from source node 202.
Sheth disclosed (re. Claim 1) initiation of authentication of the terminal.( Sheth-Paragraph 93-94,upon receiving the first request from the source node, destination node 116 sends a second request to the source node 202 for attestation information (information such as a canary stamp, a hardware finger print (derived from SUDI for example) and PCR values that can be used to verify the integrity of source node 202. At S504, destination node 116 receives the attestation information from source node 202.)
Sheth disclosed (re. Claim 1) obtaining a network address of a manufacturer usage description (MUD) file.(Sheth-Paragraph 107, if at S604, destination node 116 determines that the result of verification at S602 indicates that the source node 202 is verified, then at S608, destination node 116 sends the MUD fetch URL… a MUD manager (can reside on a DHCP server or can be a separate server) receives the attestation information (verification or integrity information) of source node 202 (IoT), in response to which MUD manager fetches the MUD file from a MUD file server to the destination node 115)
Peng and Sheth are analogous art because they present concepts and practices regarding device configuration. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Sheth into Peng. The motivation for the said combination would have been to validate or verify that traffic has traversed a specific set of nodes and that such nodes are trusted and uncompromised.(Sheth-Paragraph 29)
Peng-Sheth disclosed (re. Claim 1) obtaining, based on a correspondence between the hardware information of the terminal and a second network address, the second network address corresponding to the hardware information of the terminal’ .(Peng-Paragraph 51- network element 12 is identified by the identity of the DHCP Relay Agent 50 as well as the local port connecting to the network element 12. The DHCP Relay Agent 50 can report such information via option 82 along with the DHCP packets sent by the network element 12 to the DHCP server 42 so that the DHCP server 42 can reply with the specific configuration to the network element 12 in terms of the information,Paragraph 137, The DHCP requests, preferably, include a network element 12 identifier number that can be used on the DHCP server 42 to correlate the script with the network element 12. The DHCP response then contains a Uniform Resource Locator (URL) to a script that the network element 12 should download and execute in the execution environment.)
‘using the second network address corresponding to the hardware information of the terminal as the first network address of the MUD file of the terminal, wherein the correspondence between the hardware information of the terminal and the second network address is pre-configured in the network device (Peng-Paragraph 137, The DHCP requests, preferably, include a network element 12 identifier number that can be used on the DHCP server 42 to correlate the script with the network element 12. The DHCP response then contains a Uniform Resource Locator (URL) to a script that the network element 12 should download and execute in the execution environment.)
While Peng-Sheth substantially disclosed the claimed invention Peng-Sheth does not disclose (re. Claim 1) automatically obtaining, by the network device, a first network address of a manufacturer usage description (MUD) file of the terminal without receiving the first network address of the MUD file from the terminal
While Peng-Sheth substantially disclosed the claimed invention Peng-Sheth does not disclose (re. Claim 1) wherein the MUD file correspondence is pre-configured in the network device
Kale Paragraph disclosed wherein the MUD controller 14 may be implemented on the access switch 22.
Kale disclosed (re. Claim 1) automatically obtaining, by the network device, a first network address of a manufacturer usage description (MUD) file of the terminal without receiving the first network address of the MUD file from the terminal , wherein the MUD file correspondence is pre-configured in the network device (Kale-Paragraph 28, The MUD controller 14 is operative to obtain (block 40) the MUD profile of the IoT device 18 from the MUD server 12.)
Peng and Sheth are analogous art because they present concepts and practices regarding device configuration. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Sheth into Peng. The motivation for the said combination would have been to enable the manufacturer of the IoT device 18 to update the MUD profile of the IoT device 18 to reflect new security risks and ensure that the MUD controller 14 is in possession of the updated MUD profile.(Kale-Paragraph 36)
Peng-Sheth-Kale disclosed (re. Claim 1) wherein the hardware information is obtained from an authentication packet that is received by the network device (Sheth-Paragraph 107, if at S604, destination node 116 determines that the result of verification at S602 indicates that the source node 202 is verified, then at S608, destination node 116 sends the MUD fetch URL… a MUD manager (can reside on a DHCP server or can be a separate server) receives the attestation information (verification or integrity information) of source node 202 (IoT), in response to which MUD manager fetches the MUD file from a MUD file server to the destination node 115), Peng- Paragraph 51, a DHCP relay agent is employed as a mediator to forward DHCP packets between clients and servers… network element 12 is identified by the identity of the DHCP Relay Agent 50 as well as the local port connecting to the network element 12. The DHCP Relay Agent 50 can report such information via option 82 along with the DHCP packets sent by the network element 12 to the DHCP server 42 so that the DHCP server 42 can reply with the specific configuration to the network element 12 in terms of the information.)
Regarding Claim 6
Claim 6 (re. network device) recites substantially similar limitations as Claim 1. Claim 6 is rejected on the same basis as Claim 1.
Regarding Claim 11
Claim 11 (re. non-transitory computer readable storage medium) recites substantially similar limitations as Claim 1. Claim 11 is rejected on the same basis as Claim 1.
Regarding Claim 2,7,12
Peng-Sheth-Kale disclosed (re. Claim 2,7,12) wherein the network device is a controller, (Peng- Paragraph 51, a DHCP relay agent is employed as a mediator to forward DHCP packets between clients and servers… network element 12 is identified by the identity of the DHCP Relay Agent 50 as well as the local port connecting to the network element 12. The DHCP Relay Agent 50 can report such information via option 82 along with the DHCP packets sent by the network element 12 to the DHCP server 42 so that the DHCP server 42 can reply with the specific configuration to the network element 12 in terms of the information.)
and wherein after obtaining the network address of the MUD file of the terminal, (Sheth-Paragraph 107, if at S604, destination node 116 determines that the result of verification at S602 indicates that the source node 202 is verified, then at S608, destination node 116 sends the MUD fetch URL… a MUD manager (can reside on a DHCP server or can be a separate server) receives the attestation information (verification or integrity information) of source node 202 (IoT), in response to which MUD manager fetches the MUD file from a MUD file server to the destination node 115) the method further comprises obtaining, by the network device, the MUD file from a MUD file server based on the network address of the MUD file. (Sheth-Paragraph 107, if at S604, destination node 116 determines that the result of verification at S602 indicates that the source node 202 is verified, then at S608, destination node 116 sends the MUD fetch URL… a MUD manager (can reside on a DHCP server or can be a separate server) receives the attestation information (verification or integrity information) of source node 202 (IoT), in response to which MUD manager fetches the MUD file from a MUD file server to the destination node 115)
Regarding Claim 3,8,13
Peng-Sheth-Kale disclosed (re. Claim 3,8,13) wherein obtaining the hardware information of the terminal during the initiation of authentication comprises
receiving, by the network device, an authentication packet from the access device during the initiation of authentication, and wherein the authentication packet comprises the hardware information of the terminal. (Peng- Paragraph 51, a DHCP relay agent is employed as a mediator to forward DHCP packets between clients and servers… network element 12 is identified by the identity of the DHCP Relay Agent 50 as well as the local port connecting to the network element 12. The DHCP Relay Agent 50 can report such information via option 82 along with the DHCP packets sent by the network element 12 to the DHCP server 42 so that the DHCP server 42 can reply with the specific configuration to the network element 12 in terms of the information.)
Regarding Claim 4,9,14
Peng-Sheth-Kale disclosed (re. Claim 4,9,14) wherein after obtaining the, MUD file, (Sheth-Paragraph 107, if at S604, destination node 116 determines that the result of verification at S602 indicates that the source node 202 is verified, then at S608, destination node 116 sends the MUD fetch URL… a MUD manager (can reside on a DHCP server or can be a separate server) receives the attestation information (verification or integrity information) of source node 202 (IoT), in response to which MUD manager fetches the MUD file from a MUD file server to the destination node 115) the method further comprises generating, by the network device, a network policy based on the MUD file.(Peng-Paragraph 144, After the first phase 702, there is an intermediate phase before the second phase 704. The intermediate phase is to set up a routing configuration for the unnumbered interface 760.)
Regarding Claim 5,10,15
Peng-Sheth-Kale disclosed (re. Claim 5,10,15) wherein the network device is a second access device, and wherein after obtaining the network address of the MUD file of the terminal, (Sheth-Paragraph 107, if at S604, destination node 116 determines that the result of verification at S602 indicates that the source node 202 is verified, then at S608, destination node 116 sends the MUD fetch URL… a MUD manager (can reside on a DHCP server or can be a separate server) receives the attestation information (verification or integrity information) of source node 202 (IoT), in response to which MUD manager fetches the MUD file from a MUD file server to the destination node 115) the method further comprises sending, by the network device, the network address of the MUD file to a controller to enable the controller to obtain the MUD file from a MUD file server based on the network address of the MUD file. (Peng- Paragraph 51, a DHCP relay agent is employed as a mediator to forward DHCP packets between clients and servers… network element 12 is identified by the identity of the DHCP Relay Agent 50 as well as the local port connecting to the network element 12. The DHCP Relay Agent 50 can report such information via option 82 along with the DHCP packets sent by the network element 12 to the DHCP server 42 so that the DHCP server 42 can reply with the specific configuration to the network element 12 in terms of the information.)
Regarding Claim 16,17,19
Peng-Sheth-Kale disclosed (re. Claim 16,17,19) wherein the network address of the MUD file is a uniform resource locator (URL) of the MUD file. (Peng-Paragraph 137, The DHCP requests, preferably, include a network element 12 identifier number that can be used on the DHCP server 42 to correlate the script with the network element 12. The DHCP response then contains a Uniform Resource Locator (URL) to a script that the network element 12 should download and execute in the execution environment,Paragraph 138, the network element 12 downloads the script based on the URL to a script specified in the DHCP response. The URL can be specified in the DHCP option 66 and 67, Sheth-Paragraph 107, if at S604, destination node 116 determines that the result of verification at S602 indicates that the source node 202 is verified, then at S608, destination node 116 sends the MUD fetch URL… a MUD manager (can reside on a DHCP server or can be a separate server) receives the attestation information (verification or integrity information) of source node 202 (IoT), in response to which MUD manager fetches the MUD file from a MUD file server to the destination node 115))
Regarding Claim 21
Peng-Sheth-Kale disclosed (re. Claim 21) wherein generating the network policy comprises configuring an access control list (ACL) based on a field related to access permission included in the MUD file.(Kale-Paragraph 45, posture assessment engine 16 is operative to check (block 66) a security adequacy of an access list included in the MUD profile.)
Regarding Claim 22
Peng-Sheth-Kale disclosed (re. Claim 22) completing, by the network device, a network configuration according to the network policy; notifying, by the network device, the terminal that authentication succeeds; (Kale-Paragraph 46, posture assessment engine 16 is operative to prepare (block 76) a response for the MUD controller 14 indicating whether, or not, the MUD profile provides adequate security for the IoT device 18) and controlling, by the network device, a network service of the terminal based on the network configuration.
Conclusion
Examiner’s Note: In the case of amending the claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
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 GREG C BENGZON whose telephone number is (571)272-3944. The examiner can normally be reached on Monday - Friday 8 AM - 4: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, John Follansbee can be reached on (571) 272-3964. 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.
/GREG C BENGZON/ Primary Examiner, Art Unit 2444
