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 10/20/2023:
Claims 1, 8 and 14 have been amended.
Claims 1-2, 4-9, 11-15 and 17-23 are pending.
Response to Arguments
Applicant's arguments filed in the amendment received on 10/20/2023 have been fully considered but they are not persuasive.
With respect to the limitation “make a determination prior to forwarding the probing packet to any egress interface that the probing packet meets a lifecycle-ending condition”, the Munukutla reference teaches (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).
With respect to the limitation “perform a packet analysis on the probing packet” the Munukutla reference teaches (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. inspecting and extracting metadata of dropped packet teaches performing packet analysis on the probing packet).
With respect to the limitation “analyzing the 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”. Munukutla teaches analyzing the header of the probing packet and identifying the corresponding egress interface, identifying an egress interface requires a routing table lookup which is mainly network address maps to next hop (destination device) maps to the egress (output) interface. The examiner also respectfully directs the applicant’s attention that the limitation is rejected based on an obviousness rational of performing those steps (typical forwarding table lookup) in order to find an egress of the packet.
With respect to the limitation “packet analysis obtains packet information associated with causation of a network loop traversed by the probing packet”
Gu teaches (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)…” ). The reported information teaches packet information associated with the causation of a network loop.
Therefore, the prior art rejections are maintained.
Claim Objections
Claim 15 is objected to because of the following informalities.
As to claim 15, there are multiple antecedent basis for “the lifecycle-ending condition” found in the parent claim 14. Appropriate correction is required.
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-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, wherein the hardware layer is programmed to:
receive a probing packet (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 determination, the probing packet to a packet processor of the network device (fig. 5, 504);
a packet processor, 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 which egress interface is on a path to an ingress interface of a 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 analyzing the 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 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 12, Munukutla teaches wherein the packet analysis is performed by a packet processor of the network device (paragraph [0019], “network devices include a traffic monitor that inspects (e.g., samples, etc.) dropped packets…”).
As to claim 13, Munukutla teaches wherein the packet information comprises an egress interface of the network device from which the probing packet would have been transmitted (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 network device, a packet analysis on a probing packet to determine information for optimizing network paths, including determining an egress interface of the network device 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 (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, wherein the packet analysis is performed in a control plane of the network device when the probing packet meets a lifecycle-ending condition (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 header information of the probing packet and the egress interface (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 the 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 comprises an 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);
making 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),
wherein when the probing packet meets the lifecycle-ending condition the probing packet is not forwarded from a 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, performing, by 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 determine which egress interface 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 (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 packet analysis including analyzing the header of the probing packet to determine an address specified in the header, determining a the second network device corresponding to the specified address, and determining which egress interface 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 returning 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 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 a control plane of the 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 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 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 on (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 11/6/2023