DETAILED ACTION
This application has been examined. Claims 1-28 are pending.
Making Final
Applicant's arguments filed 11/3/2025 have been fully considered but they are not persuasive.
The Examiner is maintaining the rejection(s) using the same grounds for rejection and thus making this action FINAL.
Response to Arguments
Applicant's arguments filed 11/3/2025 have been fully considered but they are not persuasive.
Barsheshet-Terrell-Ho-Macdonald-Krieski-Rothstein disclosed (re. Claim 1) wherein a level of the monitoring of the one or more behavior details is based on content of interest in the client request and the server response (Barsheshet-Paragraph 24,each network node 112 is configured to extract and send only a portion of a packet data that contains meaningful information) to actively increase the level for each network flow associated with each indicated turn (Ho-Figure 8,Paragraph 61, Any positive match 803 against the signatures database 802 would result in the detection and marking 804, and data/metadata extraction of a primary sub-transaction and its associated TCP connection 810) and actively decrease the level for each network flow unassociated with each indicated turn (Ho-Figure 8,Paragraph 61, The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected )
Priority
The effective date of the claims described in this application is May 3, 2017.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1-6,8-13,15-20,22-27 are rejected under 35 U.S.C. 103 as being unpatentable over Barsheshet (US PGPUB 2017/0099196) further in view of Terrell (US PGPUB 2012/0278477) further in view of Ho (US PGPUB 2014/0310392) further in view of Macdonald (US Patent 6968554) further in view of Krieski (US PGPUB 2002/0156886) further in view of Rothstein (USPGPUB 2014/0269777) further in view of what was well-known in the networking art.
In regard to Claim 1
Barsheshet Paragraph 27-Paragraph 28 disclosed wherein each node 112 is configured to receive an incoming packet (either a request from a client device 130 or response for a server 140), analyze the packet's header, and perform the action (redirect the packet to controller 111 or send to destination server 140). The controller 111 also configures each of the network nodes 112 with mirroring instructions with a mirror action of X number of bytes within a packet. The mirrored bytes are sent to the controller 111 to perform the DPI analysis. Barsheshet Paragraph 24 disclosed wherein each network node 112 is configured to extract and send only a portion of a packet data that contains meaningful information.
Barsheshet disclosed (re. Claim 1) a method for monitoring one or more network flows, wherein one or more processors in a network computer execute instructions for a plurality of applications that perform actions, comprising:
employing a monitoring engine application (Barsheshet- Paragraph 36, network node 112 includes a probe flow module 321 executes functions and/or implements logic to intercept TCP flags, redirect packets, and count sequence numbers ) to continuously monitor and compare one or more characteristics of the one or more monitored network flows to one or more criteria, wherein the one or more criteria are provided by one or more filters; (Barsheshet- Paragraph 27-Paragraph 28 each node 112 is configured to receive an incoming packet (either a request from a client device 130 or response for a server 140), analyze the packet's header, and perform the action (redirect the packet to controller 111 or send to destination server 140). )
employing a filter engine application to filter network traffic (Barsheshet- Paragraph 37, processing units 314 and 323 uses instructions stored in the memories 313 and 322 respectively to execute tasks generally performed by the central controllers of SDN as well as to control and enable the operation of behavioral network intelligence processes ) based on the one or more filters and the comparison; and
employing a rule engine application (Barsheshet-Paragraph 37, instructions stored in the memories 313 and 322 respectively to execute tasks generally performed by the central controllers of SDN as well as to control and enable the operation of behavioral network intelligence processes ) to perform further actions, including:
providing one or more rules based on the filtered network traffic, wherein each rule is associated with one or more rule prologues and one or more rule actions; (Barsheshet-Paragraph 69, a set of mirroring instructions are generated using the mirror value and sent to the network nodes. Each such instruction defines the packets (designed at least by a specific source/destination IP addresses, and TCP sequences), the number of bytes, and the bytes that should be mirrored )
executing the one or more rule prologues on the filtered network traffic to provide one or more satisfied rule prologues, (Barsheshet-Paragraph 50, One instruction identifies the client to server flow traffic, including the OXM_OF_TCP_SEQ to identify the initial sequence number of the flow with the mask_M computed, while the second instruction identifies the server-to-client flow traffic, including the OXM_OF_TCP_SEQ to identify the initial sequence number of the flow with the mask_N ) wherein the one or more satisfied rule prologues includes indicating a monitored non-sequential network flow; (Barsheshet-Paragraph 53, each instruction hit increments a counter Client-to-Server hit counter X [bytes] and Server-to-Client hit counter Y [bytes], Paragraph 63, probe table 510 is populated with a medium priority probe and termination instructions 511 to detect all SYN, SYN/ACK, FIN, FIN/ACK that are the TCP connection initiation packets ) and
executing one or more of the one or more rule actions based on the one or more satisfied rule prologues, wherein the one or more executed rule actions and the one or more satisfied rule prologues are each associated with a same rule. (Barsheshet-Paragraph 50, The action is to mirror all packets that the instruction applies to, which will result in the TCP_DATA_SIZE_DPI number of byte from the server to client direction to be mirrored to the controller 111 for further analysis , Paragraph 24, The central controller 111 provides inspected data (such as application metadata) to a plurality of application servers (collectively referred to as application servers 120, for security applications (e.g., Firewall, intrusion detection, etc.), data analytic applications, and so on.)
Barsheshet disclosed (re. Claim 1) employing the detected correlation to capture an amount of detail for client requests that are monitored for network traffic (Barsheshet-Paragraph 50, One instruction identifies the client to server flow traffic, including the OXM_OF_TCP_SEQ to identify the initial sequence number of the flow with the mask_M computed, while the second instruction identifies the server-to-client flow traffic, including the OXM_OF_TCP_SEQ to identify the initial sequence number of the flow with the mask_N ) and employ a selected portion of the one or more rules (Barsheshet-Paragraph 53, each instruction hit increments a counter Client-to-Server hit counter X [bytes] and Server-to-Client hit counter Y [bytes], Paragraph 63, probe table 510 is populated with a medium priority probe and termination instructions 511 to detect all SYN, SYN/ACK, FIN, FIN/ACK that are the TCP connection initiation packets ) and
executing one or more of the one or more rule actions based on the one or more satisfied rule prologues, wherein the one or more executed rule actions and the one or more satisfied rule prologues are each associated with a same rule. (Barsheshet-Paragraph 50, The action is to mirror all packets that the instruction applies to, which will result in the TCP_DATA_SIZE_DPI number of byte from the server to client direction to be mirrored to the controller 111 for further analysis , Paragraph 24, The central controller 111 provides inspected data (such as application metadata) to a plurality of application servers (collectively referred to as application servers 120, for security applications (e.g., Firewall, intrusion detection, etc.), data analytic applications, and so on.)
While Barsheshet substantially disclosed the claimed invention Barsheshet did not disclose (re. Claim 1) (re. Claim 1) wherein one or more universal payload analysis (UPA) engines are employed to analyze protocols that are one or more of custom or unsupported natively by the network computer and extract packet payload data from the filtered network traffic.
While Barsheshet substantially disclosed the claimed invention Barsheshet did not disclose (re. Claim 1) indicating that a turn is occurring on a monitored non-sequential network flow of packets between one or more servers and clients based on detection of one or more of a response-request data pattern or a new transaction data pattern, wherein the indication of the turn identifies the detected pattern regarding the monitored network flow in the packets’ payload data.
While Barsheshet substantially disclosed the claimed invention Barsheshet did not disclose (re. Claim 1) ‘employing one or more state machines to classify the protocols by mimicking state changes in the monitored network flows’ .
While Barsheshet substantially disclosed the claimed invention Barsheshet did not disclose (re. Claim 1) employing the protocol classification to enable subsequent classification of one or more applications associated with the monitored network flows.
While Barsheshet substantially disclosed the claimed invention Barsheshet did not disclose (re. Claim 1) ‘detecting a correlation of the indicated turn at layer four and layer seven of the Open System Interconnection (OSI) model for the monitored network flow;’ and -- ‘an affirmative correlation of the indicated turn at both layer four and layer seven of the OSI model ’ .
While Barsheshet substantially disclosed the claimed invention Barsheshet did not disclose (re. Claim 1) employing the detected correlation to increase an amount of detail monitored for network traffic near the indicated turn for the monitored network flow and decrease the amount of detail monitored for network traffic away from the indicated turn for the monitored network flow.
While Barsheshet substantially disclosed the claimed invention Barsheshet did not disclose (re. Claim 1) reducing detection of filtered network traffic in the monitored network flow that is unassociated with the detected correlation, wherein the reduced detection is provided to improve performance of the monitored network flow.
While Barsheshet substantially disclosed the claimed invention Barsheshet did not disclose (re. Claim 1) selecting a rule engine application based on rules applied to the filtered network traffic to evaluate turns at different layers of the monitored network flows requiring less computations than a plurality of other rule engine applications.
Terrell Paragraph 107 disclosed an adudump utility tool for analyzing the performance of services, based on transport-level information in TCP/IP protocol headers on packets sent and received by servers. Terrell Paragraph 107 disclosed building a compact representation of the application-level dialog carried over the connection. Terrell Paragraph 119 thru Paragraph 120 disclosed characterizing a sequence of bidirectional application-level interactions between endpoints of each connection and delays between the interactions. Terrell Paragraph 148 disclosed wherein the adudump tool reports the individual elements of the A-B-T model as "ADU" records. The direction of an ADU indicates whether it is a request or a response. The subsequent think-time is also reported; think-times following a request ADU are server response times. Terrell Paragraph 191 disclosed wherein sequence numbers and acknowledgment numbers can be used to determine ADU sizes as well as a change in the directionality of data transmission.
Terrell disclosed (re. Claim 1) indicating that a turn is occurring on a monitored network flow of packets between one or more servers and clients (Terrell-Figure 3, Paragraph 185, ) and a detection of the turn. (Terrell-Paragraph 174, checks for the existence of an ADU in progress on the outbound flow. For sequential connections, the outbound flow is finished with its ADU when the inbound flow begins sending data (and vice versa). In that case, the outbound flow is marked as inactive, and the now complete outbound ADU is reported, including its direction ( indicates the opposite direction), Paragraph 191 , sequence numbers and acknowledgment numbers can be used to determine ADU sizes as well as a change in the directionality of data transmission) based on detection of one or more of a response-request data pattern or a new transaction data pattern. (Terrell-Paragraph 187, Monitor 114 may utilize the SYN, ACK, SYN-ACK exchange to identify the start of the ADU exchange , Paragraph 191, sequence numbers and acknowledgment numbers can be used to determine ADU sizes as well as a change in the directionality of data transmission )
Barsheshet and Terrell are analogous art because they present concepts and practices regarding monitoring and filtering of application data flows. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Terrell into Barsheshet. The motivation for said combination would have been to generate a model of ADU exchanges for each TCP connection seen in the network wherein the adudump tool not only reports the size of the ADUs, but the application-level think-time between ADUs. (Terrell-Paragraph 184)
While Barsheshet-Terrell substantially disclosed the claimed invention Barsheshet-Terrell did not disclose (re. Claim 1) (re. Claim 1) wherein one or more universal payload analysis (UPA) engines are employed to analyze protocols that are one or more of custom or unsupported natively by the network computer and extract packet payload data from the filtered network traffic.
While Barsheshet-Terrell substantially disclosed the claimed invention Barsheshet-Terrell did not disclose (re. Claim 1) a monitored non-sequential network flow , indicating that a turn is occurring wherein the indication of the turn identifies the detected pattern regarding the monitored network flow in the packets’ payload data.
While Barsheshet-Terrell substantially disclosed the claimed invention Barsheshet-Terrell did not disclose (re. Claim 1) ‘employing one or more state machines to classify the protocols by mimicking state changes in the monitored network flows’.
While Barsheshet-Terrell substantially disclosed the claimed invention Barsheshet-Terrell did not disclose (re. Claim 1) employing the protocol classification to enable subsequent classification of one or more applications associated with the monitored network flows.
While Barsheshet-Terrell substantially disclosed the claimed invention Barsheshet-Terrell did not disclose (re. Claim 1) ‘detecting a correlation of the indicated turn at layer four and layer seven of the Open System Interconnection (OSI) model for the monitored network flow;’ and -- ‘an affirmative correlation of the indicated turn at both layer four and layer seven of the OSI model ’ .
While Barsheshet-Terrell substantially disclosed the claimed invention Barsheshet-Terrell did not disclose (re. Claim 1) employing the detected correlation to increase an amount of detail monitored for network traffic near the indicated turn for the monitored network flow and decrease the amount of detail monitored for network traffic away from the indicated turn for the monitored network flow.
While Barsheshet-Terrell substantially disclosed the claimed invention Barsheshet-Terrell did not disclose (re. Claim 1) reducing detection of filtered network traffic in the monitored network flow that is unassociated with the detected correlation, wherein the reduced detection is provided to improve performance of the monitored network flow.
While Barsheshet-Terrell substantially disclosed the claimed invention Barsheshet-Terrell did not disclose (re. Claim 1) selecting a rule engine application based on rules applied to the filtered network traffic to evaluate turns at different layers of the monitored network flows requiring less computations than a plurality of other rule engine applications.
Ho Figure 2,Paragraph 38, Figure 8,Paragraph 61 thru Paragraph 63,Figure 9, Paragraph 66 thru Paragraph 67, Paragraph 73 disclosed wherein signatures- and context-driven application searches can be executed across multiple buffered (at the proxy 103) TCP packets and their payloads in a single TCP connection, in both directions (or more accurately, two spliced TCP connections acting as a single TCP connection). An example of such a DPI/message search would be string and regex search for a TCP connection and associated packet(s) with an incoming HTTP GET message (a signature from 205) with a predefined URL form and content (a signature in the form of a regex from 205) that indicates a HTTP request for a web-based "product and service" query in the form of a URL, initiated from a mobile client. Another example would be, in the reverse direction (from datacenter to client) the HTTP OK message of type (text/html) of the HTTP response of the previous web request example.
Ho disclosed (re. Claim 1) a monitored non-sequential network flow, (Ho-Paragraph 33, intelligent proxy 103 intercepts and processes all TCP flows/packets and HTTP(S) messages 112 into and out of a datacenter 104 , Paragraph 41,Paragraph 52, The transactions patterns/signatures defined--via transaction manager 204 and policy manager 201 (and datacenter administrators or automated cloud services)--are stateful in a HTTP sense (across multiple HTTP messages), through which multiple HTTP messages (both ingress and egress directions, detected and previously processed by classifier 211) are grouped together (correlated) by the transaction analyzer 206 into "sub-transactions," and the appropriate sets of "sub-transactions" are further grouped together (correlated) into end-to-end web transactions) indicating that a turn is occurring (Ho-Paragraph 45, web applications are broken down into three (major) constituent steps during their operations end-to-end , Paragraph 61, detect and to classify web transactions inflight, these operations are taken by the intelligent proxy 103 in the ingress direction (from client to intelligent proxy/datacenter), first to detect and process the primary sub-transactions ) and a detection of the turn (Ho-Paragraph 66, For the egress direction (datacenter to client), the intelligent proxy 103 performs similar steps and processing to detect and process the responses and traffic associated with the corresponding primary sub-transactions (after their requests' detection via the algorithms detailed before and illustrated in FIG. 8) wherein the indication of the turn identifies the detected pattern regarding the monitored network flow in the packets’ payload data (Ho-Paragraph 68, Upon successful detection 903 of a response of the primary sub-transaction (a successful string match), the classifier 211 marks the success of detecting the HTTP response message 904 and stores the related data for further analysis )
Ho disclosed (re. Claim 1) ‘detecting a correlation of the indicated turn at layer four and layer seven of the Open System Interconnection (OSI) model for the monitored network flow;’ ( Ho-Paragraph 45, web applications are broken down into three (major) constituent steps during their operations end-to-end , Paragraph 61, detect and to classify web transactions inflight, these operations are taken by the intelligent proxy 103 in the ingress direction (from client to intelligent proxy/datacenter), first to detect and process the primary sub-transactions , Paragraph 66, For the egress direction (datacenter to client), the intelligent proxy 103 performs similar steps and processing to detect and process the responses and traffic associated with the corresponding primary sub-transactions (after their requests' detection via the algorithms detailed before and illustrated in FIG. 8 ) -- and -- ‘an affirmative correlation of the indicated turn at both layer four and layer seven of the OSI model ’ (Ho-Paragraph 40, Time-stamping at application (HTTP message and metadata) level should be associated with the corresponding time-stamping at the TCP packet/header level (e.g., TSopt) so that further analysis can be performed by the timing analyzer 203 for response-related measurements and reconstructions, Paragraph 41, A transaction analyzer 206 uses transaction patterns/signatures 205 to--together with classifier 211 (above)--discover and detect web transactions at protocol-speed and to initiate additional processing, such as chronographic functions and timing analysis (FIG. 2). The transactions patterns/signatures defined--via transaction manager 204 and policy manager 201 (and datacenter administrators or automated cloud services)--are stateful in a HTTP sense (across multiple HTTP messages), through which multiple HTTP messages (both ingress and egress directions, detected and previously processed by classifier 211) are grouped together (correlated) by the transaction analyzer 206 )
Ho disclosed (re. Claim 1) employing the detected correlation to increase an amount of detail monitored for network traffic near the indicated turn for the monitored network flow (Ho-Figure 8,Paragraph 61, Any positive match 803 against the signatures database 802 would result in the detection and marking 804, and data/metadata extraction of a primary sub-transaction and its associated TCP connection 810) and decrease the amount of detail monitored for network traffic away from the indicated turn for the monitored network flow (Ho-Figure 8,Paragraph 61, The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected ) while continuing to monitor the details of the network traffic at a decreased level for subsequent analysis wherein the decreasing of the amount of detail monitored is used to improve performance of the monitored network flow (Ho-Paragraph 87, overall (net) response time of a web transaction can be, for the first time, measured inline and with precision )
The Examiner notes wherein Ho is continuing to monitor even while decreasing the amount of detail monitored from the network traffic because Ho is able to detect the next primary sub-transaction (Ho-Paragraph 33, intelligent proxy 103 intercepts and processes all TCP flows/packets and HTTP(S) messages 112 into and out of a datacenter 104 ) .
Barsheshet,Terrell and Ho are analogous art because they present concepts and practices regarding monitoring and filtering of application data flows. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Ho into Barsheshet-Terrell. The motivation for said combination would have been to diagnose and report overall (net) response time of a web transaction measured inline and with precision.(Ho-Paragraph 87)
The Examiner notes wherein Ho does not explicitly disclosed increasing or decreasing the amount of details monitored.
The Supreme Court in KSR International Co. v. Teleflex Inc., identified a number of rationales to support a conclusion of obviousness which are consistent with the proper "functional approach" to the determination of obviousness as laid down in Graham. An exemplary rationale that may support a conclusion of obviousness is that of (A) Combining prior art elements according to known methods to yield predictable results; and (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Before the time of the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the networking art to combine the Ho process of monitoring for sub-transaction data with the Terrell disclosure regarding transport-level information in TCP/IP protocol headers on packets sent and received by servers. The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected. In context of Ho-Terrell it would have been an obvious and predictable result that the granular sub-transaction data would increase the amount of details at the desired context of the turn of traffic and conversely decrease the amount of details when there is no turn of traffic detected.
While Barsheshet-Terrell-Ho substantially disclosed the claimed invention Barsheshet-Terrell-Ho did not disclose (re. Claim 1) wherein one or more universal payload analysis (UPA) engines are employed to analyze protocols that are one or more of custom or unsupported natively by the network computer and extract packet payload data from the filtered network traffic.
While Barsheshet-Terrell-Ho substantially disclosed the claimed invention Barsheshet-Terrell-Ho did disclose (re. Claim 1) ‘employing one or more state machines to classify the protocols by mimicking state changes in the monitored network flows’.
While Barsheshet-Terrell-Ho substantially disclosed the claimed invention Barsheshet-Terrell-Ho did disclose (re. Claim 1) employing the protocol classification to enable subsequent classification of one or more applications associated with the monitored network flows.
Macdonald Column 8 Lines 40-55 disclosed unpacking the payloads from the protocol data units as instructed by a protocol interpreter associated with the protocol layer that created the protocol data units, and for creating and maintaining a flow object database that holds flow objects representing the data flows at each protocol layer. The flow objects are arranged in a hierarchical flow tree data structure corresponding to the layers in the protocol stack.
Macdonald disclosed (re. Claim 1) wherein one or more universal payload analysis (UPA) engines are employed to analyze protocols ( Macdonald-Column 12 Lines 40-45, The SarAddDu( ) API is used by a protocol interpreter (PI) to instruct the SAR decode engine to extract the payload of a protocol data unit (PDU) to a circuit flow object, Column 8 Lines 40-55 , disclosed unpacking the payloads from the protocol data units as instructed by a protocol interpreter associated with the protocol layer that created the protocol data units, and for creating and maintaining a flow object database that holds flow objects representing the data flows at each protocol layer. The flow objects are arranged in a hierarchical flow tree data structure corresponding to the layers in the protocol stack.) that are one or more of custom or unsupported natively by the network computer ( Macdonald-Column 6 Lines 55-65, there are two connections between the computers at the transport protocol layer, one for retrieving HTML formatted web pages using the HTTP application protocol and one for retrieving data from a Microsoft SQL database using a tabular data stream (TDS) protocol ) and extract packet payload data from the filtered network traffic. ( Macdonald-Column 12 Lines 40-45, The SarAddDu( ) API is used by a protocol interpreter (PI) to instruct the SAR decode engine to extract the payload of a protocol data unit (PDU) to a circuit flow object, Column 8 Lines 40-55 , disclosed unpacking the payloads from the protocol data units as instructed by a protocol interpreter associated with the protocol layer that created the protocol data units, and for creating and maintaining a flow object database that holds flow objects representing the data flows at each protocol layer. The flow objects are arranged in a hierarchical flow tree data structure corresponding to the layers in the protocol stack.)
Barsheshet,Terrell,Ho and Macdonald are analogous art because they present concepts and practices regarding monitoring and filtering of application data flows. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Macdonald into Barsheshet-Terrell-Ho. The motivation for said combination would have been to manage data flow storage structures that are common for all protocol interfaces, further reducing the complexity of the individual protocol interpreter and eliminating the need for specialized interfaces previously required to pass data from layer to layer. (Macdonald-Column 2 Lines 10-25)
While Barsheshet-Terrell-Ho-Macdonald substantially disclosed the claimed invention Barsheshet-Terrell-Ho-Macdonald did disclose (re. Claim 1) ‘employing one or more state machines to classify the protocols by mimicking state changes in the monitored network flows’.
While Barsheshet-Terrell-Ho-Macdonald substantially disclosed the claimed invention Barsheshet-Terrell-Ho-Macdonald did disclose (re. Claim 1) employing the protocol classification to enable subsequent classification of one or more applications associated with the monitored network flows.
Krieski Paragraph 50 disclosed wherein protocol system 100 provides for emulation which consists of defining finite state machines that contain stimulus events, responses to those events, and transitions among states.
Krieski disclosed (re. Claim 1) ‘employing one or more state machines to classify the protocols by mimicking state changes in the monitored network flows’.(Krieski -Paragraph 167,protocol emulation logic 1102. The user provides protocol emulation logic 1102 by starting and stopping finite state machines in the protocol finite state machine library 118 )
Barsheshet,Terrell,Ho and Krieski are analogous art because they present concepts and practices regarding monitoring and filtering of application data flows. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Krieski into Barsheshet-Terrell-Ho. The motivation for said combination would have been to implement a generic solution that allows any current and future protocol to be monitored on a user interface by eliminating a need to write protocol specific software. (Krieski -Paragraph 15)
While Barsheshet-Terrell-Ho-Macdonald substantially disclosed the claimed invention Barsheshet-Terrell-Ho-Macdonald did disclose (re. Claim 1) employing the protocol classification to enable subsequent classification of one or more applications associated with the monitored network flows.
While Barsheshet-Terrell-Ho-Macdonald substantially disclosed the claimed invention Barsheshet-Terrell-Ho-Macdonald did disclose (re. Claim 1) detecting the correlation between one or more expected states and one or more actual states of filtered network traffic of the indicated turn at layer four and layer seven of the OSI model for encryption behavior.
Rothstein Paragraph 33 disclosed classifying the network traffic according to communication protocols that are used. The NMD may categorize the traffic where categories might include file transfers, streaming audio, streaming video, database access, interactive, gaming, and the like. The NMD may attempt to determine whether the traffic corresponds to known communications protocols, such as HTTP, FTP, SMTP, RTP, Tabular Data Stream (TDS), TCP, IP, and the like. In some embodiments, protocol classification may be a necessary precondition to application classification. While some protocols run on well known L4 ports, others do not. Even if there is traffic on a well known port, it is not necessarily the protocol assigned to that port. As a result, protocol classification can include additional analysis, such as signature matching, traffic analysis, and other heuristics.
Rothstein Paragraph 110 disclosed extracting information from the monitored flow, including protocol information at various layers of the protocol stack and analyzing information at one or more layers of the OSI protocol stack, such as layers 4 through 7.
Rothstein disclosed (re. Claim 1) employing the protocol classification to enable subsequent classification of one or more applications associated with the monitored network flows. (Rothstein-Paragraph 110, The NMD may categorize the traffic where categories might include file transfers, streaming audio, streaming video, database access, interactive, gaming, or the like. The NMD may determine whether the network traffic corresponds to known communications protocols, such as, for example, HTTP, FTP, SMTP, RTP, TDS , Paragraph 33, wherein protocol classification may be a necessary precondition to application classification )
Rothstein disclosed (re. Claim 1) detecting the correlation between one or more expected states and one or more actual states of filtered network traffic of the indicated turn at layer four and layer seven of the OSI model for encryption behavior.(Rothstein-Paragraph 102, NMD may observe one or more handshakes that negotiate and/or establish decryption keys for the session…determining if the monitored flow is encrypted, Paragraph 104, Figure 7, Figure 8, decrypting an encrypted monitored flow using a stream cipher and decrypting an encrypted monitored flow using a block cipher)
Barsheshet,Terrell,Ho and Rothstein are analogous art because they present concepts and practices regarding monitoring and filtering of application data flows. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Rothstein into Barsheshet-Terrell-Ho. The motivation for said combination would have been to implement network flow analysis for wherein traffic on a well known port is not necessarily the protocol assigned to that port.(Rothstein-Paragraph 33)
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 1) employing a monitoring engine application (Barsheshet- Paragraph 36, network node 112 includes a probe flow module 321 executes functions and/or implements logic to intercept TCP flags, redirect packets, and count sequence numbers ) to continuously monitor and compare one or more details of the one or more monitored network flows to one or more criteria,
comparing each state change in the monitored network flows to one or more
state changes predicted by one or more state machine rules to identify one or more anomalies in the filtered network traffic; (Barsheshet- Paragraph 24, The central controller 111 provides inspected data (such as application metadata) to a plurality of application servers (collectively referred to as application servers 120, for security applications (e.g., Firewall, intrusion detection, etc.), data analytic applications, and so on.) and
wherein a level of the monitoring of the one or more details is increased for each network flow associated with each turn (Ho-Figure 8,Paragraph 61, Any positive match 803 against the signatures database 802 would result in the detection and marking 804, and data/metadata extraction of a primary sub-transaction and its associated TCP connection 810) and decreased for each network flow unassociated with each turn: (Ho-Figure 8,Paragraph 61, The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected )
employing the detected correlation to increase a level of detail for client requests that are monitored for network traffic near the indicated turn (Ho-Figure 8,Paragraph 61, Any positive match 803 against the signatures database 802 would result in the detection and marking 804, and data/metadata extraction of a primary sub-transaction and its associated TCP connection 810) and employ a selected portion of the one or more rules near the indicated turn for the monitored network flow and decrease the amount level of detail continued to be monitored for network traffic away from the indicated turn for the monitored network flow, (Ho-Figure 8,Paragraph 61, The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected )
wherein the decreasing of the amount level of detail monitored away from the indicated turn is used to improve performance of the monitored network flow (Ho-Paragraph 87, overall (net) response time of a web transaction can be, for the first time, measured inline and with precision ) while continuing to monitor the details of the network traffic at a decreased level for subsequent analysis; (Ho-Figure 8,Paragraph 61, The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected )
The Examiner notes wherein Ho is continuing to monitor the details of the network traffic because Ho is able to detect the next primary sub-transaction (Ho-Paragraph 33, intelligent proxy 103 intercepts and processes all TCP flows/packets and HTTP(S) messages 112 into and out of a datacenter 104 ) .
The Examiner notes wherein Barsheshet-Terrell-Ho does not explicitly disclose identifying one or more anomalies in the filtered network traffic.
However Barsheshet Paragraph 24 disclosed wherein the central controller 111 provides inspected data (such as application metadata) to a plurality of application servers (collectively referred to as application servers 120, for security applications (e.g., Firewall, intrusion detection, etc.), data analytic applications, and so on.)
The Supreme Court in KSR International Co. v. Teleflex Inc., identified a number of rationales to support a conclusion of obviousness which are consistent with the proper "functional approach" to the determination of obviousness as laid down in Graham. An exemplary rationale that may support a conclusion of obviousness is that of (A) Combining prior art elements according to known methods to yield predictable results; and (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Before the time of the effective filing date of the claimed invention it would have been well-known to a person of ordinary skill in the networking art to intercept data for identifying anomalous network traffic by comparing attributes of intercepted traffic with filter criteria. Before the time of the effective filing date of the claimed invention and in context of Barsheshet-Terrell-Ho it would have been obvious to a person of ordinary skill in the networking art to implement the Barsheshet security applications (e.g., Firewall, intrusion detection, etc. ) and/or data analytic applications for identifying anomalous network traffic.
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 1) selecting a rule engine application (Barsheshet- Paragraph 37, processing units 314 and 323 uses instructions stored in the memories 313 and 322 respectively to execute tasks generally performed by the central controllers of SDN as well as to control and enable the operation of behavioral network intelligence processes ) based on one or more rules applied to the filtered network traffic (Barsheshet-Paragraph 37, instructions stored in the memories 313 and 322 respectively to execute tasks generally performed by the central controllers of SDN as well as to control and enable the operation of behavioral network intelligence processes ) to evaluate turns at different layers of the monitored network flows (Ho-Paragraph 33, intelligent proxy 103 intercepts and processes all TCP flows/packets and HTTP(S) messages 112 into and out of a datacenter 104 , Paragraph 41,Paragraph 52, The transactions patterns/signatures defined--via transaction manager 204 and policy manager 201 (and datacenter administrators or automated cloud services)--are stateful in a HTTP sense (across multiple HTTP messages), through which multiple HTTP messages (both ingress and egress directions, detected and previously processed by classifier 211) are grouped together (correlated) by the transaction analyzer 206 into "sub-transactions," and the appropriate sets of "sub-transactions" are further grouped together (correlated) into end-to-end web transactions) and requiring less computations than a plurality of other rule engine applications (Ho-Figure 8,Paragraph 61, The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected ) wherein each rule is associated with one or more rule prologues and one or more rule actions and wherein the selected rule engine application is employed to perform further actions (Barsheshet-Paragraph 69, a set of mirroring instructions are generated using the mirror value and sent to the network nodes. Each such instruction defines the packets (designed at least by a specific source/destination IP addresses, and TCP sequences), the number of bytes, and the bytes that should be mirrored )
The Examiner notes wherein Ho does not explicitly disclosed increasing or decreasing the amount of behavior details monitored.
The Supreme Court in KSR International Co. v. Teleflex Inc., identified a number of rationales to support a conclusion of obviousness which are consistent with the proper "functional approach" to the determination of obviousness as laid down in Graham. An exemplary rationale that may support a conclusion of obviousness is that of (A) Combining prior art elements according to known methods to yield predictable results; and (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Before the time of the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the networking art to combine the Ho process of monitoring for sub-transaction data with the Terrell disclosure regarding transport-level information in TCP/IP protocol headers on packets sent and received by servers. The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected. In context of Ho-Terrell it would have been an obvious and predictable result that the granular sub-transaction data would increase the amount of behavior details at the desired context of the turn of traffic and conversely decrease the amount of behavior details when there is no turn of traffic detected.
The Examiner notes wherein Ho does not explicitly disclose requiring less computations than a plurality of other rule engine applications
Official Notice (see MPEP 2144.03) is taken that at the time of the invention it would have been well-known in the networking art that the cost of computational resources being consumed is directly correlated to the volume/amount of data being processed/stored. In the context of the Barsheshet-Terrell-Ho, computational resources being consumed are directly correlated to the amount data traffic being selected/filtered/stored for analysis. In the context of the Barsheshet-Terrell-Ho it would have been obvious to a person of ordinary skill in the networking art that less data captured and processed due to the Ho filtering rule that decreases the amount of details when there is no turn of traffic detected also leads to requiring less computations for processing.
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 1) selecting a rule engine application (Barsheshet- Paragraph 37, processing units 314 and 323 uses instructions stored in the memories 313 and 322 respectively to execute tasks generally performed by the central controllers of SDN as well as to control and enable the operation of behavioral network intelligence processes ) based on one or more rules applied to the filtered network traffic (Barsheshet-Paragraph 37, instructions stored in the memories 313 and 322 respectively to execute tasks generally performed by the central controllers of SDN as well as to control and enable the operation of behavioral network intelligence processes )
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 1) selecting one of a plurality of rule engine applications (Barsheshet- Paragraph 37, processing units 314 and 323 uses instructions stored in the memories 313 and 322 respectively to execute tasks generally performed by the central controllers of SDN as well as to control and enable the operation of behavioral network intelligence processes ) to evaluate network traffic with a particular portion of the one or more rules that are arranged to monitor the one or more details of the network traffic (Ho-Paragraph 36, classifier 211 performs application-ware DPI (deep packet inspection) searches and pattern matching (e.g., regular expression "regex" string searches) into the reconstructed payloads (e.g., HTTP messages) of buffered TCP packets (TCP connection terminated previously) to detect and filter HTTP protocol metadata (e.g., message types), perform string (regex) searches/matching against HTTP messages and their contents (e.g., URIs/URLs) and other information embedded in the HTTP messages and their payloads (e.g., HTML/text data and files). ) wherein each rule is associated with one or more rule prologues and one or more rule actions, and wherein the one or more monitored details near the one or more turns include one or more of tuple information, payload content, communication protocol, application protocol, bit rate, packet size or time of day,(Ho-Paragraph 66, classifier 211 performs string search operations (e.g., regex-based search) at the HTTP message layer to detect the response of the primary sub-transaction 901, whose transaction request has already been detected (detailed before; FIG. 8). The signatures database 902 used for the string search/matching contains regular expression (regex) defined search patterns spanning both HTTP message types (e.g., HTTP OK) and their metadata and other payload data (e.g., of type html/text) 902..)
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 1) processors in a network computer that execute instructions that are configured to cause a plurality of applications to perform actions, (Barsheshet- Paragraph 24, The central controller 111 provides inspected data (such as application metadata) to a plurality of application servers (collectively referred to as application servers 120, for security applications (e.g., Firewall, intrusion detection, etc.), data analytic applications, and so on.) comprising: employing a monitoring engine application to continuously monitor and compare one or more details of the one or more monitored network flows to one or more criteria, wherein one or more of a plurality of filters are selected to provide the one or more criteria for the one or more monitored network flows, and wherein selection of the one or more filters is based on previously selected filter heuristics,(Barsheshet-Paragraph 67-68, using at least the sequence numbers of the first and second packets a mask value is computed. The mask value is utilized to determine which bytes from the flow respective of the sequence numbers N and M should be mirrored by the nodes ) configuration information, and a policy rule;
comparing each state change in the monitored network flows to one or more state changes predicted by one or more state machine rules to identify one or more anomalies in the filtered network traffic, (Barsheshet- Paragraph 24, The central controller 111 provides inspected data (such as application metadata) to a plurality of application servers (collectively referred to as application servers 120, for security applications (e.g., Firewall, intrusion detection, etc.), data analytic applications, and so on.) and wherein filtered network traffic that temporally occurs during the one or more anomalies is captured, stored and acted upon by one or more anomaly related rules; (Barsheshet-Paragraph 33, In order to track the flows, the central controller 111 also maintains a flow table ,Paragraph 61-62,each network node 112 is populated with one or more probe tables generated by the central controller 111.)
in response to execution of one or more rules on the filtered network traffic providing an indication of non-routine network traffic, selecting one of a plurality of rule engine applications to evaluate network traffic with a particular portion of the one or more rules that are arranged to monitor one or more correlations provided by the particular rule portion (Ho-Paragraph 40, Time-stamping at application (HTTP message and metadata) level should be associated with the corresponding time-stamping at the TCP packet/header level (e.g., TSopt) so that further analysis can be performed by the timing analyzer 203 for response-related measurements and reconstructions)for the one or more details of the network traffic near one or more turns at different Open Systems Interconnection (OSD) layers of the monitored network flows based on the one or more correlations for the particular rule portion (Ho-Paragraph 40, Time-stamping at application (HTTP message and metadata) level should be associated with the corresponding time-stamping at the TCP packet/header level (e.g., TSopt) so that further analysis can be performed by the timing analyzer 203 for response-related measurements and reconstructions) that requires less computations to do so than a remainder of the plurality of rule engine applications
wherein the one or more monitored details near the one or more turns include one or more of tuple information, payload content, (Ho-Paragraph 66, classifier 211 performs string search operations (e.g., regex-based search) at the HTTP message layer to detect the response of the primary sub-transaction 901, whose transaction request has already been detected (detailed before; FIG. 8). The signatures database 902 used for the string search/matching contains regular expression (regex) defined search patterns spanning both HTTP message types (e.g., HTTP OK) and their metadata and other payload data (e.g., of type html/text) 902..) communication protocol, application protocol, bit rate, packet size and time of day, (Ho-Paragraph 40, Time-stamping at application (HTTP message and metadata) level should be associated with the corresponding time-stamping at the TCP packet/header level (e.g., TSopt) so that further analysis can be performed by the timing analyzer 203 for response-related measurements and reconstructions)
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 1) employing a monitoring engine application to continuously monitor and compare one or more behavior details of the one or more monitored network flows to one or more criteria,(Ho-Paragraph 32, detecting, classifying, and reconstructing web transactions, measuring and analyzing web transactions' behaviors,… also Terrell Paragraph 191,sequence numbers and acknowledgment numbers can be used to determine ADU sizes as well as a change in the directionality of data transmission,Paragraph 140, by observing the sequence numbers of packets as they travel across the network, one can infer how the application is using the network.)
comparing each state change in an actual state of the monitored network flows (Terrell-Figure 3.4(b), CDF of actual vs. measured think time distributions, for either direction) to one or more state changes predicted by one or more state machine rules (Terrell-Paragraph 111, a profile of "normal" performance for a server regardless of the scale of response times, regardless of the distribution of response times, and regardless of how widely the performance typically varies for the server ) to discover one or more anomalies in the filtered network traffic for the actual state,(Terrell-Paragraph 104, The response times for a particular server are then aggregated into daily distributions. Over many days, these distributions may be used to define a profile of the typical response time distribution for that server. New distributions of response times may then be compared to the profile to determine whether they are anomalous.)
monitor one or more correlations provided by the particular rule portion for the one or more behavior details of the network traffic near one or more turns at different Open Systems Interconnection (OSI) layers of the monitored network flows based on the one or more correlations
employing the detected correlation to increase a level of behavior detail for client requests that are continuously monitored for network traffic near the indicated turn and employ a selected portion of the one or more rules near the indicated turn for the monitored network flow and decrease the level of behavior detail continuously monitored for network traffic away from the indicated turn for the monitored network flow, wherein the decreasing of the level of behavior detail continuously monitored away from the indicated turn is used to improve performance of the monitored network flow while continuing to monitor the behavior details of the network traffic at a decreased level for subsequent analysis.
While Barsheshet-Terrell-Ho-Macdonald-Krieski substantially disclosed the claimed invention Barsheshet-Terrell-Ho-Macdonald-Krieski did disclose (re. Claim 1) generating a virtual circuit connection in a third (Network) layer of the OSI model where all data packets belonging to a same monitored network flow are delivered over a same path, wherein hardware-based switching speed of the network computer is increased by associating a virtual circuit connection identifier instead of routing information with each monitored network flow that is delivered over the virtual circuit connection.
Rothstein disclosed (re. Claim 1) generating a virtual circuit connection in a third (Network) layer of the OSI model where all data packets belonging to a same monitored network flow are delivered over a same path, (Rothstein-Paragraph 28, virtual circuit connection may be established in a datalink layer or network layer switching mode, where all data packets belonging to the same traffic stream are delivered over the same path) wherein hardware-based switching speed of the network computer is increased by associating a virtual circuit connection identifier instead of routing information with each monitored network flow that is delivered over the virtual circuit connection (Rothstein-Paragraph 28, traffic flows are identified by some connection identifier rather than by complete routing information, which enables fast hardware based switching.)
Barsheshet-Terrell-Ho-Macdonald-Krieski-Rothstein disclosed (re. Claim 1) determining both of a request from a client and a response corresponding to a server (Barsheshet- Paragraph 27-Paragraph 28 each node 112 is configured to receive an incoming packet (either a request from a client device 130 or response for a server 140), analyze the packet's header, and perform the action (redirect the packet to controller 111 or send to destination server 140). ) based on observation of the one or more behavior details (Ho-Paragraph 32, detecting, classifying, and reconstructing web transactions, measuring and analyzing web transactions' behaviors,… also Terrell Paragraph 191,sequence numbers and acknowledgment numbers can be used to determine ADU sizes as well as a change in the directionality of data transmission,Paragraph 140, by observing the sequence numbers of packets as they travel across the network, one can infer how the application is using the network.) at just layer four of an Open System Interconnection (OSI) model for the monitored network flow (Terrell-Paragraph 174, checks for the existence of an ADU in progress on the outbound flow. For sequential connections, the outbound flow is finished with its ADU when the inbound flow begins sending data (and vice versa). In that case, the outbound flow is marked as inactive, and the now complete outbound ADU is reported, including its direction ( indicates the opposite direction), Paragraph 191 , sequence numbers and acknowledgment numbers can be used to determine ADU sizes as well as a change in the directionality of data transmission)
wherein monitored layer seven behavior details near discovered turns additionally includes a communication protocol and an application protocol. (Rothstein-Paragraph 11, extracting information from the monitored flow, including protocol information at various layers of the protocol stack and analyzing information at one or more layers of the OSI protocol stack, such as layers 4 through 7.)
Barsheshet-Terrell-Ho-Macdonald-Krieski-Rothstein disclosed (re. Claim 1) wherein a level of the monitoring of the one or more behavior details is based on content of interest in the client request and the server response (Barsheshet-Paragraph 24,each network node 112 is configured to extract and send only a portion of a packet data that contains meaningful information) to actively increase the level for each network flow associated with each indicated turn (Ho-Figure 8,Paragraph 61, Any positive match 803 against the signatures database 802 would result in the detection and marking 804, and data/metadata extraction of a primary sub-transaction and its associated TCP connection 810) and actively decrease the level for each network flow unassociated with each indicated turn (Ho-Figure 8,Paragraph 61, The Examiner notes Ho Figure 8 wherein if there is no match then the HTTP request is NOT marked as a primary sub-transaction, which is equivalent to the reducing the detection of filtered network traffic away from the indicated turn because Ho does not further detect/filter /mark/store any of the incoming sub-transactions until the next primary sub-transaction is detected )
In regard to Claim 8
Claim 8 (re. a system) recites substantially similar limitations as Claim 1. Claim 8 is rejected on the same basis as Claim 1.
Further Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 8) a network computer (Barsheshet-Paragraph 24, network node 112 is configured to determine if an incoming packet requires inspection or not) comprising a transceiver that communicates over the network; a memory that stores at least instructions; and one or more processors that execute instructions that perform actions.
Further Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 8) a client computer (Barsheshet-Paragraph 22, client device 130 may be, for example, a smart phone, a tablet computer, a personal computer, a laptop computer, a wearable computing device ) comprising a transceiver that communicates over the network; a memory that stores at least instructions; and one or more processors that execute instructions that perform actions.
In regard to Claim 15
Claim 15 (re. non-transitory storage media) recites substantially similar limitations as Claim 1. Claim 15 is rejected on the same basis as Claim 1.
In regard to Claim 22
Claim 22 (re. network computer) recites substantially similar limitations as Claim 1 and 8. Claim 22 is rejected on the same basis as Claim 1 and 8.
In regard to Claim 2,9,16,23
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 2,9,16,23) wherein providing the one or more rules, further comprises, providing the one or more rules based on which of the one or more filters are associated with the filtered network traffic. (Barsheshet-Paragraph 69, a set of mirroring instructions are generated using the mirror value and sent to the network nodes. Each such instruction defines the packets (designed at least by a specific source/destination IP addresses, and TCP sequences), the number of bytes, and the bytes that should be mirrored )
In regard to Claim 3,10,17,24
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 3,10,17,24) wherein the one or more criteria provided by the one or more filters include one or more discoveries of one or more new network flows or one or more new network devices on a monitored network.(Barsheshet-Paragraph 42, create a new bi-directional flow-id with M and N sequence numbers identified and the sequence mask logic can be calculated respective thereof )
In regard to Claim 4,11,18,25
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 4,11,18,25) wherein executing the one or more rule prologues on the filtered network traffic, further comprises, inspecting payload contents of one or more network packets that are included in the filtered network traffic.(Barsheshet-Paragraph 43, DPI flow detection module 311 implements or executes a sequence mask logic that computes a mask for the initial trapped sequence numbers (M and N) to be used for a new flow to be configured into the node 112. Specifically, the computed mask is used to define new mirroring instructions to allow mirroring of a number of bytes from the TCP session in both directions. The computed mask value specifies which bytes respective of the correct sequence number would be required to mirror from the TCP session )
In regard to Claim 5,12,19,26
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 5,12,19,26) wherein executing the one or more rule prologues on the filtered network traffic, further comprises, employing one or more state machines (Terrell-Paragraph 119, data processing module adudump tool ) to compare one or more state transitions in the filtered network traffic to one or more expected state transitions. (Terrell-Paragraph 149, information about the connection context is reported by adudump tool )
In regard to Claim 6,13,20,27
Barsheshet-Terrell-Ho-Macdonald-Krieski disclosed (re. Claim 6,13,20,27) wherein the one or more criteria provided by the one or more filters include one or more of a network protocol, an application protocol, an application type, a traffic rate, or tuple information of the one or more monitored network flows.(Barsheshet-Paragraph 69, a set of mirroring instructions are generated using the mirror value and sent to the network nodes. Each such instruction defines the packets (designed at least by a specific source/destination IP addresses, and TCP sequences), the number of bytes, and the bytes that should be mirrored )
Claims 7,14,21,28 are rejected under 35 U.S.C. 103 as being unpatentable over Barsheshet (US PGPUB 2017/0099196) further in view of Terrell (US PGPUB 2012/0278477) further in view of Ho (US PGPUB 2014/0310392) further in view of Macdonald (US Patent 6968554) further in view of Krieski (US PGPUB 2002/0156886) further in view of Rothstein (USPGPUB 2014/0269777).
In regard to Claim 7,14,21,28
Barsheshet-Terrell-Ho disclosed (re. Claim 7,14,21,28) wherein executing the one or more of the one or more rule actions further comprises, providing one or more portions of the filtered network traffic for analysis. (Barsheshet- Paragraph 27-Paragraph 28, each node 112 is configured to receive an incoming packet (either a request from a client device 130 or response for a server 140), analyze the packet's header, and perform the action (redirect the packet to controller 111 or send to destination server 140). )
While Barsheshet-Terrell-Ho substantially disclosed the claimed invention Barsheshet-Terrell-Ho did not disclose (re. Claim 7,14,21,28) providing network traffic to universal payload analysis (UPA) engines.
Macdonald Column 8 Lines 40-55 disclosed unpacking the payloads from the protocol data units as instructed by a protocol interpreter associated with the protocol layer that created the protocol data units, and for creating and maintaining a flow object database that holds flow objects representing the data flows at each protocol layer. The flow objects are arranged in a hierarchical flow tree data structure corresponding to the layers in the protocol stack.
Macdonald disclosed (re. Claim 7,14,21,28) providing network traffic to one or more universal payload analysis (UPA) engines. ( Macdonald-Column 12 Lines 40-45, The SarAddDu( ) API is used by a protocol interpreter (PI) to instruct the SAR decode engine to extract the payload of a protocol data unit (PDU) to a circuit flow object, Column 8 Lines 40-55 , disclosed unpacking the payloads from the protocol data units as instructed by a protocol interpreter associated with the protocol layer that created the protocol data units, and for creating and maintaining a flow object database that holds flow objects representing the data flows at each protocol layer. The flow objects are arranged in a hierarchical flow tree data structure corresponding to the layers in the protocol stack.)
Barsheshet,Terrell and Macdonald are analogous art because they present concepts and practices regarding monitoring and filtering of application data flows. Before the time of the effective filing date of the claimed invention it would have been obvious to combine Macdonald into Barsheshet-Terrell-Ho. The motivation for said combination would have been to manage data flow storage structures that are common for all protocol interfaces, further reducing the complexity of the individual protocol interpreter and eliminating the need for specialized interfaces previously required to pass data from layer to layer. (Macdonald-Column 2 Lines 10-25)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREG C BENGZON whose telephone number is (571)272-3944. The examiner can normally be reached on Monday - Friday 8 AM - 4:30 PM.
THIS ACTION IS MADE FINAL. 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.
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, John Follansbee can be reached on (571) 272-3964. 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.
/GREG C BENGZON/Primary Examiner, Art Unit 2444
Prosecution Insights