JP2018190341A - System and distribution method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a distribution system capable of reducing a load on a server when updating software of a device. SOLUTION: The distribution system, asynchronously with software distribution, considers the version dependency between firmware and application in advance, and obtains an appropriate combination of firmware and application to be distributed to each device. At the time of automatic update, the current firmware version is received from the device and delivered by the combination of the firmware and the appropriate version of the application requested in advance. [Selection diagram] FIG. 5

Description

  The present invention relates to a system and a distribution method for managing and distributing software installed in a client such as a device.

  In a device such as a multifunction peripheral, two types of software, firmware for realizing the intrinsic function of the device and an application installed and used later for each user, can be used. Usually, an application is selected, installed, and activated by a user. An application may require an additional usage fee (license) for use.

  By the way, firmware and applications (collectively referred to as software) may be upgraded for defect correction and function expansion. In the version upgrade, not only the firmware but also the application may be installed by the device manufacturer or the seller. Furthermore, when installing software or updating to upgraded software, devices are connected to a distribution server via a network, and software distribution from a remote location is also performed.

  In general, PCs and mobile terminals provide a mechanism for automatically inquiring of a distribution server from a client periodically to upgrade software. In these clients, the inquiry to the distribution server and the timing of version upgrade can be selected relatively freely because there are always users who make settings on the client side.

  There is also a demand for a mechanism for performing the same automatic version upgrade in devices such as multifunction peripherals. However, while an unspecified number of users use it in an office or the like, the manager of the device is often in a remote place. Therefore, as a feature of these devices, there is at most one kind of timing at which automatic version upgrade is possible in any device. That is, it is the timing when office work using the device is closed. This is limited to late nights in the area on a particular day of the week, and in many business categories, late nights on weekends. For this reason, the firmware version of each device and the automatic version upgrade of the application running on the device must be collectively implemented at this limited timing.

  By the way, the version of an application that runs on a device may depend on the version of firmware that forms part of the platform. For example, there is a case where the version of an application that needs to be updated before upgrading the firmware or the version of the firmware that is necessary for the operation of a certain version of the application is limited. For example, as in Patent Document 1, a management apparatus that transmits installation information to acquire a plurality of update data and acquires order information indicating the order of updates has been proposed. The distribution server here generates order information that does not specify the update order when there is consistency regardless of the versions between multiple software, and order information that specifies the update order when there is no consistency depending on the versions Is generated.

Japanese Patent No. 5293522

  Device users do not always want to keep all applications up to date. There are times when you want to continue to use a specific version for each user's circumstances. Further, from the viewpoint of the device or application seller, there are cases where the application version is upgraded only to those distributed at the discretion of the service person, such as security measures and emergency failure response.

  For this reason, it is necessary to determine the application to be distributed and the version, that is, to specify the update target application and the version for each device. This determination requires three types: firmware upgrade determination, application upgrade determination for each application, and application upgrade determination depending on the firmware version.

  However, as described above, if these three determinations are performed simultaneously at one limited timing, the server load during the distribution process increases.

  The present invention has been made in view of the above conventional example, and an object of the present invention is to provide a software system and method capable of reducing the load on a server when updating device software.

  In order to achieve the above object, the present invention has the following configuration.

A system comprising a plurality of devices and a distribution system,
The distribution system includes:
Management means for managing version information of firmware and applications installed in the device and version information scheduled to be updated of the firmware and applications for each device ID;
In response to receiving an update notification including the device ID of the device and the version information of the application installed on the device from the device, the version information of the application installed on the device managed by the management unit Updating means for updating the version information to be updated of the firmware and application managed by the management means;
Receiving means for receiving a firmware update confirmation request including a device ID of the device and version information of firmware installed in the device from the device;
Based on the version information of the firmware indicated by the information included in the confirmation request received by the reception unit, the version information scheduled to be updated of the firmware is specified, and further, the device ID included in the confirmation request is specified by the management unit. When the update schedule for the corresponding application has already been managed, based on the update schedule, specifying means for specifying version information of the update schedule for the application installed on the device;
Response means for transmitting the identified version information of the firmware update schedule and the version update information of the application to the device as a response to the confirmation request;
In the device, the firmware and application are updated according to the response, and an update notification including a device ID and version information of the updated application is transmitted to the distribution system according to the update of the application. .

  ADVANTAGE OF THE INVENTION According to this invention, the load of the server at the time of updating the software of a device can be reduced.

System Configuration Diagram showing server hardware configuration Functional block diagram of distribution system and device Diagram showing an example of the sequence of application and FW installation The figure which shows the example of a sequence in an application and FW automatic update Flow chart showing processing at the time of application update notification reception Flow chart for updating version information Flowchart for determining the firmware version to be updated Flowchart for determining application version to update Flow chart showing automatic update inquiry reception process Update schedule version information update batch processing flowchart The figure which shows the example of a sequence in the user mode update of an application and FW

System Configuration FIG. 1 is a block diagram showing a system configuration diagram of this embodiment. The distribution system 10 includes a web server 12, a DB server 13, and an application server 11. And it communicates with the devices 115-116,120,121,124-127,131 of each customer company 114,119,129 via the Web server 12 connected to the internet 100. FIG. Thereby, distribution control of the application program (hereinafter abbreviated as “application”) and firmware (hereinafter abbreviated as “FW”) is performed. The application program and firmware may be collectively referred to as software. The actual file of the application and the FW is in the content server 20, and when the application is installed in the device, the distribution system 10 acquires the location information of the actual file on the content server 20, and the software is distributed from the content server to the distribution destination, for example Download to device or personal computer. At each customer site, software files are distributed to devices via personal computers 117, 122, 123 and LANs 118, 128, or via LAN 130, and the software is updated. As a result, the software distribution load of many devices can be distributed and the software can be distributed efficiently. The same applies to the update of each app and FW. The content server 20 includes a content management server 21 and file storages 22 and 23. The content management server 21 stores or provides file contents, that is, applications and FWs in accordance with external requests.

  There are various types of devices such as a multi-function printer (MFP) and a single function printer (SFP), and one or a plurality of functions are mounted for each device model. By installing the FW to realize these functions, each function of the device can be used. It is also possible to install and execute an application that can be executed in common for each device model or for each device model. The user of the device performs installation by selecting a desired application from among a plurality of applications that can be used on the device, and purchasing and obtaining the application. In addition, when a defect in a device application is corrected, or when a function is improved or added, it can be used by updating the application. The application can download and install or update the content when the device communicates with the distribution system 10. A device connected to the network may be referred to as a network device or a network device. In the sales company system 30, a device manufacturer or a device sales company that sells, maintains, and manages devices to the customer companies 114, 119, and 129 performs operations for registration and management of applications and FWs. The sales company system 30 includes one or more PCs 31 and 32 or servers 33 and 34. By accessing the distribution system 10 and the content server 20 from the sales company system 30, registration of the application and FW and distribution setting are performed. In addition, the device has a mechanism for automatically updating firmware and applications, and can set a date and time for regularly confirming update information to the distribution system 10.

