Communication device

Abstract

To provide a technique for improving processing accompanied by reactivation, in a communication device capable of executing processing following an instruction from a cloud server.SOLUTION: An MFP 1 is capable of executing processing following an instruction from a first management server 3 in response to reception of the instruction. In a case where the processing following the instruction received from the first management server 3 is accompanied by reactivation of itself, the MFP 1 provides the first management server 3 with a reply of an update presence notification or a reactivation presence notification that is the final notification to the instruction received from the first management server 3 before the reactivation, and does not provide the first management server 3 with the reply of the notification to the instruction received from the first management server 3 before the reactivation after the reactivation.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The technical field disclosed in this specification relates to a communication device capable of executing processing in accordance with instructions from a cloud server. [Background technology]

[0002] There is known a system that remotely manages a communication device capable of executing a process according to an instruction from a cloud server. For example, Patent Document 1 discloses a configuration in which a monitoring device serving as a server collects information on an image forming device via a network and displays the collected information on a screen of a client PC connected to the monitoring device. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2012-48567 A Summary of the Invention [Problem to be solved by the invention]

[0004] Processing according to instructions from a cloud server may involve rebooting a communication device. It is desirable for a communication device to be managed to respond to such instructions by sending a notification to the server. Patent Document 1 does not disclose a case where a managed device reboots, and there is room for improvement. [Means for solving the problem]

[0005] A communications device made with the aim of solving this problem is a communications device that is capable of executing processing in accordance with instructions received from a cloud server in response to receiving the instructions, and is configured so that if the processing in accordance with the instructions received from the cloud server involves restarting the communications device, before restarting the communications device, the communications device responds to the cloud server with a final notification that is a final notification in response to the instructions received from the cloud server, and after restarting the communications device, the communications device does not respond to the cloud server with a notification in response to the instructions received from the cloud server before the restart.

[0006] When the communication device disclosed in this specification performs a process according to an instruction from a cloud server that involves rebooting the communication device, the communication device responds to the cloud server with a final notification of the instruction before rebooting itself. Therefore, the cloud server can know that the communication device has been rebooted without continuing to monitor the state of the communication device after sending the instruction. In addition, after the reboot, the communication device does not need to respond with a further notification of the instruction because the final notification of the instruction has been completed, and the cloud server does not need to wait for a further response after receiving the final notification before the reboot.

[0007] A program executed by the above-mentioned communication device, a computer-readable storage medium storing the program, a management system including the above-mentioned communication device, and a management method using the management system are also novel and useful. Effect of the Invention

[0008] The technology disclosed in this specification realizes a technology for improving a process involving a reboot in a communications device capable of executing a process according to instructions from a cloud server. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is an explanatory diagram showing an overview of a management system. [Diagram 2]FIG. 1 is an explanatory diagram showing a schematic configuration of a management system according to a first embodiment. [Diagram 3] FIG. 11 is a sequence diagram showing an example of a first management procedure in a first management method. [Figure 4] FIG. 11 is a sequence diagram illustrating an example of a firmware update procedure. [Diagram 5] FIG. 11 is a sequence diagram illustrating an example of a command execution procedure. [Figure 6] 13 is a flowchart showing a procedure for command processing. [Figure 7] FIG. 11 is an explanatory diagram showing a schematic configuration of a management system according to a second embodiment. [Figure 8] FIG. 11 is a sequence diagram showing an example of a second management procedure in a second management method. [Figure 9] FIG. 11 is a sequence diagram showing an example of an update execution procedure in the second management method. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, a first embodiment of a management system including a communication device will be described in detail with reference to the accompanying drawings. This specification discloses a management system for managing a multifunction peripheral (hereinafter, referred to as "MFP") having a printing function.

[0011] 1, the management system 100 is configured by combining a client-side device 200 provided in a client that uses an MFP, and a cloud-side device 300 provided on the cloud. The management system 100 is a system that allows a client-side administrator who uses the client-side device 200 to manage the MFPs under management.

[0012] The client-side device 200 includes a plurality of MFPs 1 to be managed and a personal computer (hereinafter, referred to as a "client PC") 2 used by an administrator. Each MFP 1 is an example of a communication device and an example of a printer. The client PC 2 is disposed, for example, in the client's head office, and each MFP 1 is disposed in each of the client's branches. The client PC 2 may be disposed, for example, in the office of a system manager or the office of a vendor of the MFP 1. The client PC 2 is used for managing the MFP 1, and may be called, for example, a management PC. The client PC 2 is not limited to a PC, and may be a mobile terminal such as a smartphone or a tablet computer. The client-side device 200 may include a plurality of client PCs 2. A plurality of MFPs 1 may be disposed in each of the branches.

[0013] The multiple MFPs 1 may be the same model or different models. Each MFP 1 has its own unique identification information. An administrator who uses the client PC 2 can use the identification information of each MFP 1 to identify the MFP 1 to be managed.

[0014] 2, each client-side MFP 1 included in management system 100 includes a controller 10 including a CPU 11 and a memory 12. MFP 1 also includes a user interface (hereinafter referred to as “user IF”) 13, a communication interface (hereinafter referred to as “communication IF”) 14, a print engine 15, and a scanner 16, which are electrically connected to the controller 10.

[0015] The CPU 11 executes various processes according to the programs read from the memory 12 and based on the user's operation. As shown in Fig. 2, the memory 12 stores various programs including firmware 21 and an instruction processing program 22, and various data including command information 23 indicating commands executable by the MFP 1 and method information 24 indicating a management method. The memory 12 is also used as a work area when various processes are executed. A buffer provided in the CPU 11 is also an example of the memory 12. The programs and data will be described in detail later.

[0016] An example of memory 12 is not limited to a ROM, RAM, HDD, etc. built into MFP 1, but may be a storage medium that is readable and writable by CPU 11. A computer-readable storage medium is a non-transitory medium. In addition to the above examples, non-transitory media also include recording media such as CD-ROM and DVD-ROM. A non-transitory medium is also a tangible medium. On the other hand, an electrical signal that carries a program downloaded from a server on the Internet is a computer-readable signal medium, which is a type of computer-readable medium, but is not included in non-transitory computer-readable storage media.

[0017] The user IF 13 includes hardware for displaying a screen for notifying the user of information and hardware for accepting operations by the user. The user IF 13 may include a touch panel having a screen display function and an operation acceptance function, or may include a combination of a display unit and an operation button.

[0018] The communication IF 14 includes hardware for communicating with an external device. The communication IF 14 includes a function compatible with communication standards such as Wi-Fi (registered trademark), Ethernet (registered trademark), and USB. The MFP 1 of this embodiment includes both a function capable of communicating using the MQTT protocol and a function capable of communicating using the HTTP protocol or the HTTPS protocol. Note that the HTTP protocol and the HTTPS protocol are both protocols that conform to HTTP and are different from the MQTT protocol. In the following, the HTTP protocol and the HTTPS protocol will not be distinguished from each other and will simply be referred to as the "HTTP protocol."

