DETAILED ACTION
This Office Action is in response to Applicant’s Arguments /Remarks filed on 08/13/2025.
In the instant Amendment, claims 1, 10 and 19 are independent claims. Claims 1-20 have been examined and are pending. This Action is made FINAL.
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 .
Response to Arguments
Applicant’s arguments in the instant Amendment, filed on *, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: Hares does not disclose: “receiving, from a third node of a third AS, a first BGP update message comprising a FlowSpec AS authorization list indicating autonomous systems (ASes) that are authorized to issue FlowSpecs for a prefix of the third AS”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Hares does disclose ‘receiving, from a third node of a third AS, a first BGP update message comprising a FlowSpec AS authorization list indicating autonomous systems (ASes) that are authorized to issue FlowSpecs for a prefix of the third AS’ (sec. 4.2., Using ROA to validate BGP Flow Specification: Since [REC5575] BGP Route Origin validation [RFC6432] has been standardized, and the BGPSEC protocol [i-R.jetf-sidr-bepsec-pratecat | has been developed. This document proposes that an action be created in both the proposals that has precedence over all other actions. [I-D.eddy-idr-flowspec-exp] specifies cryptographic enhancements that include:
creating a BGP identifier (in BGP attribute or in BGPSEC signature) , Expanding BGPSEC coverage for Route Orgination Authorization (ROA) to
cover the orignator of the BGP Flow specification for the BGP Flow specification SAFIs.
Covering the BGP Extended Communities with BGP signature.
While this work is interesting, the authors of [E-B.eddv-idr-flowspec-exp]
consider it research into the use of BGP security. Therefore, this proposal suggests this addition be covered as an expansion to the ROA process. As this solitifies the ROA- action should be updated to include this functionality.).
Examiner, however, in light of the above submission maintains the previous rejections while considering the amendments to the claims as follows:
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by NPL Hares et al. (hereinafter Hares), “The Information Model for Basic Network Plicy and Filter Rules draft-hares-idr-flowspec-combo-01.txt”, March 16, 2016.
Referring to claim 1, Hanes teaches a method performed by a first node of a first autonomous system (AS) for verifying that a second node of a second AS is authorized to issue a Border Gateway Protocol (BGP) flow specification (FlowSpec) (sec. 4.2., use of ROA to validate BGP FlowSspec), the method comprising:
receiving, from a third node of a third AS, a first BGP update message comprising a FlowSpec AS authorization list indicating autonomous systems (ASes) that are authorized to issue FlowSpecs for a prefix of the third AS (sec. 4.2, the use of ROA and FlowSpec);
receiving, from the second node of the second AS, a second BGP update message comprising a FlowSpec associated with the prefix of the third AS (sec. 4.2, the use of ROA and FlowSpec);
determining that the second AS is authorized to issue the FlowSpec when the FlowSpec AS authorization list includes the second AS; determining whether the second AS is a closest neighboring AS to the first AS along a best-match unicast route for a destination prefix; accepting the FlowSpec when the second AS is the closest neighboring AS to the first AS along the best-match unicast route for the destination prefix and the second AS is authorized to issue the FlowSpec (sec. 5.2, “The BGP peers determine that a BGP Flow specification is valid if and only if one of the following cases:
o If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in
destination address match filter and the following is true:
* A BGP ROA has been received to validate the originator, and
* the route is the best-match unicast route for the destination
prefix embedded in the match filter; or
o If a BGP ROA has not been received that matches the IPv4 or IPv6
destination address in the destination filter, the match filter
must abide by the [RFC5575] validation rules of:
* The originator match of the flow specification matches the
originator of the best-match unicast route for the destination
prefix filter embedded in the flow specification", and
* No more specific unicast routes exist when compared with the
flow destination prefix that have been received from a
different neighboring AS than the best-match unicast route,
which has been determined in step A. The best match is defined to be the longest-match NLRI with the highest preference.”); and
performing a traffic flow action associated with the FlowSpec when the first node receives traffic that matches a set of traffic parameters specified by the FlowSpec (sec. 5.3, traffic actions related to match conditions of a flow specification policy).
Referring to claim 2, Hanes further teaches comprising rejecting the FlowSpec when the FlowSpec AS authorization list does not include the second AS (sec. 5.2, new validation rules).
Referring to claim 3, Hanes further teaches comprising rejecting the FlowSpec when the second AS is not the closest neighboring AS to the first AS along the best-match unicast route for a destination prefix (sec. 5.2).
Referring to claim 4, Hanes further teaches wherein the FlowSpec AS authorization list is specified in a BGP FlowSpec trust list path attribute included in a path attributes portion of the first BGP update message (sec. 5.2; 6.1, use of TLV).
Referring to claim 5, Hanes further teaches wherein the BGP FlowSpec trust list path attribute is an optional transitive BGP path attribute message (sec. 5.2; 6.1, use of TLV).
Referring to claim 6, Hanes further teaches wherein the BGP FlowSpec trust list path attribute is encoded using a Flowspec Trust List Type-Length-Value (TLV) encoding format, and wherein a value field of the Flowspec Trust List TLV list the ASes in the FlowSpec AS authorization list (sec. 5.2; 6.1, use of TLV).
Referring to claim 7, Hanes further teaches wherein determining whether the second AS is the closest neighboring AS to the first AS along the best-match unicast route for the destination prefix comprises determining whether the second AS is both in a left-most position of an AS_PATH attribute of a Flowspec route received via an External Border Gateway Protocol (eBGP) and in the left-most position of the AS_PATH attribute of the best-match unicast route for the destination prefix embedded in the Flowspec (sec. 4.0, “ This set of validation requirements also require that BGP implementations are required to enforce the AS_PATH attribute having the neighbor AS in the left-most position.”).
Referring to claim 8, Hanes further teaches wherein determining whether the second AS is closest neighboring AS to the first AS along the best-match unicast route for the destination prefix comprises using a secured AS path list that is part of a routing table of the first node (sec. 4.3, “The use of bgpsec protocol to validate the AS Path is orthongonal to the validation of the prefix to origin AS. Therefore, local configuration can determine if the bgpsec protocol is supported and required to validate the AS Path checked for the set of peers using BGP Flow Specification. If bgpsec is configured to be used, the BGP FLOW Specification SHOULD use the secured AS Path for its validation checks.“).
Referring to claim 9, Hanes further teaches comprising obtaining the secured AS path list using BGP security (BGPsec) (sec. 4.3).
Referring to claim 10, This claim is similar in scope to claim 1, and is therefore rejected under similar rationale.
Referring to claim 11, This claim is similar in scope to claim 2, and is therefore rejected under similar rationale.
Referring to claim 12, This claim is similar in scope to claim 3, and is therefore rejected under similar rationale.
Referring to claim 13, This claim is similar in scope to claim 4, and is therefore rejected under similar rationale.
Referring to claim 14, This claim is similar in scope to claim 5, and is therefore rejected under similar rationale.
Referring to claim 15, This claim is similar in scope to claim 6, and is therefore rejected under similar rationale.
Referring to claim 16, This claim is similar in scope to claim 7, and is therefore rejected under similar rationale.
Referring to claim 17, This claim is similar in scope to claim 8, and is therefore rejected under similar rationale.
Referring to claim 18, This claim is similar in scope to claim 9, and is therefore rejected under similar rationale.
Referring to claim 19, This claim is similar in scope to claims 1 and 2, and is therefore rejected under similar rationale.
Referring to claim 20, This claim is similar in scope to claim 4, and is therefore rejected under similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see the attached PTO-892.
THIS ACTION IS MADE FINAL. 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 YONAS A BAYOU whose telephone number is (571)272-7610. The examiner can normally be reached Monday-Friday 7AM-4PM.
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, Philip Chea can be reached at 571-272-3951. 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.
/YONAS A BAYOU/Primary Examiner, Art Unit 2499 10/07/2025