Server Configuration FIG. 2 is a block diagram showing the hardware configuration of this embodiment. The application server 11 in this embodiment is connected to the Web server 12 and the DB server 13 via the network interface 204. The application server 11 includes a CPU 201, a RAM 202, a ROM 203, a network interface 204, an HDD 206, and the like connected via a bus 205. The distribution system 10 is realized by reading out data and programs recorded in the HDD 206, the ROM 203, and the RAM 202 and executing them by the CPU 201. Moreover, the function may be implement | achieved by cooperation of the function of a some server. The network interface 204 is used for function cooperation between servers in the distribution system 10 and is also used for communicating with an external system via the Internet 100. Although FIG. 2 is illustrated corresponding to the application server 11, it is assumed that other servers and devices have the same hardware configuration.

Functional Configuration of Distribution System FIG. 3 is a block diagram showing the functional configuration of the distribution system 10 and devices in the present embodiment. A web browser 302 indicates a web browser which is a client system of a sales company system connected to the distribution system 10. Therefore, the web browser 302 is not included in the distribution system 10. In the following description, the distribution system 10 is called a distribution server and may be distinguished from a software distribution system including a device.

The web interface unit 310 provides an app and FW distribution function for a device. The web interface unit 310 receives various requests from each device and returns a processing result. For example, when a request for app delivery information is received, the location where the target app is stored is searched and returned as a URL for acquiring the app. Details of the request processing will be described later.
The user interface unit 311 accesses the distribution system and performs application and FW registration, distribution settings, and periodic update settings.
The request receiving unit 312 receives a request from the device.
The response reply unit 313 returns a response to the device.
The distribution setting control unit 314 controls distribution settings for FW and applications.
The batch processing unit 315 performs asynchronous update of management information.
Reference numeral 317 denotes a distribution control unit that performs control associated with distribution to devices.
The scheduler 318 starts batch processing at regular intervals.

The DB access unit 320 updates or searches the data in the table managed by the data management unit 330 according to various processes. The table managed by the data management unit 330 includes the following. Each table will be described later.
Application information management table 331
Registered application management table 332
Application version management table 333
Registered firmware management table 334
Firmware version management table 335
Version restriction management table 336
Device management table 337
Update scheduled version management table 338.

On the other hand, the device 400 has the following configuration. The configuration here is a configuration for performing a new or update installation of software, and a configuration for performing a function as a device such as copying is omitted. The main processing unit 340 executes the original function of the device 400. The main processing unit 340 performs a main function such as performing an image forming process for a printer, for example. In addition to this main function, the device 400 also has a function for performing device FW and application distribution control. These are function blocks 341 to 348. The distribution control here may include, for example, a procedure of checking for updates at a specified time, receiving downloaded software, and updating.
The web interface unit 341 receives the distribution of the application and FW from the distribution system 10 and is connected to the web interface 310 of the distribution system 10 using, for example, HTTP.
For example, the distribution processing unit 342 checks that the time (day of the week, time, etc.) separately designated by the sales company system 30 is reached. Further, for example, when the designated time comes, the distribution server 10 can be inquired of whether or not the firmware has been updated via the Web interface unit 341.
The application installation unit 343 installs the downloaded application to be installed.
The application update unit 344 updates the downloaded application to be updated.
The FW update unit 345 updates the downloaded firmware to be updated.
The FW storage unit 347 stores the distributed FW.
The application storage unit 348 stores the distributed application.

Sequence Example of Manual Update Processing FIG. 4 is a sequence diagram illustrating an example of a flow when a device operation of an app installation by a device user or a firmware installation by a service person is performed on a device.

In order to install a new application on the device 400, the user 401 operates the user interface of the device 400 and issues an application installation instruction 410.
In response to the instruction 410, the device 400 sends an application delivery information request 411, which is information for specifying an application to be installed, to the distribution system 10 and requests application information for specifying the corresponding application. On the other hand, the distribution system 10 processes a request from the device 400 by the web interface unit 310. The distribution system 10 responds to the device 400 with application information 412 including, for example, identification information of the application to be installed, in accordance with the information (application) specified by the application delivery information request 411. The device 400 further transmits an application version designation 413 that designates the version of the application to the distribution system 10. The distribution system 10 responds with a URL response 414 for downloading the specified version of the specified application. Hereinafter, the request from the device 400 processed by the distribution system 10 will be described as being processed by the Web interface unit 310. The application delivery information request 411 and the application version designation 413 may be a single message if they can be combined into a single message.

  The device 400 accesses the content server 20 with the responded URL, and transmits an application request 415 for requesting an application file to be installed. The application request 415 is an HTTP request for the acquired URL, for example. Using the application file acquired in response 416, device 400 performs an application installation process 417. When the installation process 417 ends and the installed application is activated, the device 400 transmits to the distribution system 10 an application update notification 418 that notifies the completion of the installation of the application. At this time, the distribution system 10 is notified of the list information of the applications and versions installed in the device 400 at that time, including newly installed applications. That is, the application update notification 418 includes list information of installed applications and versions.

  Upon receiving the application update notification 418 from the device 400, the distribution system 10 records it and executes an application status record 419 that updates information on the application currently installed in the device 400. Information indicating the application state of the device may be updated by overwriting, or may be updated while leaving a history. When the distribution system 10 records the state of the application, the distribution system 10 returns a response 420 to the device 400.

  Further, at another timing (that is, asynchronously with software installation or update), the service person 404 connects, for example, the PC 31 for installing firmware to the device 400 to the device 400. The firmware is recorded on the hard disk of the PC 31 connected to the device 400 or another medium. The firmware to be installed from the PC 31 to the device 400 is uploaded according to the firmware installation operation 430 from the connected PC 31. The device 400 executes a firmware update process 431 with the uploaded firmware version, and executes a device restart process 432 for restarting the device 400 itself. After the restart, the device 400 is activated by the installed version of the firmware, the firmware update completion display 433 is displayed, and the installation of the firmware by the service person 404 is completed.

  As described above, application installation (including update) and firmware update can be executed with an operation by the user 401 or the service person 404 as a trigger.