[0019] The MFP 1 can communicate with the first management server 3 included in the cloud side device 300 using the MQTT protocol via the communication IF 14. The MFP 1 can also communicate with the storage server 4 and firmware server 5 included in the cloud side device 300 using the HTTP protocol via the communication IF 14.

[0020] The print engine 15 includes a configuration for printing an image based on image data on a print medium such as a sheet. The print method of the print engine 15 is, for example, an electrophotographic method or an inkjet method. The scanner 16 includes a configuration for reading an image of an original document and acquiring image data.

[0021] The client PC 2 of the client-side device 200 includes a controller 41 including an operating system and a browser, a user IF 42, and a communication IF 43 capable of communication at least according to the HTTP protocol. The client PC 2 may or may not be able to directly communicate with the MFP 1.

[0022] 2, the cloud side device 300 of the first embodiment includes a first management server 3, a storage server 4, and a firmware server 5. The first management server 3 is an example of a cloud server, and an example of a first type of cloud server. Each server of the cloud side device 300 may be configured with one device, or there may be a server configured with multiple devices, or there may be a device including the functions of multiple servers.

[0023] Among the cloud side devices 300, at least the first management server 3 and the firmware server 5 are prepared by the vendor of the MFP 1. The storage server 4 is, for example, a server provided by a third party that provides a storage service. The management system 100 can use the storage server 4 by making a request to the storage service as necessary.

[0024] The first management server 3 is a device capable of communicating with each MFP 1 using the MQTT protocol via the broker 6. Each MFP 1 is set to communicate with the first management server 3 using the MQTT protocol via the communication IF 14. The client PC 2 is capable of transmitting various instructions to the first management server 3 using the HTTP protocol. The first management server 3 includes a management program 301, and is capable of executing a process of creating instruction information to be transmitted to the MFP 1 based on various instructions received from the client PC 2. The process performed by the management program 301 will be described later.

[0025] The storage server 4 is a storage provided on the cloud and is a device capable of storing various types of information. The storage server 4 is a server capable of communicating with the first management server 3 and the MFP 1 via the HTTP protocol. The firmware server 5 is a server capable of communicating with each MFP 1 via the HTTP protocol and is a device capable of storing firmware 501 for various MFPs 1.

[0026] Next, a procedure for managing the MFP1 in the management system 100 of the first embodiment will be described. The following process basically indicates the process of the CPU 11 according to the instructions written in the program. That is, the processes such as "judgment", "extraction", "selection", "calculation", "decision", "identification", "acquisition", "reception", and "control" in the following description represent the process of the CPU. The process by the CPU also includes hardware control using the API of the OS. In this specification, the description of the OS will be omitted to describe the operation of each program. That is, in the following description, a description to the effect that "program B controls hardware C" may also mean that "program B controls hardware C using the API of the OS". In addition, the process of the CPU according to the instructions written in the program may be described in abbreviated terms. For example, it may be described as "performed by the CPU". In addition, the process of the CPU according to the instructions written in the program may be described in abbreviated terms such as "performed by program A".

[0027] Note that "obtaining" is used as a concept that does not require a request. In other words, the process of receiving data without the CPU requesting it is also included in the concept of "the CPU obtaining data." In addition, "data" in this specification is represented as a bit string that can be read by a computer. Data with the same substantial meaning but different formats will be treated as the same data. The same applies to "information" in this specification. In addition, "requesting" and "instructing" are concepts that indicate outputting information indicating a request or information indicating an instruction to the other party. In addition, information indicating a request or information indicating an instruction will also be simply referred to as "request" and "instruction."

[0028] Furthermore, the process by a CPU to determine whether information A indicates event B is sometimes conceptually described as "determining, from information A, whether event B is present." The process by a CPU to determine whether information A indicates event B or event C is sometimes conceptually described as "determining, from information A, whether event B or event C is present."

[0029] The MFP1 can accept a management method setting by, for example, a user operation, and stores the accepted setting as method information 24. The management system 100 of the first embodiment is a system for managing the MFP1 in which information indicating a first management method is stored in the method information 24. The first management method is an example of a first mode. A first management procedure for managing the MFP1 operating in the first management method will be described with reference to the sequence diagram of FIG. 3.

[0030] Note that, instead of information indicating the first management method, information indicating a second management method may be stored in the method information 24. When information indicating the second management method is stored in the method information 24, the MFP 1 is managed by a management system of a second type, which will be described later. That is, the MFP 1 of this embodiment is a device that can be managed by either a management system of the first type or a management system of the second type, depending on the method information 24.

[0031] When information indicating the first management method is stored in the method information 24, the MFP 1 performs initial setting in response to being started up, and notifies the first management server 3 of a start-up notification including its own information using the MQTT protocol (S101). Each MFP 1 has in advance information indicating the first management server 3 as a communication partner using the MQTT protocol. In the initial setting, the MFP 1 performs initial communication with the broker 6 in order to communicate with the first management server 3 using the MQTT protocol. Also, the first management server 3 has in advance performed initial communication with the broker 6 in order to communicate using the MQTT protocol.

[0032] The startup notification that the MFP 1 notifies the first management server 3 includes, for example, identification information of the MFP 1 and specification information indicating the specifications of the MFP 1. The specification information includes version information indicating the version of firmware 21 of the MFP 1, and may further include, for example, information indicating the presence or absence of optional functions and information indicating the presence or absence of optional units such as an additional tray or finisher. In response to receiving the startup notification, the first management server 3 can recognize that the MFP 1 has started up and is in a state where it can receive instructions, and the version of the firmware that is installed.

[0033] Meanwhile, the administrator uses the browser of client PC2 to access the first management server 3 by HTTP protocol, and inputs instructions for managing the MFP1 via an instruction input page provided by the first management server 3 (S105). When the first management server 3 receives an operation on the instruction input page from client PC2, it acquires information indicating the operation (S106).

[0034] An administrator can specify an MFP 1 to be managed via the instruction input page and input an instruction indicating a process to be executed by the MFP 1. Processes that can be instructed to the MFP 1 include, for example, updating firmware and executing a command file. A command file is, for example, a PJL (short for Printer Job Language) file, a batch setting command file, or other file that contains commands that can be executed by the MFP 1. A batch setting command file is, for example, a file that contains batch setting commands written in JSON (short for JavaScript Object Notation) format.

[0035] The firmware update instruction is an instruction to cause the MFP 1 to update the firmware 21. When the MFP 1 performs a firmware update process to rewrite the firmware in accordance with the firmware update instruction, the MFP 1 restarts based on the firmware update process. In other words, the process according to the firmware update instruction involves restarting the MFP 1. The firmware update instruction may include, for example, version information indicating the version of the firmware after the update. Alternatively, the firmware update instruction may simply be an instruction to update to the latest version of firmware stored in the firmware server 5.

[0036] An instruction to execute a command file is an instruction to cause the MFP1 to acquire a command file containing the commands as input data, and to cause the MFP1 to execute processing in accordance with each command described in the file. An instruction to execute a command file is an example of a specific instruction. An administrator can specify a created command file and input an instruction to execute processing in accordance with each command included in the command file on the instruction input page.

