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 .
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 12/11/2025 have been fully considered, and are persuasive. After further search and consideration of the amended claim language, new grounds of rejection are presently presented under 35 USC 112 and under 35 USC 103 based on the teachings of Patel (US-20120269198-A1).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), first paragraph:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3 – 8, 10- 15, and 17 – 23 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph.
Regarding claim 1, said claim is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, because the specification, while reciting that assignment of graceful shutdown may be made to a device via use of a new path attribute, does not reasonably provide enablement for assignment of “BGP graceful shutdown to routes”. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to use the invention commensurate in scope with these claims; assignment of an attribute to a device is not the same thing as assignment to a route. In other words, the claimed scope of the invention and the disclosed scope of the invention differ to such an extent that issues are raised with regards to compliance under 35 USC 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph. The specification recites that the above assignment to routes occurs, but provides not description as to how the process is performed or otherwise is carried out.
Regarding claims 8 and 15, said claims recite language analogous to the language addressed above appearing in claim 1, and thus suffers from similar issues. Regarding claims 3 – 7, 10 – 14, and 17 – 23, said claims depend on one of claims 1, 8, and 15, and fail to clarify the issues noted above.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3 – 8, 10- 15, and 17 – 23 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, said claim recites a determination that “graceful shutdown is required” (emphasis added). While the specification repeats this language, for example in paragraphs [12] and [17], among others, the accompanying description instead uses language that instead aligns with graceful shutdown “may be needed” ([17]) when a device “may be shut down for maintenance”. Considered as a whole, the specification supports use of graceful shutdown being “enabled” based on a configuration step. However, being “enabled” or otherwise desired (i.e., determined to be “needed . . . to reduce or eliminate a loss of traffic”) is not the same thing as being “required”. The above noted paragraphs, along with the specification as a whole, discuss use of graceful shutdown to “reduce or eliminate a loss of traffic”, but reducing or eliminating a loss of traffic is never described as being a requirement, and instead treated more in line with being a configuration option that may be enabled when supported. This raises the issue of the intended scope for the term “required” based on the standard English define for required being, e.g., “officially compulsory, or otherwise considered essential; indispensable”. In other words, while “required” is claimed, the accompanying description in the specification instead describes use of an optional setting, which is not in line with the standard definition for something being “required”. This results in a claim with an unclear and indefinite scope.
Further regarding claim 1, said claim has been amended to recite a field that “indicates that a receiver network device is to assign BGP graceful shutdown to routes”. Applicant’s specification utilizes this same phrasing, e.g., in [20], [26] and [61]. However, the specification only describes a mechanism for setting/assigning graceful shutdown to devices (rather than routes); e.g., in [24],[26],[33], and [60] via a use of a “new path attribute”. The claim instead reciting assignment to “routes” raises issues regarding the scope of what assignment to a “route” actually entails, and whether or not such an assignment overlaps in scope with the described assignment to a device. This issue is exacerbated by the accompanying lack of enabling description regarding how exactly an assignment to a “route” can be performed (as noted in the above rejections, the specification merely recites that such an assignment is performed and occurs, but provides no mechanism or discussion for how it is to be performed or otherwise made to occur).
Additionally regarding claim 1, said claim has been amended to conclude with the recitation “thereby obviating a need for the initiator device to provide a BGP routing table to the receiver devices prior to shutdown of the initiator device”. Whether a need is obviated appears to correspond to the use of a term of degree. In other words, the language requires a subjective determination be made as to whether something is or is not “needed”.
The phrase “obviating a need” in claim 1 thus is a relative phrase which renders the claim indefinite. The term “need” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
In addition to the above noted issue, the use of “thereby” raises the issue as to the intended weight of the clause “thereby obviating a need for the initiator device to provide a BGP routing table to the receiver devices prior to shutdown of the initiator device”, and whether the language is intended as a conclusory statement comprising non-functional descriptive language implicitly achieved by the preceding “providing, by the initiator device, the BGP route refresh packet” language, or whether the language is in fact intended to add additional weight to the claim (or whether some other alternative reading is desired).
Thus, based on the above noted issues, the scope of claim 1 is rendered unclear and indefinite.
Regarding claim 3, said claim recites “wherein the receiver network device is to maintain a BGP graceful shutdown state for the initiator network device”. There is a lack of antecedent basis for this language, as both claim 3 and parent claim 1 fail to provide support for a device that has a “graceful shutdown state”, and thus there is no support for a device to “maintain” such a state. Claim 1 does begin with a determining as to whether such a state “is required”, but neither claim 1 nor claim 3 ever recite establishment of such a state such that the ”maintain” language of claim has antecedent basis. Further exacerbating the clarity issues of claim 3, claim 1 instead recites assignment of “BGP graceful shutdown to routes” rather than to a “device”. This raises the issue as to whether Applicant is using the terms “route” and “device” interchangeably (a consideration particularly relevant given the accompanying rejections made above under 35 USC 112, 1st paragraph and the corresponding Objections to the Specification).
Regarding claim 4, said claim, further limiting claim 1, recites “disabling the BGP graceful shutdown after providing the BGP route refresh packet to the receiver network device”. Claim 1 and claim 4, however, never recites enabling said “graceful shutdown” in a manner it may be “disabled” as stated in claim 4. Claim 1, e.g., supports a refresh packet that indicates an assignment to be made “to routes” and that this packet is provided to “the receiver device”. However, BGP graceful shutdown is never reciting as being enabled such that the “disabling” language in claim 4 has sufficient antecedent basis. Furthermore, the scope of claim 4 is rendered indefinite due to the clarity issues regarding whether the graceful shutdown is assigned for a device or instead for routes (or potentially for both; note that this issue is discussed in more detail in the preceding rejections). Thus the “disabling” and “is disabled” language regarding this BGP state is rendered indefinite as it is unclear what exactly is being enabled or disabled (A state of a route? A state of a device? Both? Neither? Etc.).
Regarding claim 5, said claim further discusses “the BGP graceful shutdown”, now reciting a “to remove” operation. As noted above (e.g., in claim 4), where/to what the graceful shutdown is applicable is unclear and indefinite, as is how the “to remove” operation is to proceed given the claim lacks antecedent basis for establishment of the state. Note claim 1, e.g., merely recites “graceful shutdown is required . . . for the device” and that graceful shutdown “is to assign . . . to routes”, but actual assignment/invocation of the state is never established for either a device or a route. Thus claim 5 further limiting this indefinite language merely raises more issues regarding scope and clarity. Regarding claim 6, said claim again notes the BGP graceful shutdown, now reciting an indication that it “is changed from enabled to disabled”. As noted above, the claims lack antecedent basis for graceful shutdown actually having any particular state, much less being a state of “enabled” or “disabled”.
Regarding claims 7 and 21, said claim further limits claim 1 and fails to clarify the issues noted above.
Regarding claims 8 and 15, said claims recite language analogous to the language addressed above in the analysis of claim 1, and thus claims 8 and 15 suffer from issues analogous to those of claim 1. Regarding claims 10 and 17, said claims recite language analogous to the language addressed above in the analysis of claim 3, and thus claims 10 and 17 suffer from issues analogous to those of claim 3.
Regarding claims 11 and 18, said claims recite language analogous to the language addressed above in the analysis of claim 4, and thus claims 11 and 18 suffer from issues analogous to those of claim 4.
Regarding claims 12 and 19, said claims recite language analogous to the language addressed above in the analysis of claim 5, and thus claims 12 and 19 suffer from issues analogous to those of claim 5.
Regarding claims 13 and 20, said claims recite language analogous to the language addressed above in the analysis of claim 6, and thus claims 13 and 20 suffer from issues analogous to those of claim 6.
Regarding claims 14, 22, and 23, said claim further limit one of claims 8 and 15, and fails to clarify the issues noted above in their respective parent claim.
In order to perform a complete examination, the above language has been interpreted broadly.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Patel (US-20120269198-A1) in view of Francois (Francois et al. RFC 8326. "Graceful BGP Session Shutdown". (Year: 2018)).
Regarding claim 1, Patel shows a method, comprising: determining, by an initiator network device ([106-107] discussing a “restarting BGP speaker), that a border gateway protocol (BGP) graceful shutdown is required for the initiator network device ([106,108,112] where a restarting speak advertises its own enhanced graceful shutdown (EGR) capability); generating, by the initiator network device, a BGP route refresh packet ([91,95]) comprising an address family identifier (AFI) field, a subtype field, and a subsequent address family identifier (SAFI) field, wherein a value of the subtype field (Fig. 5, [95,96]),
providing, by the initiator network device, the BGP route refresh packet to the receiver network device, thereby obviating a need for the initiator network device to provide a BGP routing table to the receiver network device prior to shutdown of the initiator device ([17], see “avoid unnecessary transmission of the routing information” as it is “preserved across session restart” and [29] discussing where the “last . . . version of routing information . . . have been preserved”; further discussion provided in [105]). Patel does not show: where the subtype indicates that a receiver network device is to assign BGP graceful shutdown to routes received from the initiator device. Francois shows where the subtype indicates that a receiver network device is to assign BGP graceful shutdown to routes received from the initiator device (Abstract, see the use of “GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths”, as well as pg. 5, Section 4.2, see 1st and 2nd bullets discussing “tags the paths” and the last paragraph on pg. 5 discussing “tagging these routes with the GRACEFUL_SHUTDOWN community…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the BGP operational disclosure of Patel with the RFC standard of Francois in order to ensure a protocol-compliant version of BGP is utilized, thus increasing the number of potential devices that will support and utilize the resultant disclosure in a stable, fully functional manner.
Regarding claim 8, Patel shows a initiator network device ([106-107] discussing a “restarting BGP speaker), comprising: one or more memories; and one or more processors (Fig. 1, item 174a containing processor 102 and Fig. 8 showing processor 804 and memory 806, 808, 810) to: determine, that a border gateway protocol (BGP) graceful shutdown is required for the initiator network device ([106,108,112] where a restarting speak advertises its own enhanced graceful shutdown (EGR) capability); generate a BGP route refresh packet ([91,95]) comprising an address family identifier (AFI) field, a subtype field, and a subsequent address family identifier (SAFI) field, wherein a value of the subtype field (Fig. 5, [95,96]),
provide the BGP route refresh packet to the receiver network device, thereby obviating a need for the initiator network device to provide a BGP routing table to the receiver network device prior to shutdown of the initiator device ([17], see “avoid unnecessary transmission of the routing information” as it is “preserved across session restart” and [29] discussing where the “last . . . version of routing information . . . have been preserved”; further discussion provided in [105]). Patel does not show: where the subtype indicates that a receiver network device is to assign BGP graceful shutdown to routes received from the initiator device. Francois shows where the subtype indicates that a receiver network device is to assign BGP graceful shutdown to routes received from the initiator device (Abstract, see the use of “GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths”, as well as pg. 5, Section 4.2, see 1st and 2nd bullets discussing “tags the paths” and the last paragraph on pg. 5 discussing “tagging these routes with the GRACEFUL_SHUTDOWN community…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the BGP operational disclosure of Patel with the RFC standard of Francois in order to ensure a protocol-compliant version of BGP is utilized, thus increasing the number of potential devices that will support and utilize the resultant disclosure in a stable, fully functional manner.
Regarding claim 15, the limitations of said claim are addressed in the rejection of claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes: Zhuang (US-20170134308-A1),
Chen (Chen, E. RFC 2918. "Route Refresh Capability for BGP-4". (Year: 2000)), Patel, RFC 7313 (Patel, K. and Chen, E. RFC 7313. "Enhanced Route Refresh Capability for BGP-4" (Year: 2014)), and Patel, RFC 8538 (Patel et al. RFC 8538. "Notification Message Support for BGP Graceful Restart" (Year: 2019)).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454