Sequence Example of Automatic Update Processing FIG. 5 is a sequence diagram showing an example of exchange of firmware and application automatic update processing performed between the device 400 and the distribution system 10. The device 400 is regularly set with a date and time for checking whether firmware and applications have been updated. At this date and time, for example, every Sunday at midnight, the device 400 sends an applicable FW information request (also referred to as a confirmation request) 441 to the distribution system 10 to update the firmware and application versions. Queries the presence or absence. At this time, the inquiry from the device 400 includes information indicating the current firmware version of the firmware incorporated in the device 400. Note that the applicable FW information request 441 that is an inquiry from the device 400 does not need to include version information of an application installed in the device 400. In response to the applicable FW information, the distribution system 10 responds with firmware and application information (FW / application information) 442 to be updated by the device 400.

  The FW / application information 442 responding to the device 400 includes, for example, a combination of content type, ID, and version (see Table 9). The content type indicates whether the app is updated before the FW update, the app is updated after the FW update, or the firmware. ID indicates an application ID or a device model. The version indicates the version of each content. This indicates to the device 400 the application and / or firmware to be updated.

  Here, regarding the firmware, the distribution system 10 can determine whether or not there is an update based on the firmware version (including firmware identification information) received from the device 400. As for the application, when the distribution system 10 has information (including a version) related to the application installed in each device, the presence or absence of the update can be determined based on the information. For example, if a version newer than the currently installed application version is prepared for the application, the application identification information and version may be returned as the application information. Regarding the order of installation, information indicating restrictions on the order of installation defined separately may be referred to. The device 400 updates the firmware and the application in sequence 443 and later according to the information about the firmware and the application received in the FW / application information 442.

  First, in the entire software distribution system, if there is an application to be updated before updating the firmware, the sequence 443 is executed. In sequence 443, the device 400 sends the application and version information acquired from the received FW / application information 442 to the distribution system 10 as the application version designation 444, and receives the download URL 445 as a response. When the device 400 transmits the application version specification 444, if the FW / application information 442 includes a version newer than the current version of the application installed in the device 400, the device 400 transmits the application version specification 444 for the application. To do.

  The device 400 accesses the content server 20 with the responded URL and requests 446 the application file to be installed. Using the application file acquired in the response 447, the device 400 updates the application to a new version through an application update process 448. When the update of the application is completed and the updated application is activated, the device 400 notifies the distribution system 10 of the completion of the update of the application by the application update completion notification 449. At this time, the distribution system 10 is notified of the list information of the applications and versions installed in the device 400 at that time, including the updated application.

  Upon receiving the application update notification 449 from the device 400, the distribution system 10 performs an application status record 450 to update 450 information on the application currently installed in the device 400. When the distribution system 10 records the state of the application, the distribution system 10 returns a response 451 to the device 400.

  The sequence 443 is repeated by the number of applications when there are a plurality of applications to be updated before updating the firmware. A plurality of applications may be updated in a single procedure.

  Next, when there is a firmware version to be updated, the sequence 452 is executed. In sequence 452, the device 400 sends information specifying the firmware version from the FW / application information 442 to the distribution system 10 and receives the download URL 454. The method of determining information specifying the firmware version may be the same as that of the application.

  The device 400 accesses the content server 20 with the URL 454 that has been responded to, and transmits an FW request 455 requesting a firmware file to be installed. Using the firmware file 456 acquired in the response 456, the device 400 performs a firmware update process 457. When the version update is completed and a device restart process 458 for restarting the device 400 is performed, the device 400 notifies the distribution system 10 of a firmware update notification 459. At this time, the firmware update notification 459 notifies the distribution system 10 of updated firmware version information.

  Upon receiving the firmware update notification 459 from the device 400, the distribution system 10 executes the FW status record 460 that records it, and updates 460 information on the current version of the device firmware. When the distribution system 10 records the firmware version information, the distribution system 10 returns a response 461 to the device 400.

  Finally, if there is a version of the application to be updated after updating the firmware, the sequence 462 is executed. Processes 463 to 470 in the sequence 462 are the same as those in the sequence 443. When there are a plurality of applications to be updated after the firmware is updated, the process is repeated for the number of applications.

Information Managed by Distribution System 10 Next, information managed by the distribution system 10 and information exchanged with devices in the present invention will be described. Table 1 shows an example of application information stored in the application information management table 331.

The application information includes a list of combinations of application IDs and application names. The application name indicates the name of the application specified by the application ID. The application name is displayed to the user, and for management, the application is uniquely identified by the application ID.

  Table 2 shows an example of application registration information stored in the registered application management table 332.

The application registration information includes a list of combinations of file ID, application ID, version, and URL. A version of an application indicated by an application ID is uniquely identified by a different file ID. In addition, the application file corresponding to the file ID is stored in the content server 20 at the location indicated by the URL corresponding to the file ID. The registration information of the application is input and updated when the person in charge registers the application from the sales company system 30.

  When updating an application, it may be necessary to implement a version update mechanism in the updated version of the application, such as when a setting value for operating the application changes during version update. Therefore, there is a combination that can be updated between versions before and after the update. For example, assume that the current version is version 1 and the latest version is version 3. At this time, before updating from version 1 to the latest version (version 3), it may be necessary to update to version 2 and then update to version 3 again. Such a combination of updatable versions is managed by application version management information. Table 3 shows an example of updatable application version management information stored in the application version management table 333.

The updateable application version management information includes a list of combinations of application IDs, update source versions, and updated versions. One combination indicates that the update from the update source version to the updated version is possible in the application ID. A combination of versions not registered in the application version management table 333 means that the distribution system 10 cannot update. The updatable version combination information is input and updated together with the application management information when the person in charge registers the application from the sales company system 30 and is maintained by being updated.

  Similar to the application, the distribution system 10 also manages the FW that can be distributed. Table 4 shows an example of FW management information registered in the registered firmware management table 334.

FW management information consists of a list of combinations of device model, version, and URL. The FW file corresponding to the combination of the device model and the version is stored in the storage location on the content server 20 indicated by the URL. The management information of the FW is input and updated when the person in charge registers the FW from the sales company system 30.

  In the FW, it may be necessary to implement a version update mechanism in the updated version of the FW, such as when the software configuration changes during a version update. Therefore, there is a combination that can be updated between versions before and after the update. For example, assume that the current version is version 1 and the latest version is version 3. At this time, before updating from version 1 to the latest version, it may be necessary to update to version 2 and then update to version 3 again. Such a combination of updatable versions is managed by FW version management information. Table 5 shows an example of updatable FW version management information stored in the firmware version management table 335.

The updateable FW version management information includes a list of combinations of device models, update source versions, and updated versions. The device model represents a group of devices to which the same FW can be applied. One combination indicates that the device model can be updated from the update source version to the updated version. A combination of versions not registered in the firmware version management table 335 means that it cannot be updated. This updatable version combination information is inputted and updated together with the management information of the FW when the person in charge registers the FW from the sales company system 30 and is maintained by being updated.

  In an application, an environment in which the version of the application operates, that is, a firmware version may be limited. For example, version 1 of application A is implemented to operate on firmware version 1, but version 2 of application A may not operate on version 2 of firmware. In such a case, it is necessary to update the firmware to version 2 before updating application A to version 2. Operable combinations of such application versions and FW versions are managed by version combination information. Table 6 shows an example of the version combination information stored in the version restriction management table 336.

The version combination information is a black list including a list of combinations of device models, FW versions, and file IDs. One combination indicates that the version of the application indicated by the file ID does not operate on the version of the FW indicated by the FW version in the device model. This version combination information is inputted and updated when it is found from the sales company system 30 that there is a dependency relationship between the firmware or application to be registered when the person in charge registers the FW and the application. .

  The distribution system 10 maintains and manages the state of each device to be distributed. One piece of information indicating the device status is the version information of the FW operating on each device. Table 7 shows an example of device management information stored in the device management table 337.

The device management information includes a list of combinations of device IDs, device models, and versions. The device ID is identification information for each device. The device model is a device model to which the device identified by the device ID belongs. The version indicates the version of the FW currently operating on the device. When communicating with the distribution system 10 in the sequence shown in FIG. 5, the device notifies the device ID of the device together. The distribution system 10 updates the device management table 337 in the process of 460 from the device ID and the version of FW obtained by the FW update notification 459. Note that the correspondence between the device ID and the device model is uniquely associated from the device ID to the device model based on management information (not shown).

  As another information indicating the device status, there is an application installed in each device and information on the status. Further, the distribution system 10 manages information on which version of the application and FW is updated at the next update timing. Table 8 shows an example of update planned version information of a device stored in the update planned version management table 338.

  The scheduled update version information includes a list of combinations of device ID, application ID, current VER, update VER, update time, and update FWVER. The current VER indicates the version of the application indicated by the application ID installed on the device indicated by the device ID. The combination of the device ID, the application ID, and the current VER indicates that the application indicated by the combination of the application ID and the version is installed in the device indicated by the device ID. The installed application information further holds the application to be updated next and the version information of FW. The update VER indicates the version of the application ID scheduled to be updated. The update FWVER indicates the version of the FW that is scheduled to be updated. “Updating” indicates whether the application version indicated in the update VER is updated before or after the FW update. When the update VER and the update FWVER are combined, the update FWVER indicates that the next FW version will be updated to the app version either before or after that. If there are no scheduled updates, these will be blank. This information is updated by the processing of the application status record 419 in FIG. 4 or the application status records 450 and 469 in FIG. In accordance with this information, the distribution system 10 returns FW and application information to be updated in response to an inquiry from the device.

  Table 9 shows an example of information returned from the distribution system 10 to the device 400 using the FW / application information 442 in FIG.

  Information responding to the device 400 comprises a list of combinations of content type, ID, and version. The content type is one of the previous application, the rear application, and FW. The previous application indicates an application to be updated before updating the FW. The rear application is an application that is updated after updating the FW. FW is firmware. When the content type is the previous application or the rear application, the ID indicates an application ID. When the content type is FW, the ID indicates a device model. The version indicates the version of each content. When the content type is the previous application or the rear application, the version indicates a version corresponding to the application ID. When the content type is FW, the version is the FW version corresponding to the device model.

  The information responding to the device is obtained by narrowing down records corresponding to the device ID of the device for which information is to be returned from the update scheduled version management table 338 and extracting the application ID, update VER, update time, and update FWVER information. When the update FWVER is not recorded in the record corresponding to the device ID in the update scheduled version management table 338, that is, when the version update of the FW is not scheduled, the information whose content type is FW is not included. Similarly, when no update VER of any application ID is recorded in the record corresponding to the device ID, information on the content type of the previous application and the subsequent application is not included.

  Also, if no app is installed on the device, there is no update planned version information, so only information with a content type of FW is generated when inquiring from the device. A method of creating information to be returned to the device will be described later with reference to FIG.

Update of Update Schedule Version Management Table (Table 8) by Distribution System Next, update process of update schedule version information of the distribution system will be described. FIG. 6 is a flowchart illustrating an example of processing (application status recording processing 450) when the application update notification 449 is received from the device 400 in the distribution system 10. FIG. 6A is a process corresponding to the application state recording process 419 in the sequence of FIG. 4 and the application state recording processes 450 and 469 in the sequence of FIG. That is, it is executed by the CPU 201.

  In response to the application state recording processing 419, 450 or the application state recording processing 469, the processing from step S1000 is started. Here, the device ID and the application IDs and versions of all applications installed in the device are received from the device.

The application IDs of all applications notified from the device 400 in steps S1001 to S1006 are processed in order. In step S1002, it is confirmed whether or not a record corresponding to the combination of the device ID notified from the device and the currently processed application ID exists in the update scheduled version management table 338. If it exists (Yes.), The process proceeds to step S1004. If it does not exist (No.), the process proceeds to step S1003. In step S1003, a record corresponding to the combination of device ID and application ID is added. In step S1004, the current VER of the record corresponding to the combination of the device ID notified from the device 400 and the currently processed application ID is updated with the version corresponding to the application ID notified from the device 400. In step S1005, the update VER and the update FWVER are cleared at the time of update. In step S1006, it is determined whether the processing up to step S1005 has been completed for all application IDs received from the device. If an application ID that has not been processed remains (No.), the process returns to step S1001 to perform processing for the remaining application ID. If the processing has been completed for all application IDs (Yes.), The process proceeds to step S1007 to start asynchronous batch processing. Asynchronous batch processing is processing shown in FIG. 6B that operates in parallel (or asynchronously) with FIG. When the process shown in FIG. 6B is activated, the process proceeds to step S1008 without waiting for the process to end. In step S1008, a response to the application update notification 449 or the like is returned to the device 400. This corresponds to the response 420 in the sequence of FIG. 4 and the responses 451 and 470 in the sequence of FIG. 5. FIG. 6B is activated in step S 1007 in FIG. 6A and processed by the batch processing unit 315. FIG. 11 is an example of a flowchart of batch processing for updating scheduled update version information specifying a single device ID.

In step S1100, the process starts with the device ID received from the device.
In step S1101, the device ID is designated and the update scheduled version information update process (FIG. 7) is called. When the update scheduled version information update of the device ID is completed, the batch processing is ended in step S1002. The information indicating the version of the software to be updated next is updated without delaying the confirmation of the necessity of the software update that is currently performed on the scheduled update version information.

Update Schedule Version Information Update Process Next, details of the update schedule version information update process will be described. FIG. 7 is a flowchart illustrating an example of the update scheduled version information update process. In the scheduled update version information update process, based on the information at the time of calling for the designated device ID, the version of the FW to be distributed at the next update timing, the application, and its version are determined in advance. FW and app will determine the version to be updated respectively. Depending on the information at that time, there may be distribution of only FW, distribution of only applications, distribution of both FW and applications, but if there are restrictions on the combination of FW and application versions at the time of update, the restrictions It is determined that the satisfied version is delivered.

A device ID is designated from the caller, and processing from step S1110 is started. In step S1111, the update FW version determination process (FIG. 8) is called. When calling, the target device ID is designated. In the update FW version determination process, information on the FW version to be updated next in the specified device ID is reflected in the update scheduled version management table 338.
The application IDs of all the applications installed in the device corresponding to the device ID specified in steps S1112 to S1114 are processed in order.
In step S1113, an update application version determination process (FIG. 9) is called. In the updated application version determination process, the application version information to be updated next in the specified device ID and the currently processed application ID is reflected in the scheduled update version management table 338 (Table 8).
In step S1114, it is determined whether the processing up to step S1113 has been completed for all application IDs. If an application ID for which processing has not been completed remains (No.), the process returns to step S1112 to perform processing for the remaining application ID. If the processing has been completed for all application IDs (Yes.), The process proceeds to step S1115, and the scheduled update version information update process is terminated.

● Update FW version judgment process (S1111)
FIG. 8 is a flowchart showing an example of the update FW version determination process in step S1111 of FIG. A device ID is designated from the caller, and processing from step S1200 is started. In step S1201, the registered firmware management table 334 (Table 4) is searched to obtain the latest firmware version using the device model corresponding to the designated device ID. In the present embodiment, it is assumed that the version is defined by a numerical value and is new in the ascending numerical order among the FW versions of the same device model. Therefore, the latest version is the one with the largest numerical value. This latest version is set as the first update candidate version. The device model can be specified from, for example, the device ID.
Next, in step S1202, the current version of the device corresponding to the device ID (that is, the current version of the firmware of the device) is acquired from the device management table 337 (Table 7), and the current update candidate version is Determine if it is newer than the current version. If the update candidate version is newer than the current version (Yes.), The process proceeds to step S1203. If it is not newer than the current version (No.), it is not necessary to update the FW version, and the process advances to step S1209. In step S1209, the update FWVER of all records matching the specified device ID in the update scheduled version management table 338 (Table 8) is made blank.

In step S1203, it is determined whether or not the current version of the device corresponding to the device ID can be updated to the update candidate version. For this, a combination of the device version corresponding to the device ID, the current version corresponding to the device ID, the update source, and the update candidate version after updating is searched from the firmware version management table 335 (Table 5). If the corresponding combination exists (Yes), the combination is an updatable combination, and the process advances to step S1204. If there is no such combination (No.), the process proceeds to step S1210.
In step S1210, the registered firmware management table 334 (Table 4) is searched to obtain a previous version from the current update candidate version, and the process from step S1202 is repeated with this as a new update candidate version.

  From step S1204 to step S1207, in the update scheduled version management table 338 (Table 8), operation confirmation determination processing is performed in order for the application IDs of all applications installed in the device corresponding to the specified device ID. Go. In step S1204, attention is sequentially paid to application IDs registered in the update scheduled version management table 338. The app ID that is currently focused on is called the focused app ID. The same applies to processing objects other than the application ID.

  In step S1205, the application ID of interest and its current VER are specified from the scheduled update version management table 338 (Table 8). Then, the registered application management table 332 (Table 2) is searched with the identified application ID of interest and its current VER, and the corresponding file ID is specified. It is searched whether the combination of the device model corresponding to the designated device ID, the current update candidate FW version, and the identified application file ID exists in the version restriction management table 336 (Table 6). Operation is not possible if a combination exists, and operation is possible if no combination exists. In step S1206, the process branches according to the search result in step S1205. If it is operable (Yes), the process proceeds to step S1207. If the operation is not possible (No.), the process proceeds to step S1210, the version immediately before the current update candidate version is obtained, and the process from step S1202 is repeated with this as a new update candidate version.

In step S1207, it is determined whether the processing up to step S1206 has been completed for all application IDs. If an application ID for which processing has not been completed remains (No.), the process returns to step S1204 to perform processing for the remaining application ID. If the processing has been completed for all application IDs (Yes.), The process proceeds to step S1208.
When the processing proceeds to step S1208, the update candidate version of the FW at that time is a version that can operate all the applications installed in the device and is newer than the current version. Therefore, the current update candidate version of FW is reflected in the update FWVER of all records that match the specified device ID in the update scheduled version management table 338 (Table 8).
In step S1211, the update FW version determination process ends, and the process returns to the caller.

  With the above procedure, a new updateable version of the firmware of the device 400 can be determined with the reception of an application update notification from the device 400 as a trigger. The determined version information can be transmitted to the device 400 in response to the next applicable FW information request 441, for example. In addition, since this process is executed asynchronously with the triggering process, it is possible to prevent a delay in the response to the device.

Update Application Version Determination Process FIG. 9 is a flowchart showing an example of the update application version determination process. The device ID and application ID are specified from the caller, and the processing from step S1300 is started. These are called a target device ID and a target application ID, respectively.
In step S1301, the registered application management table 332 (Table 2) is searched to obtain the latest version with the specified application ID. In the present embodiment, it is assumed that the application version is also defined by a numerical value as in the case of FW, and is new in the ascending order of the numerical value within the version of the same application ID. Therefore, the latest version is the one with the largest numerical value. This latest version is set as the first update candidate version.
In step S1302, the current VER of the application corresponding to the combination of the device ID and the application ID is acquired from the update scheduled version management table 338 (Table 8). Then, it is determined whether the current update candidate version is newer than the current VER installed in the device. If the update candidate version is newer than the current VER (Yes.), The process proceeds to step S1303. If it is not newer than the current VER (No.), there is no need to update the application version, and the process advances to step S1314.
The fact that it has come to step S1314 means that there is no version of the app that is operable and can be operated regardless of the version before and after the FW update. Therefore, in step S1314, the update VER of the record that matches the specified device ID and application ID in the update scheduled version management table 338 (Table 8) is made blank.

In step S1303, it is determined whether the current version of the device corresponding to the device ID can be updated to the update candidate version. For this, a combination is searched from the application version management table 333 (Table 3) with the designated application ID and the current VER as the update source and the version of the update candidate as updated. If updatable, that is, there is a combination (Yes), the process proceeds to step S1304. If updating is impossible, that is, if there is no combination (No.), the process proceeds to step S1311.
In step S1304, the combination of the designated device ID and application ID is searched from the scheduled update version management table 338 (Table 8), and it is determined whether or not an update FWVER exists. If there is an updated FWVER (Yes.), The process proceeds to step S1305, and if not (No.), the process proceeds to step S1309.
In step S1305, first, it is determined from the version restriction management table 336 (Table 6) whether the combination of the update FW version (update FWVER) and the update candidate version of the application is operable. Since the determination method is the same as that in step S1205 described above, a description thereof will be omitted. In step S1306, if operation is possible (Yes) according to the determination result, the process proceeds to step S1307. If the operation is impossible (No.), the process proceeds to step S1311.
In step S1311, the registered application management table 332 is searched to obtain a previous version from the current update candidate version, and the processing from step S1302 is repeated.

  In step S1307, it is determined from the version restriction management table 336 (Table 6) whether the combination of the current FW version acquired from the device management table 337 (Table 7) and the update candidate version of the application of interest is operable. If it is operable (Yes), the application can be updated before the FW version is updated, and the process advances from step S1308 to step S1312. If it is not possible to operate (No.), it is necessary to update the application after updating the version of the FW, and the process advances from step S1308 to step S1313.

  Step S1309 is determination processing when there is no updated FW version. Similar to step S1307, it is determined from the version restriction management table 336 (Table 6) whether the combination of the current FW version and the update candidate version of the application is operable. In the case of step S1309, since there is no FW update and operation is not possible (No.), the process proceeds from step S1310 to step S1311, the previous version is set as the update candidate version, and the processing from step S1302 is repeated. . When the operation is possible (Yes), only the application can be updated, and the process advances from step S1310 to step S1312. In the case of updating only an application that has no FW update, both pre-update and post-update are possible, but in this embodiment, the process is unified by pre-update.

  Having come to step S1312, it means that the update candidate version of the application can operate with the current FW version of the target device. Furthermore, the FW version that is scheduled to be updated is operable or there is no FW update, and the update candidate version of the application of interest is newer than the current version. Therefore, the current update candidate version of the application is reflected in the update VER of the record that matches the specified device ID and application ID in the update scheduled version management table 338 (Table 8). When the record is updated, “Previous” is set.

Having come to step S1313 means that the current update candidate version of the app cannot operate with the current FW version of the target device. However, the update candidate version of the application of interest can be operated after updating the version of the FW scheduled to be updated, and the update candidate version of the application of interest is newer than the current version. Therefore, the current update candidate version of the application is reflected in the update VER of the record that matches the specified device ID and application ID in the scheduled update version management table 338 (Table 8). Then, “after” is set when the record is updated.
In step S1315, the update application version determination process ends, and the process returns to the caller.

  With the above procedure, the updateable version of the app of the device 400 can be determined with the reception of the app update notification from the device 400 as a trigger. The determined updated version of the application is guaranteed to be operable with the current firmware or the updated firmware. In addition, since this process is executed asynchronously with the triggering process, it is possible to prevent a delay in the response to the device.

FW and App Automatic Update Processing FIG. 10 is a flowchart illustrating an example of automatic FW and app update processing in the distribution system 10. FIG. 10 shows the contents processed by the distribution control unit 317 for the response of the FW / application information 442 in response to the reception of the applicable FW information request 441 in the sequence of FIG.

In response to reception of the applicable FW information request 441, processing from step S1400 is started. In step S1401, the device receives the device ID and the version of the FW installed on the device. This device is the device of interest. Here, the received FW version of the target device is stored as DFWVER and the device ID as X in internal processing variables. This device is sometimes called device X below.
In step S1402, a record whose device ID is X is searched from the registered firmware management table 334 (Table 4), and its version is acquired. This is the FW version of the device of interest known by the distribution system 10. Then, it is determined whether the received DFWVER, which is the FW version of the device of interest, matches the FW version known by the distribution system 10. If they match (Yes.), The process proceeds to step S1403. If they are different (No.), the process proceeds to step S1404.
In step S1403, it is determined whether there is update schedule information for device X. That is, it is searched whether or not a record whose device ID is X is included in the scheduled update version management table 338 (Table 8). If it is included, it is determined whether the app is installed on the device X. For example, if an application ID is registered, it can be determined that the application is installed. When the application is installed, the distribution version of the FW (update FWVER) and the distribution version of the application (update VER) are determined together. If the app is not installed, only the FW distribution version (updated FWVER) is determined. If the DFWVER and the FW version known by the distribution system 10 match (S1402-YES) and the application is installed (S1403-Yes.), The update scheduled version information update process (FIG. 7) What is necessary is just to update with the determined FW and the version of the application (that is, the version of the FW and the application registered in the update scheduled version management table 338). Accordingly, the process proceeds to step S1413.

  If the application is not installed (No.), it is necessary to determine the version of the FW to be updated based on the firmware version DFWVER received from the device 400, and the process advances to step S1404. If the application is not installed and the FW version to be updated is determined, it is determined again in step S1408 whether the application is installed, and the process branches.