[0037] Examples of PJL commands that can be included in a PJL file include setting commands for various setting values ​​that can be set in the MFP1 and a restart command that indicates restart. A PJL file is an example of PJL data. An instruction to execute a PJL file is an example of a command execution instruction. The various setting values ​​that can be set in the MFP1 are default setting values ​​that can be set in, for example, multiple print setting items related to printing by the print engine 15 and multiple read setting items related to reading an original image by the scanner 16. For example, when the MFP1 receives an instruction for print settings via the user IF 13, it can display the set setting values ​​as initial values ​​for the print settings on the user IF 13.

[0038] The batch setting commands that can be included in the batch setting command file are, for example, setting commands related to communication functions using the communication IF 14 and device information. For example, an MFP1 with an email sending function can accept setting commands for information indicating an email server or email account to be used, and setting commands for editing an address book including email addresses of recipients. Also, an MFP1 with a network connection function can accept setting commands for information indicating a communication protocol to be used by default and a connection partner. Also, the MFP1 can accept setting commands for its own device information, for example, model information, display name information, and installation location information.

[0039] Among the various setting items whose settings are instructed by the batch setting command, there are setting items that become effective after rebooting and setting items that become effective without rebooting. For example, many setting commands related to email sending functions and network connection functions become effective by rebooting after setting. On the other hand, many setting commands for device information become effective just by setting them, without rebooting. The MFP 1 stores the types of commands that can be accepted and information indicating whether or not a reboot is required in command information 23 (see FIG. 2) in memory 12, in association with each other.

[0040] The first management server 3 creates instruction information to be transmitted to the MFP 1 by the MQTT protocol based on the information acquired from the client PC 2 in S106 (S107). The first management server 3 creates the instruction information based on the management program 301 (see FIG. 2). The instruction information created by the first management server 3 includes, for example, information indicating the process to be executed by the MFP 1 and information indicating the save destination of the input data.

[0041] The MQTT protocol is a lightweight communication protocol that can communicate with low power and is suitable for monitoring communication devices, but it is not possible to transmit large amounts of data due to limitations on the transmittable data size. Therefore, when the first management server 3 needs to pass data that may not be transmittable using the MQTT protocol to the MFP 1, the first management server 3 saves the data in the storage server 4 as input data separate from the instruction information, and includes information indicating the save destination of the input data in the instruction information. The information indicating the save destination of the input data is, for example, a URL. The MFP 1 can download the input data from the storage server 4, which is the save destination, by using the URL included in the received instruction information. In other words, the input data is passed to the MFP 1 separately from the instruction information.

[0042] The processes to be executed by the MFP1 are, for example, updating firmware and executing a command file. A firmware update instruction is an instruction without input data. On the other hand, an instruction to execute a command file is an instruction with input data. The input data for an instruction to execute a command file is the command file.

[0043] If the data size of the command file is sufficiently small, the first management server 3 may create instruction information including the command file in S107. In this case, the execution instruction of the command file is an instruction without input data. Furthermore, the commands included in the command file are not limited to the PJL format or JSON format, and may be written in, for example, HTML format or MIB (abbreviation of Management Information Base) format.

[0044] The first management server 3 then transmits the created instruction information to the MFP 1 using the MQTT protocol (S108). For convenience, the series of processes that are started by transmitting the instruction information to the MFP 1 is referred to as a task. The first management server 3 registers information indicating the status of the task corresponding to the instruction information transmitted based on the instruction received in S106, and waits for a response to the transmission of the instruction information in S108. Note that, hereinafter, the information indicating the status is also simply referred to as the status.

[0045] In response to receiving the instruction information, the MFP 1 first analyzes the received instruction information (S111) and acquires information on the type of the instructed process and the presence or absence of input data. If the MFP 1 determines that the instructed process is a firmware update instruction indicating a firmware update (alt:[firmware update]), it executes the firmware update procedure (S121).

[0046] The firmware update procedure in S121 will be described with reference to the sequence diagram in Fig. 4. The MFP 1 accesses the firmware server 5 based on information stored in memory 12, and checks whether an update file exists (S201). That is, the MFP 1 transmits model information indicating the model of its own device and version information indicating the version of the installed firmware 21 (see Fig. 2) to the firmware server 5, and obtains information indicating whether the firmware 21 is the latest firmware. Each MFP 1 stores in advance in memory 12 information indicating the contact information for the firmware server 5 and information indicating the storage location of firmware 501 for its own device.

[0047] For example, based on a response from the firmware server 5, the MFP 1 determines whether or not the firmware server 5 contains firmware 501 of a newer version than the version of the installed firmware 21. Alternatively, if the firmware update instruction contains version information, the MFP 1 may determine whether or not the specified version is newer than the version of its own firmware 21.

[0048] If it is determined that the latest firmware is not installed, that is, that an update file is present (alt:[Update present]), the MFP 1 sends response information including information indicating that an update is present to the first management server 3 using the MQTT protocol as a response to the instruction information received in S108 of Fig. 3 (S211). The notification indicating that an update file is present is a notification indicating that a firmware update will be performed, and a notification indicating that a reboot will occur following the firmware update. The notification sent in S211 is an example of a final notification.

[0049] In response to receiving the response information indicating that an update is available, the first management server 3 sets the status of the task related to the instruction accepted in S106 of Fig. 3 to "updating" (S212). "Updating" is a status indicating that the MFP 1 is executing a firmware update process.

[0050] After client PC 2 transmits information indicating instructions for the process to be executed by MFP 1 to first management server 3 (S106 in FIG. 3), client PC 2, for example, periodically accesses first management server 3 and requests status information for the task related to the input instructions. In response to a request from client PC 2, first management server 3 passes status information indicating the status at that time to client PC 2. If first management server 3 receives a request for status information with the status set to "updating" in S212, it passes information indicating "updating" to client PC 2.

[0051] The client PC 2 obtains status information indicating "updating" by making a status request after S212 (S215). Since the obtained status information indicates "updating", the client PC 2 displays information indicating that the task is "updating" on the user IF 42 (S216).

[0052] In addition to the status information, the first management server 3 may also respond with version information indicating the updated firmware version in response to the request from the client PC 2 in S215. For example, the MFP 1 may notify in S211 the version information indicating the new version and information indicating that a reboot is scheduled to be performed after the update. The first management server 3 can provide information to the client PC 2 based on the notification from the MFP 1.

[0053] On the other hand, the MFP 1 executes a firmware update after notifying the response information indicating that an update is available in S211. Specifically, the MFP 1 accesses the firmware server 5 and acquires the firmware 501 to be updated by downloading it from the firmware server 5 (S221). Furthermore, the MFP 1 updates the firmware by rewriting the firmware 21 with the acquired firmware 501 (S222). S221 and S222 are an example of a firmware update process.

