Network device, method for controlling network device, and program

Abstract

This enables appropriate control over the execution of scripts other than those used for remote repair on network devices undergoing remote repair. [Solution] Device 101, which is a network device that receives multiple services including remote repair, which repairs network devices from a remote location via a network, checks whether the network device is undergoing remote repair by the remote repair service, and when the result of the check that it is not undergoing remote repair continues, it controls the execution of a task script provided by a service other than the remote repair, and when it becomes under remote repair, it interrupts the execution of the script.

Description

Technical Field

[0004] , , , , , , ,

[0001] The present invention relates to a network device, a method for controlling a network device, and a program.

Background Art

[0002] In recent years, a remote management system for remotely managing network devices typified by a multifunction peripheral using cloud services (hereinafter referred to as CS) provided on the Internet has been proposed. As an example of such a service, there are a remote repair service for remotely repairing a device when a trouble occurs in the network device, a remote device management service for constantly managing the state and setting information of the device, and the like. For example, while a user constantly manages a network device using a remote device management service, when a trouble occurs in the network device, the user may use a remote repair service to perform maintenance and setting changes of the device from a remote location. Patent Document 1 discloses a technique for controlling such that when a device receives a setting change start request from an information processing device connected remotely and performs a setting process corresponding to the request, reception of a new request is prohibited from the time when the setting change start request is received until the setting change ends.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the technology described in Patent Document 1 may prevent the execution of a more urgent and higher-priority remote repair service while configuration processing from the remote device management service is in progress. Conversely, since configuration processing requests from the remote device management service are prohibited while the remote repair service is running, processing that the user wants to perform in the remote device management service may be canceled. Thus, it is necessary to ensure that appropriate processing control is implemented when a single device uses multiple remote management services, such as the remote device management service and the remote repair service.

[0005] The present invention aims to enable appropriate control over the execution of scripts other than those used for remote repairs in network devices that are subjected to remote repairs. [Means for solving the problem]

[0006] To solve the above problems, the present invention provides a network device that receives a plurality of services, including remote repair, which repairs the network device from a remote location via a network, and includes a confirmation means for confirming whether the network device is undergoing remote repair by the remote repair service, and a control means for controlling the execution of a task script provided by a service other than the remote repair when the confirmation result that the network device is not undergoing remote repair continues, wherein the control means interrupts the execution of the script when the network device becomes under remote repair. [Effects of the Invention]

[0007] According to the present invention, it is possible to appropriately control the execution of scripts other than those used for remote repair in network devices that are subjected to remote repair. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows the system configuration. [Figure 2]This is a diagram showing the system's hardware configuration. [Figure 3] This diagram shows the software configuration of the information processing device that provides the remote repair service 131. [Figure 4] This diagram shows the software configuration of network devices. [Figure 5] This diagram shows an example of the UI screen for the remote repair app 440. [Figure 6] This figure shows an example of a table managed by CS130. [Figure 7] This figure shows an example of a table managed by CS130. [Figure 8] This figure shows an example of the UI screen for a service provided by CS130. [Figure 9] This diagram illustrates the configuration information file and task file. [Figure 10] This is a flowchart showing the remote repair process for a device. [Figure 11] This is a flowchart showing the task acquisition process in Example 1. [Figure 12] This flowchart shows the remote repair process and the execution process of other tasks in Example 1. [Figure 13] This flowchart shows the remote repair process and the execution process of other tasks in Example 1. [Figure 14] This figure shows an example of a table managed by device 101. [Figure 15] This is a flowchart showing the task acquisition process in Example 2. [Figure 16] This flowchart shows the remote repair process and the execution process of other tasks in Example 2. [Figure 17] This flowchart shows the remote repair process and the execution process of other tasks in Example 2. [Figure 18] This is a flowchart showing the remote repair process and the execution process of other tasks in Example 3. [Figure 19]It is a flowchart showing the remote repair process and the execution process of other tasks in Example 3.

Embodiments for Carrying out the Invention

[0009] (Example 1) FIG. 1 is a diagram showing the configuration of a device management system. In the device management system in this embodiment, a plurality of different services are provided to network devices to be managed via a network. As the plurality of services provided to network devices, in this embodiment, the remote repair service 131 and the remote device management service 132 will be described as examples, but it is not limited thereto.

[0010] The device management system has a remote repair service 131, a remote device management service 132, network devices, and a network. The remote repair service 131 and the remote device management service 132 are cloud services 130 that provide services to network devices via a network. The network devices are devices managed by the cloud service 130 via a network. In this embodiment, device 101 and device 102 will be described as examples of network devices. The number of network devices managed by the device management system may be one or a plurality such as 1000. The network connects the cloud service 130 and device 101 and device 102 to transmit and receive data. The network is, for example, a combination of the Internet 120 and a LAN (Local Area Network) 110.

[0011] Devices 101 and 102 are network devices managed by the cloud service 130 via a network. In this embodiment, devices 101 and 102 are network devices that receive multiple services via the network, including remote repair, which repairs network devices from a remote location. Devices 101 and 102 are, for example, multifunction printers (MFPs) equipped with printing, scanning, and network communication functions. Note that the network devices managed by the cloud service 130 may be single-function printers with only printing capabilities, scanners, 3D printers, etc., or they may be image processing devices such as cameras, smart home appliances, or other network devices capable of communication. Devices 101 and 102 are connected to LAN 110. LAN 110 is connected to the internet 120, and to devices 101 and 102. The internet 120 is connected to the cloud service 130, and to LAN 110.

[0012] The cloud service 130 is a service that remotely manages the device 101 and the device 102 via a network. In this embodiment, the cloud service 130 provides a plurality of services including remote repair of a network device from a remote location via the network. Specifically, the cloud service 130 of this embodiment provides, for example, a remote repair service 131 that provides a remote repair service and a remote device management service 132 that is a service different from the remote repair service. The remote repair service 131 provides a service for performing maintenance on network devices (device 101 and device 102) registered in the remote repair service 131 from a remote location. The remote device management service 132 provides a service for managing the status information and setting information of network devices for network devices (device 101 and device 102) registered in the remote device management service 132. Note that the remote repair service 131 may be realized by, in addition to a virtual machine (cloud service) using resources provided by a data center including an information processing device, one or more information processing devices, or a combination thereof. Also, the remote device management service 132 may be realized by, in addition to a virtual machine (cloud service) using resources provided by a data center including an information processing device, one or more information processing devices, or a combination thereof. In the following, the remote repair service 131 is also referred to as RR131, and the remote device management service 132 is also referred to as DM132.

[0013] Data exchanged between RR131 and network devices is stored in a dedicated storage area for each tenant (e.g., per contract). Only users and devices with access rights to that tenant can access the data stored for each tenant. For example, suppose devices 101 and 102 belong to tenant 1, and another device (not shown) belongs to tenant 2. In this case, users of devices 101 and 102 who have access rights to tenant 1 cannot access data in tenant 2. Similarly, users of network devices belonging to tenant 2 cannot access data in tenant 1. DM132 also manages data on a tenant-by-tenant basis, similar to RR131.

[0014] Figure 2 shows the hardware configuration of the system. Figure 2(A) shows the hardware configuration of the information processing device that provides the remote repair service 131. The information processing device that provides the remote device management service 132 has a similar configuration. The information processing device has a CPU 201, ROM 202, RAM 203, KBC 205, DSPC 206, DKC 207, and IFC 208. Each of these components is connected to the system bus 204. The information processing device also has a KB 209, PD 210, DSP 211, and HDD 212.

[0015] The CPU 201 (Central Processing Unit) controls the entire remote repair service 131. The ROM 202 is a memory dedicated to data reading and stores, for example, the basic control programs for the information processing device and the remote repair service 131. The RAM 203 is a memory that allows data reading and writing and functions as a work area for the CPU 201. The DKC (Disk Controller) 207 controls access to storage devices such as the HDD 212. The HDD (Hard Disk Drive) 212 is an example of a storage device and stores various programs, data, etc. In this embodiment, an example in which the information processing device is equipped with an HDD 212 as a storage device is described, but it is not limited to this, and other storage devices such as an SSD or a DVD-ROM (DVD 213) may be used. The CPU 201 uses the RAM 203 as a work area and executes programs stored in the ROM 202 or HDD 212 to comprehensively control each component of the computer of the information processing device.

[0016] The KBC (Keyboard Controller) 205 is an input interface that controls input from the KB209 and PD210 to the information processing device. The KB209 is a keyboard that accepts user input. The PD210 is a pointing device that accepts user input. Note that the keyboard is just one example of an input device, and other input devices may be connected to the KBC209.

