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 .
DETAILED ACTION
Response to Arguments
Applicant’s arguments filed 07/22/2025 have been fully considered. After further consideration, a new ground(s) of rejection is presented due to Applicant’s arguments.
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 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.
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.
Claims 1, 4, 6 – 8 and 11 – 13 are rejected under 35 U.S.C. 103 as being unpatentable over Caceres (US Pub. No. 2018/0359269 A1) in view of Dell (US Pub. No. 2018/0253569 Al) in view of Iomaxis (US Pub. No. 2016/0112374 Al).
Per claim 11, Caceres (US Pub. No. 2018/0359269 A1) suggests a device (reads on a network device performing one or more self-policing network governance functions, see Caceres para 0012, 0013, 0017, 0018, 0020, 0026, 0032 and 0052) for managing (reads on behavior monitoring and policy enforcement for user devices connecting to the network, see Caceres para 0036, 0037 and 0060 – 0061) a home gateway (reads on network device/ gateway combination, see Caceres para 0017, 0020, 0026, 0032 and 0039) of a local communication network (see Caceres para 0019, 0021 and 0026), said gateway comprising a plurality of components (reads on the components of Caceres Figure 2 and Figure 3), called sensitive components (reads on the components of Caceres para 0027, 0032 – 0039, Figure 2 and Figure 3), said network comprising (see Caceres para 0019, 0021 and 0026) at least one communicating object (reads on a user device 110/120, see Caceres para 0025 and Figure 1) able to be connected to (see Caceres para 0016) said network (see Caceres para 0019, 0021 and 0026) via the gateway (reads on network device/ gateway combination, see Caceres para 0017, 0020, 0026, 0032 and 0039), the device (reads on a network device performing one or more self-policing network governance functions, see Caceres para 0012, 0013, 0017, 0018, 0020, 0026, 0032 and 0052): a processor (reads on the processor of Caceres para 0027 and Figure 2); and a non-transitory computer readable medium (reads on the memory of Caceres para 0027 and Figure 2) comprising instructions stored thereon which when executed by the processor configure the device to (see Caceres para 0028 and 0031):
confine the object (reads on the function of the VLAN assignment that places the particular user device for further monitoring, see Caceres para 0037), comprising recording (reads on storing exemplary device id, attack patterns and violation details, blocked connection attempts, administrator alerts, historical compromise record and manufacturer notifications, see Caceres para 0035, 0036, 0063, 0069, 0073, 0075 and 0077. The Examiner asserts the prior art teaches when a device is deemed suspicious it is not the physical object but its state/data (ID, history and corresponding rules) that is confined) data (reads on exemplary device id, attack patterns and violation details, blocked connection attempts, administrator alerts, historical compromise record and manufacturer notifications, see Caceres para 0035, 0036, 0063, 0069, 0073, 0075 and 0077) of the object (reads on a user device 110/120, see Caceres para 0025 and Figure 1) in a memory zone, called confinement zone (reads on the VLAN assignment and profile database combination for further monitoring which tracks device identity, behaviors and security rules associated with confined/suspicious devices, see Caceres para 0035 – 0037, 0042 – 0045, 0050, 0053, 0069 and 0073. The Examiner asserts the memory/profile database stores the relevant data, and VLAN assignment tags/confines the device’s operations), said data comprising at least one identification datum of the object (reads on exemplary device id, attack patterns and violation details, blocked connection attempts, administrator alerts, historical compromise record and manufacturer notifications, see Caceres para 0035, 0036, 0063, 0069, 0073, 0075 and 0077) and at least one security rule (reads on expected behaviors, limits and restrictions, see Caceres para 0035, 0042 – 0045, 0053, 0057 – 0076. The Examiner asserts the stored profile rules are the basis for quarantine decisions and ongoing enforcement within the VLAN creating a unified confinement zone), said at least one security rule relating to (reads on device profile behavioral constraints, see Caceres para 0042 – 0045) at least one possible interaction (rads on the communications sent from/to each user device with the gateway, see Caceres para 0036 and 0066) of said object (reads on a user device 110/120, see Caceres para 0025 and Figure 1) with at least one of said sensitive components (reads on the components of Caceres para 0027, 0032 – 0039, Figure 2 and Figure 3) of said gateway (reads on network device/ gateway combination, see Caceres para 0017, 0020, 0026, 0032 and 0039);
observe (reads on a gateway/network device monitoring communications from a user device coupled to the network, see Caceres claim 1) at least one interaction of (reads on gateway/network device monitoring communications, see Caceres para 0036 and claim 1. The Examiner asserts one of ordinary skill in the art would consider the monitoring of communications at least an implicit interaction between the user device and the gateway/network device because of the conventional ways in which monitoring of communication is performed) said communicating object (reads on a user device 110/120, see Caceres para 0025 and Figure 1) with the at least one of said sensitive components of (reads on the exemplary behavior monitoring logic, see Caceres para 0036) said gateway (reads on network device/ gateway combination, see Caceres para 0017, 0020, 0026, 0032 and 0039); and
decide (reads on determine if the user device is operating outside its normal parameters, see Caceres para 0036), on the basis of said observation (reads on a gateway/network device monitoring communications from a user device coupled to the network, see Caceres claim 1), on at least one action to be performed on (reads on blocking at least some communications from being transmitted to or received by the user device in response to determining the device is not operating within its normal parameters, see Caceres para 0036 and claim 1) said object (reads on a user device 110/120, see Caceres para 0025 and Figure 1) in response to said object not meeting said at least one security rule (reads on after is determined the device is operating in a manner not in accordance with its profile, see Caceres para 0036, 0037, 0068, 0071 and 0073). The prior art of record is silent on explicitly stating observing at least one interaction of said communicating object with the at least one of said sensitive components of said gateway; and remove the object from said confinement when a deconfinement criterion is met, during which said recording of the object data is removed from said confinement zone.
[0012] Various other devices in the network (e.g., a gateway or router device) may then act to self-police the network by enforcing the device profiles, without the need for human intervention or monitoring. For example, in situations in which a device is not operating in accordance with its profile, another network device (e.g., a peer device, a router, a gateway, a service provider, etc.) may report suspicious activity associated with the operating behavior of the device. The suspicious activity may be reported to a gateway or router located closest to the suspicious device, to an Internet service provider (ISP) providing Internet access to the suspicious device, etc. The gateway/router, ISP or other network device receiving the indication of suspicious activity may then limit or prohibit at least some communications from being transmitted by or received by the suspicious device. In some implementations, a gateway or other network device may place an offending or suspicious device that is not operating in accordance with its profile in a virtual local area network (VLAN) in which its operations may be more easily monitored and controlled.
[0013] In this manner, a self-policing network governance structure allows for real time or near real time monitoring of device behavior and dynamically enforcing policies or actions on devices that have potentially been compromised with malware or other harmful software/hardware, and/or may be involved in a network attack. This monitoring and enforcement of network policies allows for quicker responses to network attacks, thereby reducing the likelihood that such attacks will be successful. In addition, by proactively monitoring the behavior of network devices, networks and/or network administrators may more quickly determine that various devices may have been compromised, thereby allowing networks, to rectify the potential problems and allow the network devices to resume normal operations. Still further, self-policing of network devices may allow manufacturers and/or service providers associated with various devices to become aware of potential malware issues or vulnerabilities of their devices more quickly. This may allow the manufacturers to proactively fix the problems (e.g., download software patches) before the malware, virus, etc., infects thousands of other devices and/or causes the compromised devices to be involved in network attacks, thereby further enhancing network security.
[0016] User devices 110 may be part of a local area network (LAN) or wide area network (WAN), such as network 112 which may be a home LAN associated with a customer premises or home. User devices 120 may similarly be part of a LAN or WAN, such as network 122 which may be a LAN or WAN associated with a business, corporation, educational institution, etc. User devices 110 may connect to network 112 and other devices in environment 100 (e.g., network device 114, gateway device 130, networks 150 and 190, etc.), and user devices 120 may connect to network 122 and other devices in environment 100 (e.g., network device 124, gateway device 140, networks 160 and 190, etc.) via any conventional technique, such as wired, wireless, optical connections or a combination of these techniques. User device 110 and user device 120 and the person associated with user device 110 or user device 120 (e.g., the party holding or using user device 110 or 120, the owner of user device 110 or 120) may be referred to collectively as user device 110 or user device 120, respectively, in the description below.
[0017] Network device 114 may correspond to a broadband home router or other routing device that acts as a gateway for devices connected via network 112 to communicate with external networks, such as network 150 and/or 190. Similarly, network device 124 may correspond to a local broadband router or other routing device that acts as a gateway for devices connected via network 122 to communicate with external networks, such as network 160 and/or 190.
[0018] Network device 114 may act as a hub for communications to/from the customer's premises via network 112. For example, network 150 may be associated with an Internet service provider (ISP) that provides Internet access to user devices 110 connected to a customer's home LAN (e.g., network 112). In this case, network device 114 acts as a local router to route communications from user devices 110 to their appropriate destinations via network 150 and/or 190 and receive communications from network 150 and/or 190 and route the communications to the appropriate user device 110. Network device 124 may function in a similar manner as network device 114. That is, network device 124 may act as a hub for communications to/from network 122
[0019] As described above, network 112 may be a LAN or WAN associated with a customer's home and network 122 may be a LAN or WAN associated with a business, corporation, educational institution, etc. User devices 110 and user devices 120 may communicate via networks 112 and 122 via wired, wireless and/or optical connections.
[0020] Gateway device 130 may include one or more computing devices that act as a gateway for communications from network 112 to networks 150 and 190 and vice versa. Similarly, gateway device 140 may act as a gateway for communications from network 122 to networks 160 and 190. In one implementation, gateway device 130 may be associated with an ISP that provides Internet access to user devices 110 via networks 150 and 190. Similarly, gateway device 140 may be associated with a different ISP (e.g., a corporate ISP) that provides Internet access to devices in network 122 via networks 160 and 190.
[0026] Various functions are described below as being performed by particular components in environment 100. In other implementations, various functions described as being performed by one device may be performed by another device or multiple other devices, and/or various functions described as being performed by multiple devices may be combined and performed by a single device. In addition, although networks 150, 160 and 190 are shown as separate networks, in other implementations, these networks or portions of these networks may be included in a single network.
[0032] FIG. 3 is an exemplary functional block diagram of components implemented in network device 114. Network device 124 may be configured in a similar manner. In an exemplary implementation, all or some of the components illustrated in FIG. 3 may be implemented by processor 220 executing software instructions stored in memory 230.
[0036] Behavior monitoring logic 330 may include logic to identify behavior associated with the functioning of user devices 110. For example, behavior monitoring logic 330 may monitor each user device 110 and compare the behavior (e.g., communications sent from/to each user device 110) to profile information for each user device 110 stored in profile database 320. In this manner, behavior monitoring logic 330 may determine whether one or more of user devices 110 are operating outside its normal operating parameters. In such cases, behavior monitoring logic 330 may determine that user device 110 is “suspicious.” The term “suspicious” as used herein should be construed to indicate that the particular device is operating outside of its expected parameters and has potentially been affected by malware or other malicious hardware/software, has had its operations/functions taken over by an external entity or virus, or has potentially been compromised in any way and may be involved in a network attack or attempting to obtain confidential information (e.g., credit card information, a user's private information, a company's private information, etc).
[0037] Policy enforcement logic 340 may include logic to enforce network policies. For example, policy enforcement logic 340 may limit communications associated with one or more user devices 110 based on information received from behavior monitoring logic 330 indicating that a particular user device 110 is behaving in a suspicious manner. In this case, policy enforcement logic 340 may enforce communication-related restrictions with respect to operations of user device 110. In one implementation, if a particular user device 110 is considered suspicious, such as compromised with malicious hardware and/or software, policy enforcement logic 340 may place the particular user device 110 in a virtual local area network (VLAN) for further monitoring, as described in detail below.
[0039] Although FIG. 3 shows exemplary components of network device 114, in other implementations, network device 114 may include fewer components, different components, differently arranged components, or additional components than depicted in FIG. 3. In addition, functions described as being performed by one of the components in FIG. 3 may alternatively be performed by another one or more of the components of network device 114.
[0052] Assuming that profile 500 was validated, profile manager 180 may then distribute user device profile 500 to appropriate entities at a later time. For example, assume that user device 110-1 attaches to network 112 and network device 114. As described above, network device 114 may function as a gateway or home router for communications to/from user devices 110. When user device 110-1 attempts to attach to network 112 and network device 114, user device 110-1 may transmit its device ID to network device 114 (FIG. 6, 620).
[0054] In other implementations, profile 500 may be distributed within environment 100 in other ways. For example, in one implementation, when user device 110-1 attaches to network 112, user device 110-1 may advertise its profile 500 as part of the procedure/protocol associated with attaching to network 112. For example, user device 110-1 may advertise its profile 500 as part of the Dynamic Host Configuration Protocol (DHCP) or the Address Configuration Protocol (ARP). Network device 114 may receive the advertisement and store the profile included in the advertisement in profile database 320. In addition, network device 114 may return information to user device 110-1 regarding network device 114 and/or network 112, thereby allowing user device 110-1 to establish awareness of the network to which it is attached (e.g., network 112).
[0055] In another implementation, profile 500 may be distributed as part of the network attachment procedure to network 112 via inquiry by other network devices. For example, in this implementation, gateway device 114 may send an inquiry to user device 110-1 to provide its profile 500 as part of the physical layer negotiations in accordance with the particular network protocol, such as physical layer negotiations associated with the IEEE 802.1X standard/protocol.
[0060] In addition, although the description above refers to network device 114 receiving (and later enforcing device profiles 500), it should be understood that profiles 500 stored by profile manager 180 may be distributed and enforced by any network element in environment 100, such as gateways (e.g., home routers), firewalls (e.g., layer 7 firewalls), peer devices (e.g., other user devices 110/120), etc. Since profile 500 contains information that covers multiple or all OSI layers, any network element may perform some type of action with respect to the user device 110's operating characteristics, thereby further enhancing security within environment 100.
[0061] As described above with respect to FIG. 4, when a user device 110 attaches to a network, such as network 112, network device 114 may retrieve or obtain the user device profile 500 and attempt to verify the profile. FIG. 7 illustrates processing associated with verifying user device profile 500 and provisioning services in environment 100. Processing may begin with determining whether profile 500 is verified (block 710). For example, network device 114 may determine whether user device profile 500 was received in response to a request from network device 114 to profile manager 180. If user device profile 500 was not received in response to such a request, network device 114 may determine that device profile 500 is not verified (block 710—no). In this case, network device 114 may determine that user device 110 is not to be trusted (block 720). For example, network device 114 may prohibit user device 110 from accessing an external network (e.g., network 150 and/or 190).
[0066] FIG. 8 illustrates exemplary processing associated with monitoring behavior and enforcing policies associated with operation of user devices 110. Processing may begin with network device 114 monitoring communications to/from user devices 110 in network 110 (block 810). For example, behavior monitoring logic 330 may determine whether communications to/from user devices 110 are in accordance with the respective user device profiles 500 associated with each user device 110 stored in profile database 320. Network device 114 may then determine whether any activity with respect to user devices 110 is considered to be suspicious activity (block 820). For example, as described above, user device profile 500 stores data profiles 500 that identify the types, length, payload size, distances, etc., associated with typical communications to/from user devices 110. User device profiles 500 also stores acceptable FQDN hosts/servers with which each user device 110 typically communicates, time profiles for typical communications to/from each user device 110, etc. Behavior monitoring logic 330 may determine whether the communications to/from user devices 110 are in accordance with the stored user device profiles 500.
[0073] Alternatively, or in addition to gateway 130 limiting communications to/from user device 110-1, in one implementation, network device 114 may place or assign user device 110-1 that is exhibiting suspicious activity into a virtual local area network (VLAN) for further monitoring (block 850). For example, policy enforcement logic 340 may create a VLAN in which potentially compromised devices will be monitored and/or such devices may be restricted from transmitting/receiving communications outside network 112.
[0076] Network device 114 may then continue to monitor device behavior and perform various actions (block 860). For example, network device 114 may place suspicious network devices into a VLAN and block communications in accordance with the respective user devices profiles 500.
[0079] Implementations described herein provide for monitoring and policing networks in a distributed manner. User devices 110/120 may be monitored for compliance with fingerprints or profiles that may be dynamically distributed to various devices for monitoring, policing and network protection purposes. The profiles may also be dynamically modified in accordance with changing network requirements. In this manner, device behavior may be monitored in real time in accordance with up-to-date device profiles. In addition, network devices may effectively “quarantine” suspicious devices, such as placing such devices in a VLAN and continuing to monitor such devices in the VLAN, by limiting communications to/from the suspicious devices. This may allow networks to effectively thwart attacks, such as DDoS attacks at their sources.
1. A method, comprising: monitoring, by a first network device, communications from a first user device coupled to a network; determining, by the first network device and based on the communications, whether the first user device is operating in accordance with a profile associated with the first user device; transmitting, by the first network device, a message to a second network device in response to determining that the first user device is not operating in accordance with the profile; and blocking, by the first network device or the second network device, at least some communications from being transmitted to or received by the first user device, in response to determining that the first user device is not operating in accordance with the profile.
2. The method of claim 1, further comprising: assigning the first user device to a virtual local area network (VLAN) in response to determining that the first user device is not operating in accordance with the profile; continuing to monitor, by the first network device, communications from the first user device after the first user device is assigned to the VLAN; and enforcing, by the first network device and after the first user device is assigned to the VLAN, communications to and from the first user device in accordance with the profile.
Dell (US Pub. No. 2018/0253569 Al) is relied upon to teach
at least one security rule (reads on Dell para [0100]: “device, behavior, and resource management service 409 may detect anomalous levels of resource consumption by a service or on an interface compared to an ongoing baseline”), said at least one security rule relating to at least one possible interaction of said object with at least one of said sensitive components of said gateway (reads on Dell para [0100]: “This action may include postponing low priority actions, reducing collection rate, volume, devices served, stopping services, and disabling interfaces”; and reads on Dell para [0110]: “techniques are presented for optimizing IoT gateway performance based on utilization and saturation rates, as well as other factors, of not only the internal components of the gateway (such as the CPU) but also of external devices connected to disparate bus architectures”. The Examiner asserts Dell provides per-device resource consumption monitoring and limits specifically governing each IoT device’s interaction with the gateway’s CPU, memory, bus, and interfaces - exactly the “sensitive components” of the gateway - the CPU, memory, bus, and interfaces - as claimed. The Examiner further asserts Dell para [0068] expressly states that “core services 402 include the following modules or microservices: core data service 407; command service 408; device, behavior, and resource management service 409; and registry and configuration service 410” - establishing a concrete, enabled per-device resource management and enforcement structure); and
observe at least one interaction of said communicating object with the at least one of said sensitive components of said gateway (reads on Dell para [0094]: “systems and methods described herein may augment or enhance the identity of a device by measuring various hardware and software based interactions with it and tracking them over time to establish a pattern of device characteristics and behavior. Once the behavioral pattern is established, then deviations from that pattern may be detected and preventive and corrective actions taken to protect against malicious behavior”. The Examiner asserts Dell’s resource management service 409 continuously and per-device monitors the IoT device’s consumption of each gateway hardware resource (CPU cycles, memory, bus, interfaces), which is precisely ‘‘observing ... interaction of said communicating object with ... sensitive components of said gateway” - the CPU, memory, bus, and interfaces being the recited sensitive components - satisfying “observing interactions with sensitive components” under the broadest reasonable interpretation because “observing interactions” with a hardware resource encompasses measuring that resource’s consumption by the connected IoT device, which is precisely what Dell’s resource management service 409 does); decide, on the basis of said observation, on at least one action on said object in response to said object not meeting said at least one security rule (reads on Dell para [0100]: “the resource management service 409 ... enforcement [includes] postponing low priority actions, reducing collection rate, volume, devices served, stopping services, and disabling interfaces”).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the IoT home gateway behavior-monitoring and policy-enforcement teachings of the prior art of record by integrating the per-device gateway resource observation and enforcement teachings of Dell (see Dell para [0068], [0094], [0100] and [0110]) to realize the instant limitation. Under KSR International Co. v. Teleflex Inc., 550 U.S. 398 (2007), 82 U.S.P.Q.2d 1385, this combination is supported by MPEP § 2143 Rationale A (combining prior art elements each performing its known function to yield a predictable result) and MPEP § 2143 Rationale C (applying the known technique of one reference to a similar device or method in the same field to yield a predictable result). Both Caceres and Dell operate in the same technical field of IoT device security and gateway resource management for home and enterprise networks: Caceres discloses a network device that monitors user device behavior and enforces profile-based policies at a gateway (see Caceres para [0012], [0013], [0036] and [0037]), while Dell discloses a gateway-resident “device, behavior, and resource management service 409” that continuously monitors per-IoT-device consumption of gateway hardware resources - CPU, memory, bus, and interfaces - and enforces corrective actions when anomalous levels are detected (see Dell para [0068], [0094] and [0100]). Both references address the same fundamental problem that Dell itself identifies in its own disclosure: IoT gateways are constrained in performance and security by the behaviors of the heterogeneous IoT devices connected to them. and existing approaches do not monitor or limit each device’s consumption of the gateway’s internal hardware resources. Dell expressly states this problem: ‘IoT gateways are challenged in implementing similar methods to maintain an optimal internal state because, among other things, they aggregate data across a broad and heterogeneous set of IoT devices. Moreover, IoT gateways are constrained in performance by a number of internal factors such as power, thermals, and available bandwidth to end points” (Dell para [0109]); and Dell further identifies that”[a] resource usage anomaly may cause the overload prevention module to take steps to prevent anomalous or excessive traffic from entering the system and configure the gateway to work around the affected services or interfaces” (Dell para [0099]). Dell expressly solves this problem by monitoring the IoT device’s interactions with the gateway’s internal hardware components (CPU utilization, memory, bus saturation, interface throughput) and enforcing per-device resource limits (see Dell para [0100]: “device, behavior, and resource management service 409 may detect anomalous levels of resource consumption by a service or on an interface compared to an ongoing baseline ... This action may include postponing low priority actions, reducing collection rate, volume, devices served, stopping services, and disabling interfaces”; and Dell para [0100]: “techniques are presented for optimizing IoT gateway performance based on utilization and saturation rates, as well as other factors, of not only the internal components of the gateway (such as the CPU) but also of external devices connected to disparate bus architectures”). Integrating Dell’s resource-monitoring teachings into Caceres’s behavior-monitoring gateway system does not change the fundamental operation of either reference: Caceres continues to operate as a profile-based behavior-monitoring and policy-enforcement network device; Dell’s resource management service 409 continues to measure per-device hardware consumption and enforce corrective actions. The combination merely extends the categories of device interactions monitored by Caceres’s existing gateway to include the per-device gateway-resource interactions taught by Dell, yielding the predictable result of a gateway that monitors each IoT device’s consumption of its sensitive hardware components (CPU, memory, bus, interfaces) in addition to its external communication behavior - thereby teaching the claimed security rule “relating to at least one possible interaction of said object with at least one of said sensitive components of said gateway” and the claimed step of “observing at least one interaction of said communicating object with the at least one of said sensitive components of said gateway,” as recited in claim 11. One of ordinary skill in the art in the field of IoT gateway security would have immediately recognized Dell para [0094]’s teaching that tracking “hardware and software based interactions” with an IoT device “over time to establish a pattern of device characteristics and behavior” - so that “deviations from that pattern may be detected and preventive and corrective actions taken” - is precisely the monitoring of “interactions with sensitive components” that the claimed method requires, and would have been motivated to incorporate that teaching into Caceres’ s existing enforcement architecture without any change to either reference’s principle of operation. The motivation to combine the references is applied to all claims below this heading.
Iomaxis (US Pub. No. 2016/0112374 Al) is relied upon to teach
configure the device to (reads on “a gateway device, comprising: a network interface ... a memory device including a local database storing internal firewall rules ... and a processor configured to execute: a network controller ... a firewall engine ... and a management interface,” see Iomaxis Claim 1. The Examiner asserts Iomaxis explicitly discloses a gateway device with a processor executing a management interface and firewall engine - satisfying “the managing being performed by a management device” under the broadest reasonable interpretation, as a management device is any device configured to manage a home gateway, which encompasses a gateway device executing its own management interface as in Iomaxis):
confine the object, comprising recording data of the object in a memory zone, called confinement zone (reads on “the device profile data 400 is generated and written to the local database’s 220 device profile database 222,” see Iomaxis para [0038]; and reads on “the device profile database 222, networks database 224 and firewall database 226 are internal to the gateway device 100,” see Iomaxis para [0033]). Iomaxis’ s creation of a per-device profile record in a gateway-internal memory-resident local database upon device connection is the functional and structural equivalent of “confining the object ... recording data ... in a memory zone” because both involve creating a new per-device record in a dedicated gateway resident data store with the effect of subjecting that device to active policy enforcement - exactly the structural and functional equivalent of recording the object in a confinement zone, matching Iomaxis’s local database 300 with device profile data 400. The Examiner further asserts under BRI, “recording data of the object in a memory zone called “confinement zone” encompasses any act of creating or storing a per-device data record in any memory space - internal or external, secure or not, accessible to the gateway - as that is the ordinary technical meaning of “memory zone” to one of ordinary skill in the art, encompassing any designated memory space or database in which per-device records are stored, regardless of whether the space is physically inside or outside the gateway device. Accordingly, “the device profile database 222, networks database 224 and firewall database 226 are internal to the gateway device 100” (see Iomaxis para [0033]) and “at block 302B, the device profile data 400 for the newly associated device is generated and written to the local database’s 220 device profile database 222” (see Iomaxis para [0038]) read directly on this limitation because lomaxis’s local database is a memory space in which per-device records are stored - satisfying the BRI of “confinement zone” in every respect), said data comprising at least one identification datum of the object (reads on “in an embodiment, the device profile data 400 includes the device MAC address 402, make 404, model 406, image 408, type 410, communication protocol(s) 412, communication port(s) 414, IP address 416, date added 418, network controller type 419, network association 420, physical location 422, description 424 and associated firewall rules 426,” see lomaxis para [0036]. Iomaxis’s device profile data 400 includes MAC address 402 and IP address 416 as identification data for each enrolled smart device - a verbatim functional match on “at least one identification datum of the object” as that term would ordinarily be understood by one of ordinary skill in the art to encompass network identifiers such as MAC address, IP address, UUID, or IMSI. as exemplified by Iomaxis’s explicit disclosure of MAC address 402 and IP address 416 as identification data (see Iomaxis para [0036])) and at least one security rule, said at least one security rule relating to at least one possible interaction of said object with at least one of said sensitive components of said gateway (reads on the “associated firewall rules 426” stored in the device profile data 400, see Iomaxis para [0036]; and reads on “Device firewall rules (both internal rules for controlling communication between devices within the private network, and external rules for controlling communication between devices in the private network and devices in an external network such as the Internet) are constructed using the firewall configuration 218 component of the management interface module 212” see Iomaxis para [0057]. Iomaxis provides per-device rules (associated firewall rules 426) stored alongside device identity in the local database; Dell provides per-device resource consumption limits specifically governing each IoT device’s interaction with the gateway’s CPU, memory, bus, and interfaces - exactly the “sensitive components” of the gateway as recited in the claim. In combination, the per-device database entry in Iomaxis would include the gateway-resource interaction rules taught by Dell, satisfying “at least one security rule relating to at least one possible interaction ... with at least one of said sensitive components.” The Examiner asserts Iomaxis para [0036] shows that ‘‘associated firewall rules 426” are already stored in the same device profile record as the device identity; the combination merely adds Dell’s resource-usage rules as additional entries in the same per-device record);
decide, on the basis of said observation, on at least one action to be performed on said object in response to said object not meeting said at least one security rule (reads on Iomaxis para [0069]: “when checkbox 720 is checked, the device state is set to suspended. When the device is in a suspended state, all device associated firewall rule data 800 is updated to have the suspend flag 820 set, identifying that the firewall rule should be ignored. Therefore, any firewall rule data 800 with the suspend flag 820 set is ignored by the firewall engine 210. This causes all the network communications to and from the suspended device to be dropped by the default firewall rules, as if there were no specific firewall rules configured for the device.” The Examiner further asserts the combination of Iomaxis’s violation-triggered enforcement decisions and Dell’s observation-based resource enforcement actions collectively and explicitly discloses “deciding, on the basis of said observation, on at least one action on said object in response to said object not meeting said at least one security rule” - Dell’s enforcement actions (stopping services, disabling interfaces) and Iomaxis’s suspension action (suspend flag 820) each independently satisfy “at least one action on said object” under the broadest reasonable interpretation because each constitutes an automated system response to a detected rule violation: both Dell and Iomaxis implement automated rule-violation-triggered enforcement); and
remove the object from said confinement (reads on “remove information associated with the one of the plurality of smart devices from the local database, the information including the device profile information, the internal firewall rules and the network information,” see Iomaxis, Claim 7) when a deconfinement criterion is met (reads on the user’s decision to remove the device from the gateway, which under the broadest reasonable interpretation constitutes the deconfinement criterion being met - Iomaxis Claim 7 recites that the processor is configured to “receive user input from an input/output device to remove one of the plurality of smart devices,” and that user input to remove the device is the event satisfying the removal condition. The Examiner asserts under BRI “deconfinement criterion” encompasses any triggering event that initiates removal of a device’s confinement record, including a user-initiated disassociation event as in Iomaxis. The KSR combination with Caceres - which monitors device compliance status (para 0036, 0037, 0073) - further supplies the basis for automated deconfinement when the device is determined to be compliant or no longer present on the network), during which said recording of the object data is removed from said confinement zone (The Examiner asserts Iomaxis’s Claim 7 expressly discloses the removal of all per-device data (profile, rules, network info) from the local database - which is the confinement zone in the combination - upon satisfaction of the removal condition, directly satisfying both the “removing from confinement” and “recording ... removed from confinement zone” subphrases. This is further supported by Iomaxis para [0052]: “When a device is removed from the gateway device 110, data associated with the device is removed. The device profile data 400 is removed from the device profile database 222 and the networks database 224 is updated. When the networks database 224 is updated, the device’s MAC address 402 is removed from the network’s network profile data 600 associated device profiles 610 field. The firewall rule database 226 is also updated to remove related firewall rule data 800 associated with the device.” Iomaxis’s deletion of all per-device entries from the local database directly satisfies “removing the recording from the confinement zone” under the broadest reasonable interpretation because the local database is the memory zone in which the per-device records are stored, and deleting those records is the operative meaning of removal from that zone. The combined system still operates by the same principle: maintain per-device records during the monitored period, delete the record when the security condition is resolved).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the IoT home gateway behavior-monitoring, policy-enforcement, and resource-management teachings of the prior art of record by integrating the per-device gateway security framework teachings of Iomaxis (see Iomaxis para [0027], [0029], [0031], [0033], [0036], [0038], [0052], [0057] and [0069], and Iomaxis Claim 7) to realize the instant limitation. Under KSR International Co. v. Teleflex Inc., 550 U.S. 398 (2007), 82 U.S.P.Q.2d 1385, this combination is supported by MPEP § 2143 Rationale A (combining known elements - Caceres’s behavior-monitoring logic, Dell’s per-device gateway-resource enforcement, and Iomaxis’s gateway-internal per-device record database with associated firewall rules - each performing its established function to yield the predictable result of a unified per-device confinement record containing identity data and gateway-resource security rules). Caceres, Dell, and Iomaxis all operate in the same technical field of IoT device behavioral profiling, rule-based policy enforcement, and gateway security for home and small-business local area networks. Both the prior art of record and Iomaxis address the same fundamental problem that Iomaxis itself identifies in its own disclosure: the security of smart devices connected to a home gateway is critically deficient because traditional security solutions address only external Internet-facing traffic while leaving local device-to-device communications unprotected. Iomaxis expressly states this problem: “Traditional solutions such as firewalls only address data communications between the device and the Internet - omitting the data communications that occurs locally to the device, such as the device-to-device communications within a home, commercial or industrial environments” (Iomaxis para [0011]); and Iomaxis further identifies that “[t]he critical gap in device security and interlaced security between devices introduces risk into commercial and residential environments” (Iomaxis para [0007]). Iomaxis expressly addresses this problem by maintaining a gateway-internal local database (device profile database 222, firewall database 226) that records per-device identity and per-device firewall rules governing each smart device’s interactions with the gateway and with the private network (see Iomaxis para [0033]: “the device profile database 222, networks database 224 and firewall database 226 are internal to the gateway device 100”; and Iomaxis para [0036]: “the device profile data 400 includes the device MAC address 402. make 404, model 406. image 408, type 410. communication protocol(s) 412, communication port(s) 414, IP address 416, date added 418, network controller type 419, network association 420, physical location 422, description 424 and associated firewall rules 426”). Integrating Iomaxis’s per-device record database into the combined Caceres/Dell gateway system does not change the fundamental operation of any reference: Caceres continues to operate as a profile-based behavior-monitoring and VLAN-enforcement network device; Dell’s resource management service 409 continues to measure per-device gateway hardware consumption and enforce corrective actions; and Iomaxis continues to operate as a gateway-internal per-device firewall policy system that creates, stores, enforces, and removes per-device records. The combination yields the predictable result of a gateway that (a) stores each connected IoT device’s identity data and security rules - including gateway-resource interaction rules - in a single gateway-resident per-device record (the claimed “confinement zone”), (b) observes and enforces those rules, and (c) removes the per-device record upon satisfaction of a deconfinement condition - thereby teaching the claimed steps of “confine the object, comprising recording data of the object in a memory zone, called confinement zone, said data comprising at least one identification datum of the object and at least one security rule relating to at least one possible interaction of said object with at least one of said sensitive components of said gateway,” and the step of removing the object from the confinement zone when a deconfinement criterion is met, as recited in claim 11. One of ordinary skill in the art in the field of IoT gateway security would have recognized that Iomaxis’s per-device profile database 222 - which already stores device identity alongside associated firewall rules 426 governing each device’s network access - is the natural and predictable structural complement to Caceres’s behavior-monitoring and Dell’s resource-enforcement teachings, requiring no redesign of any reference’s architecture to achieve a unified per-device confinement record of the type claimed. The motivation to combine the references is applied to all claims below this heading.
Per claim 12, the prior art of record further suggests a home gateway including the device (reads on network device/ gateway combination performing one or more self-policing network governance functions, see Caceres para 0012, 0013, 0017, 0018, 0020, 0026, 0032, 0039 and 0052) as claimed in claim 11.
Claim 1 is analyzed with respect to claim 11.
Claim 13 is analyzed with respect to claim 11.
Per claim 4, the prior art of record further suggests acquiring said at least one security rule after a phase of detecting a connection of said communicating object to said gateway (reads on “when a device is first paired with the gateway device 110, the gateway device 110 authenticates to a known and trusted remote database 104 accessible via the Internet 100. Once the gateway device 110 and the remote database 104 have authenticated to each other and an encrypted tunnel for communications is established, the gateway device 110 queries the remote databases 104 for device specific information of the newly paired device,” see Iomaxis para [0027]; and reads on “Initial device configuration 214 creates new firewall policies that are immediately enforced. For example, when a device is paired with the gateway device 110, as described in FIG. 3, new firewall rules are created in the firewall database 226 automatically,” see Iomaxis para [0058]). Iomaxis explicitly and in Claim 4’s exact logical sequence (i) detects a new device connecting (pairing event), then (ii) retrieves/acquires the security rules for that device - satisfying “acquiring said at least one security rule after a phase of detecting a connection” - Iomaxis’s detection-triggered rule retrieval and rule creation upon the pairing event is the precise sequence recited in the claim. The Examiner asserts Iomaxis para [0058] expressly states the process is triggered by the connection/pairing event of a new smart device).
Per claim 6, the prior art of record further suggests acquiring said at least one security rule MAC address 402, the manufacturers database 204 is searched to identify the manufacturer of the device based on the organizationally unique identifier (OUI) portion of the device’s MAC address 402. The manufacturer’s database 204 then returns the make 404 of the device and provides the models 406 associated with that specific manufacturer,” see Iomaxis para [0039]; and reads on “the manufacturer’s models database 206 is queried using the device model 406 criteria ... an image 408, device type 410 (e.g. light, Switch, motion sensor), and the communication protocol(s) 412 and communication port(s) 414 of the device are returned,” see Iomaxis para [0045]; combined with “Initial device configuration 214 creates new firewall policies that are immediately enforced ... new firewall rules are created in the firewall database 226 automatically,” see Iomaxis para [0058]). Iomaxis explicitly acquires security rules using the device’s MAC address (OUI - characteristic datum), make, model, and type as characteristic data - satisfying “acquiring said at least one security rule on the basis of a characteristic datum of the object,” where “characteristic datum” under the broadest reasonable interpretation encompasses descriptive data about the device such as device type, manufacturer, or model - as exemplified by Iomaxis’s make/model/type-based rule retrieval from a remote database (see Iomaxis para [0039], [0045]). Iomaxis explicitly discloses that the make 404, model 406, and type 410 of each device are used as the basis for querying the remote database and generating corresponding firewall rules (see Iomaxis para [0039]: “Using the device’s MAC address 402, the manufacturers database 204 is searched to identify the manufacturer”; and Iomaxis para [0045]: “the manufacturer’s models database 206 is queried using the device model 406 criteria ... an image 408, device type 410 (e.g. light, Switch, motion sensor), and the communication protocol(s) 412 and communication port(s) 414 of the device are returned”), confirming that device type, make, and model - characteristic data in the ordinary sense - are the basis for the security rule acquisition).
Per claim 7, the prior art of record further suggests wherein said at least one security rule associated with said communicating object comprises at least one element from among: a maximum amount of data that the communicating object is authorized to exchange on one of the data buses of the gateway (reads on Dell para [0110]: “techniques are presented for optimizing IoT gateway performance based on utilization and saturation rates, as well as other factors, of not only the internal components of the gateway (such as the CPU) but also of external devices connected to disparate bus architectures..; and reads on Dell para [0110]: “device, behavior, and resource management service 409 may detect anomalous levels of resource consumption by a service or on an interface compared to an ongoing baseline ... This action may include postponing low priority actions, reducing collection rate, volume, devices served, stopping services, and disabling interfaces”). Dell’s per-device bus utilization monitoring and corrective enforcement render obvious per-device data limits on gateway buses, satisfying “a maximum amount of data that the communicating object is authorized to exchange on one of the data buses of the gateway” under the broadest reasonable interpretation); a maximum percentage of use of a processor of the gateway (reads on Dell para [0110]: “optimizing IoT gateway performance based on utilization and saturation rates, as well as other factors, of not only the internal components of the gateway (such as the CPU)”; and reads on Dell para [0104]: “Gateway actions may include, but are not limited to: graceful shutdown of managed devices, reduction in collection and reporting rate and fields, reduction in running services, reduction in system hardware usage (e.g., drop CPU frequency, etc.), drive parking, handing sensors off to unaffected gateways or routes”). Dell’s explicit teaching of CPU utilization monitoring and CPU frequency reduction as an enforcement action directly supports the concept of per-device CPU usage limits as a type of gateway security rule); access to a communication module of the gateway (reads on Iomaxis para [0031]: “the gateway device’s network communications may be controlled and managed by, for example, a network interface controller/radio network controller (NIC/RNC) module 208. The NIC/RNC module 208 enables the gateway device 110 to connect and communicate externally using different mediums and technologies”; combined with Iomaxis para [0057]: “Device firewall rules (both internal rules for controlling communication between devices within the private network, and external rules for controlling communication between devices in the private network and devices in an external network such as the Internet) are constructed using the firewall configuration 218 component of the management interface module 212”). Iomaxis’s per-device firewall rules governing communications through the NIC/RNC module 208 are the functional equivalent of a security rule governing “access to a communication module of the gateway,” because gateway communication interfaces are communication modules and the rules govern access to them - Wi-Fi and similar radio interface access rules constitute “access to a communication module of the gateway” under the broadest reasonable interpretation because a network interface module is a communication module and a rule governing device access to it governs “access to a communication module”).
Per claim 8, the prior art of record further suggests further comprising detecting an interaction of said communicating object with at least one component contrary to said created security rule (reads on “network device 114 determines that user device 110-1 is communicating with an FQDN system/server not included in user device profile 500, such as a server located thousands of miles away from user device 110, has transmitted messages a number of times that is not in accordance with time profile information stored in one of the data profiles (e.g., twenty times or more over a short duration of time. such as one minute), behavior monitoring logic 330 determines that the activity is suspicious (block 820 -yes),” see Caceres para [0068]; and reads on “The firewall engine 210 enforces system default and user defined firewall rules for the internal firewall 112 and the external firewall 108,” see Iomaxis para [0034]. The combination explicitly discloses detection of a security rule violation by comparing observed device interactions against per-device stored rules - a functional match on “detecting an interaction ... contrary to said created security rule” under the broadest reasonable interpretation because detecting that observed behavior does not comply with a stored per-device rule is the ordinary technical meaning of “detecting an interaction contrary to said security rule”), and said action on the connected object comprises an action of the group consisting of: a modification of said at least one security rule (reads on “The profiles may also be dynamically modified in accordance with changing network requirements. In this manner, device behavior may be monitored in real time in accordance with up-to-date device profiles,” see Caceres para [0079]); blocking said interaction (reads on gateway device 130 may block traffic to/from user device 110-1 that is not in accordance with device profile 500, see Caceres para [0071]; and reads on “The gateway device 110 secures and protects devices 122-128 from the each other and the Internet 100 through application of default and user defined firewall rules,” see Iomaxis para [0029]); rejecting the object (reads on “network device 114 may prohibit user device 110 from accessing an external network (e.g., network 150 and/or 190),” see Caceres para [0061]; and reads on “Additional communication with the newly associated device is blacklisted by the gateway device’s default firewall rules, dropping ingress and egress network traffic of the device,” see Iomaxis para [0047]); unpairing the object (reads on “remove information associated with the one of the plurality of smart devices from the local database, the information including the device profile information, the internal firewall rules and the network information stored in the local database and associated with the one of the plurality of smart devices,” see Iomaxis Claim 7, which constitutes the functional equivalent of unpairing by deleting all device records; and reads on “When a device is removed from the gateway device 110, data associated with the device is removed. The device profile data 400 is removed from the device profile database 222 and the networks database 224 is updated.” see Iomaxis para [0052]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Caceres in view of Dell in view of Iomaxis in view of Hamza (Hamza et al., “Clear as MUD: Generating, Validating and Applying IoT Behavioral Profiles,” Proceedings of the 2018 Workshop on IoT Security and Privacy, ACM SIGCOMM 2018, DOI 10. l 145/3229565.3229566).
Per claim 5, the prior art of record suggests claim 1. The prior art of record is silent on explicitly stating acquiring said at least one security rule via a step of learning a behavior of the object.
Hamza (“Clear as MUD: Generating, Validating and Applying IoT Behavioral Profiles,” Proceedings of the 2018 Workshop on IoT Security and Privacy, ACM SIGCOMM 2018, DOI 10.1145/3229565.3229566) is relied upon to teach acquiring said at least one security rule via a step of learning a behavior of the object (reads on a behavioral observation (learning) period over which traffic flows of IoT devices are captured and then converted directly into explicit security rules - verbatim satisfying the claim limitation. Hamza describe the MUDgee system (reads on a tool that monitors the network behavior of a communicating object and derives security rules therefrom): “We, therefore, developed a tool - MUDgee - which automatically generates a MUD profile for an IoT device from its traffic trace”, see Hamza §3 p. 9). The behavioral observation/learning period is explicitly described: “We captured traffic flows for each IoT device during a six month observation period, to generate our MUD rules”, see Hamza §3 paragraph 2, - reads on acquiring security rules via a step of learning a behavior of the object, wherein traffic flows of each IoT device are observed over an extended learning period for the purpose of generating the resulting rules). The system architecture implementing this behavioral capture is described: “MUDgee has two separate modules; (a) captures and tracks all TCP/UDP flows to/from device, and (b) composes a MUD profile from the flow rules”, see Hamza §3.1 1st paragraph - reads on learning the behavior of the communicating object through continuous tracking of its network interactions, and composing security rules from that learned behavioral model). The translation of observed behaviors into explicit security rules is directly taught: “Flow translation to MUD: MUDgee uses the captured traffic flows to generate the MUD profiles for the devices”, see Hamza §3.1 Subsection Flow translation to MUD “Flow translation to MUD” - reads on the generation of security rules directly from the learned behavioral data of the communicating object). The resulting rules are expressly characterized as an access control / security rule set: “The rules reflect an application whitelisting model (i.e., there are no explicit ‘drop’ rules)”, see Hamza §3 2nd paragraph - reads on at least one security rule relating to at least one possible interaction of said object, wherein the MUD access control entries constitute the security rules acquired through the behavioral learning process). One of ordinary skill in the art would recognize that the MUD Access Control Entries (ACEs) generated by MUDgee are security rules as broadly recited in the claim under the broadest reasonable interpretation: they are named access control rules derived exclusively from observed behavioral data of the IoT device during the six-month learning/observation period, directly satisfying “said at least one security rule is acquired via a step of learning a behavior of the object”).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the IoT home gateway behavior-monitoring and per-device policy-enforcement teachings of the prior art of record by integrating the behavioral-learning security rule generation teachings of Hamza (see Hamza §3 and §3.1) to realize the instant limitation. Under KSR International Co. v. Teleflex Inc., 550 U.S. 398 (2007), 82 U.S.P.Q.2d 1385, this combination is supported by MPEP § 2143 Rationale A (combining known elements - the prior art’s gateway-based behavioral monitoring architecture and Hamza’s behavioral-learning rule-generation mechanism - each performing its established function, to yield the predictable result of automatically derived, device-specific access control rules for the gateway) and MPEP § 2143 Rationale G (the prior art as a whole would have led one of ordinary skill in the art to combine the elements in the manner claimed, because Hamza expressly identify and solve the same problem of deriving accurate per – IoT -device security rules from observed device behavior). Both the prior art of record and Hamza operate in the same technical field of IoT device behavioral profiling and security rule generation at the network gateway level. Both address the same problem that Hamza expressly identify in their own disclosure: IoT devices are increasingly implicated in cyber-attacks because network operators lack a principled, automated mechanism to derive per-device behavioral security profiles and enforce them as access control rules at the network level. Hamza state this problem directly: “IoT devices are increasingly being implicated in cyber-attacks, driving community concern about the risks they pose to critical infrastructure, corporations, and citizens”, see Hamza §Abstract; and Hamza further identify that “many IoT products do not incorporate even basic security measures”, see Hamza §2. Hamza solve this problem by developing MUDgee, a tool that “automatically generates a MUD profile for an IoT device from its traffic trace” following “a six month observation period, to generate our MUD rules”, see Hamza §3, thereby providing device-specific behavioral security rules derived from learned device behavior - precisely the approach at issue. Integrating Hamza’s behavioral-learning rule-generation mechanism into the prior art’s gateway-resident enforcement architecture does not change the fundamental operation of either the prior art of record or Hamza. The prior art of record continues to operate as a profile-based behavior-monitoring, confinement-zone management, and policy-enforcement gateway system; and Hamza’s MUDgee mechanism continues to operate as a behavioral traffic capture and flow-to-rule translation tool. The combination yields the predictable result of a gateway system in which the security rules stored in each connected IoT device’s confinement-zone record are derived automatically from that device’s observed network behavioral patterns, rather than being manually authored or retrieved from a static manufacturer database - thereby teaching the claimed step of “acquiring said at least one security rule via a step of learning a behavior of the object,” as recited in the claim. One of ordinary skill in the art in the field of IoT gateway security would have recognized that Hamza’s MUDgee approach of observing TCP/UDP flow data from each IoT device over an extended period and composing device-specific MUD Access Control Entries (ACEs) from those flows, see Hamza §3.1: “MUDgee has two separate modules; (a) captures and tracks all TCP/UDP flows to/from device, and (b) composes a MUD profile from the flow rules”) is the natural and predictable implementation of the behavioral learning rule-acquisition step described in the prior art’s own gateway architecture, and would have been motivated to combine these teachings to reduce the manual rule-authoring burden while generating tighter, device-specific access control profiles. The motivation to combine the references is applied to all claims below this heading.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Caceres in view of Dell in view of Iomaxis in view of Oracle (US Pub. No. 2016/0088021 A1).
Per claim 9, the prior art of record further suggests the method of claim 1. The prior art of record is silent on explicitly stating said at least one security rule is assigned a severity index, and the method comprises selecting the action on the object on the basis of this index.
Oracle (US Pub. No. 2016/0088021 A1) is relied upon to teach at least one security rule is assigned a severity index. and the method comprises selecting the action on the object on the basis of this index (reads on “FIG. 8 depicts an example a compliance policy indicating levels of non-compliance and remedial actions corresponding to the levels according to Some embodiments of the present invention”, see Oracle para [0144]; reads on “entry 830 in data structure 810 may indicate ‘low’ level of non-compliance defined by non-compliances 814 including a non-conforming password for an application or installation of an unauthorized (e.g., blacklisted) application in entry 830,” see Oracle para [0150]; reads on “entry 840 in data structure 810 may indicate ‘medium’ level of non-compliance defined by non-compliances 814 including inactivity of an endpoint device,” see Oracle para [0151 ]; reads on “entry 850 in data structure 810 may indicate ‘high’ level of non-compliance defined by non-compliances 814 including violation of device enrollment criteria,” see Oracle para [0152]; reads on “entry 860 in data structure 810 may indicate “fully non-compliant” level of non-compliance defined by non-compliances 814 including altering a hardware or a software configuration on a remote device,” see Oracle para [0153]; and for action selection - reads on “a level of non-compliance of a remote device may be assessed based on a compliance policy. A detected non-compliance may be compared to the non-compliance(s) defined for each of the levels of non-compliance,” see Oracle para [0158]).
Oracle’s compliance severity framework explicitly (i) indexes policies/rules by severity level (low/medium/high/fully non-compliant), (ii) links each device to a current severity index based on its worst violation, and (iii) selects the enforcement action based on that index - satisfying all three sub-phrases of Claim 9. Under BRI, “security rules are indexed” encompasses any system in which security rules or policies are classified, prioritized, or tagged with a severity or priority level; and “a connected object linked to a severity index” encompasses any per-device association between the device record and a severity or compliance level. The Examiner asserts Oracle para [0158] shows that the severity level directly determines the specific enforcement action taken - demonstrating that the severity level is a functionally operative index that controls enforcement behavior. The Examiner further asserts the prior art of record already performs per-device rule enforcement and action selection (see Iomaxis para [0069]); and Oracle’s severity indexing merely adds a graduated dimension to the action-selection logic without altering the fundamental per-device monitoring and enforcement architecture.
PNG
media_image1.png
546
840
media_image1.png
Greyscale
[0144] FIG. 8 depicts an example a compliance policy indicating levels of non-compliance and remedial actions corresponding to the levels according to some embodiments of the present invention. Data structure 810 may be created to store a compliance policy. Data structure 810 may be included or referenced by data structures described above.
[0145] Data structure 810 may be implemented as one or a combination of different types of data structures including, without restriction, an array, a record, a relational database table, a hash table, a linked list, or other types of data structures. For purposes of illustration, data structure 810 is each shown in an arrangement with a particular number of fields (e.g., fields 812-820); however, data structure 810 may be defined by more or fewer fields in different arrangement than shown. Each instance of data structure 810 may be stored in a data store such as policies data store 164.
[0146] Field 812 (“Non-Compliance Levels”) may include information defining a level of non-compliance. A level of non-compliance may be defined by one or more non-compliances indicated by information in field 814 (“Non-Compliance(s)”).
[0147] Field 816 (“User Role(s)”) may include information indicating one or more roles defined for a level of non-compliance. User roles may be defined as roles that are excluded from the non-compliances defined by the level of non-compliance. User roles may be defined as the roles for which non-compliance is assessed for the level of non-compliance.
[0148] Field 818 (“Resources(s) Not Permitted for Access”) may include information indicating one or more resources that are not permitted for access by a user with one of user roles 816 when non-compliance is detected for a remote device registered with the user. In some embodiments, field 818 may indicate resources that are permitted. Access to resources may be defined based on the resources indicated in field 818 for an assessed level of compliance during time period 820 for that assessed level. Access may not be permitted unless a remedial action is taken during the time period.
[0149] In some embodiments, a level of non-compliance may be assessed by finding a matching non-compliance level in one of the levels of non-compliance. The level of non-compliance may be assessed as the level with a matching non-compliance. A level of non-compliance may be further assessed based on whether the remote device that non-compliant is registered for a user associated with one of the user roles defined for that level. A level of non-compliance may be further assessed based on whether the non-compliance for the level occurs during a time period defined for that level. Although not described, one or more remedial actions may be defined for a non-compliance with respect to a level of non-compliance.
[0150] FIG. 8 shows several examples of non-compliances stored in data structure 810. In a first example, entry 830 in data structure 810 may indicate “low” level of non-compliance defined by non-compliances 814 including a non-conforming password for an application or installation of an unauthorized (e.g., blacklisted) application in entry 830. Entry 830 may indicate user roles 816 including an executive and an employee for which the level of non-compliance is to be assessed. For entry 830, time period 820 may indicate 24 hours during which remedial action can be taken to gain access to the resource(s) (e.g., HR application) indicated by field 818.
[0151] In a second example, entry 840 in data structure 810 may indicate “medium” level of non-compliance defined by non-compliances 814 including inactivity of an endpoint device. Entry 840 may indicate user roles 816 including an employee and a manager for which the level of non-compliance is to be assessed. For entry 840, time period 820 may indicate 48 hours during which remedial action can be taken to gain access to the resource(s) (e.g., HR application) indicated by field 818.
[0152] In a third example, entry 850 in data structure 810 may indicate “high” level of non-compliance defined by non-compliances 814 including violation of device enrollment criteria. Entry 850 may indicate user roles 816 including an employee and a contractor for which the level of non-compliance is to be assessed. For entry 850, time period 820 may indicate 2 hours during which remedial action can be taken to gain access to the resource(s) (e.g., Corporate Intranet Web Services) indicated by field 818.
[0153] In a fourth example, entry 860 in data structure 810 may indicate “fully non-compliant” level of non-compliance defined by non-compliances 814 including altering a hardware or a software configuration on a remote device. Entry 860 may indicate user roles 816 including all user roles for which the level of non-compliance is to be assessed. For entry 860, time period 820 may not be defined or not granted for taking remedial action to gain access to the resource(s) (e.g., all resources) indicated by field 818.
[0154] Now turning to FIG. 9 is a flowchart 900 illustrating a process for managing compliance of devices that access an enterprise system according to some embodiments of the present invention. In some embodiments, the process depicted in FIG. 9 may be implemented by device access management system 120 of FIG. 1 described herein.
[0155] The process depicted by flowchart 900 may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors cores), hardware, or combinations thereof. The software may be stored in memory (e.g., on a memory device, on a non-transitory computer-readable storage medium). The particular series of processing steps of flowchart 900 is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in FIG. 9 may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular applications. While processing depicted in FIG. 9 is with respect to a single non-compliance of a remote device accessing an enterprise system, the processing may be performed for multiple different non-compliances of the remote device accessing the enterprise system. While processing depicted in FIG. 9 is with respect to a request for a computing resource, the processing may be performed for multiple computing resources requested from a remote device that accesses the enterprise system. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
[0156] The processing in flowchart 900 is initiated, at step 902, by identifying a compliance policy for use of one or more remote devices with an enterprise computer system. For example, device access management system 120 can identify a compliance policy in policies data store 164. A compliance policy may be used to manage compliance for one or more remote devices (e.g., endpoint devices 108) used with enterprise computer system. A compliance policy may be identified from a plurality of compliance policies based on one or more attributes including, but not limited to, a user role for accessing the enterprise computer system, a type of remote device, a device attribute (e.g., a type of platform supported for a remote device), a geographical location of a remote device, or combinations thereof. Examples of compliance policies are described with reference to FIG. 6.
[0157] Based on a compliance policy (e.g., the compliance policy identified at step 902), a non-compliance of a remote device may be detected, at step 904. As described above, a compliance policy may indicate one or more non-compliances. Device information obtained (e.g., device synchronization) from the remote device may be assessed to determine whether the state of the remote device and/or use of the remote device matches a non-compliance identified in the compliance policy. Multiple non-compliances may be detected although processing is described with respect to a single non-compliance. Some or all of the detected non-compliances may be different types of non-compliances.
[0158] At step 906, a level of non-compliance of a remote device may be assessed based on a compliance policy (e.g., the compliance policy identified at step 902). A detected non-compliance may be compared to the non-compliance(s) defined for each of the levels of non-compliance. The non-compliance may be assessed to a level of non-compliance that includes a non-compliance matching the detected non-compliance. Examples of levels of non-compliance are described with reference to FIGS. 7 and 8. In some embodiments, when a non-compliance does not match any of the non-compliances in the levels of non-compliances, a default level of non-compliance may be assessed.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the IoT home gateway security rule enforcement and action-selection teachings of the prior art of record by integrating the severity-indexed compliance rule and graduated action-selection teachings of Oracle (see Oracle para [0144], [0150], [0151], [0152], [0153] and [0158]) to realize the instant limitation. Under KSR International Co. v. Teleflex Inc., 550 U.S. 398 (2007), 82 U.S.P.Q.2d 1385, this combination is supported by MPEP §2143 Rationale A (combining the known per-device security rule and action-selection architecture of the prior art of record with Oracle’s known severity-indexing and graduated enforcement mechanism, each element performing its established function, to yield the predictable result of an IoT gateway system that selects enforcement actions based on the indexed severity of each rule violation). Both the prior art of record and Oracle operate in the same technical field of networked device compliance monitoring, security rule management, and automated enforcement action selection. Both address the same fundamental problem that Oracle itself identifies in its own disclosure: enterprises and network systems are unable to manage compliance violations with appropriate proportionality because existing approaches either completely restrict access regardless of the severity of non-compliance, or require manual inspection and remediation device-by-device. Oracle expressly states this problem: “enterprises are unable to routinely manage compliance on devices. To ensure that access to an enterprise system is not compromised, an enterprise may completely restrict access to an enterprise system regardless of a severity of non-compliance” (Oracle para [0006]); and Oracle further identifies that defining “levels of non-compliance” enables “an enterprise system [to] control access to its resources in a fine-grain manner rather than preventing access to all resources” and “enables an enterprise to control remediation of remote devices based on the security risk posed to the enterprise by different non-compliances” (Oracle para [0010]). Oracle expressly discloses and enables this same graduated enforcement architecture: Oracle’s compliance framework assigns each security policy a level of non-compliance (low, medium, high, or fully non-compliant), links each monitored device to a current severity index based on its detected violations (see Oracle para [0150]-[0153]), and selects the remedial enforcement action based on that severity index (see Oracle para [0158]: “a level of non-compliance of a remote device may be assessed based on a compliance policy. A detected non-compliance may be compared to the non-compliance(s) defined for each of the levels of non-compliance”). Integrating Oracle’s severity-indexing mechanism into the prior art’s per-device enforcement architecture does not change the fundamental operation of either the prior art of record or Oracle. The prior art continues to operate as a profile-based behavior-monitoring, confinement-zone management, and per-device policy-enforcement gateway system (see Iomaxis para [0069]); and Oracle continues to operate as a compliance-level assessment and graduated action-selection engine. The combination yields the predictable result of an IoT gateway system that not only monitors each device’s compliance with its assigned security rules but also indexes those rules by severity and selects enforcement actions - ranging from warnings through graduated restrictions to full suspension - proportionate to the severity of the detected violation, thereby teaching the claimed method steps of “said at least one security rule is assigned a severity index” and “the method comprises selecting the action on the object on the basis of this index,” as recited in claim 9. One of ordinary skill in the art in the field of IoT gateway security and compliance management would have recognized that Oracle’s four-tier severity hierarchy (low, medium, high, fully non-compliant) mapped to four corresponding tiers of remedial action (see Oracle para [0144]-[0158]) is a well-known, predictable mechanism for graduated enforcement, and would have been motivated to incorporate that severity-indexed action-selection logic into the prior art’s per-device rule database and enforcement pipeline - which already stores per-device rules and triggers enforcement actions upon violation (see Iomaxis para [0069]) - without any change to either reference’s underlying monitoring or enforcement architecture. The motivation to combine the references is applied to all claims below this heading.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Caceres in view of Dell in view of Iomaxis in view of Thomson (US Pub. No. 2006/0010491 Al).
Per claim 10, the prior art of record suggests the method of claim 1. The prior art of record is silent on explicitly stating modifying said at least one security rule in the event of a detection of a modification in a context of the home gateway.
Thomson (US Pub. No. 2006/0010491 A 1) is relied upon to teach
modifying said at least one security rule (reads on Thomson para [0067] and para [0012] independently confirm that firewall rules are automatically regenerated (i.e., modified) on each detected context change, see Thomson para [0012]: ‘‘the system possesses on each appliance of the community means for updating the local security policy and of triggering a new calculation of the rules used by the filter”; and see Thomson para [0067]: “These rules are regenerated with each modification of the security policy, or when the environment of the appliance is modified”
-- each of these constitutes a “modifying said at least one security rule” under the broadest reasonable interpretation because each is an automated regeneration and recalculation of the resident firewall rules)) in the event of a detection of (reads on a fully enabled method step - “the detection of the addition, the removal and the banishing of an appliance of the community” and “the detection of the changes of network address of an appliance of the community” (see Thomson para [0023], Thomson Claim 13) - which is a match to “in the event of a detection of” because Thomson’s method explicitly recites detection as a discrete, positively claimed method step, satisfying “in the event of a detection of” under the broadest reasonable interpretation because Thomson’s event-triggered rule recalculation is precisely the detection-triggered rule modification the claim recites. Under BRI, each of the Thomson-detected events represents a change in the operational state or topology of the domestic network in which the gateway appliance operates - a connected appliance arriving or departing, a service changing status, and topology modification each constitute changes in the gateway’s operational environment and therefore satisfy “a modification in a context of the home gateway” under the broadest
reasonable interpretation, consistent with Thomson’s own framing that “the system possesses means of triggering a new calculation of the rules used by the filter in reaction to changes occurring on the network” (Thomson para [0013]). The Examiner asserts Thomson para [0014] and Claim 4 recite at least three independent species of such modification as positively claimed, enabled embodiments: see Thomson para [0013]: “the changes taken into account for triggering a new calculation of the rules used by the filter are at least one among the following: the change of network address of an appliance of the community, the addition, the removal or the banishing of an appliance of the community and the change of status of a service hosted on an appliance of the community”; see Thomson Claim 4: “System according to claim 3 where the changes taken into account for triggering a new calculation of the rules used by the filter are at least one among the following: the change of network address of an appliance of the community, the addition, the removal or the banishing of an appliance of the community and the change of status of a service hosted on an appliance of the community.”) a modification in a context of the home gateway (reads on Thomson para [0013]: “the system possesses means of triggering a new calculation of the rules used by the filter in reaction to changes occurring on the network” - demonstrating that Thomson explicitly treats network topology changes as the triggering context for rule regeneration; further reads on Thomson para [0067]: “These modifications may come from the modification of the topology, that is to say from the addition or from the removal of one or more appliances of the network... Hence only the change of IP address of an appliance of the community or of an appliance authorized to access a privileged service, the removal, the addition and the banishing of an appliance of the community are events requiring a new generation of the firewall rules. As this generation is totally automated, a set of firewall rules that is consistent with the security policy of which it is knowledgeable is available to the appliance at any instant”).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the IoT home gateway firewall rule management architecture of the prior art of record - which teaches a gateway device with a resident firewall engine enforcing rules stored in a local non-volatile firewall database, with an automated pipeline that pushes any new or updated rule to the firewall engine upon any change to the database - by integrating the context-triggered firewall rule regeneration mechanism of Thomson (see Thomson para [0013]: “the system possesses means of triggering a new calculation of the rules used by the filter in reaction to changes occurring on the network”) to realize the instant limitation of modifying at least one security rule upon detection of a modification in a context of the home gateway. One or more of the underpinning rationale(s). as discussed in KSR International Co. v. Teleflex Inc., 550 U.S. 398 (2007), 82 U.S.P.Q.2d 1385, also see MPEP § 2143. support this conclusion. Both the prior art of record and Thomson operate in the same technical field of IoT home gateway firewall rule management, context-triggered security policy enforcement, and local area network protection. Accordingly, it would have been obvious to one of ordinary skill in the art to have taken Thomson’s proven mechanism of detecting changes in the domestic network environment - specifically, the addition, removal, or banishing of an appliance and the change of status of a service hosted on an appliance - and automatically triggering a recalculation and regeneration of the resident firewall rules on the gateway appliance in response to each such detected context change, and to have applied that event-detection-and-rule-regeneration mechanism to the prior art of record home gateway’s existing firewall rule database and firewall engine update pipeline, so that when a modification in the operating context of the gateway is detected, the gateway’s resident security rules are automatically modified, as recited in the instant claims. As Thomson itself states: “These rules are regenerated with each modification of the security policy, or when the environment of the appliance is modified. These modifications may come from the modification of the topology, that is to say from the addition or from the removal of one or more appliances of the network ... Hence only the change of IP address of an appliance of the community or of an appliance authorized to access a privileged service, the removal, the addition and the banishing of an appliance of the community are events requiring a new generation of the firewall rules. As this generation is totally automated, a set of firewall rules that is consistent with the security policy of which it is knowledgeable is available to the appliance at any instant,” see Thomson para [0067], which addresses the well-recognized technical problem that static, manually-administered firewall rules cannot keep pace with the dynamic topology and operational context changes inherent in domestic IoT networks - precisely the problem Thomson itself identifies in its own Background: “the appliances of the domestic community are liable to develop a fault to be turned off or carried away by the user beyond reach of the means of communication of the remainder of the community…Moreover, it is necessary that the policy take account of alterations to the community, the addition or the removal of new appliances” (Thomson para [0009]); and Thomson further identifies that existing firewall approaches fail domestic networks because “each appliance is able to communicate with appliances outside the network without this communication necessarily passing through an identified access point” (Thomson para [0008]). One of ordinary skill in the art in the field of home gateway IoT security would have recognized that the prior art’s automated rule-update pipeline (see Iomaxis para [0058]: “Initial device configuration 214 creates new firewall policies that are immediately enforced. For example, when a device is paired with the gateway device 110, as described in FIG. 3, new firewall rules are created in the firewall database 226 automatically”) already provides the exact rule-modification infrastructure needed, and that Thomson’s context-event detection and rule-regeneration mechanism was a known, predictable solution to automatically triggering that existing pipeline upon a broader range of gateway context changes, requiring no change to the underlying firewall enforcement or database architecture of the prior art of record. The combination is further supported by MPEP § 2143 Rationale A (combining prior art elements using known methods to yield predictable results - plugging Thomson’s context-event trigger into Iomaxis’s rule-update pipeline yields the predictable result of automated context-triggered resident security rule modification) and MPEP § 2143 Rationale F (some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill in the art to modify Iomaxis in the way claimed - Thomson expressly identifies the same problem of dynamic domestic network context change and discloses the identical solution). The motivation to combine these references applies to all claims under this heading.
Conclusion
Applicant’s amendment necessitates the presented new ground(s) of rejection. 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 extension fee 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 date of this final action.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is ((571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights