DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 06/30/2025. Claims 1-7, 11-13, 18-19, 21, 24, 32-34, 36-37 and 43 are pending in this application.
Examiner Note
The applicant has claimed “and/or” several times throughout the claims.
The examiner is taking the position that in the case of “element A and/or element B” that the “and/or” covers embodiments having element A alone, element B alone, or elements A and B taken together. The phrase “and/or” is not inherently indefinite and therefore is not objected to or rejected as indefinite.
When construing the claims in the context of a possible anticipation or obviousness rejection, the examiner’s disclosure of any one item from the claimed list will provide sufficient teaching of the entire limitation. In Medline, for example, the PTAB stated that “and/or” is a “disjunctive alternative,” and the prior art showing one of the elements so joined renders the claim unpatentable (See, Medline Indus. Inc. v. Paul Hartmann AG, Case No. IPR2013-00173, Paper 17 (P.T.A.B. Jun. 20, 2013)).
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 06/30/2025 and 07/28/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS(s) is/are being considered by the examiner.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 18-19, 36-37 and 43 is/are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by US 20240272914 A1 (hereinafter Ma).
For Claim 1, Ma teaches a method performed by a configuration node (Ma exemplifies a network management device or a controller serving as a client in FIG. 4; param [0131] “… Client/Server (C/S) architecture: Both a NETCONF and a RESTCONF use the C/S architecture. A network management device or a controller serves as a client, and a network device (a network element device such as a router, a switch, or a bridge) serves as a server …”), comprising:
sending a message to a network node (Ma teaches the client sending a configuration rollback request/message to the server/network node; FIG. 4; para. [0210] “… The client can also send a configuration rollback request to the server, requesting to roll back to one piece of backup configuration data …”),
wherein the message is used for at least one of (Examiner notes that the limitation of “the message is used for …” with the list of optional limitations is considered an intended use of the claimed message, such a limitation has not provided sufficient function or structure to state what is next step after sending the message, therefore the limitation of “the message is used for …” with the list of optional limitations is considered to provide questionable patentable weight for the claim; As Ma teaches a NETCONF client sending a configuration rollback request/message to the server/network node and the server/network node performing configuration rollback based on the configuration rollback request/message, it is considered reading on limitation of “the message is used for …”; a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim):
getting a list of historical running configuration data of the network node,
modifying at least one configuration in running configuration data of the network node based on a module,
rolling back the running configuration data of the network node to first historical running configuration data of the network node (Ma teaches the server/network node performing the configuration rollback to baseline configuration data based on the configuration rollback request/message; Examiner notes that the claim has a list of alternatives, and therefore only requires addressing one of the options to teach the claim as a whole; FIG. 4; para. [0210] “… In an implementation, the client sends a backup creation request to the server, where the backup creation request includes baseline configuration data indication information (for example, G=1), and the baseline configuration data indication information indicates to create one piece of backup configuration data as the baseline configuration data … After receiving the configuration rollback request, the server performs configuration rollback based on the configuration rollback request …”), or
loading datastore format configuration data in the message to the running configuration data of the network node.
For Claim 2, Ma teaches the method according to claim 1, further comprising:
sending a first request for getting a difference between the running configuration data and second historical running configuration data of the network node to the network node (Ma teaches the client requesting the server to compare the running configuration data with the baseline configuration data; Examiner notes that the claim does not specify the difference between the “first historical running configuration data” and the “second historical running configuration data,” therefore the baseline configuration data in Ma could teach the “second historical running configuration data”; FIG. 7; para. [0239] “… In some embodiments, as shown in FIG. 7, the client may also send a NETCONF data comparison request to the server, to request the server to compare the configuration data in the running configuration datastore with baseline configuration data …”); and
receiving a first response comprising the difference between the running configuration data and the second historical running configuration data of the network node from the network node (Ma teaches the client receiving the configuration data comparison result from the server; FIG. 7; para. [0239] “… The server compares the configuration data in the running configuration datastore with the baseline configuration data to obtain the second comparison result. The server sends the second comparison result to the client …”).
For Claim 3, Ma teaches the method according to claim 2, wherein the first request comprises a name of the second historical running configuration data (Ma teaches the client sending the configuration data comparison request with the indication information for the target configuration data being compared with the running configuration data; FIG. 7; para. [0240] “… The NETCONF data comparison request sent by the client to the server includes the following information. The NETCONF data comparison request indicates the server to compare the configuration data in the running configuration datastore with the baseline configuration data. The NETCONF data comparison request includes a parameter <compare-config>, <source> in the parameter <compare-config> carries a name of the running configuration datastore, that is, 'running', and <target> carries indication information indicating that a comparison object is the baseline configuration data, that is, 'golden' …”)
For Claim 18, Ma teaches a method performed by a network node (Ma exemplifies a network device serving as a server in FIG. 4; param [0131] “… Client/Server (C/S) architecture: Both a NETCONF and a RESTCONF use the C/S architecture. A network management device or a controller serves as a client, and a network device (a network element device such as a router, a switch, or a bridge) serves as a server …”), comprising:
receiving a message from a configuration node (Ma teaches the server/network device receiving a configuration rollback request/message from the client/controller; FIG. 4; para. [0210] “… The client can also send a configuration rollback request to the server, requesting to roll back to one piece of backup configuration data …”); and
processing the message (Ma teaches the server/network device acting based on the received configuration rollback request/message; FIG. 4; para. [0210] “… After receiving the configuration rollback request, the server performs configuration rollback based on the configuration rollback request …”), wherein the message is used for at least one of (Examiner notes that the limitation of “the message is used for …” with the list of optional limitations is considered an intended use of the claimed message, such a limitation has not provided sufficient function or structure to state what is next step after sending the message, therefore the limitation of “the message is used for …” with the list of optional limitations is considered to provide questionable patentable weight for the claim; As Ma teaches a NETCONF client sending a configuration rollback request/message to the server/network node and the server/network node performing configuration rollback based on the configuration rollback request/message, it is considered reading on limitation of “the message is used for …”; a recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim):
getting a list of historical running configuration data of the network node,
modifying at least one configuration in running configuration data of the network node based on a module,
rolling back the running configuration data of the network node to first historical running configuration data of the network node (Ma teaches the server/network node performing the configuration rollback to baseline configuration data based on the configuration rollback request/message; Examiner notes that the claim has a list of alternatives, and therefore only requires addressing one of the options to teach the claim as a whole; FIG. 4; para. [0210] “… In an implementation, the client sends a backup creation request to the server, where the backup creation request includes baseline configuration data indication information (for example, G=1), and the baseline configuration data indication information indicates to create one piece of backup configuration data as the baseline configuration data … After receiving the configuration rollback request, the server performs configuration rollback based on the configuration rollback request …”), or
loading datastore format configuration data in the message to the running configuration data of the network node.
For Claim 19, Ma teaches the method according to claim 18, further comprising:
receiving a first request for getting a difference between the running configuration data and second historical running configuration data of the network node from the configuration node (Ma teaches the server receiving the client to compare the running configuration data with the baseline configuration data; Examiner notes that the claim does not specify the difference between the “first historical running configuration data” and the “second historical running configuration data,” therefore the baseline configuration data in Ma could teach the “second historical running configuration data”; FIG. 7; para. [0239] “… In some embodiments, as shown in FIG. 7, the client may also send a NETCONF data comparison request to the server, to request the server to compare the configuration data in the running configuration datastore with baseline configuration data …”);
comparing the difference between the running configuration data and the second historical running configuration data (Ma teaches the server comparing the configuration data; FIG. 7; para. [0239] “… The server compares the configuration data in the running configuration datastore with the baseline configuration data to obtain the second comparison result …”); and
sending a first response comprising the difference between the running configuration data and the second historical running configuration data to the configuration node (Ma teaches the server sending the configuration data comparison result to the client; FIG. 7; para. [0239] “… The server sends the second comparison result to the client …”);
wherein the first request comprises a name of the second historical running configuration data (Ma teaches the client sending the configuration data comparison request with the indication information for the target configuration data being compared with the running configuration data; FIG. 7; para. [0240] “… The NETCONF data comparison request sent by the client to the server includes the following information. The NETCONF data comparison request indicates the server to compare the configuration data in the running configuration datastore with the baseline configuration data. The NETCONF data comparison request includes a parameter <compare-config>, <source> in the parameter <compare-config> carries a name of the running configuration datastore, that is, 'running', and <target> carries indication information indicating that a comparison object is the baseline configuration data, that is, 'golden' …”).
For Claim 36, Ma teaches the method according to claim 18, further comprising: generating information about historical running configuration data; and storing the information about the historical running configuration data (Ma teaches the server/network node generating backup configuration data and storing the backup configuration data in a historical configuration datastore; para. [0186] “… Alternatively, the one or more pieces of backup configuration data generated by the server are stored in a historical configuration datastore …”).
For Claim 37, Ma teaches the method according to claim 36, wherein the information about the historical running configuration data comprises at least one of: the historical running configuration data (Ma teaches storing the backup configuration data; Examiner notes that the claim has a list of alternatives, and therefore only requires addressing one of the options to teach the claim as a whole; para. [0186] “… Alternatively, the one or more pieces of backup configuration data generated by the server are stored in a historical configuration datastore …”),
a name of the historical running configuration data, a timestamp of a running configuration data change, or an identity of a user who triggers the running configuration data change.
For Claim 43, the claim is substantially similar to claim 18 and therefore is rejected for the same reasoning set forth above. Additionally, Ma teaches a network node, comprising: a processor; and a memory coupled to the processor, said memory containing instructions executable by said processor, whereby said network node is operative to (Ma, FIG. 2; para. [0147] “… Optionally, the communication device is the client or the server shown in FIG. 1, and the communication device includes one or more processors 201, a communication bus 202, a memory 203, and one or more communication interfaces 204 …”; para. [0150] “… the memory 203 … can be configured to carry or store expected program code in a form of an instruction or a data structure and that can be accessed by a computer …”; para. [0152] “… Optionally, the processor herein is one or more devices, circuits, and/or processing cores configured to process data (such as computer program instructions) …”).
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 4-7, 11, 21, 24 and 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240272914 A1 (hereinafter Ma), in view of US 20060007944 A1 (hereinafter Movassaghi).
For Claim 4, Ma teaches the method according to claim 1. Ma does not explicitly teach, but Movassaghi teaches further comprising: sending a second request for getting third historical running configuration data of the network node to the network node (Movassaghi teaches the client requesting configuration history data; FIG. 1; para. [0050] “… Configuration manager 134 can process a request from client 110 to view the configuration history data …”); and
receiving a second response comprising information about the third historical running configuration data of the network node from the network node (Movassaghi teaches the client receiving the configuration history data from the network device comprising the configuration manager; FIG. 1; para. [0050] “… Configuration manager 134 may retrieve configuration history data associated with a particular point in time or a particular state of network device 130 and transmit the configuration history data to client 110 …”).
Movassaghi and Ma are analogous art because they are both related to network device configuration process.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the retrieving the configuration history data from the network device techniques of Movassaghi with the system of Ma to facilitate successful network device configuration with large-scale, distributed architecture (Movassaghi, para. [0005]).
For Claim 5, Ma-Movassaghi teaches the method according to claim 4, wherein the second request comprises a name of the third historical running configuration data (Movassaghi teaches the client requesting the configuration history data with reference to a period of time; FIG. 1; para. [0051] “… If client 110 transmits a request to network device 130 to view configuration data with reference to a first point in time and a second point in time, configuration manager 134 can use the configuration history data to determine a set of configuration changes between the operational state of the network device associated with the first point in time and the operational state of the network device associated with the second point in time …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the retrieving the configuration history data from the network device techniques of Movassaghi with the system of Ma to facilitate successful network device configuration with large-scale, distributed architecture (Movassaghi, para. [0005]).
For Claim 6, Ma-Movassaghi teaches the method according to claim 4, wherein the information about the third historical running configuration data comprises at least one of:
the third historical running configuration data (Movassaghi teaches the client receiving the configuration history data from the network device which comprising the configuration manager; FIG. 1; para. [0050] “… Configuration manager 134 may retrieve configuration history data associated with a particular point in time or a particular state of network device 130 and transmit the configuration history data to client 110 …”),
a name of the third historical running configuration data (Movassaghi teaches the client requesting the configuration history data with reference to a period of time; FIG. 1; para. [0051] “… If client 110 transmits a request to network device 130 to view configuration data with reference to a first point in time and a second point in time, configuration manager 134 can use the configuration history data to determine a set of configuration changes between the operational state of the network device associated with the first point in time and the operational state of the network device associated with the second point in time …”),
a timestamp of a running configuration data change (Movassaghi, FIG. 1; para. [0048] “… data manager 136 stores the configuration data in a binary file in device configuration database 140 … the binary file could reference information that describes, for each configuration change, when the configuration change was made (for example, a timestamp ), what user initiated the configuration change, which client application transmitted the request to make the configuration change, and a location from which the configuration change was initiated …”), or
an identity of a user who triggers the running configuration data change (Movassaghi, FIG. 1; para. [0048] “… data manager 136 stores the configuration data in a binary file in device configuration database 140 … the binary file could reference information that describes, for each configuration change, when the configuration change was made (for example, a timestamp ), what user initiated the configuration change, which client application transmitted the request to make the configuration change, and a location from which the configuration change was initiated …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the retrieving the configuration history data from the network device techniques of Movassaghi with the system of Ma to facilitate successful network device configuration with large-scale, distributed architecture (Movassaghi, para. [0005]).
For Claim 7, Ma teaches the method according to any of claim 1.
Ma does not explicitly teach, but Movassaghi teaches wherein when the message is used for modifying at least one configuration in the running configuration data of the network node based on a module, the message comprises a name of historical running configuration data corresponding to the running configuration data and information indicating the at least one configuration;
wherein when the message is used for rolling back the running configuration data of the network node to the first historical running configuration data of the network node, the message comprises a name of the first historical running configuration data (Movassaghi teaches the client requesting the rollback operation by specifying an earlier rollback point version number; Examiner notes that the claim has a list of alternatives, and therefore only requires addressing one of the options to teach the claim as a whole; FIG. 1, FIG. 4, FIG. 8; para. [0066] “… Client 110 may transmit a XML document over communications link 120 to request interface 132. The XML document may contain one or more requests that are formatted according to any of a variety of request syntax conventions, such as the Cisco CLI syntax … the request may be to … process an operation regarding more advanced configuration services on the network device, e.g., a lock operation, an unlock operation, a commit operation, or a rollback operation …”; para. [0136] “… Each rollback point is stored in association with a version number that associates the commit with the active namespace set and active software components, as shown in step 806 …”; para. [0138] “… In step 808, a request for a rollback to an earlier rollback point version number is received …”); or
wherein when the message is used for getting a list of historical running configuration data of the network node, the method further comprises: receiving the list of historical running configuration data of the network node from the network node.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the rollback operation techniques of Movassaghi with the system of Ma to facilitate successful network device configuration with large-scale, distributed architecture (Movassaghi, para. [0005]).
For Claim 11, Ma teaches the method according to claim 1. Ma does not explicitly teach, but Movassaghi teaches wherein the list of historical running configuration data comprises at least one of:
a name of historical running configuration data (Movassaghi teaches the client requesting the configuration history data with reference to a period of time; FIG. 1; para. [0051] “… If client 110 transmits a request to network device 130 to view configuration data with reference to a first point in time and a second point in time, configuration manager 134 can use the configuration history data to determine a set of configuration changes between the operational state of the network device associated with the first point in time and the operational state of the network device associated with the second point in time …”),
a timestamp of a running configuration data change (Movassaghi, FIG. 1; para. [0048] “… data manager 136 stores the configuration data in a binary file in device configuration database 140 … the binary file could reference information that describes, for each configuration change, when the configuration change was made (for example, a timestamp ), what user initiated the configuration change, which client application transmitted the request to make the configuration change, and a location from which the configuration change was initiated …”), or
an identity of a user who triggers the running configuration data change (Movassaghi, FIG. 1; para. [0048] “… data manager 136 stores the configuration data in a binary file in device configuration database 140 … the binary file could reference information that describes, for each configuration change, when the configuration change was made (for example, a timestamp ), what user initiated the configuration change, which client application transmitted the request to make the configuration change, and a location from which the configuration change was initiated …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the retrieving the configuration history data from the network device techniques of Movassaghi with the system of Ma to facilitate successful network device configuration with large-scale, distributed architecture (Movassaghi, para. [0005]).
For Claim 21, Ma teaches the method according to claim 18. Ma does not explicitly teach, but Movassaghi teaches further comprising:
receiving a second request for getting third historical running configuration data of the network node from the configuration node (Movassaghi teaches the network device comprising the configuration manager receiving request to view configuration history data; FIG. 1; para. [0050] “… Configuration manager 134 can process a request from client 110 to view the configuration history data …”); and
sending a second response comprising information about the third historical running configuration data of the network node to the configuration node (Movassaghi teaches the network device transmitting the configuration history data to the client; FIG. 1; para. [0050] “… Configuration manager 134 may retrieve configuration history data associated with a particular point in time or a particular state of network device 130 and transmit the configuration history data to client 110 …”);
wherein the second request comprises a name of the third historical running configuration data (Movassaghi teaches the client requesting the configuration history data with reference to a period of time; Examiner notes that the claim has a list of alternatives, and therefore only requires addressing one of the options to teach the claim as a whole; FIG. 1; para. [0051] “… If client 110 transmits a request to network device 130 to view configuration data with reference to a first point in time and a second point in time, configuration manager 134 can use the configuration history data to determine a set of configuration changes between the operational state of the network device associated with the first point in time and the operational state of the network device associated with the second point in time …”); and/or
wherein the information about the third historical running configuration data comprises at least one of: the third historical running configuration data, a name of the third historical running configuration data, a timestamp of a running configuration data change, or an identity of a user who triggers the running configuration data change.
Movassaghi and Ma are analogous art because they are both related to network device configuration process.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the retrieving the configuration history data from the network device techniques of Movassaghi with the system of Ma to facilitate successful network device configuration with large-scale, distributed architecture (Movassaghi, para. [0005]).
For Claim 24, Ma teaches the method according to claim 18. Ma does not explicitly teach, but Movassaghi teaches wherein when the message is used for modifying at least one configuration in the running configuration data of the network node based on a module, the message comprises a name of historical running configuration data corresponding to the running configuration data and information indicating the at least one configuration, and processing the message comprises modifying at least one configuration in the running configuration data based on a module;
wherein when the message is used for rolling back the running configuration data of the network node to the first historical running configuration data of the network node, the message comprises a name of the first historical running configuration data (Movassaghi teaches the client requesting the rollback operation by specifying an earlier rollback point version number; Examiner notes that the claim has a list of alternatives, and therefore only requires addressing one of the options to teach the claim as a whole; FIG. 1, FIG. 4, FIG. 8; para. [0066] “… Client 110 may transmit a XML document over communications link 120 to request interface 132. The XML document may contain one or more requests that are formatted according to any of a variety of request syntax conventions, such as the Cisco CLI syntax … the request may be to … process an operation regarding more advanced configuration services on the network device, e.g., a lock operation, an unlock operation, a commit operation, or a rollback operation …”; para. [0136] “… Each rollback point is stored in association with a version number that associates the commit with the active namespace set and active software components, as shown in step 806 …”; para. [0138] “… In step 808, a request for a rollback to an earlier rollback point version number is received …”), and processing the message comprises rolling back the running configuration data of the network node to the first historical running configuration data of the network node (Movassaghi teaches processing the rolling back request and performing rollback operation; FIG. 8; para. [0138] “… When an operator attempts to roll back the current configuration to an older rollback point, the process of FIG. 8 determines configuration of namespaces associated with the rollback point are compatible with all current active software components … If an atomic operation is requested, then the operation is aborted if a configuration incompatibility is detected. If the restore operation type is best effort, the incompatible part of the configuration is removed and then the restore operation proceeds for the compatible part of the configuration …”);
wherein when the message is used for loading datastore format configuration data in the message to the running configuration data of the network node, processing the message comprises loading the datastore format configuration data in the message to the running configuration data of the network node; or
wherein when the message is used for getting a list of historical running configuration data of the network node, the method further comprising: sending the list of historical running configuration data of the network node to the configuration node.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the rollback operation techniques of Movassaghi with the system of Ma to facilitate successful network device configuration with large-scale, distributed architecture (Movassaghi, para. [0005]).
For Claim 32, the claim is substantially similar to claim 11 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 12-13 and 33-34 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240272914 A1 (hereinafter Ma), in view of US 20160373300 A1 (hereinafter Liu)..
For Claim 12, Ma teaches the method according to claim 1. Ma does not explicitly teach, but Liu teaches further comprising:
receiving information indicating at least one capability of modifying operation, rolling back operation or loading operation from the network node (Liu teaches the client/NMS receiving network device configuration capability sets including the capability sets for running configuration changes and rolling back error that correspond to the capabilities of modifying operation and rolling back operation; FIG. 2; para. [0027] “… the NETCONF may further divide the above operations into capability sets for managing. In the process of establishing the NETCONF connection, the client end may send the <hello> element to the network management system (NMS) and complete the exchange of the capability sets, then the network device can establish a session and handle subsequent requests sent by the client end …”; para. [0028] – [0033] “… In the RFC specification. the major capability set may be defined as follows: … Writable-running: The capability set for running configuration changes … Rollback-on-error: The capability set for rolling back error …”; para. [0042] “… In block 202, during the establishment of the NETCONF session, the NMS may compare a first NETCONF capability set which is obtained from the network device with a second NETCONF capability set which is supported by the NMS …”),
wherein the message is sent to the network node when the network node supports the at least one capability of modifying operation, rolling back operation or loading operation (Liu teaches the client/NMS sending configuration request to the network device based on the capability set actively supported by the network device; FIG. 2; para. [0027] “… then the network device can establish a session and handle subsequent requests sent by the client end …”; para. [0043] “… In block 203, the NMS may perform a network configuration access to the network device based on the active capability set of the current NETCONF session …”).
Liu and Ma are analogous art because they are both related to network device configuration process.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the performing network device configuration operation based on the actively supported capability set techniques of Liu with the system of Ma to facilitate high degree of scalability in supporting the extension of the NETCONF capability set and the operation (Liu, para. [0090]).
For Claim 13, Ma-Liu teaches the method according to claim 12, wherein the information is received from the network node during a session establishment procedure between the configuration node and the network node (Liu teaches the client/NMS receiving the NETCONF capability set from the network device during the NETCONF session establishment; FIG. 2; para. [0042] “… In block 202, during the establishment of the NETCONF session, the NMS may compare a first NETCONF capability set which is obtained from the network device with a second NETCONF capability set which is supported by the NMS …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the performing network device configuration operation based on the actively supported capability set techniques of Liu with the system of Ma to facilitate high degree of scalability in supporting the extension of the NETCONF capability set and the operation (Liu, para. [0090]).
For Claim 33, Ma teaches the method according to claim 18. Ma does not explicitly teach, but Liu teaches further comprising: sending information indicating at least one capability of modifying operation, rolling back operation or loading operation to the configuration node (Liu teaches the network device sending the network device configuration capability sets including the capability sets for running configuration changes and rolling back error that correspond to the capabilities of modifying operation and rolling back operation; FIG. 2; para. [0027] “… the NETCONF may further divide the above operations into capability sets for managing. In the process of establishing the NETCONF connection, the client end may send the <hello> element to the network management system (NMS) and complete the exchange of the capability sets, then the network device can establish a session and handle subsequent requests sent by the client end …”; para. [0028] – [0033] “… In the RFC specification. the major capability set may be defined as follows: … Writable-running: The capability set for running configuration changes … Rollback-on-error: The capability set for rolling back error …”; para. [0042] “… In block 202, during the establishment of the NETCONF session, the NMS may compare a first NETCONF capability set which is obtained from the network device with a second NETCONF capability set which is supported by the NMS …”),
wherein the message is received from the configuration node when the network node supports the at least one capability of modifying operation, rolling back operation or loading operation (Liu teaches the network device receiving configuration request from the client/NMS based on the capability set actively supported by the network device; FIG. 2; para. [0027] “… then the network device can establish a session and handle subsequent requests sent by the client end …”; para. [0043] “… In block 203, the NMS may perform a network configuration access to the network device based on the active capability set of the current NETCONF session …”).
Liu and Ma are analogous art because they are both related to network device configuration process.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the performing network device configuration operation based on the actively supported capability set techniques of Liu with the system of Ma to facilitate high degree of scalability in supporting the extension of the NETCONF capability set and the operation (Liu, para. [0090]).
For Claim 34, Ma-Liu teaches the method according to claim 33, wherein the information is sent to the configuration node during a session establishment procedure between the configuration node and the network node (Liu teaches the network device sending the NETCONF capability set to the client/NMS during the NETCONF session establishment; FIG. 2; para. [0042] “… In block 202, during the establishment of the NETCONF session, the NMS may compare a first NETCONF capability set which is obtained from the network device with a second NETCONF capability set which is supported by the NMS …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the performing network device configuration operation based on the actively supported capability set techniques of Liu with the system of Ma to facilitate high degree of scalability in supporting the extension of the NETCONF capability set and the operation (Liu, para. [0090]).
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. US 2013/0194974 A1 (hereinafter Purkayastha) teaches receiving configuration data for configuring network devices; generating remote procedure calls (RPCs) for configuring the network devices, which include provisioning and reverse provisioning RPCs, where each reverse provisioning RPC reverse provisions a particular pseudowire; providing to the network devices the provisioning RPCs; determining a success with respect to each of the provisioning RPCs, where the success indicates that all endpoints of a pseudowire have been successfully configured; providing the reverse provisioning RPCs to the network devices, when it is determined that the success has not been achieved; and storing an indication of success when it is determined that the success has been achieved with respect to the provisioning RPCs (Abstract).
ii. US 2022/0014432 A1 (hereinafter Lei) teaches restoring a NETCONF server to factory defaults, and relate to the field of configuration management technologies. A NETCONF server receives a command for restoring to factory defaults sent by a NETCONF client, where the command for restoring to factory defaults is a remote procedure call (RPC) command that is based on a Yang model of the NETCONF for restoring the NETCONF server to the factory defaults. The NETCONF server replaces data in the running configuration datastore with factory defaults of the NETCONF server according to the command for restoring to factory defaults (Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444
Prosecution Insights