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 .
Election/Restrictions
During a telephone conversation with Lu Yin on 9/24/2025 a provisional election was made without traverse to prosecute the invention of group 1, claims 21-26. Affirmation of this election must be made by applicant in replying to this Office action. Claims 27-38 withdrawn from further consideration by the examiner, 37 CFR 1.142(b), as being drawn to a non-elected invention.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 21-26 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “anomalous behavior”, in claim(s) 21, 23, is a relative term which renders the claim indefinite. The term “anomalous behavior” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
For example, the specification states identifying large amount of data exchange between two machines would alert to an administrator of the anomalous behavior. However, the examiner is unclear how much is “large”. Large to a small organization would be considered small to large organization in terms of amount of data. [PGPub paragraph 16]
Claim 24 recites the limitation "the newly added service rules". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear which newly added service rules are being referred.
Claim 25 recites the limitation "the at least one flow". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear if the at least one flow is referring to the at lease one processed flow or some other flow.
Claims 22-26 are rejected based on rejection of its corresponding dependent claim.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claim(s) 21-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Holeman et al. (Pub 2010237641) (hereafter Holeman) in view of Gunda et al. (Pub 20180183757) (hereafter Gunda).
As per claim 21, Holeman teaches:
A method for detecting anomalous behavior of machines executing on a plurality of host computers, the method comprising:
receiving from the host computers sets of attributes relating to groups of flows processed on the host computers, at least a group of the received attribute sets comprising an indication of an anomaly behavior detected with respect to at least one processed flow; ([Paragraph 8], Many information technology organizations monitor network flows to improve network security. One such example of such technology is NETFLOW, which is a feature introduced on CISCO routers that provides the ability to collect Internet Protocol (IP) traffic as it enters or exits an interface of a network device. Various devices in the network may facilitate the collection and analysis of network flow data, including flow collectors and flow analyzers. This collection process allows a network administrator to determine information such as the source and destination of network traffic, class of service, and causes of network congestion. The analysis of flow data may also help in the early detection of cyber-attacks, including malware, Denial of Service (DoS) attacks, and Advanced Persistent Threats. One method for collecting and saving network flow information is by using an IP Flow Information Export (IPFIX) format promulgated by the Internet Assigned Numbers Authority (IANA). This collection of data may be useful in capturing data pertinent to layers 2, 3, and 4 of the OSI reference model (data link, network, and transport layers, respectively). [Paragraph 7], The network illustrated above has also been divided into three separate broadcast domains 40A-C, indicated from left to right. The benefit of this arrangement is that traffic within a broadcast domain 40A-C is not passed up to a higher-level of the network. Accordingly, local traffic remains local. [Paragraph 59], Sensors 460 are not limited to observing network activity relating to active connections, however. For example, sensors 460 may detect failed Domain Name Service (DNS) lookup requests, which may, in some instances, be indicative of malware attempts using domain generation algorithms. Similarly, sensors 460 may also detect other types of failed connection attempts, which might indicate attempts by endpoint computer system 120 to passively scan the network or manipulate Address Resolution Protocol (ARP) requests—for example, to facilitate man-in-the-middle attacks or ARP cache poisoning. [Paragraph 75], As described above, endpoint analysis agent 340 is operable to collect endpoint information, package that information (or a subset of that information) in one or more network flow data records, and send those records to network 110, where it may be received either by network flow analyzer 106, or by network flow collector 104, where it may be ultimately forwarded to analyzer 106. [Paragraph 76], Turning now to FIG. 5, a block diagram of a system 500 that includes network flow analyzer 106 is shown. As depicted, network flow analyzer 106 includes flow matching module 510, threat and anomaly detection module 520, and risk analysis module 530. These modules may be implemented either in hardware, software, or a combination thereof. [Paragraph 81], In some embodiments, module 520 includes computer program instructions that are executable to determine whether network activity should be classified as potential threat or anomaly. As shown, module 520, in some embodiments, may receive network threat intelligence feeds 512. Feeds 512 refer to any third-party data that provides information regarding known cyber-threats. Module 520 then uses a set of rules or heuristics, optionally in conjunction with feeds 512, to make a threat assessment determination.)
using the anomalous behavior indication to select one of the received attribute sets for further anomalous behavior analysis; ([Paragraph 59], Sensors 460 are not limited to observing network activity relating to active connections, however. For example, sensors 460 may detect failed Domain Name Service (DNS) lookup requests, which may, in some instances, be indicative of malware attempts using domain generation algorithms. Similarly, sensors 460 may also detect other types of failed connection attempts, which might indicate attempts by endpoint computer system 120 to passively scan the network or manipulate Address Resolution Protocol (ARP) requests—for example, to facilitate man-in-the-middle attacks or ARP cache poisoning. [Paragraph 65], For example, local analysis logic 420 may be programmed to look for certain sequences of operations, such as failed DNS look ups. Similarly, logic 420 may look for so-called indicators of compromise (e.g., signatures of known malware or attacks) or for common applications communicating over unusual port numbers. [Paragraph 75], As described above, endpoint analysis agent 340 is operable to collect endpoint information, package that information (or a subset of that information) in one or more network flow data records, and send those records to network 110, where it may be received either by network flow analyzer 106, or by network flow collector 104, where it may be ultimately forwarded to analyzer 106. [Paragraph 84], Threats and anomalies determined by module 520 may then be passed to risk analysis module 530, which, in some embodiments, includes computer program instructions executable to assign a risk level (e.g., high, medium, low) to these threats and anomalies. Some activity classified as a threat or anomaly may be determined by module 530 to not be a threat at all. Note that in some embodiments, modules 520 and 530 may be combined into a single module.)
based on anomalous behavior analysis, providing an indication of a detected anomalous behavior for display on a user interface. ([Paragraph 85], As shown, module 530, in some embodiments, is operable to output security alerts and risk findings 532. This information may be output, in some embodiments, via a graphical user interface that allows a network security administrator to view, for a particular identified threat or anomaly, endpoint information in addition to the network-observed activity. Such an interface may allow an administrator to more quickly and accurately assess network security risks. Exemplary screenshots of such an interface are shown in Appendix B.)
Although Holeman silently discloses groups of flows ([Paragraph 7], The network illustrated above has also been divided into three separate broadcast domains 40A-C, indicated from left to right. The benefit of this arrangement is that traffic within a broadcast domain 40A-C is not passed up to a higher-level of the network. Accordingly, local traffic remains local.)
Holeman does not explicitly state domain flows are groups of flows.
Gunda teaches groups of flows ([Paragraph 2], Applications accessible over a communication network may be segmented into various groups. Access to applications in one group may be controlled differently than access to applications in another group. Controlling that access may be performed by a network firewall type system that regulates network traffic being exchanged between physical and/or virtual computing systems on which the applications are running. For example, if a user does not want applications in one group to exchange communications with applications in another group, the user may create a firewall rule to prevent such communications. [Paragraph 4], The information at least indicates a security group for each virtual machine of the plurality of virtual machines. Additionally, the method provides identifying communication traffic flows between virtual machines of the plurality of virtual machines and identifying one or more removable traffic flows of the communication traffic flows based, at least in part, on the information. The method then provides blocking the one or more removable traffic flows.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine teachings of Holeman wherein set of attributes for process flows of a domain(s) is/are received, anomaly indication is provided for process flow(s) and analysis of the anomalous process flow(s) is/are conducted for user display, into teachings of Gunda wherein domains/groups of process flows provides security isolation, monitoring and management, because this would enhance the teachings of Holeman wherein by implementing a security group(s), allows clear separate groups to be established to provide additional security, traffic flows and control of access.
As per claim 22, rejection of claim 21 is incorporated:
Holeman teaches wherein the anomalous behavior indication is a flag bit that indicates anomalous behavior detection. ([Paragraph 59], Sensors 460 are not limited to observing network activity relating to active connections, however. For example, sensors 460 may detect failed Domain Name Service (DNS) lookup requests, which may, in some instances, be indicative of malware attempts using domain generation algorithms. Similarly, sensors 460 may also detect other types of failed connection attempts, which might indicate attempts by endpoint computer system 120 to passively scan the network or manipulate Address Resolution Protocol (ARP) requests—for example, to facilitate man-in-the-middle attacks or ARP cache poisoning. [Paragraph 65], For example, local analysis logic 420 may be programmed to look for certain sequences of operations, such as failed DNS look ups. Similarly, logic 420 may look for so-called indicators of compromise (e.g., signatures of known malware or attacks) or for common applications communicating over unusual port numbers.)
Gunda teaches flag bit ([Paragraph 24], Alternatively, the user may be an expert system or other management entity that can autonomously identify network flows that should be blocked and potentially flag such flows as being anomalous or are in contravention to a defined high-level policy.) discloses well known flagging techniques for indications (e.g. Boolean, true/false, etc.)
As per claim 23, rejection of claim 21 is incorporated:
Holeman teaches wherein the anomalous behavior indication is a value that indicates a type of anomalous behavior detected. ([Paragraph 84], Threats and anomalies determined by module 520 may then be passed to risk analysis module 530, which, in some embodiments, includes computer program instructions executable to assign a risk level (e.g., high, medium, low) to these threats and anomalies. Some activity classified as a threat or anomaly may be determined by module 530 to not be a threat at all. Note that in some embodiments, modules 520 and 530 may be combined into a single module. [Paragraph 59], Sensors 460 are not limited to observing network activity relating to active connections, however. For example, sensors 460 may detect failed Domain Name Service (DNS) lookup requests, which may, in some instances, be indicative of malware attempts using domain generation algorithms. Similarly, sensors 460 may also detect other types of failed connection attempts, which might indicate attempts by endpoint computer system 120 to passively scan the network or manipulate Address Resolution Protocol (ARP) requests—for example, to facilitate man-in-the-middle attacks or ARP cache poisoning. [Paragraph 65], For example, local analysis logic 420 may be programmed to look for certain sequences of operations, such as failed DNS look ups. Similarly, logic 420 may look for so-called indicators of compromise (e.g., signatures of known malware or attacks) or for common applications communicating over unusual port numbers.)
As per claim 24, rejection of claim 23 is incorporated:
Gunda teaches wherein the value for a particular group of flows indicates one of (1) a newly added service rule not having been used to process at least one flow in the particular group of flows to which the newly added service rule applies, (2) a default service rule having been used to process at least one flow in the particular group of flows, and (3) no service rule having been specified for communications between source and destination machine of at least one flow in the particular group of flows. ([Paragraph 20], FIG. 2 illustrates method 200 of operating computing environment 100 to micro-segment virtual computing elements. Method 200 includes micro-segmentation system 101 identifying one or more multi-tier applications, such as multi-tier application 102, comprising a plurality of virtual elements, such as application tier virtual elements 102.1-N(201). Each application tier of multi-tier application 102, and any other multi-tier application identified, comprises at least one of the plurality of virtual elements. Multi-tier application 102 may be identified using a discovery process that monitors virtual elements executing in computing environment 100 to determine a tier in which each virtual element is operating. Other manners of identifying multi-tier applications may also be used, including receiving information identifying multi-tier applications from a user or other system. [Paragraph 21], Method 200 further provides micro-segmentation system 101 maintaining information in tiered application information 121 about the one or more multi-tier applications (202). The information at least indicates a security group for each of the virtual elements. The security groups may be predefined by a user such that certain types of virtual elements (e.g., virtual elements performing certain functions) are placed into corresponding security groups. Alternatively, micro-segmentation system 101 may infer a security group for each virtual element based information obtained while monitoring the virtual elements. Other manners of placing the virtual elements into security groups may also be used. Each security group may define network security policies that should be implemented on virtual elements therein (e.g., virtual elements in one security group may only be allowed to communicate with elements in a particular other security group). [Paragraph 23], After identifying the communication traffic flows, method 200 provides micro-segmentation system 101 identifying one or more removable traffic flows of the communication traffic flows based, at least in part, on the information in tiered application information 121 (204). Removable traffic flows may be communication traffic flows that are outside the normal operation of the virtual elements, flows that are contrary to the security policies of the involved security groups, or flows that otherwise should not be allowed going forward. For instance, application tier virtual element 102.1 may be in a security group that should only communicate with virtual elements in a specific other security group. If application tier virtual element 102.1 is involved in a traffic flow with a virtual element in a different security group, then that traffic flow would be identified as removable.)
As per claim 25, rejection of claim 23 is incorporated:
Gunda teaches wherein the value for a particular group of flows indicates one of (1) a port associated with at least one flow in the particular group of flows not matching a port expected based on an application associated with the at least one flow, (2) a previously blocked flow having been allowed, and (3) an insecure version of an application having been used. ([Paragraph 20], FIG. 2 illustrates method 200 of operating computing environment 100 to micro-segment virtual computing elements. Method 200 includes micro-segmentation system 101 identifying one or more multi-tier applications, such as multi-tier application 102, comprising a plurality of virtual elements, such as application tier virtual elements 102.1-N(201). Each application tier of multi-tier application 102, and any other multi-tier application identified, comprises at least one of the plurality of virtual elements. Multi-tier application 102 may be identified using a discovery process that monitors virtual elements executing in computing environment 100 to determine a tier in which each virtual element is operating. Other manners of identifying multi-tier applications may also be used, including receiving information identifying multi-tier applications from a user or other system. [Paragraph 21], Method 200 further provides micro-segmentation system 101 maintaining information in tiered application information 121 about the one or more multi-tier applications (202). The information at least indicates a security group for each of the virtual elements. The security groups may be predefined by a user such that certain types of virtual elements (e.g., virtual elements performing certain functions) are placed into corresponding security groups. Alternatively, micro-segmentation system 101 may infer a security group for each virtual element based information obtained while monitoring the virtual elements. Other manners of placing the virtual elements into security groups may also be used. Each security group may define network security policies that should be implemented on virtual elements therein (e.g., virtual elements in one security group may only be allowed to communicate with elements in a particular other security group). [Paragraph 23], After identifying the communication traffic flows, method 200 provides micro-segmentation system 101 identifying one or more removable traffic flows of the communication traffic flows based, at least in part, on the information in tiered application information 121 (204). Removable traffic flows may be communication traffic flows that are outside the normal operation of the virtual elements, flows that are contrary to the security policies of the involved security groups, or flows that otherwise should not be allowed going forward. For instance, application tier virtual element 102.1 may be in a security group that should only communicate with virtual elements in a specific other security group. If application tier virtual element 102.1 is involved in a traffic flow with a virtual element in a different security group, then that traffic flow would be identified as removable. [Paragraph 24], Additional or alternative responses to an indication of malware may be to quarantine the VM (e.g., by placing it in a quarantine security group that requires all network flows to and from the virtual element be black-holed), or to pause the virtual element by descheduling it on its host, thus preventing it from executing any new instructions, until it can be analyzed.)
Holeman also teaches ([Paragraph 58], For example, sensors 460 may collect source and destination network address and port information for active network connections—such information may be usable in matching endpoint computing activity with network-observed flow activity. [Paragraph 79], As used herein, “matching” endpoint information with network flow data is intended to broadly cover any process in which endpoint information is used to supplement network-observed flow data. Endpoint information about a particular process executing on an endpoint computer system may be used to augment information about an associated network flow. For example, information about a particular network flow (received from a flow collector) can be supplemented with endpoint information, such as the identity of the process on an endpoint computer system that initiated the particular network flow. [Paragraph 82], But because endpoint information has been collected by endpoint analysis agent 340 and sent to network flow analyzer 106, the port 80 connection may be correlated by flow matching module 510 with information indicating that the connection was not initiated by a web browser, but rather through a task automation program such as a WINDOWS POWERSHELL Additionally, module 510 may also determine that the connection was initiated by the “System” account and not a logged-in user.)
As per claim 26, rejection of claim 21 is incorporated:
Holeman teaches wherein the further analysis comprises analyzing previously received sets of attributes stored in a time series data storage. ([Paragraph 58], Network activity sensors 460, as their name suggests, refer to computer program instructions that are executable to collect information relating to network activity. For example, sensors 460 may collect source and destination network address and port information for active network connections—such information may be usable in matching endpoint computing activity with network-observed flow activity. Sensors 460 may also collect information about the volume of network traffic including, for example, an amount of data sent or received on each connection, either in total for that connection or broken down by time period. [Paragraph 79], As used herein, “matching” endpoint information with network flow data is intended to broadly cover any process in which endpoint information is used to supplement network-observed flow data. Endpoint information about a particular process executing on an endpoint computer system may be used to augment information about an associated network flow. For example, information about a particular network flow (received from a flow collector) can be supplemented with endpoint information, such as the identity of the process on an endpoint computer system that initiated the particular network flow. [Paragraph 82], But because endpoint information has been collected by endpoint analysis agent 340 and sent to network flow analyzer 106, the port 80 connection may be correlated by flow matching module 510 with information indicating that the connection was not initiated by a web browser, but rather through a task automation program such as a WINDOWS POWERSHELL Additionally, module 510 may also determine that the connection was initiated by the “System” account and not a logged-in user.)
Gunda also teaches ([Paragraph 22], Communication traffic monitor 409 may only monitor communication traffic upon request by micro-segmentation application 408, may be configured to continually monitor communication traffic over time and provide information about communication traffic flows responsive to a request from micro-segmentation application 408, or may be configured to monitor traffic in some other time increment beneficial to the identification of communication traffic flows.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
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, Bradley Teets can be reached at 5712723338. 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.
/DONG U KIM/Primary Examiner, Art Unit 2197