[0054] Then, the MFP 1 restarts itself based on the firmware update (S223). In response to being started up by the restart in S223, the MFP 1 sends a start-up notification to the first management server 3 using the MQTT protocol (S231). S231 is the same process as S101 in Fig. 3, and is not a response to the instruction information received in S108 in Fig. 3. Note that the start-up notification sent in S231 contains, as spec information, version information indicating the version of the firmware 21 of the MFP 1, similar to the start-up notification sent in S101.

[0055] The startup notification sent in S231 is a notification indicating that the MFP1 has been started, and is not a notification indicating that the firmware update process or reboot has been performed. The final notification to the instruction information received from the first management server 3 in S108 of FIG. 3 is response information indicating that there is an update, which is responded to in S211. The MFP1 has already responded with the final notification to the instruction information in S211 before rebooting, and does not need to respond after rebooting. Therefore, the MFP1 does not need to store information in non-volatile memory just for sending the final notification after rebooting. Also, the first management server 3 does not need to wait for a further response, since it can know from the response in S211 that the MFP1 will be rebooted.

[0056] The first management server 3 can obtain the version information of the MFP 1 from the startup notification received from the MFP 1 in S231. The first management server 3 can ascertain that the firmware of the MFP 1 has been updated, for example, by comparing the version information in the current startup notification with the version information in the startup notification (S101 in FIG. 3) before acquiring the instruction information. The first management server 3 then sets the status of the task related to the instruction received in S106 in FIG. 3 to "update completed" (S232). "Update completed" is a status indicating that the MFP 1 has completed the firmware update process.

[0057] The client PC 2 acquires status information indicating "update completed" by making a status request at a timing after S232 (S235). Since the acquired status information indicates "update completed", the client PC 2 displays information indicating that the task is "update completed" on the user IF 42 (S236). If version information indicating the version of the firmware after the update is also acquired from the first management server 3 in S235, the client PC 2 may display the version information on the user IF 42.

[0058] Each time the MFP 1 is started, it notifies the first management server 3 of spec information indicating its own specs. Rewriting the firmware may change the capability information of the MFP 1, including, for example, the presence or absence of optional functions. In that case, S221 and S222 are also an example of an update process for updating the specs of the MFP 1. The first management server 3 can grasp that the specs of the MFP 1 have been updated by comparing the start-up notification of S101 in FIG. 3 with the start-up notification of S231. When the specs are updated, the first management server 3 may set the status of the task related to the instruction received in S106 in FIG. 3 to "spec update completed."

[0059] 4, that is, before downloading firmware 501. For example, instead of S211, the MFP 1 may respond with a notification that an update is available after downloading firmware 501 in S221 and before starting the update in S222, or may respond with a notification that an update is available before restarting in S223 after rewriting the firmware in S222. However, by responding at the timing of S211, the client-side administrator can quickly learn that an update is available.

[0060] On the other hand, if the check in S201 determines that the latest firmware is installed, that is, that there is no update file (alt: [no update]), the MFP 1 responds to the first management server 3 using the MQTT protocol with response information including information indicating that there is no update (S241). If there is no update file, the MFP 1 does not download firmware, rewrite firmware, or reboot. The notification indicating that there is no update file is a notification indicating that the firmware will not be updated and is a notification indicating that reboot will not be performed. The notification responded in S241 is an example of a final notification.

[0061] If the latest firmware is already installed, there is no need to update the firmware. If the firmware 21 is the latest firmware, the MFP 1 does not execute a firmware update and responds to the first management server 3 that there is no update. This makes it possible to avoid execution of unnecessary processing on the MFP 1, and allows the first management server 3 to immediately understand that the firmware was not updated as a result of the instruction.

[0062] In response to receiving the response information indicating no update, the first management server 3 sets the status of the task related to the instruction accepted in S106 of Fig. 3 to "no update" (S242). "No update" is a status indicating that the MFP 1 will not execute a firmware update.

[0063] The client PC 2 obtains status information indicating "no update" by making a status request after S242 (S245). Since the obtained status information indicates "no update", the client PC 2 displays information indicating that the task is "no update" on the user IF 42 (S246). The firmware update procedure in FIG. 4 ends after S236 or S246.

[0064] Returning to the explanation of the first management procedure in Figure 3, the MFP1 analyzes the received instruction information, and if it determines that the type of instruction is not a firmware update but an instruction to execute a command file (alt: [Execute command file]), it executes the command execution procedure (S131).

[0065] The command execution procedure of S131 will be described with reference to the sequence diagram of Fig. 5. As described above, the first management server 3 may save a command file as input data in the storage server 4 or the like, and transmit instruction information including a URL indicating the save destination. In this case, the MFP 1 uses the URL included in the received instruction information to access the storage server 4 or the like by HTTP protocol, and acquires the command file (S301). The MFP 1 can acquire the command file by downloading it from the save destination specified in the instruction information.

[0066] A command file is a file that includes one or more commands, is created by an administrator, and is specified by the administrator in S105 of Fig. 3. The MFP1 executes command processing according to the commands included in the acquired command file (S302).

[0067] The procedure for command processing will be described with reference to the flowchart of Fig. 6. Command processing is executed by the CPU 11 of the MFP 1 based on the instruction processing program 22.

[0068] First, the CPU 11 initializes a restart flag for storing whether or not a restart has occurred to turn it off (S401).Then, the CPU 11 reads the command file in order from the top, and obtains one command (S402).

[0069] CPU 11 determines whether the acquired command is a restart command indicating a restart (S403). If the command file is a PJL file, there is a possibility that the command file contains a restart command. If the PJL file contains a restart command, the process according to the command file will involve a restart. If the PJL file does not contain a restart command, the process according to the command file will not involve a restart.

[0070] If it is determined that the command is not a restart command (S403: NO), the CPU 11 executes processing according to the acquired command (S404).Then, the CPU 11 determines whether or not a restart is necessary to make the processing result of the executed command valid (S405).

[0071] The batch setting command file may contain setting commands that become valid after rebooting. For example, some setting commands related to e-mail settings and network connection settings become valid by rebooting the MFP1 after executing the processing of the setting command. On the other hand, many setting commands related to device information of the MFP1 become valid without rebooting the MFP1 by simply executing the processing of the setting command. The CPU 11 can determine whether the processing executed in S404 requires a reboot based on the command information 23 (see FIG. 2) stored in the memory 12.

[0072] If the acquired command is determined to be a restart command (S403: YES), or if the command requires a restart (S405: YES), the CPU 11 turns on the restart flag (S408). After S408, or if the CPU 11 determines that a restart is not required (S405: NO), the CPU 11 determines whether or not there are any unprocessed commands remaining in the command file to be processed (S411).

[0073] If it is determined that an unprocessed command remains (S411: YES), CPU 11 acquires the next command (S402) and performs the same processing. In other words, when the command file contains multiple commands, CPU 11 is configured to acquire each command in sequence and execute processing according to the acquired commands in sequence. However, if the command whose turn it is to be processed is a restart command, CPU 11 postpones the restart and checks the remaining commands. Also, even if the command file contains a command that requires a restart, if another command is included after that command, CPU 11 executes processing of the other command before restarting.