In step S1404, a record whose device ID is X is searched from the device management table 337 (Table 7) to specify a device model. Then, the latest version of the FW of the device model is obtained from the registered firmware management table 334 (Table 4). Here, the latest version obtained in the internal processing variable CURVER is stored. CURVER indicates the version of the current update candidate.
In step S1405, it is determined whether the firmware update candidate version CURVER is newer than the current version DFWVER. If it is new, the process proceeds to step S1405. If it is not new (No.), it should not be updated with the FW and application version determined in the update scheduled version information update process (FIG. 7), or there is no need to update, so the process proceeds to step S1410.
In step S1406, it is determined from the firmware version management table 335 (Table 5) whether or not the FW version can be updated from DFWVER to CURVER. If it can be updated (Yes), the process advances to step S1408. If it cannot be updated (No.), the process proceeds to step S1407, the previous version is obtained from the registered firmware management table 334 (Table 4), CURVER is updated, and the processing from step 1405 is repeated.

  In step S1408, it is determined with reference to the update scheduled version management table 338 (Table 8) whether or not there is update schedule information of the application and / or FW for the device X. When no app is installed on device X, the CURVER determined in the process so far indicates the version of the FW to be updated. If it is determined in step S1408 that there is update schedule information for device X (Yes), the process advances to step S1409. If there is no update schedule information for the device X (No.), that is, if no application is installed, the process proceeds to step S1425 to perform a process for responding only to the update information for the FW. That is, in step S1425, the current firmware update candidate version CURVER is added to the response 442. Then, a response including the current update candidate version of the firmware added in step S1426 is transmitted to the device 400.

In step S1409, the update FWVER recorded in the update planned version management table 338 (Table 8) in advance by the update planned version information update (FIG. 7) and the current firmware update candidate version CURVER are the same. to decide. If they are the same (Yes), it is determined that the update is possible after the update of the FW even if there is an update of the application, and the process proceeds to the next step S1412. If they are different (No.), the process proceeds to step S1410.
In step S1410, the version of the device X record in the device management table 337 (Table 7) is updated with the value of the firmware version DFWVER received from the device 400. In the case of the processing flow that does not pass step S1410, the FW version update of the device X is performed. Therefore, the device management information (Table 7) of the device X is updated at the timing of the FW state recording process 460 in FIG. . In step S1411, since there is no update information for both the FW and the application, the FW / application information 442 in FIG. 5 is returned to the device 400 without the update information.

On the other hand, in step S1412, the AFTER flag, which is a variable for internal processing, is set to ON (initial value is OFF). That is, the application update time is set after the firmware update. If this flag is set and the process proceeds to the subsequent step S 1416, the process proceeds with “at the time of update” as the value “after”. That is, it means that the update time of all applications in the update scheduled version management table 338 is regarded as “after”. Then, the process proceeds to step S1413.
In the processing from step S1413, information (Table 9) for responding to the device 400 is created from the information in the scheduled update version management table 338. In step S1413, the record of the device X is searched from the update scheduled version management table 338 (Table 8).
In step S1414, first, the first record among the corresponding records obtained as a search result is acquired and set as a target record.
In step S1415, it is determined whether there is an update VER record in the target record. That is, it is determined whether there is an updated version of the application of the target record. If yes (Yes.), The process advances to step S1416 to add update information of the target application to the response information. If not (No.), the process proceeds to step S1419 to proceed with the process.
In step S1416, it is determined whether to update the app in the information responding to the device. If the AFTER flag is set in step S1412, all the apps are determined to be “after” update here. Otherwise, it is determined as “before” or “after” according to the value of “at the time of update” of the target record in the update scheduled version information. If it is determined as “front”, the process proceeds to step S1417. If it is determined as “rear”, the process proceeds to step S1418.
In step S1417, a combination of “previous app” as the content type, the app ID value of the target record as the ID, and the update VER value of the target record as the version is added to the information responding to the device exemplified in Table 9.
In step S1418, a combination of “post-app” as the content type, the app ID value of the target record as the ID, and the update VER value of the target record as the version is added to the information responding to the device exemplified in Table 9.

In step S1419, it is determined whether the target record is the last record of the device. If it is the last record (Yes.), Since the addition of response information for all the applications has been completed so far, the process proceeds to step S1421, and the determination process of the response information of FW is performed. If it is not the last record (No.), the process proceeds to step S1420.
In step S1420, the next record is acquired from the search result, and it is set as a target record, and the processing from step S1415 is repeated.

In step S1421, it is determined whether there is a record of updated FWVER for the last record. That is, it is determined whether or not the device X has an updated version of FW. If yes (Yes.), The process advances to step S1422 to add FW update information to the response information to the device. If not (No.), the process proceeds to step S1424.
In step S1422, a combination consisting of “FW” as the content type, the value of the device model of X as the ID, and the value of the update FWVER of the target record as the version is added to the information responding to the device illustrated in Table 9.
In step S1423, with the response information to the device created so far, the update information of the FW and the application is returned to the device, and a response 442 is obtained. If there is no update information of the application in the repetition of the processing from step S1415 to S1420, there may be only FW update information here.
In step S1424, with the response information to the device created so far, only the application update information is returned to the device as a response 442.
In step S1425, a combination of “FW” as the content type, the value of the device model of X as the ID, and the value of CURVER as the version is added to the information responding to the device exemplified in Table 9.
In step S1426, with the response information to the device created so far, only the FW update information is returned to the device as a response 442.

  The procedure of FIG. 10 is summarized. If the firmware version declared by the device matches the firmware version of the device managed by the server, the update schedule is confirmed. The response 442 follows the registered contents of the update scheduled version management table 338.

  On the other hand, if the firmware version reported by the device does not match the firmware version of the device managed by the server or there is no update plan, the firmware update version is first determined. The update version is newer than the current version of the device and can be updated. At this time, all the applications to be updated are set to be updated after the firmware.

  Thereby, the firmware version and the application version to be updated can be determined. Further, when the updated version of the application is determined in the process of FIG. 6B, the version of the application can be notified to the device together.

● Processing at the time of FW registration update The scheduled update version information is also updated when a new FW is registered. If a new FW is registered, there is a possibility that it will be decided to distribute a new FW during periodic confirmation by automatic update. At this time, the operation-dependent information of the application needs to be reflected.

FIG. 11A is a flowchart illustrating an example of the FW registration update process performed by the batch processing unit 315 after FW registration.
When the registered firmware management table 334 (Table 4), the firmware version management table 335 (Table 5), and the version restriction management table 336 (Table 6) are updated by the FW registration, the processing from step S1120 starts. .

In step S1121, the target device model registered for FW is specified. Here, with a list of device IDs belonging to the target device model, all device IDs belonging to the target device model are processed in order from step S1122 to step S1124.
In step S1123, the scheduled update version information update process (FIG. 7, step S1110) is called with the device ID to be processed.
In step S1124, it is determined whether or not the processing in step S1123 has been completed for all device IDs belonging to the device model. If a device ID that has not been processed remains (No.), the process returns to step S1122, and the remaining device ID is processed. If the processing has been completed for all device IDs (Yes.), The process proceeds to step S1125, and the FW registration update process ends.

  With this procedure, when a new version of firmware is registered, the scheduled update version management table 338 can be updated accordingly.

● Scheduled Batch Processing Furthermore, the batch processing unit 315 also performs scheduled batch processing that starts at a regularly scheduled date and time. When only the application version is updated, the scheduled update version management table 338 is updated by this scheduled batch processing.
FIG. 11B is a flowchart illustrating an example of the scheduled batch process. For example, the process from step S1130 is started in the batch processing unit 315 by the scheduler 318 set to start the process every day at midnight.
From step S1131 to step S1133, all device IDs registered in the scheduled update version management table 338 (Table 8) are processed in order.
In step S1132, the scheduled update version information update process (step S1110 in FIG. 7) is called with the device ID to be processed.
In step S1133, it is determined whether the processing in step S1132 has been completed for all device IDs. If a device ID that has not been processed remains (No.), the process returns to step S1131, and the remaining device ID is processed. If the processing has been completed for all device IDs (Yes.), The process proceeds to step S1134, and the scheduled batch processing is terminated.

  If a new version of the application is registered in this procedure, the scheduled update version management table 338 can be updated accordingly. As shown in FIG. 11, the scheduled update version management table 338 can be triggered by a set predetermined time or a predetermined event such as firmware registration.

  As described above, in this embodiment, the sequence in the case of (periodic) automatic update distribution, in which it is desirable that the state is updated to the latest version that is unattended, has been described. However, the invention according to the present embodiment can also be applied as a mechanism for enabling easy update to an appropriate version even for manned persons.

  FIG. 12 is a sequence diagram illustrating an example of a flow when the device user updates the FW and the application to the latest version by the device user. Since the sequence of FIG. 12 basically follows the sequence of FIG. 5, only the differences from FIG. 5 will be described.

  The user 401 issues an update instruction 480 to the device 400 in order to update the software (FW and application) of the device 400 to the latest version of an appropriate combination. This means, for example, that there is a button such as “software update” on the operation panel of the device 400, and pressing this button causes a subsequent sequence to be visited. Thereafter, the software can be updated by the user by immediately executing the same exchange as the communication sequence between the device 400 and the distribution system 10 shown in FIG.

  As described above, in the distribution system, the latest application and FW can be distributed just by receiving the current FW version from the device at the time of automatic update. The distribution system specifies the version of the FW and application to be distributed to each device in advance asynchronously, and distributes the combination of the appropriate version of the application and FW without reducing the response speed of the server during distribution. I can do it. For the appropriate combination, if it is appropriate to update only the app version, including the current version of the device, only the app is distributed. If it is appropriate to update only the FW, only the FW is distributed.

  This makes it possible to update FW and multiple apps at the same time with limited realistic update timing even on devices such as MFP, and operational issues related to distribution schedules on devices such as MFP. Was reduced. It is also possible to automatically update only apps whose operation is guaranteed in combination with FW.

[Other Examples]
The present invention supplies a program that realizes one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program This process can be realized. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

10 distribution system, 20 content server, 30 sales company system, 400 devices

Claims (9)

A system comprising a plurality of devices and a distribution system,
The distribution system includes:
Management means for managing version information of firmware and applications installed in the device and version information scheduled to be updated of the firmware and applications for each device ID;
In response to receiving an update notification including the device ID of the device and the version information of the application installed on the device from the device, the version information of the application installed on the device managed by the management unit Updating means for updating the version information to be updated of the firmware and application managed by the management means;
Receiving means for receiving a firmware update confirmation request including a device ID of the device and version information of firmware installed in the device from the device;
Based on the version information of the firmware indicated by the information included in the confirmation request received by the reception unit, the version information scheduled to be updated of the firmware is specified, and further, the device ID included in the confirmation request is specified by the management unit. When the update schedule for the corresponding application has already been managed, based on the update schedule, specifying means for specifying version information of the update schedule for the application installed on the device;
Response means for transmitting the identified version information of the firmware update schedule and the version update information of the application to the device as a response to the confirmation request;
In the device, the firmware and application are updated according to the response, and an update notification including a device ID and version information of the updated application is transmitted to the distribution system according to the update of the application. . The system of claim 1, comprising:
The update means further performs the update when new version information of the firmware is registered in the distribution system. The system according to claim 1 or 2, wherein
The update means further performs the update by a predetermined trigger. The system according to claim 3, wherein
The system according to claim 1, wherein the predetermined trigger is that a predetermined time has been reached. The system according to any one of claims 1 to 4,
The response means further includes information indicating that the update of the application is performed after the update of the firmware when the version information of the update schedule of the application is combined with the version information of the firmware update schedule. A system characterized by inclusion in a response. A system according to any one of claims 1 to 5,
The update means is based on the version information of the firmware received from the device, is newer than the version indicated by the version information, can be updated from the version, and is installed in the device Among the versions that can be combined with the latest version, the latest version is used as version information that is scheduled to be updated by the firmware. The system according to any one of claims 1 to 6,
The update unit is newer than the version indicated by the version information installed in the device and updated from the version of the application installed in the device based on the device ID received from the device. Among the versions that are possible and can be combined with the version of the firmware that is installed in the device, the latest version is used as the version information that is scheduled to be updated for the new application. Feature system. The system of claim 7, comprising:
If the update means can be combined with the current version of the firmware installed in the device even if it cannot be combined with the version to be updated of the firmware installed in the device, the version is updated. A system characterized in that it is version information of a new update schedule of the application. A distribution method by a system including a plurality of devices and a distribution system,
The distribution system is
Managing version information of firmware and applications installed in the device and version information scheduled to update the firmware and applications for each device ID;
In response to receiving an update notification including the device ID of the device and the version information of the application installed in the device from the device, the version information of the application installed in the device is updated, and the firmware And update the version information of the application update schedule,
Receiving a firmware update confirmation request including the device ID of the device and the version information of the firmware installed in the device from the device;
Based on the version information of the firmware indicated by the information included in the received confirmation request, the version information to be updated of the firmware is specified, and the update schedule for the application corresponding to the device ID included in the confirmation request Is already managed, based on the update schedule, specify version information of the update schedule for the application installed on the device,
The identified firmware update version information and the application update version information are sent to the device as a response to the confirmation request,
The device is
The system updates the firmware and application according to the response, and transmits an update notification including a device ID and updated version information of the application to the distribution system according to the update of the application.

Images