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 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’s argument regarding claim(s) 9 and 16 (Summary of pages 15 and 16, Examiner emphasis – Bold).
…Applicant argued that Karanjkar and Agarwal, both individually and in combination, fail to teach or suggest all of the features of claim(s) 9 and 16, either as previously presented or as currently amended.
Response:
Examiner respectfully disagrees.
See updated rejection of claim(s) 9 and 16.
In particular, Agarwal discloses the amended feature of “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)”. In [0041-0042] Agarwal discloses a data collection module 200 which collets item/device data, which is information or data that identifiers/profile items/devices. Item/date may include among other attributes, a serial number of the item/device and the items/devices may be sub-divided into different categories (items that are of a similar type). Based on item/device identifier/category/profile of a device hosting a service, an online concierge system 140 may request for instruction/script for provisioning and configuring new devices providing new network services. The request for provisioning instruction/script which may include the category/profile information of the device to be provisioned and 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 by 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. Therefore, the combination of Karanjkar, and Agarwal disclose all of the limitations of claim(s) 9 and 16.
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,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), further in view of Agarwal (US 2025/0111140 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].
Regarding claim 2, Karanjkar, Venkatraman and Agarwal 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 6, Karanjkar, Venkatraman and Agarwal 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 and Agarwal 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), further in view of LIU et al. (US 2024/0346254).
Regarding claim 3, Karanjkar, Venkatraman and Agarwal 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 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, Venkatraman 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].
Claim(s) 4 -5 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 Gilde et al. (US 2006/0164199 A1).
Regarding claim 4, Karanjkar, Venkatraman and Agarwal disclose the system of claim 1, but did not explicitly 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.
Gilde discloses 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 (Gilde, figs. 22 & 23, [0024] discloses a system that is configured to detect a device seeking to join or otherwise access the network, identify a switch port that the device is attempting to connect to, and determine if the device is authentic and authorized to join the network. If it is determined that the device is unauthorized and/or unauthentic, the device may be quarantined. The suspect device is quarantined using, for example, a Virtual Local Area Network (VLAN)).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Venkatraman, Agarwal and Gilde 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 Gilde into the invention of Karanjkar, Venkatraman and Agarwal. The motivation would have been to quarantine a device requesting to join a network using a first quarantine VLAN if the device is suspected based on the result of an audit vulnerabilities are identified in the device, ensuring that the device is safe to have access to a second normal VLAN, Gilda, [0024].
Regarding claim 5, Karanjkar, Venkatraman and Agarwal disclose the system of claim 1, but did not explicitly disclose wherein: the device is 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; and the device is 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.
Gilda discloses wherein: the device is 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 (Gilde, figs. 22 & 23, [0024] discloses a system that is configured to detect a device seeking an initial connection to join or otherwise access the network, identify a switch port that the device is attempting to connect to, and determine if the device is authentic and authorized to join the network. If it is determined that the device is unauthorized and/or unauthentic, the device may be quarantined. The suspect device is quarantined using, a first Virtual Local Area Network (VLAN) designed as a “quarantine VLAN”); and
the device is assigned a second VLAN (normal VLAN) associated with the network following execution of the configuration script (configuration to grant a device access to normal VLAN), the second VLAN granting greater access to the network than the first VLAN (Gilde, figs. 22 & 23, [0120 0121] discloses an audit of network devices attempting to join a network to determine if it is safe grant the requested access. if, at decision block 2218, the result of the audit is unsatisfactory, processing continues to block 2222, where an attempt may be made to resolve the unsatisfactory audit result. Resolving the unsatisfactory audit result may include granting the network device restricted access to quarantined devices. At block 2212, a future audit may be scheduled for the device. Processing then continues to block 2214, where the device is granted access to the network. The network access control appliance (NACA) may grant the device access (Full access greater than restricted access) to the network by placing the device on a normal VLAN).
The motivation to combine is similar to that od claim 4.
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), further in view of Shah et al. (US 2018/0316673 A1).
Regarding claim 7, Karanjkar, Venkatraman and Agarwal 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 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 and Agarwal. 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, 13,15-16 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).
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].
Regarding claim 13, Karanjkar modified by Agarwal 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 modified by Agarwal 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 modified by Agarwal 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 20, the claim is rejected with rational similar to that of claim 13.
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), further in view of LIU et al. (US 2024/0346254).
Regarding claim 10, Karanjkar modified by Agarwal 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 modified by Agarwal 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) 11-12 and 18-19 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 in view of Gilde et al. (US 2006/0164199 A1).
Regarding claim 11, Karanjkar, modified by Agarwal disclose the method of claim 9, but did not explicitly 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.
Gilde discloses 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 (Gilde, figs. 22 & 23, [0024] discloses a system that is configured to detect a device seeking to join or otherwise access the network, identify a switch port that the device is attempting to connect to, and determine if the device is authentic and authorized to join the network. If it is determined that the device is unauthorized and/or unauthentic, the device may be quarantined. The suspect device is quarantined using, for example, a Virtual Local Area Network (VLAN)).
One of ordinary skill in the art would have been motivated to combine Karanjkar, Agarwal and Gilde 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 Gilde into the invention of Karanjkar, and Agarwal. The motivation would have been to quarantine a device requesting to join a network using a first quarantine VLAN if the device is suspected based on the result of an audit vulnerabilities are identified in the device, ensuring that the device is safe to have access to a second normal VLAN, Gilda, [0024].
Regarding claim 12, Karanjkar, modified by Agarwal disclose the method of claim 9, but did not explicitly disclose wherein: the device is 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; and the device is 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.
Gilda discloses wherein: the device is 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 (Gilde, figs. 22 & 23, [0024] discloses a system that is configured to detect a device seeking an initial connection to join or otherwise access the network, identify a switch port that the device is attempting to connect to, and determine if the device is authentic and authorized to join the network. If it is determined that the device is unauthorized and/or unauthentic, the device may be quarantined. The suspect device is quarantined using, a first Virtual Local Area Network (VLAN) designed as a “quarantine VLAN”); and
the device is assigned a second VLAN (normal VLAN) associated with the network following execution of the configuration script (configuration to grant a device access to normal VLAN), the second VLAN granting greater access to the network than the first VLAN (Gilde, figs. 22 & 23, [0120 0121] discloses an audit of network devices attempting to join a network to determine if it is safe grant the requested access. if, at decision block 2218, the result of the audit is unsatisfactory, processing continues to block 2222, where an attempt may be made to resolve the unsatisfactory audit result. Resolving the unsatisfactory audit result may include granting the network device restricted access to quarantined devices. At block 2212, a future audit may be scheduled for the device. Processing then continues to block 2214, where the device is granted access to the network. The network access control appliance (NACA) may grant the device access (Full access greater than restricted access) to the network by placing the device on a normal VLAN).
The motivation to combine is similar to that od claim 11.
Regarding claim(s) 18 and 19 is/are rejected with rational similar to that of claim(s) 11 and 12, respectively.
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), further in view of Shah et al. (US 2018/0316673 A1).
Regarding claim 14, Karanjkar modified by Agarwal 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 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 and Agarwal. The motivation would have been for a device provisioning file to define one or more network security policies for the particular device, Shah, [0012].
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.
Venkatraman et al. (US 10,810,361 B1)
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 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