[0074] For example, if the command file contains a restart command and another command following the restart command, executing the processes in the order of the commands will result in the MFP1 restarting without executing the process according to the other command. In that case, it is highly likely that the process according to the other command will not be executed. The MFP1 of this embodiment does not restart until it has completed the processes according to all commands other than the restart command, and restarts after completing the processes for all commands, as described below. Therefore, it is highly likely that the processes for all commands included in the command file will be executed.

[0075] If it is determined that the processing of all commands included in the command file to be processed has been completed (S411: NO), the CPU 11 ends the command processing and returns to the sequence diagram of FIG.

[0076] Returning to the description of the command execution procedure in Fig. 5, after the command processing in S302, the MFP 1 judges whether or not the restart flag is turned on by the command processing. The restart flag is turned on in S408 of the command processing, for example.

[0077] When the restart flag is on (alt:[restart on]), the MFP 1 transmits a notification indicating that there will be a restart to the first management server 3 using the MQTT protocol as a response to the instruction information received from the first management server 3 in S108 of FIG. 3 (S311). The notification transmitted in S311 is a final notification to the received instruction information, and is an example of a final notification. Note that the MFP 1 transmits a notification including information indicating the instruction to be responded to as various responses to the first management server 3. The information indicating the instruction to be responded to is, for example, information identifying each piece of instruction information or information indicating the type of command.

[0078] If the command file includes a restart command or a command indicating settings that will become effective after restart, the MFP 1 responds to the first management server 3 before restarting, informing it that it will restart in response to the command file. This allows the first management server 3 to know that the MFP 1 will be restarted. After restarting, the MFP 1 does not respond to the first management server 3 with a notification regarding the command file's instructions.

[0079] In response to receiving the response information indicating that a restart will be performed, the first management server 3 sets the status of the task related to the instruction accepted in S106 of Fig. 3 to "Execution completed" and "Restart will be performed" (S312). "Restart will be performed" is a status indicating that the MFP 1 will be restarted. When the first management server 3 accepts a request for status information in a state in which the status was set to "Execution completed" and "Restart will be performed" in S312, the first management server 3 passes information indicating "Execution completed" and information indicating "Restart will be performed" to the client PC 2.

[0080] The client PC 2 obtains status information indicating "execution completed" and "restart required" by making a status request after S312 (S315). Because the obtained status information indicates "execution completed" and "restart required", the client PC 2 displays information indicating that the task is "execution completed" and "restart required" on the user IF 42 (S316). Note that, by obtaining the status information including "execution completed" in S315, the client PC 2 ends the processing of the instruction sent in S106 of FIG. 3.

[0081] Meanwhile, the MFP1 restarts itself after notifying response information indicating that a restart has been performed in S311 (S321). In response to being started up by the restart, the MFP1 sends a start-up notification to the first management server 3 using the MQTT protocol (S322). S322 is the same process as S101 in FIG. 3, and is not a response to the instruction information received in S108 in FIG. 3. Note that the start-up notification sent in S322 includes specification information of the MFP1, similar to the start-up notification sent in S101. In response to the notification of S322, the first management server 3 sets the status of the MFP1 to "start-up completed" (S323).

[0082] Furthermore, if the restart flag is turned off by the command processing in S302 (alt: [restart off]), the MFP 1 transmits a notification indicating that there will be no restart to the first management server 3 by the MQTT protocol as a response to the instruction information received from the first management server 3 in S108 of Fig. 3 (S331). The notification transmitted in S331 is a final notification in response to the received instruction information, and is an example of a final notification.

[0083] In response to receiving the response information indicating no reboot, the first management server 3 sets the status of the task related to the instruction accepted in S106 of Fig. 3 to "execution completed" and "no reboot" (S332). "No reboot" is a status indicating that the MFP 1 will not be rebooted.

[0084] The client PC 2 obtains status information indicating "execution completed" and "no restart" by making a status request after S332 (S335). Because the obtained status information indicates "execution completed" and "no restart", the client PC 2 displays information indicating that the task is "execution completed" on the user IF 42 (S336). The client PC 2 may also display "no restart". Note that by obtaining status information including "execution completed" at S335, the client PC 2 ends the processing of the instruction sent at S106 of FIG. 3.

[0085] If the MFP 1 fails to process the command in S404 of the command processing shown in FIG. 6, the MFP 1 may interrupt the command processing, turn off the restart flag, and respond to the first management server 3 of the execution failure.

[0086] Returning to the explanation of the first management procedure in Fig. 3, the MFP 1 ends the firmware update procedure of S121 or the command execution procedure of S131 based on the received instruction information, and then returns to normal operation. Note that the MFP 1 may also be able to execute processes other than firmware update and command file execution based on instruction information received from the first management server 3.

[0087] Next, a management system of the second embodiment will be described. The management system 500 of the second embodiment uses a cloud side device 600 instead of the cloud side device 300 of the first embodiment, for example, as shown in FIG. 7. The management system 500 of the second embodiment is a system for managing an MFP 1 in which information indicating a second management method is stored in method information 24 (see FIG. 2). The second management method is an example of a second mode. In the following, the same components as those of the first embodiment are denoted by the same reference numerals, and description thereof will be omitted.

[0088] The cloud side device 600 of the second embodiment includes a second management server 7 and a firmware server 5. The second management server 7 is an example of a second type of cloud server. Each server of the cloud side device 600 may be configured with one device, or may include a server configured with multiple devices, or may include a device including the functions of multiple servers.

[0089] The second management server 7 is a device provided on the cloud, equipped with storage, and capable of storing various types of information. The second management server 7 is, for example, a server provided by a third party that provides a storage service, and is capable of communicating with the MFP 1 and the client PC 2 using the HTTP protocol. The second management server 7 does not need to have a management program. In addition, when managing the MFP 1 that operates in the second management method, a dedicated program 45 is incorporated in the client PC 2. The dedicated program 45 is prepared, for example, by the vendor of the MFP 1, and is used by the administrator on the client side. The MFP 1 has a plurality of different operation methods, and therefore is capable of appropriate operation according to the type of server with which it can communicate.

[0090] When operating in the second management method, the MFP 1 communicates with the second management server 7 included in the cloud side device 600 using the HTTP protocol via the communication IF 14. A second management procedure for managing the MFP 1 operating in the second management method will be described with reference to the sequence diagram of FIG.

[0091] The MFP 1 operating in the second management method is configured to periodically inquire of the second management server 7 as to whether or not a task addressed to the MFP 1 itself has been registered (S501). The MFP 1 accesses the second management server 7 using a protocol other than the MQTT protocol, for example, the HTTP protocol. The MFP 1 operating in the second management method does not communicate using the MQTT protocol, and does not perform the startup notification shown in S101 of FIG. 3.

[0092] If no task addressed to the MFP 1 is registered (S502), the MFP 1 performs normal operation and continues to periodically inquire of the second management server 7. When the second management server 7 accepts a task for each MFP 1, it stores information on the accepted task in the storage.

