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 .
Claim status in the amendment received on 3/23/2026:
Claims 1, 6-8, 13-14 and 20 have been amended.
Claim 12 has been canceled.
Claims 1-2, 4-9, 11, 13-15 and 17-23 are pending.
Response to Amendments
Applicant’s amendments have been considered and in response to the amendments:
The previous 112(b) rejections have been withdrawn.
Response to Arguments
Applicant’s arguments have been considered but they are not persuasive.
The new amendments are addressed in the following rejections below.
With respect to the argument that Munukutla does not teach or suggest the control plane because the traffic monitor (fig. 2, 114), which is mapped to a control plane, identified by Munukutla in a context of data plane for forwarding traffic. However, the examiner respectfully traverses.
When referring to the specification for a control plane we find that the specification does not explicitly define or limit the control plane.
“[0030] In one or more embodiments disclosed herein, the packet processor (136) obtains packets that meet a lifecycle-ending condition from the hardware layer (140) and process such packets to obtain packet drop information. The packet processor (136) may operate on the control plane of the network device (130). The control plane may be further used to perform routing processing to generate forwarding tables. The forwarding tables may be provided to the hardware layer (140). The packets may be processed by the packet processor (136) in accordance with FIG. 2B.” [Emphasis Added].
Therefore, giving the term “control plane” the broadest reasonable interpretation in the light of specification, control plane is a place within the network device that performs packet controlling, processing and/or routing.
Similarly, the packet monitor, as taught by Munukutla, meets the example, shown above, provided by the applicant, mainly a place within the network device that performs packet controlling/processing and/or routing. Additionally, the traffic monitor is used specifically to extract packet information of a dropped packet and send the information to a network controller.
With respect to other arguments not addressed here, the arguments are similar in essence to previously presented arguments in the latest appeal brief, please refer to the examiner answer dated 5/8/2024.
Therefore, the prior art rejections are maintained.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 8-9, 11, 13-15 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Munukutla et al. (Pub. No.: US 20210328939 A1).
As to claim 8, Munukutla teaches a network device (fig. 4, 406), comprising:
a hardware layer for forwarding network traffic, wherein the hardware layer is programmed on an ingress side of the hardware layer (paragraph [0035], “…PFEs 202 each include hardware and/or software forwarding units (FUs) 214 that examine the contents of each packet (or another packet property, e.g., incoming interface) to make forwarding decisions, apply filters, and/or perform accounting, management, traffic analysis, and/or load balancing…”) to:
receive a probing packet, the probing packet comprising a header (fig. 4, 404);
make a determination prior to forwarding the probing packet to any egress interface that the probing packet meets a lifecycle-ending condition (paragraph [0020], “expired TTL” teaches lifecycle-ending condition, “Packets can get dropped inside a network device because of various reasons. This includes packet lookup pointing to discard function, expired TTL” teaches the determination is made prior to forwarding to any egress because it was dropped inside the network device); and
provide, in response to the determination, the probing packet to a packet processor of the network device (fig. 5, 504) prior to the network device resolving an egress interface of the first network device for the probing packet and without the network device determining a next hop indicator for the probing packet prior to providing the probing packet to the packet processor (paragraph [0050], i.e. the packet is forwarded to the traffic monitor prior to resolving the egress interface because the traffic monitor inspects the packet for additional information including egress interface, also see paragraph [0019] and Table 2);
a control plane comprising a packet processor (fig. 2, 114, i.e. traffic monitor), wherein the packet processor is programmed to:
obtain the probing packet (fig. 5, 504);
perform a packet analysis on the probing packet to obtain packet information for optimizing network paths (paragraph [0019], “…As described below, network devices include a traffic monitor that inspects (e.g., samples, etc.) dropped packets and forwards dropped packet metadata to a monitor service”, i.e. inspection and extracting metadata of dropped packet teaches performing packet analysis on the probing packet, and fig. 5, 506, and paragraph [0051], i.e. that the information, received by the controller, after packet inspection are used to trigger an automatic remedial action on a component on the flow path, thus “optimizing network paths”), the packet analysis including analyzing the header of the probing packet to determine the egress interface for the probing packet, wherein the egress interface for the probing packet is on a path to an ingress interface of the destination network device (paragraph [0019], “…direction (ingress/egress), input interface, and/or output interface on which this packet was flowing…”) and
based on the packet analysis, provide the packet information to a network monitoring manager (fig. 5, 510).
Although Munukutla teaches identifying the egress interface of the probing packet, which implicitly requires a routing table lookup, Munukutla does not explicitly teach how the egress interface is identified during the packet analysis.
However, Munukutla further teaches a routing table lookup process, which mainly teaches resolving a destination address specified in the header to an egress interface of the network device for the probing packet paragraph [0005], “…maps packet key information (e.g., destination information and other select information from a packet header) to one or more specific next hop network devices and ultimately to one or more specific output interfaces of interface cards of the network device…”);
including analyzing the header of the probing packet to determine the destination address specified in the header, determining a destination network device corresponding to the specified destination address, and determining the egress interface for the probing packet, wherein the egress interface for the probing packet is on a path to an ingress interface of the destination network device paragraph [0005], “…For example, to generate a route table lookup forwarding entry, the control unit selects routes defined by the network topology and maps packet key information (e.g., destination information and other select information from a packet header) to one or more specific next hop network devices and ultimately to one or more specific output interfaces of interface cards of the network device…”).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the routing table lookup process with the analyzing the header of the probing packet in order to accurately identify the egress interface.
As to claim 9, Munukutla teaches wherein the lifecycle-ending condition comprises a time-to- live (TTL) value (paragraph [0020], “…expired TTL…”).
As to claim 11, Munukutla teaches wherein the probing packet travels along a designated network path (paragraph [0008], “a forwarding path being taken by the transit packet experiencing the exception”).
As to claim 13, Munukutla teaches wherein the packet information specifies the egress interface for the probing packet (paragraph [0019], “…direction (ingress/egress), input interface, and/or output interface on which this packet was flowing…”).
As to claim 14, Munukutla teaches a method for managing a network, the method comprising: performing, by a first network device, a packet analysis on a probing packet to determine information for optimizing network paths, including determining an egress interface of the first network device for the probing packet, wherein the egress interface for the probing packet is one from which the probing packet would have been transmitted (fig. 5, 506, and paragraph [0051], i.e. that the information, received by the controller, after packet inspection are used to trigger an automatic remedial action on a component on the flow path, thus “optimizing network paths”) and paragraph [0019], “…direction (ingress/egress), input interface, and/or output interface on which this packet was flowing…”),
wherein the probing packet meets a lifecycle-ending condition prior to forwarding the probing packet to any egress interface of the first network device (paragraph [0020], “expired TTL” teaches lifecycle-ending condition, “Packets can get dropped inside a network device because of various reasons. This includes packet lookup pointing to discard function, expired TTL” teaches the determination is made prior to forwarding to any egress because it was dropped inside the network device), wherein the probing packet is not transmitted out of the egress interface for the probing packet, wherein the packet analysis is performed in a control plane of the first network device when the probing packet meets the lifecycle-ending condition (paragraph [0019], “…direction (ingress/egress), input interface, and/or output interface on which this packet was flowing…”);
wherein a determination that the probing packet meets the lifecycle-ending condition is made in an ingress side of a hardware layer that forwards network traffic (paragraph [0035], “…PFEs 202 each include hardware and/or software forwarding units (FUs) 214 that examine the contents of each packet (or another packet property, e.g., incoming interface) to make forwarding decisions…”) and wherein the control plane obtains the probing packet from the hardware layer without the first network device determining the egress interface for the probing packet and a next hop indicator the probing packet prior to the control plane obtaining the probing packet (paragraph [0037], “…The dropped packet is forwarded to the traffic monitor 114…”, the egress interface is determined later by the traffic monitor, see Table 2) ; and
based on the packet analysis, sending a notification to a network monitoring manager, wherein the notification specifies header information of the probing packet and the egress interface for the probing packet (paragraph [0021], i.e. sending exception packet to a collector).
Although Munukutla teaches identifying the egress interface of the probing packet, which implicitly requires a routing table lookup, Munukutla does not explicitly teach how the egress interface is identified during the packet analysis.
However, Munukutla further teaches a routing table lookup process, which mainly teaches packet analysis including analyzing a header of the probing packet to determine a destination address specified in the header, determining a destination network device corresponding to the specified destination address, and determining which egress interface is on a path to an ingress interface of the destination network device paragraph [0005], “…For example, to generate a route table lookup forwarding entry, the control unit selects routes defined by the network topology and maps packet key information (e.g., destination information and other select information from a packet header) to one or more specific next hop network devices and ultimately to one or more specific output interfaces of interface cards of the network device…”).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the routing table lookup process with the analyzing the header of the probing packet in order to accurately identify the egress interface.
As to claim 15, Munukutla teaches wherein the lifecycle-ending condition comprises a time-to-live (TTL) value of 0 or 1 (paragraph [0020], “…expired TTL…”).
As to claim 17, Munukutla teaches wherein the probing packet travels along a designated network path (paragraph [0008], “a forwarding path being taken by the transit packet experiencing the exception”).
As to claim 18, Munukutla teaches wherein the network monitoring manager updates the designated network path after obtaining the notification (paragraph [0051], “…the occurrence of one or more faults may trigger an automatic remedial action, such as causing the network device to check the consistency of its forwarding table…”).
As to claim 19, Munukutla teaches wherein the network monitoring manager stores an identifier of the egress interface in a database (paragraph [0021],”…The collector collects and analyzes the exception packet for a pattern indicative of an issue…”).
As to claim 20, Munukutla teaches wherein the notification further specifies the ingress interface (paragraph [0019], “…direction (ingress/egress), input interface, and/or output interface on which this packet was flowing…”).
Claim(s) 1-2 and 4-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Munukutla et al. (Pub. No.: US 20210328939 A1) in view of Guilbaud et al. (Pub. No.: US 20140003224 A1).
As to claim 1, Munukutla teaches a method for managing a network, the method comprising: generating a probing packet by a network device in the network, the probing packet configured to traverse a network path that includes a predetermined set of network devices (paragraph [0049], i.e. the packet “402” is generated by a network device);
at a first network device, in an ingress processing side of a hardware layer for forwarding network traffic (paragraph [0035], “…PFEs 202 each include hardware and/or software forwarding units (FUs) 214 that examine the contents of each packet (or another packet property, e.g., incoming interface) to make forwarding decisions…”), making a determination prior to forwarding the probing packet to any egress interface of the first network device that the probing packet meets a lifecycle-ending condition (paragraph [0020], “expired TTL” teaches lifecycle-ending condition, “Packets can get dropped inside a network device because of various reasons. This includes packet lookup pointing to discard function, expired TTL” teaches the determination is made prior to forwarding to any egress because it was dropped inside the network device),
wherein when the probing packet meets the lifecycle-ending condition the probing packet is not forwarded from the first network device towards a second network device associated with an internet protocol (IP) address in a header of the probing packet (paragraph [0020], “…expired TTL…”);
based on the determination, transmitting the probing packet to a control plane of the first network device prior to the first network device resolving the an egress interface of the first network device for the probing packet and without the first network device determining a next hop indicator for the probing packet prior to transmitting the probing packet to the control plane (paragraph [0050], i.e. the packet is forwarded to the traffic monitor prior to resolving the egress interface because the traffic monitor inspects the packet for egress interface, also see paragraph [0019] and Table 2);
performing, by the control plane of the first network device, a packet analysis on the probing packet to determine information for optimizing network paths, the packet analysis including analyzing the header of the probing packet to determining the egress interface for the probing packet, wherein the egress interface for the probing packet is on a path to an ingress interface of the second network device (paragraph [0019], “…direction (ingress/egress), input interface, and/or output interface on which this packet was flowing…”);and
based on the packet analysis, sending a notification to a network monitoring manager, wherein the notification specifies the egress interface for the probing packet (paragraph [0021], i.e. sending exception packet to a collector).
Although Munukutla teaches identifying the egress interface of the probing packet, which implicitly requires a routing table lookup, Munukutla does not explicitly teach how the egress interface is identified during the packet analysis and the probing packet is generated and returned to a network monitoring manager.
However, Munukutla further teaches a routing table lookup process, which mainly teaches resolving the IP address specified in the header to an egress interface of the first network device for the probing packet (paragraph [0005], “…maps packet key information (e.g., destination information and other select information from a packet header) to one or more specific next hop network devices and ultimately to one or more specific output interfaces of interface cards of the network device…”);
packet analysis including analyzing the header of the probing packet to determine the IP address specified in the header, determining the second network device corresponding to the specified IP address, and determining the egress interface for the probing packet, wherein the egress interface for the probing packet is on a path to an ingress interface of the second network device (paragraph [0005], “…For example, to generate a route table lookup forwarding entry, the control unit selects routes defined by the network topology and maps packet key information (e.g., destination information and other select information from a packet header) to one or more specific next hop network devices and ultimately to one or more specific output interfaces of interface cards of the network device…”).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the routing table lookup process with the analyzing the header of the probing packet in order to accurately identify the egress interface.
Munukutla does not explicitly teach the probing packet is generated and returned to a network monitoring manager.
However, in the same field of endeavor (network monitoring) Guilbaud teaches generating a probing packet by a network monitoring manager in the network, the probing packet configured to traverse a network path that includes a predetermined set of network devices and return to the network monitoring manager (paragraph [0025], “An example probe sent along a defined path is illustrated in FIG. 1 by a source device…”).
Based on Munukutla in view of Guilbaud, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate probing packet is generated and returned to a network monitoring manager (taught by Guilbaud) with routing table lookup process and monitoring network by a network manager (taught by Munukutla) in order to accurately identify the egress interface and in order to deterministically identifying a network problem using probes that follow predetermined paths through a network as motivated by Guilbaud (paragraph [0027]).
As to claim 2, Munukutla teaches wherein the lifecycle-ending condition comprises a time-to-live (TTL) value of the probing packet (paragraph [0020]).
As to claim 4, Munukutla teaches wherein the probing packet travels along a designated network path (paragraph [0008], “a forwarding path being taken by the transit packet experiencing the exception”).
As to claim 5, Munukutla teaches wherein the network monitoring manager updates the designated network path after obtaining the notification (paragraph [0051], “…the occurrence of one or more faults may trigger an automatic remedial action, such as causing the network device to check the consistency of its forwarding table…”).
As to claim 6, Munukutla teaches wherein the network monitoring manager stores an identifier of the egress interface for the probing packet in a database (paragraph [0021],”…The collector collects and analyzes the exception packet for a pattern indicative of an issue…”).
As to claim 7, Munukutla teaches wherein the packet analysis is performed by a packet processor executing on the control plane of the first network device (paragraph [0019], “network devices include a traffic monitor that inspects (e.g., samples, etc.) dropped packets…”).
Claim(s) 22-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Munukutla et al. (Pub. No.: US 20210328939 A1) in view of Gu et al. (Pub. No.: US 20210250295 A1).
As to claim 22, Munukutla further teaches wherein the packet analysis obtains packet information associated with causation of a network condition traversed by the probing packet (paragraph [0019], “…As described below, network devices include a traffic monitor that inspects (e.g., samples, etc.) dropped packets and forwards dropped packet metadata to a monitor service…”).
Munukutla does not explicitly teach a network loop condition.
However, in the same field of endeavor (computer networks) Gu teaches packet analysis obtains packet information associated with causation of a network loop traversed by the probing packet (paragraph [0184],”…After the loop occurs, the loop is found (for example, when a time to live (time to live, TTL) expires, the loop is reported)…” ).
Based on Munukutla in view of Gu, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate obtaining information associated with causation of a network loop (taught by Gu) with the routing table lookup process with the analyzing the header of the probing packet in order to accurately identify the egress interface and in order to detect network loops as motivated by Gu (paragraph [0184]).
As to claim 23, the claim limitations are substantially similar to claim 22. Please refer to claim 22 above.
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Munukutla et al. (Pub. No.: US 20210328939 A1) in view of Guilbaud et al. (Pub. No.: US 20140003224 A1) and further in view of Gu et al. (Pub. No.: US 20210250295 A1).
As to claim 21, Munukutla further teaches wherein the packet analysis obtains packet information associated with causation of a network condition traversed by the probing packet (paragraph [0019], “…As described below, network devices include a traffic monitor that inspects (e.g., samples, etc.) dropped packets and forwards dropped packet metadata to a monitor service…”).
Munukutla in view of Guilbaud does not explicitly teach a network loop condition.
However, in the same field of endeavor (computer networks) Gu teaches packet analysis obtains packet information associated with causation of a network loop traversed by the probing packet (paragraph [0184],”…After the loop occurs, the loop is found (for example, when a time to live (time to live, TTL) expires, the loop is reported)…” ).
Based on Munukutla in view of Guilbaud and further in view of Gu, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate obtaining information associated with causation of a network loop (taught by Gu) with probing packet is generated and returned to a network monitoring manager (taught by Guilbaud) with routing table lookup process and monitoring network by a network manager (taught by Munukutla) in order to accurately identify the egress interface and in order to deterministically identifying a network problem using probes that follow predetermined paths through a network as motivated by Guilbaud (paragraph [0027]) and in order to detect network loops as motivated by Gu (paragraph [0184]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULKADER M ALRIYASHI whose telephone number is (313)446-6551. The examiner can normally be reached Monday - Friday, 8AM - 5PM Alt, Friday, EST.
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, JOON HWANG can be reached at (571)272-4036. 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.
/Abdulkader M Alriyashi/Primary Examiner, Art Unit 2447 5/23/2026
Prosecution Insights