[0017] The DSPC (Display Controller) 206 is an output interface and controls the display on the DSP 211. The DSP 211 is a display that shows the output from the information processing device to the user, and is, for example, an LCD (Liquid Crystal Display). The display device DSP 211 and the input devices KB 209 and PD 210 may be implemented as an integrated touch panel. By associating input coordinates with display coordinates on the touch panel, a GUI can be configured that makes it appear as if the user can directly operate the screen displayed on the touch panel. The IFC (Interface Controller) 208 controls data communication with external devices on the network, such as device 101, via the network.

[0018] Figure 2(B) shows the hardware configuration of a network device. While device 101 is used as an example, device 102 has a similar hardware configuration. The network device 101 includes a CPU 251, ROM 252, RAM 253, HDD 254, control unit 255, and network interface 256. Furthermore, as a multifunction device, device 101 includes a printer 257, scanner 258, and facsimile communication unit 259. Each of these components is connected to the system bus 260.

[0019] The CPU 251 controls the entire device 101. The CPU 251 reads programs stored in the ROM 252 or HDD 254 and executes various control processes for the computer of device 101. The ROM 252 stores the programs executed by the CPU 251 and device information such as the serial number. The RAM 253 functions as the main memory and work area of ​​the CPU 251. The RAM 253 is also used for the receive buffer and image drawing. The HDD 254 is an example of a storage device. The HDD 254 stores image data, various programs, extension applications, font data, various setting information, etc.

[0020] The operation unit 255 displays information to the user and accepts user input. The operation unit 255 may consist of various switches, buttons, and a liquid crystal display for displaying messages, or it may consist of a touch panel. By associating input coordinates with display coordinates on the touch panel, a GUI can be configured that makes it appear as if the user can directly operate the screen displayed on the touch panel.

[0021] The network interface 256 is a network interface for connecting to a network, and it sends and receives information with other network devices and cloud services 130 via the network. The printer 257 prints on recording paper. For example, the printer 257 prints documents read by the reader or image data stored in the HDD 254, or prints image data based on print jobs received from external devices. The scanner 258 optically reads documents placed on the platen or ADF (Auto Document Feeder) and converts them into electronic data. The facsimile communication unit 259 sends and receives facsimile messages.

[0022] Figure 3 shows the software configuration of the information processing device that provides the remote repair service 131. The information processing device that provides the remote device management service 132 has a similar configuration. The software configuration of the information processing device is realized by the CPU 201 of the information processing device executing programs stored in the memory (ROM 202, HDD 212, etc.) of the information processing device.

[0023] The information processing device has a controller 300 that controls the information processing device to realize a remote repair service 131. The controller 300 has a UI control unit 301, a function control unit 302, a setting creation unit 303, an authentication unit 304, a communication unit 305, an authentication unit 304, a communication unit 305, a device information management unit 306, a DB management unit 307, a script management unit 309, and a task management unit 310.

[0024] The UI control unit 301 provides a graphical user interface (GUI) for the user to operate the remote repair service 131. The GUI is configured as a web page that can be displayed on other client terminals (not shown) using HTTP (HyperText Transfer Protocol). The GUI may also be configured to be displayed on a DSP 111 installed in the information processing device.

[0025] The function control unit 302 instructs each function within the controller 300 to perform various processes according to instructions input from the UI control unit 301 and requests received by the communication unit 305. The setting creation unit 303 generates setting information for distribution to network devices according to instructions from the function control unit 302 based on the input information from the UI control unit 301. The setting information created by the setting creation unit 303 is stored in the DB 308 via the DB management unit 307.

[0026] The authentication unit 304 performs authentication processing for users and devices that have requested to log in to the remote repair service 131. During the authentication process, the authentication unit 304 uses user information and device information for each tenant stored in DB 308. The communication unit 305 receives requests from external devices such as network devices and transmits the request content to the function control unit 302. The communication unit 305 also receives the processing result for the request from the function control unit 302, creates response data for the request from the external device, and transmits the response data to the request source. The communication unit 305 also controls HTTP communication. For example, the communication unit 305 transmits the web page received from the UI control unit 301 to the client terminal (not shown) as needed.

[0027] The device information management unit 306 acquires device information from network devices via the communication unit 305 and manages the acquired device information. The device information is stored in DB 308. The DB management unit 307, following instructions from the function control unit 302, instructs DB 308 to store, delete, update, and acquire configuration information, user information, device information, etc. The DB management unit 307 also manages various tables used by the remote repair service 131. DB (database) 308 is a database that holds various data and various tables. The data held in DB 308 is managed on a tenant-by-tenant basis. Users and devices can only access data in their own tenant and are restricted from accessing data in other tenants.

[0028] The script management unit 309 generates scripts according to the instructions of the function control unit 302. For example, the script management unit 309 generates scripts for acquiring device information to be managed by the device information management unit 306, and scripts for distributing configuration information created by the configuration creation unit 303 to devices. The task management unit 310 creates tasks according to the instructions of the function control unit 302. For example, the task management unit 310 creates a task that combines the scripts and schedules created by the script management unit 309 based on input information from the UI control unit 351. Tasks created by the task management unit 310 are saved to DB 308 via DB management unit 307. The tasks created by the task management unit 310 are in a format that can be parsed by the task control unit 404 of the network device.

[0029] Figure 4 shows the software configuration of a network device. Here, the software configuration of a network device will be explained using device 101 as an example, but device 102 has a similar software configuration. Device 101 has a UI unit 401, a job control unit 402, a network communication unit 403, a task control unit 404, a system data management unit 410, a file system 405, and various applications. In this embodiment, an example is described in which each network device has a cloud connection application 430, a copy application 450, and a send application 460 as applications, but it may have other applications as well.

[0030] The UI (User Interface) unit 401 displays a screen to the operation unit 255 and notifies the system of user interactions. The job control unit 402 is a module that controls printing, scanning, etc., by communicating with the printer 257 and scanner 258 according to user instructions and received data. The network communication unit 403 is a module that controls network communication with external devices and cloud services via the network interface 256. The task control unit 404 is a module that acquires and executes tasks sent from the cloud service 130 (RR131 and DM132).

[0031] The file system 405 reads and writes non-volatile data held within the device to the HDD 254. The data held within the device is managed by the system data management unit 410 according to its type. In other words, the system data management unit 410 functions as a management means for managing various system data, including firmware (FW). The system data management unit 410 includes a firmware update unit 411, a license management unit 412, a setting value management unit 413, and an application management unit 414.

[0032] The firmware update unit 411 manages system data such as firmware. System data managed by the firmware update unit 411 is stored in system data 421. The license management unit 412 manages license information for functions activated by licenses. License information managed by the license management unit 412 is stored in license data 422. The setting value management unit 413 manages setting values, which are configuration information. Setting values ​​managed by the setting value management unit 413 are stored in setting value data 423. The application management unit 414 manages applications installed on the device. Applications managed by the application management unit 414 are stored in application management data 424.

[0033] Each application installed on device 101 is provided with its own operating area and storage area, and each application individually holds its own unique data. In this embodiment, we will explain using the case where a cloud connection application 430, a copy application 450, and a send application 460 are installed on device 101 as an example. Each of the cloud connection application 430, copy application 450, and send application 460 is provided with its own operating area and storage area. The cloud connection application 430 holds its unique data in cloud connection application data 431. The copy application 450 holds its unique data in copy application data 451. The send application 460 holds its unique data in send application data 461. The remote repair application 440 holds its unique data in remote repair application data 441.

[0034] The copy application 450 and the send application 460 are system applications. System applications are pre-installed on the system and integrated with the firmware. The copy application 450 is an application that provides copy functionality. The send application 460 is an application that provides send functionality for transmitting scan data over the network. In addition to pre-installed applications, there are also extension applications that can be installed on the device later via the application management unit 414. The remote repair application (hereinafter referred to as the remote repair application) 440 is an extension application that communicates with the RR131 to enable remote device repair.

[0035] The cloud connection application (hereinafter referred to as the connection application) 430 is an application that may be pre-installed on the firmware or distributed later as an extension application. The connection application 430 manages the connection with the CS130 (RR131 and DM132). To maintain the connection with the CS130, the connection application 430 performs polling at regular intervals. Under steady conditions, the polling interval may be as short as once every few hours.

[0036] Figure 5 shows an example of the UI screen of the remote repair application 440. Figure 5(A) is an example of the UI screen displayed when the remote repair application 440 is launched. UI screen 480 is the UI screen that the remote repair application 440 displays on the control unit 255 when the remote repair application 440 installed on the device is launched by the user. UI screen 480 includes a remote repair start button 841 and a close button 483. The user selects the remote repair start button 841 when receiving repair service for device 101 by RR131. When the remote repair application 440 detects that the remote repair start button 841 has been selected, it notifies RR131 that the remote repair start button 841 has been selected. Upon receiving the notification, RR131 performs remote operations on device 101. When remote repair by RR131 begins, the remote repair start button 481 is hidden, and when remote repair is completed, the remote repair end button 482 is displayed. When the remote repair application 440 detects that the close button 483 has been selected,