[0093] Moreover, in the second management method, the administrator launches a dedicated program 45 (see FIG. 2) built into the client PC 2, instead of a browser, and inputs various instructions for managing the MFP 1. The administrator can input, for example, an instruction to update the firmware in the MFP 1 using the dedicated program 45 (S511). Note that the dedicated program 45 is a program having a function of accepting, for example, a designation of the MFP 1 to be managed and a designation of a process to be executed by the MFP 1, generating task information based on the various accepted instructions, and uploading the task information to the second management server 7.

[0094] The task information is information indicating tasks to be instructed to the MFP1 based on various instructions received from the administrator, and includes instruction information and status information. The instruction information is information indicating instructions to the MFP1, like the instruction information in the first management method. Moreover, the status information is information indicating the status of each task, and is information similar to the status information in the first management method.

[0095] In the second management method, since communication is performed using the HTTP protocol, there is no limit to the transmittable data size as in the MQTT protocol. Therefore, the dedicated program 45 may generate instruction information including information on the command file and the like that was used as input data in the first management method.

[0096] Based on the administrator's operation, the client PC 2 generates task information by the dedicated program 45 and uploads the generated task information to the second management server 7 (S512). As a result, the second management server 7 registers the task information including instruction information to be executed by the MFP 1 (S513). The task information sent from the dedicated program 45 includes status information indicating "waiting". The second management server 7 may be made up of multiple servers, and for example, the instruction information and status information of the task information may be stored in different servers.

[0097] If a task addressed to the MFP1 is registered by the periodic inquiry described above (S521), the MFP1 acquires the registered task information (S522). If the instruction input by the administrator to the dedicated program 45 is a firmware update instruction, the MFP1 acquires task information including instruction information indicating the firmware update instruction. S522 in which instruction information including a firmware update instruction is acquired is an example of a firmware update instruction.

[0098] Furthermore, in response to acquiring the instruction information, the MFP 1 instructs the second management server 7 to update the status information. Specifically, the MFP 1 updates the status information of the task to a status indicating "processing" (S523). The notification of S523 is a notification indicating the intermediate progress of the processing according to the instruction received from the second management server 7 in S522, and is an example of a progress notification.

[0099] In response to an instruction from the MFP 1, the second management server 7 changes the status information of the task registered by the client PC 2 to a status indicating "processing" (S524). Although not shown in Fig. 8, the client PC 2 periodically requests status information indicating the status of the registered task from the second management server 7. In a state where task information has been registered but the target MFP 1 has not received the task information, the second management server 7 returns a status indicating "waiting" in response to a request from the client PC 2.

[0100] After the task status has been changed to "in process" in S524, when a status request is received from the client PC 2, the second management server 7 returns a status indicating "in process" to the client PC 2 (S525). In response to receiving the status indicating "in process", the client PC 2 displays information indicating that the task is in process on the user IF 42 (S526).

[0101] On the other hand, when task information including instruction information indicating a firmware update instruction is acquired, the MFP 1 accesses the firmware server 5 based on the information stored in the memory 12, and checks whether an update file exists (S531). S531 is the same procedure as the checking procedure in the first management method (S201 in FIG. 4).

[0102] When it is determined that there is firmware to be updated (alt: [update available]), the MFP 1 executes an update execution procedure (S541). The update execution procedure will be described with reference to the sequence diagram of FIG.

[0103] The MFP 1 makes a request to the firmware server 5 to download the latest firmware 501 to be updated (S601). The MFP 1 then executes the downloaded firmware 501 to rewrite the firmware 21, thereby updating the firmware (S602). S601 and S602 are similar to the firmware update procedure in the first management method (S221 and S222 in FIG. 4), and are an example of a firmware update process. Furthermore, the MFP 1 stores information indicating that the firmware is being updated in a non-volatile area of ​​the memory 12 (S611). The MFP 1 then restarts (S612).

[0104] After booting, the MFP1 reads the information stored in the non-volatile area of ​​the memory 12 and determines whether or not information indicating that the firmware is being updated is stored (S621). The information indicating that the firmware is being updated is stored in a non-volatile area and is therefore not lost by rebooting.

[0105] If it is determined that information indicating that the firmware is being updated is stored (opt:[updating]), the MFP 1 updates the status information of the task managed by the second management server 7 to a status indicating "update completed" indicating that the firmware update has been completed (S631). The notification of S631 is a final notification in response to the instruction received from the second management server 7 in S522 of Fig. 8, and is an example of a completion notification. In other words, the MFP 1 operating in the second management method does not respond to the final notification in response to the received instruction before rebooting, but responds after rebooting.

[0106] The second management server 7, upon receiving the status update instruction from the MFP 1, changes the status of the task received from the client PC 2 to "update complete" (S632). If a status request is received from the client PC 2 after the task status has been changed to "update complete" in S632, the second management server 7 returns a status indicating "update complete" to the client PC 2 (S633). In response to receiving the status indicating "update complete", the client PC 2 displays information indicating that the firmware update has been completed on the user IF 42 (S634).

[0107] On the other hand, after notifying the second management server 7 of an instruction to update the status information to a status indicating "update completed" in S631, the MFP 1 deletes the information indicating that the firmware is being updated, which was stored in the non-volatile area of ​​the memory 12 in S611 (S641). As a result, the MFP 1 will not notify the second management server 7 the next time it is started up.

[0108] The MFP 1 may respond to the second management server 7 with version information indicating the current firmware version together with the update instruction to “update complete”. For example, when the second management server 7 receives a notification including the version information, the second management server 7 may return status information including the version information in response to a status request from the client PC 2.

[0109] Returning to the explanation of the second management procedure in Fig. 8, if it is determined that there is no firmware to be updated as a result of the check in S531 (alt: [no update]), the MFP 1 notifies the second management server 7 of an instruction to update the status information to the status of "no update" indicating that there is no update (S551).

[0110] In response to the notification from the MFP 1, the second management server 7 changes the status of the task accepted from the client PC 2 to "no update" (S552). Then, when a status request is accepted from the client PC 2 after the status has been changed to "no update" (S553), the second management server 7 returns a status indicating "no update" to the client PC 2 (S554). In response to receiving the status indicating "no update", the client PC 2 displays information indicating that the firmware is the latest version and has not been updated on the user IF 42 (S555).

[0111] It should be noted that even an MFP 1 operating in the second management method can execute processing based on a command file such as a PJL file or a batch setting command file. For example, when instruction information including a command file is generated by the dedicated program 45 and task information including the instruction information is registered in the second management server 7, the MFP 1 can acquire the command file from the instruction information. In this case, the MFP 1 also updates the status information of the task information to a status indicating "processing" as in S523 of FIG. 8, and executes processing based on the acquired command file. The processing based on the command file is the same as the command processing shown in FIG. 6 in the first management method.

