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 communications file on 12/29/2023. Claims 1-20 have been examined and are pending
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Peng et al (US 2025/0007816 A1), in view of RAO, D et al: "BGP Color-Aware Routing (CAR) draft-ietf-idr-bgpcar-00 ;draft-ietf-idr-bgp-car-00.txt", IETF 29 August, 2022 (cited by Applicant in 03/12/25 IDS)
Re: Claim 1, Peng teaches a method, comprising:
receiving, by a border gateway protocol (BGP) network device (Peng: FIG 7, Receiving module 702), from an originator BGP network device (Peng: FIG5, speaker PE2 ; FIG 6, speakers PE2, PE3) via a first other BGP network device, a first message (Peng: [0008] “The method for receiving BGP-intent route includes: receiving the BGP-intent route advertised by a BGP speaker …”; where [0003] “BGP-intent route” refers to a BGP route that carries “intent information”)
wherein the first message includes first attribute data associated with a nontransitive attribute (Peng: [0008] “BGP-intent route carries at least one of the following: a metric type, a metric and metric credit information; [0056] The metric type attribute is an optional non-transitive attribute, configured to indicate a type of metric included in the AIGP Attribute; [0063] The metric credit attribute is an optional non-transitive attribute, and configured to indicate end-to-end information…”)
wherein the first attribute data comprises a first metric data element that is associated with a metric data element format and that indicates a metric type, [and] a metric value; (Peng: [0056]; [0064] ref FIG 4)
processing, by the BGP network device, the first message to determine first path information associated with a first path from the BGP network device to the originator BGP network device via the first other BGP network device. (Peng: [0102]-[0118] ref FIG 5: esp.: [0103]: “… two paths with related intents between the same source/destination [(PE1,PE2)] … configure two colors (color-1000 and color-2000) on Egress PE2”, [0112] – [0113] ref FIG 5, TE path-12; [0116] ref FIG 5, TE path-11; [0131]-[0151] ref FIG 6: esp. [0132] “the same type of service is to be communicated between the Ingress PE1 and the Egress PE2, and between the Ingress PE1 and the Egress PE3”; [0141] – [0142] ref FIG 6, TE path-13; [0145]-[0146] ref FIG 6, TE path-12; [0149] ref FIG 6, TE path-11)
Peng does not explicitly teach:
(i) a first metric data element that is associated with … continuity information;
Rao teaches
(i) a first metric data element that is associated with … continuity information; (Rao: p.9 §2.6. “The Accumulated IGP (AIGP) Attribute is updated as the BGP CAR route propagates across the network. The value set … in the AIGP TLV corresponds to the metric associated with the underlying intent …. If BGP CAR routes traverse across a discontinuity in the transport path for a given intent … The discontinuity is also indicated to upstream nodes via a bit in the AIGP TLV”; p. 9-10 §2.8; p.46-47 §A.4 “color-aware paths between two PEs may … go through a transit domain that does not support CAR. Example[s] include… BGP-LU based multi-domain network …
[(FIG A.1)]
PNG
media_image1.png
83
446
media_image1.png
Greyscale
BR1 and BR4 … form direct BGP-LU sessions to BR2 and BR3 respectively, to establish labeled paths between each other through the BGP-LU network …BR1 signals the transport discontinuity to E1 via the AIGP TLV, so that E1 can prefer other paths if available; BR4 does the same in the reverse direction”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Rao re: determining AIGP attributes of end-to-end paths for an intent across multiple domains, including signalling of discontinuities (Rao: p.9 §2.6; p. 9-10 §2.8; §A.1; p.46-47 §A.4), with those of Peng re: establishing end-to-end routes for an intent (Peng: [0004]; [0076]-[0086] Embodiment 1; [0087]-[0100] Embodiment 2) according to AIGP attributes (Peng:[0079]; [0090]) in which “contents carried in the BGP-intent route decrease efficiency of establishment of the transmission path” (Peng: [0005]) in order to more effectively establish such paths, in particular where “paths between two [endpoints] … go through a transit domain that does not support CAR”, by providing the ability to select alternative paths (Rao: p.47)
Claim 9 does not teach or define any new limitations above claim 1 insofar as it simply recites a device for performing the associated message generating and sending (advertising) operations corresponding to the receiving operation performed by the device of claim 1 (Peng: [0099] “… the BGP-intent route [is] generated on the current BGP Speaker, [0100] “… the current BGP Speaker may continue to advertise the BGP-intent route generated to upstream BGP Speaker neighbors and change a BGP Next-hop to itself. [0108], [0120] ref FIG 5, “Egress PE2 generates the BGP-intent route and advertises same to the ABR”). Therefore similar reasons for rejection apply.
Claim 16 does not teach or define any new limitations above claim 1 except the BGP network device: (i) updat[ing] the metric data element of the attribute data of the message; and (ii) send[ing] the message to another BGP network device However, Peng teaches: (i) updat[ing] the metric data element of the attribute data of the message; (Peng: [0099] “In the BGP-intent route generated on the current BGP Speaker, the metric type included is copied from the route advertisement received, and an attribute value of the metric included is updated to the metric included in the route advertisement received plus an accumulated metric of a corresponding metric type of the transmission path used; and (ii) send[ing] the message to another BGP network device. (Peng: [0100] “the current BGP Speaker may continue to advertise the BGP-intent route generated to upstream BGP Speaker neighbors and change a BGP Next-hop to itself. In this case, the route advertisement will carry the updated metric attribute and metric credit attribute.”). Therefore, similar reasons for rejection apply.
Claims 12 and 20 do not teach or define any new limitations above claim 1: “determin[ing] first path information associated with a first path from the BGP network device to the originator BGP network device via the first other BGP network device” (Peng: [0102]-[0118] ref FIG 5; [0131]-[0151] ref FIG 6) Therefore, similar reasons for rejection apply.
Re: Claim 2, Peng teaches the method of claim 1, wherein the non-transitive attribute is an accumulated interior gateway protocol (AIGP) attribute (Peng: [0008] “BGP-intent route carries at least one of the following: a metric type, a metric and metric credit information; [0054] The metric attribute is an accumulated interior gateway protocol (AIGP) attribute defined in RFC7311; [0079], [0090] “A variable metric_value is set as a value of the metric included in an AIGP Attribute of the BGP-intent route received”) and the metric data element format is a type-length-value (TLV) ([0056]; [0064] ref FIG 4)
Claims 10 and 17 do not teach or define any new limitations above claim 2. Therefore similar reasons for rejection apply.
Re: Claim 3, Peng teaches the method of claim 1, including wherein the non-transitive attribute is an accumulated interior gateway protocol (AIGP) attribute (Peng: [0054] The metric attribute is an accumulated interior gateway protocol (AIGP) attribute defined in RFC7311; [0079], [0090]) wherein the metric data element format is a type-length-value (TLV) (Peng: [0056]; [0064] ref FIG 4) and Rao teaches: wherein the continuity information of the first metric data element is a continuity bit that indicates, … when set to a second value, that at least one BGP network device along the first path does not support the non-transitive attribute and the metric data element as discussed re: Claim 1 (Rao: p.9 §2.6. “If BGP CAR routes traverse across a discontinuity in the transport path for a given intent … The discontinuity is also indicated to upstream nodes via a bit in the AIGP TLV”; p.47 §A.1 “transport discontinuity [signalled] via the AIGP TLV” when “color-aware paths between two PEs … go through a transit domain that does not support CAR”). Therefore similar reasons for rejection apply.
Claims 11, 15 and 18 do not teach or define any new limitations above claim 3 (Rao: p.9 §2.6; p.47 §A.1). Therefore similar reasons for rejection apply.
Re: Claim 4, Peng teaches the method of claim 1, wherein the first path information indicates an accumulated metric value for the metric type associated with the first path (Peng: [0047] “… a metric corresponding to the metric type [includes] an accumulated metric corresponding to a metric type of a transmission path from a current BGP speaker to the downstream neighbor BGP speaker”; and [0052] “an accumulated metric of a corresponding metric type of this transmission path [is] used”;) and whether the accumulated metric value is a full accumulated metric value or a partial accumulated metric value. (Peng: [0063] The metric credit attribute indicate[s] end-to-end information such as the total metric credit, the estimated BGP hops count and the metric credit piece where [0069] P-Flag: a piece flag, indicat[es] whether metric credit piece information (consisting of “Current Hop Number” and “Metric Credit Piece[ ]”) is included, with 0 indicating not includ[ed][(full)] and 1 indicating includ[ed][(partial)])
Re: Claim 5, Peng teaches the method of claim 1, further comprising:
determining, based on the first path information, a particular path from the BGP network device to the originator BGP network device. (Peng: [0036]; [0052]; [0159]-[0160]; [0102]-[0118] ref FIG 5, [0131]-[0151] ref FIG 6 as discussed re: Claim 1)
Claim 6 does not teach or define any new limitations above claim 1 inasmuch as it simply recites the same limitations as applied to a second path, and Peng teaches a second path (Peng: [0102]-[0118] ref FIG 5 esp. [0103]: “… two paths with related intents between the same source/destination [(PE1,PE2)] …. configure two colors (color-1000 and color-2000) on Egress PE2”, [0114] ref FIG 5, TE path-22”; [0117] ref FIG 5, TE path-21; [0131]-[0151] ref FIG 6, esp. [0132] “the same type of service is to be communicated between the Ingress PE1 and the Egress PE2, and between the Ingress PE1 and the Egress PE3”; [0143] – [0144] ref FIG 6, TE path-23; [0147]-[0148] ref FIG 6, TE path-22; [0150] ref FIG 6, TE path-21). Therefore similar reasons for rejection apply.
Claim 7 does not teach or define any new limitations above Claim 4 inasmuch as it simply recites the same limitation as Claim 4 applied to second path information and Peng teaches second path information as discussed re: Claim 6. Therefore similar reasons for rejection apply.
Re: Claim 8, Peng teaches the method of claim 6, further comprising:
selecting, based on the first path information and the second path information, one of the first path and the second path as a particular path from the BGP network device to the originator BGP network device (Peng: [0036]; [0052]; [0159]-[0160]; [0102]-[0118] ref FIG 5, [0131]-[0151] ref FIG 6 as discussed re: Claim 6)
Re: Claim 13, Peng teaches the BGP network device of claim 9, wherein sending the first message to the first other BGP network device allows the first other BGP network device to update the first metric data element of the first attribute data of the first message (Peng: [0099]-[0100])
Re: Claim 14, Peng teaches the BGP network device of claim 9, wherein the one or more processors are further configured to:
generate a second message that includes second attribute data associated with the non-transitive attribute, (Peng: [0099]-[0100] “… the BGP-intent route [is] generated on the current BGP Speaker .… the current BGP Speaker may continue to advertise the BGP-intent route generated to upstream BGP Speaker neighbors and change a BGP Next-hop to itself. [0108], [0120] ref FIG 5, “Egress PE2 generates the BGP-intent route and advertises same to the ABR”).
wherein the second attribute data comprises a second metric data element that is associated with the metric data element format; (Peng: [0056]; [0064] ref FIG 4) [and]
send the second message to a second other BGP network device. (Peng: [0099]-[0100] “… the BGP-intent route [is] generated on the current BGP Speaker .… the current BGP Speaker may continue to advertise the BGP-intent route generated to upstream BGP Speaker neighbors and change a BGP Next-hop to itself. [0108], [0120] ref FIG 5, “Egress PE2 generates the BGP-intent route and advertises same to the ABR”).
Re: Claim 19, Peng teaches the non-transitory computer-readable medium of claim 16, wherein the one or more instructions cause the BGP network device to update the metric data element of the attribute data of the message (Peng: [0099]-[0100]), as discussed re: claim 16 and Rao teaches updat[ing] at least the continuity information of the metric data element. as discussed re: claim 1 (Rao: p.9 §2.6. “The Accumulated IGP (AIGP) Attribute is updated as the BGP CAR route propagates across the network”). Therefore, similar reasons for rejection apply.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ansari et al (US 2017/0366444 A1) (Abstract: ‘scaled end-to-end view of link metrics to integrate multiple non-uniform IGP domains using AIGP’; [0024]; [0035]; [0041]-[0045],[0049]; [0055]-[0059]; [0064]-[0065]; [0068],[0070]-[0076]; FIGs 1,3,4
Chandrashekaran et al. (US 10,305,780 B1) (Abstract: “BGP updates to update the AIGP cost”; Col 1/ln 41-44; Col 3/ln 6-11, 14-19 39-55: RFC 7311; Col 3/ln 56 – col 4/ln 2, AIGP_SESSION; Col 4/ln 5-10, 32-35: AIGP_ORIGINATE; Col 4/ln 57-60, 62-65, Col 4/ln 66 – col 5/ln 5: distributing BGP updates with (new) AIGP values
Sivabalan et al (US 2023/0146374 A1) (Abstract: ‘incrementally eliminating BGP-LU in a multi-region network includes receiving BGP-LU updates from one or more Area Border Router (ABR) nodes in a multi-region network; [0004]-[0006]; [0012]; [0022]; [0026]; [0029]-0031])
Saad et al (US 2012/0069847 A1)(Abstract; [0019]; [0024]-[0026]; [0029]; [0032]; [0035]; [0038]; [0044]-[0045]; FIGs 1,3)
Wang et al (US 2025/0211516 A1) (Abstract; [0015]-[0017]; [0087])
Yadlapalli et al (US 2017/0034039 A1)(Abstract: “virtual route reflector”; [0021]; [0036]; [0062], [0068]-[0070]; [0073], [0079]-[0080]; FIGs. 1,2,3,6, 7)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT A SHAW whose telephone number is (571)270-5643. The examiner can normally be reached Monday-Friday 1pm-5pm.
Examiner interviews are available via telephone, 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, Emmanuel Moise can be reached at (571)272-3865. 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.
/ROBERT A SHAW/Examiner, Art Unit 2455
/EMMANUEL L MOISE/Supervisory Patent Examiner, Art Unit 2455
Prosecution Insights