[0037] Figure 5(B) shows an example of a UI screen displayed after remote repair is completed. UI screen 484 is the UI screen that the remote repair application 440 displays on the control unit 255 when remote repair by RR131 is completed. UI screen 484 includes a remote repair completion button 482 and a close button 483. When the remote repair application 440 detects that the user has selected the remote repair completion button 482, it notifies RR131 that the remote repair completion button 482 has been selected. Upon receiving the notification, RR131 terminates its remote operation on device 101. After that, the remote repair completion button 482 disappears and the remote repair start button 481 is displayed.

[0038] Figures 6 and 7 show an example of a table managed by CS130. Note that the table configuration shown in Figures 6 and 7 is just an example, and a different table configuration is possible. Figure 6(A) shows an example of the authentication information management table 500. The authentication information management table 500 includes columns 501 to 505. Each record represents one piece of authentication information.

[0039] Column 501 is the account ID. The account ID is an ID used to uniquely identify users accessing CS130. Generally, users accessing CS130 include not only customer users who own devices 101 and 102, but also sales company users who maintain the devices. For example, the email address registered by the user is used as the account ID. Column 502 is the affiliated tenant. The affiliated tenant contains information about the tenant to which the user in column 501 belongs. Column 503 is the username. The username is the name of the user identified by the user ID. Column 504 is the Role. The Role contains the role (permissions) assigned to the user corresponding to column 501. In Figure 6(A), examples of roles are shown, in this embodiment, "admin" indicating administrator privileges within the tenant, "general" indicating a regular user, and "service" indicating a sales company user, but it is not limited to these. Note that each tenant must have at least one account with administrator privileges ("admin" role). Column 505 is the password. For user authentication, the combination of the account ID in column 501 and the password in column 505 is used.

[0040] Figure 6(B) shows an example of the device management table 510. The device management table 510 includes columns 511 to 515. Each record represents one piece of device information. Column 511 is the serial number. The serial number of the device registered in CS130 is stored in the serial number column. Column 512 is the tenant to which the device with the serial number stored in the serial number column belongs. The tenant value is a number that uniquely identifies the tenant. Column 513 is the model name. The model name is stored in a value that uniquely identifies the model of the target device. Column 514 is the FW version. The FW version is stored in the FW version of the target device. Column 515 is the status. The status is stored in the status column. For example, if the device is operating correctly, "Normal" is stored; if an error has occurred in the device, "Error" is stored. Note that a predefined status code may also be stored in the status column. Furthermore, it is possible to include network information such as device names and IP addresses in the device management table 510.

[0041] Figure 6(C) shows an example of the configuration information management table 520. The configuration information management table 520 includes columns 521 to 524. Each record represents one piece of configuration information. Column 521 is the configuration information ID. The configuration information ID is an identifier used to uniquely identify the configuration information. Columns 522 to 524 list examples of configuration information. Note that the configuration information is not limited to those exemplified here. Column 522 is the IP address. Column 523 is the gateway address. Column 524 is the subnet mask. Note that Figure 6(C) shows an example of assigning configuration items to each column from column 522 onwards, but this is not limited to this, and the actual configuration information file or the path to the configuration information file may also be stored. Note that if the path to the actual configuration information file is stored, the actual file will be located in a different location.

[0042] Figure 7(A) shows an example of the script management table 530. The script management table 530 includes columns 531 to 536. Each record represents one piece of script information. A script is a process executed by a device. Column 531 is the script ID. The script ID stores an ID that uniquely identifies the script. In this embodiment, a number starting from 1 is stored, but it is not limited to this. Column 532 is the firmware (FW). The firmware itself is stored in the firmware column. In this embodiment, the firmware itself is stored in column 532, but it is not limited to this; for example, only the path to the firmware itself may be stored. If only the path to the firmware itself is stored, the actual firmware will be placed as a file in a different location.

[0043] Column 533 is the extension application. The extension application contains the actual extension application. In this embodiment, the actual extension application is stored in column 533, but this is not the only option; only the path to the extension application may be stored. If only the path to the extension application is stored, the actual application will be located as a file in a different location. Column 534 is the configuration information. The configuration information contains the value of the configuration information ID of one of the records in the configuration information management table 520. For example, a record with script ID 1 is associated with the configuration information with the value of configuration information ID S001. If there is no configuration information to associate, column 534 may be left blank.

[0044] Column 535 is status information. The status information stores whether the script retrieves the device's status information or not. In the example shown in Figure 7(A), "YES" is stored as status information if status information is retrieved, and "NO" if it is not, but this is not the only option. Column 536 is restart. The restart information stores whether the script will restart the device or not. In this embodiment, "YES" is stored if status information is retrieved, and "NO" if it is not, but this is not the only option. Generally, if the value of a specific setting item on the device is changed, a device restart may be required. In such cases, the value of column 536 is set to "YES". The script management table 530 may also contain columns that define processes for updating firmware or for installing extension applications.

[0045] Figure 7(B) shows an example of the task management table 540. The task management table 540 includes columns 541 to 545. Each record represents one piece of task information. A task is a script to which control information such as execution time and target device is attached. Column 541 is the task ID. The task ID stores an ID that uniquely identifies the task. In the example shown in Figure 7(B), a number starting with 1 is stored as the task ID, but this is not the only option. Column 542 is the execution time. The execution time stores the date and time information when the script will be executed. It is also possible to execute the script immediately after the device receives it without specifying a date and time. In the case of immediate execution, the value of column 542 is set to "NOW". In the example shown in Figure 7(B), "NOW" is used as the value to indicate immediate execution, but this is not the only option.

[0046] Column 543 is the target device. The target device column stores information that uniquely identifies the device on which the script will be executed. If you want to run the script on multiple devices, you may store multiple pieces of identification information in column 543. In the example shown in Figure 7(B), the serial number of the device is stored as the identification information, but this is not the only option. Column 544 is the script ID. The script ID is stored in column 531 of any record in the script management table 530. In the example shown in Figure 7(B), the record with task ID 1 is associated with the script with a script ID value of 1. Column 545 is the result. The result column stores the execution result of the task. In this embodiment, it is assumed that the result column stores "Success" if the task execution was successful, "Failure" if it failed, and "Aborted" if it was aborted, but this is not the only option. For example, a predefined result code may be stored in column 545. Also, it is assumed that column 545 is blank before task execution, but this is not the only option.

[0047] Figure 7(C) shows an example of the configuration change management table 550. The configuration change management table 550 includes columns 551 and 552. The configuration change management table 550 is a table for managing whether the processes executed by a device change the device's configuration. Column 551 is the process. The process contains a string indicating each process defined in columns 532 to 536 of the script management table 530. Note that in the example shown in Figure 7(C), the column name is stored, but this is not the only way. Column 552 is the configuration change. The configuration change contains whether the process for each record changes the device's configuration. In the example shown in Figure 7(C), "1" is stored if the configuration is changed, and "0" if it is not, but this is not the only way. Note that the definition of whether or not a configuration change is made for each process defined in the configuration change management table 550 is used as the value of the confcng attribute in the task file 720 shown in Figure 9(B), which will be described later.

[0048] Figure 8 shows an example of the UI screen for a service provided by CS130. Figure 8(A) shows an example of the task creation screen 600. The task creation screen 600 is a UI screen provided by the UI control unit 301 of RR131. The task creation screen 600 allows users with the service role in each tenant of RR131 to create tasks for remote repair of devices registered in the tenant to which they belong. Since the remote repair task targets a device experiencing trouble, it is assumed that it will always be executed immediately upon the occurrence of trouble.

[0049] The task creation screen 600 includes, for example, the tenant name 601, the target device display area 602, the script creation button 603, the OK button 604, and the cancel button 605. The tenant name 601 displays the value of column 502 (tenant name) associated with the account used by the user when logging into RR131. In the example shown in Figure 8(A), "Tenant 1" is displayed in the tenant name 601.

[0050] The target device display area 602 displays information to identify the device. In the example shown in Figure 8(A), the serial number and model name are displayed in the target device display area 602, but this is not the only display. The serial number is the serial number stored in column 511 of the device management table 510. The model name is the model name stored in column 513 of the device management table 510. Note that when a user operates the task creation screen 600 to create a task for remote repair, it is assumed that the device to be remotely repaired has been identified in advance. Therefore, the target device display area 602 displays the information of the identified device to be remotely repaired. The script creation button 603 is a button that displays the screen for creating a script to be executed in the task. When the user selects the script creation button 603, the script creation screen 640 (Figure 8(C)) is displayed. If the user wants to generate and save the remote repair task with the settings made on the task creation screen 600, they select the OK button 604. If the user wants to cancel the creation of the remote repair task, they select the Cancel button 605. When the selector of the cancel button 605 is detected, the controller 300 of RR131 discards the editing results of the task creation screen 600 and instructs the UI control unit 301 to terminate the display of the task creation screen 600.

