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 .
Election/Restrictions
Applicant’s election without traverse of claims 1-8, 10, 11, 13-20, 22, and 23 in the reply filed on 1/5/2026 is acknowledged.
Claim Objections
Claims 1-6, 8-13, 16, 21, 22, and 24 are objected to because of the following informalities:
Claim 1, lines 1-2 recite “secure compartmentalization for Internet of Things (IoT) application” which should be changed to --secure compartmentalization for Internet of Things (IoT) applications--.
Claims 2-6, 8-10, and 12 recite “The method of secure compartmentalization for IoT application” which should be changed to --The method of secure compartmentalization for IoT applications--.
Claim 4, page 2, line 1 recites “OT service applications” which should be changed to --OT service application--.
Claim 11, lines 2-3 recite “from untrusted network” which should be changed to --from an untrusted network--.
Claim 13, line 1 recites “An Internet of Things gateway” which should be changed to --An Internet of Things (IoT) gateway--.
Claim 16, line 4 “OT service applications” which should be changed to --OT service application--.
Claim 21, line 4 recites “untrusted zone” which should be changed to --an untrusted zone--.
Claim 22, line 1 recites “An Internet of Things gateway” which should be changed to --The Internet of Things gateway--.
Claim 24, line 1 “An Internet of Things gateway” which should be changed to --The Internet of Things gateway--.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7 and 11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7 recites the limitation "The method for secure partitioning of Internet of Things applications" in lines 1 and 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitation “The method for secure zoning of Internet of Things applications” in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 4, 5, 7, 10, 11, 13, 14, 16, 17, 19, 22, and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over “McLinden “(US 11973783) in view of “Fellows” (US 2019/0260781).
Regarding Claim 1:
McLinden teaches:
A method of secure compartmentalization for Internet of Things (IoT) application, adapted to an IoT gateway (Col. 5, lines 21-24, “The SAPSIN device 108 may be a computing device at the network border, serving as a gateway between protected devices and unprotected wide area networks (WAN) or the Internet”), and comprising:
creating a plurality of zones corresponding to a plurality of subnets by partitioning the subnets (Fig. 2, step 202; Col. 7, lines 16-21, “At step 202, the SAPSIN may segment the IoT network into two virtual networks: a service network and a control network with the service network providing access control for service request data packets, and the control network providing access control for configuration request data packets”);
…
configuring a conduit policy associated with at least one of the zones (Col. 8, lines 9-20, “At step 208, the SAPSIN device may apply security rules based on the type of the request. Each virtual network (e.g., service network and control network) may define a respective set of rules. Specifically, the SAPSIN device may determine access control rules for the service network by translating administratively defined services into rules for a micro-firewall, packet filtering rules, routing configuration, and access control lists. For example, the SAPSIN may provide a service-based model that defines the addresses, ports, protocols, applications, and similar network metrics for allowed connection to protected devices. The SAPSIN may store the access control rule in the security database”); and
managing packet transmission of the zones based on the conduit policy (Col. 8, lines 21-27, “When the SAPSIN device receives a service request demanding service from an IoT device, the SAPSIN device may apply the defined rules by checking whether the request satisfies the network metrics of the rules. Specifically, the SAPSIN device may query the security database based on the IoT device identifier to retrieve a service data record associated with the device”).
McLinden does not disclose:
deploying an application installed in the IoT gateway to one of the zones;
Fellows teaches:
deploying an application installed in the IoT gateway one of the zones (Fig. 1 details a Cyber Security Appliance containing a respective IT module and OT module each being deployed to a respective IT or OT zone shown in Fig. 4; ¶0051, “By identifying unexpected anomalies in behavior, the cyber defense appliance autonomously defends against all threat types from … IoT hacks, as they emerge, at the earliest stage of the attack life cycle”);
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify McLinden’s system to prevent attacks in IoT networks by enhancing McLinden’s SAPSIN to deploy specific modules corresponding to respective network zones, such as an Information Technology zone and an Operational Technology zone, as taught by Fellows, in order to provide real-time threat monitoring to specific network zones.
The motivation is to enhance visibility of network zones to be monitored by utilizing specific application modules to “plug” into each respective network zone. This allows for a centralized view of what is happening within the network zones, which can be advantageous in order to detect cyber threats, malfunctions, or misconfigurations of devices within the network zones in a real-time manner (Fellows, ¶0035; ¶0036; ¶0109).
Regarding Claim 2:
The method of secure compartmentalization for IoT application according to claim 1, wherein McLinden in view of Fellows further teaches the step of creating the zones corresponding to the subnets by partitioning the subnets comprising:
partitioning the subnets by establishing a virtual network interface (McLinden, Col. 7, lines 16-25, “At step 202, the SAPSIN may segment the IoT network into two virtual networks: a service network and a control network with the service network providing access control for service request data packets, and the control network providing access control for configuration request data packets. The SAPSIN may give a virtual route through the service network to traffic requesting data or services from an IoT device; the SPASIN may give a virtual route through the control network to traffic requesting configuration or administration of an IoT device”), wherein each of the plurality of subnets corresponds to an IP address range (McLinden, Col. 10, lines 35-38, “Specifically, the SAPSIN may allow or disallow access to IoT device based on a combination of transport, session, presentation or application protocol; inbound or outbound IP address or IP range…”).
Regarding Claim 4:
The method of secure compartmentalization for IoT application according to claim 1, wherein McLinden in view of Fellows further teaches the zones comprise an Information Technology (IT) service zone (Fellows, Fig. 4 - “IT Network”) and an Operational Technology (OT) service zone (Fellows, Fig. 4 - “OT Network”), the IT service zone comprises at least one ITservice application (Fellows, Fig. 1 details an IT Module corresponding to the IT network; ¶0060, “… FIG. 4 illustrates a block diagram of an embodiment of an example central cyber security appliance 100 with its modules and machine-learning models using probes to monitor the informational technology network and the OT network”), and the OT service zone comprises at least one OT service applications (Fellows, Fig. 1 details an OT module corresponding to the OT network; ¶0060, “… FIG. 4 illustrates a block diagram of an embodiment of an example central cyber security appliance 100 with its modules and machine-learning models using probes to monitor the informational technology network and the OT network”).
The motivation to combine Fellows to McLinden for the rejection of claim 4 is the same motivation recited for the rejection of claim 1 above.
Regarding Claim 5:
The method of secure compartmentalization for IoT application according to claim 4, wherein McLinden in view of Fellows further teaches the zones further comprise an administration zone (Fellows, Fig. 4 - “Cyber Security Appliance” is considered as an “administration zone”), and the administration zone comprises at least one security service application (Fellows, Fig. 3 details that the centralized Cyber Security Appliance has a Graphical User Interface & Display Screen installed within it).
The motivation to combine Fellows to McLinden for the rejection of claim 5 is the same motivation recited for the rejection of claim 1 above.
Regarding Claim 7:
The method for secure partitioning of Internet of Things applications according to claim 1, McLinden in view of Fellows further comprising:
obtaining a zoning label of the application, wherein the zoning label corresponds to the one of the plurality of zones (Fellows, ¶0084, “Thus, the user interface is configurable to program in different responses and authorized autonomous responses in different zones for the OT network, those zones comprising … user defined tags”).
The motivation to combine Fellows to McLinden for the rejection of claim 7 is the same motivation recited for the rejection of claim 1 above.
Regarding Claim 10:
The method of secure compartmentalization for IoT application according to claim 1, wherein McLinden in view of Fellows further teaches the zones comprise a first zone, a second zone and a third zone (McLinden, Col. 5, lines 40-42, “The SAPSIN 108 may divide the protected network space into three categories: WAN, control network 110, and service network 112”), and the conduit policy associated with the third zone comprises a plurality of rules (McLinden, Col. 8, lines 9-19, “At step 208, the SAPSIN device may apply security rules based on the type of the request. Each virtual network (e.g., service network and control network) may define a respective set of rules. Specifically, the SAPSIN device may determine access control rules for the service network by translating administratively defined services into rules for a micro-firewall, packet filtering rules, routing configuration, and access control lists. For example, the SAPSIN may provide a service-based model that defines the addresses, ports, protocols, applications, and similar network metrics for allowed connection to protected devices”), and the rules comprise denying packet transmission between a first application in the first zone or the second zone and a second application in the third zone (McLinden, Col. 5, lines 54-64, “The service network 112 may maintain network state information such as traffic source and destination, flow, and bandwidth. The SAPSIN 108 may combine and analyze the metrics to provide security features such as distributed denial of service (DDoS) attack detection and address resolution protocol (ARP) scan detection. The service network 112 may not allow IoT device-to-device traffic, unless specifically configured by a device-to-device service”; Col. 8, lines 5-8, “For example, the SAPSIN device may determine the requests demanding a device to execute certain software, run certain executable codes, change system setup, and the like, are configuration requests”), or allowing packet transmission between the first application in the first zone or the second zone and the second application in the third zone.
Regarding Claim 11:
The method for secure zoning of Internet of Things applications according to claim 10, wherein McLinden in view of Fellows further teaches the rules further comprise denying packets to be transmitted from untrusted network to the third zone (McLinden, Col. 5, lines 43-45, “The SAPSIN 108 may strictly regulate the access to the IoT devices through the WAN to prevent external configuration or attack”).
Regarding Claim 13:
McLinden teaches:
An Internet of Things gateway (Col. 5, lines 21-24, “The SAPSIN device 108 may be a computing device at the network border, serving as a gateway between protected devices and unprotected wide area networks (WAN) or the Internet”), comprising:
a transceiver (Col. 5, lines 21-24, “The SAPSIN device 108 may be a computing device at the network border, serving as a gateway…”);
a storage device Col. 5, lines 21-24, “The SAPSIN device 108 may be a computing device …”); and
a processor connected to the transceiver and the storage device (Col. 4, lines 14-17, “The SAPSIN 108 may be software and hardware components at a computing device configured to offer protection for a broad range of internet enabled devices”), and configured to:
create a plurality of zones corresponding to a plurality of subnets by partitioning the subnets (Fig. 2, step 202; Col. 7, lines 16-21, “At step 202, the SAPSIN may segment the IoT network into two virtual networks: a service network and a control network with the service network providing access control for service request data packets, and the control network providing access control for configuration request data packets”);
…
configure a conduit policy associated with at lest one of the zones (Col. 8, lines 9-20, “At step 208, the SAPSIN device may apply security rules based on the type of the request. Each virtual network (e.g., service network and control network) may define a respective set of rules. Specifically, the SAPSIN device may determine access control rules for the service network by translating administratively defined services into rules for a micro-firewall, packet filtering rules, routing configuration, and access control lists. For example, the SAPSIN may provide a service-based model that defines the addresses, ports, protocols, applications, and similar network metrics for allowed connection to protected devices. The SAPSIN may store the access control rule in the security database”); and
manage packet transmission of the zones based on the conduit policy (Col. 8, lines 21-27, “When the SAPSIN device receives a service request demanding service from an IoT device, the SAPSIN device may apply the defined rules by checking whether the request satisfies the network metrics of the rules. Specifically, the SAPSIN device may query the security database based on the IoT device identifier to retrieve a service data record associated with the device”).
McLinden does not disclose:
deploy an application installed in the IoT gateway to one of the zones;
Fellows teaches:
deploy an application installed in the IoT gateway one of the zones (Fig. 1 details a Cyber Security Appliance containing a respective IT module and OT module each being deployed to a respective IT or OT zone shown in Fig. 4; ¶0051, “By identifying unexpected anomalies in behavior, the cyber defense appliance autonomously defends against all threat types from … IoT hacks, as they emerge, at the earliest stage of the attack life cycle”);
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify McLinden’s system to prevent attacks in IoT networks by enhancing McLinden’s SAPSIN to deploy specific modules corresponding to respective network zones, such as an Information Technology zone and an Operational Technology zone, as taught by Fellows, in order to provide real-time threat monitoring to specific network zones.
The motivation is to enhance visibility of network zones to be monitored by utilizing specific application modules to “plug” into each respective network zone. This allows for a centralized view of what is happening within the network zones, which can be advantageous in order to detect cyber threats, malfunctions, or misconfigurations of devices within the network zones in a real-time manner (Fellows, ¶0035; ¶0036; ¶0109).
Regarding Claims 14, 16, 17, 19, 22, and 23:
Internet of Things gateway claims 14, 16, 17, 19, 22, and 23 correspond to respective method claims 2, 4, 5, 7, 10, and 11, and contain no further limitations. Therefore claims 14, 16, 17, 19, 22, and 23 are rejected by applying the same rationale used to reject claims 2, 4, 5, 7, 10, and 11 above, respectively.
Claim(s) 3, 8, 15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “McLinden “(US 11973783) in view of “Fellows” (US 2019/0260781) in further view of “Berdy” (US 2020/0145415).
Regarding Claim 3:
McLinden in view of Fellows teaches:
The method of secure compartmentalization for IoT application according to claim 2, …
McLinden in view of Fellows does not disclose:
… wherein the step of deploying the application installed in the IoT gateway to the one of the zones comprising:
assigning a specific IP address within the IP address range of one of the subnets to the application to deploy the application to the one of the zones corresponding to the one of the subnets.
Berdy teaches:
… wherein the step of deploying the application installed in the IoT gateway to the one of the zones comprising:
assigning a specific IP address within the IP address range of one of the subnets to the application (¶0038, “The application layer 205, in this illustrative example, supports various applications 265 including an automated assignment application 260. Any number of applications can be utilized by the IoT device 105, whether proprietary or third-party applications. The applications can be implemented using locally executing code. However, in some cases, applications can rely on services and/or remote code execution provided by remote servers or other computing platforms”) to deploy the application to the one of the zones corresponding to the one of the subnets (Fig. 5, elements 5351, 5352, & 535N; ¶0004, “In some implementations, multiple subnets can be created behind a single networking device by using a subnet mask and reconfiguring the IP (Internet Protocol) addresses for the host IoT devices. IoT device users (e.g., customers for the IoT solutions) may set network configuration, create subnets, and assign the IoT devices subnets to specific IoT solutions using an IoT device management application”; ¶0005, “For example, an option may include the IoT hub automatically assigning newly connecting IoT devices to an IoT solution to which an existing group of devices is connected from the same subnet”).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify McLinden in view of Fellows’ system to prevent attacks in IoT networks by enhancing McLinden in view of Fellows’ SAPSIN to assign specific IP address ranges to specific subnets while deploying an application to one of the subsets, as taught by Berdy, in order to divide up services provided by IoT devices via an associated label.
The motivation is to provide easier configuration and management of groups of IoT devices by labeling the groups of IoT devices based on their service/application affiliation. Thus, IoT devices providing services corresponding to HVAC systems can be grouped separately from IoT devices providing services corresponding to a Tech. department (Berdy, Fig. 5), thereby allowing for easier management of the IoT devices.
Regarding Claim 8:
McLinden in view of Fellows teaches:
The method of secure compartmentalization for IoT application according to claim 7, …
McLinden in view of Fellows does not disclose:
… wherein the step of deploying the application installed in the IoT gateway to the one of the plurality of zones comprises:
deploying the application to the one of the zones according to the zoning label of the application when installing the application on the IoT gateway.
Berdy teaches:
… wherein the step of deploying the application installed in the IoT gateway to the one of the plurality of zones comprises:
deploying the application to the one of the zones according to the zoning label of the application (¶0045, “Each subnet 505, 510, and 515 may be, for example, associated with specific departments or divisions within an organization, such as an HVAC department, technology department, and manufacturing department, respectively. The IoT solution utilized by the respective departments are analytics 520, data storage 525, and machine learning 530. Thus, the IoT solution utilized for specific departments may vary since each department may be using cloud services for different purposes. The assignment to IoT solutions based on the subnet facilitates a device-based virtual local area network (VLAN) environment”) when installing the application on the IoT gateway (Abstract, “Upon the user setting up an IoT device's network connection to a network device, such as a router, the IoT device transmits its network information to the IoT hub. The IoT hub can then automatically assign the IoT device to a specific IoT solution without further user input or predict which IoT solution to utilize for that IoT device based on known parameters”).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify McLinden in view of Fellows’ system to prevent attacks in IoT networks by enhancing McLinden in view of Fellows’ SAPSIN to deploy application services to specific subnet groups according to the service type, as taught by Berdy, in order to divide up services provided by IoT devices via an associated label.
The motivation is to provide easier configuration and management of groups of IoT devices by labeling the groups of IoT devices based on their service/application affiliation. Thus, IoT devices providing services corresponding to HVAC systems can be grouped separately from IoT devices providing services corresponding to a Tech. department (Berdy, Fig. 5), thereby allowing for easier management of the IoT devices.
Regarding Claims 15 and 20:
Internet of Things gateway claims 15 and 20 correspond to respective method claims 3 and 8, and contain no further limitations. Therefore claims 15 and 20 are rejected by applying the same rationale used to reject claims 3 and 8 above, respectively.
Allowable Subject Matter
Claims 6 and 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: The prior art of record does not fairly teach or suggest, either alone or in combination, the subject matter recited within respective claims 6 and 18. Therefore claims 6 and 18, when considered in view of their respective base claims and intervening claims, are deemed allowable over the prior art of record.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B POTRATZ whose telephone number is (571)270-5329. The examiner can normally be reached on M-F 10 A.M. - 6 P.M. CST.
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, William Korzuch can be reached on 571-272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491