DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
Claim Status
Claims 1, 7, 9, 10, 13, 18, and 19 are amended.
Claims 12 and 20 are canceled.
Claims 21 and 22 are newly added.
Claims 1-11, 13-19, 21 and 22 are presented for examination.
Response to Arguments
Applicant's arguments filed in the amendment filed on 5/14/2026 have been fully considered but they are moot in view of new grounds of rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
Claims 1, 11, 13-19, 21, and 22 are rejected under U.S.C. 103 as being unpatentable over Huffman et al. (US 20210352110), in view of Kang (US 20230421527), in further view of Sanaullah et al. (US 20250119311), in further view of Perneti et al. (US 20220391113).
Regarding claim 1, Huffman discloses, a computer-implemented method for automatically discovering and configuring internet of things (IoT) devices on a network (Par. 0060, Device discovery component 210 can be configured to discover and identify devices on the plant network for which security is to be configured, par. 0173, internet of things), comprising:
receiving, by a device service platform, the connection event that includes the device identifier of the device and the network address for the device (Par. 0141, Communications component 208 is configured to detect that a new device 1704 has been installed on the plant network 406 based on device identification data 1702 submitted to the system 202 by the new device 1704 upon installation. Device identification data 1702 may identify, for example, the device's type, model, and/or vendor information; a durable device identifier such as a media access control (MAC) address, the device's current firmware version, or other such information);
determining, by the device service platform and based at least in part on the device identifier of the device, whether the device is to be serviced (Par. 0166, a determination is made as to whether the device identity data received at step 2102 corresponds to an authorized device permitted to operate within the plant facility. In some scenarios, the device's authorization can be verified based on a determination that the device identity data corresponds to a device included on a list of approved devices. The device may also be verified by the identity authority server, which can inform the security configuration system that the device is permitted to operate. If the device is not authorized (NO at step 2104), the methodology ends); and
in response to determining that the device is to be serviced, automatically performing a configuration operation for the device by the device service platform, the configuration operation comprising (i) determining a device model of the device, based at least in part of the device identifier of the device, (ii) receiving, from a configuration data store, preferred configuration settings that have been specified for the device model of the device, and (iii) applying the preferred configuration settings to the device, using the network address for the device a configuration settings application script that is specific to the device model of the device (Par. 0065, To allow devices to be added to model 216, some embodiments of security configuration system 202 can maintain a database of industrial device definitions that can be manually or automatically selected and added to the model as needed. Par. 0141, If the device identification data 1702 is validated, the security configuration system 202 then determines, based on the device identification data 1702, where the new device 1704 resides within the organization of zones and conduits recorded in the model 216, determines how the new device 1704 should be configured in order to comply with the existing security policies given the device's role or location within the model 216, and generates appropriate security configuration data 404 and/or security event configuration data 1504 designed to configure the new device 1704 to comply with the existing security policies. Instruction translation component 206 generates this new configuration data 404, 1504 based on the type and vendor (i.e. model of the device) of the new device 1704, such that the new configuration data 404, 1504 is understandable and executable (i.e. instruction to apply configuration is specific to device model/type/vendor) by the new device 1704).
Huffman does not disclose, receiving, by a network address server, a request for a network address for a device that is connecting to the network, wherein the request for the network address includes a device identifier of the device;
in response to receiving the request for the network address, (i) providing the network address for the device, and (ii) logging a connection event to an event data store, wherein the connection event includes the device identifier of the device and the network address for the device;
after automatically performing the configuration operation, determining whether configuration drift has occurred on the device, by:
establishing a remote connection to the device over the network,
executing a configuration settings collection script that is specific to the device model of the device and that collects current configuration settings of the device,
receiving, from the configuration data store, the preferred configuration settings that were previously applied to the device, and
determining whether the current configuration settings match the preferred configuration settings, wherein configuration drift is indicated when the current configuration settings do not match the preferred configuration settings; and
in response to determining that configuration drift has occurred on the device, automatically performing a reconfiguration operation for the device by the device service platform, by:
for each configuration setting having a current value that has deviated from a preferred value of the configuration setting, reapplying the preferred value of the configuration setting to the device, using the network address for the device and the configuration settings application script that is specific to the model of the device.
Kang discloses, receiving, by a network address server, a request for a network address for a device that is connecting to the network, wherein the request for the network address includes a device identifier of the device (Par. 0022, allocate the private IP address to the IoT device connected to the router and manage the allocated private IP address and connected IoT device information on the IoT device; and collect information on registered IoT device information for IoT devices registered at the database from the database, wherein the connected IoT device information includes a MAC address, a private IP address, a service port number, a lease period of the private IP address, and a public IP address of the router. Par. 0090-0095, when IoT device 200 is initially connected to router 400, router 400 (e.g., DHCP processor 412) may allocates a private address, router 400 receives information on (e.g., a registration request message) a service port number from IoT device 200 and registers the service port number of IoT device 200, collect and maintain and store the information about connected IoT device, The connected IoT device information (e.g., DB data or Collected data) may include i) a media access control (MAC) address of each IoT device connected to router 440, ii) a private IP address of each IoT device, i.e. as part of the request received by DHCP processor from newly connected IoT device for IP address, receiving the storing information such MAC address of IoT device);
in response to receiving the request for the network address, (i) providing the network address for the device (Par. 0090-0095, when IoT device 200 is initially connected to router 400, router 400 (e.g., DHCP processor 412) may allocates a private address, router 400 receives information on (e.g., a registration request message) a service port number from IoT device 200 and registers the service port number of IoT device 200), and (ii) logging a connection event to an event data store, wherein the connection event includes the device identifier of the device and the network address for the device (Par. 0094, The connected IoT device information (e.g., DB data or Collected data, i.e. connected IoT device data is stored in DB or database) may include i) a media access control (MAC) address of each IoT device connected to router 440, ii) a private IP address of each IoT device, iii) a service port number of each IoT device, iv) a lease period (Idle time) of each private IP address, and v) a public IP address of router 440).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Huffman by teaching of receiving, by a network address server, a request for a network address for a device that is connecting to the network, wherein the request for the network address includes a device identifier of the device; in response to receiving the request for the network address, (i) providing the network address for the device, and (ii) logging a connection event to an event data store, wherein the connection event includes the device identifier of the device and the network address for the device, as taught by Kang, to provide dynamic private IP address to newly joined IoT device and allow them communicate with external network and use database to keep joined IoT device information to verify the next IoT device against stored data of existing data, as disclosed in Kang par. 0029.
Huffman in view of Kang does not discloses, after automatically performing the configuration operation, determining whether configuration drift has occurred on the device, by:
establishing a remote connection to the device over the network,
executing a configuration settings collection script that is specific to the device model of the device and that collects current configuration settings of the device,
receiving, from the configuration data store, the preferred configuration settings that were previously applied to the device, and
determining whether the current configuration settings match the preferred configuration settings, wherein configuration drift is indicated when the current configuration settings do not match the preferred configuration settings; and
in response to determining that configuration drift has occurred on the device, automatically performing a reconfiguration operation for the device by the device service platform, by:
for each configuration setting having a current value that has deviated from a preferred value of the configuration setting, reapplying the preferred value of the configuration setting to the device, using the network address for the device and the configuration settings application script that is specific to the model of the device.
Sanaullah discloses, after automatically performing the configuration operation, determining whether configuration drift has occurred on the device by: establishing a remote connection to the device over the network, executing a configuration settings collection script that is specific to the device model of the device and that collects current configuration settings of the device, receiving, from the configuration data store, the preferred configuration settings that were previously applied to the device, and determining whether the current configuration settings match the preferred configuration settings, wherein configuration drift is indicated when the current configuration settings do not match the preferred configuration settings (Par. 0238, The instrumentation plug-in 1404 may scan for device settings across the various devices (par. 0232, fig. 14, instrumentation plugin 1404 monitors the peripherals (IHSs 104, audio devices 306/307, displays 102, cameras 308, whiteboard 509, touch controller 105b, etc. i.e. plurality of different device models is being monitored therefore scanning script is specific to the device model of the device for collecting current configuration settings) in the conference room and send data indicative of the device settings to the telemetry ingest 1403. The recommender service 1401 may pull this data to compare against original policy-applied (i.e. configuration policy has previously been applied and scanning of current policy after the previously applied configuration policy)) configuration settings to monitor configuration drift. The recommender service 1401 may determine that certain application settings and/or hardware settings are changed relatively often or at least more often than a threshold (i.e. configuration drift has occulted based on determining that configuration is changed from original configuration)).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Huffman in view of Kang by teaching of after applying the configuration settings to the device, automatically performing an inventory operation for the device by the device service platform, the inventory operation comprising, establishing a remote connection to the device, executing a configuration settings collection script that collects the configuration settings of the device, determining whether the current configuration settings match the preferred configuration settings, wherein configuration drift is indicated when the current configuration settings do not match the preferred configuration settings, as taught by Sanaullah, to monitor change in device’s original configuration and see how often the change is being made for system to suggest the recondition of commonly used configuration, as disclosed in Sanaullah par. 0238.
Huffman in view of Kang in further view of Sanaullah does not disclose
in response to determining that configuration drift has occurred on the device, automatically performing a reconfiguration operation for the device by the device service platform, by:
for each configuration setting having a current value that has deviated from a preferred value of the configuration setting, reapplying the preferred value of the configuration setting to the device, using the network address for the device and the configuration settings application script that is specific to the model of the device.
Perneti discloses, in response to determining that configuration drift has occurred on the device, automatically performing a reconfiguration operation for the device by the device service platform, by:
for each configuration setting having a current value that has deviated from a preferred value of the configuration setting, reapplying the preferred value of the configuration setting to the device, using the network address for the device and the configuration settings application script that is specific to the model of the device (Par. 0035, It automatically pushes changes for non-compliant systems, which are systems where any identified configuration drift is above a predefined threshold value. Par. 0044, configuration drift handling for components in a data storage environment, under some embodiments. For every component (device/model/OS) in each storage system 206, Par. 0075-0076 configuration drift (when compared to the golden configuration 902) a ranking can be performed, such as shown in the example of FIG. 9C, where a top rank (higher number) means a large configuration drift is identified. This configuration drift determination process can be configured to run at a regular interval of time (e.g., once in a week) Automatic response actions can be assigned to different defined threshold values or ranges to trigger corresponding actions, for those identified configuration drifts that belongs to the red range, trigger an immediate action to reset the running configuration to the golden configuration. This end-to-end automatic handling of configuration drift by pushing changes to non-compliant systems can greatly help users maintain the integrity of their data storage systems).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Huffman in view of Kang in further view of Sanaullah of by teaching of in response to determining that configuration drift has occurred on the device, automatically performing a reconfiguration operation for the device by the device service platform, reapplying the preferred value of the configuration setting to the device, using the network address for the device and the configuration settings application script that is specific to the model of the device, as taught by Perneti, this end-to-end automatic handling of configuration drift by pushing changes to non-compliant systems can greatly help users maintain the integrity of system, as disclosed in Perneti par. 0076.
Regarding claim 2, The computer-implemented method of claim 1,
Huffman in view of Kang in further view of Sanaullah in further view of Perneti further discloses, wherein the device is a security camera (Kang Par. 0051, 0054-0055, discloses IoT device performing surveillance through CCTV and camera).
Regarding claim 3, The computer-implemented method of claim 1,
Huffman in view of Kang in further view of Sanaullah in further view of Perneti further discloses, wherein the device identifier of the device is a media access control (MAC) address (Kang Par. 0094, The connected IoT device information (e.g., DB data or Collected data, i.e. connected IoT device data is stored in DB or database) may include i) a media access control (MAC) address of each IoT device connected to router 440, ii) a private IP address of each IoT device).
Regarding claim 4, The computer-implemented method of claim 1,
Huffman in view of Kang in further view of Sanaullah in further view of Perneti further discloses, wherein the network address server is a dynamic host configuration protocol (DHCP) server, and wherein the network address for the device is an internet protocol (IP) address (Kang Par. 0090-0095, when IoT device 200 is initially connected to router 400, router 400 (e.g., DHCP processor 412) may allocates a private address, router 400 receives information on (e.g., a registration request message) a service port number from IoT device 200 and registers the service port number of IoT device 200),.
Regarding claim 5, The computer-implemented method of claim 1,
Huffman further discloses, wherein the event data store is an event streaming platform, and wherein the device service platform subscribes to the event data store (Par. 0055, user equipment 100 may be a computer that remotely accesses IoT device 200, collects data from IoT device 200, and controls IoT device 200 in accordance with an embodiment. For example, user equipment 100 may remotely connect to IoT device 200 using its domain address and view captured video or control the device's camera for capturing images.).
Regarding claim 6, The computer-implemented method of claim 1,
Huffman further discloses, further comprising:
determining, by the device service platform and based at least in part on the network address for the device, a facility at which the device is located (Par. 0083, Selecting IP Block security for a zone specifies that the selected zone contains industrial assets identified by individual IP addresses or a range of IP addresses, par. 0128, Par. 1028, fig. 16, FIG. 16 is a diagram illustrating assignment of security event policies 1602 to respective security zones 1604. In this example, the industrial facility is a brewing plant, and model 216 has been generated to define groupings of industrial assets and devices 408 within the plant into three security zones 1604a-1604c, using techniques described above for defining and modeling trust zones. These zones 1604 correspond to different production areas of the plant—a brewing area (security Zone 1), a bottling area (security zone 2), and a packaging area (security zone 3), i.e. determining based on IP address of the device determining zone where device is located, each zone is identified as different facility such as, brewing, bottling and parking area); and storing, by the device service platform, data that represents the facility at which the device is located, along with the device identifier of the device and the network address for the device (Par. 0095, A Device Definition table 704 may include information defining the inventory of industrial assets and devices for which the plant-wide security strategy is to be implemented. For embodiments that support auto-discovery, at least some of this device information may be discovered automatically by the device discovery component 210, including but not limited to asset catalog numbers (i.e. device identifier) and current IP addresses (i.e. network address), Par. 0101, fig. 7A, 8A, a table illustrating example user configuration input that can be provided to (or, in some cases, automatically discovered by) security configuration system 202, and FIG. 8B is a diagram representing the security policy. In this example, devices D2-D3 all support CIP security and are assigned to the same zone (Zone 1). Device D4, assigned to Zone 2, i.e. storing the data which represents, zones (i.e. different facilities as disclosed in par. 0083, along with IP address and asset catalog numbers (i.e. device identifier)).
Regarding claim 7, The computer-implemented method of claim 6,
Huffman further discloses, wherein receiving the preferred configuration settings comprises receiving preferred configuration settings that have been specified for the device model of the device and the facility at which the device is located (Par. 0098, instruction translation component 206 then generates and deploys appropriate device-level, model- and vendor-specific security configuration instructions to any of the devices determined to require reconfiguration in order to implement the specified plant-wide security strategy. Par. 0164, translation engine capable of converting the security event management policies defined by the configuration input into device- and vendor-specific security event configuration instructions that, when executed on the individual target devices, will implement the zone-specific security event management policies, i.e. receiving configuration settings for implementation specified for specific device model and which zone (i.e. facility) it is located in).
Regarding claim 8, The computer-implemented method of claim 1,
Huffman further discloses, wherein determining the device model of the device comprises parsing the device identifier of the device, and identifying a model identifier included in the device identifier, that corresponds to the device model of the device (Par. 0141, Device identification data 1702 may identify, for example, the device's type, model, and/or vendor information; a durable device identifier such as a media access control (MAC) address, the device's current firmware version, or other such information, par. 0151, As part of the request, the new device 1704 may provide device information—e.g., the device's type, model, vendor, a durable device identifier such as a MAC address, etc.—that can be used by the identity authority server 130 to determine whether the device 1704 is to be granted identity credentials and configured for secure communication and event management, i.e. in order to determine whether the device to be to granted identify credentials, determine the device model by reading the device identifier provided in device identification data 1702).
Regarding claim 9, The computer-implemented method of claim 1,
Huffman further discloses, wherein applying the preferred configuration settings to the device comprises: establishing a remote connection to the device; and executing the configuration settings application script that is specific to the device model of the device, and that applies the preferred configuration settings to the device, using a protocol of the device model of the device (Par. 0064, Plant network 406 may conform to any suitable networking protocol or combination of protocols. Par. 0164, The system's translation engine can include knowledge of the types and formats of security event configuration instructions supported by a range of different device types and vendors, allowing the system to appropriately map the security event management policies defined by the model to a set of vendor- and model-specific device-level security event configuration instructions in order to implement the defined security policy. At 2016, the security event configuration instructions generated at step 2014 are sent to the appropriate industrial assets on the plant floor (e.g., via the plant network)).
Regarding claim 10, The computer-implemented method of claim 1,
Huffman in view of Kang in further view of Sanaullah in further view of Perneti further discloses, after applying the preferred configuration settings to the device, automatically performing an inventory operation for the device by the device service platform, the inventory operation comprising (i) establishing a remote connection to the device, (ii) executing [[a]] the configuration settings collection script that is specific to the device model of the device and that collects the current configuration settings of the device (Sanaullah Par. 0238, The instrumentation plug-in 1404 may scan for device settings across the various devices in the conference room and send data indicative of the device settings to the telemetry ingest 1403. The recommender service 1401 may pull this data to compare against original policy-applied (i.e. configuration policy has previously been applied and scanning of current policy after the previously applied configuration policy)) configuration settings to monitor configuration drift), and (iii) storing, at an inventory data store that is external to the device service platform, data that represents the current configuration settings, data that represents the facility at which the device is located, the device identifier of the device, and the network address for the device (Huffman Par. 0095, A Device Definition table 704 may include information defining the inventory of industrial assets and devices for which the plant-wide security strategy is to be implemented. For embodiments that support auto-discovery, at least some of this device information may be discovered automatically by the device discovery component 210, including but not limited to asset catalog numbers (i.e. device identifier) and current IP addresses (i.e. network address), Par. 0101, fig. 7A, 8A, a table illustrating example user configuration input that can be provided to (or, in some cases, automatically discovered by) security configuration system 202, and FIG. 8B is a diagram representing the security policy. In this example, devices D2-D3 all support CIP security and are assigned to the same zone (Zone 1). Device D4, assigned to Zone 2, i.e. storing the data which represents, zones (i.e. different facilities as disclosed in par. 0083, along with IP address and asset catalog numbers (i.e. device identifier)).
Regarding claim 11, The computer-implemented method of claim 10,
Huffman in view of Kang in further view of Sanaullah in further view of Perneti further discloses, wherein the inventory operation runs on a server that is within a same local area network (LAN) as the device, and wherein the configuration operation runs on a server that is external to the LAN (Sanaullah Fig. 5, par.0090, conference room clients are connected to video bar (par. 0070-0072 discloses, communication between video bar and other devices via WiFi), (Sanaullah Par. 0238, The instrumentation plug-in 1404 (residing on local video bar or Host located in conference room connected via Wi-Fi to other devices within conference room) may scan for device settings across the various devices in the conference room and send data indicative of the device settings to the telemetry ingest 1403, The recommender service 1401 (Sanaullah par. 0236, fig. 7 discloses, Recommender service 1401 is part of peripheral management service 503 is part of cloud, i.e. remotely running) may pull this data to compare against original policy-applied (i.e. configuration policy has previously been applied and scanning of current policy after the previously applied configuration policy)) configuration settings to monitor configuration drift).
Regarding claims 13, Huffman in view of Kang in further view of Sanaullah in further view of Perneti meets the claim limitations as set forth in claim 1.
Regarding claims 14, Huffman in view of Kang in further view of Sanaullah in further view of Perneti meets the claim limitations as set forth in claim 2-4.
Regarding claims 15, Huffman meets the claim limitations as set forth in claim 5.
Regarding claims 16, Huffman meets the claim limitations as set forth in claim 6.
Regarding claims 17, Huffman meets the claim limitations as set forth in claim 8.
Regarding claims 18, Huffman meets the claim limitations as set forth in claim 9.
Regarding claims 19, Huffman meets the claim limitations as set forth in claim 10.
Regarding claims 20, Huffman meets the claim limitations as set forth in claim
Regarding claim 21, The computer-implemented method of claim 1,
Huffman further discloses, wherein the preferred configuration settings include one or more of security settings, network configuration settings, system settings, analytics settings, and event handling settings (Par. 0054, The configuration system translates the defined security policy into device-level security configuration instructions that are then downloaded or otherwise sent to the appropriate devices (e.g., network infrastructure devices and/or industrial devices) in order to implement the defined security policy).
Regarding claim 22, The computer-implemented method of claim 1, Huffman in view of Kang in further view of Sanaullah in further view of Perneti further discloses, wherein determining whether configuration drift has occurred on the device is performed according to a periodic schedule (Perneti Par. 0075-0076 This configuration drift determination process can be configured to run at a regular interval of time (e.g., once in a week) Automatic response actions can be assigned to different defined threshold values or ranges to trigger corresponding actions, for those identified configuration drifts that belongs to the red range, trigger an immediate action to reset the running configuration to the golden configuration).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AKSHAY DOSHI whose telephone number is (571)272-2736. The examiner can normally be reached M-F 9:30 AM to 6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JOHN W MILLER can be reached at (571)272-7353. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.D./Examiner, Art Unit 2422
/JOHN W MILLER/Supervisory Patent Examiner, Art Unit 2422
Prosecution Insights