[0051] Here, we will explain the processing performed by the RR131's controller 300 when it detects that the OK button 604 has been selected on the task creation screen 600. The controller 300 adds new records to the configuration information management table 520, the script management table 530, and the task management table 540 based on the settings on the task creation screen 600. Furthermore, the controller 300 stores the newly generated configuration information ID in column 521 of the record added to the configuration information management table 520. Columns 522 to 524 store the values ​​entered by the user in the configuration value input area 643 on the script creation screen 640, which will be described later. Next, the controller 300 stores the newly generated script ID in column 531 of the record added to the script management table 530. The controller 300 stores the values ​​specified in the FW specification area 641 and the application specification area 642 in columns 532 and 533. The controller 300 stores the configuration information ID of the configuration information added to the configuration information management table 520 in column 534. Controller 300 stores the values ​​specified in the status information specification area 644 and the restart specification area 645 in columns 535 and 536. Next, Controller 300 stores the newly generated task ID in column 541 of the record added to the task management table 540. Controller 300 stores "NOW" in column 542 to indicate immediate execution. Controller 300 stores the device information displayed in the target device display area 602 in column 543. Controller 300 stores the script ID of the script added to the script management table 530 in column 544. Note that column 545 is blank because the task has not yet been executed. After that, Controller 300 instructs the UI control unit 301 to close the task creation screen 600.

[0052] Figure 8(B) shows an example of the task creation screen 620. The task creation screen 620 is a UI screen provided by the UI control unit 301 of DM132. On the task creation screen 620, users of each tenant of DM132 create tasks to perform remote device management for devices registered in their respective tenants. The task creation screen 620 includes, for example, the tenant name 621, the target device specification area 622, the execution time specification area 626, the script creation button 623, the OK button 624, and the cancel button 625.

[0053] The tenant name 621 displays the value in column 502 (tenant name) associated with the account used by the user when logging into DM132. Therefore, the tenant name 621 on the task creation screen 620 is the same as the tenant name 601 on the task creation screen 600. The target device specification area 622 is used to specify the devices to which the task created on the task creation screen 620 will be distributed and executed. For example, the target device specification area 622 displays a list of devices registered in the tenant to which the logged-in user belongs, and allows the user to select a device using checkboxes. In the example shown in Figure 8(B), the serial number and model name values ​​are displayed as information to identify the device in the target device specification area 622, but this is not the only option. The serial number displays the serial number stored in column 511 of the device management table 510. The model name displays the model name stored in column 513 of the device management table 510. The user can specify the target device for the task by selecting the checkboxes placed at the beginning of the target device information.

[0054] The execution time specification area 626 is used to specify the execution time of the task. In the example shown in Figure 8(B), the task execution time can be selected using radio buttons: "Execute immediately" to execute the task immediately, and "Execute at a specified time" to execute the task at a specified time, but this is not the only option. The script creation button 623 is used to display the screen for creating the script to be executed by the task (script creation screen 640 in Figure 6(C)).

[0055] When a user wants to create and save a task with the settings configured on the task creation screen 620, they select the OK button 624. The process executed by the DM132 controller 300 upon detecting the selection of the OK button 624 is the same as the process executed by the RR131 controller 300 upon detecting the selection of the OK button 604 on the task creation screen 600. However, the value entered in the execution time specification area 626 is stored in column 542 of the task management table 540. When a user wants to cancel the creation of a remote device management task, they select the Cancel button 625. Upon detecting the selection of the Cancel button 625, the DM132 controller 300 discards the editing results on the task creation screen 620 and instructs the UI control unit 301 to terminate the display of the task creation screen 620.

[0056] Figure 8(C) shows an example of the script creation screen 640. The script creation screen 640 is a UI screen provided by the UI control unit 301. When a remote repair task is created, if the script creation button 603 on the task creation screen 600 is selected, the UI control unit 301 of RR131 displays the script creation screen 640. Also, when a remote device management task is created, if the script creation button 623 on the task creation screen 620 is selected, the UI control unit 301 of DM132 displays the script creation screen 640.

[0057] The script creation screen 640 includes, for example, a FW specification area 641, an application specification area 642, a setting value input area 643, a status information specification area 644, a restart specification area 645, an OK button 646, and a cancel button 647. The FW specification area 641 is an area for specifying the file path of the actual FW to be applied to the device on which the script will be executed, i.e., the target device of the task. The user enters the file path of the actual FW to be applied to the target device in the FW specification area 641. It is assumed that the user has obtained the FW file in advance. To facilitate the input of the file path, a file browsing dialog display button (not shown) or the like may be provided to allow the user to select the file path.

[0058] The application specification area 642 is where the file path of the actual extension application to be installed on the device on which the script will be executed, i.e., the target device of the task, is specified. The user enters the file path of the actual extension application to be installed on the target device in the application specification area 642. It is assumed that the application file has been obtained by the user in advance. To facilitate the input of the file path, a file browsing dialog display button (not shown) may be provided to allow the user to select the file path. Also, if a license is required when installing the application, a license specification area (not shown) where the license information can be entered may be displayed.

[0059] The setting value input area 643 is where the user enters the setting values ​​to be applied to the target device for each setting item. The user enters the setting values ​​to be applied to the target device for each setting item displayed in the setting value input area 643. At the beginning of each setting item, for example, a checkbox is attached, and the user selects the setting items they want to apply to the target device and sets the setting values ​​for each selected setting item.

[0060] The status information specification area 644 is an area for specifying whether or not to acquire status information from the device on which the script is executed, i.e., the target device of the task. The user selects whether or not to acquire status information from the target device in the status information specification area 644. In the example shown in Figure 8(C), "Acquire" is used to acquire status information, and "Do not acquire" is used to not acquire it, but this is not the only option, and it may be configured to be specified using another UI, such as radio buttons.

[0061] The restart specification area 645 is where you specify whether or not to restart the device on which the script is executed, i.e., the target device of the task, after the script has been executed. The user selects whether or not to restart the target device in the restart specification area 645. In the example shown in Figure 8(C), a dropdown list is used to specify whether to restart ("Yes") or not ("No"), but this is not the only option, and a configuration using another UI, such as radio buttons, may also be used.

[0062] When a user wants to generate and save a script based on the settings configured on the script creation screen 640, they select the OK button 646. For example, when the RR131 controller 300 detects that the OK button 646 has been selected when creating a script to be executed in a remote repair task, it temporarily stores the script creation result in the script management unit 309. The controller 300 then instructs the UI control unit 301 to terminate the display of the script creation screen 640. When a user wants to cancel script creation, they select the Cancel button 647. When the controller 300 detects that the Cancel button 647 has been selected, it discards the edited results on the script creation screen 640 and instructs the UI control unit 301 to terminate the display of the script creation screen 640.

[0063] Figure 9 illustrates the configuration information file and task file. Figure 9(A) illustrates the configuration information file. The configuration information file is a file in which the configuration information from columns 522 to 524 of the configuration information management table 520 has been converted into a format that the device can interpret. The configuration information file 700 shown in Figure 9(A) is an example of a configuration information file in XML format. In this embodiment, the data file is represented in XML (Extensible Markup Language) format, but it may also be represented in JSON (JavaScript Object Notation) format, for example.

