DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments, see Remarks filed 10/17/2025, with respect to the rejection(s) of independent claims 1, 11 and 19 under 35 USC § 103 have been fully considered but are moot because of the new ground of rejection which is based on newly found prior arts, Aziz, US 8898788; and Lackey, US 2020/0076799.
The amendments applied to claim 11 to overcome the 112(b) rejection has been fully considered, and the amendments do overcome the 35 U.S.C. 112(b) rejection. Thus, the rejection of the claims 11, 13, and 15-18 under 35 U.S.C. 112(b) has been withdrawn.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over USPAT No. 8898788 B1 to Aziz et al. (hereinafter “Aziz”), and further in view of USPAT No. 2019/0044948 A1 to Beals
Regarding claim 1:
Aziz discloses:
A method (see the method of Fig. 5) of isolating networked devices (see Fig. 1, Infected device 105, and Destination device 110) on a local network (see Fig. 1, Communication Network 120) using a networked security device (see Fig. 2, Controller 125), comprising:
Performing internet protocol spoofing in the networked security device to intercept network traffic between at least two networked devices on the same local network as the networked security device (col 10, lines 15-23: “The interceptor module 240 may manipulate dynamic host configuration protocol (DHCP) services to intercept network data. As the infected device 105 transmits network data that is flagged as suspicious or otherwise identified as containing a malware attack. The interceptor module 240 may manipulate DHCP services to assign new IP addresses, associate the controller 125 MAC address with the IP address of the destination device 110, or otherwise redirect network data from the infected device 105 to the controller 125.”);
determining, based on behavioral or packet-level analysis of network activity, that one of the networked devices is infected, insecure, or untrusted (col 5, lines 3-12: “The tap 115 can also capture metadata from the network data. … a heuristic module … can determine the infected device 105 and the destination device 110 by analyzing data packets within the network data in order to generate the metadata.”);
and in response to the determination, automatically modifying at least one of an Address Resolution Protocol (ARP) table entry or a firewall routing rule to isolate the identified device from other devices on the local area network (col 9, lines 33-37: “… the policy engine 235 may generate a rule or command the interceptor module 240 to intercept network data from the infected device 105 and delete or bar the packet from the communication network 120.”) […]
However, Aziz does not explicitly teach the following limitation taught by Beals:
[…] while maintaining communication between the identified device and an external network (Beals, ¶25: “… the gateway 105 moves a client device … to the timeout zone 185 in an event the client device fails an integrity check or a security check. In the timeout zone 185, the client devices are isolated from other client devices in the LAN 120 as the client device is restricted from accessing other client devices in the LAN 120 either within the timeout zone 185 or outside of the timeout zone 185. Further, the client devices in the timeout zone 185 are provided limited access to the external network 110, e.g., limited bandwidth and/or limited websites.”, see Fig. 1A for LAN 120, External Network 110 and Timeout Zone 185 ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Aziz to incorporate the functionality of the gateway device to assign client devices to different device zones that have different network access privileges, as disclosed by Beals, such modification would enable the system to provide device isolation in the LAN at different degrees, including full, limited or restricted access to external network.
Regarding claim 11:
Aziz discloses:
A network security device (see Fig. 7, Controller 125), comprising:
a processor (see Fig. 7, Processor 700) and a memory (see Fig. 7, Memory System 705);
a malware protection module implemented as software instructions stored in the memory and executed by the processor to analyze network packet content and behavior to determine that (col 3, lines 4-10: “A malware attack prevention system can comprise … a heuristic module, … The heuristic module may be configured to receive the copied network data from the tap and determine if a possible malware attack is within the copied network data.”), … and
In addition to above limitations, claim 11 recites substantially the same limitations as claim 1 in the form of a network security device to realize and implement the corresponding method, therefore it is rejected by the same rationale.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Aziz, Beals, and further in view of US-PGPUB No. 2005/0278784 A1 to Gupta et al. (hereinafter “Gupta”)
Regarding claim 3:
The combination of Aziz and Beals discloses the method of isolating networked devices on a local network using a networked security device of claim 1, but does not explicitly disclose the following limitation taught by Gupta:
further comprising
identifying in the networked security device one or more networked devices that are either insecure or infected for selectively blocking intercepted networked traffic (Gupta, ¶53: “… identifying the infected systems. … a network intrusion detection system may be used. … these types of systems can identify the network adapter and hence the IP address of the machine that is responsible for transmitting the packet.”, ¶59-61: “… a determination is made as to whether the traffic is from an infected data processing system (step 702). … if the type of traffic is not allowed (selectively), then the traffic is dropped (step 712)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Aziz and Beals to incorporate the functionality of the router or switch to be instructed to prevent traffic having IP addresses from infected clients while allowing traffic from infected clients to pass to destinations external to a local network, as disclosed by Gupta, such modification would allow the system to selectively block untrusted, infectious devices from communicating devices in the local network while providing internet access to an external network.
Regarding claim 13:
Claim 13 substantially recites the same limitation as claim 3 in the form of a network security device realizing the corresponding method, therefore it is rejected by the same rationale.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Aziz, Beals, and further in view of US-PGPUB No. 2021/0051180 A1 to Barnett
Regarding claim 5:
The combination of Aziz and Beals discloses the method of isolating networked devices on a local network using a networked security device of claim 1, but does not disclose the following limitation taught by Barnett:
wherein selectively blocking intercepted network traffic between the at least two networked devices on the local network comprises using iptables or ip6tables rules to selectively block traffic (Barnett, ¶19: “… the in home network device can include a blocking stack that includes iptables functioning as an operating system netfilter that can block and/or route Internet traffic …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Aziz and Beals to incorporate the functionality of the in home network device to include a blocking stack that includes iptables to block or route internet traffic, as disclosed by Barnett, such modification would provide the system to manage network traffic security by analyzing and matching bad IPV4 and IPV6 addresses, and bad Geo locations in the iptables to the incoming network traffic, and blocking the traffic if the iptables determine that the traffic matches any of the filters.
Regarding claim 15:
Claim 15 substantially recites the same limitation as claim 5, in the form of a network security device realizing the corresponding method, therefore it is rejected by the same rationale.
Claims 6-7 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Aziz, Beals, and further in view of US-PGPUB No. 2006/0184454 A1 to Ananda
Regarding claim 6:
The combination of Aziz and Beals discloses the method of isolating networked devices on a local network using a networked security device of claim 1, but does not explicitly disclose the following limitation taught by Ananda:
wherein Internet Protocol spoofing comprises at least one of Address Resolution Protocol (ARP) spoofing (Ananda, ¶90: “IP spoofing involves forging a host's IP address as a source address, using one machine to impersonate another. Many applications and tools in UNIX systems rely on source IP address authentication. Where IP spoofing is not sufficient, ARP spoofing may be implemented. ARP spoofing involves forging a packet source hardware address (MAC address) of the host being spoofed.”), Internet Control Message Protocol version 6 (ICMPv6) spoofing, and neighbor table spoofing.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Aziz and Beals to incorporate the functionality of the monitoring system to implement ARP spoofing where IP spoofing is not sufficient, as disclosed by Ananda, such modification would provide the system an additional layer of protection to isolate the networked devices by using ARP spoofing which involves forging a packet source hardware address (MAC address) of the host being spoofed when IP spoofing is not sufficient.
Regarding claim 7:
The combination of Aziz, Beals and Ananda discloses:
The method of isolating networked devices on a local network using a networked security device of claim 6, where performing ARP spoofing comprises sending an ARP packet from the networked security device to a networked device, the ARP packet claiming the networked security device is another device on the local network (Aziz, col 10, lines 36-43: “… the interceptor module 240 may send an ARP reply to the infected device 105. The ARP reply is configured to identify the MAC address of the controller 125 with the IP address of the destination device 110. When the infected device 105 receives the ARP reply, the infected device 105 may begin to send network data intended for the destination device to the controller 125.”).
Regarding claims 16-17:
Claims 16-17 substantially recite the same limitations as claims 6-7, respectively, in the form of a network security device realizing the corresponding method, therefore they are rejected by the same rationale.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable Aziz, Beals, Ananda, and further in view of USPAT No. 10,257,295 B1 to Alpert et al. (hereinafter “Alpert”)
Regarding claim 8:
The combination of Aziz, Beals and Ananda discloses the method of isolating networked devices on a local network using a networked security device of claim 6, but fails to explicitly disclose the following limitation taught by Alpert:
further comprising monitoring the local network for ARP packets from the at least two local network devices (Alpert, col 11, lines 31-34: “… a process running on the internet sensor 120 may monitor local network 105 traffic of client devices 130 … for periodic network management packets relating to … ARP, ICMPv6, etc., …”), and reinserting the network security device between the local network devices using ARP spoofing in response to discovering an ARP packet from one of the at least two local network devices (Alpert, col 16, lines 19-25: “… the internet sensor 304 observing traffic from a new client device 308 for ARP packets … the new client device 308 may request the MAC address of the router 302, and the internet sensor 304 may detect the MAC address request, and the internet sensor 304 may transmit a spoofed ARP packet (IPv4) …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Aziz, Beals and Ananda to incorporate the functionality of the internet sensor to monitor local network traffic of client devices for periodic network management packets relating to ARP, and observing traffic in the network of the client devices and transmit a spoofed ARP packet when a new client device requesting the MAC address of the router is discovered, as disclosed by Alpert, such modification would allow the system to monitor communications between local client devices and reinsert the security device between the respective devices when a suspect ARP packet is detected, providing reliable protection to the system.
Regarding claim 18:
Claim 18 substantially recites the same limitation as claim 8, in the form of a network security device realizing the corresponding method, therefore it is rejected by the same rationale.
Claims 9 is rejected under 35 U.S.C. 103 as being unpatentable over Aziz, Beals, Ananda, Alpert, and further in view of US-PGPUB No. 2010/0241744 A1 to Fujiwara
Regarding claim 9:
The combination of Aziz, Beals, Ananda and Alpert discloses the method of isolating networked devices on a local network using a networked security device of claim 8, but does not disclose the following limitation taught by Fujiwara:
wherein reinserting the network security device between the at least two local network devices comprises delaying at least five milliseconds between discovering an ARP packet from the one of the at least two local network devices and sending ARP packets to reinsert the network security device between the at least two local network devices (Fujiwara, ¶147: “After a specific length of time (e.g., 5 seconds) has passed since the monitoring unit 101 received the ARP request packet from the unregistered computer 103 (S21B), the monitoring unit 101 unitcasts a spoofed ARP reply packet where the MAC address of the registered computer 102 is spoofed as MAC3 (the fictitious MAC address) (S25). … This makes it possible to block the transmission of packets from the unregistered computer 103 to the registered computer 102.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Aziz, Beals, Ananda and Alpert to incorporate the functionality of the monitoring unit to delay replying to ARP requests for a length of time (e.g. 5 seconds), as disclosed by Fujiwara, such modification would allow the system to provide sufficient time so that the client device's ARP packet exchange is complete before it re-spoofs the client device by sending its own ARP packets.
Claims 10 is rejected under 35 U.S.C. 103 as being unpatentable over Aziz, Beals, Ananda, Alpert, and further in view of USPAT No. 7,945,656 B1 to Remaker
Regarding claim 10:
The combination of Aziz, Beals, Ananda and Alpert discloses the method of isolating networked devices on a local network using a networked security device of claim 8, but does not disclose the following limitation taught by Remaker:
wherein reinserting the network security device between the at least two local network devices comprises sending ARP packets to reinsert the network security device between the at least two local network devices multiple times over the first five seconds after discovering the ARP packet from one of the at least two local network devices (Remaker, col 4, lines 23-26: “… ARP requests are often sent in rapid succession, such as once every two seconds during a ten second interval, to rule out network congestion as a reason for non-reply.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Aziz, Beals, Ananda and Alpert to incorporate the functionality of the routing device to send ARP requests in rapid succession, as disclosed by Remaker, such modification would allow the system to rule out network congestion as a reason for non-reply, and to reduce the chances of the unspoofed client device communicating a significant amount of network traffic directly with the router/gateway rather than through the network security.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over US-PGPUB No. 2015/0020188 A1 to Segal et al. (hereinafter “Segal”), US-PGPUB No. 2020/0076799 A1 to Lackey et al. (hereinafter “Lackey”), and further in view of Beals
Regarding claim 19:
Segal discloses:
A method of isolating networked devices (¶09: “… a computer implemented method … sending at least one spoof packet to at least one host over the network (e.g., a local network, including a local area network (LAN)), the at least one spoof packet causing network packet rerouting over the network …”) on a local network (¶26: “… local network 20 …”, see Fig. 2) using a networked security device (¶26: “… a gateway host 30 …”, ¶29: “The gateway host 30, is the host performing the network security function … for the local network 20”, see Fig. 2), comprising:
performing Address Resolution Protocol (ARP) spoofing by the networked security device (Segal, ¶06: “… the gateway host … sends crafted Address Resolution Protocol (ARP) packets to controlled hosts, by ARP spoofing.”) to intercept network traffic (¶06: “This ARP spoofing causes the controlled hosts to send all of their network packets, which are intended to be routed via the router to the gateway host …”) between at least a first networked device (¶26: “… a router 22 …”) and other network devices (¶06: “… controlled hosts …”) on the same local network as the networked security device (¶26: “The local network 20 includes a router 22 … a controlled host 24 (¶28: “The controlled host 24 … is representative of all controlled hosts on the local network 20.”) and a gateway host 30. …”);
transmitting a spoofed ARP packet from the networked security device to the first networked device to redirect the first networked device's local traffic to the networked security device (¶07: “The gateway host sends spoof packets to one or more of the other hosts, … Each controlled host, having received the spoof packets, sends network packets for an intended destination, which are intercepted by the gateway host.”);
However, Segal does not explicitly disclose the following limitation taught by Lackey:
and selectively discarding packets addressed to the other network devices on the same local network while forwarding packets addressed to an external network (Lackey, ¶59: “permit a particular type of local device, such as a smart refrigerator, within a local network to communicate with its manufacturer at an external network address for software updates, but not permit such as a device type to send traffic to a local device, such as a desktop computer, within the same local network.”), […]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Segal to incorporate the functionality of the security systems to provide protection from devices within the same network, as disclosed by Lackey, such modification would enable the system to protect network devices behind a firewall from devices in the same network that would pose a threat.
The combination of Segal and Lackey does not explicitly disclose the following limitation taught by Beals:
[…] thereby isolating the first device from the local area network (Beals, ¶25: “… the gateway 105 moves a client device … to the timeout zone 185 in an event the client device fails an integrity check or a security check. In the timeout zone 185, the client devices are isolated from other client devices in the LAN 120 as the client device is restricted from accessing other client devices in the LAN 120 either within the timeout zone 185 or outside of the timeout zone 185.”, see Fig. 1A for LAN 120, Timeout Zone 185 ) while maintaining its external network connectivity (Beals, ¶25: “… the client devices in the timeout zone 185 are provided limited access to the external network 110, e.g., limited bandwidth and/or limited websites.”, see Fig. 1A for LAN 120, External Network 110 and Timeout Zone 185 ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Segal and Lackey to incorporate the functionality of the gateway device to assign client devices to different device zones that have different network access privileges, as disclosed by Beals, such modification would enable the system to provide device isolation in the LAN at different degrees, including full, limited or restricted access to external network.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Segal, Lackey, Beals, and further in view of Gupta
Regarding claim 20:
The combination of Seagal, Lackey and Beals discloses:
The method of isolating networked devices on a local network using a networked security device of claim 19, […] and wherein the external network is the Internet (Segal, ¶29: “The gateway host 30 … provides access, full or partial for the controlled host 24 to the Internet 26 …”, see Fig. 2, Internet 26),
The combination of Seagal, Lackey and Beals does not explicitly disclose the following limitation taught by Gupta:
[…] wherein the networked security device is further operable to make the determination that the first networked device is insecure, infected, or untrusted (Gupta, ¶53: “… identifying the infected systems. … a network intrusion detection system may be used. … these types of systems can identify the network adapter and hence the IP address of the machine that is responsible for transmitting the packet.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Seagal, Lackey and Beals to incorporate the functionality of the router or switch to be instructed to prevent traffic having IP addresses from infected clients while allowing traffic from infected clients to pass to destinations external to a local network , as disclosed by Gupta, such modification would allow the system to selectively block untrusted, infectious devices from communicating devices in the local network while providing internet access to an external network.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHIAS HABTEGEORGIS whose telephone number is (571)272-1916. The examiner can normally be reached M-F 8am-5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William R. Korzuch can be reached on (571)272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.H./Examiner, Art Unit 2491
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491