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 .
Status of the Claims
The office action is in response to the claim amendments and remarks filed on December 12, 2025 for the application filed October 21, 2022. Claims 1-20 are currently pending.
Drawings
The drawings are objected to because step 214 in Figure 2 is performing the same action to “set flow record bit in the packet header of the packet” in different paths. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities: Paragraphs [0011] and [0012] describe step 214 which performs the same action to “set flow record bit in the packet header of the packet” in different paths”. It is not clear as to what the flow record bit is set to, based on the path.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 in line 6 recites “a first local flow record table (LFRT)”. However, claim 1 in lines 7, 10, 11, 13, 14, 16, recites “the LFRT”. It is unclear whether “the LFRT” is “a first local flow record table (LFRT)”. There is insufficient antecedent basis for these limitations in the claim. Further, line 8 recites “a LFRT”, which renders the claim limitation indefinite. Claims 13 and 20 also have similar issues. As a result, the metes and bounds of the claims are unclear.
Dependent claims 2-12, and 14-19 are rejected based on their dependencies on the independent claims 1 and 13.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-7, 13, 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Kapoor et al. (US7193968B1) in view of Bechtolsheim et al. (US6515963B1).
Regarding claim 1, Kapoor teaches a method performed by a first network device for generating a distributed flow record, the method comprising: receiving a packet along a flow path of the packet; determining whether information related to a packet flow associated with the packet should be recorded in a first local flow record table (LFRT) of the first network device; determining whether a flow entry for the packet flow already exists in the LFRT when the information related to the packet flow associated with the packet should be recorded in a LFRT of the first network device (Abstract: If the determination is to process the group of information, the group of information is processed for network data collection. The group of information is forwarded according to its destination address. The group of information can be an IP packet and the sample mode can be, for example, one of linear, exponential, natural log, burst and traffic attribute. To process the group of information, a determination is made whether the group of information is part of one or more recorded traffic flows. If not, a new entry in a table is created. If so, a field in an existing entry in the table is incremented. In addition, a traffic information packet is created and transmitted to a network traffic data collection application. The traffic information packet can consist of a header and one or more flow records.);
wherein the flow path comprises a plurality of network devices comprising the first network device (Col 2, Lines 62-67; Col 3, Line 1: FIG. 1 illustrates a network environment in which embodiments of the present invention may be practiced. Network 100 includes a number of nodes, network nodes 195 (1)–(N). One or more of network nodes 195(1)–(N) can be a router such as router 400, described in FIG. 4, or any other type of communications equipment such as a switch, bridge, or a hub.)
updating the flow entry for the packet flow in the LFRT with the information from the packet when the flow entry for the packet flow already exists in the LFRT (Col 6, Lines 6-11: Route processor 420 determines the network topology, calculates the best path across the network, creates and maintains a routing table, distributes and updates forwarding tables on line cards 430 and maintains copies of the tables of each line card for card initialization. Col 6, lines 32-37: When an IP packet is received by a line card 430, line card 430 performs a lookup in its forwarding table of the destination address located in the IP packet. If the destination address is in the forwarding table, the IP packet is automatically forwarded or switched across switch fabric 410 to the destination line card.);
creating the flow entry for the packet flow in the LFRT and updating the flow entry for the packet flow with the information from the packet when there is available memory space to create the flow entry for the packet flow in the LFRT; wherein the distributed flow record comprises first flow entries of the first LFRT and second flow entries of at least one other LFRT of the other networking devices in the plurality of network devices (Col 6, lines 57-65: Router 400 can be configured and enabled to collect network data. To collect network data, the processing engine(s) in route processor 420 or line card 430 must process each IP packet travelling through router 400 to collect network data. Routers and switches can be enabled to collect network traffic data, for example, by monitoring and tracking for various fields within IP packets such as source address, destination address, protocol, type of service (ToS), and the like. Col 7, lines 8-24: In addition to monitoring control information fields in an IP packet, network data such as the number of packets in the flow, the total number of bytes in a flow, first and last time stamps of packets that were switched as part of a flow, etc. can be collected. Traffic records are often kept in a table coupled to the processing engine(s). During the processing of packets and monitoring the flows, in one implementation the processing engine(s) can determine if the packet is part of one or more recorded traffic flows. The processing engine(s) create a new entry in the table if the packet is not part of one of the recorded flows or already recorded. The processing engine(s) increment information in a field in an existing entry in the table if the packet is part of an already recorded traffic flow or already recorded information. The processing engine(s) can also time stamp packets in the flow and perform other traffic monitoring activities. Col 8, lines 53-66; Col 9, lines 1-3: Network traffic data is collected while the routers and switches perform their switching functions. The network node's processing engine(s) perform table management functions such as determining if a packet is part of an existing traffic flow or if the packet should generate a new table entry, dynamically updating the per-flow data in the table, determining the aging, idleness, and storage limits of flows, time stamping the first and last packets in a flow, and creating, updating and transmitting traffic information packets. Forwarding tables are included in network nodes to reduce processing engine(s) processing overhead. However, when network traffic monitoring functions are enabled, the network node's processing engine(s) must process all IP packets, causing reduced flow of packets through the network node. Methods to improve throughput have been limited to reducing the number of control fields monitored or simply turning off network traffic monitoring by the network node.)
and forwarding the packet (Col 6, lines 19-43: Line cards 430 perform the packet-forwarding functions. A copy of the forwarding tables computed by route processor 420 is distributed to each of line cards 430. Each line card 430 performs an independent lookup of a destination address for each IP packet received on a local copy of the forwarding table. If the destination address is found in the forwarding table, the IP packet is automatically switched across switch fabric 410 to the destination line card. Line cards 430 connect router 400 to other devices on the network via electrical or optical media. Line cards 430 typically transmit IP packets over DPT, PPP, Frame Relay, or ATM interfaces. The specific features and functions of line cards 430 are typically interface specific. When an IP packet is received by a line card 430, line card 430 performs a lookup in its forwarding table of the destination address located in the IP packet. If the destination address is in the forwarding table, the IP packet is automatically forwarded or switched across switch fabric 410 to the destination line card. If the destination address is not in the forwarding table, route processor 420 must calculate the best path for the IP packet across the network, update the routing table and distribute and update the forwarding tables on line cards 430. The use of forwarding tables on line cards 430 saves significant processing overhead for the processing engine(s) on route processor 420.);
Kapoor does not explicitly teach determining whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT; setting a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record.
However, Bechtolsheim teaches determining whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT (Abstract: The present invention provides a per-flow dynamic buffer management scheme for a data communications device. With per-flow dynamic buffer limiting, the header information for each packet is mapped into an entry in a flow table, with a separate flow table provided for each output queue. Each flow table entry maintains a buffer count for the packets currently in the queue for each flow. On each packet enqueuing action, a dynamic buffer limit is computed for the flow and compared against the buffer count already used by the flow to make a mark, drop, or enqueue decision. A packet in a flow is dropped or marked if the buffer count is above the limit. Otherwise, the packet is enqueued and the buffer count incremented by the amount used by the newly-enqueued packet. The scheme operates independently of packet data rate and flow behavior, providing means for rapidly discriminating well-behaved flows from non-well-behaved flows in order to manage buffer allocation accordingly. Col 9, lines 59-67: Enqueue/Tag Decision: Once the DBL appropriate to the received packet is determined, the current (pre-enqueuing) stored buffer count 334 for the flow is compared to DBL, 320 in FIG. 3. This count is retrieved from the indexed flow table entry, described above. If the buffer count is greater than DBL, the packet is tagged for further processing 340, detailed below. Otherwise, whenever the buffer count is less than or equal to DBL, the packet is enqueued 330. Col 10, lines 10-18: Enqueuing: When enqueuing, referring to FIG. 7, the buffer count stored in the indexed flow table entry is incremented by the packet's buffer requirement, which is simply the packet size 240 (FIG. 2), read from header 710 and converted into buffer cell units 720 (simply referred to as “buffers”) as discussed above. If the buffer count is zero initially 723, the router state parameter flowsInQueue is incremented by one, 726, denoting a new flow.)
setting a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record (Col 11, lines 1-10: In an alternate embodiment, referring to FIG. 6, tagged packets are not dropped immediately, but tested, 610, first. If the packet qualifies for marking and enqueuing, a mark bit is set 620 in the packet header (such as in the TOS field 210 or options field 230, FIG. 2) and the packet is enqueued normally as shown in FIG. 7 and described above. The mark bit tells subsequent recipients of the packet, be they other routers or switches in the network or the packet's ultimate destination, that the packet passed through congestion. Col 10, lines 10-18: When enqueuing, referring to FIG. 7, the buffer count stored in the indexed flow table entry is incremented by the packet's buffer requirement, which is simply the packet size 240 (FIG. 2), read from header 710 and converted into buffer cell units 720 (simply referred to as “buffers”) as discussed above. If the buffer count is zero initially 723, the router state parameter flowsInQueue is incremented by one, 726, denoting a new flow.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide determining whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT and setting a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record, as taught by Bechtolsheim in the system of Kapoor, in order to provide a flexible, low-overhead, extremely fast dynamic buffer limiting method to fairly buffer and enqueue flows, and enable efficient buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 3, the combination of Kapoor and Bechtolsheim teaches the method of claim 1 (see rejection for claim 1);
Kapoor does not explicitly teach wherein determining whether to record information related to the packet flow associated with the packet in the LFRT of the first network device is based on whether the flow record bit in the packet header of the packet is marked.
However, Bechtolsheim teaches wherein determining whether to record information related to the packet flow associated with the packet in the LFRT of the first network device is based on whether the flow record bit in the packet header of the packet is marked (Col 11, lines 1-10: In an alternate embodiment, referring to FIG. 6, tagged packets are not dropped immediately, but tested, 610, first. If the packet qualifies for marking and enqueuing, a mark bit is set 620 in the packet header (such as in the TOS field 210 or options field 230, FIG. 2) and the packet is enqueued normally as shown in FIG. 7 and described above. The mark bit tells subsequent recipients of the packet, be they other routers or switches in the network or the packet's ultimate destination, that the packet passed through congestion.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein determining whether to record information related to the packet flow associated with the packet in the LFRT of the first network device is based on whether the flow record bit in the packet header of the packet is marked, as taught by Bechtolsheim in the system of Kapoor, in order to efficiently buffer and enqueue flows, and determine buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 4, the combination of Kapoor and Bechtolsheim teaches the method of claim 3 (see rejection for claim 3);
Kapoor does not explicitly teach wherein the flow record bit in the packet header of the first network device is initially unmarked when the packet is received from a consumer side of a network.
However, Bechtolsheim teaches wherein the flow record bit in the packet header of the first network device is initially unmarked when the packet is received from a consumer side of a network (Col 3, lines 59-66: With per-flow dynamic buffer limiting, the header information for each packet is mapped into an entry in a flow table, with a separate flow table provided for each output queue. Each flow table entry maintains a count of buffers currently in the queue for each flow. On each packet enqueuing action, a dynamic buffer limit is computed for the flow and compared against the number of buffers already used by the flow to make a mark, drop, or enqueue decision. Col 5, lines 23-33: FIG. 3 illustrates the high-level process involved in queue-based management through dynamic buffer limiting, specifically focused on the computations and transformations of the enqueuing operation. Upon receipt of a packet in a given flow, 300, the packet header is parsed 302 to determine the packet size, source address, destination address, and type of service (TOS). Additionally, the UDP source and destination port (for an IP packet) or the MAC source and destination and protocol type (for Ethernet packets) may be extracted as required to fully identify the necessary TOS. Col 11, lines 1-10: In an alternate embodiment, referring to FIG. 6, tagged packets are not dropped immediately, but tested, 610, first. If the packet qualifies for marking and enqueuing, a mark bit is set 620 in the packet header (such as in the TOS field 210 or options field 230, FIG. 2) and the packet is enqueued normally as shown in FIG. 7 and described above. The mark bit tells subsequent recipients of the packet, be they other routers or switches in the network or the packet's ultimate destination, that the packet passed through congestion. Col 12, lines 19-23: Once the packet is either enqueued or marked, the system loops back to wait for and process the next packet received, 9999. In a substantially parallel process, enqueued packets are transmitted out into the network via output ports 70 (FIG. 1), as described 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 provide wherein the flow record bit in the packet header of the first network device is initially unmarked when the packet is received from a consumer side of a network, as taught by Bechtolsheim in the system of Kapoor, in order to efficiently buffer and enqueue flows, and determine buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 5, the combination of Kapoor and Bechtolsheim teaches the method of claim 4 (see rejection for claim 4);
Kapoor does not explicitly teach wherein setting the flow record bit in the packet header of the packet comprises: marking the flow record bit when the information from the packet associated with the packet flow is recorded in the LFRT of the first network device, and maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is not recorded in the LFRT of the first network device.
However, Bechtolsheim teaches wherein setting the flow record bit in the packet header of the packet comprises: marking the flow record bit when the information from the packet associated with the packet flow is recorded in the LFRT of the first network device, and maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is not recorded in the LFRT of the first network device (Col 5, lines 23-33: FIG. 3 illustrates the high-level process involved in queue-based management through dynamic buffer limiting, specifically focused on the computations and transformations of the enqueuing operation. Upon receipt of a packet in a given flow, 300, the packet header is parsed 302 to determine the packet size, source address, destination address, and type of service (TOS). Additionally, the UDP source and destination port (for an IP packet) or the MAC source and destination and protocol type (for Ethernet packets) may be extracted as required to fully identify the necessary TOS. Col 9, lines 59-67: Enqueue/Tag Decision: Once the DBL appropriate to the received packet is determined, the current (pre-enqueuing) stored buffer count 334 for the flow is compared to DBL, 320 in FIG. 3. This count is retrieved from the indexed flow table entry, described above. If the buffer count is greater than DBL, the packet is tagged for further processing 340, detailed below. Otherwise, whenever the buffer count is less than or equal to DBL, the packet is enqueued 330. Col 10, lines 10-18: Enqueuing: When enqueuing, referring to FIG. 7, the buffer count stored in the indexed flow table entry is incremented by the packet's buffer requirement, which is simply the packet size 240 (FIG. 2), read from header 710 and converted into buffer cell units 720 (simply referred to as “buffers”) as discussed above. If the buffer count is zero initially 723, the router state parameter flowsInQueue is incremented by one, 726, denoting a new flow. Col 11, lines 1-10: In an alternate embodiment, referring to FIG. 6, tagged packets are not dropped immediately, but tested, 610, first. If the packet qualifies for marking and enqueuing, a mark bit is set 620 in the packet header (such as in the TOS field 210 or options field 230, FIG. 2) and the packet is enqueued normally as shown in FIG. 7 and described above. The mark bit tells subsequent recipients of the packet, be they other routers or switches in the network or the packet's ultimate destination, that the packet passed through congestion. Col 12, lines 19-23: Once the packet is either enqueued or marked, the system loops back to wait for and process the next packet received, 9999. In a substantially parallel process, enqueued packets are transmitted out into the network via output ports 70 (FIG. 1), as described 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 provide wherein setting the flow record bit in the packet header of the packet comprises: marking the flow record bit when the information from the packet associated with the packet flow is recorded in the LFRT of the first network device, and maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is not recorded in the LFRT of the first network device, as taught by Bechtolsheim in the system of Kapoor, in order to provide a flexible, low-overhead, extremely fast dynamic buffer limiting method to fairly buffer and enqueue flows, and enable efficient buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 6, the combination of Kapoor and Bechtolsheim teaches the method of claim 3 (see rejection for claim 3);
Kapoor does not explicitly teach wherein the method determines that the information related to the packet flow associated with the packet should be recorded in the LFRT of the first network device when the flow record bit is unmarked.
However, Bechtolsheim teaches wherein the method determines that the information related to the packet flow associated with the packet should be recorded in the LFRT of the first network device when the flow record bit is unmarked (Col 9, lines 59-67: Enqueue/Tag Decision: Once the DBL appropriate to the received packet is determined, the current (pre-enqueuing) stored buffer count 334 for the flow is compared to DBL, 320 in FIG. 3. This count is retrieved from the indexed flow table entry, described above. If the buffer count is greater than DBL, the packet is tagged for further processing 340, detailed below. Otherwise, whenever the buffer count is less than or equal to DBL, the packet is enqueued 330. Col 10, lines 10-18: Enqueuing: When enqueuing, referring to FIG. 7, the buffer count stored in the indexed flow table entry is incremented by the packet's buffer requirement, which is simply the packet size 240 (FIG. 2), read from header 710 and converted into buffer cell units 720 (simply referred to as “buffers”) as discussed above. If the buffer count is zero initially 723, the router state parameter flowsInQueue is incremented by one, 726, denoting a new flow. Col 11, lines 1-10: In an alternate embodiment, referring to FIG. 6, tagged packets are not dropped immediately, but tested, 610, first. If the packet qualifies for marking and enqueuing, a mark bit is set 620 in the packet header (such as in the TOS field 210 or options field 230, FIG. 2) and the packet is enqueued normally as shown in FIG. 7 and described above. The mark bit tells subsequent recipients of the packet, be they other routers or switches in the network or the packet's ultimate destination, that the packet passed through congestion. Col 12, lines 19-23: Once the packet is either enqueued or marked, the system loops back to wait for and process the next packet received, 9999. In a substantially parallel process, enqueued packets are transmitted out into the network via output ports 70 (FIG. 1), as described 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 provide wherein the method determines that the information related to the packet flow associated with the packet should be recorded in the LFRT of the first network device when the flow record bit is unmarked, as taught by Bechtolsheim in the system of Kapoor, , in order to efficiently buffer and enqueue flows, and determine buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 7, the combination of Kapoor and Bechtolsheim teaches the method of claim 6 (see rejection for claim 6);
Kapoor does not explicitly teach wherein setting the flow record bit in the packet header of the packet comprises: maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is not recorded in the LFRT of the first network device, and setting the flow record bit as marked when the information from the packet associated with the packet flow is recorded in the LFRT of the first network device.
However, Bechtolsheim teaches wherein setting the flow record bit in the packet header of the packet comprises: maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is not recorded in the first LFRT of the first network device, and setting the flow record bit as marked when the information from the packet associated with the packet flow is recorded in the LFRT of the first network device (Col 5, lines 23-33: FIG. 3 illustrates the high-level process involved in queue-based management through dynamic buffer limiting, specifically focused on the computations and transformations of the enqueuing operation. Upon receipt of a packet in a given flow, 300, the packet header is parsed 302 to determine the packet size, source address, destination address, and type of service (TOS). Additionally, the UDP source and destination port (for an IP packet) or the MAC source and destination and protocol type (for Ethernet packets) may be extracted as required to fully identify the necessary TOS. Col 9, lines 59-67: Enqueue/Tag Decision: Once the DBL appropriate to the received packet is determined, the current (pre-enqueuing) stored buffer count 334 for the flow is compared to DBL, 320 in FIG. 3. This count is retrieved from the indexed flow table entry, described above. If the buffer count is greater than DBL, the packet is tagged for further processing 340, detailed below. Otherwise, whenever the buffer count is less than or equal to DBL, the packet is enqueued 330. Col 10, lines 10-18: Enqueuing: When enqueuing, referring to FIG. 7, the buffer count stored in the indexed flow table entry is incremented by the packet's buffer requirement, which is simply the packet size 240 (FIG. 2), read from header 710 and converted into buffer cell units 720 (simply referred to as “buffers”) as discussed above. If the buffer count is zero initially 723, the router state parameter flowsInQueue is incremented by one, 726, denoting a new flow. Col 11, lines 1-10: In an alternate embodiment, referring to FIG. 6, tagged packets are not dropped immediately, but tested, 610, first. If the packet qualifies for marking and enqueuing, a mark bit is set 620 in the packet header (such as in the TOS field 210 or options field 230, FIG. 2) and the packet is enqueued normally as shown in FIG. 7 and described above. The mark bit tells subsequent recipients of the packet, be they other routers or switches in the network or the packet's ultimate destination, that the packet passed through congestion. Col 12, lines 19-23: Once the packet is either enqueued or marked, the system loops back to wait for and process the next packet received, 9999. In a substantially parallel process, enqueued packets are transmitted out into the network via output ports 70 (FIG. 1), as described 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 provide wherein setting the flow record bit in the packet header of the packet comprises: maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is not recorded in the LFRT of the first network device, and setting the flow record bit as marked when the information from the packet associated with the packet flow is recorded in the LFRT of the first network device, as taught by Bechtolsheim in the system of Kapoor, in order to provide a flexible, low-overhead, extremely fast dynamic buffer limiting method to fairly buffer and enqueue flows, and enable efficient buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 13, Kapoor teaches a network node comprising: a memory storing instructions; a processor coupled to the memory, the processor configured to execute the instructions to cause the network node to (Col 6, lines 6-18: Route processor 420 determines the network topology, calculates the best path across the network, creates and maintains a routing table, distributes and updates forwarding tables on line cards 430 and maintains copies of the tables of each line card for card initialization. Route processor 420 is responsible for the system control and administrative functions and also handles general maintenance functions such as diagnostics, console support, and line card monitoring. Route processor 420 provides the routing intelligence for router 400. Route processor 420 typically includes Ethernet connections for network management access, one or more processing engines (431 and 432), and memory 433. Also see Col 12, lines 11-17)
receive a packet along a flow path of the packet wherein the flow path comprises a plurality of network devices comprising the network node; determine whether information related to a packet flow associated with the packet should be recorded in a first local flow record table (LFRT) of the network node; determine whether a flow entry for the packet flow already exists in the LFRT when the information related to the packet flow associated with the packet should be recorded in a LFRT of the network node; update the flow entry for the packet flow in the LFRT with the information from the packet when the flow entry for the packet flow already exists in the LFRT; create the flow entry for the packet flow in the LFRT and updating the flow entry for the packet flow with the information from the packet when there is available memory space to create the flow entry for the packet flow in the LFRT; wherein the distributed flow record comprises first flow entries of the first LFRT and second flow entries of at least one other LFRT of the other networking devices in the plurality of network devices; and forward the packet (see rejection for claim 1);
Kapoor does not explicitly teach to determine whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT; set a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of a distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record.
However, Bechtolsheim teaches to determine whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT; set a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of a distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record (see rejection for claim 1);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to determine whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT, and set a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of a distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record, as taught by Bechtolsheim in the system of Kapoor, in order to provide a flexible, low-overhead, extremely fast dynamic buffer limiting method to fairly buffer and enqueue flows, and enable efficient buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 15, the combination of Kapoor and Bechtolsheim teaches the network node of claim 13 (see rejection for claim 13);
Kapoor does not explicitly teach wherein determining whether to record information related to the packet flow associated with the packet in the LFRT of the network node is based on whether the flow record bit in the packet header of the packet is marked.
However, Bechtolsheim teaches wherein determining whether to record information related to the packet flow associated with the packet in the LFRT of the network node is based on whether the flow record bit in the packet header of the packet is marked (see rejection for claim 3);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein determining whether to record information related to the packet flow associated with the packet in the LFRT of the network node is based on whether the flow record bit in the packet header of the packet is marked, as taught by Bechtolsheim in the system of Kapoor, in order to efficiently buffer and enqueue flows, and determine buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 16, the combination of Kapoor and Bechtolsheim teaches the network node of claim 15 (see rejection for claim 15);
Kapoor does not explicitly teach wherein the flow record bit in the packet header of the network node is initially unmarked when the packet is received from a consumer side of a network.
However, Bechtolsheim teaches wherein the flow record bit in the packet header of the network node is initially unmarked when the packet is received from a consumer side of a network (see rejection for claim 4);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the flow record bit in the packet header of the network node is initially unmarked when the packet is received from a consumer side of a network, as taught by Bechtolsheim in the system of Kapoor, in order to efficiently buffer and enqueue flows, and determine buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 17, the combination of Kapoor and Bechtolsheim teaches the network node of claim 16 (see rejection for claim 16);
Kapoor does not explicitly teach wherein setting the flow record bit in the packet header of the packet comprises: marking the flow record bit when the information from the packet associated with the packet flow is not recorded in the LFRT of the network node, and maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is recorded in the LFRT of the network node.
However, Bechtolsheim teaches wherein setting the flow record bit in the packet header of the packet comprises: marking the flow record bit when the information from the packet associated with the packet flow is not recorded in the LFRT of the network node, and maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is recorded in the LFRT of the network node (see rejection for claim 5);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein setting the flow record bit in the packet header of the packet comprises: marking the flow record bit when the information from the packet associated with the packet flow is not recorded in the LFRT of the network node, and maintaining the flow record bit as unmarked when the information from the packet associated with the packet flow is recorded in the LFRT of the network node, as taught by Bechtolsheim in the system of Kapoor, in order to provide a flexible, low-overhead, extremely fast dynamic buffer limiting method to fairly buffer and enqueue flows, and enable efficient buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Regarding claim 18, the combination of Kapoor and Bechtolsheim teaches the network node of claim 15 (see rejection for claim 15);
Kapoor does not explicitly teach wherein the information related to the packet flow associated with the packet should be recorded in the LFRT of the network node when the flow record bit is unmarked.
However, Bechtolsheim teaches wherein the information related to the packet flow associated with the packet should be recorded in the LFRT of the network node when the flow record bit is unmarked (see rejection for claim 6);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the information related to the packet flow associated with the packet should be recorded in the LFRT of the network node when the flow record bit is unmarked, as taught by Bechtolsheim in the system of Kapoor, in order to efficiently buffer and enqueue flows, and determine buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
Claims 2, 8, 14, 19, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kapoor et al. (US7193968B1) in view of Bechtolsheim et al. (US6515963B1), and further in view of Aybay et al. (US20110255408A1).
Regarding claim 2, the combination of Kapoor and Bechtolsheim teaches the method of claim 1 (see rejection for claim 1);
The combination of Kapoor and Bechtolsheim does not explicitly teach further comprising extracting a flow identifier (ID) from the packet header of the packet to identify the packet flow associated with the packet.
However, Aybay teaches further comprising extracting a flow identifier (ID) from the packet header of the packet to identify the packet flow associated with the packet (Paragraph [0043]: Flow table logic 520 may include hardware, or hardware in combination with software, that may receive a data unit from PFE 310, determine a flow identifier from the data unit (e.g., read the flow identifier from the data unit or generate the flow identifier based on information in the data unit), provide information regarding the data unit and the flow identifier to create and/or update information regarding the data flow in flow table 530. Paragraph [0044]: In one implementation, flow table logic 520 may identify the flow identifier from information in the header of the data unit. For example, flow table logic 520 may construct the flow identifier from information in the data unit header that relates to information in the IP fields, such as the source IP address, the destination IP address, the source port, the destination port, and/or the L3 protocol type. In one implementation, the flow identifier may be calculated as a hash value of the information in the data unit header, and may be used to identify or create an entry in flow table 530. Flow table logic 520 may use pointer 432 in packet descriptor 430 to locate the IP fields in header portion 420 of the data unit.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide extracting a flow identifier (ID) from the packet header of the packet to identify the packet flow associated with the packet, as taught by Aybay in the combined system of Kapoor and Bechtolsheim, in order to obtain information relating to the data flow entry and the record in the data table (Aybay: Paragraphs [0043], [0044]).
Regarding claim 8, the combination of Kapoor and Bechtolsheim teaches the method of claim 1 (see rejection for claim 1);
The combination of Kapoor and Bechtolsheim does not explicitly teach wherein the LFRT is stored in on-chip memory of the first network device.
However, Aybay teaches wherein the LFRT is stored in on-chip memory of the first network device (Paragraph [0038]: VCPU 360 may include one or more processors, microprocessors, and/or processing logic (e.g., ASICs, FPGAs, etc.) that may perform network communications, management, and analysis functions. For example, VCPU 360 may control functions related to (local) operations between components shown in FIG. 3 and may control functions related to “visibility” of data units transmitted though interface 230. For example, VCPU 360 may accumulate records associated with a flow table and/or sampled data units. For example, VCPU 360 may receive a record, associated with a flow table entry, and/or sampled data units from FFQ logic 320. Paragraph [0039]: VCPU 360 may aggregate flow table records and/or statistics based on various parameters, such as communication protocol, port number, source and/or destination addresses, source and/or destination address prefixes, source and/or destination autonomous system (AS) prefixes, etc. VCPU 360 may also perform management, accounting, or security processes, such as intrusion detection algorithms, analyses of successful to unsuccessful flows, etc. Paragraph [0052]: FIG. 5, in an exemplary operation, flow table logic 520 may send certain information regarding entries in flow table 530 to VCPU 360 (FIG. 3). For example, when flow table logic 520 creates a new entry in flow table 530, flow table logic 520 may generate a flow creation record. In one implementation, a flow creation record may include information regarding the time that the entry is created in flow table 530, the header of the data unit, the packet descriptor associated with the data unit, and/or bookkeeping information (e.g., the flow identifier or other information that may be useful to the operations performed by VCPU 360). Paragraph [0071]: The flow creation record may be sent to VCPU 360 (block 1070). For example, flow table logic 520 may send the flow creation record to VCPU 360 when the flow creation record is generated.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the LFRT is stored in on-chip memory of the first network device, as taught by Aybay in the combined system of Kapoor and Bechtolsheim, in order to enable efficient storage and retrieval of the forwarded information (Aybay: Paragraph [0005], [0020]).
Regarding claim 14, the combination of Kapoor and Bechtolsheim teaches the network node of claim 13, wherein the processor is configured to execute the instructions to cause the network node to (see rejection for claim 13);
The combination of Kapoor and Bechtolsheim does not explicitly teach to extract a flow identifier (ID) from the packet header of the packet to identify the packet flow associated with the packet.
However, Aybay teaches to extract a flow identifier (ID) from the packet header of the packet to identify the packet flow associated with the packet (see rejection for claim 2);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to extract a flow identifier (ID) from the packet header of the packet to identify the packet flow associated with the packet, as taught by Aybay in the combined system of Kapoor and Bechtolsheim, in order to obtain information relating to the data flow entry and the record in the data table (Aybay: Paragraphs [0043], [0044]).
Regarding claim 19, the combination of Kapoor and Bechtolsheim teaches the network node of claim 18 (see rejection for claim 18);
The combination of Kapoor and Bechtolsheim does not explicitly teach wherein the processor comprises on-chip memory, and wherein the LFRT is stored in the on-chip memory.
However, Aybay teaches wherein the processor comprises on-chip memory, and wherein the LFRT is stored in the on-chip memory (see rejection for claim 8);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the processor comprises on-chip memory, and wherein the LFRT is stored in the on-chip memory, as taught by Aybay in the combined system of Kapoor and Bechtolsheim, in order to enable efficient storage and retrieval of the forwarded information (Aybay: Paragraph [0005], [0020]).
Regarding claim 20, Kapoor teaches to receive a packet along a flow path of the packet, wherein the flow path comprises a plurality of network devices comprising the device; determine whether information related to a packet flow associated with the packet should be recorded in a first local flow record table (LFRT) of the device; determine whether a flow entry for the packet flow already exists in the LFRT when the information related to the packet flow associated with the packet should be recorded in a LFRT of the device; update the flow entry for the packet flow in the LFRT with the information from the packet when the flow entry for the packet flow already exists in the LFRT; create the flow entry for the packet flow in the LFRT and updating the flow entry for the packet flow with the information from the packet when there is available memory space to create the flow entry for the packet flow in the LFRT; wherein the distributed flow record comprises first flow entries of the first LFRT and second flow entries of at least one other LFRT ofthe other networking devices in the plurality o fnetwork devices; and forward the packet (see rejection for claim 1);
Kapoor does not explicitly teach a computer program product comprising a non-transitory computer readable storage medium having computer readable program instructions stored thereon, the computer readable program instructions when executed by a processor of a device causes the device to: determine whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT; set a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of a distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record.
However, Bechtolsheim teaches to determine whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT; set a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of a distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record (see rejection for claim 1);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to determine whether there is sufficient available memory space to create the flow entry for the packet flow in the LFRT when the flow entry for the packet flow does not exist in the LFRT; set a flow record bit in a packet header of the packet based on whether the information from the packet associated with the packet flow has been recorded as part of a distributed flow record to indicate to other networking devices in the plurality of network devices whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record, as taught by Bechtolsheim in the system of Kapoor, in order to provide a flexible, low-overhead, extremely fast dynamic buffer limiting method to fairly buffer and enqueue flows, and enable efficient buffer allocation and resource sharing to avoid congestion (Bechtolsheim: Col 3, lines 48-67; Col 4, lines 1-13; Col 11, lines 1-10).
The combination of Kapoor and Bechtolsheim does not explicitly teach a computer program product comprising a non-transitory computer readable storage medium having computer readable program instructions stored thereon, the computer readable program instructions when executed by a processor of a device causes the device to.
However, Aybay teaches a computer program product comprising a non-transitory computer readable storage medium having computer readable program instructions stored thereon, the computer readable program instructions when executed by a processor of a device causes the device to (Claim 31: A non-transitory computer-readable memory device storing instructions that are executable by a processor, the instructions comprising:)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a computer program product comprising a non-transitory computer readable storage medium having computer readable program instructions stored thereon, the computer readable program instructions when executed by a processor of a device causes the device to, as taught by Aybay in the combined system of Kapoor and Bechtolsheim, so that the instructions can be executed to perform functions that facilitate storage of information, and enable efficient searching and retrieval of the stored information (Aybay: Claim 31; Paragraphs [0005], [0006]).
Claims 9, 10, 11 are rejected under 35 U.S.C. 103 as being unpatentable over Kapoor et al. (US7193968B1) in view of Bechtolsheim et al. (US6515963B1), and further in view of Kohn et al. (US20130013598A1).
Regarding claim 9, the combination of Kapoor and Bechtolsheim teaches the method of claim 1 (see rejection for claim 1);
The combination of Kapoor and Bechtolsheim does not explicitly teach further comprising forwarding a second packet to an overflow network device for enabling the overflow network device to record the information related to the packet flow prior to forwarding the packet to a consumer side of a network when the information related to the packet flow has not been recorded in the LFRT of any network device along the flow path.
However, Kohn teaches forwarding a second packet to an overflow network device for enabling the overflow network device to record the information related to the packet flow prior to forwarding the packet to a consumer side of a network when the information related to the packet flow has not been recorded in the LFRT of any network device along the flow path (Paragraph [0028]: For example, in managing flow records, VCPU 340 may receive flow table records and statistics from FFQ logic 320, aggregate and/or maintain the received flow table records and statistics in a shadow table, and export the aggregated flow table records and/or statistics to another device within network device 102, or alternatively, to a network device that is external to network device 102. VCPU 340 may aggregate flow table records and/or statistics based on various parameters, such as a communication protocol, a port number, source and/or destination addresses, a source/destination address prefix, a source/destination autonomous system (AS) prefix, etc. Paragraph [0048]: When information in mask field 520 indicates that the record should be masked (Yes—in block 640), the data unit may be processed by FFQ logic 320 (block 650). For example, FFQ logic 320 may prepare and forward the data unit to switch fabric for transmission to another network device 102 (block 650), without creating or updating a record within flow table 440 (block 640).)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide forwarding a second packet to an overflow network device for enabling the overflow network device to record the information related to the packet flow prior to forwarding the packet to a consumer side of a network when the information related to the packet flow has not been recorded in the LFRT of any network device along tha flow path, as taught by Kohn in the combined system of Kapoor and Bechtolsheim, in order to manage flow records (Kohn: Paragraph [0028]).
Regarding claim 10, the combination of Kapoor, Bechtolsheim, and Kohn teaches the method of claim 9 (see rejection for claim 9);
The combination of Kapoor and Bechtolsheim does not explicitly teach wherein the second packet is a copy of the packet.
However, Kohn teaches wherein the second packet is a copy of the packet (Paragraph [0028]: For example, in managing flow records, VCPU 340 may receive flow table records and statistics from FFQ logic 320, aggregate and/or maintain the received flow table records and statistics in a shadow table, and export the aggregated flow table records and/or statistics to another device within network device 102, or alternatively, to a network device that is external to network device 102. VCPU 340 may aggregate flow table records and/or statistics based on various parameters, such as a communication protocol, a port number, source and/or destination addresses, a source/destination address prefix, a source/destination autonomous system (AS) prefix, etc.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the second packet is a copy of the packet, as taught by Kohn in the combined system of Kapoor and Bechtolsheim, in order to manage flow records (Kohn: Paragraph [0028]).
Regarding claim 11, the combination of Kapoor, Bechtolsheim, and Kohn teaches the method of claim 9 (see rejection for claim 9);
The combination of Kapoor and Bechtolsheim does not explicitly teach wherein the second packet comprises the information related to the packet flow associated with the packet to be recorded in the LFRT of the overflow network device.
However, Kohn teaches wherein the second packet comprises the information related to the packet flow associated with the packet to be recorded in the LFRT of the overflow network device (Paragraph [0028]: For example, in managing flow records, VCPU 340 may receive flow table records and statistics from FFQ logic 320, aggregate and/or maintain the received flow table records and statistics in a shadow table, and export the aggregated flow table records and/or statistics to another device within network device 102, or alternatively, to a network device that is external to network device 102. VCPU 340 may aggregate flow table records and/or statistics based on various parameters, such as a communication protocol, a port number, source and/or destination addresses, a source/destination address prefix, a source/destination autonomous system (AS) prefix, etc.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide wherein the second packet comprises the information related to the packet flow associated with the packet to be recorded in the LFRT of the overflow network device, as taught by Kohn in the combined system of Kapoor and Bechtolsheim, in order to manage flow records (Kohn: Paragraphs [0028], [0048]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Kapoor et al. (US7193968B1) in view of Bechtolsheim et al. (US6515963B1) and Kohn et al. (US20130013598A1), and further in view of Aybay et al. (US20110255408A1).
Regarding claim 12, the combination of Kapoor, Bechtolsheim, and Kohn teaches the method of claim 11 (see rejection for claim 11);
The combination of Kapoor, Bechtolsheim, and Kohn does not explicitly teach further comprising exporting the flow entry for the packet flow in the LFRT to a network management entity.
However, Aybay teaches further comprising exporting the flow entry for the packet flow in the LFRT to a network management entity (Paragraph [0038]: For example, VCPU 360 may accumulate records associated with a flow table and/or sampled data units. For example, VCPU 360 may receive a record, associated with a flow table entry, and/or sampled data units from FFQ logic 320. In one implementation, VCPU 360 may include temporary storage, such as RAM and/or flash memory, to temporarily store the records and/or sampled data units. Paragraph [0039]: For example, VCPU 360 may receive flow table records and statistics from FFQ logic 320, aggregate and/or maintain the received flow table records and statistics, and export the aggregated flow table records and/or statistics to another component within network device 104 (e.g., analyzer module 240), or alternatively, to a device that is external to network device 104. VCPU 360 may aggregate flow table records and/or statistics based on various parameters, such as communication protocol, port number, source and/or destination addresses, source and/or destination address prefixes, source and/or destination autonomous system (AS) prefixes, etc. VCPU 360 may also perform management, accounting, or security processes, such as intrusion detection algorithms, analyses of successful to unsuccessful flows, etc. Paragraph [0081]: VCPU 360 may also perform security and/or network functions. For example, VCPU 360 may determine whether a particular source (e.g., a particular endpoint device 102) is responsible for the creation of more than a particular quantity of data flows during a period of time. In another implementation, VCPU 360 may determine the ratio of the number of successful data flows to the number of unsuccessful data flows associated with a particular source. Whether establishment of a data flow is successful or unsuccessful may be determined, for example, by monitoring the initial data units exchanged between a source and a destination (e.g., the transmission control protocol (TCP) messages exchanged in a three-way handshake). It might be useful for flow table logic 520 to track successful and unsuccessful data flows in flow table 530. In this case, flow table 530 may include an additional field that indicates whether a data flow was successfully or unsuccessfully established. Flow table logic 520 may send information regarding successful and unsuccessful data flows to VCPU 360 as part of the flow creation or termination records.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide comprising exporting the flow entry for the packet flow in the LFRT to a network management entity, as taught by Aybay in the combined system of Kapoor, Bechtolsheim, and Kohn, so that a packet flow that has not been recorded in the flow table can be stored in the network management entity such as the VPCU to support extra storage as well as for maintaining flow records and statistics (Aybay: Paragraphs [0038], [0039]).
Response to Arguments
Applicant's arguments filed December 12, 2025 with respect to Claims 1, 3-7, 13, and 15-18 being rejected under 35 U.S.C. § 103 as being unpatentable over Kapoor et al. (US7193968B1) in view of Bechtolsheim et al. (US6515963B1); Claims 2, 8, 14, and 19-20 being rejected under 35 U.S.C. § 103 as being unpatentable over Kapoor in view of Bechtolsheim, and further in view of Aybay et al. (US20110255408A1); Claims 9-11 being rejected under 35 U.S.C. 103 as being unpatentable over Kapoor in view of Bechtolsheim, and further in view of Kohn et al. (US2013/0013598); Claim 12 being rejected under 35 U.S.C.§ 103 as being unpatentable over Kapoor in view of Bechtolsheim, and Kohn, and further in view of Aybay, have been fully considered.
Applicant argues that the combination of Kapoor and Bechtolsheim does not disclose all of the limitations set forth in independent claims 1, 13, and 20. Kapoor teaches “wherein the distributed flow record comprises first flow entries of the first LFRT and second flow entries of at least one other LFRT of the other networking devices in the plurality of network devices”. Kapoor teaches recording information from the packet associated with the packet flow as part of the distributed flow record. Kapoor teaches that during the processing of packets and monitoring the flows, the processing engine can determine if the packet is part of one or more recorded traffic flows, and create a new entry in the table if the packet is not part of one of the recorded flows or already recorded, and dynamically updating the per-flow data in the table, determining the aging, idleness, and storage limits of flows, time stamping the packets in a flow, and creating, updating and transmitting traffic information packets.
Applicant further argues that Bechtolsheim does not teach “whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record”. However, as per Figure 6 of Bechtolsheim, the marked packet (with the mark bit set), is enqueued and a flow table entry is created, which indicates that the mark bit set in the packet header is associated with the packet for which a flow table entry is created. The bit in the packet header is marked for the packet that is enqueued normally and for which a flow table entry is updated. Since the packet qualifies for enqueuing, it is enqueued normally. While the marked bit can indicate that the packet passed through congestion, it still indicates that it was enqueued, and a flow table entry was created. Thus, Bechtolsheim teaches that the bit in the packet header of the marked packet indicates the packet flow being recorded as part of the flow table entry (flow record). As per the limitation of claim 1 which recites “whether the information from the packet associated with the packet flow has been recorded as part of the distributed flow record so that the other networking devices can identify whether or not the information from the packet associated with the packet flow still needs to be recorded to the distributed flow record”, it suggests the intended use of setting the flow record bit in the packet header.
Thus, the combination of Kapoor and Bechtolsheim teaches independent claims 1 and 13, and the combination of Kapoor, Bechtolsheim and Aybay teaches independent claim 20. Dependent claims 2-12, 14-19 are taught by a combination of the cited references.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LATHA CHAKRAVARTHY whose telephone number is (703)756-1172. The examiner can normally be reached M-Th 8:30 AM - 5 PM.
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, Huy Vu can be reached at 571-272-3155. 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.
/L.C./Examiner, Art Unit 2461
/HUY D VU/Supervisory Patent Examiner, Art Unit 2461