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 Arguments
Applicant’s arguments with respect to claim(s) 1-4 and 6-7 summarized in pages 11-14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argued that independent claim(s) 9 and 16 have now been amended to include “wherein sending the request to the language model causes the language model to translate based at least in part on the workflow, the profiling information into the configuration script”. However, this is not a new amendment because this limitation was included in the claims presented on 02/24/2026 and rejected in the final rejection mailed on 04/20/2026. Applicant did not present any specific argument regarding this limitation, therefore, there is no specific response to this argument and the final rejection of this limitation is maintained.
Applicant’s argument regarding the allowability of all the dependent claims are moot because the arguments rely on the argument that the respective independent claims they depend from are allowable. This argument have already been fully addressed above.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-2,4,6 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karanjkar et al. (US 2025/0193072 A1), in view of Venkatraman et al. (US 2021/0248556 A1), in view of Agarwal (US 2025/0111140 A1), further in view of Patel et al. (US 2018/0219920 A1).
Regarding claim 1, Karanjkar discloses a system (Fig. 1.1 – system 100) comprising: one or more processors (Fig. 1.1, (101), (103) & (105)) (Karanjkar, figs. 1.1 & 4, [0035], shows a system (100) for app-assisted Next generation zero touch provisioning (Next ZTP). The system (100) includes a network management service (101), a user device (103), and a network device (105). Each of these devices include one or more processors similar to 402 of figure 4); and
one or more non-transitory computer-readable media (fig. 4, (404) (406)) storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising (Karanjkar, figs. 1.1 &4, [0041] devices 101, 103 and 105 include may include any type of non-transitory computer-readable medium that is used to persistently store instructions, which, when executed by one or more processor(s) in the devices ( (101), (103) & (105)), enable the devices to perform one or more functions):
receiving, at a network controller (Network management service/device 101) associated with a network ([0028] Internet Service Providers (ISPs) and private networks) and from a profiling server ([0020] Expected Device Workflow (EDW engine) on a server machine) associated with the network, profiling information associated with a device (a device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device) that has made an initial connection (a connection request is received from a network device) to the network (ISP/Private network) (Karanjkar, fig.3, [0019-0020;0028] network device 101 hosting a management service receives a connection request from a new device (user device 103). The request includes a device identifier (ID) provided by the network device (e.g., a device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device. A server machine hosting an expected device workflow engine (EDW) profiles the new device and provides the profiled information to the network management service/device 101);
determining, based at least in part on the profiling information, a type (serial number of smart phone, a tablet, a laptop, etc.) associated with the device (User device 103) (Karanjkar, figs. 1.1 & 3, [0019-0020; 0027-0028] based on the device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device included in the profile of the new device, the manufacturer, the type (smart phone, a tablet, a laptop, etc.) is determined);
querying a database to identify a workflow (script) associated with on-boarding the device (Karanjkar [0019-0020;0082;0084] a centralized database accessible by the network management service hosted on the network device 101, stores profile information (device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device) extracted from a connection request received from the user device. Implementing a mapping logic executed on the Expected Device Workflow (EDW engine), device profile information is used to determine if a device match will be found in centralized database. If a match is found in an entry of the centralized database, the EDW engine obtains the knowledge on: 1) the network device itself; 2) the owner of the network device; and 3) the suborganization or tenant for which the network device is to be configured. The EDW engine provides these pieces of information to the network management service. The network management service, in turn, directs the new network device to a configuration file or script corresponding to the tenant or suborganization (313));
sending, from the network controller (Network Management Service /device 101) and to a language model (onboarding features/language used to create a ZTP-token, e.g. URL for ZTP) associated with the network (ISP/Private network), a request (request to download a script) for a configuration script associated (configuration script for onboarding a particular type of new network device) with configuring the device with the network (Karanjkar, Fig. 2.5 [0015 - 0018;0079], the network management service/device 101 provides a ZTP-token created using a program/language model. The ZTP token may be used to request downloading a configuration script associated with onboarding on a particular new network device identified based on device id included in the request. The network management service/device may provide the ZTP-token such as a URL for ZTP before it can download the configuration file or script from the designated URL);
the request (onboarding request) including the workflow (Expected Device Workflow) associated with on-boarding the device (new device) and the profiling information (Device ID, MAC address, Serial number) associated with the device (New device) (Karanjkar, [0019-0021], an on-boarding request from a new device is received at the Network Management Service/Device 101, where the request includes device specific/profile information that enables the management service to map the request to an Expected Device Workflow (EDW engine) specific to the device identified in the request. Through lookups, the EDW engine obtains the knowledge on: 1) the network device itself; 2) the owner of the network device; and 3) the suborganization or tenant for which the network device is to be configured. After these pre-provisioning steps are completed, control moves from the EDW to ZTP. Based on the knowledge thus gained, the new network device is directed to an appropriate configuration file or script for ZTP),
receiving, at the network controller (101) and from the
the configuration script being associated with a network port of a switch connecting the device to the network (Karanjkar, fig. 4, [0040;0084], A configuration file or script for onboarding a new device 105 is downloaded based on identifying information associated with the new device. The new device (105) may be a physical device such as a router, switch, gateway, etc. which includes two or more physical ports. That is, the file or script is associated with the ports associated on the new router, switch, gateway, etc., through which the device is connected to the network), and
configuring, by the network controller (EDW/ZTP engines of Management Service 101), the network port associated with the device based at least in part on execution of the configuration script (Karanjkar [0084] the configuration file or script may reside at a resource location that belongs to the tenant or suborganization or that is on a ZTP server operating on the premises of the owner or the Network Management Service 101. Control of the process moves from the EDW to ZTP , which automatically provisions the new network device using the configuration file or script).
Karanjkar discloses querying a database to identify a workflow associated with on-
boarding the device [0019-0020;0082;0084], however, Karanjkar did not explicitly disclose “performing a semantic search”.
Venkatraman discloses querying, by performing a semantic search using at least one of the type or the profiling information, a database to identify a workflow associated with on- boarding the device (Venkatraman fig. 26T; [0086;0103;0203; 0236] discloses an interaction management system which determines and renders workflow sequences analogous to a deployment/re-deployable workflow sequence in communication with at least one database, for deployment by users. The interaction management system stores all captured workflow sequences and metadata for associated with deploying different types of user devices such as desktop computers, laptops, tablets, and smart phones in at least one database. To detect or recognize workflow sequence analogues deployment for any of the user devices in the database of captured workflow sequences, the interaction management system performs a structural interpretation to identify a relationship or a lack thereof between stored workflow sequences. At capture, the interaction management system allows a user to name, describe, and tag a workflow sequence for storage and search and/or retrieval. The interaction management system performs a semantic relevance to a search string associated with device type entered by a user on the display interface and retrieves an appropriate/relevant workflow for deployment of the device).
One of ordinary skill in the art would have been motivated to combine Karanjkar and Venkatraman because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new devices.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Venkatraman into the invention of Karanjkar. The motivation would have been to track and map actions performed along an interaction path to generating one or more deployable workflow sequences for deploying user devices, Venkatraman, [Abstract].
Karanjkar and Venkatraman disclose all of the limitations of claim 1, however, Agarwal more explicitly disclose the use of a language model for onboarding new network devices.
Agarwal, discloses receiving, at the network controller (fig. 1 - concierge system 140) and from the language model (LLM), the configuration script associated with the device (Agarwal, figs. 1,3 &4 [Abstract; 0068] discloses an online concierge system 140 retrieving and modifying instruction/script for provisioning and configuring new devices providing new network services. The capability of the online concierge system 140 to modify an existing configuration script allows the online concierge system 140 to tailor resources provisioned for an internal service, data monitored for an internal service, a metric generated for an internal service, or other functionality for an internal service for a specific user device based on the configuration parameters. These instructions/script for provisioning new devices for new internal services, are generated using and fine-tuning (fig. 3, steps 305-355 & fig. 4, steps 405,415 & 430) of a large language model (LLM)). The generative model of fig. 3 is a large language model tuned 320).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Venkatraman and Agarwal because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new devices.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Agarwal into the invention of Karanjkar and Venkatraman. The motivation would have been to generate instructions for a new internal service, the online system by tuning a large language model (LLM) with the database and provides prompts to LLM to generate executable instructions for the internal service based on the prompts, Agarwal, [0009].
Karanjkar, Venkatraman and Agarwal did not explicitly disclose the device being assigned a first virtual local area network (VLAN) associated with the network during the initial connection to the network, the first VLAN being configured as a quarantine VLAN; the device being assigned a second VLAN associated with the network following execution of the configuration script, the second VLAN granting greater access to the network than the first VLAN.
Patel discloses the device (fig. 1A, IoT device/ 101A, 101B, . . . , 101N) being assigned a first virtual local area network (VLAN) (fig. 1A, Quarantine/guest VLAN) associated with the network (Enterprise VLAN) during the initial connection (initial connection between an IoT device (101A, 101B, . . . , 101N) to be deployed and an edge device (100, 100B, . . . , 100N) to the network (Enterprise VLAN), the first VLAN being configured as a quarantine VLAN (Quarantine/guest VLAN); (fig. 1A, an Edge device 100 assigns IoT device/101A to a first/quarantine/guest VLAN) (Patel. Fig. 1A, [0025;0035-0037] before an IoT device (101A, 101B, . . . , 101N) is deployed on an enterprise network, the IoT device (101A, 101B, . . . , 101N) will initially be connected to an edge device (100, 100B, . . . , 100N). The IoT device connected to the edge device may first be assigned to a quarantine/guest virtual LAN (ULAN) by the associated edge device. At fig. 4A, steps 700 -701, a data packet engine 121 may determine that an IoT device is ready to be deployed on an enterprise VLAN to which the edge device 100 is connected. The data packet engine 121 may determine the IoT device is ready to be deployed responsive to receiving an instruction from a data center, another edge device in the network, and/or other entity in the network to deploy the IoT device. In order to deploy the IoT device, the data packet engine 121 may assign the IoT device to a quarantine or guest VLAN. The quarantine or guest VLAN may comprise a VLAN that is separate from the enterprise VLAN and that may only be accessible to edge device 100);
the device (fig. 1, 101A, 101B, . . . , 101N) being assigned a second VLAN (Enterprise VLAN) associated with the network following execution of the configuration script (instruction/configuration wizard received from a data center, another edge device in the network), the second VLAN granting greater access (Once the IoT device is moved to the enterprise network, it is granted full access to participate in the enterprise network) to the network than the first VLAN (IoT devices in the quarantine/guest VLAN do not participate in the enterprise network) (Patel, [0029; 0040] before moving the IoT device from the quarantine/guest VLAN to the enterprise VLAN, based on information from a control packet received from the IoT device and information about the IoT device, a data packet engine 121 may generate a signature for the IoT device. The data packet engine 121 may generate the signature for the IoT device by listing the IoT device as a connected IoT device in an edge device signature configuration wizard. Responsive to the data packet engine 121 generating the signature, the data packet engine 121 may determine that the IoT device is ready to be deployed. As such, the data packet engine 121 may facilitate the moving of the IoT device from operating on the quarantine VLAN to the enterprise VLAN that connects the edge device 100 to the rest of the network (e.g., to other IoT devices, other edge devices, a data center, and/or other entities connected via the enterprise VLAN). The data packet engine 121 may also enforce policies regarding the IoT device, such as ingress/egress bandwidth, Power-Over Ethernet (POE), access control lists (ACL), and/or other policies related to performance of the IoT device. That is, data packets of the IoT device may be validated based on comparing the signature of the IoT device and information from the packet headers, thus, fully participate in the enterprise VLAN which was not possible when the IoT device was in the quarantine/guest VLAN).
One of ordinary skill in the art would have been motivated to combine Patel, Venkatraman, Agarwal and Karanjkar because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new devices to an enterprise network.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Patel into the invention of Karanjkar, Venkatraman and Agarwal. The motivation would have been to provide security for Internet of Things (IoT) devices, by generating a signature for each device based device specific information that is accessed and validated by an edge device connected to the IoT and apply a set of rules when processing packets from the IoT device, Patel, [Abstract].
Regarding claim 2, Karanjkar, Venkatraman, Agarwal and Patel disclose the system of claim 1, wherein the language model is configured as a generative artificial intelligence (AI) model comprising at least one of: a large language model (LLM); a medium language model (MLM); or a small language model (SLM) (Agarwal, fig. 3, [Abstract; 0074] discloses a generative model such as a large language model tuned to generate instructions for providing new network resources).
The motivation to combine is similar to that of claim 1.
Regarding claim 4, Karanjkar, Venkatraman, Agarwal and Patel disclose the system of claim 1, disclose wherein configuring the network port associated with the device based at least in part on execution of the configuration script comprises at least one of: assigning the device to an overlay network associated with the network; assigning the device to a virtual local area network (VLAN) associated with the network; configuring one or more quality of service (QoS) attributes associated with the device; and configuring the network port with one or more security services associated with the device (Patel [0036] discloses that data packet engine 121 may determine that an IoT device is ready to be deployed on an enterprise VLAN to which an edge device 100 is connected. The data packet engine 121 may determine the IoT device is ready to be deployed responsive to receiving an instruction from a data center, another edge device in the network, and/or other entity in the network to deploy the IoT device. In order to deploy the IoT device, the data packet engine 121 may assign the IoT device to a quarantine or guest VLAN. The quarantine or guest VLAN may comprise a VLAN that is separate from the enterprise VLAN and that may only be accessible to edge device 100. After quarantining the IoT device, the device can then be moved to an appropriate enterprise VLAN).
The motivation to combine is similar to that of claim 1.
Regarding claim 6, Karanjkar, Venkatraman, Agarwal and Patel disclose the system of claim 1, wherein the device is at least one of: a non-human device configured as at least one of:
an internet of things (IoT) device; a camera; a sensor; a human machine interface (HMD); or a programmable logic controller (PLC); or a human device, under control of one or more users and configured as at least one of: a mobile device; or a personal computing device (Karanjkar, fig. 1.2, [0043-0044] discloses the user device (140) being onboarded may also include a camera (148), a mobile device such as a smartphone, a tablet computer, a laptop computer, and so on).
The motivation to combine is similar to that of claim 1.
Regarding claim 8, Karanjkar, Venkatraman, Agarwal and Patel disclose the system of claim 1, wherein the profiling information associated with the device includes at least one of:
an identifier associated with the device; an internet protocol (IP) address associated with the device; a manufacturer associated with the device; one or more capabilities associated with the device; or power over ethernet (PoE) information associated with the device (Karanjkar, figs. 1.1 & 3, [0019-0020; 0027-0028] an onboarding request from a new device include a device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device included in the profile of the new device, the manufacturer, the type (smart phone, a tablet, a laptop, etc.) is determined).
The motivation to combine is similar to that of claim 1.
Claim(s) 3, is/are rejected under 35 U.S.C. 103 as being unpatentable over Karanjkar et al. (US 2025/0193072 A1), in view of Venkatraman et al. (US 2021/0248556 A1), in view of Agarwal (US 2025/0111140 A1), view of Patel et al. (US 2018/0219920 A1), further in view of LIU et al. (US 2024/0346254).
Regarding claim 3, Karanjkar, Venkatraman, Agarwal and Patel disclose the system of claim 2, but did not explicitly disclose wherein at least one of the MLM or the SLM is generated as a result of one or more distillation processes performed with respect to the LLM based at least in part on input received from an administrator (User feedback) of the network.
Liu discloses wherein at least one of the MLM or the SLM is generated as a result of one or more distillation processes performed with respect to the LLM based at least in part on input received from an administrator of the network (Liu, [0044-0045] discloses a process of generating a small language model 318 (SLM) from a large language model 302 (LLM) based on inputs received as feedback 324. The large language model 302 can generate various feedback inputs 324 received from users that modify various aspects of the small language model 318 to align the small language model 318 with the tendencies of the large language model 302).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Venkatraman, Agarwal, Patel and Liu because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new network devices.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Liu into the invention of Karanjkar, Venkatraman, Agarwal and Patel. The motivation would have been for the natural language generation system to collect feedback from users to further fine-tune the natural language generation system in order to perform a desired task, Liu, [0012].
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karanjkar et al. (US 2025/0193072 A1), in view of Venkatraman et al. (US 2021/0248556 A1), in view of Agarwal (US 2025/0111140 A1), view of Patel et al. (US 2018/0219920 A1), further in view of Shah et al. (US 2018/0316673 A1).
Regarding claim 7, Karanjkar, Venkatraman, Agarwal and Patel disclose the system of claim 1, but did not explicitly disclose wherein determining the type associated with the device is further based at least in part on a manufacturer usage description (MUD) uniform resource identifier (URI) included in the profiling information and indicating the type of the device.
Shah discloses wherein determining the type ([0049] – HVAC, Appliances, security cameras, etc.) associated with the device (IOT) is further based at least in part on a manufacturer usage description (MUD) uniform resource identifier (URI) included in the profiling information and indicating the type of the device (Shah [0026;0030;0049] a zero-touch device provisioning process is described. The process starts with a request for provisioning file (Manufacturer Usage Description - MUD file) for the particular device from a device provisioning server. The identity of the particular IOT device (HVAC, Appliances, security cameras, etc.) can be retrieved from the profile of the device stored in a registration database. The IoT device included a MUD URI in its request, the Registrar may send that to the Manufacturer Authorized Signing Authority (MASA) server). The MASA server 350 requests a MUD file from the MUD server 340, the MASA server 350 receives and returns the MUD file (e.g., for the class of IoT device that is being registered) to the Registrar 330 along with the BRSKI state for the device).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Venkatraman, Agarwal, Patel and Shah because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new devices.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Shah into the invention of Karanjkar, Venkatraman, Agarwal and Patel. The motivation would have been for a device provisioning file to define one or more network security policies for the particular device, Shah, [0012].
Claim(s) 9,11,13,15-16,18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karanjkar et al. (US 2025/0193072 A1), in view of Agarwal (US 2025/0111140 A1), Further view of Patel et al. (US 2018/0219920 A1).
Regarding claim 9, Karanjkar discloses a method (Karanjkar, figs. 1.1 & 4, [0035], discloses a method for app-assisted Next generation zero touch provisioning (Next ZTP). The method may be implemented by a system (100) which includes a network management service (101), a user device (103), and a network device (105). Each of these devices include one or more processors similar to 402 of figure 4) comprising:
receiving, at a network controller (Network management service/device 101) associated with a network ([0028] Internet Service Providers (ISPs) and from a profiling
server ([0020] Expected Device Workflow (EDW engine) on a server machine) associated with the network; profiling information associated with a device (a device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device) that has made an initial connection (a connection request is received from a network device) to the network (ISP/Private network) ( Karanjkar, fig.3, [0019-0020;0028] network device 101 hosting a management service receives a connection request from a new device (user device 103). The request includes a device identifier (ID) provided by the network device (e.g., a device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device. A server machine hosting an expected device workflow engine (EDW) profiles the new device and provides the profiled information to the network management service/device 101);
determining, based at least in part on the profiling information, a type (serial number of smart phone, a tablet, a laptop, etc.) associated with the device (User device 103) (Karanjkar, figs. 1.1 & 3, [0019-0020; 0027-0028] based on the device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device included in the profile of the new device, the manufacturer, the type (smart phone, a tablet, a laptop, etc.) is determined);
querying a database to identify a workflow (script) associated with on-boarding the device based at least in part on the type associated with the device (Karanjkar [0019-0020;0082;0084] a centralized database accessible by the network management service hosted on the network device 101, stores device profile information (device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device) extracted from a connection request received from the user device. Implementing a mapping logic executed on the Expected Device Workflow (EDW engine), device profile information is used to determine if a device match will be found in centralized database. If a match is found in an entry of the centralized database, the EDW engine obtains the knowledge on: 1) the network device itself; 2) the owner of the network device; and 3) the suborganization or tenant for which the network device is to be configured. The EDW engine provides these pieces of information to the network management service. The network management service, in turn, directs the new network device to a configuration file or script corresponding to the tenant or suborganization (313));
sending, from the network controller (Network Management Service /device 101) and to a language model (onboarding features/language used to create a ZTP-token, e.g. URL for ZTP) associated with the network (ISP/Private network), a request (request to download a script) for a configuration script associated (configuration script for onboarding a particular type of new network device) with configuring the device with the network (Karanjkar, Fig. 2.5 [0015 - 0018;0079], the network management service/device 101 provides a ZTP-token created using a program/language model. The ZTP token may be used to request downloading a configuration script associated with onboarding on a particular new network device identified based on device id included in the request. The network management service/device may provide the ZTP-token such as a URL for ZTP before it can download the configuration file or script from the designated URL);
the request (device onboarding request) including the workflow (Expected Device Workflow) associated with on-boarding the device (new device) and the profiling information (Device ID, MAC address, Serial number) associated with the device (New device) (Karanjkar, [0019-0021], an on-boarding request from a new device is received at the Network Management Service/Device 101, where the request includes device specific/profile information that enables the management service to map the request to an Expected Device Workflow (EDW engine) specific to the device identified in the request. Through lookups, the EDW engine obtains the knowledge on: 1) the network device itself; 2) the owner of the network device; and 3) the suborganization or tenant for which the network device is to be configured. After these pre-provisioning steps are completed, control moves from the EDW to ZTP. Based on the knowledge thus gained, the new network device is directed to an appropriate configuration file or script for ZTP),
receiving, at the network controller (101) and from the model, the configuration
script associated with the device (Karanjkar, [0084], the Network Management Service receives and stores configuration scripts that are used to onboard and configure new network devices based device identifying information obtained from an onboarding request received from the new device. A ZTP-token written in a language model may be used to access to the designated location of the file or script for the device specified in the request),
the configuration script being associated with a network port of a switch connecting the device to the network (Karanjkar, fig. 4, [0040;0084], A configuration file or script for onboarding a new device 105 is downloaded based on identifying information associated with the new device. The new device (105) may be a physical device such as a router, switch, gateway, etc. which includes two or more physical ports. That is, the file or script is associated with the ports associated on the new router, switch, gateway, etc., through which the device is connected to the network); and
configuring, by the network controller (EDW/ZTP engines of Management Service 101), the network port associated with the device based at least in part on execution of the configuration script (Karanjkar [0084] the configuration file or script may reside at a resource location that belongs to the tenant or suborganization or that is on a ZTP server operating on the premises of the owner or the Network Management Service 101. Control of the process moves from the EDW to ZTP , which automatically provisions the new network device using the configuration file or script).
Karanjkar did not explicitly disclose a language model and wherein sending the request to the language model causes the language model to translate based at least in part on the workflow, the profiling information into the configuration script.
Agarwal, discloses wherein sending the request to the language model large language model (LLM)) causes the language model to translate (LLM modifies/ fine-tunes configuration instructions/script for providing items providing internal services) based at least in part on the workflow (based on a previously generated instruction/script), the profiling information (based in the type of item/category) into the configuration script (provisioning instruction/script) (Agarwal [0041-0042] a data collection module 200 collets item data, which is information or data that identifiers/profile items including a serial number of the item, where the items may be sub-divided into different categories (items that are of a similar type). Based on item identifier/category/profile of a device hosting a service, an online concierge system 140 request for an instruction/script for provisioning and configuring new devices providing new network services. The request for provisioning instruction/script which includes the category/profile information of the device to be provisioned is sent to a Large Language Model (LLM) where the instructions/script are modified/fine-tuned to generate and provide configuration script to the online concierge system 140 which allows the system to tailor resources provisioned for an internal service, data monitored for an internal service, a metric generated for an internal service, or other functionality for an internal service for a specific user device based on the configuration parameters. These instructions/script for provisioning new devices for new internal services, are generated using and fine-tuning (fig. 3, steps 305-355 & fig. 4, steps 405,415 & 430) of a large language model (LLM)). The generative model of fig. 3 is a large language model tuned 320) and
receiving, at the network controller (fig. 1 - concierge system 140) and from the language model (LLM), the configuration script associated with the device (Agarwal, figs. 1,3 &4 [Abstract; 0068] discloses an online concierge system 140 retrieving and modifying instruction/script for provisioning and configuring new devices providing new network services. The capability of the online concierge system 140 to modify an existing configuration script allows the online concierge system 140 to tailor resources provisioned for an internal service, data monitored for an internal service, a metric generated for an internal service, or other functionality for an internal service for a specific user device based on the configuration parameters. These instructions/script for provisioning new devices for new internal services, are generated using and fine-tuning (fig. 3, steps 305-355 & fig. 4, steps 405,415 & 430) of a large language model (LLM)). The generative model of fig. 3 is a large language model tuned 320).
One of ordinary skill in the art would have been motivated to combine Karanjkar, and Agarwal because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new devices.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Agarwal into the invention of Karanjkar. The motivation would have been to generate instructions for a new internal service, the online system by tuning a large language model (LLM) with the database and provides prompts to LLM to generate executable instructions for the internal service based on the prompts, Agarwal, [0009].
Karanjkar, and Agarwal did not explicitly disclose the device being assigned a first virtual local area network (VLAN) associated with the network during the initial connection to the network, the first VLAN being configured as a quarantine VLAN; the device being assigned a second VLAN associated with the network following execution of the configuration script, the second VLAN granting greater access to the network than the first VLAN.
Patel discloses the device (fig. 1A, IoT device/ 101A, 101B, . . . , 101N) being assigned a first virtual local area network (VLAN) (fig. 1A, Quarantine/guest VLAN) associated with the network (Enterprise VLAN) during the initial connection (initial connection between an IoT device (101A, 101B, . . . , 101N) to be deployed and an edge device (100, 100B, . . . , 100N) to the network (Enterprise VLAN), the first VLAN being configured as a quarantine VLAN (Quarantine/guest VLAN); (fig. 1A, an Edge device 100 assigns IoT device/101A to a first/quarantine/guest VLAN) (Patel. Fig. 1A, [0025;0035-0037] before an IoT device (101A, 101B, . . . , 101N) is deployed on an enterprise network, the IoT device (101A, 101B, . . . , 101N) will initially be connected to an edge device (100, 100B, . . . , 100N). The IoT device connected to the edge device may first be assigned to a quarantine/guest virtual LAN (ULAN) by the associated edge device. At fig. 4A, steps 700 -701, a data packet engine 121 may determine that an IoT device is ready to be deployed on an enterprise VLAN to which the edge device 100 is connected. The data packet engine 121 may determine the IoT device is ready to be deployed responsive to receiving an instruction from a data center, another edge device in the network, and/or other entity in the network to deploy the IoT device. In order to deploy the IoT device, the data packet engine 121 may assign the IoT device to a quarantine or guest VLAN. The quarantine or guest VLAN may comprise a VLAN that is separate from the enterprise VLAN and that may only be accessible to edge device 100);
the device (fig. 1, 101A, 101B, . . . , 101N) being assigned a second VLAN (Enterprise VLAN) associated with the network following execution of the configuration script (instruction/configuration wizard received from a data center, another edge device in the network), the second VLAN granting greater access (Once the IoT device is moved to the enterprise network, it is granted full access to participate in the enterprise network) to the network than the first VLAN (IoT devices in the quarantine/guest VLAN do not participate in the enterprise network) (Patel, [0029; 0040] before moving the IoT device from the quarantine/guest VLAN to the enterprise VLAN, based on information from a control packet received from the IoT device and information about the IoT device, a data packet engine 121 may generate a signature for the IoT device. The data packet engine 121 may generate the signature for the IoT device by listing the IoT device as a connected IoT device in an edge device signature configuration wizard. Responsive to the data packet engine 121 generating the signature, the data packet engine 121 may determine that the IoT device is ready to be deployed. As such, the data packet engine 121 may facilitate the moving of the IoT device from operating on the quarantine VLAN to the enterprise VLAN that connects the edge device 100 to the rest of the network (e.g., to other IoT devices, other edge devices, a data center, and/or other entities connected via the enterprise VLAN). The data packet engine 121 may also enforce policies regarding the IoT device, such as ingress/egress bandwidth, Power-Over Ethernet (POE), access control lists (ACL), and/or other policies related to performance of the IoT device. That is, data packets of the IoT device may be validated based on comparing the signature of the IoT device and information from the packet headers, thus, fully participate in the enterprise VLAN which was not possible when the IoT device was in the quarantine/guest VLAN).
One of ordinary skill in the art would have been motivated to combine Karanjkar Agarwal and Patel because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new devices to an enterprise network.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Patel into the invention of Karanjkar, and Agarwal. The motivation would have been to provide security for Internet of Things (IoT) devices, by generating a signature for each device based device specific information that is accessed and validated by an edge device connected to the IoT and apply a set of rules when processing packets from the IoT device, Patel, [Abstract].
Regarding claim 11, Karanjkar, Agarwal and Patel disclose the method of claim 9, wherein configuring the network port associated with the device based at least in part on execution of the configuration script comprises at least one of:
assigning the device to an overlay network associated with the network; assigning the device to a virtual local area network (VLAN) associated with the network; configuring one or more quality of service (QoS) attributes associated with the device; and configuring the network port with one or more security services associated with the device (Patel. Fig. 1A, [0025;0035-0037] before an IoT device (101A, 101B, . . . , 101N) is deployed on an enterprise network, the IoT device (101A, 101B, . . . , 101N) will initially be connected to an edge device (100, 100B, . . . , 100N). The IoT device connected to the edge device may first be assigned to a quarantine/guest virtual LAN (ULAN) by the associated edge device. At fig. 4A, steps 700 -701, a data packet engine 121 may determine that an IoT device is ready to be deployed on an enterprise VLAN to which the edge device 100 is connected. The data packet engine 121 may determine the IoT device is ready to be deployed responsive to receiving an instruction from a data center, another edge device in the network, and/or other entity in the network to deploy the IoT device. In order to deploy the IoT device, the data packet engine 121 may assign the IoT device to a quarantine or guest VLAN. The quarantine or guest VLAN may comprise a VLAN that is separate from the enterprise VLAN and that may only be accessible to edge device 100).
The motivation to combine is similar to is similar to that of claim 9.
Regarding claim 13, Karanjkar, Agarwal and Patel disclose the method of claim 9, wherein the device is at least one of: a non-human device configured as at least one of: an internet of things (IoT) device; a camera; a sensor; a human machine interface (HMI); or a programmable logic controller (PLC); or a human device under control of one or more users configured as at least one of: a mobile device; or a personal computing device (Karanjkar, fig. 1.2, [0043-0044] discloses the user device (140) being onboarded may also include a camera (148), a mobile device such as a smartphone, a tablet computer, a laptop computer, and so on).
The motivation to combine is similar to that of claim 9.
Regarding claim 15, Karanjkar, Agarwal and Patel disclose the method of claim 9, wherein the profiling information associated with the device includes at least one of: an identifier associated with the device; an internet protocol (IP) address associated with the device; a manufacturer associated with the device; one or more capabilities associated with the device; or power over ethernet (PoE) information associated with the device (Karanjkar, figs. 1.1 & 3, [0019-0020; 0027-0028] an onboarding request from a new device include a device ID, MAC address, serial number, Internet Protocol (IP) address assigned to the device included in the profile of the new device, the manufacturer, the type (smart phone, a tablet, a laptop, etc.) is determined).
The motivation to combine is similar to that of claim 9.
Regarding claim 16, Karanjkar, Agarwal and Patel disclose one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising (Karanjkar, figs. 2.1-2.4, [0039] discloses a persistent storage in the user device (103) which may include any type of non-transitory computer-readable medium that stores data. The persistent storage may be instructions, which, when executed by one or more processor(s) in the user device (103), enable the user device (103) to perform one or more functions of the user device (103).
The rest of the limitations of claim 16 are rejected with rational similar to that of claim 9.
Regarding claim(s) 18 and 20 is/are rejected with rational similar to that of claim(s) 11 and 13, respectively.
Claim(s) 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karanjkar et al. (US 2025/0193072 A1), in view of Agarwal (US 2025/0111140 A1), view of Patel et al. (US 2018/0219920 A1), further in view of LIU et al. (US 2024/0346254).
Regarding claim 10, Karanjkar, Agarwal and Patel disclose the method of claim 9, wherein the language model is configured as a generative artificial intelligence (AI) model comprising at least one of: a large language model (LLM); a medium language model (MLM); or a small language model (SLM) (Agarwal, fig. 3, [Abstract; 0074] discloses a generative model such as a large language model tuned to generate instructions for providing new network resources).
Karanjkar, Agarwal and Patel did not explicitly disclose wherein at least one of the MLM or the SLM is generated as a result of one or more distillation processes performed with respect to the LLM based at least in part on input received from an administrator of the network.
Liu discloses wherein at least one of the MLM or the SLM is generated as a result of one or more distillation processes performed with respect to the LLM based at least in part on input received from an administrator of the network (Liu, [0044-0045] discloses a process of generating a small language model 318 (SLM) from a large language model 302 (LLM) based on inputs received as feedback 324. The large language model 302 can generate various feedback inputs 324 received from users that modify various aspects of the small language model 318 to align the small language model 318 with the tendencies of the large language model 302).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Agarwal and Liu because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new devices.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Liu into the invention of Karanjkar, and Agarwal. The motivation would have been for the natural language generation system to collect feedback from users to further fine-tune the natural language generation system in order to perform a desired task, Liu, [0012].
Regarding claim 17, the claim is rejected with rational similar to that of claim 10.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karanjkar et al. (US 2025/0193072 A1), in view of Agarwal (US 2025/0111140 A1), Patel et al. (US 2018/0219920 A1), further in view of Shah et al. (US 2018/0316673 A1).
Regarding claim 14, Karanjkar, Agarwal and Patel disclose the method of claim 9, but did not explicitly disclose wherein determining the type associated with the device is further based at least in part on a manufacturer usage description (MUD) uniform resource identifier (URI) included in the profiling information and indicating the type of the device.
Shah discloses wherein determining the type ([0049] – HVAC, Appliances, security cameras, etc.) associated with the device (IOT) is further based at least in part on a manufacturer usage description (MUD) uniform resource identifier (URI) included in the profiling information and indicating the type of the device (Shah [0026;0030;0049] a zero-touch device provisioning process is described. The process starts with a request for provisioning file (Manufacturer Usage Description - MUD file) for the particular device from a device provisioning server. The identity of the particular IOT device (HVAC, Appliances, security cameras, etc.) can be retrieved from the profile of the device stored in a registration database. The IoT device included a MUD URI in its request, the Registrar may send that to the Manufacturer Authorized Signing Authority (MASA) server). The MASA server 350 requests a MUD file from the MUD server 340, the MASA server 350 receives and returns the MUD file (e.g., for the class of IoT device that is being registered) to the Registrar 330 along with the BRSKI state for the device).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Venkatraman, Agarwal, Patel and Shah because these teachings are from the same field of endeavor with respect to disclosing techniques related to automatic onboarding of new devices.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Shah into the invention of Karanjkar, Venkatraman, Agarwal and Patel. The motivation would have been for a device provisioning file to define one or more network security policies for the particular device, Shah, [0012].
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karanjkar et al. (US 2025/0193072 A1), in view of Venkatraman et al. (US 2021/0248556 A1), in view of Agarwal (US 2025/0111140 A1), in view of Patel et al. (US 2018/0219920 A1), further in view of Kallarakuzhi (US 2025/0284828 A1).
Regarding claim 21, Karanjkar, Venkatraman, Agarwal and Patel disclose the system of claim 1, but did not explicitly disclose wherein the language model is fine-tuned with knowledge of generalized configuration profiles for a wide variety of devices.
Kallarakuzhi discloses wherein the language model is fine-tuned (fig. 2, Fine-Tuned (Large language model 250) with knowledge of generalized configuration profiles (figs. 2 &3 Entity configuration profile 220/Configuration Profile 306) for a wide variety of devices (entities) (Kallarakuzhi [0058-0059;0121] a data configuration management system 104 fine-tunes a large language model 250 based general knowledge of an entity configuration profile 220. Fig. 12 illustrates the process of fine-tuning a large language model 250 based on general knowledge a configuration profile for each entity/device. That is, for a variety of entities/devices, the large language model is fine-tuned/modified to accommodate the difference/gap in the profile for each entity/device).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Venkatraman, Agarwal and Kallarakuzhi because these teachings are from the same field of endeavor with respect to disclosing techniques related to customizing configuration file based on a device profile.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Kallarakuzhi into the invention of Karanjkar, Venkatraman and Agarwal. The motivation would have been to fine-tune a large language model to accommodate for the difference/gap between different entity/device profile, Kallarakuzhi, [0121].
Claim(s) 22 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Karanjkar et al. (US 2025/0193072 A1), in view of Agarwal (US 2025/0111140 A1), in view of Patel et al. (US 2018/0219920 A1), further in view of Kallarakuzhi (US 2025/0284828 A1).
Regarding claim 22, Karanjkar, Venkatraman, Agarwal and Patel disclose the method of claim 9, but did not explicitly disclose wherein the language model is fine-tuned with knowledge of generalized configuration profiles for a wide variety of devices.
Kallarakuzhi discloses wherein the language model is fine-tuned (fig. 2, Fine-Tuned (Large language model 250) with knowledge of generalized configuration profiles (figs. 2 &3 Entity configuration profile 220/Configuration Profile 306) for a wide variety of devices (entities) (Kallarakuzhi [0058-0059;0121] a data configuration management system 104 fine-tunes a large language model 250 based general knowledge of an entity configuration profile 220. Fig. 12 illustrates the process of fine-tuning a large language model 250 based on general knowledge a configuration profile for each entity/device. That is, for a variety of entities/devices, the large language model is fine-tuned/modified to accommodate the difference/gap in the profile for each entity/device).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Venkatraman, Agarwal, Patel and Kallarakuzhi because these teachings are from the same field of endeavor with respect to disclosing techniques related to customizing configuration file based on a device profile.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Kallarakuzhi into the invention of Karanjkar, Venkatraman, Agarwal and Patel. The motivation would have been to fine-tune a large language model to accommodate for the difference/gap between different entity/device profile, Kallarakuzhi, [0121].
Regarding claim 23, the claim is rejected with rational similar to that of claim 22.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following publications show the state of the art related to the use of generative AI for onboarding new network devices.
Han et al. (US 2017/0339144 A1)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday - Friday from 9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher L Parry, can be reached at telephone number 571-272-8328. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/D.F.D/ Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights