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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/08/2026 has been entered.
Response to Amendment/Remarks
This communication is considered fully responsive to the amendment filed on 07/08/2026.
Claims 1-17, 19-20 are pending and are examined in this office action.
No claim has been amended.
No new claim has been added and claim 18 has been canceled previously.
Response to Arguments
Applicant’s arguments , filed on, 07/08/2026, with respect to claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. See MONSHIZADEH et. al. (US 20190215305 A1, hereinafter as “MONSHIZADEH”).
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(s) 1-3, 8-12 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart (US 20120054363 A1, hereinafter as “Hart”) in view of SREEVALSAN et. al. (US 20200274815 A1, hereinafter as “SREEVALSAN”) and further in view of MONSHIZADEH et. al. (US 20190215305 A1, hereinafter as “MONSHIZADEH”).
Examiner’s note: in what follows, references are drawn to Hart unless otherwise mentioned.
With respect to independent claims:
Regarding claim 1, A method, comprising:
PNG
media_image1.png
326
543
media_image1.png
Greyscale
PNG
media_image2.png
332
456
media_image2.png
Greyscale
receiving, by a network device (e.g. Fig. 2, “First network server 210”), a set of flow group rules defined by a user (e.g. Fig. 2, “one or more classification groups 214”, wherein “the first network server and the second network server receive data associated with the classification groups and service definitions from a policy configuration server (==rules). The entry criteria of the classification groups can include one or more of: rules (flow group rules) for determining membership in the classification groups, parameters for determining membership in the classification groups, policies for determining membership in the classification groups, and patterns for determining membership in the classification groups” [0026]; see fig. 2 where First Network Server 210 receives “”Input Traffic Flow” originate at User Equipment (UE): [0039]; “ Any of the attributes in the traffic flow 205 can be used by the first network server 210 ….., for example, to classify the traffic flow into groups (==a set of flow group rules ) by comparing the attributes against entry criteria of the classification groups (e.g., 214/224)”: [0042]),
the set of flow group rules including, for at least a first flow group (e.g. Fig. 2, “Input Traffic Flow 205a”; Classification Group Tags 235 : “tags (e.g., Classification Group Tag(s) 235) which can be transferred via the traffic flow 205 between different nodes (e.g., first network server 210 and second network server 220) in the network. ”: [0043] ):
one or more first flow group attributes identifying the first flow group (e.g. “Any of the attributes (first flow group attributes) in the traffic flow 205 can be used by the first network server 210 and/or the second network server 220, for example, to classify the traffic flow into groups (first flow group) by comparing the attributes against entry criteria of the classification groups (e.g., 214/224)” [0042]);
one or more characteristics of the first flow group to be tracked in a data structure by the network device (e.g. “comparing attributes of the traffic flow with entry criteria of the classification groups includes identifying (tracking) one or more characteristics (==one or more characteristics) associated with the traffic flow, comparing the identified characteristics to the entry criteria, and determining whether the identified characteristics match the entry criteria” [0025]; “ the traffic flow 205 can include a series of packets, which are units of data formatted for transmission over a communications network. A packet generally includes metadata (==a data structure ) and a payload. The packet metadata includes attributes related to the packet (e.g., arrival information, destination information, origin information, encoding protocols, or structure of information in the packet) ”[0040]); and
a first and second operations to be executed (e.g. “the tag(s) 235 can be applied to the input traffic flow 205a at the first network server 210 ………. a first node (e.g., first network server 210) in the network that receives the input traffic flow 205a identifies, via matching, which tags are applicable to an action or an event in the traffic flow 205“ [0043], which action or event with tagging in the first flow group is associated with a first operation; “The operator can construct any number of tags 235 (==ie. second tag), up to the limits of what each node can support. The definition of the tags 235 is also determined by the operator. The definition of the tag 235 determines the matching criteria used to determine if a traffic flow 205 should be associated with a specific tag 235 (==second tag with second operations ) and in the resultant service logic executed when a node (e.g., second network server 220) recognizes the classification group assignment ”: [0045] ) with respect to the first flow group (e.g. aforesaid first flow group),
the first and second operations (e.g. aforesaid action or event associated with tagging) being associated with one or more criteria that are defined (e.g. “In some SMF implementations, there is not a strict 1:1 relationship between Match and Action. A Match condition may result in multiple Actions, or the implementation can require multiple Match conditions to be satisfied in order for an Action to be taken” [0053], which multiple Match conditions are associated with one or more criteria) using the one or more characteristics that are tracked in the data structure (e.g “In some embodiments, the system 200 matches a traffic flow (e.g., traffic flow 205) by examining the type of media associated with the traffic flow 205. Some examples of this technique include deep packet inspection (DPI) or deep packet manipulation (DPM) technology to identify types of traffic based on matching patterns/rules about the contents of the packets” [0060]);
receiving, by the network device, network data including a first flow of data packets (e.g. “the traffic flow 205 can include a series of packets, which are units of data (network data) formatted for transmission over a communications network. A packet generally includes metadata and a payload. The packet metadata includes attributes related to the packet (e.g., arrival information, destination information, origin information, encoding protocols, or structure of information in the packet). The payload includes the user data to be transmitted” [0040]);
classifying the first flow as belonging to the first flow group based on the one or more first flow group attributes (e.g. “A first network server 210 receives (302) a traffic flow 205. For example, the first network server 210 can receive the traffic flow 205 from user equipment located on another network. Using the classification group matching module 212, the first network server 210 matches (304) the traffic flow 205 (==classifying the first flow) to one or more classification groups 214 (first flow group)” [0048], wherein “The matching includes comparing attributes (==first flow group attributes) of the traffic flow with entry criteria of the classification groups” [0013]);
updating, based on the first flow, first flow information pertaining to the one or more characteristics of the first flow group (e.g. “A further aspect of the techniques described herein is the ability to have classification group membership change (e.g., as subsequent events are received by the system 200)”[0105], which classification group membership change is associated with updating first flow information and the first flow information is related to characteristics of the first flow group);
determining, based on the first flow information, that the one or more criteria associated with the first and second operations to be executed by the network device with respect to the first flow group are satisfied (e.g. “the operator of the network associated with the system 200 defines rules such that the signaling content can be manipulated. In some examples, such functionality is called Signaling Manipulation Functionality (SMF)…… Generally, SMF can be implemented in a variety of different ways, as the operator of the communications network has the ability to specify multiple rules. In some examples, a rule includes two parts: a Match and an Action. A Match can define a pattern to look for in the attributes associated with a traffic flow, and an Action can define some action to take place” [0051]-[0052], which matching is associated with determining that the criteria are satisfied; “The operator can construct any number of tags 235, up to the limits of what each node can support. The definition of the tags 235 is also determined by the operator. The definition of the tag 235 determines the matching criteria used to determine if a traffic flow 205 should be associated with a specific tag 235 and in the resultant service logic executed when a node (e.g., second network server 220) recognizes the classification group assignment ”: [0045]); and
in response to the determining, executing the first and second operations on the first flow (e.g. aforesaid “Action” based on Matching: “where a rule has multiple Action parts, the techniques described herein can invoke classification Actions and also traffic flow attribute manipulation Actions. ”: [0052]-[0056]).
It is noted that while disclosing flow group rules,
Hart is silent about:
wherein the data structure is updated to reflect updated statuses or values for the one or more characteristics as flows belonging to the first flow group are received by the network device;
wherein the first operation causes flow information pertaining to the one or more characteristics to be exported to a first network destination, and wherein the second operation includes mirroring one or more sampled packets to be sent to a second network destination different from the first network destination;
wherein executing the first operation comprises exporting the first flow information to the first network destination, and wherein executing the second operation comprises sampling a subset of packets in the first flow and mirroring the sampled packets to the second network destination; and
concurrent with ongoing processing of the network data using the set of flow group rules, the network device:
receiving a user request to update one or more rules in the set of flow group rules; and in response, updating the one or more rules in the set of flow group rules without halting the ongoing processing of the network data using the set of flow group rules.
SREEVALSAN discloses:
PNG
media_image3.png
325
686
media_image3.png
Greyscale
wherein the data structure (==Fig. 1: [0051]-[0053]) is updated to reflect updated statuses or values for the one or more characteristics as flows belonging to the first flow group are received by the network device (System or server receives multiple data flow from clients : [0089]; System/Server extract data and add flow attributes to the flows : Server (==framework of models 325) divides traffic flows in different categories and classes/group based on different attributes. Aforesaid “attributes thus extracted and derived are intended to form the features that will be used by the system to classify encrypted services.”: [0089]-[0090]; “ system is capable of classifying traffic to a granular classification using the approach described herein a standalone classification system. For example, the system can classify, using attributes which are unaffected by known forms of encryption, not just a service such as Facebook, but also the various sub-classes such as Facebook Web Browsing (==first flow group ), Facebook Video (==second flow group), Facebook Messaging (==3rd flow group) and the like.”: [0057]);
wherein the first operation causes flow information pertaining to the one or more characteristics to be exported to a first network destination, and wherein the second operation one or more sampled packets to be sent to a second network destination different from the first network destination (see fig. 2 element 215, 220: “ A network traffic flow may be described as having the following properties: [0066] The flow occurs between two endpoints, specified as sets of attribute values in the meter's current rule set. A flow is identified by its set of endpoint attribute values. [0067] Each flow may also have values for computed attributes (for example, Class and Kind). These may be directly derived from the endpoint attribute values. [0068] A new flow (==second network destination) is created when a packet is to be counted that does not match the computed attributes of an existing flow (==first network destination). A meter may record the time when this new flow is created, and the age of the flow may be used as input for derived flow attributes. [0069] Computed attribute values may be set when the meter sees the first packet for the flow, and are not changed. [0070] Each flow may have two packet counters and two byte counters, one for each flow direction (Forward and Backward). These are updated as packets for the flow are exchanged. [0071] The computed attributes may have similar meaning for a variety of protocols (for example, TCP, UDP and others). [0072] Flow attributes may be either static or continuously updated counters over the lifetime of the flow.: [0065]-[0072]; NOTE: forward is first network destination ; backward is second network destination which is different than forward; NOTE: crossed/missed limitations will be addressed by another reference below);
wherein executing the first operation comprises exporting the first flow information to the first network destination (==forward flow), and wherein executing the second operation comprises sampling a subset of packets in the first flow and the sampled packets to the second network destination (==backward flow) ( “The extracted and derived flow attributes (Fi) for unclassified encrypted traffic (Ti) is sent to the deep classification engine. The flow attributes may be forwarded to various relevant models or sequence of models within the framework of models. The relevant models may be based on an operator's configuration or goal for the configuration and/or the type of traffic. In an example, the operator may configure the system in order for the first model to be run as a general categorizer model for all encrypted traffic that classifies into VPN and Non-VPN traffic. A secondary model may be applied afterwards to categorize the non-VPN traffic into further sub-categories.”: [0110]; NOTE: crossed/missed limitations will be addressed by another reference below).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the flow group rules of Hart to with above limitation of SREEVALSAN to manage or control for performing multiple connection traffic analysis and management (SREEVALSAN: [0002]).
The combination of Hart and SREEVALSAN does not expressively disclose:
wherein the second operation includes mirroring one or more sampled packets to be sent to a second network destination different from the first network destination;
…… mirroring the sampled packets to the second network destination; and
concurrent with ongoing processing of the network data using the set of flow group rules, the network device:
receiving a user request to update one or more rules in the set of flow group rules; and in response, updating the one or more rules in the set of flow group rules without halting the ongoing processing of the network data using the set of flow group rules.
MONSHIZADEH discloses:
wherein the second operation includes mirroring one or more sampled packets to be sent to a second network destination different from the first network destination ( “network apparatus provides a copy (==mirroring ) of a packet contained in a traffic flow to a cluster node, ”: [abstract]; “ When a first (or any consequent) packet arrives into the switch node (==network apparatus above ), the packet is mirrored into a clustering system and forwarded normally towards its destination. Based on clustering (for the purpose of load balancing or based on some other criteria) the mirrored packet is forwarded for analysis to a corresponding DaaS node (==second network destination different from first network destination )”: [0038]);
…… mirroring the sampled packets to the second network destination (mirroring/coping packet goes to corresponding DaaS Node : [0038]); and
concurrent with ongoing processing of the network data using the set of flow group rules, the network device (==Switch Node or network apparatus ):
receiving a user request to update one or more rules in the set of flow group rules (see fig. 4 where Switch Node/Switch 1 receives updates rules or policy from UE : [0031], ); and
in response, updating the one or more rules in the set of flow group rules without halting the ongoing processing of the network data using the set of flow group rules ( aforesaid “ switch node may be configured to define specific flow forwarding rules. The flow forwarding rules may be stored in the forwarding table of the switch node and/or dynamically defined (==updating the one or more rules ). The flow forwarding rules may be communicated between the SDN node (SDN controller) and the switch node. The SDN orchestrator formulates the forwarding rule information and communicates it to the SDN controller to pass the information to the switch node”: 0031]; “ The SDN controller instructs the switch node to perform the flow actions (flow removal, modification and/or installation), so that suspicious and/or potentially malicious traffic is not forwarded in the network. Thus, the abnormal traffic is stopped before it reaches the network elements. The SDN controller instructs a switch node to remove malicious flows. The SDN controller also includes or interacts with a load balancer or clustering unit to help to reduce the load. FIGS. 3, 6, 7, 12, 13, 14 and 15 illustrate the second embodiment.”: [0042]; NOTE: without halting the ongoing processing of the network data).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the flow group rules of Hart in view of SREEVALSAN to with above limitation of MONSHIZADEH to detecting malicious traffic in the network, and reverting and stopping the malicious traffic from reaching the network elements in SDN. (MONSHIZADEH: [0038]).
Regarding claim 10, A network flow controller (e.g. Fig. 1, “session border controller 110”, wherein “the first network server 210 and the second network server 220 can be any of the following: a session border controller, an application server, a switching node, or another type of device connected to a communications network” [0037]) comprising:
a set of flow group rules defined by a user, the set of flow group rules including, for at least a first flow group:
one or more flow group attributes identifying the first flow group;
one or more characteristics of the first flow group to be tracked in a data structure by the network flow controller, wherein the data structure is updated to reflect updated statuses or values for the one or more characteristics as flows belonging to the first flow group are received by the network flow controller; and
first and second operations to be executed with respect to the first flow group,
the first and second operations being associated with one or more criteria that are defined using the one or more characteristics that are tracked in the data structure,
wherein the first operation causes flow information pertaining to the one or more characteristics to be exported to a first network destination, and wherein the second operation includes mirroring one or more sampled packets to be sent to a second network destination different from the first network destination; and
one or more processors configured to:
receive, via a network interface, network data including a first flow of data packets; and
classify the first flow as belonging to the first flow group based on the one or more flow group attributes;
update, based on the first flow, first flow information for the first flow pertaining to the one or more characteristics of the first flow group;
determine, based on the first flow information, that the one or more criteria associated with the first and second operations to be executed by the network flow controller with respect to the first flow group are satisfied; and
in response to the determining, execute the first and second operations to be executed on the first flow,
wherein executing the first operation comprises exporting the first flow information to the first network destination, and wherein executing the second operation comprises sampling a subset of packets in the first flow and mirroring the sampled packets to the second network destination; and
concurrent with ongoing processing of the network data using the set of flow group rules, the network device:
receiving a user request to update one or more rules in the set of flow group rules; and in response, updating the one or more rules in the set of flow group rules without halting the ongoing processing of the network data using the set of flow group rules.
(Regarding rest of claim 10, the claim is interpreted and rejected for the same reason as set forth in claim 1).
Hart in view of SREEVALSAN and MONSHIZADEH discloses the following (Note: unless mentioned otherwise references made below draw to Hart):
With respect to dependent claims:
Regarding claim 2, The method of claim 1, wherein the set of flow group rules defined by the user further includes, for a second flow group:
one or more second flow group attributes identifying the second flow group (e.g. aforesaid “Any of the attributes in the traffic flow 205 can be used by the first network server 210 and/or the second network server 220, for example, to classify the traffic flow into groups by comparing the attributes against entry criteria of the classification groups”, which groups comprises second flow group with second flow group attributes); and
a third operation to be executed with respect to the second flow group (e.g. aforesaid “the tag(s) 235 can be applied to the input traffic flow 205a at the first network server 210 ………. a first node (e.g., first network server 210) in the network that receives the input traffic flow 205a identifies, via matching, which tags are applicable to an action or an event in the traffic flow 205“, which action on the second flow group is considered as the second operation),
wherein the network data (e.g. aforesaid network data) includes a second flow of data packets, and
wherein the method further comprises (e.g. Note that the remainder of this claim is similar to claim 1 except that instead of first flow, a second flow is considered in this claim):
classifying the second flow as belonging to the second flow group based on the one or more second flow group attributes; and
in response to the classifying, cause the third operation to be executed on the second flow ([0040]-[0045]).
Regarding claim 3, The method of claim 1:
wherein the set of flow group rules further includes a third operation to be executed with respect to the first flow group (e.g. “A Match condition may result in multiple Actions (second operation), or the implementation can require multiple Match conditions to be satisfied in order for an Action to be taken” [0053]), and wherein the method further comprises causing the third operation to be executed on the first flow (e.g. “In the example where a rule has multiple Action parts, the techniques described herein can invoke classification Actions and also traffic flow attribute manipulation Actions.” [0054]).
Regarding claim 8, The method of claim 3 wherein the third operation restricts transmission of data packets associated with the first flow (e.g. “Examples include the following, ………: [0065] a. Common bandwidth/call restrictions (e.g., the Call Admission Control (CAC) (restricts) or leaky-bucket attributes)” [0065]).
Regarding claim 9, The method of claim 1, comprising:
modifying one or more data packets of the first flow to include a marker (e.g. aforesaid tag) corresponding to the first flow group, wherein the first flow information is updated based on the marker ([0040]-[0045]).
Regarding claim 11, The network flow controller of claim 10, wherein the one or more processors are flow group identifier is further configured to modify one or more data packets of the first flow to include a marker that identifies the first flow as belonging to the first flow group and update the first flow information based on the marker (e.g. Note that this claim is similar to claim 9 except that it is a device claim and thus the same reasoning as applied to claim 9 applies here as well).
Regarding claim 12, The network flow controller of claim 10, wherein the set of flow group rules further includes a third operation to be executed with respect to the first flow group, and wherein the one or more processors are further configured to cause the third operation to be executed on the first flow (e.g. Note that this claim is similar to claim 3 except that it is a device claim and thus the same reasoning as applied to claim 3 applies here as well).
Regarding claim 15, The network flow controller of claim 12, wherein the third operation includes one or more actions that meter network traffic associated with the first flow (e.g. aforesaid “Common bandwidth/call restrictions (e.g., the Call Admission Control (CAC) or leaky-bucket attributes)”. Note that there are multiple options in the claim and only this option is considered here).
Claim(s) 4, 5 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of SREEVALSAN as applied to claims 3, 1 and 12 above, and further in view of Kjendal et. al. (US 20140280887 A1, hereinafter as “Kjendal”).
Hart in view of SREEVALSAN discloses the following (Note: unless mentioned otherwise references made below draw to Hart):
Regarding claim 4, the combination of Hart in view of SREEVALSAN teach claim 3 as shown above. The combination does not expressively disclose:
Wherein, the third operation causes a network traffic mirror to modify transmission of data packets corresponding to the first flow.
Kjendal discloses Wherein, the third operation causes a network traffic mirror to modify transmission of data packets corresponding to the first flow.
( “NetFlow provides an established designation of seven elements of a packet that define the characteristics of a flow, including ingress interface, source IP address, destination IP address, IP protocol, source port for Uniform Datagram Protocol (UDP) or Transmission Control Protocol (TCP), destination port for UDP or TCP and IP type of service. That information is useful for determining flow characteristics, but it does not contain all values that may be of interest and it does permit customization of flow characterization information to be collected. IPFIX is an IETF protocol that solves some NetFlow limitations. It was created based on the need for a common, universal standard of export for Internet Protocol flow information from switches, routers, probes, and other devices that are used by network management systems to monitor, manage and facilitate network usage and services. The IPFIX RFC defines how IP flow information is to be formatted and transferred from an exporter to a collector” [0064], which packet of the flow is considered as the first packet, the flow is considered as the first flow, the seven elements that define the characteristics of a flow is considered as the flow information and the collector is considered as the first network destination).
Kjendal also discloses “An aspect of the present invention is the forwarding of one or more frames contained in packets or one or more portions of frames in packets of a flow or at the initiation of a session to the application identification engine of one or more devices of the network infrastructure for the purpose of determining the application associated with the flow/session being established. That is, the mirroring of the one or more packets or portions of packets to a destination other than the original intended destination. The present invention includes a dynamic network traffic mirror function that may be used to mirror traffic through a dedicated port or a selectable portal of a packet forwarding device. The mirroring may be done selectively rather than simply on a regular basis, which would be inefficient. The ability to dynamically launch/create a traffic (flow) mirror to an IDS and/or to the application identification engine improves the capability to monitor the flows of the network anywhere while only needing a very limited set of monitors, IDS sensors or APP ID devices. Frames of flows of traffic from any packet forwarding device can be mirrored without disturbing the normal routing of the messages and maximizing the usage of network bandwidth and the usage of other devices of the network, including IDSs. The dynamic network traffic mirror function can be included or dynamically added to a packet forwarding device of the network system” [0022]. Furthermore, “The dynamic traffic mirror of the present invention extends the ability to "flow mirror" the first N-packets or other varying sets of frames in a new flow and other selections of existing flows or data within the flow……. More broadly, the dynamic mirror function can be used to filter traffic flows and that filtering can be changed automatically on-the-fly” [0026], which flow is considered as the first flow and the packet forwarding device is considered as the base station.).
Therefore, it would have been obvious to one of ordinary skill in the art to combine Kjenda’s exporter to export flow information and the traffic mirror to modify transmission of data packets with Hart’s method of transmission of data packets so that it is “advantageous to have the ability to conduct mirroring activities dynamically, including when to mirror, how much to mirror, which devices to use for mirroring and when to stop mirroring” [0101]).
Hart in view of SREEVALSAN and Kjendal further discloses the following (e.g. Note: unless mentioned otherwise references made below draw to Hart):
Regarding claim 5, The method of claim 1, wherein the second operation further causes data packets in the second flow to be sampled according to a sampling interval (e.g. Kjenda: “Sampling flows, shedding trusted users, limiting the time period of examining all flows from a device or user are some such techniques to use dynamic mirroring to limit load to application identification, IDS and other monitoring engines” [0096], which sampling flows is associated with a sampling interval) and stored in a flow group storage (e.g aforesaid flow group storge).
Regarding claim 13, The network flow controller of claim 12, wherein the third
operation causes a network traffic mirror to modify transmission of data packets corresponding to the first flow (e.g. Note that this claim is similar to claim 4, except that it is an Apparatus claim and the second operation instead of the first operation is used to export. Thus, the same reasoning as applied to claim 4 applies here as well).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of SREEVALSAN as applied to claim 1 above, and further in view of Xu et. al. (US 20200053590 A1, hereinafter as “Xu’).
Hart in view of SREEVALSAN discloses the following (Note: unless mentioned otherwise references made below draw to Hart):
Regarding claim 6, The method of claim 1:
the one or more criteria specify (e.g. aforesaid criteria for first flow), and wherein the first and second operations are (e.g. aforesaid first operation) executed
It is noted that while disclosing first flow, Hart is silent about one or more criteria specify a defined threshold for the first flow, and wherein the first operation is executed in response to determining that the first flow exceeds the defined threshold, which however had been known in the art before the filing date of the claimed invention as shown by Xu, wherein “in the first transmission period, if the transmission rate of the data flow is greater than the second rate threshold of the data flow, the transmit end discards N data packets in the data flow, where N is a difference between the quantity of data packets that can be transmitted according to the transmission rate of the data flow and a quantity of data packets that can be transmitted according to the second rate threshold of the data flow. According to the data transmission method provided in this embodiment of this application, when the transmission rate of the data flow is greater than the second rate threshold of the data flow, the N data packets are discarded, to effectively control the transmission rate of the data flow and improve transmission efficiency” [0165]-[0166], wherein second rate threshold is considered as the defined threshold associated with one or more criteria. Note that before discarding N packets, a determination must be made between the transmission rate of the flow and the defined threshold. Furthermore, note that the determination of the first flow exceeding threshold is preceded by storing the information related to the first set of packets in memory 930 of Apparatus 900 of Fig. 9, wherein the Apparatus 900 is considered as the network device.
Therefore, it would have been obvious to one of ordinary skill in the art to combine Xu’s method of controlling transmission of packets with defined threshold with Hart’s method of transmission of data packets so that “PBR utilization can be improved While the transmission rate of the DRB is ensured” ([0233]).
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of SREEVALSAN as applied to claims 1 and 10 above, and further in view of Chen (US 20190313275 A1, hereinafter “Chen”).
Chen in view of Chen discloses the following (Note: unless mentioned otherwise references made below draw to Chen):
Regarding claim 7, The method of claim 1, comprising:
receiving, during operation of the network device, (e.g aforesaid flow group rules); and
It is noted that while disclosing the operation of the network device, Hart is silent about receiving, ….. a user request to update the set of flow group rules and updating the set of flow group rules based on the user request without discontinuing operation of the network device, which however had been known in the art before the filing date of the claimed invention as shown by Chen, wherein “A quality of service setting system comprising a quality of service controller including an input/output device; at least one user/CPE having a default QOS setting, the at least one user/CPE selectively communicating a request for an altered QOS setting to the quality of service controller; wherein the quality of service controller, upon determining that the request for the altered QOS setting can be granted, is configured to issue an altered flow rule including a tag establishing the altered QOS setting for the at least one user/CPE, wherein subsequent communications from the user/CPE carry the tag” [0134], which quality of service controller is considered as the network device and which request for the altered flow rule is associated with a user request to update the set of flow group rules, wherein the updating is done without discontinuing operation of the quality of service controller.
Therefore, it would have been obvious to one of ordinary skill in the art to combine Chen’s method of operating the network device with user control with Hart’s method of operating the network device so that “customer experience” [0121] is improved.
Regarding claim 14, The network flow controller of claim 10, wherein the one or more processors are further configured to update the first set of set of flow group rules based on a user request without discontinuing operation of the network flow controller (e.g. Note that this claim is similar to claim 7, except that it is an Apparatus claim and thus the same reasoning as applied to claim 7 applies here as well).
Claim(s) 16 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of SREEVALSAN , in view of Samuels et. al. (US 20100095021 A1, hereinafter as “Samuels”) and further in view of MONSHIZADEH et. al. (US 20190215305 A1, hereinafter as “MONSHIZADEH”).
Hart in view of Mishra and SREEVALSAN, MONSHIZADEH discloses the following (Note: unless mentioned otherwise references made below draw to Hart):
Regarding claim 16, A network interface system, comprising:
a network traffic manager (e.g. “first network server 210 may have applied a traffic policer (network traffic manager) to each of these classification groups” [0094]) configured to:
receive network data including a first flow of data packets (e.g. “the traffic flow 205 can include a series of packets, which are units of data (network data) formatted for transmission over a communications network. A packet generally includes metadata and a payload. The packet metadata includes attributes related to the packet (e.g., arrival information, destination information, origin information, encoding protocols, or structure of information in the packet). The payload includes the user data to be transmitted” [0040]); and
forward the network data to corresponding network destinations (e.g. Fig. 2, output traffic flow 205c); and
a network flow controller communicatively coupled to the network traffic manager and configured to:
receive the network data;
receive a set of flow group rules defined by a user, the set of flow group rules including, for at least a first flow group:
one or more flow group attributes identifying the first flow group;
one or more characteristics of the first flow group to be tracked in a data structure by the network flow controller, wherein the data structure is updated to reflect updated statuses or values for the one or more characteristics as flows belonging to the first flow group are received by the network flow controller;
and an operation first and second operations to be executed with respect to the first flow group, the first and second operations operation being associated with one or more criteria that are defined using the one or more characteristics that are tracked in
data structure, wherein the first operation causes flow information pertaining to the one or more characteristics to be exported to a first network destination, and wherein the second operation causes one or more sampled packets to be sent to a second network destination different from the first network destination; classify the first flow as belonging to the first flow group based on the one or more flow group attributes; update, based on the first flow, first flow information for the first flow pertaining to the one or more characteristics of the first flow group;
determine, based on the first flow information, that the one or more criteria associated with the first and second operations operation to be executed by the network flow controller with respect to the first flow group are satisfied; and in response to the determining, cause execute the first and second operations operation to be executed on the first flow, wherein executing the first operation comprises exporting the first flow information to the first network destination, and wherein executing the second operation comprises sampling a subset of packets in the first flow and sending the sampled packets to the second network destination.
(e.g. Note that the remainder of this claim is similar to claim 1 except that it is for a network flow controller whereas claim 1 is for a network device, which network device is the network flow controller).
It is noted that while disclosing network flow controller, Hart in view of SREEVALSAN is silent about a network flow controller communicatively coupled to the network traffic manager, which however had been known in the art before the filing date of the claimed invention as shown by Samuels wherein “Data transfer manager 430 may be any type of device, software, application or a unit for controlling or managing the transfer or transmission of data from the sender to the receiver. Data transfer manager 430 may be a communication device capable of controlling the amount of transmitted information and the timing of the amount of the information transmitted. Data transfer manager 420 may be any device, unit, software or a component of the sender transmitting information using the values and statistics provided by any network optimizer 420 model, such as the data transfer model 440. ……. Data transfer manager 430 may comprise any features or functionality of a network optimizer 420, flow controller 220 or a data transfer model 440. In some embodiments, data transfer manager 430 is combined or fused into a single device, unit, function, software or a component together with the network optimizer 420, flow controller 220 and data transfer model 440. In some embodiments, data transfer manager 430 is a part of the network optimizer 420. In some embodiments, data transfer manager 430 is not comprised by the network optimizer 420, but communicates with it. In some embodiments, data transfer manager 430 is a part of the sender, while in other embodiments data transfer manager 430 is a component separate from the sender” [0208], which data transfer manager is considered as the traffic manager and the network optimizer is considered as the network flow controller which is communicatively coupled to the traffic manager.
Therefore, it would have been obvious to one of ordinary skill in the art to combine Samuels’s traffic manager with Hart in view of SREEVALSAN ‘s flow controller so that “data transmission throughput between the source node (sender) 102 and the destination node (receiver) 106” is increased “by taking advantage of the larger buffer in the flow control modules 220, 220' between the devices” [0134]
The combination of Hart, Samuels and SREEVALSAN does not expressively disclose:
wherein the second operation includes mirroring one or more sampled packets to be sent to a second network destination different from the first network destination;
…… mirroring the sampled packets to the second network destination; and
concurrent with ongoing processing of the network data using the set of flow group rules, the network device:
receiving a user request to update one or more rules in the set of flow group rules; and in response, updating the one or more rules in the set of flow group rules without halting the ongoing processing of the network data using the set of flow group rules.
MONSHIZADEH discloses:
wherein the second operation includes mirroring one or more sampled packets to be sent to a second network destination different from the first network destination ( “network apparatus provides a copy (==mirroring ) of a packet contained in a traffic flow to a cluster node, ”: [abstract]; “ When a first (or any consequent) packet arrives into the switch node (==network apparatus above ), the packet is mirrored into a clustering system and forwarded normally towards its destination. Based on clustering (for the purpose of load balancing or based on some other criteria) the mirrored packet is forwarded for analysis to a corresponding DaaS node (==second network destination different from first network destination )”: [0038]);
…… mirroring the sampled packets to the second network destination (mirroring/coping packet goes to corresponding DaaS Node : [0038]); and
concurrent with ongoing processing of the network data using the set of flow group rules, the network device (==Switch Node or network apparatus ):
receiving a user request to update one or more rules in the set of flow group rules (see fig. 4 where Switch Node/Switch 1 receives updates rules or policy from UE : [0031], ); and
in response, updating the one or more rules in the set of flow group rules without halting the ongoing processing of the network data using the set of flow group rules ( aforesaid “ switch node may be configured to define specific flow forwarding rules. The flow forwarding rules may be stored in the forwarding table of the switch node and/or dynamically defined (==updating the one or more rules ). The flow forwarding rules may be communicated between the SDN node (SDN controller) and the switch node. The SDN orchestrator formulates the forwarding rule information and communicates it to the SDN controller to pass the information to the switch node”: 0031]; “ The SDN controller instructs the switch node to perform the flow actions (flow removal, modification and/or installation), so that suspicious and/or potentially malicious traffic is not forwarded in the network. Thus, the abnormal traffic is stopped before it reaches the network elements. The SDN controller instructs a switch node to remove malicious flows. The SDN controller also includes or interacts with a load balancer or clustering unit to help to reduce the load. FIGS. 3, 6, 7, 12, 13, 14 and 15 illustrate the second embodiment.”: [0042]; NOTE: without halting the ongoing processing of the network data).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the flow group rules of Hart in view of Samuels , SREEVALSAN to with above limitation of MONSHIZADEH to detecting malicious traffic in the network, and reverting and stopping the malicious traffic from reaching the network elements in SDN. (MONSHIZADEH: [0038]).
Hart in view of SREEVALSAN and Samuels, MONSHIZADEH further discloses the following (e.g. Note: unless mentioned otherwise references made below draw to Hart):
Regarding claim 19, The network interface system of claim 16, wherein the network flow controller is further configured to:
modify one or more data packets associated with the first flow to include a marker that identifies the one or more data packets as belonging to the first flow group, and wherein the flow information is updated based on the marker (e.g. aforesaid tag).
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of SREEVALSAN and Samuels, MONSHIZADEH as applied to claim 16 above, and further in view of Kjendal et. al. (US 20140280887 A1, hereinafter as “Kjendal”).
Hart in view of SREEVALSAN and Samuels, MONSHIZADEH and further disclose the following (e.g. Note: unless mentioned otherwise references made below draw to Hart):
Regarding claim 17, the combination of Hart in view of SREEVALSAN and Samuels, MONSHIZADEH teaches claim 16.
The combination does not expressively disclose:
wherein executing the second operation further comprises sending instructions to the network traffic manager to modify port mirroring of a subset of the network data corresponding to the first flow.
Kjendal discloses wherein executing the second operation further comprises sending instructions to the network traffic manager to modify port mirroring of a subset of the network data corresponding to the first flow ( “Packet forwarding devices of the network infrastructure transmit and receive packets through their ports. A "port" includes a physical component that is a structure to establish a connection between network system devices, including packet forwarding devices, servers and attached functions” [0023], which packet forwarding device is considered as the traffic manager and “In the classic sense a "port mirror" is the copying of all the data received (and/or transmitted) being copied to another port on the same switching device” [0024]. Moreover, “The dynamic traffic mirror of the present invention extends the ability to "flow mirror" the first N-packets or other varying sets of frames in a new flow and other selections of existing flows or data within the flow…… More broadly, the dynamic mirror function can be used to filter traffic flows and that filtering can be changed automatically on-the-fly” [0026]. Furthermore, “The set-up, teardown and filtering employed in the mirroring activity can be adjusted based on network policies, the detection of particular triggers by the device performing the mirroring or another network infrastructure device” [0072], which triggering is performed by the network flow controller. Furthermore, “Examples for criteria which may generate a mirroring activity include, but are not limited to, frames of packets, the content of particular fields in a frame, flow counts, the end of a flow, a regularly timed mirroring initiation or any other conditions of interest to the network administrator can be used as conditions for establishing mirroring activities on a device of the network. In addition, events or criteria may be established for stopping the mirroring function. For example, a mirroring activity may be stopped based on the data value in a packet field, a network, regional or device specific event, a simple count of packets or other flow metric, a time out, the end of flow or based on a change in a prioritization condition (i.e., a condition has occurred wherein mirroring must be performed on a different flow that has been designated as being of higher priority for mirroring, particularly when the device carrying out the mirroring has limited capacity in that regard” [0027]. Note that aforesaid flow and network policies are associated with the flow controller and thus the flow controller must trigger or send instructions to the traffic manager for port mirroring).
Therefore, it would have been obvious to one of ordinary skill in the art to combine Kjenda’s flow controller sending instructions to the network traffic manager to modify the port mirroring with Hart’s flow controller so that it is “advantageous to have the ability to conduct mirroring activities dynamically, including when to mirror, how much to mirror, which devices to use for mirroring and when to stop mirroring” [0101].
Hart in view of SREEVALSAN Samuels and Kjenda further discloses the following (e.g. Note: unless mentioned otherwise references made below draw to Hart):
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hart in view of SREEVALSAN and Samuels, MONSHIZADEH as applied to claim 16 above, and further in view of Chen (US 20190313275 A1, hereinafter as “Chen”).
Hart in view of SREEVALSAN and Samuels, MONSHIZADEH further discloses the following (e.g. Note: unless mentioned otherwise references made below draw to Hart):
Regarding claim 20, The network interface system of claim 16, wherein the network flow controller is further configured to:
update the set of flow group rules based on a user request
It is noted that while disclosing the operation of the network device, Hart is silent about update the set of rules based on the user request without discontinuing operation of the network flow controller, which however had been known in the art before the filing date of the claimed invention as shown by Chen, wherein “A quality of service setting system comprising a quality of service controller including an input/output device; at least one user/CPE having a default QOS setting, the at least one user/CPE selectively communicating a request for an altered QOS setting to the quality of service controller; wherein the quality of service controller, upon determining that the request for the altered QOS setting can be granted, is configured to issue an altered flow rule including a tag establishing the altered QOS setting for the at least one user/CPE, wherein subsequent communications from the user/CPE carry the tag” [0134], which quality of service controller is considered as the network flow controller and which altered flow rule from the user is associated with update the set of rules based on the user request without discontinuing the operation of the network flow controller.
Therefore, it would have been obvious to one of ordinary skill in the art to combine Chen’s method of operating the network flow controller with user control with Hart’s method of operating the network flow controller so that “customer experience” [0121] is improved.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to M MOSTAZIR RAHMAN whose telephone number is (571)272-4785. The examiner can normally be reached 8:30am-5:00pm PST.
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, Derrick Ferris can be reached at 571-272-3123. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M Mostazir Rahman/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Prosecution Insights