[0064] The configuration information file 700 includes, for example, a control information area 701 and a configuration information area 702. The control information area 701 contains information that identifies the device. In the example shown in Figure 9(A), the control information area 701 contains the model name ( <model>Tag) and serial number ( <sn>The settings information area 702 lists the settings information to be set on the device. In this embodiment, each tag name of the settings information is separately defined to have a one-to-one correspondence with the information set in the settings information management table 520 (columns 522 to 524). Therefore, in the example shown in Figure 9(A), the settings information area 702 contains the IP address corresponding to column 522, the gateway address corresponding to column 523, and the subnet mask corresponding to column 524.

[0065] Figure 9(B) shows an example of a task file that describes the processing procedure for a device to automatically execute a specified process at a specified time. The task file 720 is acquired by the device's cloud connection application 430 via the network communication unit 403. The acquired task file 720 is parsed by the task control unit 404, and the processes described are executed by the device. The task file 720 is written in, for example, XML format. However, the format of the task file 720 is not limited to XML format; it may also be written in shell script or other formats.

[0066] The task file 720 includes, for example, a task identification unit 721, an aircraft identification unit 722, an execution time unit 723, and a script description unit 730. The task identification unit 721 is <id>It consists of tags and contains a task ID to identify the task. The task identification unit 721 contains the same value as the task ID in column 531 of the task management table 540. The aircraft identification unit 722 is <sn>It consists of tags and contains a serial number to identify the device being targeted for task execution. The device identification unit 722 contains the value of the target device in column 543 of the task management table 540.

[0067] The execution time section 723 is <time>It consists of tags and contains time information to identify the execution time of a task. The execution time section 723 contains the execution time value from column 542 of the task management table 540. In the example shown in Figure 9(B), if the value in column 542 is "NOW", then the execution time section 723 will be <time> NOW< / time> Although it is stated as such, it is also acceptable to delete the entire tag entry only in the case of "NOW". If the entire tag entry in the execution time section 723 is deleted, the device performing this task will interpret it as having been instructed to execute the task immediately.

[0068] The script description section 730 contains a set of processes to be performed on the target device. The script description section 730 includes, for example, a firmware update processing unit 731, an extended application installation processing unit 732, a configuration information processing unit 733, a status information processing unit 734, and a restart processing unit 735. Each process tag includes an order attribute, which specifies the order of processing. Additionally, tags indicating processes that involve device configuration changes include a confcng attribute. The value of the confcng attribute for each process is set according to the definition in the configuration change management table 550. A value of 1 for the confcng attribute indicates that the device configuration will be changed.

[0069] The firmware update processing unit 731 is responsible for updating the firmware via the firmware update unit 411. <updatefirmwarecommand>By specifying tags, you define the process, <path>The tag specifies the path to the server where the actual firmware resides. The extended application installation processing unit 732 is responsible for installing the extended application via the application management unit 414. The extended application installation processing unit 732, <installappcommand>By specifying tags, you define the process, <path>The tag specifies the path to the server where the extension application resides. The configuration information processing unit 733 is responsible for changing the device's configuration information via the configuration value management unit 413. The configuration information processing unit 733 <deviceconfigcommand>By specifying tags, you define the process, <conffileid>Tags are used to specify the configuration file to apply to the target device. <conffileid>The tag will use the value of the configuration information ID in column 521 as the filename.

[0070] The status information processing unit 734 is responsible for obtaining status information from the device. <getstatuscommand>It consists only of tags. The restart processing unit 735 is responsible for restarting the device after all processing is complete, in order to reflect the configuration information to the device. The restart processing unit 735 is <rebootcommand>It consists only of tags. Note that the script description shown in Figure 9(B) does not limit the processing that can be performed on the device, and processing may be duplicated or increased or decreased as needed.

[0071] Here, we assume a scenario where device 101 is registered in the CS130's device management table 510 via the connection application 430, and then some kind of trouble occurs with device 101. The operation when a sales company user remotely repairs device 101 when a trouble occurs with device 101 will be explained using the flowchart in Figure 10. Figure 10 is a flowchart of the remote repair process for a device. In Figure 10, each process performed by device 101 is realized by the CPU 251 executing a program stored in memory (ROM 252 or HDD 254). Similarly, each process performed by RR131 is realized by the RR131's CPU 201 executing a program stored in memory (ROM 202 or HDD 212).

[0072] When a customer user launches the remote repair application 440 on the device 101 where the problem occurred and presses the remote repair start button 481 on the screen 480, this process begins and S801 is executed. In S801, the remote repair application 440 on device 101 notifies RR131 via the connection application 430 and the network communication unit 403 that remote repair has started. In S802, the function control unit 302 of RR131 receives the remote repair start notification from device 101 via the communication unit 305 and starts the remote repair process. The function control unit 302 then obtains information on the remote repair target device via the device information management unit 306 and temporarily stores it in DB 308.

[0073] In S803, the remote repair application 440 of device 101 sends a notification to the connection application 430 via the network communication unit 403 to shorten the polling interval. In S804, the function control unit 302 of RR131 receives the polling interval change notification from device 101 via the communication unit 305 and notifies the communication unit 305 that the polling interval of the target device has been shortened. Based on the polling interval change notification, the communication unit 305 modifies the communication parameters as necessary.

[0074] S805 and S806 are processes performed while device 101 is being remotely repaired by RR131. Details of the remote repair process (S805) on device 101 are explained in Figures 12 and 13. When remote repair by RR131 is initiated, the remote repair start button 481 is hidden. When it is determined that the problem with device 101 has been resolved or not resolved by the remote repair, the remote repair end button 482 is displayed. When it is detected that the customer user has pressed the remote repair end button 482 on screen 480, device 101 executes the process in S807.

[0075] In S807, the remote repair application 440 of device 101 notifies RR131 that the remote repair is complete via the connection application 430 and the network communication unit 403. In S808, the function control unit 302 of RR131 receives the remote repair completion notification from device 101 via the communication unit 305 and terminates the remote repair to device 101. The function control unit 302 then deletes the device information that was temporarily held in RAM 203.

[0076] In S809, the remote repair application 440 of device 101 notifies RR131 via the network communication unit 403 to reset (initialize) the polling interval of the connection application 430. In S810, the function control unit 302 of RR131 receives the polling interval initialization notification from device 101 via the communication unit 305 and notifies the communication unit 305 that the polling interval of the target device has been initialized. The communication unit 305 modifies the communication parameters as necessary based on the polling interval initialization notification.

[0077] Although this flowchart describes a configuration in which device 101 and RR131 communicate directly, a configuration in which a relay device is placed between device 101 and RR131 is also acceptable. When a relay device is placed between device 101 and RR131, the relay device is responsible for processing related to the polling interval change. On the other hand, regarding processing related to remote repair, the relay device relays requests from device 101 to RR131.

[0078] Next, the operation when a task created by a sales user of RR131 or a customer user of DM132 using the task creation screen 600 or task creation screen 620 is sent to device 101 will be explained using the flowchart in Figure 11. Figure 11 is a flowchart of the task acquisition process in Example 1. Here, the process is explained using the example of a remote device management task created by a customer user of DM132 using the task creation screen 620 and distributed to device 101, but the process for distributing a remote repair task created by RR131 to device 101 is similar. In Figure 11, each process executed by device 101 is realized by the CPU 251 executing a program stored in memory (ROM 252 or HDD 254). Similarly, each process executed by DM132 is realized by the CPU 201 of DM132 executing a program stored in memory (ROM 202 or HDD 212).

[0079] When the connection application 430 periodically starts polling RR131 and DM132, device 101 performs this process for all registered CS130s. This section describes the processes performed by device 101 and DM132 within CS130. In S901, the connection application 430 of device 101 determines whether the specified polling interval has elapsed. If the connection application 430 determines that the specified polling interval has elapsed, it proceeds to S902. On the other hand, if the connection application 430 determines that the specified polling interval has not elapsed, it repeats the process in S901.

[0080] In S902, the connection application 430 of device 101 sends a task acquisition request to DM132 via the network communication unit 403. At this time, the task control unit 404 obtains its own serial number from the system data 421 and sends the serial number to DM132 along with the task acquisition request. In S903, the function control unit 302 of DM132 receives the task acquisition request from device 101 via the communication unit 305. At this time, the function control unit 302 receives the serial number of device 101 along with the task acquisition request.

[0081] In S904, the function control unit 302 of DM132 uses the serial number received from device 101 to determine whether a task targeting device 101 has been registered. The function control unit 302 accesses the task management table 540 via the task management unit 310 and the DB management unit 307 to check whether the serial number of device 101, the source of the task acquisition request, is stored in each record of the target devices in column 543. If the serial number of device 101 is stored in each record of column 543 where the target devices for the task are stored, the function control unit 302 performs the process in S905. On the other hand, if the serial number of device 101 is not stored in each record of column 543 where the target devices for the task are stored, the function control unit 302 performs the process in S906.

[0082] In S905, the task management unit 310 of DM132 retrieves information on task records targeting device 101 from the task management table 540, generates task information based on this information, and passes it to the function control unit 302 of DM132. Here, the task information generated based on the task records targeting device 101 obtained from the task management table 540 is, for example, a task file 720 written in XML format. The function control unit 302 generates a result to send back to device 101 as a response to the task acquisition request and associates the task information with the result. Therefore, if there is a task to be delivered to device 101, the result sent as a response to the task acquisition request will include the task information.

[0083] In S906, the function control unit 302 of DM132 generates a result to send back to device 101 as a response to the task acquisition request. Since there is no task targeting device 101 in the task management table 540, the function control unit 302 does not associate a task with the result sent back to device 101. In S907, the function control unit 302 of DM132 sends the result to device 101, the source of the task acquisition request, via the communication unit 305.

[0084] In S908, the connection application 430 of device 101 receives the result of the task acquisition request from DM132 via the network communication unit 403. The connection application 430 also passes the received result to the task control unit 404. In S909, the task control unit 404 of device 101 determines whether a task is associated with the result of the task acquisition request passed from the connection application 430. If it determines that a task is associated with the result of the task acquisition request, it performs the process in S910. On the other hand, if it determines that a task is not associated with the result of the task acquisition request, it performs the process in S911.

[0085] In S910, the task control unit 404 of device 101 extracts task information from the results of the task acquisition request received from DM132, associates it with the source service DM132, and stores it in system data 421. In S911, the connection application 430 of device 101 waits for the time specified by the polling interval and returns to S901. Through the above process, device 101 periodically sends task acquisition requests to DM132, and DM132, upon receiving the task acquisition request, checks if there are any tasks created targeting the requesting device 101. If there are tasks targeting device 101, DM132 sends task information generated based on the information obtained from the task management table 540 when responding to the requesting device 101, and device 101 acquires the task information. After that, device 101 saves the acquired task information in system data 421. Similarly, remote repair tasks created by RR131 are also acquired by device 101 and saved in system data 421 through the same process.

[0086] Next, the details of the processing (S805) in device 101 during remote repair by RR131 will be explained using Figures 12 and 13. Repair is a process that should be performed with the highest priority in a device. On the other hand, there are cases where the remote repair, which has the highest priority in the device, conflicts with other tasks that have a lower priority than remote repair, such as when the execution time of other tasks is reached during repair, or when remote repair processing is required while other tasks are being executed. Therefore, in this embodiment, the execution of task scripts delivered from a service other than remote repair is controlled while checking whether device 101 is undergoing remote repair by RR131. In particular, Figures 12 and 13 describe the process of controlling the execution of task scripts from another cloud service, DM131, while checking whether remote repair is in progress.

[0087] Figures 12 and 13 are flowcharts showing the remote repair process and the execution of other tasks in Embodiment 1. Each process performed by device 101 in Figures 12 and 13 is realized by the CPU 251 executing a program stored in memory (ROM 252 or HDD 254). The flowcharts in Figures 12 and 13 are divided into two main blocks. The first block is from S1001 to S1006 and concerns the processing of the remote repair task received from RR 131. The second block is from S1011 to S1021 and concerns the processing of tasks other than the remote repair task (for example, the remote device management task received from DM 132). The processing of the first block and the processing of the second block are processed in parallel by device 101.

[0088] First, we will explain the processing related to the remote repair task received from RR131 (processing of the first block). When remote repair (S806) by RR131 is initiated, processing S1001 begins. In S1001, the task control unit 404 sets the "processing flag" to "on" to indicate that remote repair is being performed. The processing flag is located, for example, in system data 421. Note that the processing flag is not limited to being located in system data 421.

[0089] In S1002, the task control unit 404 determines whether there is a task among the tasks held in the system data 421 that is associated with RR131, which provides remote repair services. If the task control unit 404 determines that there is a task associated with RR131, it performs the process in S1003. On the other hand, if the task control unit 404 determines that there is no task associated with RR131, it performs the process in S1002.

[0090] In S1003, the task control unit 404 executes the task associated with RR131. Specifically, the task control unit 404 executes the process described in the script section 730 of the task file 720 associated with RR131 according to the value of the order attribute. In S1004, the task control unit 404 sends the task execution result to RR131 via the network communication unit 403. When RR131 receives the task execution result from device 101, it stores the task execution result in column 545 of the task management table 540.

[0091] In S1005, the UI unit 401 determines whether the remote repair completion button 482 on screen 480 has been pressed by the customer user. If the UI unit 401 determines that the remote repair completion button 482 has been pressed, it proceeds to the process in S1006. On the other hand, if the UI unit 401 determines that the remote repair completion button 482 has not been pressed, it returns to the process in S1002. In S1006, the task control unit 404 sets the value of the "processing flag," which was set to "on" in S1001, to "off." This concludes the explanation of the first block of this flowchart.

[0092] Next, we will explain the processing related to tasks other than remote repair tasks (processing of the second block). Here, we will use the remote device management task received from DM132 as an example of a task other than remote repair tasks, but it is not limited to this. In S1011, the task control unit 404 determines whether there is a task linked to DM132 among the tasks held in the system data 421, and whether the execution time for that task has arrived. Specifically, if there is a task linked to DM132, the task control unit 404 compares the time described in the execution time section 723 of the task file 720 with the time on the device's clock to determine whether the task execution time has been reached. If it is determined that there is a task linked to DM132 and the execution time has arrived, the process in S1012 is performed. On the other hand, if there is no task linked to RR131, or if there is a task linked to RR131 but the task execution time has not been reached, the process returns to S1011. Note that the S1011 process is performed periodically on device 101, regardless of remote repair.

[0093] In S1012, the task control unit 404 retrieves tasks that have reached the execution time associated with DM132 and determines whether each process described in the script description unit 730 is a process that changes the device configuration. Specifically, it determines whether the value of the confcng attribute of the tag for each process is 1. If the value of the confcng attribute is 1, the task control unit 404 determines that it is a process that changes the device configuration. If the task control unit 404 determines that the retrieved tasks include one or more processes that change the device configuration, it performs the process in S1014. On the other hand, if the task control unit 404 determines that the retrieved tasks do not include processes that change the device configuration, it performs the process in S1013.

[0094] In S1013, the task control unit 404 executes the process described in the script description section 730 of the task file 720 according to the value of the order attribute. The process in S1013 is the same as the process in S1003. Therefore, if no tasks other than the remote repair task include processing to change the device configuration, the task is executed without checking the processing flag indicating whether or not remote repair is in progress. Due to the processes in S1012 and S1013, even if remote repair is in progress, if the settings of device 101 are not changed by the execution of a task script provided by a service other than remote repair, control is performed so as not to interrupt the execution of the script.

[0095] If a task other than the remote repair task includes processing to change the device configuration, the task control unit checks the processing flag to indicate whether or not remote repair is in progress. In S1014, the task control unit 404 checks the processing flag to determine whether or not device 101 is undergoing remote repair by RR131. Specifically, the task control unit 404 determines whether or not the value of the processing flag is "off". If the processing flag is "off", it means that remote repair is not being performed. If the task control unit 404 determines that the processing flag is "off", it performs the process in S1015. On the other hand, if the task control unit 404 determines that the processing flag is "on", that is, not "off", it performs the process in S1019. In this way, the task control unit 404 also functions as a means of confirming whether remote processing (remote repair) is in progress using the repair flag.

[0096] If the processing flag is "off" and it is confirmed that remote repair is not in progress, device 101 executes a task script provided by a service other than remote repair. In S1015, the task control unit 404 executes only one unexecuted process from the processes listed in the script description section 730 of the task file 720, the one with the smallest order attribute value. Once the unexecuted process with the smallest order attribute value listed in the script description section 730 is completed, it performs the process in S1016. The task control unit 404 determines whether the processing flag value is "off" or not.

[0097] In S1016, the task control unit 404 checks the value of the processing flag again. Specifically, the task control unit 404 determines whether the value of the processing flag remains "off". If the task control unit 404 determines that the value of the processing flag remains "off", it performs the process in S1017. On the other hand, if the task control unit 404 determines that the value of the processing flag has changed to "on", it performs the process in S1018.

[0098] In S1017, the task control unit 404 determines whether all the processes described in the script description section 730 have been executed. If the task control unit 404 determines that all the processes described in the script description section 730 have been executed, it proceeds to the process in S1021. If the task control unit 404 determines that there are still processes in the script description section 730 that have not been executed, it returns to the process in S1015. By repeating the processes in S1015 to S1017, as long as the value of the processing flag remains "off," that is, as long as the state of not performing remote repair continues, the processes described in the script are executed one by one. In this way, when the device 101 continues to confirm that it is not performing remote repair, it controls the execution of the task script provided by a service other than remote repair. In S1016, if it is detected that the processing flag has changed from "off" to "on," the process in S1018 is performed. In S1018, the task control unit 404 stops the execution of the currently running script midway through.

[0099] In the example shown in Figure 13, if remote repair is required after some script execution (if the result in S1016 is No), processing is stopped in S1018. However, it is also possible to temporarily suspend script execution in S1018. That is, if remote repair is required, script execution is temporarily suspended in S1018. Then, if remote repair is required, the process in S1020 is performed to confirm whether or not remote repair is being performed. If remote repair is required, script execution is suspended again, and if it is confirmed that remote repair is not being performed, script execution is resumed in S1015.

[0100] In S1014, if the processing flag is determined to be "on", the process in S1019 is performed. That is, if remote repair processing was being performed at the time the task was executed, the process in S1019 is performed. In S1019, the task control unit 404 temporarily suspends the script. In S1020, the task control unit 404 checks the value of the processing flag again. Specifically, it determines whether the value of the processing flag has changed from "on" to "off". If the task control unit 404 determines that the value of the processing flag has changed to "off", it performs the process in S1015. On the other hand, if the task control unit 404 determines that the value of the processing flag has not changed to "off", that is, that the value of the processing flag remains "on", it returns to S1020.

[0101] In S1021, the task control unit 404 similarly sends the task execution result to DM132 via the network communication unit 403. When DM131 receives the task execution result from device 101, it stores the task execution result in column 545 of the task management table 540. In this process, when executing a task that changes the device configuration other than a remote repair task, the value of the "processing" flag is checked before the start of the process described in the script and after each process is performed to determine whether to continue executing the task. If the value of the "processing" flag is "off," i.e., remote repair is not in progress, the process described in the script can be executed. On the other hand, if the value of the "processing" flag is "on," i.e., remote repair is in progress, the execution of the script is interrupted. Also, if the value of the "processing" flag changes from "off" to "on," i.e., if remote repair processing is started while the task script is being executed, the execution of the script can be stopped midway. If the "Processing" flag is "on," the script execution will be suspended and waited until it becomes "off," that is, until the remote repair is completed. The script will then be executed after confirming that the remote repair has finished based on the value of the "Processing" flag. Therefore, while a remote repair is in progress, it is possible to prevent the device configuration from being changed by tasks delivered from services other than the remote repair service.

[0102] Through the above process, according to this embodiment, another cloud service will not be able to change the device configuration while the customer user is using the remote repair service. This prevents unexpected device configuration changes during remote repair and allows high-priority remote repair processing to be properly applied to the device.

[0103] (Example 2) In Example 1, we described an example where the execution of another service's task was suspended while a remote repair task was being performed, and the other service's task was executed after the remote repair task was completed. However, executing another service's task after the remote repair task is completed may cause the changes made during the remote repair to be reverted, or the same script processing to be executed repeatedly. Therefore, in this example, we aim to avoid these phenomena when device 101 executes another service's task after remote repair. The following will focus on the differences from Example 1.

[0104] Figure 14 shows an example of a table managed by device 101. Note that the table configuration shown in Figure 14 is an example and is not limited to this configuration. Figure 14(A) is the task management table 1100. The task management table 1100 includes columns 1101 to 1105. Each record represents one task.

[0105] Column 1101 is the task ID. The task ID stored in column 1101 is the same as the task ID stored in column 541. Column 1102 is the registration time. Column 12 stores the time when device 101 received the task from CS130 and registered it in the task management table 1100. Column 1103 is the source service. Column 1103 stores the name of the service from which the task was obtained. For example, in this embodiment, RR131 and DM132 are assumed to be cloud services, so the name of one of these will be stored.

[0106] Column 1104 is the script ID. Script ID 1104 stores the value of script ID 1131 from the script management table 1130 (Figure 14(C)), which will be described later. Column 1105 is the task execution status. Column 1105 stores "Completed" if the task has been executed, and "Not yet executed" if the task has not been executed. Note that the values ​​stored in column 1105 are not limited to these; for example, it could be left blank if the task has not been executed.

[0107] Figure 14(B) shows the configuration information management table 1120. The configuration information management table 1120 is a table used by the task control unit 404 of device 101 to manage the configuration information included in the task received from RR131. The configuration information management table 1120 includes columns 1121 to 1124. Each record represents one piece of configuration information. The table structure of the configuration information management table 1120 is the same as that of the configuration information management table 520 shown in Figure 6(C). That is, column 1121 is the configuration information ID and corresponds to column 521. Columns 1122 to 1124 list examples of configuration information. Note that the configuration information is not limited to those exemplified here. Column 1122 is the IP address and corresponds to column 522. Column 1123 is the gateway address and corresponds to column 523. Column 1124 is the subnet mask and corresponds to column 524.

[0108] Figure 14(C) shows the script management table 1130. The script management table 1130 is a table used by the task control unit 404 of device 101 to manage scripts included in tasks received from RR131. The script management table 1130 includes columns 1131 to 1136. Each record represents one piece of script information. Columns 1131 to 1136 correspond to columns 531 to 536 in Figure 7(A), respectively.

[0109] In this embodiment, the operation when a task created by a sales user of RR131 or a customer user of DM132 using the task creation screen 600 or task creation screen 620 is sent to a device will be explained using the flowchart in Figure 15. Figure 15 is a flowchart of the task acquisition process in Embodiment 2. Here, the process is explained using the example of a remote device management task created by a customer user of DM132 using the task creation screen 620 and distributed to device 101, but the process for distributing a remote repair task created by RR131 to device 101 is similar. In Figure 15, each process executed by device 101 is realized by the CPU 251 executing a program stored in memory (ROM 252 or HDD 254). Similarly, each process executed by DM132 is realized by the CPU 201 of DM132 executing a program stored in memory (ROM 202 or HDD 212).

[0110] When the connection application 430 periodically starts polling RR131 and DM132, device 101 performs this process for all registered CS130s. This section describes the processes performed by device 101 and DM132 within CS130. In S901, the connection application 430 of device 101 determines whether the specified polling interval has elapsed. The processes in S901 to S909 are the same as those in Figure 11 of Embodiment 1. In S909, the task control unit 404 of device 101 determines whether a task is associated with the result of the task acquisition request handed over from the connection application 430. If it determines that a task is associated with the result of the task acquisition request, it performs the process in S1201. On the other hand, if it determines that a task is not associated with the result of the task acquisition request, it performs the process in S911.

[0111] In S1201, the task control unit 404 of device 101 registers task information in the task management table 1100, in addition to the processing in S910. Therefore, in S1201, the task control unit 404 extracts task information from the results of the task acquisition request obtained from DM132, links it to the source service DM132, and registers it in the system data 421 and the task management table 1100. When registering task information in the task management table 1100, the time the task was registered is stored in the registration time 1102, and the name of the service that requested this task (for example, DM132) is stored in the source service 1103. The execution status column 1105 is stored as "Not done". Furthermore, in S1201, the task control unit 404 also stores the corresponding information in the script management table 1130 and the configuration information management table 1120. Specifically, the task control unit 404 extracts configuration information from the results of the task acquisition request obtained from DM132 and registers it in the configuration information management table 1120. The task control unit 404 extracts script information from the results of the task acquisition request received from DM132 and registers it in the script management table 1130. Once the registration of the information obtained from the results in S1201 into each table is complete, the device 101 performs the process in S911. S911 is the same as the process described in Figure 11 of Embodiment 1.

[0112] Next, the details of the remote repair process (S805) performed by device 101 in this embodiment will be explained using Figures 16 and 17. Figures 16 and 17 are flowcharts showing the remote repair process and the execution process of other tasks in Embodiment 2. In Figures 16 and 17, each process performed by device 101 is realized by the CPU 251 executing a program stored in memory (ROM 252 or HDD 254). In Figures 16 and 17, processes S1001 to S1006 and S1011 to S1021 are the same as the processes described in Embodiment 1 (Figures 12 and 13), so their explanation will be omitted.

[0113] In S1020, the task control unit 404 checks the value of the processing flag again. Specifically, it determines whether the value of the processing flag has changed from "on" to "off". If the task control unit 404 determines that the value of the processing flag has changed to "off", it performs the process in S1301. On the other hand, if the task control unit 404 determines that the value of the processing flag has not changed to "off", that is, that the value of the processing flag remains "on", it returns to S1020.

[0114] In S1301, the task control unit 404 determines whether the task being processed was registered before the remote repair task. Specifically, the task control unit 404 determines whether the registration time 1102 of the task interrupted in S1019 is earlier than the registration time 1102 of the remote repair task. The registration time 1102 of the remote repair task is the registration time 1102 of each record where the requesting service 1103 value is "RR131" and the task execution status in column 1105 is "Completed". Since the remote repair task is an immediate execution task, the registration time 1102 is the same as the execution date and time of the remote repair task. If the task control unit 404 determines that the task being processed was registered before the remote repair task, that is, if the registration date and time of the task being processed is earlier than the execution date and time of the remote repair, it performs the process in S1302. On the other hand, if the task control unit 404 determines that the task being processed was not registered before the remote repair task, that is, if the registration date and time of the task being processed is later than the date and time of the remote repair, it performs the process in S1015.

[0115] In S1302, the task control unit 404 determines whether the processing (script) included in the task being processed is related to the processing included in the remote repair task executed earlier. Specifically, the task control unit 404 determines whether the processing in each column stored in the script management table 1130 overlaps between the task being processed and the remote repair task compared in S1302. In the example of the script management table 1130 shown in Figure 14(C), the processing of the first record and the processing of the second record do not overlap, so the task control unit 404 determines that they are not related processes. On the other hand, for example, if both the task being processed and the remote repair task compared in S1302 include a script to update the firmware, then the task control unit 404 determines that the processing in the task being processed and the remote repair task executed earlier are related. Note that only all or some of the processes for which the value of column 552 in the configuration change management table 550 is 1 may be considered for evaluation. If the task control unit 404 determines that the processing included in the task being processed is related to the processing included in the remote repair task, it performs the process in S1018. On the other hand, if the task control unit 404 determines that the processing included in the task being processed is not related to the processing included in the remote repair task, it performs the process in S1015. The subsequent processing is the same as the processing described in Embodiment 1 shown in Figure 13. In addition, in S1021, the task control unit 404 may similarly notify the DM132 of a review of the processing for the task that was aborted in S1018 when sending the task execution result to the DM132 via the network communication unit 403. That is, if the device 101 aborts the execution of a script, it may notify the service that provided the task of a review of the processing.

[0116] As explained above, in this embodiment, after the remote repair is completed, the execution of the task script is controlled by the processes in S1301 and S1302 based on the task's registration date and time and its processing content. If a task to be executed after the remote repair is completed was registered before the remote repair was performed, and the processing content of the task's script is related to the processing performed by the remote repair, the execution of the script is stopped. This prevents the risk of the remote repair being reversed, for example, if a firmware upgraded by the remote repair is downgraded by the execution of a task's firmware update script. It also prevents the risk of the remote repair being reversed (reverting to a previous setting) if a setting value updated by the remote repair is modified by a task's device setting value change script. On the other hand, if a task to be executed after the remote repair is completed was registered after the remote repair was performed, the task's script is executed. Also, if a task to be executed after the remote repair is completed was registered before the remote repair was performed, and the processing content of the task's script is not related to the processing performed by the remote repair, the task's script is executed.

[0117] By executing the processes shown in Figures 15, 16, and 17, this embodiment makes it possible to avoid reverting the changes made during remote repair when another service task is executed after the remote repair task is completed. Furthermore, by executing the processes shown in Figures 15, 16, and 17, this embodiment makes it possible to avoid repeatedly executing the same script when another service task is executed after the remote repair task is completed.

[0118] (Example 3) In Example 2, we described an example of how to avoid reverting the changes made during remote repair or repeatedly executing the same actions when another service task is executed after the completion of a remote repair task. However, if the process is stopped simply because it contains the same processing as in Example 2, there is a risk that processing that further improves the processing performed during remote repair will also be stopped. Therefore, in this example, we describe an example in which device 101 can execute processing that improves itself without stopping when executing another service task after remote repair. The following will focus on the differences from Example 2.

[0119] Details of the remote repair process (S805) performed by device 101 in this embodiment will be explained using Figures 18 and 19. Figures 18 and 19 are flowcharts showing the remote repair process and the execution process of other tasks in Embodiment 3. In Figures 18 and 19, each process performed by device 101 is realized by the CPU 251 executing a program stored in memory (ROM 252 or HDD 254). In Figures 18 and 19, processes S1001 to S1006 and S1011 to S1021 are the same as the processes described in Embodiment 1 (Figures 12 and 13), so their explanation is omitted. Also, S1301 and S1302 are the same as the processes described in Embodiment 2, so their detailed explanation is omitted.

[0120] In S1302, the task control unit 404 determines whether the processing included in the task currently being processed is related to the processing included in the remote repair task. If the task control unit 404 determines that the processing included in the task currently being processed is related to the processing included in the remote repair task, it performs the process in S1401. On the other hand, if the task control unit 404 determines that the processing included in the task currently being processed is not related to the processing included in the remote repair task, it performs the process in S1015.

[0121] In S1401, the task control unit 404 determines whether the processing included in the task being processed improves the processing included in the remote repair task. Specifically, if the processing of FW1132 or the extended application 1133 overlaps between the task being processed and the remote repair task that was compared in S1302, the task control unit 404 checks the version information of each entity. For example, the FW version information is described in the file that defines the contents included in the FW entity. The extended application version information is described in the manifest file included in the extended application entity. If the version of the FW or extended application included in the task being processed is newer, it can be determined that the task being processed improves the processing included in the remote repair task. Note that only all or part of the processing for which the value of column 552 in the configuration change management table 550 is 1 may be considered for determination. Specifically, only processing whose target is firmware or an extended application may be considered for determination in S1401. If the task control unit 404 determines that the processing included in the task being processed improves the processing included in the remote repair task, it performs the processing in S1015. On the other hand, if the task control unit 404 determines that the processing included in the task being processed does not improve the processing included in the remote repair task, it performs the processing in S1018. In this embodiment, the processing in S1401 enables the device 101 to execute the script if it improves the content of the remote repair processing, even if the content of the script processing is related to the content of the remote repair processing.

[0122] Through the above process, in this embodiment, when a task for another service is executed after the completion of a remote repair task, it is possible to avoid the interruption of processing that further improves the processing performed during remote repair. On the other hand, when a task for another service is executed after the completion of a remote repair task, if the processing does not further improve the processing performed during remote repair, it is possible to avoid reverting the parts that were corrected during remote repair to their original state.

[0123] The disclosure of this embodiment includes the following system configuration. (Composition 1) A network device that receives multiple services, including remote repair, which involves repairing the network device from a remote location via a network, A means for confirming whether the network device is undergoing remote repair through the remote repair service, The system includes a control means that controls the execution of a task script provided by a service other than the remote repair service when the confirmation that remote repair is not in progress continues, The control means is a network device characterized by interrupting the execution of the script when remote repair is in progress. (Configuration 2) The network device according to Configuration 1, characterized in that even when remote repair is in progress, the control means does not interrupt the execution of the script if the settings of the network device are not changed by the execution of a task script provided by a service other than the remote repair. (Composition 3) The network device according to configuration 1 or 2, characterized in that the control means cancels the execution of a script if the task to be executed after the completion of the remote repair was registered before the date and time the remote repair was performed, and the content of the processing by the script of the task is related to the content of the processing performed by the remote repair. (Composition 4) The network device according to configuration 3, characterized in that the control means executes the script if the content of the processing by the script for the task improves the content of the processing by the remote repair, even if the content of the processing by the script for the task is related to the content of the processing by the remote repair. (Composition 5) The network device according to configuration 4, characterized in that the target of the processing when determining whether the content of the processing by the script for the task improves the content of the processing by the remote repair is firmware or an extended application. (Composition 6) The network device is characterized in that, if the execution of the script is interrupted, it notifies the service that provided the task to review the process, as described in any one of configurations 1 to 5.

[0124] (Other embodiments) The present invention can also be realized by supplying a program that implements one or more of the functions of the above-described embodiments to a system or device via a network or storage medium, and by having one or more processors in the computer of that system or device read and execute the program. It can also be realized by a circuit (e.g., an ASIC) that implements one or more functions.

[0125] Although preferred embodiments of the present invention have been described above, the present invention is not limited to these embodiments, and various modifications and changes are possible within the scope of its gist.< / rebootcommand> < / getstatuscommand> < / conffileid> < / conffileid> < / deviceconfigcommand> < / path> < / installappcommand> < / path> < / updatefirmwarecommand> < / time> < / sn> < / id> < / sn> < / model>

Claims

1. A network device that receives multiple services, including remote repair, which involves repairing the network device from a remote location via a network, A means for confirming whether the network device is undergoing remote repair through the remote repair service, The system includes a control means that controls the execution of a task script provided by a service other than the remote repair service when the confirmation that remote repair is not in progress continues, The control means is a network device characterized by interrupting the execution of the script when remote repair is in progress.

2. The network device according to claim 1, characterized in that the control means does not interrupt the execution of the script even when remote repair is in progress, if the settings of the network device are not changed by the execution of a task script provided by a service other than the remote repair.

3. The network device according to claim 1, characterized in that the control means cancels the execution of a script if the task to be executed after the completion of the remote repair was registered before the date and time the remote repair was performed, and the content of the processing by the script of the task is related to the content of the processing by the remote repair.

4. The network device according to claim 3, wherein the control means executes the script if the content of the processing by the script for the task improves the content of the processing by the remote repair, even if the content of the processing by the script for the task is related to the content of the processing by the remote repair.

5. The network device according to claim 4, characterized in that the target of the processing when determining whether the content of the processing by the script for the task improves the content of the processing by the remote repair is firmware or an extended application.

6. The network device according to claim 1, characterized in that, if the execution of the script is interrupted, it notifies the service that provided the task to review the process.

7. A method for controlling a network device that receives multiple services, including remote repair, which involves repairing the network device from a remote location via a network, A step of confirming whether the network device is undergoing remote repair through the remote repair service, The process includes a step of controlling the execution of a task script provided by a service other than the remote repair, while the confirmation that remote repair is not in progress is still being made. A method for controlling a network device, characterized by interrupting the execution of the script when remote repair is in progress.

8. A program that causes the computer of an information processing device to execute each of the steps described in claim 7.

Images