[0112] When the MFP1 operating in the second management method is a process based on the command file that requires a restart, in S408 of FIG. 6, the MFP1 stores information indicating that the process based on the command file is being executed in a non-volatile area. The MFP1 then restarts as in S612 and S621 of FIG. 9, and checks the information stored in the non-volatile area. If information indicating that the process based on the command file is being executed is stored, the MFP1 updates the status information of the task information to a status indicating "processing completed." This allows the MFP1 to respond that the instructions of the command file have been completed after the restart.

[0113] On the other hand, if the process based on the command file does not require rebooting, the MFP 1 updates the status information of the task information to a status indicating "processing completed" as in S551 in FIG. 8, without rebooting.

[0114] In the second management method, the dedicated program 45 may also create instruction information including a URL indicating a destination to save the input data. In this case, the MFP 1 that receives the instruction information including the URL may download and acquire the input data using the URL.

[0115] As described above in detail, when the MFP 1 of this embodiment is operating in the first management mode, if the process according to an instruction from the first management server 3 involves rebooting the MFP 1 itself, the MFP 1 responds with a final notification to the instruction to the first management server 3 before rebooting. Therefore, the first management server 3 does not need to continue to monitor the state of the MFP 1 after sending the instruction to the MFP 1 or wait for a further response, and can know that the MFP 1 will be rebooted. Also, since the MFP 1 has finished sending the final notification to the received instruction after rebooting, it does not need to respond with a further notification.

[0116] The above embodiments are merely examples and do not limit the present invention. Therefore, the technology disclosed in this specification can be improved and modified in various ways without departing from the spirit of the present invention. For example, the device to be managed may be any device that has a communication IF and can communicate with the first management server 3 and the second management server 7, and may be a printer with a single printing function, a copier, a scanner, a FAX machine, or a machine tool, not limited to an MFP.

[0117] Furthermore, the MFP 1 may be capable of handling not only the instructions described in each embodiment, but also other instructions. The MFP 1 only needs to have a function to operate in at least the first management method, and may not have a function to operate in the second management method. In that case, the MFP 1 may not have the method information 24.

[0118] Also, the MFP 1 may require a user operation before rebooting. For example, the firmware update process may be a process that includes updating the firmware and does not include rebooting. However, since the updated firmware becomes effective by rebooting, the first management server 3 will maintain the task status as "updating" from when it receives a response to the update availability notification in S211 of FIG. 4 until it receives a startup notification in S231.

[0119] Furthermore, the MFP 1 operating in the first management method may generate output data as response information in accordance with the execution of processing according to the received instruction information. In this case, the MFP 1 may, for example, store the output data in the storage server 4 or the like, and transmit the response information to the first management server 3 using the MQTT protocol by including information indicating the storage destination in the response information.

[0120] Also, for example, the firmware 501 is not limited to being prepared in the dedicated firmware server 5, but may be, for example, in the first management server 3. Also, the first management server 3 may have a function of displaying the result of an instruction. In other words, the first management server 3 may include the function of the client PC 2.

[0121] Also, for example, the protocol used for communication between the MFP 1 operating in the second management method and the second management server 7 may be any protocol different from the MQTT protocol, and may not be the HTTP protocol. Also, the cloud side device may include both the first management server 3 and the second management server 7.

[0122] In addition, in any of the flowcharts or sequence diagrams disclosed in each embodiment, the execution order of multiple processes in any of the steps can be changed as desired or the processes can be executed in parallel as long as no contradiction occurs in the process content.

[0123] The processes disclosed in each embodiment may be executed by a single CPU, multiple CPUs, hardware such as ASIC, or a combination of these. The processes disclosed in the embodiments may be realized in various forms, such as a recording medium having a program for executing the processes recorded thereon, or a method. [Explanation of symbols]

[0124] 1 MFP 3 First Management Server 7 Second Management Server

Claims

1. A communication device capable of executing a process according to an instruction received from a cloud server, When the process according to the instruction received from the cloud server is a process involving a reboot of the communication device, Responding to the cloud server with a final notification, the final notification being a final notification to the instruction received from the cloud server, before rebooting the communication device; after rebooting the communication device, not responding to the cloud server with a notification in response to the instruction received from the cloud server before the reboot; 2. A communications device configured to:

2. 2. The communication device according to claim 1, The cloud server can communicate with the cloud server via MQTT protocol, Receive the instruction from the cloud server using an MQTT protocol; When the process according to the instruction received from the cloud server is a process involving a reboot of the communication device, before rebooting the communication device, responding to the cloud server with the final notification in response to the instruction received from the cloud server using an MQTT protocol; after rebooting the communication device, not responding to the cloud server with a notification in response to the instruction received from the cloud server before the reboot; 2. A communications device configured to:

3. 2. The communication device according to claim 1, A firmware update process for updating firmware is executable, configured to reboot the communication device when firmware is updated; The instruction receivable from the cloud server includes a firmware update instruction indicating a firmware update; If the instruction received from the cloud server is a firmware update instruction, executes the firmware update process as a process in accordance with the firmware update instruction; before rebooting the communication device based on the firmware update process, responding to the cloud server with the final notification for the firmware update instruction; After rebooting the communication device based on the firmware update process, the communication device does not respond to the cloud server with a notification for the firmware update instruction received from the cloud server before the reboot.

2. A communications device configured to:

4. 4. The communication device according to claim 3, If the instruction received from the cloud server is a firmware update instruction, Determine whether the latest firmware is installed, If the latest firmware is not installed, executing a firmware update process for updating the firmware to the latest version as the process in accordance with the firmware update instruction; before rebooting the communication device based on the firmware update process, responding to the cloud server with a final notification for the firmware update instruction, the final notification indicating that the communication device will be rebooted; After rebooting the communication device based on the firmware update process, the communication device does not respond to the cloud server with a notification regarding the firmware update instruction received before the reboot; If the latest firmware is installed, not executing the firmware update process, not rebooting the communications device, and sending a final notification indicating that the communications device will not be rebooted as the final notification to the firmware update instruction to the cloud server; 2. A communications device configured to:

5. 2. The communication device according to claim 1, at startup, notifying the cloud server of specification information indicating a specification of the communication device; the process involving a restart of the communication device includes an update process for updating a specification of the communication device; When the process performed in accordance with the instruction received from the cloud server is the update process, Responding to the cloud server with the final notification in response to the instruction received from the cloud server before rebooting the communication device; after rebooting the communications device, notifying the cloud server of the specification information indicating the specification updated by execution of the update process without responding to the cloud server with a notification in response to the instruction received from the cloud server before the reboot; 2. A communications device configured to:

6. 6. The communication device according to claim 5, A firmware update process for updating firmware is executable, configured to reboot the communication device when firmware is updated; The device is configured to notify the cloud server of the specification information including the firmware version at the time of startup, The instruction receivable from the cloud server includes a firmware update instruction indicating a firmware update; If the instruction received from the cloud server is a firmware update instruction, executing the firmware update process as the process in accordance with the firmware update instruction; Responding to the cloud server with the final notification of the firmware update instruction before rebooting the communication device; After rebooting the communication device, the communication device does not respond to the cloud server with a notification for the firmware update instruction received from the cloud server before the reboot, and notifies the cloud server of the specification information including a version of the firmware updated by execution of the firmware update process.

