DETAILED ACTION
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 1-3, 5-7, 9-13, 15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Cohen et al. (US 20180034888) hereinafter Cohen in view of Adhya et al. (US 20160036794) hereinafter Adhya.
Regarding claim 1, Cohen teaches a method comprising:
establishing, by a local activate server agent (Fig 2 item: management agent 204; Fig 4 item 400 “agent”) of a first local branch computer network (Fig 2, the local network connecting the components 204, 104 and 202) of (see Fig 2, [0030, 0034] wherein “In a conventional management configuration, the local computer system 106 runs a management agent 204 (a local activate server agent), 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”), a first connection (communication channel 218) with an activate server (Fig 2 item: 108/110) of a central computer system (see [0034], wherein “The cloud service infrastructure 108 (an activate server of a central computer system) also provides a protocol interface capable of communicating with the management agent 204 (first connection) through a communication channel 218 across the network 112”; 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 (see [0056]: wherein “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”);
communicating, by the local activate server agent, with the activate server over the first connection (see [0049, 0052]: wherein “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”; “The discovery agent 220 contacts the cloud service infrastructure 108 via the network 112 at block 306 and sends a list of discovered devices to the cloud service infrastructure 108 at block 310. Additionally, the discovery agent 220 may authenticate itself at block 308 before sending the list of discovered devices. 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. 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. Association of devices is discussed in more detail below. The cloud service infrastructure 108 also identifies other devices that are interesting at block 324 and may store a list of such devices at block 326 and may request additional information about these devices at block 328”) to receive network device validation information for a given network device (see [0054-0056]: wherein “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 … 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”);
(see [0043]: wherein “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)).
Cohen fails to explicitly disclose a plurality of local branch computer networks and that the validating is performed by the local activate server agent responsive to the given network device initiating a second connection with the local activate server agent. However, Adhya discloses a plurality of local branch computer networks (Adhya, see Fig. 2, [0024], wherein “Specifically, FIG. 2 illustrates a network that is deployed in at least a central office 270 and a number of branch offices, such as Branch.sub.A 260, . . . Branch.sub.N 269. Typically, branch offices are located physically remote from central office 270. As such, network devices at each branch office may be connected to network devices at central office 270 via Internet 250”) that the validating is performed by the local activate server agent responsive to the given network device initiating a second connection with the local activate server agent (Adhya, see Fig. 2, [0052, 0056-0057], wherein “FIG. 5 illustrates an exemplary process for determining whether to use a local authentication server according to embodiments of the present disclosure. During operations, a first network device executing a first authentication server receives a request for authentication from a client device (operation 500). The first authentication server then determines whether the client device was previously successfully authenticated by a second authentication server executing on a second network device within a particular period of time (operation 520). If so, the first authentication server at the first network device attempts to authenticate the client device using the first authentication server (operation 540). If not, the first authentication server at the first network device declines the request for authentication from the client device (operation 560)”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Adhya’s branch-local authentication technique into Cohen’s cloud-assisted device management system to achieve the claimed limitations because this would have permitted to locally validate managed devices using centrally supplied validation information and thus reducing continues dependency on connection to central remote system (see Adhya [0044-0045])
Regarding claim 2, Cohen is applied as disclosed in claim 1 examined above. 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 (Fig 2 item: management agent 204; Fig 4 item 400 “agent”) of a first branch computer network (Fig 2, the local network connecting the components 204, 104 and 202), the local activate agent to:
provide, to a cloud-based remote activate server (Fig 2 item: 108/110, 0034], wherein “The cloud service infrastructure 108 (an activate server of a central computer system) also provides a protocol interface capable of communicating with the management agent 204 (first connection) through a communication channel 218 across the network 112”;), a customer credential (see [0054], wherein “the agent 400 may be a certified component from another provider, also trusted by the cloud service infrastructure 108, or the user, e.g., local user 102 or remote user 114, may provide credentials such as a username and password associated with an account maintained by the cloud service infrastructure 108. In some embodiments, one or more of these examples will serve to credential the agent 400”) associated with the first branch computer network to establish a first connection (communication channel 218) between the local activate server agent and the cloud-based remote 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 cloud-based remote activate server is associated with a p (see [0034], wherein “The cloud service infrastructure 108 (an activate server of a central computer system) also provides a protocol interface capable of communicating with the management agent 204 (first connection) through a communication channel 218 across the network 112”; 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);
retrieve, via the first connection, network device validation information from the cloud-based remote activate server (see [0054-0056]: wherein “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 … 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”); and
(see [0043]: wherein “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)).
Cohen fails to explicitly disclose a plurality of local branch computer networks and that the validating is performed over the second connection responsive to the first network device initiating a second connection with the local activate server agent. However, Adhya discloses a plurality of local branch computer networks (Adhya, see Fig. 2, [0024], wherein “Specifically, FIG. 2 illustrates a network that is deployed in at least a central office 270 and a number of branch offices, such as Branch.sub.A 260, . . . Branch.sub.N 269. Typically, branch offices are located physically remote from central office 270. As such, network devices at each branch office may be connected to network devices at central office 270 via Internet 250”) that the validating is performed over the second connection responsive to the first network device initiating a second connection with the local activate server agent (Adhya, see Fig. 2, [0052, 0056-0057], wherein “FIG. 5 illustrates an exemplary process for determining whether to use a local authentication server according to embodiments of the present disclosure. During operations, a first network device executing a first authentication server receives a request for authentication from a client device (operation 500). The first authentication server then determines whether the client device was previously successfully authenticated by a second authentication server executing on a second network device within a particular period of time (operation 520). If so, the first authentication server at the first network device attempts to authenticate the client device using the first authentication server (operation 540). If not, the first authentication server at the first network device declines the request for authentication from the client device (operation 560)”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Adhya’s branch-local authentication technique into Cohen’s cloud-assisted device management system to achieve the claimed limitations because this would have permitted to locally validate managed devices using centrally supplied validation information and thus reducing continues dependency on connection to central remote system (see Adhya [0044-0045])
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 (Fig 2 item: 108/110, 0034], wherein “The cloud service infrastructure 108 (an activate server of a central computer system) also provides a protocol interface capable of communicating with the management agent 204 (first connection) through a communication channel 218 across the network 112”;), a credential associated with a subscription identification (see [0054], wherein “the agent 400 may be a certified component from another provider, also trusted by the cloud service infrastructure 108, or the user, e.g., local user 102 or remote user 114, may provide credentials such as a username and password associated with an account maintained by the cloud service infrastructure 108. In some embodiments, one or more of these examples will serve to credential the agent 400”) to establish a first connection (communication channel 218) 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 (see [0034], wherein “The cloud service infrastructure 108 (an activate server of a central computer system) also provides a protocol interface capable of communicating with the management agent 204 (first connection) through a communication channel 218 across the network 112”; 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);
retrieve, via the first connection, network device validation information corresponding to a plurality of network devices associated with the subscription identification (see [0054-0056]: wherein “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 … 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); and
((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)).
Cohen fails to explicitly disclose a plurality of local branch computer networks and that the validating is performed over the second connection responsive to the first network device initiating a second connection with the local activate server agent. However, Adhya discloses a plurality of local branch computer networks (Adhya, see Fig. 2, [0024], wherein “Specifically, FIG. 2 illustrates a network that is deployed in at least a central office 270 and a number of branch offices, such as Branch.sub.A 260, . . . Branch.sub.N 269. Typically, branch offices are located physically remote from central office 270. As such, network devices at each branch office may be connected to network devices at central office 270 via Internet 250”) that the validating is performed over the second connection responsive to the first network device initiating a second connection with the local activate server agent (Adhya, see Fig. 2, [0052, 0056-0057], wherein “FIG. 5 illustrates an exemplary process for determining whether to use a local authentication server according to embodiments of the present disclosure. During operations, a first network device executing a first authentication server receives a request for authentication from a client device (operation 500). The first authentication server then determines whether the client device was previously successfully authenticated by a second authentication server executing on a second network device within a particular period of time (operation 520). If so, the first authentication server at the first network device attempts to authenticate the client device using the first authentication server (operation 540). If not, the first authentication server at the first network device declines the request for authentication from the client device (operation 560)”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Adhya’s branch-local authentication technique into Cohen’s cloud-assisted device management system to achieve the claimed limitations because this would have permitted to locally validate managed devices using centrally supplied validation information and thus reducing continues dependency on connection to central remote system (see Adhya [0044-0045])
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).
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 Adhya et al. (US 20160036794) hereinafter Adhya and Onno et al. (US 20180077016) hereinafter Onno.
Regarding claim 4, Cohen and Adhya are applied as disclosed in claim 1 as examined above. Cohen and Adhya fail to suggest responsive to a discovery query by the given network device, providing to the given network device and by a dynamic host control protocol (DHCP) server, the connection information, wherein the connection information comprises at least one of an address of the local activate server agent or a credential for the second connection.
In the same field of endeavor as the Cohen reference, Onno teaches responsive to a discovery query by the given network device, providing to the given network device and by a dynamic host control protocol (DHCP) server, the connection information, wherein the connection information comprises at least one of an address of the local activate server agent or a credential for the second connection (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 and Adhya 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 and Adhya reference do 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)).
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 and Adhya 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 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 Adhya et al. (US 20160036794) hereinafter Adhya and 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 and Adhya arts do 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.
Response to Arguments
Applicant’s arguments filed on 10/16/2025 have been considered but are moot because in light of the new mapping and new grounds of rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 pm.
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, Ario Etienne can be reached at ario.etienne@uspto.gov. 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.
/HAMZA N ALGIBHAH/Primary Examiner, Art Unit 2457
