DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 10/23/2025.
In the instant Amendment: Claims 1, 8, and 15 have been amended. Claims 1-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants' arguments in the instant Amendment, filed on 10/23/2025, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant Argues: Shin and Xie fail to disclose “wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within a virtual network interface card (NIC) of the second virtualized execution environment that stores the second packet” and “adding the first filtering rule to a physical NIC of a host associated with the hypervisor based on a determination by the hypervisor that the first filtering rule is similar to at least one additional filtering rule” and of amended claim 1. See Remarks at 10 (emphasis added).
The examiner respectfully disagrees because these arguments are not persuasive.
In regards to, “wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within a virtual network interface card (NIC) of the second virtualized execution environment that stores the second packet,” applicant alleges that Shin and Xie fail to disclose a “virtual network interface card (NIC)” is capable of providing a “filtering rule” in a virtualized environment. Id. at 10. However, the specification explains that a “virtual network interface card” just constitutes a portion or function of a virtual machine, which is itself a collection of software codes being executed in a distributed computing environment. See Specification ¶ [0042] (“The virtual machines 121A and 121B may each execute a guest operating system 123A and 123B that may utilize the underlying virtual devices, including virtual processors, virtual memory, virtual network interface cards (NICs) 124A and 124B, and virtual I/O devices.”).
Similarly, Shin discloses “[t]he vSwitch 500 is an OpenFlow-based software switch existing inside a hypervisor for communication between the virtual machines. The vSwitch 500 blocks intruder's traffics according to blocking rules transferred from the vIPS 400.” See Shin col. 6: 1-4 (emphasis added). Accordingly, Shin teaches the concept of “virtual network interface card (NIC)” of amended claim 1.
Thus, Shin in view of Xie teaches ““wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within a virtual network interface card (NIC) of the second virtualized execution environment that stores the second packet.”
In regards to, “adding the first filtering rule to a physical NIC of a host associated with the hypervisor based on a determination by the hypervisor that the first filtering rule is similar to at least one additional filtering rule,” Xie discloses:
In some embodiments, a malware analysis system includes receiving a potential malware sample from a firewall; analyzing the potential malware sample using a virtual machine to determine if the potential malware sample is malware; and automatically generating a signature (e.g., a hash-based signature for a file and/or other types of signatures as described herein) if the potential malware sample is determined to be malware. In some embodiments, the signature is distributed to a plurality of network devices/functions (e.g., routers and gateways) and/or security devices/functions (e.g., security/firewall appliances, security/firewall gateways, host-based firewalls, host-based security suites, and security cloud services).
As also shown, signatures 418 are received and stored in the management plane 402. In some embodiments, policy enforcement (e.g., policies can include one or more rules, and rules can apply one or more signatures) using signatures is applied as described herein with respect to various embodiments based on the monitored, identified, and decoded session traffic flows. In some embodiments, decoder 414 can also enforce policies 416 using signatures 418 provided by management plane 402, including newly generated signatures, using the various techniques described herein with respect to various embodiments.
At 508, the new signature is sent to the firewall. In some embodiments, the new signature is distributed to other security functions/devices and/or a security cloud service.
See Xie FIG. 5, ¶¶ [0026], [0048], [0051] (emphasis added).
Here, Xie teaches generating hash-based signatures of suspicious traffic, matching the signature, and to retrieve enforcement policies in response to the matched signature. New signatures are routinely added in response to changing malicious traffic, and updated enforcement policies for these new signatures can be provisioned, as needed, to the network devices/VM. Furthermore, such security actions can be executed in a virtual machine environment. Thus, Shin in view of Xie teaches “adding the first filtering rule to a physical NIC of a host associated with the hypervisor based on a determination by the hypervisor that the first filtering rule is similar to at least one additional filtering rule” of amended claim 1.
In conclusion, applicant’s argument is unpersuasive and the rejection of amended claims 1 is maintained. Rejection of claims 8 and 15, which recite similar matters, is similarly maintained.
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 discloses as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 8, 11, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Shin et al. (“Shin,” US 9,166,988, patented Oct. 20, 2015) in view of Xie et al. (“Xie,” US 20120304244, published Nov. 29, 2012).
Regarding claim 1, Shin discloses A method, comprising:
receiving, by a hypervisor that manages a first virtualized execution environment and a second virtualized execution environment and that is executed by a processing device, a first packet addressed to the first virtualized execution environment (Shin FIG. 5, col. 6: 1-10, col. 8: 28-32, 35-40. The vSwitch 500 is an OpenFlow-based software switch existing inside a hypervisor for communication between the virtual machines. The VIPS 400 is a hypervisor-based intrusion prevention platform. The VIPS 400 [ ] checks the intruder's IP (Internet Protocol) by carrying out malicious behavior analysis and detection according to correlation analysis procedures of the cloud ESM system 200. [W]hen a doubtful traffic or attack pattern is detected, the VIPS 400 [ ] creates an attack detection-related security alert. [For “packet” associated with network traffic, see col. 2: 17-22.]);
determining, by the hypervisor executed by the processing device, whether the first packet has similar characteristics with a second packet by applying a first filtering rule to the first packet, [wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within a virtual network interface card (NIC) of the second virtualized execution environment that stores the second packet, and wherein the second virtualized execution environment stores the second packet in the first filtering queue based on a determination by the second virtualized execution environment that the second packet is malicious] (Shin FIG. 4, col. 8: 4-8, and col. 9: 55-60. [W]hen any malicious behavior is detected according to the signature-based detection, the VIPS 400 creates real time blocking rules (S10-S20). The VIPS400 sends the real time blocking rules of a flow rule type to the vSwitch 500 (S30). [Note that signature can be created for previously detected intruder [i.e. as a filtering rule]. Subsequent data are compared against the signature. See also col. 9: 55-60 “… controlling the virtual network with the security function according to the present invention reduce the number of packets to which the IPS carries out the signature matching inspection through the DPI [deep packet inspection] test by diffusing blocking against the previously detected intruder by the network level, so as to enhance performance of the virtualized network IPS.”.]),
a virtual network interface card (NIC) (Shin col. 6: 1-4. The vSwitch 500 is an OpenFlow-based software switch existing inside a hypervisor for communication between the virtual machines. The vSwitch 500 blocks intruder's traffics according to blocking rules transferred from the vIPS 400.); and
responsive to determining that the first packet is similar to the second packet, discarding, by the hypervisor executed by the processing device, the first packet (Shin FIG. 4: col. 8: 10-14, col. 9: 28-32. Then, the vSwitch500 [of a hypervisor, see col. 8: 3-9] blocks the intruder's traffics according to the blocking rules sent from the VIPS 400 in advance (S40). The vSwitch 500 carries out traffic blocking during a designated period of time.).
Shin does not explicitly disclose: wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within [a virtual network interface card (NIC)] of the second virtualized execution environment that stores the second packet, and wherein the second virtualized execution environment stores the second packet in the first filtering queue based on a determination by the second virtualized execution environment that the second packet is malicious; and adding the first filtering rule to a physical NIC of a host associated with the hypervisor based on a determination by the hypervisor that the first filtering rule is similar to at least one additional filtering rule.
However, in an analogous art, Xie discloses a method, comprising the step of:
wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within [a virtual network interface card (NIC) ] of the second virtualized execution environment that stores the second packet, and wherein the second virtualized execution environment stores the second packet in the first filtering queue based on a determination by the second virtualized execution environment that the second packet is malicious (Xie [0025], [0037]. In particular, a malware analysis, using the various techniques described herein can provide zero-day protection, is provided, which protects against zero-day exploits by detecting new malware threats for which preexisting signatures do not exist and automatically generating new signatures in real-time for the new malware threats. For example, a virtual machine (VM) can be used to perform behavior profiling (e.g., in a VM sandbox environment) using various heurist based analysis techniques that can be performed in real-time during a file transfer (e.g., during a file download), and if the file being downloaded is determined to be malicious, then the firewall can automatically block the file download based on the analysis result, and a new signature can be generated and distributed to automatically block future file transfer requests to download the file determined to be malicious. For example, the VM emulation of accessing a particular web site and downloading certain content from the web site can indicate certain suspicious behavior, such as changes to certain platform, software, or registry settings. In some embodiments, if no preexisting signatures are matched, a potential malware sample can be selected for further analysis and forwarded to the VM malware analysis engine for performing the further analysis (e.g., for real-time behavior profiling analysis using virtual machines to provide a sandbox environment to detect malware and/or for post analysis using log information as described herein with respect to various embodiments) to determine whether the potential malware sample is malware.);
adding the first filtering rule to a physical NIC of a host associated with the hypervisor based on a determination by the hypervisor that the first filtering rule is similar to at least one additional filtering rule (Xie FIG. 5, ¶¶ [0026], [0048], [0051]. In some embodiments, a malware analysis system includes receiving a potential malware sample from a firewall; analyzing the potential malware sample using a virtual machine to determine if the potential malware sample is malware; and automatically generating a signature (e.g., a hash-based signature for a file and/or other types of signatures as described herein) if the potential malware sample is determined to be malware. In some embodiments, the signature is distributed to a plurality of network devices/functions (e.g., routers and gateways) and/or security devices/functions (e.g., security/firewall appliances, security/firewall gateways, host-based firewalls, host-based security suites, and security cloud services). As also shown, signatures 418 are received and stored in the management plane 402. In some embodiments, policy enforcement (e.g., policies can include one or more rules, and rules can apply one or more signatures) using signatures is applied as described herein with respect to various embodiments based on the monitored, identified, and decoded session traffic flows. In some embodiments, decoder 414 can also enforce policies 416 using signatures 418 provided by management plane 402, including newly generated signatures, using the various techniques described herein with respect to various embodiments. At 508, the new signature is sent to the firewall. In some embodiments, the new signature is distributed to other security functions/devices and/or a security cloud service.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective date of the claimed invention to combine the teachings of Xie with the teachings of Shin to include the step of: wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within the second virtualized execution environment that stores the second packet, and wherein the second virtualized execution environment stores the second packet in the first filtering queue based on a determination by the second virtualized execution environment that the second packet is malicious. One would have been motivated to provide users with a means for using a virtual sandbox for analyzing a suspicious file and generating signatures of zero-day attacks or malware for future firewall protection. (See Xie [0025].)
Regarding claim 4, Shin and Xie disclose the method of claim 1. Shin discloses:
further comprising, prior to receiving the first packet: generating, by the processing device, the first filtering rule in view of the characteristics of the second packet (Shin FIG. 5, col. 8: 51-55. When the blocking reaction command is received from the cloud ESM system 200, the VIPS400 creates real time blocking rules according to the blocking reaction command (S170). Additionally, the VIPS 400 sends the created real time blocking rules of the flow rule type to the vSwitch 500. [Note that signature can be created for previously detected intruder [i.e. as a filtering rule]. Subsequent data are compared against the signature. See col. 9: 55-60.]); and
storing, by the processing device, the first filtering rule in a data store (Shin FIG. 4, col. 6: 43-47, col. 8: 4-11, and col. 9: 55-60. [W]hen any malicious behavior is detected according to the signature-based detection, the VIPS 400 creates real time blocking rules (S10-S20). The VIPS400 sends the real time blocking rules of a flow rule type to the vSwitch 500 (S30). Then, the vSwitch500 blocks the intruder's traffics according to the blocking rules sent from the VIPS 400 in advance (S40). [Note that signature can be created for previously detected intruder [i.e. as a filtering rule]. Subsequent data are compared against the signature. See col. 9: 55-60.]).
Regarding claim 8, A system comprising: the processing device to: receive, by a hypervisor that manages a first virtualized execution environment and a second virtualized execution environment and that is executed by the processing device, a first packet addressed to the first virtualized execution environment (Shin FIG. 5, col. 6: 1-10, col. 8: 28-32, 35-40. The vSwitch 500 is an OpenFlow-based software switch existing inside a hypervisor for communication between the virtual machines. The VIPS 400 is a hypervisor-based intrusion prevention platform. The VIPS 400 [ ] checks the intruder's IP (Internet Protocol) by carrying out malicious behavior analysis and detection according to correlation analysis procedures of the cloud ESM system 200. [W]hen a doubtful traffic or attack pattern is detected, the VIPS 400 [ ] creates an attack detection-related security alert. [For “packet” associated with network traffic, see col. 2: 17-22.]);
determine, by the hypervisor, whether the first packet has similar characteristics with a second packet by applying a first filtering rule to the first packet (Shin FIG. 4, col. 6: 43-47, col. 8: 4-11, and col. 9: 55-60. [W]hen any malicious behavior is detected according to the signature-based detection, the VIPS 400 creates real time blocking rules (S10-S20). The VIPS400 sends the real time blocking rules of a flow rule type to the vSwitch 500 (S30). Then, the vSwitch500 blocks the intruder's traffics according to the blocking rules sent from the VIPS 400 in advance (S40). [Note that signature can be created for previously detected intruder [i.e. as a filtering rule]. Subsequent data are compared against the signature. See col. 9: 55-60.]),
a virtual network interface card (NIC) (Shin col. 6: 1-4. The vSwitch 500 is an OpenFlow-based software switch existing inside a hypervisor for communication between the virtual machines. The vSwitch 500 blocks intruder's traffics according to blocking rules transferred from the vIPS 400.);
and wherein the first filtering queue is designated for malicious packets (Shin col. 7: 58-62. The hypervisor-based virtual network controlling system 100 with the security function according to the preferred embodiment of the present invention enhances intrusion prevention performance by previously blocking attacking traffics in the network level before an application of a DPI (Deep Packet Inspection.) and
provides an interface between a virtualization section of a host and the second virtualized execution environment (Shin col. 6: 5-10. The vIPS 400 is a hypervisor-based intrusion prevention platform, and controls an NIPS (Network-based IPS) service, a stateful firewall service, and an HIPS (Host-based IPS) service of a higher level and provides an interface for providing information necessary for carrying out an intrusion detection and an interface which receives detected results.); and
responsive to a determination that the first packet is similar to the second packet, discard, by the hypervisor, the first packet (Shin FIG. 4: col. 8: 10-14, col. 9: 28-32. Then, the vSwitch500 [of a hypervisor, see col. 8: 3-9] blocks the intruder's traffics according to the blocking rules sent from the VIPS 400 in advance (S40). The vSwitch 500 carries out traffic blocking during a designated period of time.).
Shin does not explicitly disclose: a memory; and a processing device coupled to the memory;
wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within [a virtual network interface card (NIC)] of the second virtualized execution environment that stores the second packet, wherein the second virtualized execution environment stores the second packet in the first filtering queue based on a determination by the second virtualized execution environment that the second packet is malicious;
and adding the first filtering rule to a physical NIC of a host associated with the hypervisor based on a determination by the hypervisor that the first filtering rule is similar to at least one additional filtering rule.
However, in an analogous art, Xie discloses a system, comprising:
a memory; and a processing device coupled to the memory (Xie [0014]. The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor.),
wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within a [virtual network interface card (NIC) ] the second virtualized execution environment that stores the second packet, wherein the second virtualized execution environment stores the second packet in the first filtering queue based on a determination by the second virtualized execution environment that the second packet is malicious (Xie [0025], [0037]. In particular, a malware analysis, using the various techniques described herein can provide zero-day protection, is provided, which protects against zero-day exploits by detecting new malware threats for which preexisting signatures do not exist and automatically generating new signatures in real-time for the new malware threats. For example, a virtual machine (VM) can be used to perform behavior profiling (e.g., in a VM sandbox environment) using various heurist based analysis techniques that can be performed in real-time during a file transfer (e.g., during a file download), and if the file being downloaded is determined to be malicious, then the firewall can automatically block the file download based on the analysis result, and a new signature can be generated and distributed to automatically block future file transfer requests to download the file determined to be malicious. For example, the VM emulation of accessing a particular web site and downloading certain content from the web site can indicate certain suspicious behavior, such as changes to certain platform, software, or registry settings. In some embodiments, if no preexisting signatures are matched, a potential malware sample can be selected for further analysis and forwarded to the VM malware analysis engine for performing the further analysis (e.g., for real-time behavior profiling analysis using virtual machines to provide a sandbox environment to detect malware and/or for post analysis using log information as described herein with respect to various embodiments) to determine whether the potential malware sample is malware.);
adding the first filtering rule to a physical NIC of a host associated with the hypervisor based on a determination by the hypervisor that the first filtering rule is similar to at least one additional filtering rule (Xie FIG. 5, ¶¶ [0026], [0048], [0051]. In some embodiments, a malware analysis system includes receiving a potential malware sample from a firewall; analyzing the potential malware sample using a virtual machine to determine if the potential malware sample is malware; and automatically generating a signature (e.g., a hash-based signature for a file and/or other types of signatures as described herein) if the potential malware sample is determined to be malware. In some embodiments, the signature is distributed to a plurality of network devices/functions (e.g., routers and gateways) and/or security devices/functions (e.g., security/firewall appliances, security/firewall gateways, host-based firewalls, host-based security suites, and security cloud services). As also shown, signatures 418 are received and stored in the management plane 402. In some embodiments, policy enforcement (e.g., policies can include one or more rules, and rules can apply one or more signatures) using signatures is applied as described herein with respect to various embodiments based on the monitored, identified, and decoded session traffic flows. In some embodiments, decoder 414 can also enforce policies 416 using signatures 418 provided by management plane 402, including newly generated signatures, using the various techniques described herein with respect to various embodiments. At 508, the new signature is sent to the firewall. In some embodiments, the new signature is distributed to other security functions/devices and/or a security cloud service.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective date of the claimed invention to combine the teachings of Xie with the teachings of Shin to include: wherein the first filtering rule is generated by the hypervisor in view of characteristics of the second packet by accessing a first filtering queue within the second virtualized execution environment that stores the second packet, and wherein the second virtualized execution environment stores the second packet in the first filtering queue based on a determination by the second virtualized execution environment that the second packet is malicious. One would have been motivated to provide users with a means for using a virtual sandbox for analyzing a suspicious file and generating signatures of zero-day attacks or malware for future firewall protection. (See Xie [0025].)
Regarding claim 11, claim 11 is directed to a system corresponding to the method of claim 4. Claim 11 is similar to claim 4 and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a non-transitory computer readable medium corresponding to the method of claim 1. Claim 15 is similar to claim 1 and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a non-transitory computer readable medium corresponding to the method of claim 4. Claim 18 is similar to claim 4 and is therefore rejected under similar rationale.
Claims 2, 3, 7, 9, 10, 14, 16, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shin et al. (“Shin,” US 9,166,988, patented Oct. 20, 2015) in view of Xie et al. (“Xie,” US 20120304244, published Nov. 29, 2012) and Zhu et al. (“Zhu,” US 8938611, patented Jan 20, 2015).
Regarding claim 2, Shin and Xie disclose the method of claim 1. Shin further discloses
determining, by the processing device, whether the first packet has the similar characteristics with the second packet (Shin FIG. 4, col. 8: 4-8, and col. 9: 55-60. [W]hen any malicious behavior is detected according to the signature-based detection, the VIPS 400 creates real time blocking rules (S10-S20). The VIPS400 sends the real time blocking rules of a flow rule type to the vSwitch 500 (S30). [Note that signature can be created for previously detected intruder [i.e. as a filtering rule]. Subsequent packet flows are compared against the signature. See col. 9: 55-60 “… controlling the virtual network with the security function according to the present invention reduce the number of packets to which the IPS carries out the signature matching inspection through the DPI [deep packet inspection] test by diffusing blocking against the previously detected intruder by the network level, so as to enhance performance of the virtualized network IPS.”.]).
Shin and Xie do not explicitly disclose: determining, by the processing device, whether the first virtualized execution environment satisfies a trust condition pertaining to the second virtualized execution environment, wherein determining whether the first virtualized execution environment satisfies the trust condition comprises determining whether the first virtualized execution environment and the second virtualized execution environment are associated with a same user; responsive to determining that the first virtualized execution environment satisfies the trust condition.
Zhu discloses further comprising: determining, by the processing device, whether the first virtualized execution environment satisfies a trust condition pertaining to the second virtualized execution environment, wherein determining whether the first virtualized execution environment satisfies the trust condition comprises determining whether the first virtualized execution environment and the second virtualized execution environment are associated with a same user; responsive to determining that the first virtualized execution environment satisfies the trust condition (Zhu FIGs 2-3, col. 3: 56-57; col. 4: 13-15, 20-23; col. 5: 36-40. After user login, the network is configured to utilize the user's machine. Referring back to FIG. 2, a separate virtual machine 206a, 206b, 206c may be created for each user … there may be instances where a single user may have multiple virtual machines. These settings [for establishing a virtual machine] can include all the configuration information needed to establish the encrypted channels and correctly route traffic. Various network security inspection functions can be built into the security virtual machine. These include, for example, firewall, IPS/IDS, application control, URL filtering, data leakage protection, anti-virus and anti-malware functions. Indeed, any network protection aspect could conceivably be built into the security virtual machine.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective date of the claimed invention to combine the teachings of Zhu with the teachings of Shin to include the step of: determining, by the processing device, whether the first virtualized execution environment satisfies a trust condition pertaining to the second virtualized execution environment, wherein determining whether the first virtualized execution environment satisfies the trust condition comprises determining whether the first virtualized execution environment and the second virtualized execution environment are associated with a same user; responsive to determining that the first virtualized execution environment satisfies the trust condition. One would have been motivated to provide users with a means for applying security policies, fire-wall, and anti-malware measures to a plurality of virtual machines belonging to the same or different users. (See Zhu col. 5: 36-42.)
Regarding claim 3, Shin and Xie disclose the method of claim 1.
Shin further discloses:
accessing, by the processing device, a second filtering queue of the [second]virtualized execution environment, the second filtering queue storing at least a third packet (Shin FIG. 5, col. 6: 1-10, col. 8: 28-32, 35-40. The vSwitch 500 is an OpenFlow-based software switch existing inside a hypervisor for communication between the virtual machines. The VIPS 400 is a hypervisor-based intrusion prevention platform. The VIPS 400 [ ] checks the intruder's IP (Inter net Protocol) by carrying out malicious behavior analysis and detection according to correlation analysis procedures of the cloud ESM system 200. [W]hen a doubtful traffic or attack pattern is detected, the VIPS 400 [ ] creates an attack detection-related security alert. );
generating, by the processing device, a second filtering rule in view of characteristics of the third packet (Shin FIG. 5, col. 8: 51-55. When the blocking reaction command is received from the cloud ESM system 200, the VIPS400 creates real time blocking rules according to the blocking reaction command (S170). Additionally, the VIPS 400 sends the created real time blocking rules of the flow rule type to the vSwitch 500.);
performing, by the processing device, at least one of:
installing the first filtering rule, or storing the first filtering rule in a data store to apply to subsequent packets addressed to the first virtualized execution environment and the second virtualized execution environment (Shin FIG. 4, col. 6: 43-47, col. 8: 4-11, and col. 9: 55-60. [W]hen any malicious behavior is detected according to the signature-based detection, the VIPS 400 creates real time blocking rules (S10-S20). The VIPS400 sends the real time blocking rules of a flow rule type to the vSwitch 500 (S30). Then, the vSwitch500 blocks the intruder's traffics according to the blocking rules sent from the VIPS 400 in advance (S40). [Note that signature can be created for previously detected intruder [i.e. as a filtering rule]. Subsequent data are compared against the signature. See col. 9: 55-60.]).
Zhu further discloses:
a second virtualized execution environment (Zhu col. 4: 19-23. It should be noted that there is not necessarily a separate virtual machine for each user. While in many cases a user will have only one virtual machine assigned to himself or herself, there may be instances where a single user may have multiple virtual machines.).;
and in response to determining that the first filtering rule and the second filtering rule match (Zhu col. 4: 19-23, col. 5: 37-42. It should be noted that there is not necessarily a separate virtual machine for each user. While in many cases a user will have only one virtual machine assigned to himself or herself, there may be instances where a single user may have multiple virtual machines. Various network security inspection functions can be built into the security virtual machine. These include, for example, firewall, IPS/IDS, application control, URL filtering, data leakage protection, anti-virus and anti-malware functions. Indeed, any network protection aspect could conceivably be built into the security virtual machine. [i.e. multiple VM can share same security rules for detecting malware])).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective date of the claimed invention to combine the teachings of Zhu with the teachings of Shin to include the step of: in response to determining that the first filtering rule and the second filtering rule match. One would have been motivated to provide users with a means for applying security policies, fire-wall, and anti-malware measures to a plurality of virtual machines belonging to the same or different users and across a plurality of VM environments. (See Zhu col. 5: 36-42.)
Regarding claim 7, Shin and Xie disclose the method of claim 1.
Shin discloses further comprising:
storing, by the processing device, the first packet in a filtering queue of the first virtualized execution environment (Shin FIG. 5, col. 6: 1-10, col. 8: 28-32, 35-40. The vSwitch 500 is an OpenFlow-based software switch existing inside a hypervisor for communication between the virtual machines. The VIPS 400 is a hypervisor-based intrusion prevention platform. The VIPS 400 [ ] checks the intruder's IP (Inter net Protocol) by carrying out malicious behavior analysis and detection according to correlation analysis procedures of the cloud ESM system 200. [W]hen a doubtful traffic or attack pattern is detected, the VIPS 400 [ ] creates an attack detection-related security alert. [For “packet” associated with network traffic, see col. 2: 17-22.]);
receiving, by the processing device, a third packet addressed to a [third] virtualized execution environment, the third packet having similar characteristics with the first packet and the second packet (Shin FIG. 4, col. 6: 43-47, col. 8: 4-11, 28-32 and col. 9: 55-60. [W]hen any malicious behavior is detected according to the signature-based detection, the VIPS 400 creates real time blocking rules (S10-S20). The VIPS 400 [ ] checks the intruder's IP (Internet Protocol) by carrying out malicious behavior analysis and detection according to correlation analysis procedures of the cloud ESM system 200. The VIPS400 sends the real time blocking rules of a flow rule type to the vSwitch 500 (S30). Then, the vSwitch500 blocks the intruder's traffics according to the blocking rules sent from the VIPS 400 in advance (S40). [Note that signature can be created for previously detected intruder [i.e. as a filtering rule]. Subsequent data are compared against the signature. See col. 9: 55-60 “… controlling the virtual network with the security function according to the present invention reduce the number of packets to which the IPS carries out the signature matching inspection through the DPI [deep packet inspection] test by diffusing blocking against the previously detected intruder by the network level, so as to enhance performance of the virtualized network IPS.”.]); and
responsive to receiving the third packet, discarding, by the processing device, the third packet (Shin FIG. 4, col. 6: 43-47, col. 8: 4-11, and col. 9: 55-60. [W]hen any malicious behavior is detected according to the signature-based detection, the VIPS 400 creates real time blocking rules (S10-S20). The VIPS400 sends the real time blocking rules of a flow rule type to the vSwitch 500 (S30). Then, the vSwitch500 blocks the intruder's traffics according to the blocking rules sent from the VIPS 400 in advance (S40). [Note that signature can be created for previously detected intruder [i.e. as a filtering rule]. Subsequent data are compared against the signature. See col. 9: 55-60.]).
Zhu further discloses: a third virtualized execution environment (Zhu FIGs 2-3, col. 3: 56-57; col. 4: 13-15, 20-23; After user login, the network is configured to utilize the user's machine. Referring back to FIG. 2, a separate virtual machine 206a, 206b, 206c may be created for each user … there may be instances where a single user may have multiple virtual machines. These settings [for establishing a virtual machine] can include all the configuration information needed to establish the encrypted channels and correctly route traffic.).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective date of the claimed invention to combine the teachings of Zhu with the teachings of Shin to include the step of: a third virtualized execution environment. One would have been motivated to provide users with a means for applying security policies, fire-wall, and anti-malware measures to a plurality of virtual machines belonging to the same or different users and across a plurality of VM environments. (See Zhu col. 5: 36-42.)
Regarding claim 9, claim 9 is directed to a system corresponding to the method of claim 2. Claim 9 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 10, claim 10 is directed to a system corresponding to the method of claim 3. Claim 10 is similar to claim 3 and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a system corresponding to the method of claim 7. Claim 14 is similar to claim 7 and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is directed to a non-transitory computer readable medium corresponding to the method of claim 2. Claim 16 is similar to claim 2 and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to a non-transitory computer readable medium corresponding to the method of claim 3. Claim 17 is similar to claim 3 and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a non-transitory computer readable medium corresponding to the method of claim 7. Claim 20 is similar to claim 7 and is therefore rejected under similar rationale.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Shin et al. (“Shin,” US 9,166,988, patented Oct. 20, 2015) in view of Xie et al. (“Xie,” US 20120304244, published Nov. 29, 2012) and Varghese et al. (“Varghese,” US 20060282660, published Dec. 14, 2006).
Regarding claim 5, Shin and Xie disclose the method of claim 1. Shin and Xie do not explicitly disclose: further comprising performing, by the processing device, at least one of: removing the first filtering rule after a first set period of time; or temporarily suspending the first filtering rule for a second set period of time.
However, Varghese, in an analogous art, discloses a method comprising:
further comprising performing, by the processing device, at least one of: removing the first filtering rule after a first set period of time; or temporarily suspending the first filtering rule for a second set period of time (Varghese [0119], [0122] and Table 12. In more detail, the groups, model, and rules can be customized according to business need, to become activated if a transaction is scored above a certain risk threshold [See Table 12 for temporarily suspend rules on a time basis. Such rules can be security rules for analysis suspicious traffic. See [0098], Table 5, and [0122].).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective date of the claimed invention to combine the teachings of Varghese with the teachings of Shin and Xie to include the step of: further comprising performing, by the processing device, at least one of: removing the first filtering rule after a first set period of time; or temporarily suspending the first filtering rule for a second set period of time. One would have been motivated to provider user with a means for temporarily suspend certain security rules on a time basis and analyzing network traffic without applying such suspended security rules. (See Varghese Table 12).
Regarding claim 12, claim 12 is directed to a system corresponding to the method of claim 5. Claim 12 is similar to claim 5 and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a non-transitory computer-readable medium corresponding to the method of claim 5. Claim 19 is similar to claim 5 and is therefore rejected under similar rationale.
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Shin et al. (“Shin,” US 9,166,988, patented Oct. 20, 2015) in view of Xie et al. (“Xie,” US 20120304244, published Nov. 29, 2012) and Kumar et al. (“Kumar,” US 20170171159, published June 15, 2017).
Regarding claim 6, Shin and Xie disclose the method of claim 1. Shin and Xie do not explicitly disclose: further comprising adding, by the processing device, metadata included with the first packet to the first filtering rule when the first filtering rule is generated, the metadata comprising a type of malicious packet.
However, Kumar, in an analogous art, discloses a method comprising:
further comprising adding, by the processing device, metadata included with the first packet to the first filtering rule when the first filtering rule is generated, the metadata comprising a type of malicious packet (Kumar [0041], [0080]. The transport layer 242 creates a synchronization (SYN) packet with a 5-tuple (i.e., source IP address, source port, destination IP address, destination port, protocol) to be sent to the destination server. The process 500 authorizes the connection packet based on the identified security rules and determines (at 530) whether to allow the request. When the process 500 deter mines (at 530) to deny the request, the process 500 drops (at 535) the connection packet [based at least in part on the metadata for the packet determined to be malicious. For VM machine, see [0077].]).
Therefore, it would have been obvious to one of ordinary skill in the art on or before the effective date of the claimed invention to combine the teachings of Kumar with the teachings of Shin and Xie to include the step of: adding metadata included with the packet to the filtering rule when the filtering rule is generated, the metadata comprising a type of malicious packet. One would have been motivated to provider user with a means of determining whether a packet violates security rules based at least in part on the metadata of the packet. (See Kumar [0080]).
Regarding claim 13, claim 13 is directed to a system corresponding to the method of claim 6. Claim 13 is similar to claim 6 and is therefore rejected under similar rationale.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD LONG whose telephone number is (571)272-8961. The examiner can normally be reached on Monday to Friday, 9 AM - 6 PM EST (Alternate Fridays).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD LONG/
Examiner, Art Unit 2439
/LUU T PHAM/ Supervisory Patent Examiner, Art Unit 2439