DETAILED ACTION
This communication is in response to Application No. 18/565,468 filed on 11/29/2023. The preliminary amendment presented on 8/16/2024, which amends claims 4-6, 11, and 13-17, is hereby acknowledged. Claims 1-17 have been examined.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/29/2023 and 5/29/2025 is being considered by the examiner.
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.
Claims 1-2, 5-11, and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over D’Souza et al. (hereinafter D’Souza)(US 2016/0241463) in view of Mitsumori (US 2015/0003230).
Regarding claims 1, 8, and 15, D’Souza teaches as follows:
A node device (interpreted as the network device (ND) 101 in figure 1), comprising a first memory, a first processor, and a computer program stored in the first memory and executable by the first processor, wherein when executing the computer program (An electronic device includes hardware and software, such as a set of one or more processors coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data… A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network, see, ¶ [0037]-[0038]), the first processor performs a path protection method (The methods include detecting the second network device is not operational, and in response to detecting the second network device is not operational, causing the FRR NH to switch from using the PNH for forwarding the IP traffic towards the second network device to using the SNH for forwarding the IP traffic towards the third network device, see, ¶ [0013]), wherein the path protection method comprises:
acquiring a primary path and at least one standby path (Each of routing clients 150-151 can be implemented as a Border Gateway Protocol (BGP) client, static route client, etc. Routing clients 150-151 are responsible for determining reachability and adding/removing/updating routes to RIB 153… RIB 153 includes FRR NH 111, which comprises primary next hop (PNH) 121 and secondary next hop (SNH) 122. PNH 121 includes forwarding information for causing IP traffic to be forwarded via a set of one or more primary paths, and SNH 122 includes forwarding information for causing IP traffic to be forwarded via a set of one or more backup paths (when the primary paths are down), see, ¶ [0041]-[0042] and figure 1); and
sending the primary path and the at least one standby path to a forwarding plane (When a new route is added for the first time, RIB 153 causes the route to be downloaded to forwarding plane 106, see, ¶ [0043] and figure 1) according to a preset path protection control policy, wherein in response to failure of the primary path, the forwarding plane switches a service to one standby path among the at least one standby path directly (FIB 156 causes FRR NH 112 to use PNH 131 for forwarding IP traffic associated with prefixes 134-135 (i.e., to use forwarding information included in PNH 131 for forwarding IP traffic associated with prefixes 134-135 towards network device 102 via primary paths 120-121 (equivalent to applicant’s primary path)). When there is a failure (e.g., network device 102 is down), FIB 156 causes FRR NH 112 to switch to SNH 132 (i.e., to start using the forwarding information included in SNH 132 for forwarding IP traffic associated with prefixes 134-135 towards network device 103 via backup path 123 (equivalent to applicant’s standby path)), see, ¶ [0046] and figure 1).
D’Souza does not teach the preset path protection control policy.
Mitsumori teaches as follows:
The received frame table 22 stores a destination side path protection flag (D-SIDE PROTECTION FLAG)(equivalent to applicant’s preset path protection control policy) and a source side path protection flag (S-SIDE PROTECTION FLAG)(see, ¶ [0065] and figure 7); and
the destination side path protection flag represents whether or not path protection is implemented for a logical path on the destination side. In this example, "1" represents a state where path protection is implemented, and "0" represents a state where path protection is not implemented (see, ¶ [0069]).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify D’Souza with Mitsumori to include the destination side path protection flag as taught by Mitsumori in order to efficiently preset whether the path protection is enabled or not.
Regarding claim 2, D’Souza teaches of acquiring at least two candidate paths and sending the primary path and the standby path to the forwarding plane as presented above.
Mitsumori teaches the path protection flag as follows:
The destination side path protection flag (equivalent to applicant’s path protection flag) represents whether or not path protection is implemented for a logical path on the destination side. In this example, "1" represents a state where path protection is implemented, and "0" represents a state where path protection is not implemented (see, ¶ [0069]).
Therefore, D’Souza in view of Mitsumori teaches all limitations as presented above.
Regarding claim 5, D’Souza teaches as follows:
In response to the failure of the primary path, configuring a standby path corresponding to a next priority of a priority of the primary path as the primary path (When there is a failure (e.g., network device 102 is down), FIB 156 causes FRR NH 112 to switch to SNH 132 (i.e., to start using the forwarding information included in SNH 132 for forwarding IP traffic associated with prefixes 134-135 towards network device 103 via backup path 123), see, ¶ [0046]); and
updating the primary path and the at least one standby path to the forwarding plane (FIB 156 generates and updates its FRR NHs based on FRR NH information downloaded from RIB 153, see, ¶ [0045]).
D’Souza also teaches the priority to select next path as follows:
Next hop selection by the routing system for a given destination may resolve to one path; but if the routing system determines there are multiple viable next hops, some additional criteria is used—for instance, in a connectionless network, Equal Cost Multi Path (ECMP) may be used (e.g., typical implementations use as the criteria particular header fields to ensure that the packets of a particular packet flow are always forwarded on the same next hop to preserve packet flow ordering)(see, ¶ [0139]).
Mitsumori teaches the state of a path protection flag as follows:
The destination side path protection flag represents whether or not path protection is implemented for a logical path on the destination side. In this example, "1" represents a state where path protection is implemented, and "0" represents a state where path protection is not implemented (see, ¶ [0069]).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify D’Souza in view of Mitsumori to include updating the primary and standby paths based on the predetermined path protection state of the primary path.
Regarding claims 6, 10, and 14, D’Souza teaches as follows:
Each of routing clients 150-151 can be implemented as a Border Gateway Protocol (BGP) client, static route client, etc. Routing clients 150-151 are responsible for determining reachability and adding/removing/updating routes to RIB 153 (see, ¶ [0041]); and
updating the primary path and the at least one standby path to the forwarding plane (FIB 156 generates and updates its FRR NHs based on FRR NH information downloaded from RIB 153 (see, ¶ [0045]).
The updating of removed routes is equivalent to applicant’s path deletion notification information.
Regarding claim 7, Mitsumori teaches the path protection control policy (interpreted as the destination side path protection) as follows:
The received frame table 22 stores a destination side path protection flag (D-SIDE PROTECTION FLAG)(equivalent to applicant’s preset path protection control policy) and a source side path protection flag (S-SIDE PROTECTION FLAG)(see, ¶ [0065] and figure 7).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify D’Souza in view of Mitsumori to include specifying the destination side path protection flag as a local control policy being applied for local data routing.
Regarding claim 9, D’Souza in view of Mitsumori teaches similar limitations as presented above in the rejection of claims 5 and 6.
Regarding claim 11, D’Souza in view of Mitsumori teaches similar limitations as presented above in the rejection of claims 1 and 2.
Regarding claim 16, D’Souza further teaches as follows:
An electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data (see, ¶ [0037]).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify D’Souza in view of Mitsumori to include multiple processors and multiple memories in order to efficiently designate for the control plane and the forwarding plane respectively.
Regarding claim 17, D’Souza further teaches the non-transitory computer-readable storage medium as follows:
These electronic device(s) would similarly include compute resource(s), a set or one or more physical NICs, and a non-transitory machine-readable storage medium having stored thereon the centralized control plane software (see, ¶ [0130]).
Therefore, D’Souza in view of Mitsumori teaches all limitations as presented above in the rejection of claim 1.
Claims 3-4 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over D’Souza et al. (hereinafter D’Souza)(US 2016/0241463) in view of Mitsumori (US 2015/0003230), and further in view of Kondreddy et al. (hereinafter Kondreddy)(US 2020/0304402).
Regarding claims 3-4 and 12-13, D’Souza in view of Mitsumori teaches all limitations as presented above except for the type-length-value (TLV) field of the path computation element communication protocol (PCEP).
Kondreddy teaches as follows:
The path computation element communication protocol (PCEP) message includes a Label Switch Path Attributes (LSPA) object field including one or more characteristics associated with the level of protection of the Protection LSP. The PCEP message field includes a TLV field, wherein the V field of the TLV field includes an array of units of flags numbered from the least significant bit, where each bit represents the one or more characteristics associated with the level of protection of the protection LSP (see, ¶ [0097]).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify D’Souza in view of Mitsumori with Kondreddy to include the PCEP message as taught by Kondreddy in order to efficiently carry the level of protection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jeong S Park whose telephone number is (571)270-1597. The examiner can normally be reached Monday through Friday 8:00-4:30 ET.
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, Glenton B Burgess can be reached at 571-272-3949. 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.
/JEONG S PARK/Primary Examiner, Art Unit 2454
November 21, 2025