DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment/Remarks
This communication is considered fully responsive to the amendment filed on 01/29/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 01/29/2026have been fully considered but they are not persuasive.
Applicant’s Argument 1 :
Applicant argues in substance the combination of HART and SREEVALSAN, specially, HART fail to teach “receiving, by a network device, a set of flow group rules defined by a user” (see Remarks).
Examiner’s Response 1:
The examiner respectfully disagrees. The claims merely recites, “receiving, by a network device, a set of flow group rules defined by a user” without further detail explanation “defined by a user”.
As per Fig. 2, Fig. 7 and paragraphs 0039, 0042 of Hart (which is cited by the examiner, along with other supporting paragraphs here), First Network Server 210 (also Session Border Controller 110 in fig. 1 ) (or 710 in Fig. 7), receives traffic flows from multiple user Equipments A/B/C (fig. 1-2, Fig. 7)). Input Traffic flow, i.e “Input Traffic Flow 205a” in Fig. 2 has multiple classification group rules, ie. entry criteria, tag, service definition, other attributes ([0039]). “ The first network server 210 receives an input traffic flow 205a. In some embodiments, the traffic flows originate at user equipment that are located on the same network as the network servers 210 and 220, or on different networks. A "subscriber" can be an individual user, a group of users, a business, a corporation, or an entity that can access the service provider's network. One of ordinary skill in the art will understand that the techniques described herein are not limited to application on network traffic initiated or provided by a particular configuration of subscribers or users.”: [0039]. Fig. 7 shows that First Network server 710 receives these group rules from User Equipment A/B/C ,. Aforesaid ‘subscriber”/ User of these Equipment A/B/C sends these rules to First Network Server ([0039]]0042], [0114]). “traffic flows originating from UE A 701 or UE B 702 match the entry criteria to belong to a "RECORD_CALL" classification group 711 defined at the first network server 710 (e.g., a session border controller). The classification group 711 is configured to include the "RECORD_CALL" tag 712 in the internodal signaling from the first network server 710 to the second network server 720 (e.g., an application server). Traffic flows that originate from UE A 701 or UE B 702 have the "RECORD_CALL" tag 712 added as the traffic flow progresses to the second network server 720.” Therefore, because the traffic flows originate from the UE, this is viewed as “flow group rules defined by a user”.
Thus claim limitation as written, clearly is taught by cited prior art HART.
Applicant’s Argument 2:
Applicant argues in substance the combination of HART and SREEVALSAN, specially, SREEVALSAN fail to teach “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”
The Office Action cites paragraphs 65-72 of Sreevalsan as teaching these claim features. However, as discussed at the Examiner interview, these cited sections merely describe the notion using machine learning to classify network flows into categories/groups. Sreevalsan does not make any mention of executing operations on the flows once classified, let alone executing the two specific operations recited in our claims that involve transmitting flow information regarding a flow group to a first destination and transmitting samples (i.e., mirrored copies) of packets in the flow group to a second destination different from the first destination. Examples of these first and second destinations include systems/tools that are configured for security analysis, network performance analysis, data management, and/or other network management functions. (See Specification: paragraph 44).” (see Remarks).
Examiner’s Response 2:
The examiner respectfully disagrees. The claims merely recites, “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” without further detail explanation. The claims and only the claims form the metes and bounds of the invention. “Office personnel are to give claims their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). Limitations appearing in the specification but not recited in the claim are not read into the claim. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 1969)” (MPEP p 2100-8, c 2, I 45-48; p 2100-9, c 1, l 1-4). The Examiner has full latitude to interpret each claim in the broadest reasonable sense. The Examiner will reference prior art using terminology familiar to one of ordinary skill in the art. Such an approach is broad in concept and can be either explicit or implicit in meaning.
As Fig. 2 elements 215, 220 and paragraphs 0065-0072 of SREEVALSAN teaches, (which is cited by the examiner, along with other supporting paragraphs here),
PNG
media_image1.png
658
314
media_image1.png
Greyscale
network system/Network node receives network traffic flows and determines traffic flow parameters which are encrypted ([0065]). Flow attributes are derived and extracted from each network flow. The Flow attributes are used to categorize and classify encrypted traffic ([0062[, Fig. 2 element 215, 220).
The flow occurs between two endpoints, specified as sets of attributes values. Each flow have values for computed attributes like, class, kind, directions. These can be derived from endpoint attributes values (==network destination in claim). First flow operation is created by the attributes value with destination endpoint attributes value (==first operation). A new flow is created (==second operation) using a new attribute value in different direction than that first flow ([0065]). Computed attributes use TCP, UDP or other protocols. Thus SREEVALSAN clearly teach this limitation.
Regarding all dependent claims: the applicant alleges that all dependent claims are allowable since they depend from all the independent claims above. The examiner respectfully disagrees in view of the above explanation of independent claims. Thus the rejection is deemed proper.
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 in view of SREEVALSAN et. al. (US 20200274815 A1, hereinafter as “SREEVALSAN”).
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_image2.png
478
787
media_image2.png
Greyscale
PNG
media_image3.png
533
730
media_image3.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 causes 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 sending the sampled packets to the second network destination.
SREEVALSAN discloses:
PNG
media_image4.png
405
858
media_image4.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 causes 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 );
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 sending 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]).
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]).
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 causes 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 sending the sampled packets to the second network destination. (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 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 and further in view of Samuels et. al. (US 20100095021 A1, hereinafter as “Samuels”).
Hart in view of Mishra and SREEVALSAN 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]
Hart in view of SREEVALSAN and Samuels 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 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 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 further in view of Samuels 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 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 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
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.
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