DETAILED ACTION
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 Objections
Claim 7 is objected to because of the following informalities:
In claim 7, the claim recites the following limitation: “from the central manger via the third connection” in line 9. The word “manger” should be changed to “manager”.
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.
Claim 9 is 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.
Claim 9 recites the limitation "the remove activation server" in lines 7 and 8 in claim 9. However, upon examining the claim, there is no previous mention of a “remote activation server” or an activation server.
Therefore, there is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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, 5-7, 9-13, 15, and 17-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Cohen et al. (US 20180034888) hereinafter Cohen.
Regarding claim 1, Cohen teaches a method comprising:
establishing, by a local activate server agent of a first local branch computer network of a plurality of local branch computer networks (see Fig. 1 cloud service infrastructure 108 including cloud server 110; see also cloud-based management system 100 in Fig. 1 including a plurality of computer networks 112, 106, 116, etc. (i.e. a plurality of local branch computer networks)), a first connection with an activate server of a central computer system (see Fig. 2 management agent 204 in computer 106 (i.e. central computer system); see also Fig. 4 step 410 and [0055]: The example interchange of FIG. 4 begins with a pairing request 410 (i.e. establishing a first connection) from the agent 400. The pairing request includes an identification of the managed device 104), wherein the activate server manages network device validation information corresponding to the plurality of local branch computer networks (see [0045-46]: In some embodiments the discovery agent 220 requests an authorization token (i.e. the network device validation information) from the cloud service infrastructure 108 and broadcasts the authorization token on the local network. Potential managed devices, such as the managed device 104, may be configured to respond to the broadcast if they recognize the authenticity of the authorization token (i.e. managing device validation information). The discovery agent 220 may be included with the management agent 204 as a single software package capable of performing both discovery and management functions; see also [0057]: ... As a result, the user or the agent 400 ((i.e. management agent 204 as disclosed in [0054]) may now manage, monitor, generate reports, receive alerts, etc. with respect to managed device 104, or perform or use other tasks, components, or features within the capabilities of the cloud service infrastructure 108 or the managed device 104 as permitted by any permissions, groups, roles, or profiles (i.e. managing network device validation information) imposed by the cloud service infrastructure 108 or the cloud-based management system 100);
communicating, by the local activate server agent, with the activate server over the first connection to receive network device validation information for a given network device (see Fig. 2 managed device 104) associated with an entity (i.e. see Fig. 4 user 102) associated with the first local branch computer network (see Fig. 4 step 430 and [0056]: The cloud service infrastructure 108 also sends a pairing message 430 including both the unlock token and a pairing token (i.e. receiving the network device validation information) to the agent 400 (i.e. the activate server as disclosed in [0054]); see also [0045]: In some embodiments the discovery agent 220 (i.e. the activate server) requests an authorization token from the cloud service infrastructure 108 (i.e. receiving network device validation information) and broadcasts the authorization token on the local network);
responsive to the given network device connecting to the first local branch computer network, establishing a second connection between the given network device and the local activate server agent (see [0043]: When the managed device 104 is connected to power and a network, and has a basic or default configuration sufficient to communicate over the network 112, the managed device 104 will attempt to establish a channel 216 to communicate with the cloud service infrastructure 108 (i.e. establishing a second connection between the network device and the local activate server agent) using the network identifier); and
validating, by the local activate server agent, the given network device based on the network device validation information for the given network device, wherein the validating comprises the local activate server agent communicating with the given network device over the second connection (see [0043]: the managed device 104 will attempt to establish a channel 216 (i.e. the second connection) to communicate with the cloud service infrastructure 108 using the network identifier. The managed device 104 will then provide to the cloud service infrastructure 108 identifying information representative of the managed device 104; see also Fig. 4 step 460 and [0056]: The cloud service infrastructure 108 may perform a validation 460 of the pairing token, such as by matching it to the pairing token sent in the pairing message 430, which was previously sent in response to the pairing request 410 ... Upon validating the received pairing token the cloud service infrastructure 108 also records an entry in the database that the user, or optionally the agent 400, is now associated, or paired, with the managed device 104, and the cloud service infrastructure 108 sends a confirmation message 470 to the agent 400. The agent 400 may indicate to the user that the pairing was successful (i.e. communicating with the network device over the second connection)).
Regarding claim 2, Cohen is applied as disclosed in claim 1 examined above. The Cohen reference teaches a method comprising validating the given network device based on the network device validation information for the given network device. Furthermore, Cohen teaches a method wherein validating the given network device comprises receiving, by the local activate server agent, a device identifier of the given network device and verifying, by the local activate server agent, that the device identifier has an associated license (see [0004]: The controller is configured to communicate with at least one of a cloud service or an agent via the network interface, send an identifier of the managed device to at least one of the cloud service or the agent, receive one or more tokens from at least one of the cloud service or the agent, validate the one or more tokens, and receive management information from the cloud service; see also [0043]: In such embodiments, the managed device 104 is pre-configured with a network identifier to make contact with the cloud service infrastructure 108. The network identifier may include a URL, domain name, or IP address, or any combination of these identifiers or others. When the managed device 104 is connected to power and a network, and has a basic or default configuration sufficient to communicate over the network 112, the managed device 104 will attempt to establish a channel 216 to communicate with the cloud service infrastructure 108 using the network identifier; see Fig. 4 step 460).
Regarding claim 3, Cohen is applied as disclosed in claim 1 examined above. The Cohen reference further teaches a method wherein validating the network device comprises receiving, by the local activate server agent, a device type of the given network device and verifying, by the local activate server agent, that the device type is compatible with the first local branch computer network (see [0050]: Whereas the cloud service infrastructure 108 may determine that devices of a certain manufacturer, or of a certain serial number or MAC address, are suited to management by the cloud service infrastructure 108 and therefore determine that such devices, e.g., managed device 104, are of interest and the cloud service infrastructure 108 may attempt to communicate with such devices to establish cloud based management).
Regarding claim 5, Cohen is applied as disclosed in claim 1 examined above. Cohen teaches a method further comprising:
detecting, by the local server activate agent, a communication from a local central server agent of the first local branch computer network (see Fig. 4 step 410 and [0055]: The example interchange of FIG. 4 begins with a pairing request 410 from the agent 400. The pairing request includes an identification of the managed device 104);
responsive to detection of the communication, sending, by the local server activate agent, information to the local central server agent to allow the local central server agent to connect to a central manager (see Fig. 4 step 430 and [0056]), wherein the central manger manages network devices of the plurality of local branch computer networks (see [0030]: In a conventional management configuration, the local computer system 106 runs a management agent 204, which is a software package that provides monitoring and management capability. The management agent 204 typically manages a number of the various IT equipment 202); and
communicating, by the local central server agent, with the central manager to establish a third connection between the local central server agent and the central manager (see Fig. 2 channel 218 and [0034]: The cloud service infrastructure 108 also provides a protocol interface capable of communicating with the management agent 204 through a communication channel 218 across the network 112, such that the managed device 104 does not need to support such a protocol for, or communicate directly with, the management agent 204; see Fig. 4 step 470).
Regarding claim 6, Cohen is applied as disclosed in claim 5 examined above. Furthermore, Cohen teaches a method further comprising:
maintaining, by the local central server agent, an inventory of network devices of the first local branch computer network (see [0050-51]: Other devices may be interesting because they are manufactured by competitors or provide capabilities of interest or may provide business opportunities for, e.g., service contracts, upgrade, or replacement, etc. and cloud service infrastructure 108 may therefor maintain a database of such devices for follow up with users, such as local user 102 and/or remote user 114 ... Additionally, in some embodiments the cloud service infrastructure 108 will include a database of MAC addresses for devices manufactured by one or more manufacturers. The database may further include the model number and/or serial number of the device associated with each MAC address); and
responsive to successful validation of the given network device by the local activate server agent, adding, by the local central server agent, the given network device to the inventory (see [0053]: FIG. 4 illustrates one embodiment of an interchange of messages that can authenticate and associate an owner or user of a device to be managed in a cloud-based management system. The interchange of messages illustrated in FIG. 4 associates or pairs the owner or user with the device to be managed, and the pairing may be recorded in a database maintained by the cloud service infrastructure 108).
Regarding claim 7, Cohen is applied as disclosed in claim 5 as examined above. The Cohen reference further teaches a method comprising:
receiving, by the local central server agent, first messages from respective network devices of the first local branch computer network (see [0044]: The discovery agent 220 may discover devices by passively listening to the network or by probing the network with discovery request messages. Probing the network may include probing a set of possible addresses with low layer protocols, such as Address Resolution Protocol (ARP) or Internet Control Message Protocol (ICMP) messages; probing with higher layer protocols, which may include support for a User Datagram Protocol (UDP) broadcast request for all devices to respond, if so configured; probing for well-known ports; or probing for a specific protocol, for example);
consolidating, by the local central server agent, the first messages to provide first consolidated data (see [0047]: The result of the discovery processes described is that the discovery agent 220 compiles a list of device identifiers, typically including MAC addresses and IP address, and possibly including port numbers, device names, and the like);
sending, by the local central server agent, the first consolidated data to the central manager via the third connection (see [0049]: In other embodiments the management agent 204 may receive and sort the list, and may compile statistics);
receiving, by the local central server agent, second consolidated data from the central manger via the third connection (see [0052]: The cloud service infrastructure 108 will compile statistical information about the discovered devices at block 312 and will sort the discovered devices into groups at block 314. Devices that are not of interest may be identified but ignored at block 316);
separating the second consolidated data into second messages (see [0052]: The cloud service infrastructure 108 will sort the discovered devices into groups at block 314 (i.e. separate the consolidated data). The cloud service infrastructure 108 identifies devices of particular interest, e.g., devices that may be managed by the cloud service infrastructure 108, at block 318 and the cloud service infrastructure 108 may attempt to associate and manage these devices at block 320 and block 322, respectively); and
sending, by the local central server agent, the second messages to respective network devices of the first local branch computer network (see Fig. 3 steps 320 and 322 and [0052]: the cloud service infrastructure 108 may attempt to associate and manage these devices at block 320 and block 322, respectively).
Regarding claim 9, Cohen teaches a system comprising:
a plurality of network devices including a first network device (see Fig. 2 items 104, 202, etc.); and
a local activate server agent of a first branch computer network (see Fig. 1 cloud service infrastructure 108 including cloud server 110; see also cloud-based management system 100 in Fig. 1 including a plurality of computer networks 112, 106, 116, etc. (i.e. a plurality of local branch computer networks)), the local activation agent to:
provide, to a cloud-based remote activate server, a customer credential associated with the first branch computer network to establish a first connection between the local activate server agent and the remote activation server (see Fig. 4 step 410 and [0055]: The example interchange of FIG. 4 begins with a pairing request 410 (i.e. establishing a first connection) from the agent 400. The pairing request includes an identification of the managed device 104 (i.e. customer credential)), wherein the remote activation server is associated with a plurality of branch computer networks including the first branch computer network (see [0023]: Although only one local user 102 and one local computer system 106, and only one remote user 114 and one remote computer system 116, is shown in FIG. 1, embodiments disclosed herein may interact with one or more users via one or more computer systems, such as additional local users, local computer systems, remote users, and remote computer systems. In addition, although only one managed device 104 is shown in FIG. 1, embodiments disclosed herein are not limited to a particular number of managed devices and several embodiments include multiple managed devices of various types; see also [0030-31]: The management agent 204 typically manages a number of the various IT equipment 202);
retrieve, via the first connection, network device validation information from the remote activate server (see [0034]: This architecture also allows the cloud service infrastructure 108 to receive monitoring and management information about the managed device 104 that it otherwise may not have, and allows the cloud service infrastructure 108 to provide monitoring and management to the managed device 104 that it otherwise may not have; see also Fig. 4 step 430 and [0056]: The cloud service infrastructure 108 also sends a pairing message 430 including both the unlock token and a pairing token to the agent 400); and
responsive to the first network device connecting to the first branch computer network, communicate with the first network device to validate the first network device based on the network device validation information (see [0043]: the managed device 104 will attempt to establish a channel 216 (i.e. the second connection) to communicate with the cloud service infrastructure 108 using the network identifier. The managed device 104 will then provide to the cloud service infrastructure 108 identifying information representative of the managed device 104; see also Fig. 4 step 460 and [0056]: The cloud service infrastructure 108 may perform a validation 460 of the pairing token, such as by matching it to the pairing token sent in the pairing message 430, which was previously sent in response to the pairing request 410 ... Upon validating the received pairing token the cloud service infrastructure 108 also records an entry in the database that the user, or optionally the agent 400, is now associated, or paired, with the managed device 104, and the cloud service infrastructure 108 sends a confirmation message 470 to the agent 400. The agent 400 may indicate to the user that the pairing was successful (i.e. communicating with the network device over the second connection)).
Regarding claim 10, Cohen is applied as disclosed in claim 9 examined above. The Cohen reference further teaches a system comprising:
a local central server agent of the first branch computer network, the local central server agent to:
receive connection information from the local activate server agent to allow the local central server agent to establish a second connection with a remote cloud-based central server (see [0045]: In some embodiments the discovery agent 220 requests an authorization token from the cloud service infrastructure 108 and broadcasts the authorization token on the local network. Potential managed devices, such as the managed device 104, may be configured to respond to the broadcast if they recognize the authenticity of the authorization token);
receive data from the plurality of network devices (see [0045]: Potential managed devices, such as the managed device 104, may be configured to respond to the broadcast if they recognize the authenticity of the authorization token); and
communicate the data received from the plurality of network devices to the remote central server via the second connection (see [0049]: According to at least one embodiment, the discovery agent 220 communicates with the cloud service infrastructure 108 to provide a list of identifiers associated with the devices attached to the network).
Regarding claim 11, Cohen is applied as disclosed in claim 10 examined above. The Cohen reference further teaches a system wherein:
the remote central server to process the data communicated to the remote central server by the local central server agent (see [0049]: The cloud service infrastructure 108 sorts the list to identify devices of particular interest, devices that are interesting, and devices that are not of interest. The cloud service infrastructure 108 may also compile statistical data about the devices, such as number of devices, manufacturer identities, etc., and the cloud service infrastructure 108 may make the statistical data available to users 102, 114, or others); and
the local central server agent to communicate, via the second connection, with the remote central server to receive data representing a result of the processing (see [0057]: In various embodiments, the result of the process discussed above is that the managed device 104 becomes associated, or paired, with the user's account or with the agent 400. As a result, the user or the agent 400 may now manage, monitor, generate reports, receive alerts, etc. with respect to managed device 104, or perform or use other tasks, components, or features within the capabilities of the cloud service infrastructure 108 or the managed device 104 as permitted by any permissions, groups, roles, or profiles imposed by the cloud service infrastructure 108 or the cloud-based management system 100).
Regarding claim 15, it teaches the same limitations as claim 6 examined above. Therefore, the same rationale of rejection is applied.
Regarding claim 17, Cohen teaches a non-transitory storage medium that stores machine-readable instructions that correspond to a local activate server agent of a first local network, and when executed by a machine of the first local network, cause the machine to:
provide, to a cloud-based activate server, a credential associated with a subscription identification to establish a first connection between the local activate server agent and the activate server (see Fig. 4 step 410 and [0055]: The example interchange of FIG. 4 begins with a pairing request 410 (i.e. establishing a first connection) from the agent 400. The pairing request includes an identification of the managed device 104 (i.e. customer credential)), wherein the activate server manages network device validation information for a plurality of local computer networks including the first local branch computer network (see [0023]: Although only one local user 102 and one local computer system 106, and only one remote user 114 and one remote computer system 116, is shown in FIG. 1, embodiments disclosed herein may interact with one or more users via one or more computer systems, such as additional local users, local computer systems, remote users, and remote computer systems. In addition, although only one managed device 104 is shown in FIG. 1, embodiments disclosed herein are not limited to a particular number of managed devices and several embodiments include multiple managed devices of various types; see also [0030-31]: The management agent 204 typically manages a number of the various IT equipment 202);
retrieve, via the first connection, network device validation information corresponding to a plurality of network devices associated with the subscription identification see [0034]: This architecture also allows the cloud service infrastructure 108 to receive monitoring and management information about the managed device 104 that it otherwise may not have, and allows the cloud service infrastructure 108 to provide monitoring and management to the managed device 104 that it otherwise may not have; see also Fig. 4 step 430 and [0056]: The cloud service infrastructure 108 also sends a pairing message 430 including both the unlock token and a pairing token to the agent 400); and
responsive to a first network device of the plurality of network devices connecting to the first local branch computer network, communicate with the first network device to validate the first network device based on a subset of the network device validation information corresponding to the first network device ((see [0043]: the managed device 104 will attempt to establish a channel 216 (i.e. the second connection) to communicate with the cloud service infrastructure 108 using the network identifier. The managed device 104 will then provide to the cloud service infrastructure 108 identifying information representative of the managed device 104; see also Fig. 4 step 460 and [0056]: The cloud service infrastructure 108 may perform a validation 460 of the pairing token, such as by matching it to the pairing token sent in the pairing message 430, which was previously sent in response to the pairing request 410 ... Upon validating the received pairing token the cloud service infrastructure 108 also records an entry in the database that the user, or optionally the agent 400, is now associated, or paired, with the managed device 104, and the cloud service infrastructure 108 sends a confirmation message 470 to the agent 400. The agent 400 may indicate to the user that the pairing was successful (i.e. communicating with the network device over the second connection)).
Regarding claim 18, Cohen is applied as disclosed in claim 17 examined above. The Cohen reference further teaches a system wherein the instructions, when executed by the machine, further cause the machine to retrieve the network validation information prior to any network device of the plurality of network devices initially connecting to the first local branch computer network (see [0005]: In embodiments, the controller is further configured to receive authorization from a user before at least one of communicating, sending an identifier, and validating the one or more tokens).
Regarding claim 19, Cohen is applied as disclosed in claim 17 examined above. The Cohen reference further teaches a system wherein the instructions, when executed by the machine, further cause the machine to:
monitor a port for a communication from a local central server agent of the first local branch computer network, wherein the local central server agent is associated with a cloud-based central server, and the central server performs network device analytics processing for the plurality of local computer networks (see Fig. 4 step 410 and [0055]: The example interchange of FIG. 4 begins with a pairing request 410 from the agent 400. The pairing request includes an identification of the managed device 104. The cloud service infrastructure 108 may optionally determine whether the user is authorized to associate this particular managed device 104 to the user, whether the managed device 104 is already associated with another user, whether it is permissible to be associated with multiple users, and whether the association will be trusted, e.g., whether the user is authorized to communicate on the local network or whether the user is able to communicate on the local network);
responsive to detection of the communication, validate the local central server agent (see Fig. 4 step 460 and [0056]: The cloud service infrastructure 108 may perform a validation 460 of the pairing token, such as by matching it to the pairing token sent in the pairing message 430, which was previously sent in response to the pairing request 410); and
responsive to validation of the local central server agent, provide connection information to the local central server agent to allow the local central server agent to form a connection with the central server (see Fig. 4 step 470 and [0056]: Upon validating the received pairing token the cloud service infrastructure 108 also records an entry in the database that the user, or optionally the agent 400, is now associated, or paired, with the managed device 104, and the cloud service infrastructure 108 sends a confirmation message 470 to the agent 400. The agent 400 may indicate to the user that the pairing was successful).
Regarding claim 20, Cohen is applied as disclosed in claim 19 examined above. The Cohen reference further teaches a system wherein the instructions, when executed by the machine, further cause the machine to, responsive to the validation of the first network device, provide connection information to the first network device to allow the first network device to form a connection with the local central server agent (see [0057]: In various embodiments, the result of the process discussed above is that the managed device 104 becomes associated, or paired, with the user's account or with the agent 400. As a result, the user or the agent 400 may now manage, monitor, generate reports, receive alerts, etc. with respect to managed device 104, or perform or use other tasks, components, or features within the capabilities of the cloud service infrastructure 108 or the managed device 104 as permitted by any permissions, groups, roles, or profiles imposed by the cloud service infrastructure 108 or the cloud-based management system 100).
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.
Claims 4, 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Cohen et al. (US 20180034888) hereinafter Cohen in view of Onno et al. (US 20180077016) hereinafter Onno.
Regarding claim 4, Cohen is applied as disclosed in claim 1 as examined above. The Cohen reference further teaches a system wherein establishing a first connection with an activate server of a central computer system. However, Cohen fails to suggest a method wherein establishing the second connection comprises sending, by a dynamic host control protocol (DHCP) server, at least one of an address of the local activate server agent or a credential for the second connection to the given network device.
In the same field of endeavor as the Cohen reference, Onno teaches a method in accordance with the present invention, the method wherein establishing the second connection comprises sending, by a dynamic host control protocol (DHCP) server, at least one of an address of the local activate server agent or a credential for the second connection to the given network device (see [0099]: When such a connection is established (the tunnel 101 between the BRG 104 and the virtual gateway 100 is working), the vG agent 221 can activate (step 303) the DHCP server 223 to run the DHCP service on the virtual gateway 100 for that given BRG 104. Thus, the DHCP server 223 can allocate (step 304) IP addresses upon request from terminals 106 of the network 105 of the BRG 104 thanks to the DHCP two steps process. Configuration information (leases, subnet, subnet-mask, default lease time, maximum lease time, MAC address, etc.) associated with the allocated IP addresses by the DHCP server 223 is gathered in a vG address configuration (also called main address configuration), for instance, stored in the memory 225 (or, as a variant, in the DHCP server 223)).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to incorporate the teachings of Onno suggesting establishing a second connection by sending, by a DHCP server, at least one address of the local activate server agent to the given network device into the method taught by Cohen in order to provide connection information for establishing a communication between components of the system. The motivation for such combination would have been to simplifying network management and improve efficiency by automatically assigning IP address and network configuration settings to devices, eliminating the need for manual configuration.
Regarding claim 8, Cohen is applied as disclosed in claim 5 examined above. The Cohen reference teaches a method comprising responsive to detection of the communication from a local central server agent of the first local branch computer network, sending, by the local server activate agent, information to the local central server agent to allow the local central server agent to connect to a central manager.
predictively retrieving, by the local central server agent, firmware images for network devices of the first local branch computer network (see [0036]: the cloud service infrastructure 108 may request or be provided additional information from the managed device 104, and the cloud service infrastructure 108 may perform monitoring and management functions directed to the managed device 104. Additional information from the managed device 104 may include, but is not limited to, configuration information, hardware and firmware version numbers, optionally installed hardware, authorization and authentication information (e.g., security and encryption keys) to be discussed in more detail below, environmental information (e.g., temperature and humidity information), control information (e.g., information that triggers a function, such as a shutdown or self-test), performance information (e.g., efficiency, battery life), diagnostic information, alerts, and any other relevant information);
storing, by the local central server agent, the firmware images in a repository (see [0032]: The memory 212 and the storage 214 may also store information such as configuration settings, sensor or environmental data, statistical data, identifiers for various devices, such as the managed device 104 (itself) or the cloud service infrastructure 108, and any other suitable information).
However, the Cohen reference does not explicitly teach a method comprising:
performing firmware upgrades of the plurality of network devices, comprising retrieving, by the local central server agent, the firmware images from the repository.
In the same field of endeavor, Onno teaches a method comprising:
performing firmware upgrades of the plurality of network devices, comprising retrieving, by the local central server agent, the firmware images from the repository (see [0099]: Every time configuration information is updated, the vG address configuration is updated. The vG address configuration can be published (step 305) by the vG agent 221 to let the BRG 104 be aware of the update of the configuration information performed by the DHCP server 223 (when said BRG 104 has subscribed for receiving the vG address configuration)).
Regarding claim 16, it teaches the same limitations as claim 4 examined above. Therefore, the same rationale of rejection is applied.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Cohen et al. (US 20180034888) hereinafter Cohen in view of Carlen et al. (US 20140304398) hereinafter Carlen.
Regarding claim 14, Cohen is applied as disclosed in claim 10 examined above. The Cohen reference teaches a system comprising a local central server agent of the first branch computer network, the local central server agent to receive connection information from the local activate server agent to allow the local central server agent to establish a second connection with a remote cloud-based central server. However, the Cohen art does not explicitly teach a system wherein the local central server agent to responsive to detection of a failure of the first network device, communicate data to the first network device representing a last known good configuration for the first network device.
In the same field of endeavor as Cohen, Carlen is applied in accordance with the present invention, the Carlen reference suggesting a system wherein the local central server agent to responsive to detection of a failure of the first network device, communicate data to the first network device representing a last known good configuration for the first network device (see [0190-192]: In the process flow, in a step 1 (reference 1302), orchestration service instance 708 detects a failure of container 802. In one embodiment, orchestration service instance 708 may detect the failure by monitoring blackboard service 804 ... Instead of troubleshooting the failure and attempting to continue using service 706 in container 802, orchestration service instance 708 terminates the container ... In a step 3 (reference 1306), orchestration service instance 708 determines a last-known good state for service 706 ... The frozen file system may constitute the last known good state of service 706 and is a full image needed to restart the service from scratch. Since the changes have not been written to the known good state of service 706, orchestration service instance 708 can use this last-known good state with confidence that it will not fail).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the present invention to modify the local central server agent taught by the Cohen reference such that the local central server agent can, responsive to detection of a failure of the first network device, communicate the last known good configuration for the first network device. The motivation for such modification would have been to provide restoration of the device configuration in case of update failure, thereby preventing delays and providing fail-over capabilities when a component of the network fails.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PATRICK F NGANKAM whose telephone number is (571)270-3659. The examiner can normally be reached M-F 9:30-7:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton Burgess can be reached at (571) 272-3949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/P.F.N/Examiner, Art Unit 2454
/GLENTON B BURGESS/Supervisory Patent Examiner, Art Unit 2454
Prosecution Insights