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 .
This office action is responsive to a response filed on February 25th, 2026. In this Office Action:
Claims 1, 3, 6-10, 12, 14-16, 18, and 20-27 are pending.
Claims 1, 3, 6-10, 12, 14-16, 18, and 20-27 are rejected.
Response to Amendment
The amendments filed on February 25th, 2026 have been entered.
Claims 1, 3, 10, 12, 16, and 18 have been amended.
Claims 2, 4-5, 11, 13, 17 and 19 have been canceled.
Claim 21-27 have been added.
The previously raised claim objections are withdrawn for claims 11 and 17 in light of the amendments.
Response to Arguments
Applicant’s arguments filed on February 25th, 2026 have been fully considered, but are moot in view of the new grounds of rejection, as presented in this Office Action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 and 6-10, 14-16, and 20-27 are under 35 U.S.C. 103 as being unpatentable over Segalov et al. (Patent No. US 9,369,360), hereinafter Segalov; in view of Indiresan et al. (Pub. No. US 2021/0344598), hereinafter Indiresan.
Claim 1. Segalov discloses [a] method comprising:
detecting a failure in a data path in a data plane, wherein the failure comprises a failure to send packets through the data path, wherein the data path comprises a plurality of nodes (See Col. 2 lines 63-65; systems and methods of detecting and identifying silent failures in a network. See Col. 10 lines 23-50 and Fig. 7; retrieving probing instructions that resulted in failed transmissions from the database 312 by a route resolver 314 (step 710). The route resolver 314 executes route resolving functions to determine a set of nodes that are likely to have been on the path of the from a source node to a destination node specified in the retrieved probing instruction (step 720). This set of nodes is referred to as the partial path … Upon receipt by the fault detection module 302 of a probing instruction that resulted in a failed transmission (step 710), the route resolver executes route resolving functions to determine a set of nodes that are likely to have been on the path of the from a source node to a destination node specified in the retrieved probing instruction (step 720) … See also Col. 1 lines 44-53 and Col. 11 lines 9-27. Examiner’s interpretation: The Examiner interprets “detecting a failure in a data path in a data plane” as detecting a failure to forward packet(s), by a node, in data path); and
traversing the data path in reverse order to identify a root cause of the failure (See Col. 10 lines 51-67; route resolving functions is a “traceroute” functions that can be performed from the source node to the destination node. The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through. The data packet prompts a response to be sent back to the source upon either reaching the designated destination of the packet or obtaining a TTL of zero … See Col. 11 lines 28-45; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). See also Col. 11 lines 1-10 and 27-45, Col. 12 lines 1-23, and Col. 13 lines 13-29), wherein traversing the data path in reverse order comprises, at each node in the plurality of nodes in the traversal,
modifying packets to comprise an ordered list of identifiers of the plurality of nodes (See Col. 10 lines 51-67 and Col. 11 lines 1-8; By sending multiple packets with varying TTL values, the route resolver 314 identifies nodes that were likely to have been on the path of the from the source node to the destination node specified in a given probing instruction);
sending the modified packets through a subset of the plurality of nodes, wherein the subset of the plurality of nodes comprises the node and those of the plurality of nodes prior to the node in the data path (See Col. 10 lines 51-67 and Col. 11 lines 1-8; The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through (sending packets through a subset of the plurality of nodes) … if a packet with a TTL value of one is sent from a source node to a destination node along a path that includes multiple nodes between the source node and the destination node, the TTL value would be reduced to zero at the first node after the source on the path. In this case, a response would be sent to the source node from the first node after the source node on the path. If a packet with a TTL value of two is sent along the same path, the TTL value would be reduced to zero at the second node after the source on the path, and a response would be sent to the source node from the second node after the source. By sending multiple packets with varying TTL values, the route resolver 314 identifies nodes that were likely to have been on the path of the from the source node to the destination node specified in a given probing instruction … Examiner’s interpretation: At the second node after the source on the path, the subset of the plurality of nodes includes the second node and the first node which is prior to the second node in the data path. It is reasonable to interpret that at a third node, the subset of the plurality of nodes includes the third node itself, the second node and the first node which are prior to the third node in the data path);
determining whether the modified packets are successfully transmitted through the subset of the plurality of nodes; based on determining that the packets are successfully transmitted through the subset of the plurality of nodes, identifying a subsequent node to the node in the data path as the node being the root cause of the failure (See Col. 11 lines 28-45; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). Nodes can be fault at their ingress or their egress ports … If the failure was at the ingress of the faulty node, that node would not respond to a traceroute query, and thus the terminal node of the partial path identified by the route resolver would be the last properly functioning node in the path. The faulty path would be a not yet identified terminal node next hop (a subsequent node to the node). The route resolver 314 can further resolve the route of a given partial path to identify the potential terminal node next hops that might have been responsible for the failed transmission, in case the failure was not at the terminal node …); and
based on determining that the packets are not successfully transmitted through the subset of the plurality of nodes, traversing to a preceding node in the data path (See Col. 11 lines 28-40; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). Nodes can be fault at their ingress or their egress ports. If the faulty node is faulty at its egress, the node would have received a traceroute query with a TTL value corresponding to its position on the path, and would send a response. However, the egress failure would prevent traceroute queries with higher TTL values from reaching more distant nodes. In these situations, the faulty node would appear as the terminal node of the partial path determined by the route resolver 314).
Segalov doesn’t explicitly disclose modifying packets to comprise signatures unique to each of the packets and headers of the packets with indications to exit the data path at the node; [and] wherein determining whether the packets are successfully transmitted through the subset of the plurality of nodes comprises matching signatures of packets exiting the data plane with signatures of the modified packets.
However, Indiresan discloses:
modifying packets to comprise signatures unique to each of the packets and headers of the packets with indications to exit the data path at the node (See Parag. [0123-0126] and Fig. 7B; Process 712 may be performed by a node receiving a data path with an existing path signature. At 714, a packet including a first path signature received. The packet may be part of a flow through a network from a source to a destination. In some cases, the first path signature may have been added to the packet and/or generated by a previous node in the network. At 716, a second path signature based on the first path signature and one or more node details is generated. The one or more node details can include at least one of an identifier of the particular ingress port at which the packet is received, an identifier of an egress port at which the packet will be forwarded from, an identifier of the node at which the packet is received, or the like ... At 718, the first path signature is replaced with the second path signature in the packet. In some cases, the first path signature is deleted from, and the second path signature is populated in, a data field in a header field ... the packet is forwarded with the second path signature. In various implementations, the packet is forwarded from a selected egress port. The egress port can be selected based on at least one of the destination of the packet, a load associated with a node affiliated with the egress port, a load associated with a node attached to another egress port, or the like. For instance, the header of the packet may indicate the destination of the packet, and the egress port (indications to exit the data path at the node) can be selected to forward the packet in the direction of the destination. See Parag. [0039]; generate path signatures for the packets and amend the packets with the path signatures. As used herein, the terms “signature,” “path signature,” and their equivalents, can refer to a unique identifier of a path that a packet has traversed or is traversing); [and]
wherein determining whether the packets are successfully transmitted through the subset of the plurality of nodes comprises matching signatures of packets exiting the data plane with signatures of the modified packets (See Parag. [0129-0137] and Fig. 8-9; At 802, a first path signature of a first packet in a flow is identified. In some implementations, the first path signature is in the first packet as-received from a previous node in the network ... At 804, a second path signature of a second packet in the flow is identified ... the second path signature is also generated by the node performing the process 800 ... the first path signature is determined to be different than the second path signature ... Accordingly, the first path signature and the second path signature can be compared even after one or both of the first and second packets has been forwarded to another node in the network ... At 808, an alert indicating the flow is transmitted to a collector ... At 902, an alert is received from a node. The alert may indicate a path change in a network to which the node belongs ... At 904, a problem associated with the node is identified. In some cases, another alert may be received from another node that is downstream of the node from which the alert is received at 902. The path change at the downstream node may be determined to have originated at the node from which the alert is received at 902 ... the problem may be a problem associated with congestion in the network. For instance, the node may determine to forward a first packet in the flow to a downstream node, may determine that the downstream node is congested).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify fault detection system, taught by Segalov, to include modifying packets to comprise signatures unique to each of the packets and headers of the packets with indications to exit the data path at the node, and wherein determining whether the packets are successfully transmitted through the subset of the plurality of nodes comprises matching signatures of packets exiting the data plane with signatures of the modified packets, as taught by Indiresan. This would be convenient to diagnosing problems with networks (Indiresan, Parag. [0002]).
Claim 6. Segalov in view of Indiresan discloses [t]he method of claim 1,
Segalov further discloses wherein each node of the plurality of nodes comprises one or more chips (See Col. 16 lines 20-23; each node could be a switch, router, other forwarding device within a network or one of a plurality of ports located thereon. See also Col. 2 lines 63-67).
Claim 7. Segalov in view of Indiresan discloses [t]he method of claim 6,
Segalov further discloses wherein the one or more chips comprise at least one of a central processing unit, an application-specific integrated circuit chip, a memory chip, and a network-on-chip (See Col. 16 lines 20-23; each node could be a switch, router, other forwarding device within a network or one of a plurality of ports located thereon. See also Col. 2 lines 63-67. Examiner’s interpretation: The examiner reasonably interprets switches, routers or other forwarding device, taught by Segalov, to include elements such as a CPU and memory etc.).
Claim 8. Segalov in view of Indiresan discloses [t]he method of claim 1,
Segalov doesn’t explicitly discloses the method further comprising remediating the node identified as the root cause of the failure.
However, Charles discloses remediating the node identified as the root cause of the failure (See Parag. [0137]; At 906, the problem is reported to a central administrator. In some cases, the central administrator may initiate a process by which the problem can be solved. In various implementations, the central administrator can be a device that can output an alert to an individual or system that can address the problem. For instance, the central administrator my dispatch an individual to correct the problem in the network).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify fault detection system, taught by Segalov, to include remediating the node identified as the root cause of the failure, as taught by Indiresan. This would be convenient to resolve diagnosed problems with networks (Indiresan, Parag. [0002]).
Claim 9. Segalov in view of Indiresan discloses [t]he method of claim 1,
Segalov further discloses wherein the data path comprises a data path in a firewall (See Col. 4 lines 44-52; servers 210 in a network may interact with one another by sending and receiving data packets via the network links. The servers 210 may interact with other servers 210 in the same rack 214, on other racks 214 within the same superblock 202, within another superblock 202, or another data center 200 by sending and receiving packets via the network links. A packet may be routed through network gateway devices 220 to reach its destination server. See Col. 4 lines 41-43; the gateway device 220 implements a firewall or filtering protocols to restrict data access to or from the data center).
Claim 10. Segalov discloses [a] non-transitory machine-readable medium having program code stored thereon (See Col. 5 lines 27-36), the program code comprising instructions to:
detect a failure in a data path in a computing fabric, wherein the failure comprises a failure to send packets through the data path, wherein the data path comprises a plurality of nodes (See Col. 2 lines 63-65; systems and methods of detecting and identifying silent failures in a network. See Col. 10 lines 23-50 and Fig. 7; retrieving probing instructions that resulted in failed transmissions from the database 312 by a route resolver 314 (step 710). The route resolver 314 executes route resolving functions to determine a set of nodes that are likely to have been on the path of the from a source node to a destination node specified in the retrieved probing instruction (step 720). This set of nodes is referred to as the partial path … Upon receipt by the fault detection module 302 of a probing instruction that resulted in a failed transmission (step 710), the route resolver executes route resolving functions to determine a set of nodes that are likely to have been on the path of the from a source node to a destination node specified in the retrieved probing instruction (step 720) … See also Col. 1 lines 44-53 and Col. 11 lines 9-27); and
traverse the data path in reverse order to identify a root cause of the failure (See Col. 10 lines 51-67; route resolving functions is a “traceroute” functions that can be performed from the source node to the destination node. The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through. The data packet prompts a response to be sent back to the source upon either reaching the designated destination of the packet or obtaining a TTL of zero … See Col. 11 lines 28-45; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). See also Col. 11 lines 1-10 and 27-45, Col. 12 lines 1-23, and Col. 13 lines 13-29), wherein traversing the data path in reverse order comprises, at each node in the plurality of nodes in the traversal,
modify packets to comprise an ordered list of identifiers of the plurality of nodes (See Col. 10 lines 51-67 and Col. 11 lines 1-8; By sending multiple packets with varying TTL values, the route resolver 314 identifies nodes that were likely to have been on the path of the from the source node to the destination node specified in a given probing instruction);
send the modified packets through the data path (See Col. 10 lines 51-67 and Col. 11 lines 1-8; The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through … By sending multiple packets with varying TTL values, the route resolver 314 identifies nodes that were likely to have been on the path of the from the source node to the destination node specified in a given probing instruction …);
determine whether the modified packets successfully exit the data path at the node; based on determining that the modified packets successfully exit the data path at the node, identify a subsequent node to the node in the data path as the node being the root cause of the failure (See Col. 11 lines 28-45; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). Nodes can be fault at their ingress or their egress ports … If the failure was at the ingress of the faulty node, that node would not respond to a traceroute query, and thus the terminal node of the partial path identified by the route resolver would be the last properly functioning node in the path. The faulty path would be a not yet identified terminal node next hop (a subsequent node to the node). The route resolver 314 can further resolve the route of a given partial path to identify the potential terminal node next hops that might have been responsible for the failed transmission, in case the failure was not at the terminal node …); and
based on determining that the packets do not successfully exit the data path at the node, traverse to a preceding node in the data path (See Col. 11 lines 28-40; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). Nodes can be fault at their ingress or their egress ports. If the faulty node is faulty at its egress, the node would have received a traceroute query with a TTL value corresponding to its position on the path, and would send a response. However, the egress failure would prevent traceroute queries with higher TTL values from reaching more distant nodes. In these situations, the faulty node would appear as the terminal node of the partial path determined by the route resolver 314).
Segalov doesn’t explicitly disclose modify packets to comprise signatures unique to each of the packets and packet headers with indications to exit the data path at the node; [and] wherein the instructions to determine whether the modified packets successfully exit the data path at the node comprise instructions to match signatures of packets exiting the computing fabric with signatures of the modified packets.
However, Indiresan discloses:
modify packets to comprise signatures unique to each of the packets and packet headers with indications to exit the data path at the node (See Parag. [0123-0126] and Fig. 7B; Process 712 may be performed by a node receiving a data path with an existing path signature. At 714, a packet including a first path signature received. The packet may be part of a flow through a network from a source to a destination. In some cases, the first path signature may have been added to the packet and/or generated by a previous node in the network. At 716, a second path signature based on the first path signature and one or more node details is generated. The one or more node details can include at least one of an identifier of the particular ingress port at which the packet is received, an identifier of an egress port at which the packet will be forwarded from, an identifier of the node at which the packet is received, or the like ... At 718, the first path signature is replaced with the second path signature in the packet. In some cases, the first path signature is deleted from, and the second path signature is populated in, a data field in a header field ... the packet is forwarded with the second path signature. In various implementations, the packet is forwarded from a selected egress port. The egress port can be selected based on at least one of the destination of the packet, a load associated with a node affiliated with the egress port, a load associated with a node attached to another egress port, or the like. For instance, the header of the packet may indicate the destination of the packet, and the egress port (indications to exit the data path at the node) can be selected to forward the packet in the direction of the destination. See Parag. [0039]; generate path signatures for the packets and amend the packets with the path signatures. As used herein, the terms “signature,” “path signature,” and their equivalents, can refer to a unique identifier of a path that a packet has traversed or is traversing); [and]
wherein the instructions to determine whether the modified packets successfully exit the data path at the node comprise instructions to match signatures of packets exiting the computing fabric with signatures of the modified packets (See Parag. [0129-0137] and Fig. 8-9; At 802, a first path signature of a first packet in a flow is identified. In some implementations, the first path signature is in the first packet as-received from a previous node in the network ... At 804, a second path signature of a second packet in the flow is identified ... the second path signature is also generated by the node performing the process 800 ... the first path signature is determined to be different than the second path signature ... Accordingly, the first path signature and the second path signature can be compared even after one or both of the first and second packets has been forwarded to another node in the network ... At 808, an alert indicating the flow is transmitted to a collector ... At 902, an alert is received from a node. The alert may indicate a path change in a network to which the node belongs ... At 904, a problem associated with the node is identified. In some cases, another alert may be received from another node that is downstream of the node from which the alert is received at 902. The path change at the downstream node may be determined to have originated at the node from which the alert is received at 902 ... the problem may be a problem associated with congestion in the network. For instance, the node may determine to forward a first packet in the flow to a downstream node, may determine that the downstream node is congested).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify fault detection system, taught by Segalov, to include modify packets to comprise signatures unique to each of the packets and packet headers with indications to exit the data path at the node, and wherein the instructions to determine whether the modified packets successfully exit the data path at the node comprise instructions to match signatures of packets exiting the computing fabric with signatures of the modified packets, as taught by Indiresan. This would be convenient to diagnosing problems with networks (Indiresan, Parag. [0002]).
Claim 14. Segalov in view of Indiresan discloses [t]he non-transitory machine-readable medium of claim 10,
Segalov further discloses wherein each node of the plurality of nodes comprises one or more chips (See Col. 16 lines 20-23; each node could be a switch, router, other forwarding device within a network or one of a plurality of ports located thereon. See also Col. 2 lines 63-67).
Claim 15. Segalov in view of Indiresan discloses [t]he non-transitory machine-readable medium of claim 14,
Segalov further discloses wherein the one or more chips comprise at least one of a central processing unit, an application-specific integrated circuit chip, a memory chip, and a network-on-chip (See Col. 16 lines 20-23; each node could be a switch, router, other forwarding device within a network or one of a plurality of ports located thereon. See also Col. 2 lines 63-67. Examiner’s interpretation: The examiner reasonably interprets switches, routers or other forwarding device, taught by Segalov, to include elements such as a CPU and memory etc.).
Claim 16. Segalov discloses [a]n apparatus comprising:
in a data plane, a computing fabric; and in a control plane, a processor; and a machine-readable medium having instructions stored thereon that are executable by the processor to cause the apparatus to identify a root cause of failure in a data path of the computing fabric, wherein the instructions to identify the root cause of failure in the data path comprise instructions executable by the processor to cause the apparatus (See Col. 2 lines 63-65; systems and methods of detecting and identifying silent failures in a network. See Col. 5 lines 27-36; Each of the components of the fault detection system (zone probing controllers 304, probing agents 306, and the fault detection module 302) described herein can be implemented as a combination of hardware and software. For example, a component can be implemented as computer readable instructions stored on a tangible computer readable medium. When the computer executable instructions are executed by a processor, the instructions cause the processor to carry out the functionality of the respective components) to,
detect a failure in a data path in a data plane, wherein the failure comprises a failure to send packets through the data path, wherein the data path comprises a plurality of nodes (See Col. 2 lines 63-65; systems and methods of detecting and identifying silent failures in a network. See Col. 10 lines 23-50 and Fig. 7; retrieving probing instructions that resulted in failed transmissions from the database 312 by a route resolver 314 (step 710). The route resolver 314 executes route resolving functions to determine a set of nodes that are likely to have been on the path of the from a source node to a destination node specified in the retrieved probing instruction (step 720). This set of nodes is referred to as the partial path … Upon receipt by the fault detection module 302 of a probing instruction that resulted in a failed transmission (step 710), the route resolver executes route resolving functions to determine a set of nodes that are likely to have been on the path of the from a source node to a destination node specified in the retrieved probing instruction (step 720) … See also Col. 1 lines 44-53 and Col. 11 lines 9-27. Examiner’s interpretation: The Examiner interprets “detecting a failure in a data path in a data plane” as detecting a failure to forward packet(s), by a node, in data path); and
traverse the data path in reverse order to identify a root cause of the failure (See Col. 10 lines 51-67; route resolving functions is a “traceroute” functions that can be performed from the source node to the destination node. The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through. The data packet prompts a response to be sent back to the source upon either reaching the designated destination of the packet or obtaining a TTL of zero … See Col. 11 lines 28-45; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). See also Col. 11 lines 1-10 and 27-45, Col. 12 lines 1-23, and Col. 13 lines 13-29), wherein traversing the data path in reverse order comprises, at each node in the plurality of nodes in the traversal,
modify packets as diagnostic to comprise an ordered list of identifiers of the plurality of nodes (See Col. 10 lines 51-67 and Col. 11 lines 1-8; By sending multiple packets with varying TTL values, the route resolver 314 identifies nodes that were likely to have been on the path of the from the source node to the destination node specified in a given probing instruction);
send the modified packets through the data path (See Col. 10 lines 51-67 and Col. 11 lines 1-8; The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through … By sending multiple packets with varying TTL values, the route resolver 314 identifies nodes that were likely to have been on the path of the from the source node to the destination node specified in a given probing instruction …);
determine whether the modified packets successfully exit the data path at the node; based on determining that the modified packets successfully exit the data path at the node, identify a subsequent node to the node in the data path as the node being the root cause of the failure (See Col. 11 lines 28-45; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). Nodes can be fault at their ingress or their egress ports … If the failure was at the ingress of the faulty node, that node would not respond to a traceroute query, and thus the terminal node of the partial path identified by the route resolver would be the last properly functioning node in the path. The faulty path would be a not yet identified terminal node next hop (a subsequent node to the node). The route resolver 314 can further resolve the route of a given partial path to identify the potential terminal node next hops that might have been responsible for the failed transmission, in case the failure was not at the terminal node …); and
based on determining that the packets do not successfully exit the data path at the node, traverse to a preceding node in the data path (See Col. 11 lines 28-40; The faulty node that resulted in the failure for the probe instruction is likely to either be the last node of the identified path (referred to as the “terminal node” of the path) or the next node the packet was transferred to from the terminal node (referred to as the “terminal node next hop”). Nodes can be fault at their ingress or their egress ports. If the faulty node is faulty at its egress, the node would have received a traceroute query with a TTL value corresponding to its position on the path, and would send a response. However, the egress failure would prevent traceroute queries with higher TTL values from reaching more distant nodes. In these situations, the faulty node would appear as the terminal node of the partial path determined by the route resolver 314).
Segalov doesn’t explicitly disclose modify packets as diagnostic to comprise signatures unique to each of the packets and packet headers with indications to exit the data path at the node; [and] wherein the instructions to determine whether the modified packets successfully exit the data path at the node comprise instructions executable by the processor to cause the apparatus to match signatures of packets exiting the computing fabric with signatures of the modified packets.
However, Indiresan discloses:
modify packets as diagnostic to comprise signatures unique to each of the packets and packet headers with indications to exit the data path at the node (See Parag. [0123-0126] and Fig. 7B; Process 712 may be performed by a node receiving a data path with an existing path signature. At 714, a packet including a first path signature received. The packet may be part of a flow through a network from a source to a destination. In some cases, the first path signature may have been added to the packet and/or generated by a previous node in the network. At 716, a second path signature based on the first path signature and one or more node details is generated. The one or more node details can include at least one of an identifier of the particular ingress port at which the packet is received, an identifier of an egress port at which the packet will be forwarded from, an identifier of the node at which the packet is received, or the like ... At 718, the first path signature is replaced with the second path signature in the packet. In some cases, the first path signature is deleted from, and the second path signature is populated in, a data field in a header field ... the packet is forwarded with the second path signature. In various implementations, the packet is forwarded from a selected egress port. The egress port can be selected based on at least one of the destination of the packet, a load associated with a node affiliated with the egress port, a load associated with a node attached to another egress port, or the like. For instance, the header of the packet may indicate the destination of the packet, and the egress port (indications to exit the data path at the node) can be selected to forward the packet in the direction of the destination. See Parag. [0039]; generate path signatures for the packets and amend the packets with the path signatures. As used herein, the terms “signature,” “path signature,” and their equivalents, can refer to a unique identifier of a path that a packet has traversed or is traversing); [and]
wherein the instructions to determine whether the modified packets successfully exit the data path at the node comprise instructions executable by the processor to cause the apparatus to match signatures of packets exiting the computing fabric with signatures of the modified packets (See Parag. [0129-0137] and Fig. 8-9; At 802, a first path signature of a first packet in a flow is identified. In some implementations, the first path signature is in the first packet as-received from a previous node in the network ... At 804, a second path signature of a second packet in the flow is identified ... the second path signature is also generated by the node performing the process 800 ... the first path signature is determined to be different than the second path signature ... Accordingly, the first path signature and the second path signature can be compared even after one or both of the first and second packets has been forwarded to another node in the network ... At 808, an alert indicating the flow is transmitted to a collector ... At 902, an alert is received from a node. The alert may indicate a path change in a network to which the node belongs ... At 904, a problem associated with the node is identified. In some cases, another alert may be received from another node that is downstream of the node from which the alert is received at 902. The path change at the downstream node may be determined to have originated at the node from which the alert is received at 902 ... the problem may be a problem associated with congestion in the network. For instance, the node may determine to forward a first packet in the flow to a downstream node, may determine that the downstream node is congested).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify fault detection system, taught by Segalov, to include modify packets as diagnostic to comprise signatures unique to each of the packets and packet headers with indications to exit the data path at the node, and wherein the instructions to determine whether the modified packets successfully exit the data path at the node comprise instructions executable by the processor to cause the apparatus to match signatures of packets exiting the computing fabric with signatures of the modified packets, as taught by Indiresan. This would be convenient to diagnosing problems with networks (Indiresan, Parag. [0002]).
Claim 20 is taught by Segalov in view of Indiresan as described for claim 14.
Claim 21. Segalov in view of Indiresan discloses [t]he method of claim 1,
Segalov doesn’t explicitly disclose wherein determining whether the modified packets are successfully transmitted through the subset of the plurality of nodes comprises determining whether a threshold percentage of the modified packets have signatures matching the packets exiting the data plane.
However, Indiresan discloses wherein determining whether the modified packets are successfully transmitted through the subset of the plurality of nodes comprises determining whether a threshold percentage of the modified packets have signatures matching the packets exiting the data plane (See Parag. [0083]; The path change identifier 412 may determine that the second path signature 416 stored in the second entry of the flow table 410, is different than the first path signature 408, which is stored in the first entry of the flow table 410. Based on this difference, the path change identifier 412 may determine that there is a path change in the flow. In some cases, the path change identifier 412 may determine that greater than a threshold number of packets with the first path signature 408 and/or greater than the threshold number of packets with the second path signature 416 have been received, and in response, identify that there is a persistent path change in the flow).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify fault detection system, taught by Segalov, to include determining whether a threshold percentage of the modified packets have signatures matching the packets exiting the data plane, as taught by Indiresan. This would be convenient to diagnosing problems with networks (Indiresan, Parag. [0002]).
Claim 22. Segalov in view of Indiresan discloses [t]he method of claim 1,
Segalov discloses the method further comprising, at each current node in the subset of the plurality of nodes that receives a modified packet of the modified packets: based on a packet header of the modified packet indicating exiting the data path at the current node, exiting the modified packet from the data path at the current node; based on the packet header not indicating exiting the data path at the current node, determining a next node in the subset of the plurality of nodes based on the ordered list of identifiers of the plurality of nodes; and communicating the modified packet to the next node (See Col. 10 lines 51-67 and Col. 11 lines 1-8; The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through … if a packet with a TTL value of one is sent from a source node to a destination node along a path that includes multiple nodes between the source node and the destination node, the TTL value would be reduced to zero at the first node after the source on the path. In this case, a response would be sent to the source node from the first node after the source node on the path. If a packet with a TTL value of two is sent along the same path, the TTL value would be reduced to zero at the second node after the source on the path, and a response would be sent to the source node from the second node after the source. By sending multiple packets with varying TTL values, the route resolver 314 identifies nodes that were likely to have been on the path of the from the source node to the destination node specified in a given probing instruction …).
Claim 23. Segalov in view of Indiresan discloses [t]he method of claim 1,
Segalov further discloses wherein the headers of the modified packets further comprise data structures that indicate numbers of current nodes in the data path traversed by the modified packets (See Col. 10 lines 51-67 and Col. 11 lines 1-8; The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through … if a packet with a TTL value of one is sent from a source node to a destination node along a path that includes multiple nodes between the source node and the destination node, the TTL value would be reduced to zero at the first node after the source on the path. In this case, a response would be sent to the source node from the first node after the source node on the path. If a packet with a TTL value of two is sent along the same path, the TTL value would be reduced to zero at the second node after the source on the path, and a response would be sent to the source node from the second node after the source. By sending multiple packets with varying TTL values, the route resolver 314 identifies nodes that were likely to have been on the path of the from the source node to the destination node specified in a given probing instruction …).
Claim 24 is taught by Segalov in view of Indiresan as described for claim 21.
Claim 25 is taught by Segalov in view of Indiresan as described for claim 22.
Claim 26 is taught by Segalov in view of Indiresan as described for claim 21.
Claim 27 is taught by Segalov in view of Indiresan as described for claim 22.
Claims 3, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Segalov et al. (Patent No. US 9,369,360), hereinafter Segalov; in view of Indiresan et al. (Pub. No. US 2021/0344598), hereinafter Indiresan; and further in view of Ball (Pub. No. US 2023/0146525).
Claim 3. Segalov in view of Indiresan discloses [t]he method of claim 1,
Segalov further discloses wherein sending the packets through the subset of the plurality of nodes at each node in the traversal (See Col. 10 lines 51-67 and Col. 11 lines 1-8; The traceroute function includes sending multiple data packets from the source of the failed transmission, each packet having a different time-to-live value. The time-to-live (TTL) value is reduced at each node that it passes through … See also Col. 11 lines 28-45), wherein determining, at each node in the traversal, whether the packets are successfully transmitted through the subset of the plurality of nodes comprises determining, in user space, whether the packets are successfully transmitted through the subset of the plurality of nodes (See Col. 6 lines 27-35; The fault detection module 302 includes a database 312, a route resolver 314, an analysis module 316 and a reporting module 318. Information indicating the success or failure of probing instructions from across the network is received by the fault detection module 302 from the zone probing controllers 304 and is stored in the database 312 included in the fault detection module … See Col. 15 lines 64-67 and Col. 16 1-19; The reporting module 318 is configured to display or otherwise communicate to a human user (or operator) the resulting set of most likely failed network nodes (step 650). The reporting module 318 can also be configured to present data stored in the database 312 included in the fault detection module 302. For example, the reporting module 318 can display failed or successful probes and probing instructions or paths associated with probes. The reporting module 318 can include a user interface which allows the human user interactions with the fault detection system).
Segalov in view of Indiresan doesn’t explicitly disclose that sending the packets through the subset of the plurality of nodes at each node in the traversal comprises sending the packets through the subset of the plurality of nodes in kernel space.
However, Ball discloses sending the packets through the subset of the plurality of nodes in kernel space (See Parag. [0065]; Data path 313 module of kernel space 312 may configure a flow action of the policy for the forward packet flow to forward packets originating from the application workload running on VM 310A. Data path 313 module of kernel space 312 may also perform a lookup of the forwarding information in FIB 324A with an L3 address (e.g., destination IP address) of packet 316, e.g., either with an exact match or a longest prefix match (LPM), to determine the next hop and configures the next hop for the forward packet flow within flow table 326A).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify sending the packets through the subset of the plurality of nodes at each node in the traversal, taught by Segalov in view of Indiresan, to comprise sending the packets through the subset of the plurality of nodes in kernel space, as taught by Ball. This would be convenient for providing automatic policy configuration for packet flows; a computing device may automatically configure policy flows with a kernel of the computing device without sending packets to the user space of the computing device (Ball, Parag. [0005]).
Claim 12. Segalov in view of Indiresan discloses [t]he non-transitory machine-readable medium of claim 10,
Segalov further discloses wherein the instructions to determine, at each node in the traversal, whether the modified packets successfully exit the data path at the node comprise instructions to determine, in user space, whether the modified packets successfully exit the data path at the node (See Col. 6 lines 27-35; The fault detection module 302 includes a database 312, a route resolver 314, an analysis module 316 and a reporting module 318. Information indicating the success or failure of probing instructions from across the network is received by the fault detection module 302 from the zone probing controllers 304 and is stored in the database 312 included in the fault detection module … See Col. 15 lines 64-67 and Col. 16 1-19; The reporting module 318 is configured to display or otherwise communicate to a human user (or operator) the resulting set of most likely failed network nodes (step 650). The reporting module 318 can also be configured to present data stored in the database 312 included in the fault detection module 302. For example, the reporting module 318 can display failed or successful probes and probing instructions or paths associated with probes. The reporting module 318 can include a user interface which allows the human user interactions with the fault detection system).
Segalov in view of Indiresan doesn’t explicitly disclose wherein the instructions to send the modified packets through the data path comprise instructions to send the modified packets through the data path in kernel space.
However, Ball discloses wherein the instructions to send the modified packets through the data path comprise instructions to send the modified packets through the data path in kernel space (See Parag. [0065]; Data path 313 module of kernel space 312 may configure a flow action of the policy for the forward packet flow to forward packets originating from the application workload running on VM 310A. Data path 313 module of kernel space 312 may also perform a lookup of the forwarding information in FIB 324A with an L3 address (e.g., destination IP address) of packet 316, e.g., either with an exact match or a longest prefix match (LPM), to determine the next hop and configures the next hop for the forward packet flow within flow table 326A).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify sending the packets through the subset of the plurality of nodes, taught by Segalov in view of Indiresan, to comprise sending the modified packets through the data path in kernel space, as taught by Ball. This would be convenient for providing automatic policy configuration for packet flows; a computing device may automatically configure policy flows with a kernel of the computing device without sending packets to the user space of the computing device (Ball, Parag. [0005]).
Claim 18 is taught by Segalov in view of Indiresan and Ball as described for claim 12.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Dinh et al. (Pub. No. US 2022/0237500) – Related art in the area of detecting or locating defective hardware or software using an automated test suite, (Abstract; A system and method reorder execution of a test suite to be performed on a given device according to an initial testing order. Each testing sequence in the test suite is analyzed for dependencies between test cases, and these dependencies are recorded in directed graphs. Next, a machine learning algorithm, such as the random forest algorithm, is trained on multi-dimensional historical testing data according to several testing parameters to predict success or failure of any given test. The trained algorithm is used to predict, for a given device under test, which of the test cases are likely to fail, and to compute a confidence value for each such prediction. The directed graphs then are reorganized so that graphs containing tests most likely to fail are executed early in the test suite, according to a modified testing order that accounts for both test dependencies and the confidence values).
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 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, Oscar Louie can be reached on 571-270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights