DETAILED ACTION
This Action is in response to application/ communications filed on 05/01/2024.
Claims 1-19 are presented for examination. Claims 1, 11 and 17 are independent claims.
Claims 1-19 remain pending in this application.
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 .
Domestic Benefit/ National Stage Information
Acknowledgment is made of applicant's claim for benefit of provisional application 63/501,065 filed on 05/09/2023.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claim(s) 17 is/are objected to because of the following informalities:
Claim 17 recites the limitations “the new device configuration update” in last two lines. There is insufficient antecedent basis for this limitation in the claim. However, the claim recites “new device configuration” (see line 7) and “device configuration update” (see line 5).
Claim 17 recites the limitations “the past device configuration” in the last line. There is insufficient antecedent basis for this limitation in the claim. However, the claim recites “old device configuration” (see line 6).
Appropriate correction is required.
Claim Rejections - 35 USC § 112
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-2, 6-15 and 17-19 are 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.
Independent claims 1, 11 and 17 end with the concept “determining, based on the beacon value, whether to undo the device configuration update using the backup file” (for e.g., see last limitation of representative claim 1). However, the claims end at the determination step without clarifying on how exactly the determination made in this step is being used to undo/ rollback the device configuration update. The instant claims only determine beacon value to make roll back decisions, without actually performing configuration rollback and/or deletion. The recited concept thus only amounts to inspecting the beacon value to arrive at a decision, without any post-decision action(s), thereby making the claims:
indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention; and/or
incomplete for omitting essential steps, amounting to a gap.
Dependent claims 2, 6-10, 12-15 and 18-19 do not remedy the issue highlighted above, as same rationale applies. Therefore, claims 2, 6-10, 12-15 and 18-19 are also rejected for the same reasons as set forth above in claims 1, 11 and 17. The post-decision action steps are recited in parts in claims 3-5 & 16.. Applicant is encouraged to amend the independent claims to include complete inventive steps as depicted in Fig.2 which removes the ambiguity as to how the beacon value is used in actually performing rollback.
Depending claim 6 depends on claim 1 and recites, “wherein the beacon value comprises a timestamp indicative of a time the beacon value was obtained from the beacon service by the first managed device”. However, it is not clear how the beacon service can know the timestamp indicative of a time the beacon value will be obtained by the first managed device before sending the beacon value comprising the timestamp. In other words, to be able to compose a message comprising a timestamp indicating when the message is obtained at the receiver, the message needs to be sent first. Therefore, timestamp indicating when the message is obtained at the receiver cannot be determined before the transmitter even sends the message (i.e. if the message is not yet transmitted).
Claim 6 and 9 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Depending claim 6 depends on claim 1 and recites, “wherein the beacon value comprises a timestamp indicative of a time the beacon value was obtained from the beacon service by the first managed device”.
A review of the applicant’s specification, as originally filed, was conducted. It appears that the concept claimed in the dependent claim 6 is not described in the specification and/or drawings.
Issues of adequate written description arise for original claims when an aspect of the claimed invention has not been described with sufficient particularity such that one skilled in the art would recognize that the inventor had possession of the claimed invention at the time of filing (see MPEP 2163.I.A). The claimed invention as a whole may not be adequately described if the claims require an essential or critical feature which is not adequately described in the specification and which is not conventional or known in the art (see MPEP 2163.I.A). Therefore, claim 6 is rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement.
Depending claim 9 depends on claim 1 and recites, “wherein obtaining the beacon value from the beacon service comprises establishing secure communications between the first managed device and the beacon service using a key, the key being indicative of an identification of the device configuration update”.
A review of the applicant’s specification, as originally filed, was conducted. It appears that the concept claimed in the dependent claim 6 is not described in the specification and/or drawings.
Issues of adequate written description arise for original claims when an aspect of the claimed invention has not been described with sufficient particularity such that one skilled in the art would recognize that the inventor had possession of the claimed invention at the time of filing (see MPEP 2163.I.A). The claimed invention as a whole may not be adequately described if the claims require an essential or critical feature which is not adequately described in the specification and which is not conventional or known in the art (see MPEP 2163.I.A). Therefore, claim 9 is rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement.
Examiner’s Note Regarding Claim Rejections - 35 USC § 101
During examination, the application was reviewed for potential rejection under 35 USC § 101 (revised Step 2A, two-prong test). The independent claims recite limitations:
receiving, by a first managed device, a device configuration update, wherein the device configuration update includes an identifier for a beacon service;
causing the first managed device to generate and store a backup file for the first managed device;
updating the first managed device using the device configuration update;
upon detecting an expiration of a check-in timer, obtaining, by the first managed device, a beacon value from the beacon service; and
determining, based on the beacon value, whether to undo the device configuration update using the backup file.
Examiner found that such claimed invention, as a whole, integrates any judicial exception, if present, into a practical application. For instance, the claimed invention updates managed devices in a network, such as routers, to ensure that any updates may be rolled back or undone, even if connectivity to the managed devices is limited or non-existent (see [0016]). In addition, disclosed invention provides that the managed devices can communicate with the beacon service to obtain a beacon value, and after obtaining a beacon value, the managed devices may each determine what to do based on the beacon value (see [0027]). Since the claim as a whole integrates the judicial exception into a practical application, the claim is not directed to a judicial exception (Step 2A: NO) and is eligible under 35 USC § 101.
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 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.
Claim(s) 1-3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1).
NOTE: The cited reference to Wan (WO 2017211091 A1) is a WIPO publication, designating US, but published in Chinese. A machine translated English version along with the original publication in Chinese is attached herewith as a single file. For citation reason, please refer to the machine translated English version/ portion of the document.
Regarding claim 1, Wan discloses a method for updating managed devices in a network (see Abstract on page 1: method and device for configuring a network access apparatus; also see page 7 lines 11-15 regarding Distribution Point Unit (DPU) as "managed devices in a network"; server to manage configuration and status information of all network access (i.e., DPU) devices under the subordinate), comprising:
receiving, by a first managed device, a device configuration update (see Abstract on page 1: receiving the configuration file issued by the data storage server; also see "Summary of the Invention" section on page 2; Receiving, by the network access device, configuration file information that is sent by the storage server in response to the request), wherein the device configuration update includes an identifier for a beacon service (see second-last paragraph on page 2; the configuration file information further includes: a configuration file name and a file server information; also see third paragraph on page 8; The push information includes the file server address, the account number, and the corresponding configuration file name; examiner articulates that file server information/ address corresponds to "an identifier for a beacon service"); and
updating the first managed device using the device configuration update (see Abstract on page 1: updating, according to the configuration file, a configuration of the network access apparatus; also see "Summary of the Invention" section on page 2; The basic configuration file is used to record general configuration information of the network access device; network access device updates the configuration of the network access device according to the configuration file information).
Wan does not explicitly disclose causing the first managed device to generate and store a backup file for the first managed device; upon detecting an expiration of a check-in timer, obtaining, by the first managed device, a beacon value from the beacon service; and determining, based on the beacon value, whether to undo the device configuration update using the backup file.
However, in an analogous art, Subbaiah discloses causing the first managed device to generate and store a backup file for the first managed device (see Col.3: lines 39-60; a known or understood configuration (e.g., a default configuration) corresponds to stored backup configuration/ file; also see Col.5: lines 4-6; the one or more other configurations stored in the candidate configuration data structure);
updating the first managed device using the device configuration update (see Col.2: lines 56-61; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process);
upon detecting an expiration of a check-in timer, obtaining, by the first managed device, a beacon value from the beacon service (see Col.6: lines 1-3; the network device may determine that the time of reception (the network device receiving the second message) occurred after the end time of the period of time (e.g., after expiration of the period of time); also see Fig.1C:125 in view of Col.5: lines 40-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration; examiner articulates that detecting the expiration of the period of time corresponds to “detecting an expiration of a check-in timer”; examiner also articulates that receiving the second message that include syntax such as “confirm new_configuration” corresponds to obtaining a beacon value from the beacon service upon detecting an expiration of a check-in timer); and
determining, based on the beacon value (see Fig.1B:115 as well as Fig.1C:125 in view of Col.5: lines 40-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration), whether to undo the device configuration update using the backup file (see Col.2: lines 56-65; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process. As part of the process, a “commit” message is sent to the network device to cause the network device to operate according to the new configuration for a period of time. If the network device does not receive a “confirmation” message before expiration of the period of time, the network device rolls back to operating according to the particular configuration (e.g., that was previously active); also see Col.3: lines 39-52; when the new configuration is not confirmed, the network device is configured to automatically roll back to operating according to a preferred configuration; the preferred configuration may be a known or understood configuration (e.g., a default configuration); also see Fig.5:560).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbaiah with Wan to cause the first managed device to generate and store a backup file for the first managed device; update the first managed device using the device configuration update; and to determine, based on the beacon value, whether to undo the device configuration update using the backup file.
One of ordinary skill in the art would have been motivated to test the new configuration of the network device during the period of time, and to prevent permanent installation of the new configuration on the network device without an explicit confirmation (see Subbaiah Col.2: line 65 – Col.3: line 2), and/or to allow the one or more issues to be addressed (e.g., via a software change and/or hardware change to the network device), which leads to an improved performance of the network device (see Subbaiah Col.3: lines 56-60).
Regarding claim 2, Wan (modified by Subbaiah) discloses the method of claim 1, as set forth above. In addition, Subbaiah further discloses wherein the beacon value comprises one of a wait command, a complete command (Fig.1C:125 in view of Col.5: lines 35-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration; confirmation of the new configuration is received by the network device prior to expiration of the period of time; also see Col.2: lines 56-65; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process), or a rollback command (see Col.3: lines 39-52; when the new configuration is not confirmed, the network device is configured to automatically roll back to operating according to a preferred configuration… such as a user specified configuration; the preferred configuration may be a known or understood configuration (e.g., a default configuration); also see Fig.5:560).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbaiah with Wan so that the beacon value comprises one of a wait command, a complete command, or a rollback command.
One of ordinary skill in the art would have been motivated to test the new configuration of the network device during the period of time, and to prevent permanent installation of the new configuration on the network device without an explicit confirmation (see Subbaiah Col.2: line 65 – Col.3: line 2), and/or to allow the one or more issues to be addressed (e.g., via a software change and/or hardware change to the network device), which leads to an improved performance of the network device (see Subbaiah Col.3: lines 56-60).
Regarding claim 3, Wan (modified by Subbaiah) discloses the method of claim 2, as set forth above. In addition, Subbaiah further discloses determining that the beacon value comprises the rollback command (see Col.3: lines 39-52; when the new configuration is not confirmed, the network device is configured to automatically roll back to operating according to a preferred configuration… such as a user specified configuration; the preferred configuration may be a known or understood configuration (e.g., a default configuration); also see Fig.5:560); and
based on determining that the beacon value comprises the rollback command, undoing the device configuration update using the backup file (see Col.3: lines 39-52; when the new configuration is not confirmed, the network device is configured to automatically roll back to operating according to a preferred configuration… such as a user specified configuration; the preferred configuration may be a known or understood configuration (e.g., a default configuration); also see Fig.5:560).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbaiah with Wan so that determining that the beacon value comprises the rollback command; and based on determining that the beacon value comprises the rollback command, undoing the device configuration update using the backup file.
One of ordinary skill in the art would have been motivated to test the new configuration of the network device during the period of time, and to prevent permanent installation of the new configuration on the network device without an explicit confirmation (see Subbaiah Col.2: line 65 – Col.3: line 2), and/or to allow the one or more issues to be addressed (e.g., via a software change and/or hardware change to the network device), which leads to an improved performance of the network device (see Subbaiah Col.3: lines 56-60).
Regarding claim 10, Wan (modified by Subbaiah) discloses the method of claim 1, as set forth above. In addition, Subbaiah further discloses wherein the beacon service sets a length of time of the check-in timer (see Col.5: lines 19-35; the network device may be configured to allow the new configuration to be stored in the running configuration data structure until expiration of the period of time).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbaiah with Wan so that the beacon service sets a length of time of the check-in timer.
One of ordinary skill in the art would have been motivated to test the new configuration of the network device during the period of time, and to prevent permanent installation of the new configuration on the network device without an explicit confirmation (see Subbaiah Col.2: line 65 – Col.3: line 2), and/or to allow the one or more issues to be addressed (e.g., via a software change and/or hardware change to the network device), which leads to an improved performance of the network device (see Subbaiah Col.3: lines 56-60).
Regarding claim 17, Wan discloses a system (see second-last paragraph on page 5; FIG.1 shows network access device 103 and the system architecture diagram) for updating managed devices in a network (see Abstract on page 1: method and device for configuring a network access apparatus; also see page 7 lines 11-15 regarding Distribution Point Unit (DPU) as "managed devices in a network"; server to manage configuration and status information of all network access (i.e., DPU) devices under the subordinate), comprising:
one or more managed devices (see page 7 lines 11-15 regarding Distribution Point Unit (DPU) as "managed devices in a network"; server to manage configuration and status information of all network access (i.e., DPU) devices under the subordinate), the one or more managed devices comprising at least one processor (see 10th paragraph on page 15), and memory (see last paragraph on page 17), operatively connected to the at least one processor and storing instructions that, when executed by the at least one processor, cause the system to:
receive a device configuration update (see Abstract on page 1: receiving the configuration file issued by the data storage server; also see "Summary of the Invention" section on page 2; Receiving, by the network access device, configuration file information that is sent by the storage server in response to the request) that includes an identifier for a beacon service (see second-last paragraph on page 2; the configuration file information further includes: a configuration file name and a file server information; also see third paragraph on page 8; The push information includes the file server address, the account number, and the corresponding configuration file name; examiner articulates that file server information/ address corresponds to "an identifier for a beacon service"); and
update the one or more managed devices to a new device configuration using the device configuration update (see Abstract on page 1: updating, according to the configuration file, a configuration of the network access apparatus; also see "Summary of the Invention" section on page 2; The basic configuration file is used to record general configuration information of the network access device; network access device updates the configuration of the network access device according to the configuration file information).
Wan does not explicitly disclose generate and store a backup file of an old device configuration; communicate with the beacon service at a check-in interval to obtain a beacon value; and determine, based on the beacon value, whether to roll back the new device configuration update and use the backup file of the past device configuration.
However, in an analogous art, Subbaiah discloses generate and store a backup file of an old device configuration (see Col.3: lines 39-60; a known or understood configuration (e.g., a default configuration) corresponds to stored backup configuration/ file; also see Col.5: lines 4-6; the one or more other configurations stored in the candidate configuration data structure);
update the one or more managed devices to a new device configuration using the device configuration update (see Col.2: lines 56-61; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process);
communicate with the beacon service at a check-in interval to obtain a beacon value (see Col.6: lines 1-3; the network device may determine that the time of reception (the network device receiving the second message) occurred after the end time of the period of time (e.g., after expiration of the period of time); also see Fig.1C:125 in view of Col.5: lines 40-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration; examiner articulates that the expiration of the period of time corresponds to “check-in interval”; examiner also articulates that receiving the second message that include syntax such as “confirm new_configuration” corresponds to obtaining a beacon value by communicating with the beacon service at a check-in timer); and
determine, based on the beacon value (see Fig.1B:115 as well as Fig.1C:125 in view of Col.5: lines 40-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration), whether to roll back the new device configuration update and use the backup file of the past device configuration (see Col.2: lines 56-65; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process. As part of the process, a “commit” message is sent to the network device to cause the network device to operate according to the new configuration for a period of time. If the network device does not receive a “confirmation” message before expiration of the period of time, the network device rolls back to operating according to the particular configuration (e.g., that was previously active); also see Col.3: lines 39-52; when the new configuration is not confirmed, the network device is configured to automatically roll back to operating according to a preferred configuration; the preferred configuration may be a known or understood configuration (e.g., a default configuration); also see Fig.5:560).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbaiah with Wan to generate and store a backup file of an old device configuration; communicate with the beacon service at a check-in interval to obtain a beacon value; and to determine, based on the beacon value, whether to roll back the new device configuration update and use the backup file of the past device configuration.
One of ordinary skill in the art would have been motivated to test the new configuration of the network device during the period of time, and to prevent permanent installation of the new configuration on the network device without an explicit confirmation (see Subbaiah Col.2: line 65 – Col.3: line 2), and/or to allow the one or more issues to be addressed (e.g., via a software change and/or hardware change to the network device), which leads to an improved performance of the network device (see Subbaiah Col.3: lines 56-60).
Claim(s) 4 are rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Lee et al. (hereinafter, Lee, US 10303588 B2).
Regarding claim 4, Wan (modified by Subbaiah) discloses the method of claim 2, as set forth above. In addition, Subbaiah further discloses determining that the beacon value comprises the complete command (Fig.1C:125 in view of Col.5: lines 35-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration; confirmation of the new configuration is received by the network device prior to expiration of the period of time; also see Col.2: lines 56-65; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process).
Wan (modified by Subbaiah) does not explicitly disclose based on determining that the beacon value comprises the complete command, releasing the backup file from a memory of the first managed device.
However, in an analogous art, Lee discloses determining that the beacon value comprises the complete command (see Col.5: lines 62-63; the device may receive a test process completion signal); and
based on determining that the beacon value comprises the complete command, releasing the backup file from a memory of the first managed device (see Lee Col.6: lines 3-5; the device may delete the configuration data when receiving the test process completion signal).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lee with Wan and Subbaiah to determine that the beacon value comprises the complete command; and based on determining that the beacon value comprises the complete command, releasing the backup file from a memory of the first managed device.
One of ordinary skill in the art would have been motivated to prevent a malfunction that may occur when device boots due to temporary configuration data stored in the nonvolatile memory (see Lee Col.6: lines 1-3).
Claim(s) 5 are rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Wilson et al. (hereinafter, Wilson, US 7523097 B1).
Regarding claim 5, Wan (modified by Subbaiah) discloses the method of claim 2, as set forth above. Wan (modified by Subbaiah) does not explicitly disclose determining that the beacon value comprises the wait command; and upon expiration of an ultimate timer, and based on determining that the beacon value comprises the wait command, undoing the device configuration update using the backup file.
Wilson discloses determining that the beacon value comprises the wait command (see Col.11: lines 35-36; web server 28 (FIG. 2) issues a lock command to cause control unit 40 to lock the candidate configuration); and upon expiration of an ultimate timer, and based on determining that the beacon value comprises the wait command, undoing the device configuration update using the backup file (see Col.12: lines 25-46; Meanwhile, control unit 40 waits to receive a commit command from web server 28 (106). In the event control unit 40 does not receive a commit command, management module 48 compares timer 58 to a pre-set time limit (108). Control unit 40 continues to wait for the commit command as long as timer 58 is less than the time limit ("NO" branch). However, in the event that timer 58 exceeds the time limit, management module 48 reverts the operational configuration back to the previous operational configuration).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wilson with Wan and Subbaiah to determine that the beacon value comprises the wait command; and to undo the device configuration update using the backup file upon expiration of an ultimate timer based on determining that the beacon value comprises the wait command.
One of ordinary skill in the art would have been motivated so that a command set may be utilized to reliably restore an archived configuration (see Wilson Col.12: lines 66-67).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Tully et al. (hereinafter, Tully, US 20130103740 A1).
Regarding claim 8, Wan (modified by Subbaiah) discloses the method of claim 1, as set forth above, including obtaining the beacon value from the beacon service (see Fig.1B:115 as well as Fig.1C:125 in view of Col.5: lines 40-59). Wan (modified by Subbaiah) does not explicitly disclose connecting, by the first managed device, to the beacon service via a URL.
Vantalon discloses connecting, by the first managed device, to the beacon service via a URL (see [0016]; Upon construction of the web beacon request, the request URL is generated with the "yi13n://" protocol... the request to the web beacon is made with the "yi13n://" protocol).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Tully with Wan and Subbaiah to connect, by the first managed device, to the beacon service via a URL.
One of ordinary skill in the art would have been motivated to establishing a connection, so that the stored requests are made to the beacon server (see Tully [0016]).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Vantalon et al. (hereinafter, Vantalon, US 20060136702 A1).
Regarding claim 9, Wan (modified by Subbaiah) discloses the method of claim 1, as set forth above, including obtaining the beacon value from the beacon service (see Fig.1B:115 as well as Fig.1C:125 in view of Col.5: lines 40-59). Wan (modified by Subbaiah) does not explicitly disclose establishing secure communications between the first managed device and the beacon service using a key, the key being indicative of an identification of the device configuration update.
Vantalon discloses establishing secure communications between the first managed device and the beacon service using a key, the key being indicative of an identification of the device configuration update (see [0067]; The configuration server sends an update ID request (609) to the device using the secure communication channel established through the authentication messages and the key derivation messages. The update ID request includes the new identification information transmitted in an encrypted format to the device).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Vantalon with Wan and Subbaiah so that obtaining the beacon value from the beacon service comprises establishing secure communications between the first managed device and the beacon service using a key, the key being indicative of an identification of the device configuration update.
One of ordinary skill in the art would have been motivated to secure the process of configuring products (see Vantalon [0045]).
Claim(s) 11-12 is rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Charnauski et al. (hereinafter, Charnauski, US 11546338 B1).
Regarding claim 11, Wan discloses a method for updating a managed device in a network (see Abstract on page 1: method and device for configuring a network access apparatus; also see page 7 lines 11-15 regarding Distribution Point Unit (DPU) as "managed devices in a network"; server to manage configuration and status information of all network access (i.e., DPU) devices under the subordinate) comprising:
receiving a device configuration update (see Abstract on page 1: receiving the configuration file issued by the data storage server; also see "Summary of the Invention" section on page 2; Receiving, by the network access device, configuration file information that is sent by the storage server in response to the request) that includes an identifier for a beacon service (see second-last paragraph on page 2; the configuration file information further includes: a configuration file name and a file server information; also see third paragraph on page 8; The push information includes the file server address, the account number, and the corresponding configuration file name; examiner articulates that file server information/ address corresponds to "an identifier for a beacon service");
updating to a new device configuration using the device configuration update (see Abstract on page 1: updating, according to the configuration file, a configuration of the network access apparatus; also see "Summary of the Invention" section on page 2; The basic configuration file is used to record general configuration information of the network access device; network access device updates the configuration of the network access device according to the configuration file information).
Wan does not explicitly disclose generating and storing a backup file of a past device configuration; requesting a beacon value from the beacon service upon an expiration of a check-in timer; and determining, based on the beacon value, whether to roll back the new device configuration and use the backup file of the past device configuration.
However, in an analogous art, Subbaiah discloses generating and storing a backup file of a past device configuration (see Col.3: lines 39-60; a known or understood configuration (e.g., a default configuration) corresponds to stored backup configuration/ file; also see Col.5: lines 4-6; the one or more other configurations stored in the candidate configuration data structure);
updating to a new device configuration using the device configuration update (see Col.2: lines 56-61; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process);
(see Col.6: lines 1-3; the network device may determine that the time of reception (the network device receiving the second message) occurred after the end time of the period of time (e.g., after expiration of the period of time); also see Fig.1C:125 in view of Col.5: lines 40-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration); examiner articulates that detecting the expiration of the period of time corresponds to “detecting an expiration of a check-in timer”; examiner also articulates that receiving the second message that include syntax such as “confirm new_configuration” corresponds to obtaining a beacon value from the beacon service upon an expiration of a check-in timer); and
determining, based on the beacon value (see Fig.1B:115 as well as Fig.1C:125 in view of Col.5: lines 40-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration), whether to roll back the new device configuration and use the backup file of the past device configuration (see Col.2: lines 56-65; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process. As part of the process, a “commit” message is sent to the network device to cause the network device to operate according to the new configuration for a period of time. If the network device does not receive a “confirmation” message before expiration of the period of time, the network device rolls back to operating according to the particular configuration (e.g., that was previously active); also see Col.3: lines 39-52; when the new configuration is not confirmed, the network device is configured to automatically roll back to operating according to a preferred configuration; the preferred configuration may be a known or understood configuration (e.g., a default configuration); also see Fig.5:560).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbaiah with Wan to generate and store a backup file of a past device configuration; and to determine, based on the beacon value, whether to roll back the new device configuration and use the backup file of the past device configuration.
One of ordinary skill in the art would have been motivated to test the new configuration of the network device during the period of time, and to prevent permanent installation of the new configuration on the network device without an explicit confirmation (see Subbaiah Col.2: line 65 – Col.3: line 2), and/or to allow the one or more issues to be addressed (e.g., via a software change and/or hardware change to the network device), which leads to an improved performance of the network device (see Subbaiah Col.3: lines 56-60).
Although, and as set forth above, Subbaiah discloses obtaining a beacon value from the beacon service upon an expiration of a check-in timer (see Col.6: lines 1-3; also see Fig.1C:125 in view of Col.5: lines 40-59), Wan (modified by Subbaiah) does not explicitly disclose such beacon value is obtained from the beacon service by requesting.
Charnauski discloses requesting a beacon value from the beacon service upon an expiration of a check-in timer (see Col.:32: lines 6-9; system 110 can also routinely confirm the configuration of a mode, such as by requesting the user device 106 to confirm that a certain mode is to persist (e.g., freezing of all electronic activities) on a periodic basis (e.g., daily)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Charnauski with Wan and Subbaiah to request a beacon value from the beacon service upon an expiration of a check-in timer.
One of ordinary skill in the art would have been motivated to allow the system to be configured by third-party or an administrator (see Charnauski Col.18: line 49-50).
Regarding claim 12, Wan (modified by Subbaiah and Charnauski) discloses the method of claim 11, as set forth above. In addition, Subbaiah further discloses wherein the backup file of the past device configuration is stored in non-volatile memory (see Col.3: lines 39-52; when the new configuration is not confirmed, the network device is configured to automatically roll back to operating according to a preferred configuration… such as a user specified configuration; the preferred configuration may be a known or understood configuration (e.g., a default configuration); also see Fig.5:560; also see Col.4: lines 15-23 and 48-54; Upon receiving the active configuration, the network device may have stored the active configuration in a candidate configuration data structure (e.g., a database, a file, or another type of data structure), which is also referred to as a candidate configuration datastore; the candidate configuration data structure include the new configuration, the active configuration and one or more other configurations are different than each of the new configuration and the active configuration).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Subbaiah with Wan and Charnauski so that the backup file of the past device configuration is stored in non-volatile memory.
One of ordinary skill in the art would have been motivated to test the new configuration of the network device during the period of time, and to prevent permanent installation of the new configuration on the network device without an explicit confirmation (see Subbaiah Col.2: line 65 – Col.3: line 2), and/or to allow the one or more issues to be addressed (e.g., via a software change and/or hardware change to the network device), which leads to an improved performance of the network device (see Subbaiah Col.3: lines 56-60).
Claim(s) 13 is rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Charnauski et al. (hereinafter, Charnauski, US 11546338 B1) in view of Ugur-Ozekinci et al. (hereinafter, Ugur, US 10534760 B1).
Regarding claim 13, Wan (modified by Subbaiah and Charnauski) discloses the method of claim 12, as set forth above. Wan (modified by Subbaiah and Charnauski) does not explicitly disclose wherein the backup file of the past device configuration is stored on an external server in communication with the managed device.
Ugur discloses wherein the backup file of the past device configuration is stored on an external server in communication with the managed device (see Col.2: lines 17-23; A clone copy is created of a backup file stored on a disk… the backup application stores the clone copy on an external disk… The clone copy is recovered from the external destination node based on the backup parameters).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ugur with Wan, Subbaiah and Charnauski so the backup file of the past device configuration is stored on an external server in communication with the managed device.
One of ordinary skill in the art would have been motivated to restore a corrupted relational database (see Ugur Col.8: lines 53).
Claim(s) 14 is rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Charnauski et al. (hereinafter, Charnauski, US 11546338 B1) in view of LV et al. (hereinafter, LV, WO 2015103735 A1).
Regarding claim 14, Wan (modified by Subbaiah and Charnauski) discloses the method of claim 11, as set forth above. Wan (modified by Subbaiah and Charnauski) does not explicitly disclose rolling back the new device configuration and using the backup file of the past device configuration upon expiration of a polling timer.
LV discloses rolling back the new device configuration and using the backup file of the past device configuration upon expiration of a polling timer (see Abstract; when determining that a connectivity detection response message is not received in a time interval that is set, based on backup configuration information saved by itself, restoring configuration information of itself to an initial configuration).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of LV with Wan, Subbaiah and Charnauski to roll back the new device configuration and use the backup file of the past device configuration upon expiration of a polling timer.
One of ordinary skill in the art would have been motivated to ensure that a connection can be quickly established with the management device for re-configuration, and improving a fault tolerance rate of a configuration process (see LV, Abstract).
Claim(s) 15 is rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Charnauski et al. (hereinafter, Charnauski, US 11546338 B1) in view of Hassan et al. (hereinafter, Hassan, US 20110122774 A1).
Regarding claim 15, Wan (modified by Subbaiah and Charnauski) discloses the method of claim 11, as set forth above. Wan (modified by Subbaiah and Charnauski) does not explicitly disclose upon detecting an expiration of a burn-in timer, attempting to communicate with the beacon service to obtain a final beacon value.
Hassan discloses upon detecting an expiration of a burn-in timer, attempting to communicate with the beacon service to obtain a final beacon value (see [0012] and [0092]; attempting to reestablish a secure connection between a home router of the home network and the service provider network).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Hassan with Wan, Subbaiah and Charnauski to attempt to communicate with the beacon service to obtain a final beacon value upon detecting an expiration of a burn-in timer.
One of ordinary skill in the art would have been motivated to reestablish the secure connection when that connection fails (see Hassan, [0017]).
Claim(s) 16 are rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Charnauski et al. (hereinafter, Charnauski, US 11546338 B1) in view of Hassan et al. (hereinafter, Hassan, US 20110122774 A1) in view of Lee et al. (hereinafter, Lee, US 10303588 B2).
Regarding claim 16, Wan (modified by Subbaiah, Charnauski and Hassan) discloses the method of claim 15, as set forth above. In addition, Subbaiah further discloses determining that the beacon value comprises the complete command (Fig.1C:125 in view of Col.5: lines 35-59; the second message may be a confirm message and may include syntax such as “network device>confirm new_configuration; confirmation of the new configuration is received by the network device prior to expiration of the period of time; also see Col.2: lines 56-65; A network device (e.g., when operating according to a particular configuration) can be configured to operate according to a new configuration via a “confirmed commit” process).
Wan (modified by Subbaiah, Charnauski and Hassan) does not explicitly disclose if the final beacon value is ‘COMPLETE’, the method further comprises deleting the backup file of the past device configuration.
However, in an analogous art, Lee discloses if the final beacon value is ‘COMPLETE’ (see Col.5: lines 62-63; the device may receive a test process completion signal), the method further comprises deleting the backup file of the past device configuration (see Lee Col.6: lines 3-5; the device may delete the configuration data when receiving the test process completion signal).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lee with Wan, Subbaiah, Charnauski and Hassan to delete the backup file of the past device configuration if the final beacon value is ‘COMPLETE’.
One of ordinary skill in the art would have been motivated to prevent a malfunction that may occur when device boots due to temporary configuration data stored in the nonvolatile memory (see Lee Col.6: lines 1-3).
Claim(s) 19 is rejected under 35 U.S.C. 103 as being unpatentable over Wan (WO 2017211091 A1) in view of Subbaiah (US 11888695 B1) in view of Paningipalli et al. (hereinafter, Paningipalli, US 9804855 B1).
Regarding claim 19, Wan (modified by Subbaiah) discloses the system of claim 17, as set forth above. Wan (modified by Subbaiah) does not explicitly disclose wherein the backup file of the old device configuration comprises an operating system of the one or more managed devices.
However, in an analogous art, Paningipalli discloses wherein the backup file of the old device configuration comprises an operating system of the one or more managed devices (see Col.2: lines 10-28; backup image file includes at least an operating system).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Paningipalli with Subbaiah and Wan so that the backup file of the old device configuration comprises an operating system of the one or more managed devices.
One of ordinary skill in the art would have been motivated for efficiently restoring data to a different computing device (see Paningipalli Col.2: lines 10-11).
Allowable Subject Matter
Claim 6 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, as well as under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Claim 7 and 18 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Krueger et al. (US 20150172381 A1) discloses storing an update in an undo registry at the client device; waiting for a confirmation message from the server; and undoing the update if no confirmation message is received from the server after a predetermined period of time.
Stone et al. (US 20160196582 A1) teaches receiving, from a brand server, another configuration file with an updated list of service set identifiers (SSIDs) and beacon identifiers.
Bøgelund et al. (US 20170134532 A1) discloses transmitting a configuration information to the management server for updating a configuration table stored therein, wherein the configuration information comprises the identifier of the second recording server.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
/SANDARVA KHANAL/Primary Examiner, Art Unit 2453