DETAILED ACTION
Status of Claims
Claims 1 – 20 are pending.
Claims 1 and 11 are independent.
This office action is Non-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 .
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.
The factual inquiries 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.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fraley (US Patent No. 8,412,803), in view of Jungck et al. (US Patent Application Publication No. 2009/0262741 A1, hereinafter “Jungck”) .
As per claim 1, Fraley teaches a method, comprising:
generating, by a …[router], one or more pieces of backup configuration data [candidate configuration 520, fig. 5], wherein each piece of backup configuration data corresponds to metadata, the metadata comprises baseline indication information and a backup identifier [data is identified with flags, col. 6, lines 65 - 67], and the baseline indication information indicates whether the corresponding piece of backup configuration data is baseline configuration data [fig. 5, step 545, col.3, lines 45-53: “… the apparatus may be configured by (1) identifying a configuration as a rescue configuration, (2) storing the identified rescue configuration in a storage device (if it is not already stored), and (3) selecting a stored rescue configuration to use as a most recently committed configuration in a data forwarding apparatus ( e.g., by committing it as a part of the rescue operation of the router) after a rescue command.…”, col. 6, lines 40 - 64];
receiving, by the … [router], a network configuration protocol (NETCONF) configuration rollback request sent by a client1 [col. 6, lines 7 – 9 : The rescue command may be initiated in a variety of ways, such as by a CLI, some other user interface]; and performing, by the …[router], configuration rollback based on the metadata corresponding to the one or more pieces of backup configuration data and the NETCONF configuration rollback request [fig. 5, step 560, col. 7, lines 6 – 13: In addition to replacing the most recently committed configuration with the rescue configuration in response to a "rescue" command, the apparatus may also be rebooted (Block 560). ].
However, Fraley does not explicitly teach the server. Jungck teaches that the router can be integrated with a server to provision across a network.
As per claim 1, Jungck further teaches the server is integrated with the router [0079: the edge server 402 is integrated with a router].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jungck and Fraley, as Jungck centralizes the functionalities of the router to a server in one place.
As per claim 2, Fraley teaches the method according to claim 1, wherein the NETCONF configuration rollback request comprises rollback target indication information, and the rollback target indication information indicates to roll back to the baseline configuration data; and wherein performing, by the server, configuration rollback based on the metadata corresponding to the one or more pieces of backup configuration data and the NETCONF configuration rollback request comprises: determining, by the server, the baseline configuration data from the one or more pieces of backup configuration data based on the rollback target indication information and baseline indication information in the metadata corresponding to the one or more pieces of backup configuration data; and rolling back, by the server, configuration data in a running configuration datastore to the baseline configuration data [roll back to a committed stored configuration fig. 5, steps 520, 540, and 545, col. 6 – 7, lines 40 - 12 ].
As per claim 3, Fraley teaches the method according to claim 1, wherein the NETCONF configuration rollback request comprises rollback target indication information, the rollback target indication information indicates to roll back to first backup configuration data, and metadata corresponding to the first backup configuration data comprises a first backup identifier; and wherein performing, by the server, configuration rollback based on the metadata corresponding to the one or more pieces of backup configuration data and the NETCONF configuration rollback request comprises: determining, by the server, the first backup configuration data corresponding to the first backup identifier from the one or more pieces of backup configuration data; and rolling back, by the server, configuration data in a running configuration datastore to the first backup configuration data [col.6, lines 51 – 62 : “In response to a "save rescue" command, a copy of a (e.g., the most recently) committed configuration may be saved as the rescue configuration (Block 540) before the method 500 branches back to Block 510. In an apparatus that permits multiple configurations to be committed, the copy saved may be any one of the configurations ( e.g., any one of a number of revisions) committed. In response to a "commit rescue" command, the current candidate configuration ( e.g., the configuration currently stored in non-persistent work memory) may be saved to persistent storage as the rescue configuration (Block 545) before method 500 branches back to Block 510…”].
As per claim 4, Fraley teaches the method according to claim 1, wherein generating, by the server, the one or more pieces of backup configuration data comprises: generating, by the server each time the server receives a NETCONF backup creation request, a corresponding one piece of backup configuration data based on the NETCONF backup creation request; or generating, by the server, at least one piece of backup configuration data based on a preset time; or generating, by the server each time configuration updating is performed, a corresponding one piece of backup configuration data based on configuration data after the configuration updating [system may automate updating of rescue configuration col. 7, lines 23 – 28: “… In yet another alternative method, when a "rescue" 20 command is entered, the apparatus may automatically determine the known functioning configuration and use it to reboot the apparatus. In still another alternative, the apparatus may determine the known functioning configuration, to be used as the rescue configuration, even before the "rescue" command is entered.…” ].
As per claim 5, Fraley teaches the method according to claim 4, wherein in a case that the server receives a NETCONF backup creation request, when the NETCONF backup creation request comprises baseline configuration data indication information, baseline indication information in metadata corresponding to the corresponding generated one piece of backup configuration data is the baseline configuration data indication information, wherein the baseline configuration data indication information comprises a first value or a second value, the first value indicates that the corresponding backup configuration data is the baseline configuration data, and the second value indicates that the corresponding backup configuration data is not the baseline configuration data [fig. 5, steps 520, 540, and 545, col. 6 – 7, lines 40 - 12 ].
As per claim 6, Fraley teaches the method according to claim 1, further comprising: receiving, by the server, a NETCONF data comparison request sent by the client, wherein the NETCONF data comparison request comprises first configuration data to be delivered; comparing, by the server, the first configuration data with second configuration data to obtain a first comparison result, wherein the first comparison result comprises a differential part between the first configuration data and the second configuration data, and the second configuration data is comprised in the one or more pieces of backup configuration data; and sending, by the server, the first comparison result to the client [col. 7, lines 23 – 28: the apparatus may determine the known functioning configuration, to be used as the rescue configuration, even before the "rescue" command 25 is entered.].
As per claim 7, Fraley teaches the method according to claim 6, wherein the NETCONF data comparison request further comprises comparison object indication information; and wherein before comparing, by the server, the first configuration data with second configuration data, the method further comprises: determining, by the server, the second configuration data from the one or more pieces of backup configuration data based on the comparison object indication information and the metadata corresponding to the one or more pieces of backup configuration data [multiple configurations are stored, fig. 5, steps 520, 540, and 545, col. 6 – 7, lines 40 - 26 ].
As per claim 8, Fraley teaches the method according to claim 7, wherein the comparison object indication information comprises indication information indicating that a comparison object is the baseline configuration data; and wherein determining, by the server, the second configuration data from the one or more pieces of backup configuration data based on the comparison object indication information and the metadata corresponding to the one or more pieces of backup configuration data comprises: determining, by the server, the second configuration data from the one or more pieces of backup configuration data based on the comparison object indication information and the baseline indication information in the metadata corresponding to the one or more pieces of backup configuration data, wherein the second configuration data is data in the baseline configuration data [fig. 5, steps 520, 540, and 545, col. 6 – 7, lines 40 - 26 ].
As per claim 9, Fraley teaches the method according to claim 7, wherein the comparison object indication information comprises a second backup identifier; and wherein determining, by the server, the second configuration data from the one or more pieces of backup configuration data based on the comparison object indication information and the metadata corresponding to the one or more pieces of backup configuration data comprises: determining, by the server, the second configuration data from the one or more pieces of backup configuration data based on the comparison object indication information and each backup identifier in the metadata corresponding to the one or more pieces of backup configuration data, wherein the second configuration data is data in backup configuration data corresponding to the second backup identifier [fig. 5, steps 520, 540, and 545, col. 6 – 7, lines 40 - 26 ]..
As per claim 10, Fraley teaches the method according to claim 8, wherein the comparison object indication information further comprises a filter; and wherein determining, by the server, the second configuration data from the one or more pieces of backup configuration data comprises: determining, by the server, reference backup configuration data from the one or more pieces of backup configuration data; and determining, by the server, the second configuration data from the reference backup configuration data based on the filter [configurations may be “filtered” based on flags and/or locations, col. 6, lines 64 – 66: “… The stored rescue configuration may be identified as such by storing it in a particular storage location, or flagging it in some way…”].
As per claims 11 - 20, it is directed to an apparatus to implement the method of steps set forth in claims 1 - 10. Fraley teaches the claimed method steps. Therefore, Fraley teaches the apparatus to implement the claims steps.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
York et al. (US Patent No. 12,056,262 B2) “Applying Trusted Backup Configuration To a Node” is cited to teach examples to restore a trusted backup configuration for a node. Example techniques include failover to an alternate firmware of the node, in response to an unverifiable condition of an existing firmware of the node. The node may validate a first configuration file stored in the node. The first configuration file includes a first backup configuration. The node may validate a second configuration file stored in the node based on the validation of the first configuration file. The second configuration file includes a second backup configuration. In response to the validation of at least one of the first configuration file and the second configuration file, the node may select one of the first backup configuration and the second backup configuration, and apply the selected backup configuration to the node.
Zhang; Xiaoping et al. (US Patent No. 11,989,100 B2)“Information Backup Method And Related Device” is cited to teach an information backup method applied to a communications system including a primary device, a secondary device, and a cloud device, and the method is performed by the primary device. The method includes sending a first identity notification to the cloud device, where the first identity notification is a notification indicating that the primary device has a primary device identity, and uploading obtained first user information to the cloud device when determining that a communication status of the cloud device is normal, where the first user information is stored by the cloud device and provided to the secondary device, and the first user information is to-be-backed-up information of user equipment that gets online from the primary device when the communication status of the cloud device is normal.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TERRELL S JOHNSON whose telephone number is (571)270-3485. The examiner can normally be reached 10AM-7PM EST M-F.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/TERRELL S JOHNSON/Primary Examiner, Art Unit 2176
1 Administrator communicating with a router remotely in a command line interface is well-known and conventional in the art