(57)【要約】【課題】アプリに不具合を発生させるファームのアップデートを防止するとともに、ファームのアップデートに対応したアプリのリリースに応じファームをアップデート可能にすること。【解決手段】配信サーバ１１１は、ファームの定期アップデートのための通信で取得したネットワークデバイスの構成情報とアップデートに利用されるファームの情報に基づき、該ネットワークデバイスのファームをアップデートすべきか判定し(S1506)、アップデートすべきである場合、該ネットワークデバイスに該ファームを配信する(S1507)。アップデートすべきでない場合、定期アップデートのための通信に基づく該ネットワークデバイスに対するファームのアップデートを禁止する(S1508)。また、ファームのアップデートが禁止されているネットワークデバイスにアプリの新バージョンが適用された場合、該ネットワークデバイスに対するファームのアップデート禁止を解除する。【選択図】図１１
2017045302.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークデバイスに対するソフトウェアの配信を制御する配信システムであって、
ネットワークデバイスに対するファームウェアのアップデートの定期的な確認のために行われる通信を介して、該ネットワークデバイスから該ネットワークデバイスにインストールされているファームウェア及びアプリケーションの情報を含む構成情報を取得する取得手段と、
前記取得手段により前記ネットワークデバイスから取得された構成情報とアップデートに利用されるファームウェアの情報とに基づいて、該ネットワークデバイスのファームウェアをアップデートすべきか否かを判定する第１判定手段と、
前記第１判定手段によりアップデートすべきであると判定された場合には、前記ネットワークデバイスに対して前記ファームウェアによるアップデートのために、該ファームウェアの配信の制御を行う第１制御手段と、
前記第１判定手段によりアップデートすべきでないと判定された場合には、前記定期的な確認のために行われる通信に基づく前記ネットワークデバイスに対するファームウェアのアップデートを禁止する制御を行う第２制御手段と、
前記第２制御手段によりファームウェアのアップデートが禁止されている前記ネットワークデバイスにインストールされているアプリケーションの新たなバージョンのアプリケーションが、該ネットワークデバイスに対して適用された場合、前記第２制御手段による該ネットワークデバイスに対するファームウェアのアップデートの禁止を解除する解除手段と、
を有することを特徴とする配信システム。
【請求項２】
前記第２制御手段によりファームウェアのアップデートが禁止されている前記ネットワークデバイスにインストールされているアプリケーションの新たなバージョンのアプリケーションがリリースされたことに応じて、該ネットワークデバイスの構成情報と前記新たなバーションのアプリケーションの情報とに基づいて、該ネットワークデバイスに前記新たなバーションのアプリケーションを適用すべきか否かを判定する第２判定手段と、
前記第２判定手段により前記新たなバーションのアプリケーションを適用すべきであると判定された場合、前記ネットワークデバイスに該新たなバーションのアプリケーションを適用することを決定する決定手段と、を更に有し、
前記解除手段は、前記決定手段による決定に従い前記新たなバージョンのアプリケーションが前記ネットワークデバイスに対して適用された場合、前記第２制御手段による該ネットワークデバイスに対するファームウェアのアップデートの禁止を解除することを特徴とする請求項１に記載の配信システム。
【請求項３】
前記第２判定手段により前記新たなバーションのアプリケーションを適用すべきでないと判定された場合、前記新たなバーションのアプリケーションの適用と前記ネットワークデバイスにインストールされているファームウェアのアップデートの両方を行う同時アップデートを行うべきか否かを判定する第３判定手段と、を更に有し、
前記決定手段は、前記第３判定手段により前記同時アップデートを行うべきであると判定された場合、前記ネットワークデバイスに対して前記同時アップデートを行うことを決定し、
前記解除手段は、前記決定手段による決定に従い前記新たなバージョンのアプリケーションが前記ネットワークデバイスに対して適用された場合、前記第２制御手段による該ネットワークデバイスに対するファームウェアのアップデートの禁止を解除することを特徴とする請求項２に記載の配信システム。
【請求項４】
前記決定手段は、前記第３判定手段により前記同時アップデートを行うべきでないと判定された場合、前記ネットワークデバイスに対する前記新たなバーションのアプリケーションの適用を行わないことを決定する、ことを特徴とする請求項３に記載の配信システム。
【請求項５】
インストールすべきでないファームウェアのバージョン及びアプリケーションのバージョンの組み合わせ、又は、インストール可能なファームウェアのバージョン及びアプリケーションのバージョンの組み合わせを登録するための登録手段を有し、
前記第１判定手段は、前記登録手段に登録された組み合わせを用いて、前記判定を行うことを特徴とする請求項１乃至４のいずれか1項に記載の配信システム。
【請求項６】
インストールすべきでないファームウェアのバージョン及びアプリケーションのバージョンとの組み合わせ、又は、インストール可能なファームウェアのバージョン及びアプリケーションのバージョンとの組み合わせを登録するための登録手段を有し、
前記第１判定手段、前記第２判定手段および前記第３判定手段は、前記登録手段に登録された組み合わせを用いて、前記判定を行うことを特徴とする請求項３又は４に記載の配信システム。
【請求項７】
前記ファームウェアは、バージョンごとに優先度が設定されており、
前記第２制御手段は、前記優先度が所定の優先度以上のバージョンのファームウェアについて、前記第１判定手段によりアップデートすべきでないと判定された場合であっても、前記ネットワークデバイスに対して該ファームウェアによるアップデートのために、該ファームウェアの配信の制御を行うことを特徴とする請求項１乃至６のいずれか１項に記載の配信システム。
【請求項８】
前記第２制御手段によりファームウェアのアップデートが禁止された場合、及び、前記解除手段により前記第２制御手段によるファームウェアのアップデートの禁止が解除された場合の少なくともいずれかの場合に、その旨を所定の通知先に通知する通知手段を更に有することを特徴とする請求項１乃至７のいずれか１項に記載の配信システム。
【請求項９】
ネットワークデバイスに対するソフトウェアの配信を制御する配信システムの制御方法であって、
ネットワークデバイスに対するファームウェアのアップデートの定期的な確認のために行われる通信を介して、該ネットワークデバイスから該ネットワークデバイスにインストールされているファームウェア及びアプリケーションの情報を含む構成情報を取得する取得ステップと、
前記取得ステップで前記ネットワークデバイスから取得された構成情報とアップデートに利用されるファームウェアの情報とに基づいて、該ネットワークデバイスのファームウェアをアップデートすべきか否かを判定する判定ステップと、
前記判定ステップでアップデートすべきであると判定された場合には、前記ネットワークデバイスに対して前記ファームウェアによるアップデートのために、該ファームウェアの配信の制御を行う第１制御ステップと、
前記判定ステップでアップデートすべきでないと判定された場合には、前記定期的な確認のために行われる通信に基づく前記ネットワークデバイスに対するファームウェアのアップデートを禁止する制御を行う第２制御ステップと、
前記第２制御ステップでファームウェアのアップデートが禁止されている前記ネットワークデバイスにインストールされているアプリケーションの新たなバージョンのアプリケーションが、該ネットワークデバイスに対して適用された場合、前記第２制御ステップでの該ネットワークデバイスに対するファームウェアのアップデートの禁止を解除する解除ステップと、
を有することを特徴とする配信システムの制御方法。
【請求項１０】
コンピュータを、請求項１乃至８のいずれか１項に記載の手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置などのネットワークデバイスに対してソフトウェアを配信する技術に関する。
【背景技術】
【０００２】
従来、画像形成装置のファームウェアを含むソフトウェアのアップデートは、機能アップもしくは障害等の理由により更新する必要が生じた場合に行われていた。ここで、画像形成装置には、プリンタや複写機などが含まれる。また、以降、画像形成装置をはじめとする各種ネットワーク上の機器を、ネットワークデバイスと呼ぶ。
【０００３】
ソフトウェアのアップデート方法としては、インターネット経由で所定の配信サーバから配信を行うか、ＵＳＢ経由／イントラネット経由のアップデートツールを使用する。前述した配信サーバでネットワークデバイスのソフトウェアのアップデートを行う場合、配信サーバのＷｅｂ画面から配信対象のネットワークデバイスを指定し、配信日時を設定してインターネット経由で配信を行う。
【０００４】
配信サーバは、ネットワークデバイスに対してインターネットを利用してソフトウェアを配信している。また、配信サーバは、ソフトウェアを高速に配信するため、インターネットに接続されたストレージにソフトウェアを転送して、外部サーバから配信する機能も有する。
【０００５】
近年、ネットワークデバイスのファームウェア開発体制は複数機種の同時開発になり、機種に依存した共通モジュールを最小限にする目的の下に、ファームウェアのアーキテクチャの見直しが図られている。それに伴い、ミドルウェアの変更も検討され、アプリケーションについてはＪａｖａ（登録商標）のプラットフォームが変更される場合がある。
【０００６】
配信サーバはネットワークデバイスに対して、ファームウェアやアプリケーションを配信するが、アプリケーションのプラットフォームに関わるミドルウェアを配信する場合、注意が必要となる。ミドルウェアが更新されることで、ネットワークデバイス内のアプリケーションが不具合を受ける可能性がある。
【０００７】
特許文献１には、アプリケーション毎にミドルウェア選択情報を生成し、アプリケーション実行時にミドルウェア選択情報を参照して適したミドルウェアをロードすることにより、アプリの実行性能の向上を図ることが記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００８−５９４９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述のように、ネットワークデバイスのファームウェア開発体制が複数機種の同時開発になり、機種に依存した共通モジュールを最小限にする目的の下に、ファームウェアのアーキテクチャの見直しが図られている。それに伴い、ミドルウェアの変更も検討されており、アプリケーションについてはＪａｖａ（登録商標）のプラットフォームが変更される可能性が出てきた。しかし、配信サーバのファームウェアップデートによりアプリケーションのミドルウェアが変更されてしまうと、複数のアプリケーションで、不具合が発生する可能性があるといった問題があった。 
【００１０】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、アプリケーションに不具合を発生させるようなファームウェアのアップデートを防止するとともに、ファームウェアのアップデートに対応したアプリケーションのリリースに応じてファームウェアをアップデート可能にする仕組みを提供することである。
【課題を解決するための手段】
【００１１】
本発明は、ネットワークデバイスに対するソフトウェアの配信を制御する配信システムであって、ネットワークデバイスに対するファームウェアのアップデートのタイミングで、該ネットワークデバイスから該ネットワークデバイスにインストールされているファームウェア及びアプリケーションの情報を含む構成情報を取得する取得手段と、前記取得手段により前記ネットワークデバイスから取得された構成情報と前記アップデートするファームウェアの情報とに基づいて、該ネットワークデバイスのファームウェアをアップデートすべきか否かを判定する第１判定手段と、前記第１判定手段によりアップデートすべきであると判定された場合には、前記ネットワークデバイスに対して前記ファームウェアのアップデートを行い、アップデートすべきでないと判定された場合には、前記ネットワークデバイスに対する前記ファームウェアのアップデートを禁止する制御を行う制御手段と、前記制御手段により前記ファームウェアのアップデートが禁止されているネットワークデバイスにインストールされているアプリケーションの新たなバージョンが、該ネットワークデバイスに対して適用された場合、該ネットワークデバイスに対する前記ファームウェアのアップデートの禁止を解除する解除手段と、を有することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、アプリケーションに不具合を発生させるようなファームウェアのアップデートを防止するとともに、ファームウェアのアップデートに対応したアプリケーションのリリースに応じてファームウェアをアップデート可能にすることができる。
【図面の簡単な説明】
【００１３】
【図１】本実施例のネットワークシステムの構成を例示する図
【図２】本実施例のネットワークシステムを構成する装置のハードウェア構成図
【図３】本実施例のネットワークシステムの通信部分のソフトウェア構成図
【図４】本実施例のネットワークシステムのソフトウェア構成図
【図５】本実施例のネットワークシステムにおけるシーケンス図
【図６】定期アップデートの際にネットワークデバイスから通知される情報およびＮＧテーブル
【図７】ＮＧテーブルの登録画面
【図８】定期アップデート防止フラグ状態テーブルおよび優先度テーブル
【図９】優先度テーブル登録画面
【図１０】配信予約情報および定期アップデート適用ファームテーブル
【図１１】配信サーバの定期アップデートの判断処理を例示するフローチャート
【図１２】ライセンスサーバのアプリの新バージョンリリース処理を例示するフローチャート
【図１３】配信サーバのアプリ適用判断処理を例示するフローチャート
【図１４】配信サーバの優先度順にアプリ適用可否を確認する処理を例示するフローチャート
【図１５】配信サーバのメモリに保持される一時的な情報を例示する図
【図１６】監視センタホストのファーム／アプリ配信指示の処理を例示するフローチャート
【図１７】ネットワークデバイスのファーム／アプリのアップデート処理を例示するフローチャート
【図１８】配信サーバのファーム／アプリアップデート処理を例示するフローチャート
【図１９】優先度６のファームがリリースされた場合の配信サーバの処理を例示するフローチャート
【図２０】優先度７のファームがリリースされた場合の配信サーバの処理を例示するフローチャート
【発明を実施するための形態】
【００１４】
以下、本発明の発明を実施するための形態について図面を用いて説明する。
図１は、本発明の一実施例を示すネットワークシステムの構成を例示する図である。
図１では、複数のシステムが接続されている。なお、本発明は、図１と同等機能を達成できれば同一の構成でなくても実施可能である。
【００１５】
販売会社システム１０１には、ＰＣ１０２、１０３、１０４が含まれる。ＰＣ１０２、１０３、１０４は、パーソナルコンピュータ等の情報処理装置である。ＰＣ１０２、１０３、１０４は、監視センタホスト１１７、配信サーバ１１１が提供するＷｅｂサイトへアクセスして、ソフトウェアの配信予約、ネットワークデバイスのデータの閲覧、及びアプリケーション（以下、アプリ）の登録等を行う。ＰＣ１０２、１０３、１０４はＬＡＮ１０５で接続されている。
【００１６】
外部サーバ１０６には、ＰＣ１０７，ホスト１０８、データベース１０９が、ＬＡＮ１１０で接続されている。外部サーバ１０６は、配信サーバ１１１のソフトウェアを高速に配信するためサービスを持つ。
【００１７】
次に、配信サーバ１１１を説明する。
配信サーバ１１１は、ネットワークデバイスに対するソフトウェアの配信制御を行うサーバである。データベース１１２は、ネットワークデバイスに適用するためのソフトウェアを蓄積する記憶部としてのデータベースである。配信サーバ１１１とデータベース１１２はＬＡＮ１１３で接続されており、ＬＡＮ１１３はインターネット１２０に接続されている。なお、データベース１１２は、物理的に配信サーバ１１１内に存在してもよい。さらに、データベース１１２は、配信サーバ１１１からアクセス可能であれば、インターネット１２０を経由した別の場所に存在しても構わない。なお、ＬＡＮ１１３と、後述するＬＡＮ１１６、ＬＡＮ１１９は同一のＬＡＮとしてもよく、データベース１１２と、後述するデータベース１１５とデータベース１１８はデータを送受信してデータを共有しても構わない。配信サーバ１１１及びデータベース１１２は、ネットワークデバイスに対するソフトウェアの配信制御を行う配信システムを構成する。
【００１８】
配信サーバ１１１には、配信用のファームウェア（以下、ファーム）が登録され、販売会社システム１０１向けに公開処理される。公開処理されたファームは、販売会社システム１０１のＰＣ１０２、１０３、１０４及び、販売会社システムが管轄するネットワークデバイス１２３、１２４、１３０、１３１、１３４、１３５、１３６、１３７、１２８からダウンロードが可能となる。
【００１９】
次に、ライセンスサーバ１１４を説明する。
ライセンスサーバ１１４は、データベース１１５を持ち、ネットワークデバイスのソフトウェアに対してライセンスを発行したり、ソフトウェアを登録するサーバである。データベース１１５は、ライセンスのための情報や、アプリ情報などを蓄積する記憶部としてのデータベースである。ライセンスサーバ１１４とデータベース１１５はＬＡＮ１１６で接続されており、ＬＡＮ１１６はインターネット１２０に接続されている。なお、データベース１１５は、物理的にライセンスサーバ１１４内に存在してもよい。さらに、データベース１１５は、ライセンスサーバ１１４からアクセス可能であれば、インターネット１２０を経由した別の場所に存在しても構わない。
【００２０】
次に、監視センタホスト１１７を説明する。
監視センタホスト１１７は、データベース１１８を持つ、ネットワークデバイスの監視システムである。データベース１１８は、監視のための情報や、ネットワークデバイスの稼働状態などを蓄積する履歴記憶部としてのデータベースである。監視センタホスト１１７とデータベース１１８はＬＡＮ１１９で接続されており、ＬＡＮ１１９はインターネット１２０に接続されている。なお、データベース１１８は、物理的に監視センタホスト１１７内に存在してもよい。さらに、データベース１１８は、監視センタホスト１１７からアクセス可能であれば、インターネット１２０を経由した別の場所に存在しても構わない。
【００２１】
監視センタホスト１１７は、監視装置１２２、１３２、１３３やネットワークデバイス１２８から監視対象としてのネットワークデバイスの情報、稼働状態を示す情報を収集、蓄積、加工し、警告等を外部に提供する機能を有する。
【００２２】
本実施例のネットワークシステムは、配信サーバ１１１、ライセンスサーバ１１４、監視センタホスト１１７が連携して、画像形成装置などのネットワークデバイスに対してソフトウェアの配信を制御する連携システムである。
【００２３】
なお、配信サーバ１１１とデータベース１１２、ライセンスサーバ１１４とデータベース１１５、および監視センタホスト１１７とデータベース１１８等は、それぞれ単一の物理リソース（例えば１台のコンピュータ）で構築されていてもよいし、ぞれぞれ複数の物理リソース（例えば複数のコンピュータ）を単一の論理リソースに仮想化したものでもよい。
【００２４】
また、図１には、配信サーバ１１１とデータベース１１２、ライセンスサーバ１１４とデータベース１１５、および監視センタホスト１１７とデータベース１１８が１つずつしか示されていない。しかし、実際には、多くのネットワークデバイスおよび監視装置からの情報収集や、ライセンス管理や、ソフトウェア配信の負荷分散を行なうために、これらを複数のシステムに分散処理をさせるケースもある。
【００２５】
次に、顧客側のシステム構成について説明する。
顧客側のシステムは、顧客により構成が異なる。図１では、顧客システム１２１、１２６、１２９が示されている。
【００２６】
顧客システム１２１（Ａ社Ｘ事業所）においては、インターネット１２０に接続されたＬＡＮ１２５に接続されたネットワークデバイス１２３、１２４が、監視装置１２２により監視されている。監視装置１２２は、インターネット１２０経由で監視センタホスト１１７と通信している。
【００２７】
また、顧客システム１２９（Ａ社Ｙ事業所）においては、監視装置１３２、１３３によってＬＡＮ１３８上のネットワークデバイスが管理されている。監視装置１３２により、ネットワークデバイス１３０、１３１、１３４、１３５が、監視装置１３３によりネットワークデバイス１３６、１３７がそれぞれ管理されている。
【００２８】
また、顧客１２６システム（Ｂ社）においては、インターネット１２０に接続されたＬＡＮ１２７に接続されたネットワークデバイス１２８自身が、直接インターネット１２０経由で監視センタホスト１１７と通信している。ネットワークデバイス１２８は、監視装置１２２、１３２、１３３と同等の機能を有しており、自身の稼働情報を監視センタホスト１１７に送信している。また、ネットワークデバイス１２８は、配信サーバ１１１からダウンロードしたファームを適用するためのコントローラを持つ。同様に、ネットワークデバイス１２３、１２４、１３０、１３１、１３４、１３５、１３６、１３７も配信サーバ１１１からダウンロードされたファームを適用するためのコントローラを持つ。
【００２９】
図２（ａ）は、監視センタホスト１１７に適用可能なコンピュータのハードウェア構成を例示する図である。なお、配信サーバ１１１、ライセンスサーバ１１４、ホスト１０８、監視装置１２２、１３２、１３３、ＰＣ１０２、１０３、１０４、１０７のハードウェア構成も配信サーバ１１１と同様である。
【００３０】
図２（ａ）において、ＣＰＵ２０１は本装置上の各処理を司る。書換え不可能なＲＯＭ２０２は、後述する本装置の各処理に関わるプログラムやデータを記憶する。ＲＡＭ２０３は、本装置の各処理に関わる一時的なデータを電気的に記憶でき、かつ書き換え可能である。ＨＤＤ２０４は、本装置の各処理に関わるプログラムやデータ、および一時的なデータ、監視対象のネットワークデバイスに関する情報、およびネットワークデバイスから収集した情報などを記憶するハードディスクである。例えば、稼働情報などがＨＤＤ２０４に保存される。監視センタホスト１１７、ライセンスサーバ１１４、配信サーバ１１１の場合、後述する図３（ａ）、図４に示すソフトウェア構成を実現するプログラムをＨＤＤ２０４に記憶している。このプログラムは、ＲＡＭ２０３を一時保存領域として使用し、ＣＰＵ２０１によって呼び出され実行される。
【００３１】
操作部２０５は、本装置への指示入力を受け付けるキーボードやポインティングデバイス（例えばマウス）等である。表示部２０６は、本装置の動作状況や、本装置上で動作する各プログラムが出力する情報を表示する。Ｎｅｔｗｏｒｋ Ｉ／Ｆ２０８は、ネットワーク経由でＬＡＮおよびインターネット１２０に接続し、外部と情報交換を行う。外部機器Ｉ／Ｆ２０７は外部記憶機器等を接続する。２０１〜２０８に示す要素がシステムバス２０９により結び付き、データをやりとりしている。
【００３２】
図２（ｂ）は、ネットワークデバイス１２３、１２４、１２８、１３０、１３１、１３４、１３５、１３６、１３７におけるハードウェア構成を例示する図である。
ネットワークデバイスとしては、具体的には、プリンタ及びファクシミリ機能が統合的に設けられた複合機（ＭＦＰ；Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）、ＰＣなどからデータを受信し印刷するプリンタ（電子写真方式、インクジェット方式及びその他のプリント方式を含む）や、スキャナや、ファクシミリなどが挙げられる。本図では、ネットワークデバイスの一例として複合機の構成を示している。
【００３３】
イメージリーダ３０２は、原稿給送部３０１で原稿を読み込む。画像形成部３０３は、イメージリーダ３０２で読み込んだ原稿やＮｏｔｗｏｒｋ Ｉ／Ｆ３０５からネットワーク経由で受信したデータを印刷画像に変換・印刷出力する。排紙部３０４は、印刷出力した紙を排出し、ソートやステイプルといった処理を施す。Ｎｅｔｗｏｒｋ Ｉ／Ｆ３０５は、ネットワーク経由でＬＡＮおよびインターネット１２０に接続し、外部と情報交換を行う。
【００３４】
ＣＰＵ３０６は、本装置上の各処理を司る。ネットワークデバイスの動作状態を監視し、障害等の特定のイベントが発生した場合には、その状態を示す状態情報を、あらかじめ定めた宛先へと送信する。宛先は、例えば、監視センタホスト１１７や監視装置などである。書換え不可能なＲＯＭ３０７は、本装置の各処理に関わるプログラムやデータを記憶する。ＲＡＭ３０８は、本装置の各処理に関わる一時的なデータを電気的に記憶でき、かつ書き換え可能である。ＨＤＤ３０９は、本装置の各処理に関わるプログラムやデータ、および一時的なデータ、本装置へ送信されてきたユーザデータなどを記憶する。ネットワークデバイスは、後述する図３（ｂ）、図４に示すソフトウェア構成を実現するプログラムをＨＤＤ３０９に記憶している。このプログラムは、ＲＡＭ３０８を一時保存領域として使用し、ＣＰＵ３０６によって呼び出され実行される。
【００３５】
操作部３１０は、本装置への指示入力を受け付ける。表示部３１１は、本装置の動作状況および操作部３１０に対する操作に関わる情報を表示する。３０１〜３１１に示す要素が、システムバス３１２により結び付き、データをやりとりしている。
なお、ネットワークデバイス自身が監視のための情報を送信する機能を持つネットワークデバイス１２８では、ＲＯＭ３０７或いはＨＤＤ３０９内に、監視データ送出処理に係るプログラムやデータを保持している。
【００３６】
図３（ａ）は、監視センタホスト１１７、配信サーバ１１１、ライセンスサーバ１１４における通信部分のソフトウェア構成を例示する図である。なお、図３（ａ）に示す各部は、監視センタホスト１１７、配信サーバ１１１のそれぞれのＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。
【００３７】
ＳＯＡＰ通信部４０１は、監視装置１２２、１３２、１３３またはネットワークデバイス１２８よりＮｅｔｗｏｒｋ Ｉ／Ｆ２０８を介して受信したＳＯＡＰデータをＳＯＡＰメッセージ解析部４０２に渡す。また、ＳＯＡＰ通信部４０１は、ＳＯＡＰメッセージ作成部４０３により作成されたＳＯＡＰデータを、Ｎｅｔｗｏｒｋ Ｉ／Ｆ２０８を介して監視装置１２２、１３２、１３３またはネットワークデバイス１２８に送信する。
【００３８】
収集情報処理部４０４では、監視装置１２２、１３２、１３３またはネットワークデバイス１２８から受信した情報をそのまま、または加工し、データベースアクセス部４０６を介してデータベース１１２、あるいはデータベース１１５に格納する。
【００３９】
監視制御部４０５は、監視センタホスト１１７においては、監視装置１２２、１３２、１３３またはネットワークデバイス１２８のスケジュール管理などの制御を行なう。また、監視制御部４０５は、配信サーバ１１１においては、監視装置１２２、１３２、１３３またはネットワークデバイス１２８のポーリング処理などの制御を行う。
【００４０】
図３（ｂ）は、監視装置１２２、１３２、１３３またはネットワークデバイス１２８における通信部分のソフトウェア構成を例示する図である。なお、図３（ｂ）に示す各部は、監視装置の場合、監視装置のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。また、ネットワークデバイスの場合、ネットワークデバイスのＣＰＵ３０６がＲＯＭ３０７又はＨＤＤ３０９に格納されたプログラムを読み出して実行することにより実現されるものである。
【００４１】
ＳＯＡＰ通信部５０１は、監視センタホスト１１７もしくは、配信サーバ１１１によりＮｅｔｗｏｒｋ Ｉ／Ｆ２０８を介して受信したＳＯＡＰデータを、ＳＯＡＰメッセージ解析部５０３に渡す。また、ＳＯＡＰ通信部５０１は、ＳＯＡＰメッセージ作成部５０２により作成したＳＯＡＰデータをＮｅｔｗｏｒｋ Ｉ／Ｆ２０８を介して監視センタホスト１１７、配信サーバ１１１に送信する。
【００４２】
監視制御部５０４は、情報蓄積部に保持する監視対象のネットワークデバイス情報の更新や、ネットワークデバイス１２３、１２４の情報取得を行なう。デバイス情報処理部５０５は、ネットワークデバイスの稼働情報を、情報蓄積部５０６に蓄積する。情報蓄積部５０６に蓄積したデータは、デバイス情報処理部５０５を介して、そのままＳＯＡＰメッセージ作成部５０２に渡され、監視センタホスト１１７へ送信される。
【００４３】
なお、図示しないが、監視センタホスト１１７、ライセンスサーバ１１４、配信サーバ１１１或いは、監視装置１２２、１３２、１３３或いは、各ネットワークデバイスは、本発明に係る処理プログラムを実行する際、監視センタホスト１１７、ライセンスサーバ１１４、配信サーバ１１１或いは、監視装置１２２、１３２、１３３ではＲＡＭ２０３上に、各ネットワークデバイスではＲＡＭ３０８上にプログラムがロードされる。例えば、基本Ｉ／Ｏプログラム、システム・プログラム、本実施例の処理プログラムを初めとする各種処理プログラムがＲＡＭ上にロードされ、関連データを格納するエリアや、プログラムのワークエリア等も確保される。基本Ｉ／Ｏプログラムは、本装置上の入出力を司る。システム・プログラムは、各処理プログラムに動作環境を提供する。
【００４４】
以下の説明では、ネットワークデバイスについては、ネットワークデバイス１２８を例にして説明するが、ネットワークデバイス１２３、１２４、１３０、１３１、１３４、１３５、１３６、１３７であっても同様である。ただし、ネットワークデバイス１２３、１２４、１３０、１３１、１３４、１３５、１３６、１３７は、監視センタホスト１１７との通信を、監視装置１２２、１３２、１３３を介して行うものとする。なお、ネットワークデバイス１２３、１２４、１３０、１３１、１３４、１３５、１３６、１３７と配信サーバ１１１との通信は、直接行う構成でも、監視装置１２２、１３２、１３３を介して行う構成でもよい。
【００４５】
図４は、本実施例のネットワークシステムのソフトウェア構成を例示する図である。
まず、ネットワークデバイス１２８について説明する。
７０２〜７０７は、コントローラ７０１に含まれるソフトウェアの構成を表す。ネットワークデバイス１２８は、コントローラ７０１とコントローラ７０１に制御されるエンジン７０８から構成される。コントローラ７０１は、ネットワークデバイス１２８のＣＰＵ３０６、ＲＯＭ３０７、ＲＡＭ３０８、ＨＤＤ３０９、Ｎｅｔｗｏｒｋ Ｉ／Ｆ３０５等で構成される。すなわち、７０２〜７０７は、ネットワークデバイス１２８のＣＰＵ３０６がＲＯＭ３０７又はＨＤＤ３０９に格納されたプログラムを読み出して実行することにより実現されるものである。
【００４６】
７０２は、通信Ｉ／Ｆ部を示している。通信Ｉ／Ｆ部７０２は、コントローラ７０１と配信サーバ１１１、外部サーバ１０６との通信を司る。７０３は、コントローラ７０１の通信データ制御部を示している。通信データ制御部７０３は、通信Ｉ／Ｆ部７０２から受信した通信データを制御する。
【００４７】
７０４は、ソフトウェア管理部を示している。ソフトウェア管理部７０４は、配信サーバ１１１から受信したＵＲＬ情報を元に、外部サーバ１０６からソフトウェアを受信し、エンジン制御部７０５や、アクセサリ制御部７０６にインストールする役割を持つ。７０７は、データ記憶部を示す。データ記憶部７０７は、コントローラ７０１内のソフトウェアデータの記憶や、一時記憶領域として使用する。
【００４８】
次に、ライセンスサーバ１１４について説明する。
７０９〜７１４は、ライセンスサーバ１１４に含まれるソフトウェアの構成を表す。即ち、７０９〜７１４は、ライセンスサーバ１１４のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。
【００４９】
７０９は、ライセンスサーバ１１４の通信Ｉ／Ｆを示す。通信Ｉ／Ｆ部７０９は、ネットワークデバイスのコントローラ７０１とライセンスサーバ１１４との通信を司る。７１０は、ライセンスサーバ１１４の通信データ制御部を示している。通信データ制御部７１０は、通信Ｉ／Ｆ部７０９から受信した通信データを制御する。
【００５０】
７１１は、データ制御部を示している。データ制御部７１１は、ライセンスサーバ１１４内のデータの制御を司る。７１２は、アプリ登録部を示している。アプリ登録部７１２は、アプリの情報をデータ記憶部７１４に登録する。７１３は、アプリ検索部を示している。アプリ検索部７１３は、アプリの検索をデータ記憶部７１４より行う。７１４は、データ記憶部を示している。データ記憶部７１４は、ライセンスサーバ１１４内にアプリ情報を記憶する。
【００５１】
次に、監視センタホスト１１７について説明する。
７１５〜７２０は、監視センタホスト１１７に含まれるソフトウェアの構成を表す。即ち、７１５〜７２０は、監視センタホスト１１７のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。
【００５２】
７１５は、監視センタホスト１１７の通信Ｉ／Ｆを示す。通信Ｉ／Ｆ部７１５は、ネットワークデバイスのコントローラと監視センタホスト１１７との通信を司る。７１６は、監視センタホスト１１７の通信データ制御部を示している。通信データ制御部７１６は、通信Ｉ／Ｆ部７１５から受信した通信データを制御する。
【００５３】
７１７は、データ制御部を示している。データ制御部は監視センタホスト１１７内のデータの制御を司る。７１８では、デバイスデータ登録部を示している。デバイスデータ登録部７１８は、ネットワークデバイスの情報をデータ記憶部７２０に登録する。７１９では、デバイスデータ検索部を示している。デバイスデータ検索部は、ネットワークデバイスのデータ検索をデータ記憶部７２０より行う。７２０では、データ記憶部を示している。データ記憶部７２０は、監視センタホスト１１７内にネットワークデバイスのデータ情報を記憶するデータベース１１８に記憶される。
【００５４】
次に、配信サーバ１１１について説明する。
７２１〜７２６は、配信サーバ１１１に含まれるソフトウェアの構成を表す。即ち、７２１〜７２６は、配信サーバ１１１のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。
【００５５】
７２１は、配信サーバ１１１の通信Ｉ／Ｆを示す。通信Ｉ／Ｆ部７２１は、ネットワークデバイスのコントローラと配信サーバ１１１との通信を司る。７２２では、配信サーバ１１１の通信データ制御部を示している。通信データ制御部７２２は、通信Ｉ／Ｆ部７２１から受信した通信データを制御する。
【００５６】
７２３では、データ制御部を示している。データ制御部７２３は、配信サーバ１１１内のデータの制御を司る。７２４では、ファームデータ登録部を示している。ファームデータ登録部７２４は、ソフトウェアの情報をデータ記憶部７２６に登録する。７２５では、ファームデータ検索部を示している。ファームデータ検索部は、ソフトウェアの検索をデータ記憶部７２６より行う。７２６では、データ記憶部を示している。データ記憶部７２６は、配信サーバ１１１内に配信用のファームデータの情報を記憶するデータベース１１２のデータが記憶される。
【００５７】
次に、外部サーバ１０６について説明する。
７２７〜７３０は、外部サーバ１０６に含まれるソフトウェアの構成を表す。即ち、７２１〜７２６は、外部サーバ１０６のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。
【００５８】
前述したように、外部サーバ１０６は、配信サーバ１１１のソフトウェアを高速に配信するためサービスを持ち、配信サーバ１１１より定期的にソフトウェアデータが転送されている。
【００５９】
７２７は、データ受信部を示す。データ受信部７２７は、配信サーバ１１１により転送されるソフトウェアデータを受信する。７２８は、配信部を示す。配信部７２８は、データ記憶部７３０に登録されているデータをコントローラ７０１に高速に配信する。７２９は、データ管理部を示す。データ管理部７２９は、データ受信部７２７から受信したデータをデータ記憶部７３０に記憶させる。また、データ管理部７２９は、配信部７２８に配信用のデータを供給する。７３０は、データ記憶部を示す。
【００６０】
図５は、本実施例のネットワークシステムにおけるシーケンスを例示する図である。
本シーケンスは、配信サーバ１１１がネットワークデバイス１２８からファームの定期アップデートの処理方法を判断する処理と、その後、ライセンスサーバ１１４にアプリの新バージョンがリリースされた場合の適用処理について説明する。なお、図中の８００に示すような記号は、時間の区切りを示す。この記号がついている箇所は連続的な処理ではなく、各々の通知があるまで待機することを示す。
【００６１】
なお、図５中のネットワークデバイス１２８の処理は、ネットワークデバイス１２８のＣＰＵ３０６がＲＯＭ３０７又はＨＤＤ３０９に格納されたプログラムを読み出して実行することにより実現される。また、配信サーバ１１１の処理は、配信サーバ１１１のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。また、ライセンスサーバ１１４の処理は、ライセンスサーバ１１４のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。また、監視センタホスト１１７の処理は、監視センタホスト１１７のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。
【００６２】
Ｓ８０１において、ネットワークデバイス１２８は、ファームの定期アップデートのタイミングで、自身のファームとアプリの構成情報を配信サーバ１１１に通知する。なお、定期アップデートとは、ネットワークデバイスが配信サーバ１１１に対して自身の構成情報を定期的に通知することで、一定期間毎にファームのアップデート版などのリリースを確認し、新しいファームがリリースされている場合に本発明の更新処理を実施するアップデート方法を指す。
【００６３】
Ｓ８１２において、配信サーバ１１１は、ネットワークデバイス１２８から受信したファーム情報・アプリ情報と、後述する図６（ｂ）に示すようなＮＧテーブル１００１から、定期アップデートを実施してよいか否かを判断する。そして、定期アップデートを実施しても問題ない（アップデートすべき）と判断した場合、配信サーバ１１１は、ファームをネットワークデバイス１２８に配信する（Ｓ８０２）。一方、定期アップデートを実施すると問題がある（アップデートすべきでない）と判断した場合、図５には示していないが、配信サーバ１１１は、以後の定期アップデートを防止する。
【００６４】
Ｓ８０３において、ライセンスサーバ１１４は、ＮＧテーブル１００１に関連するアプリの新バージョンがリリースされたことを配信サーバ１１１に通知する。
Ｓ８１３において、配信サーバ１１１は、上記Ｓ８０３で通知されたアプリの新バージョン情報を基に、該アプリの新バージョンを配信可能（適用可能）か否かを判断する。そして、配信可能（適用可能）と判断した場合、配信サーバ１１１は、監視センタホスト１１７に配信指示通知を行う（Ｓ８０４）。
【００６５】
Ｓ８０５において、ネットワークデバイス１２８は、ポーリング通信により監視センタホスト１１７に配信指示情報を要求する。
Ｓ８０６において、監視センタホスト１１７は、配信指示情報をポーリング通信のレスポンス情報として返す。
【００６６】
上記配信指示情報の返信に応じて、ネットワークデバイス１２８は、Ｓ８０７において、配信サーバ１１１に配信予約情報を要求する。配信予約情報は、図１０（ａ）に示すように、配信する日時情報を指す。
Ｓ８０８において、配信サーバ１１１は、ネットワークデバイス１２８に配信予約情報を通知する。
【００６７】
Ｓ８０９において、ネットワークデバイス１２８は、配信予約日時になると、配信要求通知を配信サーバ１１１に対して通知する。
Ｓ８１０において、配信サーバ１１１は、ネットワークデバイス１２８に要求されたアプリ及び、ファームを配信する。
Ｓ８１１において、ネットワークデバイス１２８は配信サーバ１１１に対してアップデート完了通知を行う。
【００６８】
図６（ａ）は、定期アップデートの際にネットワークデバイスから通知される情報９０１を例示する図である。
図６（ａ）において、９０２は、ネットワークデバイスを一意に識別する番号であるネットワークデバイスのシリアル番号（シリアルＮｏ．）を示す。９０３はアプリ名で、ネットワークデバイスにインストールされているアプリの名称を示す。９０４はアプリバージョンで、ネットワークデバイスにインストールされているアプリのバージョンを示す。９０５はファームバージョンで、ネットワークデバイスにインストールされているファームのバージョンを示す。
【００６９】
図６（ｂ）は、配信サーバ１１１が保持するファームとアプリもしくは、アプリ間のＮＧ構成を表すＮＧテーブルを例示する図である。
ＮＧテーブル１００１は、管理者等により、後述する図７に示す配信サーバ１１１の画面を使用して、アプリとファームの組み合わせによる不具合が判明したタイミングで作成される。
【００７０】
ＮＧテーブル１００１において、１００２は、ファームとアプリ間のＮＧパターンＩＤを示す。１００３はファームバージョンで、ネットワークデバイスのファームのバージョンを示す。１００４は、ファームバージョン１００３において不具合が判明しているアプリ名称とバージョンを示す。
【００７１】
即ち、ＮＧテーブル１００１は、インストールすべきでない（共存すべきでない）ファームのバージョンとアプリのバージョンとの組み合わせが登録されたものである。なお、ここでは、インストールすべきでない（共存すべきでない）ファームのバージョンとアプリのバージョンとの組み合わせをＮＧテーブル１００１（即ちブラックリスト）として登録しているが、インストール可能な（共存可能な）ファームのバージョンとアプリのバージョンとの組み合わせをＯＫテーブル（即ちホワイトリスト）として登録するように構成してもよい。
【００７２】
ＮＧテーブル１００５は、管理者等により、後述する図７に示す配信サーバ１１１の画面を使用して、アプリ間の組み合わせによる不具合が判明したタイミングで作成される。
【００７３】
ＮＧテーブル１００５において、１００６は、アプリ間のＮＧパターンＩＤを示す。１００７，１００８は、アプリ間の組み合わせによる不具合が判明している第一のアプリと第二のアプリの名称とバージョンを示す。１００７には、第一のアプリ名称とバージョンを示す。１００８には、第二のアプリ名称とバージョンを示す。なお、本実施例では２つのアプリの依存関係で不具合を判断する例を示しているが、３以上の複数のアプリの依存関係で不具合を判断するように構成してもよい。
【００７４】
即ち、ＮＧテーブル１００５は、インストールすべきでない（共存すべきでない）アプリ同士のバージョンの組み合わせが登録されたものである。なお、ここでは、インストールすべきでない（共存すべきでない）アプリ同士のバージョンの組み合わせをＮＧテーブル１００５（即ちブラックリスト）として登録しているが、インストール可能な（共存可能な）アプリ同士のバージョンの組み合わせをＯＫテーブル（即ちホワイトリスト）として登録するように構成してもよい。
【００７５】
図７は、配信サーバ１１１で保持するＮＧテーブルの登録画面２２０１を例示する図である。
登録画面２２０１は、例えばＰＣ１０２、１０３、１０４から配信サーバ１１１が提供するＷｅｂサイトへアクセスすることにより、ＰＣ１０２、１０３、１０４の表示部２０６に表示される。
【００７６】
２２０２は、ＮＧテーブルを作成するための情報であるファームバージョンを入力するための入力欄である。２２０３は、ＮＧテーブルを作成するための情報であるアプリ名を入力するための入力欄である。２２０４は、ＮＧテーブルを作成するための情報であるアプリバージョンを入力するための入力欄である。
２２０５は登録ボタンを示す。２２０６はキャンセルボタンを示す。
【００７７】
なお、２２０３と２２０４は、複数のアプリを入力可能である。複数のアプリが入力された場合には、２２０２は非活性になり、画面２２０１は、ＮＧテーブル１００５作成用の画面として機能する。一方、２１０２で一つのファームバージョンと、２１０３、２１０４で一つのアプリの情報が入力された場合には、画面２２０１は、ＮＧテーブル１００１作成用の画面として機能する。
【００７８】
図８（ａ）は、定期アップデート防止フラグ状態テーブル１１０１を例示する図である。
定期アップデート防止フラグ状態テーブル１１０１は、図５のＳ８１２で定期アップデートの適用可否判断をした際に、配信サーバ１１１において作成・更新される。
定期アップデート防止フラグ状態テーブル１１０１において、１１０２は、ネットワークデバイスを一意に識別する番号であるネットワークデバイスのシリアル番号（シリアルＮｏ．）を示す。１１０３は、定期アップデート防止フラグの状態（ＯＮ／ＯＦＦ）を示す。
【００７９】
図８（ｂ）は、アプリの優先度テーブル１２０１とファームの優先度テーブル１２０２を例示する図である。
アプリの優先度テーブル１２０１は、管理者等により、図９に示す配信サーバ１１１の優先度テーブル作成画面にて作成される。作成タイミングとしては、ライセンスサーバ１１４にアプリの新バージョンを登録する際に作成される。なお、優先度は、数値が大きい方がより優先度が高いものとする。
【００８０】
ファームの優先度テーブル１２０２は、管理者等により、図９の配信サーバ１１１の優先度テーブル作成画面にて作成される。作成タイミングとしては、配信サーバ１１１にファームを登録する際に作成される。なお、優先度は、数値が大きい方がより優先度が高いものとする。
【００８１】
図９は、配信サーバ１１１で保持する優先度テーブルの登録画面２３０１を例示する図である。
登録画面２３０１は、例えばＰＣ１０２、１０３、１０４から配信サーバ１１１が提供するＷｅｂサイトへアクセスすることにより、ＰＣ１０２、１０３、１０４の表示部２０６に表示される。
【００８２】
２３０２は、優先度テーブルを作成するための情報であるファームバージョンを入力するための入力欄である。２３０３は、優先度テーブルを作成するための情報であるアプリ名を入力するための入力欄である。２３０４は、優先度を入力するための入力欄である。２３０５は登録ボタンを示す。２３０６はキャンセルボタンを示す。
【００８３】
なお、２３０２のファームバージョンと、２３０３のアプリ名は排他制御しており、どちらか一方を入力すると、もう一方は非活性状態となる。
２３０２にファームバージョンが入力された場合には、２３０３は非活性になり、画面２３０１は、優先度テーブル１２０２作成用の画面として機能する。一方、２３０３にアプリ名が入力された場合には、２３０２は非活性になり、画面２３０１は、優先度テーブル１２０１作成用の画面として機能する。
【００８４】
図１０（ａ）は、配信サーバ１１１が保持する配信予約情報１３０１を例示する図である。
配信予約情報１３０１は、配信サーバ１１１で定期アップデートのスケジュールを設定する際、もしくは後述する同時アップデート（ファームのアップデートとアプリの新バージョンの適用の両方を行う）を行う際に作成される。
【００８５】
配信予約情報１３０１において、１３０２は、ネットワークデバイスを一意に識別する番号であるネットワークデバイスのシリアル番号（シリアルＮｏ．）を示す。１３０３は、１３０２で指定されているネットワークデバイスに対する定期アップデートスケジュールを示す。１３０４は、１３０２で指定されているネットワークデバイスに対する配信予約情報を示す。
【００８６】
図１０（ｂ）は、定期アップデート適用ファームテーブル１４０１を例示する図である。
定期アップデート適用ファームテーブル１４０１は、最新バージョンのファームがリリースされたタイミングで作成され、定期アップデートで対象となるファームバージョンが記載される。
【００８７】
図１１は、配信サーバ１１１の定期アップデートの判断処理を例示するフローチャートである。本フローは、ネットワークデバイス１２８から定期アップデート要求を受けて、配信サーバ１１１が定期アップデートの処理方法を判断する処理について説明する。本処理は、図５のＳ８１２のタイミングで実行される処理に対応する。なお、図１１、後述する図１３、図１４、図１８〜図２０の処理は、配信サーバ１１１のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。
【００８８】
Ｓ１５０１において、配信サーバ１１１は、ネットワークデバイスから定期アップデート要求を受信すると、Ｓ１５０２に処理を進める。
Ｓ１５０２において、配信サーバ１１１は、上記Ｓ１５０１で定期アップデート要求を受信したネットワークデバイス（以下、対象のネットワークデバイス）からネットワークデバイス自身のファーム構成とアプリ構成の情報を受信すると、Ｓ１５０３に処理を進める。図６（ａ）の９０１に示すように、ネットワークデバイス１２８は、配信サーバ１１１に、自分の管理するネットワークデバイスのシリアル番号９０２と、アプリ名９０３と、アプリバージョン９０４と、ファームバージョン９０５を送信する。
【００８９】
Ｓ１５０３において、配信サーバ１１１は、図８（ａ）の定期アップデート防止フラグ状態テーブル１１０１を参照して、対象のネットワークデバイスの定期アップデート防止フラグが「ＯＦＦ」になっているかを確認する。そして、対象のネットワークデバイスの定期アップデート防止フラグが「ＯＦＦ」になっていない（「ＯＮ」になっている）と判定した場合（Ｓ１５０３でＮＯの場合）、配信サーバ１１１は、定期アップデートを実行不可能（禁止されている）と判断し、処理を終了する。なお、定期アップデート防止フラグが「ＯＮ」の場合は、ファーム及び、アプリのアップデートにより、後述する図１８のＳ２００９にて定期アップデート防止フラグが「ＯＦＦ」になるまでその状態が継続される。
【００９０】
一方、上記Ｓ１５０３において、定期アップデート防止フラグが「ＯＦＦ」である、あるいはその対象のネットワークデバイスのシリアルＮｏが定期アップデート防止フラグ状態テーブル１１０１に登録されていないと判定した場合（Ｓ１５０３でＹＥＳの場合）、配信サーバ１１１は、定期アップデートを実行可能と判断し、Ｓ１５０４に処理を進める。
【００９１】
Ｓ１５０４において、配信サーバ１１１は、対象のネットワークデバイスから通知された情報９０１と、図１０（ｂ）に示した定期アップデート適用ファームテーブル１４０１から、定期アップデート後のアプリとファームのバージョン情報を生成し、一時データとしてメモリ２０３に保持する。
【００９２】
Ｓ１５０５において、配信サーバ１１１は、一時データである定期アップデート後のバージョン情報と、図６（ｂ）に示したＮＧテーブル１００１とを比較する。比較方法としてはまず、一時データのファームバージョンとＮＧテーブル１００１のファームバージョン１００３を比較して該当するファームバージョンが存在するかを判別する。該当するファームバージョンが存在すれば、次に一時データのアプリ名とアプリバージョンとＮＧテーブルに登録されているアプリ１００４を比較してＮＧパターン１００２に該当するかを判断する。
【００９３】
Ｓ１５０６において、配信サーバ１１１は、上記Ｓ１５０５の比較処理でＮＧパターンに該当しないか否かにより、定期アップデートを実行しても問題なしか否かを判定する。そして、配信サーバ１１１は、上記Ｓ１５０５の比較処理でＮＧパターンに該当しない場合には、定期アップデートを実行しても問題なし（アップデートすべき）と判定し（Ｓ１５０６でＹＥＳと判定し）、Ｓ１５０７に処理を進める。
Ｓ１５０７において、配信サーバ１１１は、対象のネットワークデバイス受信されたファーム構成からアップデートに利用できるファームを特定する。そして、配信サーバ１１１は、その特定されたファームを対象のネットワークデバイスに配信して定期アップデートを実行し、処理を終了する。ネットワークデバイスでは、配信サーバ１１１から配信されてきたファームを利用して、自身にインストール済みのファームをアップデートする。
【００９４】
一方、配信サーバ１１１は、上記Ｓ１５０５の比較処理でＮＧパターンに該当する場合には、定期アップデートを実行すると問題が発生する（アップデートすべきでない）と判定し（Ｓ１５０６でＮＯと判定し）、Ｓ１５０８に処理を進める。
Ｓ１５０８において、配信サーバ１１１は、定期アップデートを実行するとＮＧパターン１００２になってしまうので、対象のネットワークデバイスの定期アップデート防止フラグを「ＯＮ」にして、今後の定期アップデートを防止（禁止）し、処理を終了する。なお、この際、配信サーバ１１１は、対象のネットワークデバイスに対応付けられて予め配信サーバ１１１に登録されている通知先（例えば管理者のメールアドレス）に、定期アップデートが防止（禁止）されたこと、及び、その原因等を通知するようにしてもよい。例えば、「ファームを１１．０にアップデートすると、アプリＣ（１．０）が正常に動作しない可能性がありますので、ファーム１１．０へのアップデートを防止（禁止）しました。」等のメッセージを通知してもよい。
【００９５】
ここで、上記Ｓ１５０２〜Ｓ１５０８の処理について、具体例を用いて説明する。
Ｓ１５０２において、配信サーバ１１１は、例えば以下のデータをネットワークデバイス１２８から受信する。
〔定期アップデート前のネットワークデバイスＡのバージョン構成〕
シリアルＮＯ．：ＺＺＺ００００１
ファームバージョン：１０．０
アプリＡのバージョン：１．０
アプリＣのバージョン：１．０
【００９６】
Ｓ１５０３において、配信サーバ１１１は、定期アップデート防止フラグ状態テーブル１１０１に、Ｓ１５０２で通知を受けたシリアルＮＯ．の「ＺＺＺ００００１」が該当をするか検索を行う。その結果、シリアルＮＯ．の「ＺＺＺ００００１」は定期アップデート防止フラグ状態テーブル１１０１に登録されていないので、Ｓ１５０４に進む。
【００９７】
Ｓ１５０４において、配信サーバ１１１は、ネットワークデバイスから通知される情報９０１と定期アップデート適用ファームテーブル１４０１から、定期アップデート後のアプリとファームのバージョン情報を生成し、一時データとしてメモリ２０３に保持する。その結果、定期アップデート後のネットワークデバイスＡのバージョン構成は以下になる。
〔定期アップデート後のネットワークデバイスＡのバージョン構成〕
ファームバージョン：１１．０
アプリＡのバージョン：１．０
アプリＣのバージョン：１．０
【００９８】
Ｓ１５０５において、配信サーバ１１１は、定期アップデート後のネットワークデバイスＡのバージョン構成とＮＧテーブル１００１を比較する。その結果、定期アップデートを適用するとアプリＣのバージョン「１．０」と、ファームバージョン「１１．０」の組み合わせになり、１００２のＮＧパターン「Ｙ」に合致する。従って、ネットワークデバイスＡは定期アップデート実行後にＮＧ状態になるという判断となり、Ｓ１５０６に移行する。
【００９９】
Ｓ１５０６では、配信サーバ１１１は、定期アップデートを行うと問題があるためＳ１５０８に移行し、定期アップデート防止フラグ状態テーブル１１０１に「ＺＺＺ００００１」を追加して、定期アップデート防止フラグを「ＯＮ」にする。
【０１００】
図１２は、ライセンスサーバ１１４のアプリの新バージョンリリース処理を例示するフローチャートである。本フローは、ライセンスサーバ１１４にアプリの新バージョンがリリースされた場合の説明を行う。本処理は、図５のＳ８０３のタイミングで実行される処理に対応する。なお、図１２の処理は、ライセンスサーバ１１４のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。
【０１０１】
Ｓ１６０１において、ライセンスサーバ１１４は、アプリの新バージョンがリリースされたことを検知すると、Ｓ１６０２に処理を進める。なお、ライセンスサーバ１１４は、アプリの新バージョンがライセンスサーバ１１４又はデータベース１１５に登録された場合に、アプリの新バージョンがリリースされたことを検知する。
【０１０２】
Ｓ１６０２において、ライセンスサーバ１１４は、上記Ｓ１６０１で新バージョンのリリースが検知されたアプリのアプリ名と、ＮＧテーブル１００１の１００４に登録されているアプリ名とを比較することにより、新バージョンがリリースされたアプリがＮＧテーブル１００１に関連するアプリか否かを判断する。ここでは、新バージョンのリリースが検知されたアプリのアプリ名がＮＧテーブル１００１の１００４に登録されていれば、ＮＧテーブル１００１に関連するアプリと判断するものとする。
【０１０３】
Ｓ１６０３において、新バージョンがリリースされたアプリがＮＧテーブル１００１に関連するアプリと判断した場合（Ｓ１６０３でＹＥＳの場合）、ライセンスサーバ１１４は、Ｓ１６０４に処理を進める。
Ｓ１６０４において、ライセンスサーバ１１４は、ＮＧテーブル１００１に関連するアプリの新バージョンがリリースされたことを、配信サーバ１１１に通知する。
【０１０４】
一方、Ｓ１６０３において、新バージョンがリリースされたアプリがＮＧテーブル１００１に関連するアプリでないと判断した場合（Ｓ１６０３でＮＯの場合）、ライセンスサーバ１１４は、そのまま処理を終了する。
【０１０５】
図１３は、配信サーバ１１１のアプリ適用判断処理を例示するフローチャートである。本フローチャートでは、配信サーバ１１１がライセンスサーバ１１４からアプリの新バージョンがリリースされたことを受信して、配信処理を判断する処理について説明を行う。本処理は、図５のＳ８１３のタイミングで実行されるものである。即ち、配信サーバ１１１は、ライセンスサーバ１１４からＮＧテーブル１００１に関連するアプリの新バージョンがリリースされたことの通知（図１２のＳ１６０４の通知）を受信すると、本フローチャートの処理を開始する。
【０１０６】
まず、Ｓ１７０１において、配信サーバ１１１は、定期アップデート防止フラグ状態テーブル１１０１から定期アップデート防止フラグがＯＮの状態のネットワークデバイスを検索して選択する。
【０１０７】
次に、Ｓ１７０２において、配信サーバ１１１は、上記Ｓ１７０１で選択されたネットワークデバイスの構成情報を、選択されたネットワークデバイスから、過去に、配信サーバ１１１に通知された情報９０１の履歴情報を使用して取得する。
次に、Ｓ１７０３において、配信サーバ１１１は、ライセンスサーバ１１４から通知されたアプリの新バージョン情報を取得する。
【０１０８】
Ｓ１７０４において、配信サーバ１１１は、選択されたネットワークデバイスにライセンスサーバ１１４から通知されたアプリと別バージョンで同一のアプリが存在するか判定する。そして、存在すると判定した場合（Ｓ１７０４でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７０５に処理を進める。
【０１０９】
一方、上記Ｓ１７０４において、選択されたネットワークデバイスにライセンスサーバ１１４から通知されたアプリと別バージョンで同一のアプリが存在しないと判定した場合（Ｓ１７０４でＮＯの場合）、配信サーバ１１１は、Ｓ１７０６に処理を進める。
Ｓ１７０６において、配信サーバ１１１は、定期アップデート防止フラグがＯＮ状態のネットワークデバイスが他にも存在するかを確認する。そして、他にも存在する場合（Ｓ１７０６でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７０７に処理を進める。
Ｓ１７０７において、配信サーバ１１１は、次の定期アップデート防止フラグがＯＮ状態のネットワークデバイスを選択し、Ｓ１７０２に処理を移行する。
【０１１０】
一方、上記Ｓ１７０６において、定期アップデート防止フラグがＯＮ状態のネットワークデバイスが他に存在しないと判定した場合（Ｓ１７０６でＮＯの場合）、配信サーバ１１１は、処理を終了する。このような処理により、定期アップデート防止フラグがＯＮ状態の全てのネットワークデバイスについて処理を行うことができる。
【０１１１】
Ｓ１７０５において、配信サーバ１１１は、選択されたネットワークデバイスから通知された情報９０１を基に、図１５に示すような、アプリの新バージョン適用後のテーブル２１０１を作成する。
次に、Ｓ１７０８において、配信サーバ１１１は、アプリの新バージョン適用後のテーブル２１０１とアプリ間のＮＧテーブル１００５とを比較する。
【０１１２】
そして、Ｓ１７０９において、配信サーバ１１１は、上記Ｓ１７０８の比較に基づいて、アプリの新バージョンを適用しても問題ないか否かを判定する。そして、問題あると判定した場合（Ｓ１７０９でＮＯの場合）、Ｓ１７１１に処理を進める。
Ｓ１７１１において、配信サーバ１１１は、選択されたネットワークデバイスに対する、アプリの新バージョン適用を中止して、Ｓ１７０６に処理を移行する。なお、アプリの新バージョン適用を中止した際、配信サーバ１１１は、選択されたネットワークデバイスに対応付けられて予め配信サーバ１１１に登録されている通知先（例えば管理者のメールアドレス）に、アプリの新バージョンの適用を中止したこと、及び、その原因等を通知するようにしてもよい。例えば、「アプリＡを２．０にバージョンアップしても、正常に動作しない可能性がありますので、アプリＡ２．０の適用を中止しました。」等のメッセージを通知してもよい。
【０１１３】
一方、上記Ｓ１７０９において、アプリの新バージョンを適用しても問題ないと判定した場合（Ｓ１７０９でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７１０に処理を進める。
Ｓ１７１０において、配信サーバ１１１は、新バージョンを適用する対象アプリと定期アップデート用ファームの優先度を、優先度テーブル１２０１及び１２０２を参照することで比較する。該比較の結果、対象アプリは定期アップデート用ファームよりも優先度が高いと判定した場合（Ｓ１７１０でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７１４に処理を進める。
【０１１４】
Ｓ１７１４において、配信サーバ１１１は、選択されたネットワークデバイスに対するアプリの新バージョンの適用を、実施方法として仮決定し、Ｓ１７２１に処理を進める。
Ｓ１７２１において、配信サーバ１１１は、優先度順にアプリの適用可否を確認してＳ１７０６に処理を移行する。なお、Ｓ１７２１の処理については、後述する図１４で詳細に説明する。
【０１１５】
一方、上記Ｓ１７１０において、対象アプリは定期アップデート用ファームよりも優先度が高くないと判定した場合（Ｓ１７１０でＮＯの場合）、配信サーバ１１１は、Ｓ１７１２に処理を進める。
【０１１６】
Ｓ１７１２において、配信サーバ１１１は、アプリの新バージョン適用後のテーブル２１０１とファームとアプリ間のＮＧテーブル１００１とを比較する。
Ｓ１７１３において、配信サーバ１１１は、アプリの新バージョンを適用しても問題ないか否かを判定する。そして、問題ないと判定した場合（Ｓ１７１３でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７１４，Ｓ１７２１の処理を実行し、Ｓ１７０６に処理を移行する。
【０１１７】
一方、上記Ｓ１７１３において、アプリの新バージョンを適用すると問題があると判定した場合（Ｓ１７１３でＮＯの場合）、配信サーバ１１１は、Ｓ１７１５に処理を進める。なお、このケースは、アプリの新バージョン適用とファームのアップデートの両方を行う同時アップデートを試みるケースに対応する。
【０１１８】
Ｓ１７１５において、配信サーバ１１１は、上記Ｓ１７０５で作成した、アプリの新バージョン適用後のテーブル２１０１を基に、定期アップデート後のテーブル２１０２を作成する。
次に、Ｓ１７１６において、配信サーバ１１１は、定期アップデート後のテーブル２１０２とファームとアプリ間のＮＧテーブル１００１との比較を、新バージョンがリリースされたアプリに対して行う。
【０１１９】
次に、Ｓ１７１７において、配信サーバ１１１は、上記Ｓ１７１６の比較結果に基づいて、アプリとファームの同時アップデートで問題ないか否かを判定する。そして、問題があると判定した場合（Ｓ１７１７でＮＯの場合）、配信サーバ１１１は、Ｓ１７１１の処理を実行し、Ｓ１７０６に処理を移行する。
【０１２０】
一方、上記Ｓ１７１７において、アプリとファームの同時アップデートで問題ないと判定した場合（Ｓ１７１７でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７１８に処理を進める。
Ｓ１７１８において、配信サーバ１１１は、選択されたネットワークデバイスに対するアプリの新バージョンと定期アップデートの同時適用を、実施方法として仮決定する。
【０１２１】
次に、Ｓ１７１９において、配信サーバ１１１は、定期アップデート後のテーブル２１０２とファームとアプリ間のＮＧテーブル１００１との比較を、新バージョンがリリースされたアプリ以外のアプリに対して行う。
【０１２２】
次に、Ｓ１７２０おいて、配信サーバ１１１は、上記Ｓ１７１９の比較結果に基づいて、アプリとファームの同時アップデートで他のアプリについても問題ないか否かを判定する。そして、問題があると判定した場合（Ｓ１７２０でＮＯの場合）、配信サーバ１１１は、Ｓ１７１１の処理を実行し、Ｓ１７０６に処理を戻す。
【０１２３】
一方、上記Ｓ１７２０おいて、アプリとファームの同時アップデートで他のアプリについても問題ないと判定した場合（Ｓ１７２０でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７２１の処理を実行し、Ｓ１７０６に処理を移行する。
【０１２４】
図１４は、図１３のＳ１７２１の処理を詳細に示すものであり、配信サーバ１１１の優先度順にアプリの適用可否を確認する処理を例示するフローチャートである。
Ｓ１７２２において、配信サーバ１１１は、図１３のＳ１７０２で選択されたネットワークデバイスにインストールされているアプリに、適用対象のアプリよりも優先度の高いアプリが存在するか否かを、優先度テーブル１２０１を参照して判断する。そして、存在しないと判定した場合（Ｓ１７２２でＮＯの場合）、配信サーバ１１１は、Ｓ１７３０に処理を進める。
【０１２５】
Ｓ１７３０において、配信サーバ１１１は、図１３のＳ１７１４やＳ１７１８で仮決定された実施方法を本決定とする。
次に、Ｓ１７３１において、配信サーバ１１１は、上記本決定された実施方法に従って、図１０（ａ）の１３０１に示すような配信予約情報を作成して配信予約を行う。例えば、アプリＡのアップデートが本決定された場合、アプリＡに関する配信予約情報を作成する。また、アプリＡとファームの同時アップデートが本決定された場合、アプリＡに関する配信予約情報と、ファームに関する配信予約情報を作成する。なお、同時アップデートの場合、アプリＡとファームのアップデートを１つにした配信予約情報を作成してもよい。
【０１２６】
次に、Ｓ１７３２において、配信サーバ１１１は、配信指示を監視センタホスト１１７に通知して、処理を終了する。なお、この配信指示では、配信サーバ１１１は、上記選択されたネットワークデバイスのシリアル番号と、該シリアル番号に対応するネットワークデバイスに対するアプリやファームの配信があることを示す情報を、監視センタホスト１１７に通知する。
【０１２７】
また、上記Ｓ１７２２において、配信サーバ１１１は、上記選択されたネットワークデバイスにインストールされているアプリに適用対象のアプリよりも優先度の高いアプリが存在すると判定した場合（Ｓ１７２２でＹＥＳの場合）、Ｓ１７２３に処理を進める。
Ｓ１７２３において、配信サーバ１１１は、上記適用対象のアプリよりも優先度の高いアプリの中で最も優先度の高いアプリを選択する。
【０１２８】
次に、Ｓ１７２４において、配信サーバ１１１は、アプリの新バージョン適用後のテーブル２１０１を基に、図１５に示すような、上記選択アプリのバージョンアップ後のテーブル２１０３を作成し、Ｓ１７２５に処理を進める。この際、配信サーバ１１１は、上記選択アプリについてリリースされているが上記選択されたネットワークデバイスには未だ適用されていないバージョンが存在する場合、上記選択アプリが該新バーションにバージョンアップされた後のテーブル２１０３を作成する。なお、図示しないが、上記選択アプリについてリリースされているが上記選択されたネットワークデバイスには未だ適用されていないバージョンが存在しない場合、配信サーバ１１１は、そのままＳ１７２７に処理を進める。
【０１２９】
Ｓ１７２５において、配信サーバ１１１は、上記選択アプリのバージョンアップ後のテーブル２１０３とアプリ用ＮＧテーブル１００５とを比較する。
次に、Ｓ１７２６において、配信サーバ１１１は、上記Ｓ１７２５の比較結果に基づいて、アプリの新バージョンを適用しても問題ないか否かを判定する。そして、問題あると判定した場合（Ｓ１７２６でＮＯの場合）、配信サーバ１１１は、Ｓ１７２８に処理を進める。
【０１３０】
Ｓ１７２８において、配信サーバ１１１は、アプリの新バージョン適用を中止し、処理を終了する。なお、アプリの新バージョン適用を中止した際、配信サーバ１１１は、選択されたネットワークデバイスに対応付けられて予め配信サーバ１１１に登録されている通知先（例えば管理者のメールアドレス）に、アプリの新バージョンの適用を中止したこと、及び、その原因等を通知するようにしてもよい。例えば、「アプリＡ（２．０）を適用すると、アプリＣ（２．０）が正常に動作しない可能性がありますので、アプリＡの２．０の適用を中止しました。」等のメッセージを通知してもよい。
【０１３１】
一方、上記Ｓ１７２６において、配信サーバ１１１は、アプリの新バージョンを適用しても問題ないと判定した場合（Ｓ１７２６でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７２７に処理を進める。
【０１３２】
Ｓ１７２７において、配信サーバ１１１は、上記選択されたネットワークデバイスにインストールされているアプリに、上記既に選択したアプリの他にも、適用対象のアプリよりも優先度の高いアプリが存在するか否かを判定する。そして、存在すると判定した場合（Ｓ１７２７でＹＥＳの場合）、配信サーバ１１１は、Ｓ１７２９に処理を進める。
Ｓ１７２９において、配信サーバ１１１は、次に優先度の高いアプリを選択し、Ｓ１７２４に処理を移行する。
【０１３３】
一方、上記Ｓ１７２７において、上記既に選択したアプリの他には適用アプリよりも優先度の高いアプリが存在しないと判定した場合（Ｓ１７２７でＮＯの場合）、配信サーバ１１１は、Ｓ１７３０〜Ｓ１７３２の処理を実行する。
【０１３４】
ここで、Ｓ１７０１〜Ｓ１７３２の処理について、具体例を用いて説明する。
配信サーバ１１１は、Ｓ１７０１において、以下のシリアルＮＯ．のネットワークデバイスを選択して、Ｓ１７０２において、以下の構成情報を取得する。
〔ネットワークデバイスのバージョン構成〕
シリアルＮＯ．：ＺＺＺ００００５
ファームバージョン：１０．０
アプリＡのバージョン：１．０
アプリＢのバージョン：１．０
【０１３５】
Ｓ１７０３において、配信サーバ１１１は、ライセンスサーバ１１４から通知されたアプリの新バージョン情報であるアプリＡのバージョン「２．０」の情報を取得する。
Ｓ１７０４において、配信サーバ１１１は、選択されたネットワークデバイスにライセンスサーバ１１４から通知されたアプリと別バージョンで同一のアプリが存在するか検索を行う。アプリＡのバージョン：１．０が上記ネットワークデバイスに存在するのでＳ１７０５に進む。
【０１３６】
Ｓ１７０５において、配信サーバ１１１は、ネットワークデバイスから通知される情報９０１を基に、アプリの新バージョン適用後のテーブル２１０１を作成する。
その結果、アプリの新バージョン適用後のネットワークデバイスのバージョン構成は以下のようになる。
〔アプリの新バージョン適用後のネットワークデバイスのバージョン構成〕
シリアルＮＯ．：ＺＺＺ００００５
ファームバージョン：１０．０
アプリＡのバージョン：２．０
アプリＢのバージョン：１．０
【０１３７】
Ｓ１７０８において、配信サーバ１１１は、アプリの新バージョン適用後のテーブル２１０１とアプリ間のＮＧテーブル１００５を比較する。
Ｓ１７０９において、配信サーバ１１１は、アプリＡとアプリＢの組み合わせはＮＧテーブル１００５に該当しないので、アプリの新バージョンを適用しても問題ないと判断し、Ｓ１７１０に進む。
【０１３８】
Ｓ１７１０において、配信サーバ１１１は、新バージョンを適用する対象アプリと定期アップデート用ファームの優先度を優先度テーブル１２０１及び１２０２を参照することで比較する。その結果、優先度は以下のようになる。
〔アプリＡと定期アップデート用ファームの優先度〕
アプリＡの優先度：１
ファーム１１．０の優先度：３
【０１３９】
上記Ｓ１７１０の比較の結果、配信サーバ１１１は、対象アプリよりも、定期アップデート用ファームの優先度の方が高いと判断し、Ｓ１７１２に進む。
【０１４０】
Ｓ１７１２において、配信サーバ１１１は、アプリの新バージョン適用後のテーブル２１０１と、ファームとアプリ間のＮＧテーブル１００１とを比較する。
上記Ｓ１７１２の結果、配信サーバ１１１は、ファームバージョン：１０．０とアプリＢのバージョン：１．０は、ＮＧパターンＩＤの「Ｘ」に該当し、問題があると判断し、Ｓ１７１５に進む。
【０１４１】
Ｓ１７１５において、配信サーバ１１１は、アプリの新バージョン適用後のテーブル２１０１を基に、定期アップデート後のテーブル２１０２を作成する。
その結果、アプリの新バージョン適用後のネットワークデバイスのバージョン構成は以下のようになる。
〔定期アップデート後のネットワークデバイスのバージョン構成〕
シリアルＮＯ．：ＺＺＺ００００５
ファームバージョン：１１．０
アプリＡのバージョン：２．０
アプリＢのバージョン：１．０
【０１４２】
Ｓ１７１６において、配信サーバ１１１は、定期アップデート後のテーブル２１０２とファームとアプリ間のＮＧテーブル１００１を比較する。その結果、ファームバージョン：１１．０とアプリＡのバージョン：２．０は、ＮＧパターンＩＤの「Ｙ」に該当すると判断し、Ｓ１７１７において、配信サーバ１１１は同時アップデートで問題があると判断し、Ｓ１７１１に進む。Ｓ１７１１において、配信サーバ１１１は、アプリの新バージョン適用を中止して、Ｓ１７０６に戻る。
【０１４３】
次に、Ｓ１７０１〜Ｓ１７３２の処理について、もう一つの具体例を用いて説明する。
配信サーバ１１１は、Ｓ１７０１において、以下のシリアルＮＯ．のネットワークデバイスを選択して、Ｓ１７０２において、以下の構成情報を取得する。
〔ネットワークデバイスのバージョン構成〕
シリアルＮＯ．：ＺＺＺ００００８
ファームバージョン：１０．０
アプリＡのバージョン：１．０
アプリＦのバージョン：１．０
【０１４４】
Ｓ１７０３において、配信サーバ１１１は、ライセンスサーバ１１４から通知されたアプリの新バージョン情報である「アプリＦ」のバージョン「２．０」の情報を取得する。
Ｓ１７０４において、配信サーバ１１１は、選択されたネットワークデバイスにライセンスサーバ１１４から通知されたアプリと別バージョンで同一のアプリが存在するか検索を行う。アプリＦは、上記ネットワークデバイスに存在するのでＳ１７０５に進む。
【０１４５】
Ｓ１７０５において、配信サーバ１１１は、ネットワークデバイスから通知される情報９０１を基に、アプリの新バージョン適用後のテーブル２１０１を作成する。
その結果、アプリの新バージョン適用後のネットワークデバイスのバージョン構成は以下のようになる。
〔アプリの新バージョン適用後のネットワークデバイスのバージョン構成〕
シリアルＮＯ．：ＺＺＺ００００８
ファームバージョン：１０．０
アプリＡのバージョン：１．０
アプリＦのバージョン：２．０
【０１４６】
Ｓ１７０８において、配信サーバ１１１は、アプリの新バージョン適用後のテーブル２１０１とアプリ間のＮＧテーブル１００５とを比較する。
Ｓ１７０９において、配信サーバ１１１は、アプリＡとアプリＦの組み合わせはＮＧテーブル１００５に該当しないため、アプリの新バージョンを適用しても問題ないと判断し、Ｓ１７１０に進む。
【０１４７】
Ｓ１７１０において、配信サーバ１１１は、新バージョンを適用する対象アプリと定期アップデート用ファームの優先度を優先度テーブル１２０１及び１２０２を参照することで比較する。その結果、優先度は以下のようになる。
〔アプリＦと定期アップデート用ファームの優先度〕
アプリＦの優先度：４
ファーム１１．０の優先度：３
【０１４８】
上記Ｓ１７１０の比較の結果、配信サーバ１１１は、定期アップデート用ファームよりも対象アプリの優先度の方が高いので、Ｓ１７１４に進む。
Ｓ１７１４において、配信サーバ１１１は、アプリの新バージョンの適用を実施方法として仮決定し、Ｓ１７２１に進み、Ｓ１７２１の処理は、Ｓ１７２２より始まるので、Ｓ１７２２に進む。
【０１４９】
Ｓ１７２２において、配信サーバ１１１は、適用対象のアプリよりも優先度の高いアプリが存在するか優先度テーブル１２０１を参照して判断する。その結果、適用対象のアプリＦよりも優先度の高いアプリは存在しないため、Ｓ１７３０に進む。
【０１５０】
Ｓ１７３０において、配信サーバ１１１は仮決定の方法を本決定とする。
次に、Ｓ１７３１において、配信サーバ１１１は、シリアルＮＯ．：ＺＺＺ００００８のネットワークサーバに対する、アプリＦの配信予約情報を生成することにより配信予約を行う。
さらに、Ｓ１７３２において、配信サーバ１１１は、配信指示（シリアルＮＯ．：ＺＺＺ００００８のネットワークサーバに対して配信があることを指示する情報）を監視センタホスト１１７に通知して、処理を終了する。
【０１５１】
図１５は、配信サーバ１１１のメモリ（ＲＡＭ２０３）に保持される一時的な情報を例示する図である。
２１０１は、アプリの新バージョンが適用された場合のネットワークデバイスのファームとアプリの状態を示す。
２１０２は、アプリの新バージョンが適用され、さらに定期アップデートが適用された場合のネットワークデバイスのファームとアプリの状態を示す。
２１０３は、アプリの新バージョンが適用され、さらに、該新バーションが適用されたアプリより優先度の高いアプリのバージョンアップ後のネットワークデバイスのファームとアプリの状態を示す。
【０１５２】
図１６は、監視センタホスト１１７のファーム／アプリ配信指示の処理を例示するフローチャートである。本フローチャートでは、監視センタホスト１１７からの配信指示によってネットワークデバイス１２８のアプリ及び、ファームを更新する処理について説明する。なお、図１６の処理は、監視センタホスト１１７のＣＰＵ２０１がＲＯＭ２０２又はＨＤＤ２０４等に格納されたプログラムを読み出して実行することにより実現されるものである。本処理は、図５のＳ８０４〜Ｓ８０６のタイミングで実行されるものである。
【０１５３】
Ｓ１８０１において、監視センタホスト１１７は、配信サーバ１１１からの配信指示（ネットワークデバイスのシリアル番号と配信があることを示す情報が含まれる）を受信すると、Ｓ１８０２に処理を進める。
Ｓ１８０２において、監視センタホスト１１７は、上記Ｓ１８０１で受信した配信指示に対応するネットワークデバイスよりポーリング通信を受信するまで待機する。なお、ネットワークデバイス１２８は、一定間隔で監視センタホスト１１７とポーリング通信をしている。
【０１５４】
上記Ｓ１８０２において、上記Ｓ１８０１で受信した配信指示に対応するネットワークデバイスよりポーリング通信を受信したと判定した場合（Ｓ１８０２でＹＥＳの場合）、監視センタホスト１１７は、Ｓ１８０３において、該ポーリング通信のレスポンスとして、該ポーリング通信の送信元のネットワークデバイスに配信指示を通知する。なお、この配信指示では、例えばアプリ又はファームの配信があることを示す情報をネットワークデバイスに通知する。
【０１５５】
図１７は、ネットワークデバイス１２８のファーム／アプリのアップデート処理を例示するフローチャートである。本フローチャートでは、ネットワークデバイス１２８のファーム／アプリのアップデート処理を説明する。図１７の処理は、ネットワークデバイス１２８のＣＰＵ３０６がＲＯＭ３０７又はＨＤＤ３０９に格納されたプログラムを読み出して実行することにより実現される。本処理は、図５のＳ８０５〜Ｓ８１１のタイミングでネットワークデバイス１２８により実行されるものである。
【０１５６】
Ｓ１９０１において、ネットワークデバイス１２８は、ポーリングを行い監視センタホスト１１７から配信指示（例えば、アプリ又はファームの配信があることを示す情報）を受信すると、Ｓ１９０２に処理を進める。
Ｓ１９０２において、ネットワークデバイス１２８は、配信サーバ１１１に配信予約情報を要求する。
【０１５７】
次に、Ｓ１９０３において、ネットワークデバイス１２８は、配信サーバ１１１から、図１０（ａ）に示したような配信予約情報１３０１を受信すると、Ｓ１９０４に処理を進める。
Ｓ１９０４において、ネットワークデバイス１２８は、配信予約情報１３０１に登録されている日時で配信サーバ１１１に配信要求を行う。
【０１５８】
次に、Ｓ１９０５において、ネットワークデバイス１２８は、配信サーバ１１１からアプリもしくはファームのダウンロード用ＵＲＬを受信すると、Ｓ１９０６に処理を進める。
Ｓ１９０６において、ネットワークデバイス１２８は、上記Ｓ１９０５で受信したダウンロード用ＵＲＬを用いて、配信サーバ１１１からアプリもしくはファームをダウンロードする。
【０１５９】
次に、Ｓ１９０７において、ネットワークデバイス１２８は、上記Ｓ１９０６でダウンロードしたアプリもしくはファームのアップデートを行う。
Ｓ１９０８において、ネットワークデバイス１２８は、上記Ｓ１９０７で行ったアプリもしくはファームのアップデートが完了すると、その結果を、配信サーバ１１１に通知する。
【０１６０】
図１８は、配信サーバ１１１のファーム／アプリアップデートにおける処理を例示するフローチャートである。本フローチャートでは、配信サーバ１１１のファーム／アプリアップデート処理を説明する。本処理は、図５のＳ８０７〜Ｓ８１１のタイミングで配信サーバ１１１により実行されるものである。
【０１６１】
Ｓ２００１において、配信サーバ１１１は、ネットワークデバイス１２８から配信予約情報要求を受信すると、Ｓ２００２に処理を進める。
Ｓ２００２において、配信サーバ１１１は、上記Ｓ２００１で配信予約情報要求を受信したネットワークデバイス１２８（以下、対象のネットワークデバイス）に、図１０（ａ）の１３０１に示したような、配信予約情報を送信する。
【０１６２】
次に、Ｓ２００３において、配信サーバ１１１は、対象のネットワークデバイスから配信要求を受信すると、Ｓ２００４に処理を進める。
Ｓ２００４において、配信サーバ１１１は、対象のネットワークデバイスにアプリもしくはファームのダウンロード用ＵＲＬを返信する。
【０１６３】
次に、Ｓ２００５において、配信サーバ１１１は、対象のネットワークデバイスからファームのアップデート完了通知を受信すると、Ｓ２００６に処理を進める。
Ｓ２００６において、配信サーバ１１１は、対象のネットワークデバイスが正常に動作しているか否かを判断する。判断方法としては、上記Ｓ２００５において正常なアップデート通知を受信している場合には正常に動作していると判断し、一方、正常なアップデート通知を受信していない場合には正常に動作していないと判断する。
【０１６４】
そして、上記Ｓ２００６において、対象のネットワークデバイスが正常に動作していると判定した場合（Ｓ２００６でＹＥＳの場合）、配信サーバ１１１は、Ｓ２００７に処理を進める。
Ｓ２００７において、配信サーバ１１１は、定期アップデート防止フラグがＯＦＦにできるか否かを上記Ｓ２００５の通知に基づいて判断する。
【０１６５】
例えば、上記Ｓ２００５において正常なアップデート通知を受信している場合には定期アップデート防止フラグをＯＦＦにできると判断し、一方、正常なアップデート通知を受信していない場合には定期アップデート防止フラグをＯＦＦにできないと判断する。また、上記Ｓ２００５において正常なアップデート通知を受信している場合、さらに、該正常にアップデートされたネットワークデバイスの定期アップデート後のテーブルを作成し、該テーブルとファームとアプリ間のＮＧテーブル１００１とを比較し、ファームの定期アップデートを行っても問題ない場合に定期アップデート防止フラグをＯＦＦにできると判断してもよい。
【０１６６】
そして、上記Ｓ２００７において、配信サーバ１１１は、定期アップデート防止フラグをＯＦＦにできると判断した場合（Ｓ２００７でＹＥＳの場合）、Ｓ２００９に処理を進める。
Ｓ２００９において、配信サーバ１１１は、対象のネットワークデバイスの定期アップデート防止フラグをＯＦＦにし、処理を終了する。これにより、対象のネットワークデバイスの定期アップデートの防止（禁止）を解除することができる。なお、この際、配信サーバ１１１は、対象のネットワークデバイスに対応付けられて予め配信サーバ１１１に登録されている通知先（例えば管理者のメールアドレス）に、定期アップデートの防止（禁止）が解除されたことを通知するようにしてもよい。
【０１６７】
一方、上記Ｓ２００７において、配信サーバ１１１は、定期アップデート防止フラグをＯＦＦにできないと判断した場合（Ｓ２００７でＮＯの場合）、そのまま処理を終了する。
【０１６８】
また、上記Ｓ２００６において、対象のネットワークデバイスが正常に動作していないと判定した場合（Ｓ２００６でＮＯの場合）、配信サーバ１１１は、Ｓ２００８に処理を進める。
Ｓ２００８において、配信サーバ１１１は、エラーが発生していると判断してシステム管理者（予め登録されているメールアドレス）にメール通知し、処理を終了する。
【０１６９】
以下、図１９、図２０を参照して、配信サーバ１１１に緊急度の高いファームがリリースされた場合の処理を説明する。
図８（ｂ）で示される優先度テーブルは、アプリ、ファームの優先度範囲は１〜５であるが、ネットワークデバイスに緊急で適用すべきファーム（緊急度の高いファーム）がリリースされた場合に、例外として優先度６、優先度７のファームが存在する。
【０１７０】
図１９では優先度６のファームがリリースされた場合の説明を行い、図２０では優先度７のファームがリリースされた場合の説明を行う。
優先度６は、例えば、脆弱性の高いセキュリティホールが見つかった場合などのセキュリティパッチなどを指す。また、優先度７は、例えば、リコールレベルのハードウェア故障を修復するための修復用ファームなどを指す。
【０１７１】
図１９は、優先度６のファームがリリースされた場合の配信サーバ１１１の処理を例示するフローチャートである。
Ｓ２５０１において、配信サーバ１１１は、配信サーバ１１１に優先度６のファームが優先度テーブルに登録されたことを検知すると、Ｓ２５０２に処理を進める。なお、ライセンスサーバ１１４から優先度６のファームがリリースされたことを示す情報を受信した場合に、Ｓ２５０２に処理を進めるようにしてもよい。
【０１７２】
Ｓ２５０２において、配信サーバ１１１は、配信サーバ１１１で配信可能なネットワークデバイスを検索する。なお、配信可能なネットワークデバイスは、配信サーバ１１１で配信対象となっている各ネットワークデバイスのシリアル番号に基づいて機種を決定し、該機種に基づいて判断可能である。
【０１７３】
次に、Ｓ２５０３において、配信サーバ１１１は、上記Ｓ２５０２の検索結果に基づいて、配信可能なネットワークデバイスが存在するか否かを判定する。そして、配信可能なネットワークデバイスが存在しないと判定した場合（Ｓ２５０２でＮＯの場合）、配信サーバ１１１は、処理を終了する。
【０１７４】
一方、上記Ｓ２５０３において、配信可能なネットワークデバイスが存在すると判定した場合（Ｓ２５０２でＹＥＳの場合）、配信サーバ１１１は、Ｓ２５０４に処理を進める。
【０１７５】
Ｓ２５０４において、配信サーバ１１１は、図１０（ａ）に示したような配信予約情報１３０１の定期アップデートスケジュールの指定日を本日に変更し、指定時間は変更なしで、配信予約を行う。このようにすることで、定期アップデートの指定日を待たずとも、本日中に顧客影響の少ない時間帯でファームを配信可能となる。通常、定期アップデートの指定時刻は深夜に設定されているので、本実施例では、そのケースを基に顧客影響の少ない時間帯と判断している。
【０１７６】
次に、Ｓ２５０５において、配信サーバ１１１は、監視センタホスト１１７に配信指示を行う。次に、Ｓ２５０６において、配信サーバ１１１は、上記優先度６のファームを配信可能なネットワークデバイスが他にも存在するか否かを確認する。そして、他にも存在すると判定した場合（Ｓ２５０６でＹＥＳの場合）、配信サーバ１１１は、Ｓ２５０７に処理を進める。
Ｓ２５０７において、配信サーバ１１１は、次のネットワークデバイスを選択して、Ｓ２５０４に処理を移行する。
【０１７７】
一方、上記Ｓ２５０６において、上記優先度６のファームを配信可能なネットワークデバイスは他には存在しないと判定した場合（Ｓ２５０６でＮＯの場合）、配信サーバ１１１は、処理を終了する。
【０１７８】
図２０は、優先度７のファームがリリースされた場合の配信サーバ１１１の処理を例示するフローチャートである。
Ｓ２６０１において、配信サーバ１１１は、配信サーバ１１１に優先度７のファームが優先度テーブルに登録されたことを検知すると、Ｓ２６０２に処理を進める。なお、ライセンスサーバ１１４から優先度７のファームがリリースされたことを示す情報を受信した場合に、Ｓ２６０２に処理を進めるようにしてもよい。なお、Ｓ２６０２〜Ｓ２６０３の処理は、図１９のＳ２５０２〜Ｓ２５０３の処理と同一であるので説明は省略する。
【０１７９】
Ｓ２６０４において、配信サーバ１１１は、図１０（ａ）に示したような配信予約情報１３０１を即時に変更して配信予約を行う。即ち、配信予約情報１３０１の定期アップデートスケジュールの指定日を本日に変更し、指定時間を現時分に変更し、配信予約を行う。このようにすることで、即時にファームを配信可能となる。
なお、Ｓ２６０６〜Ｓ２６０７の処理は、図１９のＳ２５０６〜Ｓ２５０７の処理と同一であるので説明は省略する。
【０１８０】
以上、図１９、図２０に示したように、優先度が所定の優先度以上（例えば優先度６以上）のバージョンのファームウェアがリリースされた場合、配信サーバ１１１は、ＮＧテーブル１００１に登録された情報に関係なく、優先度に応じた期間で（例えば優先度６では即日、優先度７では即時）、ネットワークデバイスに対してファームをアップデートする制御を行う。これにより、例えば、リコール等で緊急度の高いファームがリリースされた場合には、アプリの不具合の発生の可能性に関係なく優先的にファームのインストールを行うようにすることができる。例えば、緊急を要する事態（例えばリコール）に迅速に対応することができる。
【０１８１】
なお、緊急度の高いことを示す優先度のファームがリリースされた場合、ＮＧテーブルを用いた判定に関係なく、ファームをアップデートする構成について説明したが、緊急度の高いことを示す優先度のアプリについても同様にアップデートしてもよい。
また、優先度６のファームの場合には配信予約情報の指定日時をその日とし、優先度７のファームの場合には配信予約情報の指定日時を即時とする構成について説明したが、優先度に応じた期間で定期アップデートを行える構成であれば、その日や即時に限定されるものではない。
【０１８２】
また、上記実施例では、ネットワークデバイスの一例として画像形成装置を用いて説明したが、本発明を適用可能なネットワークデバイスは画像形成装置に限定されるものではなく、ソフトウェアの配信を受けることが可能なネットワーク機器であれば他の種類の機器であってもよい。例えば、パーソナルコンピュータ、タブレット型コンピュータ、スマートフォン等であっても、テレビジョン、ハードディスクレコーダ、ネットワークオーディオ等のネットワーク家電であっても、カーナビゲーションシステム、ネットワークカメラなどであってもよい。
【０１８３】
以上示したように、ファームのアップデートによりアプリのミドルウェアが変更されてしまうと複数のアプリで不具合を及ぼす可能性があるため、該不具合を及ぼす可能性がある構成を記載したＮＧテーブルを配信サーバに登録しておき、配信サーバの定期ファームップデート処理において、ＮＧテーブルを参照して、ＮＧの構成（アプリに不具合が発生する構成）にならないように、ファームとアプリの更新タスクを制御することにより、ファームのアップデートによりアプリに不具合が発生することを防止することができる。また、ファームウェアアップデートに対応したアプリケーションがリリースされた場合には、最善の方法でネットワークデバイスのファームウェア及び、アプリケーションをアップデートすることが可能となる。
従って、アプリに不具合を発生させるようなファームのアップデートを防止するとともに、ファームのアップデートに対応したアプリのリリースに応じてファームをアップデート可能にすることができる。
【０１８４】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
【０１８５】
（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【図１】
2017045302.tif 000003
【図２】
2017045302.tif 000004
【図３】
2017045302.tif 000005
【図４】
2017045302.tif 000006
【図５】
2017045302.tif 000007
【図６】
2017045302.tif 000008
【図７】
2017045302.tif 000009
【図８】
2017045302.tif 000010
【図９】
2017045302.tif 000011
【図１０】
2017045302.tif 000012
【図１１】
2017045302.tif 000013
【図１２】
2017045302.tif 000014
【図１３】
2017045302.tif 000015
【図１４】
2017045302.tif 000016
【図１５】
2017045302.tif 000017
【図１６】
2017045302.tif 000018
【図１７】
2017045302.tif 000019
【図１８】
2017045302.tif 000020
【図１９】
2017045302.tif 000021
【図２０】
2017045302.tif 000022