2. A communications device configured to:

7. 2. The communication device according to claim 1, The device is configured to be capable of executing a process according to the acquired input data in response to the acquisition of the input data, The communication device is configured to reboot when the acquired input data includes a command indicating a reboot or a setting requiring a reboot, the instructions receivable from the cloud server include specific instructions for executing a process in accordance with the input data; If the instruction received from the cloud server is the specific instruction, Acquiring the input data and executing a process according to the acquired input data; If the acquired input data includes a command indicating a restart or a setting that requires a restart, Responding to the cloud server with the final notification for the specific instruction before rebooting the communication device; After rebooting the communication device, the communication device does not respond to the cloud server with a notification in response to the specific instruction received from the cloud server before the reboot.

2. A communications device configured to:

8. 8. The communication device according to claim 7, the communication device is a printer having a printing function and configured to be able to execute processing in accordance with PJL (short for Printer Job Language) commands; the input data is PJL data that may include a plurality of PJL commands; The communication device is configured to restart the communication device when the acquired PJL data includes a restart command that is a PJL command indicating a restart, The specific instruction receivable from the cloud server includes a command execution instruction indicating execution of a process based on the PJL data, If the instruction received from the cloud server is a command execution instruction, acquiring the PJL data, and executing a process in accordance with the PJL command included in the acquired PJL data; If the acquired PJL data includes the restart command, before rebooting the communication device, responding to the cloud server with the final notification in response to the command execution instruction; after rebooting the communications device, not responding to the cloud server with a notification in response to the command execution instruction received from the cloud server before the reboot; 2. A communications device configured to:

9. 8. The communication device according to claim 7, If the instruction received from the cloud server is the specific instruction, Acquiring the input data and executing a process according to the acquired input data; If the acquired input data includes a command indicating a restart or a setting that requires a restart, responding to the cloud server with the final notification to the specific instruction, the final notification indicating that the communication device will be rebooted, before rebooting the communication device; After rebooting the communication device, the communication device does not respond to the cloud server with a notification in response to the specific instruction received from the cloud server before the reboot; If the acquired input data does not include either a command indicating a restart or a setting that requires a restart, not rebooting the communication device, and sending a final notification indicating that the communication device will not be rebooted as the final notification in response to the specific instruction to the cloud server; 2. A communications device configured to:

10. 8. The communication device according to claim 7, When the acquired input data includes a plurality of commands, the processing is sequentially performed according to each command; If the command that is being processed is a command that indicates a reboot, If there are no outstanding commands remaining, respond to the cloud server with the final notification for the specific instruction and reboot the communication device; if there are any unprocessed commands remaining, wait for the completion of the processing for all the commands, and when the processing for all the commands is completed, respond with the final notification for the specific instruction to the cloud server and restart the communication device; After rebooting the communication device, the communication device does not respond to the cloud server with a notification in response to the specific instruction received from the cloud server before the reboot.

2. A communications device configured to:

11. 2. The communication device according to claim 1, When the process according to the instruction received from the cloud server is a process involving a reboot of the communication device, responding to the cloud server with a final notification to the instruction received from the cloud server before rebooting the communication device, the final notification indicating that the communication device will be rebooted; After rebooting the communication device, the communication device does not respond to the cloud server with a notification in response to the instruction received from the cloud server before the reboot; When the process according to the instruction received from the cloud server is a process that does not require a reboot of the communication device, not rebooting the communications device, and sending a final notification indicating that the communications device will not be rebooted to the cloud server as the final notification in response to the instruction received from the cloud server; 2. A communications device configured to:

12. 2. The communication device according to claim 1, The device may operate in a first mode or in a second mode, When the process according to the instruction received from the first type cloud server while operating in the first mode is a process involving a reboot of the communication device, before rebooting the communication device, responding to the first type of cloud server with the final notification in response to the instruction received from the first type of cloud server; after rebooting the communications device, not responding to the first type of cloud server with a notification in response to the instruction received from the first type of cloud server before the reboot; When the process according to the instruction received from a second type cloud server while operating in the second mode is a process involving a reboot of the communications device, before restarting the communications device, responding to the second type cloud server with a progress notification which is a notification indicating an intermediate progress of the processing according to the instruction received from the second type cloud server; after rebooting the communication device, responding to the second type of cloud server with a completion notification indicating completion of the process in accordance with the instruction received from the second type of cloud server before the reboot; 2. A communications device configured to:

13. 13. The communication device of claim 12, A firmware update process for updating firmware is executable, configured to reboot the communication device when firmware is updated; configured to notify the first type cloud server of a firmware version at startup when operating in the first mode; the instructions receivable from the first type cloud server and the second type cloud server include a firmware update instruction indicating a firmware update; When the instruction received from the first type cloud server while operating in the first mode is the firmware update instruction, executing the firmware update process as the process in accordance with the firmware update instruction; before rebooting the communication device, responding to the first type cloud server with the final notification for the firmware update instruction; After rebooting the communications device, notifying the first type of cloud server of a version of the firmware updated by execution of the firmware update process without responding to the first type of cloud server with a notification for the firmware update instruction received from the first type of cloud server before the reboot; When the instruction received from the second type cloud server while operating in the second mode is the firmware update instruction, executes the firmware update process as a process in accordance with the firmware update instruction; Before rebooting the communication device, a progress notification indicating an intermediate progress of the firmware update process in accordance with the firmware update instruction is sent to the second type cloud server; After rebooting the communication device, respond to the second type of cloud server with a completion notification indicating completion of the firmware update process in accordance with the firmware update instruction received from the second type of cloud server before the reboot, the completion notification including a version of the firmware updated by the firmware update process.

2. A communications device configured to:

14. 13. The communication device of claim 12, When operating in the first mode, The first type of cloud server can communicate with the first type of cloud server via MQTT protocol, receiving the instruction from the first type cloud server using an MQTT protocol; When the process according to the instruction received from the first type cloud server is a process involving a reboot of the communication device, Before rebooting the communication device, respond to the first type of cloud server with the final notification for the instruction received from the first type of cloud server using an MQTT protocol; after rebooting the communications device, not responding to the first type of cloud server with a notification in response to the instruction received from the first type of cloud server before the reboot; When operating in the second mode, The second type cloud server is configured to access a storage device provided in the second type cloud server using a protocol other than the MQTT protocol and receive the instruction for the communication device stored in the storage device, When the process according to the instruction received from the storage of the second type cloud server is a process involving a reboot of the communication device, Before restarting the communication device, the progress notification indicating an intermediate progress of the process according to the instruction received from the second type cloud server is responded to by the second type cloud server using the protocol other than the MQTT protocol; After restarting the communication device, responding to the second type of cloud server with the completion notification indicating completion of the process according to the instruction received from the second type of cloud server before the restart using the protocol other than the MQTT protocol.

2. A communications device configured to:

Images