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 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) 1, 2, 10, 11, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Scudder et al. (US PG PUB 20050177634), hereinafter "Scudder", in views of Qui et al. (US PG PUB 20170318087), hereinafter "Qui".
Regarding Claims 1 and 10 Scudder discloses:
(Claim 1) A method performed by a network device for implementing a hitless reboot (i.e. a method performed by a router [i.e. a network device] for gracefully shutting down [i.e. a hitless reboot]) (Fig. 1, Fig. 3 and Abstract) the method comprising,
(Claim 10) A network device (i.e. a router) (Fig. 3 and ¶ 0028) comprising: a central processing unit (CPU) (i.e. route processor 302) (302 – Fig. 3 and ¶ 0028);
a non-volatile storage (i.e. memory 304 storing router operating system [i.e. a non-volatile storage]) (304 – Fig. 3 and ¶ 0028); and a main memory having stored thereon program code that, when executed by the CPU, causes the CPU (i.e. memory 304 storing router operating system and program software executable by the route processor 302) (¶ 0028) to
at a time of shutting down the network device for the hitless reboot (i.e. when the router undergoes the graceful shutdown [i.e. at a time of shutting down the network device for the hitless reboot]) (Fig. 8 and ¶ 0014 and ¶ 0041):
identifying/identify one or more Border Gateway Protocol (BGP) static peers defined in a peer configuration of the network device (i.e. the router may send [i.e. in order to send it firstly needs to identify] graceful shutdown notification message to all of its BGP peers [i.e. static peers] which are addressable via corresponding prefixes stored in Forwarding Information Base FIB 330 [i.e. a peer configuration of the network device] of the router [i.e. note that a static peer with an explicit IP address may be defined using prefix with /32 for IPv4 and /128 for IPv6]) (330 – Fig. 3, 804 – Fig. 8, ¶ 0005 and ¶ 0041);
identifying/identify one or more BGP dynamic peers that have an established BGP session with the network device (i.e. the router may send [i.e. in order to send it firstly needs to identify] graceful shutdown notification message to all of its BGP peers [i.e. dynamic peers] which are addressable via corresponding prefixes stored in FIB 330 [i.e. note that FIB stores prefixes that have established BGP session with the network device] of the router) (330 – Fig. 3, 804 – Fig. 8, ¶ 0032 and ¶ 0041).
However, Scudder does not explicitly disclose:
for each identified BGP static peer, writing a first entry to a peering status file maintained on a non-volatile storage of the network device, the first entry including an Internet Protocol (IP) address of the identified BGP static peer and a current peering status of the identified BGP static peer; and
for each identified BGP dynamic peer, writing a second entry to the peering status file, the second entry including an IP address of the identified BGP dynamic peer and a current peering status of the identified BGP dynamic peer.
On the other hand, in an analogous art, Qiu discloses:
for each identified BGP static peer, writing a first entry to a peering status file maintained on a non-volatile storage of the network device, the first entry including an Internet Protocol (IP) address of the identified BGP static peer and a current peering status of the identified BGP static peer (i.e. at the time of graceful shutdown, for each virtual network function VNF [i.e. analogous to each identified BGP static peer], the computing device may identify peer network function instances [i.e. analogous to each identified BGP static peer] and obtain snapshot of configuration data of the peer network function instances [i.e. writing a first entry to a peering status file maintained on a non-volatile storage of the network device]; the snapshot [i.e. the first entry] may include configuration information including IP address [i.e. an Internet Protocol (IP) address of the identified BGP static peer] and/or state, e.g. in service, out service, shutting down [i.e. current peering status] associated with each virtual network function instance [i.e. a current peering status of the identified BGP static peer] identified as a peer network function instance) (Fig. 2, 306, 310 & 312 – Fig. 3, ¶ 0037 and ¶ 0061 - 0063); and
for each identified BGP dynamic peer, writing a second entry to the peering status file, the second entry including an IP address of the identified BGP dynamic peer and a current peering status of the identified BGP dynamic peer (i.e. at the time of graceful shutdown, for each virtual network function VNF [i.e. analogous to each identified BGP dynamic peer], the computing device may identify peer network function instances [i.e. analogous to each identified BGP dynamic peer] and obtain snapshot of configuration data of the peer network function instances [i.e. writing a second entry to the peering status file]; the snapshot [i.e. second entry] may include configuration information including IP address [i.e. an IP address of the identified BGP dynamic peer] and/or state, e.g. in service, out service, shutting down [i.e. current peering status] associated with each virtual network function instance [i.e. a current peering status of the identified BGP dynamic peer] identified as a peer network function instance) (Fig. 2, 306, 310 & 312 – Fig. 3, ¶ 0037 and ¶ 0061 - 0063).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method/system of Scudder to include wherein for each identified BGP static peer, writing a first entry to a peering status file maintained on a non-volatile storage of the network device, the first entry including an Internet Protocol (IP) address of the identified BGP static peer and a current peering status of the identified BGP static peer; and for each identified BGP dynamic peer, writing a second entry to the peering status file, the second entry including an IP address of the identified BGP dynamic peer and a current peering status of the identified BGP dynamic peer as taught by Qiu in order to reestablish network connection with the peers based on the configuration and status of the peers (Fig. 2, 306, 310 & 312 – Fig. 3, ¶ 0037 and ¶ 0061 - 0063).
Regarding Claims 2 and 11, Scudder and Qui disclose, in particular Scudder teaches:
wherein the IP address of the identified BGP static peer is included in the peer configuration (i.e. BGP peers [i.e. the identified static BGP peers] addressable via corresponding prefixes are stored in Forwarding Information Base FIB 330 [i.e. a peer configuration of the network device]) (330 – Fig. 3, 804 – Fig. 8, ¶ 0005 and ¶ 0041).
Regarding Claim 19, Scudder discloses:
A method performed by a network device for implementing a hitless reboot (i.e. a method performed by a router [i.e. a network device] for gracefully shutting down [i.e. a hitless reboot]) (Fig. 1, Fig. 3 and Abstract) the method comprising,
at a time of shutting down the network device for the hitless reboot (i.e. when the router undergoes the graceful shutdown [i.e. at a time of shutting down the network device for the hitless reboot]) (Fig. 8 and ¶ 0014 and ¶ 0041):
identifying/identify one or more Border Gateway Protocol (BGP) static peers defined in a peer configuration of the network device (i.e. the router may send [i.e. in order to send it firstly needs to identify] graceful shutdown notification message to all of its BGP peers [i.e. static peers] which are addressable via corresponding prefixes stored in Forwarding Information Base FIB 330 [i.e. a peer configuration of the network device] of the router [i.e. note that a static peer with an explicit IP address may be defined using prefix with /32 for IPv4 and /128 for IPv6]) (330 – Fig. 3, 804 – Fig. 8, ¶ 0005 and ¶ 0041).
However, Scudder does not explicitly disclose:
for each identified BGP static peer, writing a first entry to a peering status file maintained on a non-volatile storage of the network device, the first entry including an Internet Protocol (IP) address of the identified BGP static peer and a current peering status of the identified BGP static peer.
On the other hand, in an analogous art, Qiu discloses:
for each identified BGP static peer, writing a first entry to a peering status file maintained on a non-volatile storage of the network device, the first entry including an Internet Protocol (IP) address of the identified BGP static peer and a current peering status of the identified BGP static peer (i.e. at the time of graceful shutdown, for each virtual network function VNF [i.e. analogous to each identified BGP static peer], the computing device may identify peer network function instances [i.e. analogous to each identified BGP static peer] and obtain snapshot of configuration data of the peer network function instances [i.e. writing a first entry to a peering status file maintained on a non-volatile storage of the network device]; the snapshot [i.e. the first entry] may include configuration information including IP address [i.e. an Internet Protocol (IP) address of the identified BGP static peer] and/or state, e.g. in service, out service, shutting down [i.e. current peering status] associated with each virtual network function instance [i.e. a current peering status of the identified BGP static peer] identified as a peer network function instance) (Fig. 2, 306, 310 & 312 – Fig. 3, ¶ 0037 and ¶ 0061 - 0063).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method/system of Scudder to include wherein for each identified BGP static peer, writing a first entry to a peering status file maintained on a non-volatile storage of the network device, the first entry including an Internet Protocol (IP) address of the identified BGP static peer and a current peering status of the identified BGP static peer as taught by Qiu in order to reestablish network connection with the peers based on the configuration and status of the peers (Fig. 2, 306, 310 & 312 – Fig. 3, ¶ 0037 and ¶ 0061 - 0063).
Regarding Claim 20, Scudder and Qui disclose:
identifying/ one or more BGP dynamic peers that have an established BGP session with the network device (Scudder - i.e. the router may send [i.e. in order to send it firstly needs to identify] graceful shutdown notification message to all of its BGP peers [i.e. dynamic peers] which are addressable via corresponding prefixes stored in FIB 330 [i.e. note that FIB stores prefixes that have established BGP session with the network device] of the router) (Scudder - 330 – Fig. 3, 804 – Fig. 8, ¶ 0032 and ¶ 0041);
for each identified BGP dynamic peer, writing a second entry to the peering status file, the second entry including an IP address of the identified BGP dynamic peer and a current peering status of the identified BGP dynamic peer (Qui - i.e. at the time of graceful shutdown, for each virtual network function VNF [i.e. analogous to each identified BGP dynamic peer], the computing device may identify peer network function instances [i.e. analogous to each identified BGP dynamic peer] and obtain snapshot of configuration data of the peer network function instances [i.e. writing a second entry to the peering status file]; the snapshot [i.e. second entry] may include configuration information including IP address [i.e. an IP address of the identified BGP dynamic peer] and/or state, e.g. in service, out service, shutting down [i.e. current peering status] associated with each virtual network function instance [i.e. a current peering status of the identified BGP dynamic peer] identified as a peer network function instance) (Qui - Fig. 2, 306, 310 & 312 – Fig. 3, ¶ 0037 and ¶ 0061 - 0063).
The prior art used in the rejection of the current claim is combined using the same motivations as was applied in claim 19.
Allowable Subject Matter
Claims 3-9 and 12-18 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SOE MIN HLAING whose telephone number is (303)297-4282. The examiner can normally be reached Monday-Friday 9AM - 5PM.
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, Christopher Parry can be reached at 571-272-8328. 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.
/Soe Hlaing/Primary Examiner, Art Unit 2451