JP2021026252A - ソフトウェア更新システムおよびソフトウェア更新方法 - Google Patents

Abstract

【課題】サービス機能を構成するソフトウェアモジュールの更新を迅速に行うソフトウェア更新システムを提供する。【解決手段】複合機３０ａ〜３０ｎにおいて優先して実現させたいサービス機能がある場合、通信ネットワーク２０を介して通信可能に接続されたサーバ１０は、スケジュールデータベース１７内のモジュール取得スケジュールを変更して、実現させたいサービス機能を要求した複合機へ、そのサービス機能に対応するソフトウェアモジュールを優先的にダウンロードする。その複合機は、実現させるサービス機能に対応するソフトウェアモジュール間において所定の依存関係が満たされると判断した場合、サービス機能をアップデートする。【選択図】図２

Description

本発明は、遠隔地に設置された端末装置のソフトウェアをアップデートするソフトウェア更新システムおよびその方法に関する。

サーバ装置より離れた遠隔地に設置された多数の端末装置を制御するシステムは、設置台数の多さと展開地域の広さから、保守要員が個々の地域に出向いて端末装置のファームウェアを更新することは時間と費用の観点から現実的ではない。そのため、通信回線を経由してサーバ装置から端末装置へファームウェアをダウンロードして、ファームウェアを更新するオンラインアップデートが実用化されている。

このようなアップデートシステムは、例えば、アップデートを行うソフトウェアを一つにまとめて通信回線を介して端末装置へ送信することで、一斉にアップデート処理を行う構成をとる。

特許文献１は、ファームウェアのダウンロードと書き換え処理に時間を要するという課題に着目して、ファームウェアのバージョンアップ時には、変更のあるモジュール群が格納されたメモリ領域のみを更新することで、ダウンロードと書き換え処理の時間を短縮する技術を開示している。

特開２００２−３４２１００号公報

しかしながら、更新するファームウェア量が多い場合には、特許文献１の構成をとっても、時間短縮の効果が十分に得られないという問題がある。近年における端末装置の高機能化、およびソフトウェアの高容量化、複雑化に伴い、ソフトウェアを複数のソフトウェアモジュールで構成してサービス機能を実現しているが、通信回線に接続された端末装置が多数ある場合、ファームウェアのアップデート等に際して膨大な通信回線容量が必要となるからである。

通信回線容量が不足すると、例えば端末装置のユーザにとって早急に更新したいサービス機能がある場合、ソフトウェアモジュールがダウンロードされて、アップデートが実行されるまで待たされるという問題がある。

一方、不特定多数の端末装置のアップデート等に要する時間を短縮するには、ユーザが端末装置を操作して指示するよりも、自動的にダウンロードとアップデートを実行する必要がある。

また、時期（日時）を決めて、機能を凝縮したソフトウェアをまとめてダウンロードする方式をとると、大容量ファイルの一括送信になるだけでなく、不要な機能のソフトウェアもダウンロードすることになり、通信回線資源の無駄の発生のみならず、個々のユーザが必要とするサービス機能の実現に対応できないという問題がある。

そこで、本発明は上記課題を解決するため、遠隔地に配置された端末装置において、サービス機能を構成するソフトウェアモジュールのダウンロードおよびアップデートを迅速に行うことを可能にするためのソフトウェア更新システムおよびその方法を提供することを目的とする。

本発明によれば、
搭載された１またはそれ以上のソフトウェアモジュールにより所定の各サービス機能を実現する１またはそれ以上の端末装置と、サーバ装置とが通信ネットワークを介して通信可能に接続されたソフトウェア更新システムであって、
前記サーバ装置は、
少なくとも前記ソフトウェアモジュールと、前記ソフトウェアモジュール間の依存関係を示す情報と、前記端末装置による前記ソフトウェアモジュールの取得スケジュールを示すスケジュールファイルとを記憶する記憶手段を備え、
前記端末装置は、
前記サーバ装置より前記取得スケジュールに従って前記ソフトウェアモジュールを取得する取得手段と、
前記依存関係を充足するために必要な全てのソフトウェアモジュールが前記取得手段により取得されたか否かを判断する判断手段と、
前記判断手段により前記依存関係を充足するために必要な全てのソフトウェアモジュールが取得されたと判断された場合、該ソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを更新する更新手段と、
を備えることを特徴とするソフトウェア更新システムが提供される。

また、本発明によれば、
１またはそれ以上の端末装置と、サーバ装置とが通信ネットワークを介して通信可能に接続されたシステムにおけるソフトウェア更新方法であって、
前記サーバ装置において、前記端末装置で実現される所定のサービス機能に対応する１またはそれ以上のソフトウェアモジュールと、前記ソフトウェアモジュール間の依存関係を示す情報と、前記端末装置による前記ソフトウェアモジュールの取得スケジュールを示すスケジュールファイルとを記憶する工程と、
前記端末装置において、前記サーバ装置より前記取得スケジュールに従って前記ソフトウェアモジュールを取得する工程と、
前記端末装置において、前記依存関係を充足するために必要な全てのソフトウェアモジュールが取得されたか否かを判断する工程と、
前記端末装置において、前記依存関係を充足するために必要な全てのソフトウェアモジュールが取得されたと判断された場合、前記ソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを更新する工程と、
を有するソフトウェア更新方法が提供される。

本発明によれば、必要な機能モジュールを優先的に取得してソフトウェアをアップデートすることで、端末装置において必要なサービス機能を迅速に実行可能となる。その際、あらかじめ設定したソフトウェアモジュールの依存関係に従ってアップデートするので、不要なモジュールのダウンロードやアップデートが行われず、回線容量の負担を軽減するとともに、ソフトウェアの更新を迅速かつ効率的に行うことができる。

本発明の実施の形態に係るソフトウェア更新システムのシステム構成図である。 本発明の実施の形態に係るソフトウェア更新システムのサーバの内部構成を示すブロック図である。 本発明の実施の形態に係るソフトウェア更新システムの複合機の内部構成を示すブロック図である。 本発明の実施の形態に係るソフトウェア更新システムのサーバにおける処理手順を示すフローチャートである。 本発明の実施の形態に係るソフトウェア更新システムの複合機における処理手順を示すフローチャートである。 本発明の実施の形態による依存関係データベースの具体的な構成を示す図である。 本発明の実施の形態においてスケジュール変更されたときの依存関係データベースの構成を例示する図である。 サービス機能を実現するモジュール間の依存関係の一例を説明する図である。 サービス機能を実現するモジュール間の依存関係の他の例を説明する図である。 サービス機能を実現するモジュール間の依存関係の他の例を説明する図である。 サービス機能を実現するモジュール間の依存関係の他の例を説明する図である。 サービス機能を実現するモジュール間の依存関係の他の例を説明する図である。 サービス機能を実現するモジュール間の依存関係のさらなる他の例を説明する図である。 本発明の実施例１に係る機能アップデートを説明する図である。 本発明の実施例２に係る特定サービス機能の優先的なアップデート要求を説明する図である。 本発明の実施例２に係る特定サービス機能のアップデート要求時における操作部の画面表示例を示す図である。 本発明の実施例３に係る同一サービス機能内の特定機能の優先的なアップデート要求を説明する図である。 本発明の実施例３に係る同一サービス機能内の特定機能のアップデート要求時における操作部の画面表示例を示す図である。 本発明の実施形態に係るソフトウェア更新システム全体の詳細構成を示す図である。

以下、図面を参照して本発明を実施するための形態について詳細に説明する。

図１は、本発明の実施の形態に係るソフトウェア更新システムのシステム構成図である。図１において、ソフトウェア更新システム１は、サーバ１０と、複数（ここではｎ台）の複合機（ＭＦＰ）３０ａ〜３０ｎとが、通信ネットワーク（ＮＷ）２０を介して互いに通信可能に接続された構成を有する。

複合機３０ａ〜３０ｎは、例えば、コピー機能、スキャン機能、印刷機能等の各種画像形成機能、ＦＡＸ送受信等の通信機能を実行するデジタル複合機またはアナログ複合機であり、例えばコンビニエンスストアに設置されている。複合機３０ａ〜３０ｎは、以降において単に端末ともいう。また、以下で複合機３０というときには、複合機３０ａ〜３０ｎのうちの任意の複合機を指すものとする。

通信ネットワーク２０は、例えば専用の通信網、公衆電話回線網、インターネット等であって、有線あるいは無線の通信回線からなる。

図２は、サーバ１０の内部構成を示すブロック図である。サーバ１０は、サーバ全体を制御するサーバ制御部１１、複合機３０に対するソフトウェアの更新に使用するアップデート用モジュール等を格納する記憶部１２、および、通信ネットワーク２０を介して複合機３０と通信を行う通信制御部１９を備える。

図３は、複合機３０の内部構成を示すブロック図である。図３において複合機３０は、複合機全体を制御する端末制御部３１、サーバ１０より送信されたアップデート用モジュール等を格納する記憶部３３、入力部３５ａ、表示部３５ｂを含む操作部（ＵＩ部）３５、および、通信ネットワーク２０を介してサーバ１０と通信を行う通信制御部３９を備える。

なお、図示を省略するが、複合機３０は、原稿台と、その原稿台に設置された原稿用紙をレーザー光源等により検知して読み取り、画像データを生成する原稿読取装置、その画像データを印刷用紙（シート）に印刷して出力する画像形成装置とを備える。さらに、シートを給送するシート給送部、シートを手差し給送可能な手差し給送部とを備え、シート給送部または手差し給送部により給送されるシートに画像形成装置により画像が形成される。

画像読取りのために原稿読取装置を単体で用いること、画像形成のために画像形成装置を単体で用いることの他に、画像を複写するためにこれらを連動させることもできる。また、複合機３０は、記憶装置、およびファクシミリ装置を含んでいてもよい。ファクシミリ装置は、原稿読取装置により読み取られた画像、記憶装置に格納されている画像等を送信すること、外部から画像を受信することができる。記憶装置は、原稿読取装置によって読み取られた画像、ファクシミリ装置により受信した画像等を格納する。

サーバ１０のサーバ制御部１１、複合機３０の端末制御部３１は、各種のプログラムを読み出して実行することにより所定の機能を実現する、例えばＣＰＵ（Central Processing Unit）等を含んでいてもよい。また、サーバ１０の記憶部１２、複合機３０の記憶部３３は、例えばＨＤＤ（Hard Disc Drive）、フラッシュメモリ、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）等の不揮発性メモリである。

次に、本実施の形態に係るソフトウェア更新システムの動作について説明する。図４は、図１のソフトウェア更新システム１を構成するサーバ１０における処理手順を示すフローチャートであり、図５は、複合機３０における処理手順を示すフローチャートである。
＜サーバの動作＞
サーバ１０は、上述したように通信ネットワーク２０を介して複合機３０と通信可能に接続され、種々の情報をやり取りしながら複合機３０を統括している。具体的には、サーバ１０は、複合機３０各々の機種名、設置場所、機能構成、設定情報等に関する最新情報をもとに、複合機３０を一元的に管理している。

複合機３０は、コピー、スキャン、ＦＡＸ送信等、複数の機能（サービス機能ともいう）を有しており、それらのサービス機能を実現するソフトウェアは、１あるいは複数のソフトウェアモジュールからなる。ソフトウェアモジュールはソフトウェアの構成要素であり、以降において機能モジュール、あるいは単にモジュールともいう。

サーバ１０のサーバ制御部１１は、最初に、図４のステップＳ１１において、記憶部１２に格納されている複数のモジュール（後述するモジュールａ〜ｇ）１５のうちの少なくとも一部のモジュールに対して、機能追加、仕様変更、不具合修正等を伴う最新バージョンへの更新（アップデート）を行う。これに伴い更新したモジュールのバージョン（Version）表記を変更する。

続くステップＳ１３において、複合機３０毎に、それぞれのサービス機能の実現に要する複数のモジュール間の依存関係を示す依存関係データベース１３を新しいバージョン標記を用いて再構築する。

ここで「依存関係」とは、複合機において、あるサービス機能が複数のモジュールによって実現される場合、それら複数のモジュール間相互において満たされるべき関係をいう。例えば、あるモジュールの動作時に他のモジュールの動作を伴う関係、複数のモジュールの内部に含まれる要素間の関係等をいう。依存関係のさらなる詳細については後述する。

サーバ制御部１１は、さらにステップＳ１５において、スケジュールデータベース（スケジュールファイルともいう）１７を作成する。スケジュールファイル１７は、サーバ１０から各複合機３０に複数のモジュールをダウンロードする場合における、あらかじめ決めたダウンロードの日時、ダウンロード順序等を示すデータを含む。

スケジュールファイル１７は、サービスを受ける複合機３０の管理者が指示した要求内容に従って作成されるが、その際、他の複合機に対するスケジュールとの関係、ダウンロードする機能モジュールのデータ容量、サーバと複合機間の回線容量、回線のデータ伝送速度等が考慮される。

図６は、依存関係データベースの具体的な構成を示している。図６（ａ）は複合機３０ａ（ＭＦＰ１）に対応する依存関係データベースの構成である。複合機３０ａは、モジュールａ，ｂ，ｃからなるサービス機能Ｘと、モジュールｂ，ｄからなるサービス機能Ｙと、モジュールｅからなるサービス機能Ｚを利用者に提供する。

すなわち、複合機３０ａにおいてサービス機能Ｘを実現するには、各々が更新後のバージョンをＶｅｒ２．０とするモジュールａ，ｂ，ｃが必要であり、それらの取得順序（ＤＬ順序）がそれぞれ１，２，３とあることから、モジュールａ，ｂ，ｃの順にダウンロード（ＤＬ）されるようにスケジュールが組み込まれている。なお、取得順序１，２，３はモジュールａ，ｂ，ｃの間で入れ替わってもよい。

依存関係に関して、図６（ａ）においてモジュールａ，ｂ，ｃそれぞれに同一の数字１が付与されていることから、モジュールａ，ｂ，ｃすべてが揃うことによりサービス機能Ｘが実現される。バージョンも絡めて説明すると、Ｖｅｒ２．０のモジュールａと、Ｖｅｒ２．０のモジュールｂと、Ｖｅｒ２．０のモジュールｃが揃うことにより最新バージョンのサービスＸを利用者に提供することができるようになる。

サービス機能Ｙの実現に必要なモジュールｂ，ｄの最新バージョンは、更新後のバージョンがＶｅｒ２．０であるが、モジュールｂ，ｄの双方に依存関係を示す数字２が付与されている。取得順序がそれぞれ４，５とあることから、モジュールａ，ｂ，ｃがダウンロードされた後、モジュールｂ，ｄがこの順にダウンロードされるスケジュールが組み込まれている。バージョンも絡めて説明すると、Ｖｅｒ２．０のモジュールｂと、Ｖｅｒ２．０のモジュールｄが揃うことにより最新バージョンのサービスＹを利用者に提供することができるようになる。

一方、サービス機能Ｚの実現に必要なモジュールｅの最新バージョンは、更新後のバージョンがＶｅｒ２．０であるが、依存関係を示す項がブランクになっていることから、他のモジュールと依存関係を有しない。また、取得順序が６であるため、モジュールａ〜ｄがダウンロードされた後、モジュールｅがダウンロードされるようにスケジュールが組み込まれている。

図６（ｂ）は複合機３０ｂに対応する依存関係データベースの構成である。複合機３０ｂには、サービス機能Ｘの実現に必要なＶｅｒ２．０のモジュールａ，ｂ，ｃ（依存関係あり）がこの順にダウンロードされる。但し、取得順序１，２，３はモジュールａ，ｂ，ｃの間で入れ替わってもよく、入れ替わったならば、入れ替わった後の取得順序に従ってＶｅｒ２．０のモジュールａ，ｂ，ｃがダウンロードされる。

さらに、複合機３０ｃに対応する依存関係データベースの構成を示す図６（ｃ）より、複合機３０ｃについては、サービス機能Ｑの実現に必要なＶｅｒ２．０のモジュールｆ，ｇ（依存関係あり）が、この順にダウンロードされる。但し、取得順序１，２はモジュールｆ，ｇの間で入れ替わってもよく、入れ替わったならば、入れ替わった後の取得順序に従ってＶｅｒ２．０のモジュールｆ，ｇはダウンロードされる。

ここで、サービス機能とモジュールのソフトウェア構成を例示する。例えば図６（ａ）の場合、サービス機能Ｘはコピーサービスであり、モジュールａはユーザインターフェース（ＵＩ）制御、モジュールｂは課金制御、モジュールｃは機械制御（ＭＦＰ制御）をそれぞれ司る。

サービス機能ＹはＦＡＸサービスであり、モジュールｂは課金制御、モジュールｄは通信制御をそれぞれ司る。よって、この例では、課金制御に関するモジュールｂは、サービス機能Ｘ，Ｙにおいて共通モジュールとなる。

再びサーバ１０の動作に戻ると、サーバ制御部１１は、図４のステップＳ１７において、複合機３０より、モジュールについて後述するダウンロード順序の変更要求があったか否かを判断する。変更要求がなければ、ステップＳ１９において、当初のスケジュールに従って各複合機に必要なモジュールをダウンロードする。

変更要求があった場合には、ステップＳ２１において、複合機からの要求にしたがったスケジュール変更（ダウンロード順の入れ替え）を行う。続くステップＳ２３において、その複合機に対して、変更後のスケジュールによるモジュールのダウンロードを行う。

図７は、複合機３０ａにおいて、図６（ａ）のスケジュールが変更されたときの依存関係データベースの構成を示している。ここでは、複合機３０ａのユーザが、サービス機能Ｙの更新をサービス機能Ｘに優先させるため、後述する操作を行うことで、図７に示すように、モジュールｂ，ｄが先にダウンロードされ、その後、モジュールａ，ｂ，ｃがダウンロードされる。なお、モジュールｅについては、スケジュール変更の前後においても、最後にダウンロードされる。

このようなスケジュール変更に従って複合機３０ａにモジュールがダウンロードされることで、複合機３０ａでは、サービス機能Ｙが更新された後、サービス機能Ｘが更新される。

サーバ制御部１１は、ステップＳ２５において、サーバ１０が統括している複合機に対して、個々のサービス機能の実現に必要なすべてのモジュールのダウンロードが完了したか否かを判断する。全モジュールのダウンロードが完了していない場合、それが完了するまで、上記のステップＳ１７〜Ｓ２３を繰り返す。

なお、サービス機能間でモジュールが重複する（１つのモジュールが複数のサービス機能で使用される）場合、そのモジュールをサービス機能対応にダウンロードせず、１回の通信でダウンロードすることで、処理の簡素化、回線の有効利用が可能となる。

例えば、複合機３０ａについていうと、モジュールａ、モジュールｂ、モジュールｃ、モジュールｂ、モジュールｄおよびモジュールｅをこの順序でダウンロードする代わりに、モジュールａ、モジュールｂ、モジュールｃ、モジュールｄ及びモジュールｅをこの順序でダウンロードしてもよい。
＜複合機の動作＞
本実施の形態に係るソフトウェア更新システムを構成する各複合機３０の端末制御部３１は、サーバ１０より送信されたアップデート用モジュールを受信等するため、以下の処理を実行する。

最初に端末制御部３１は、図５のステップＳ３１において、サーバ１０より送信された、自己の複合機のサービス機能に関する依存関係データベースを取得する。そして、続くステップＳ３３において、取得した依存関係データベースの内容を解析する。例えば、サービス機能を実現するために新たに受信した最新の依存関係データベースに記載されたモジュール構成の確認、既に複合機に格納されているモジュール構成との対比、各モジュールのバージョン更新状況の確認等を行う。

端末制御部３１は、ステップＳ３５において、複合機の操作部（ＵＩ部）３５が操作されて、ユーザより特定のサービス機能の優先的なアップデートの要求があるか否かを判断する。すなわち、優先して実現させたいサービス機能がある場合、サーバ１０に格納されたスケジュールファイルに記載された複数のモジュールのダウンロード順序に従わない優先的なモジュールのダウンロード要求の有無を判断する。

特定のサービス機能の優先的なアップデート要求がない場合、ステップＳ３７において、サーバ１０内のスケジュールファイルに記載された当初の順序に従ってモジュールをダウンロードする。続くステップＳ４１において、上記のステップＳ３７でダウンロードされたモジュールにおける依存関係の有無を判断する。

ステップＳ３７でダウンロードされたモジュールに依存関係がない場合、ステップＳ４５において、そのモジュールで実現されるサービス機能を無条件でアップデート（更新）する。

ステップＳ３７でダウンロードされたモジュールに依存関係がある場合には、ステップＳ４３において、サービス機能を実現するすべてのモジュールを受信したかどうかの判断とともに、それらのモジュールについて依存関係が満たされたか否かを判断する。

モジュール受信処理を繰り返した結果、すべてのモジュールを受信し、かつ、依存関係が満たされた場合、ステップＳ４５においてモジュールをアップデートしてサービス機能を更新する。

一方、後述するように、ユーザが複合機の操作部（ＵＩ部）３５を操作することで、特定のサービス機能の優先的なアップデートの要求があった場合（ステップＳ３５でＹＥＳ）、ステップＳ５１において、特定のサービス機能の優先的なアップデート要求がサーバ１０に送信される。そして、ステップＳ５３において、優先させたサービス機能を実現するモジュールをサーバ１０よりダウンロードする。

ステップＳ５５において、ステップＳ５３で受信した複数のモジュールについて、上述した依存関係を満たすか否か、すなわち、依存関係を満たすモジュールが揃ったか否かを判断する。依存関係が満たされた場合、続くステップＳ５７においてモジュールをアップデートして、優先させて実現するサービス機能を更新する。その後、ステップＳ３５に戻り、上記特定のサービス機能以外に実現を優先させたい他のサービス機能の有無を判断する。

ステップＳ３５において、実現を優先させる他のサービス機能があると判断されれば、上記のステップＳ５１〜Ｓ５７の処理を行い、実現を優先させたいサービス機能がないと判断された場合には、ステップＳ３７に進んで、当初のスケジュールにしたがった順序によるサーバ１０からのモジュール受信処理に移行する。

なお、複合機３０では、サーバ１０より受信した複数のモジュールの一部のモジュールのバージョンが最新バージョンでないことでモジュール間の依存関係が満たされない場合、その一部のモジュールについて更新後の最新バージョンのモジュールがダウンロードされるまで、これら複数のモジュールで実現されるサービス機能のアップデートを行わない。

上述したモジュールのアップデートにおいて、例えば、図８Ａに示すようにサービス機能Ｓを実現するためにモジュールｘとモジュールｙが必要であり、モジュールｙが、モジュールｘの内部に存在するオブジェクトｍを参照するような場合において、モジュールｙが参照しているオブジェクトｍを機能追加等のためオブジェクトｍ´に更新するだけならば、モジュールｘをモジュールｘ´に更新するだけでよく、モジュールｙを更新する必要はない。すなわち、モジュールｙがモジュールｘ´にあるオブジェクトｍ´を参照しても正常に動作するならば、モジュールｘ´とモジュールｙは依存関係がない。この場合、モジュールｘをモジュールｘ´に更新しても、モジュールｙはそのままでよい。

しかし、例えば、図８Ｂに示すようにモジュールｍ´に追加された機能を使用するためにモジュールｙをモジュールｙ´に更新する必要があるならば、モジュールｘ´とモジュールｙ´は依存関係を有することになる。つまり、モジュールｙがモジュールｘ´にあるオブジェクトｍ´を参照すると正常に動作しないが、モジュールｙ´がモジュールｘ´にあるオブジェクトｍ´を参照すれば正常に動作する場合、モジュールｘ´とモジュールｙ´は依存関係がある。よって、モジュールｘをモジュールｘ´に更新し、かつ、同時にモジュールｙをモジュールｙ´に更新する必要がある。

そこで、同一のサービス機能Ｓを実現するための全てのモジュールが相互に依存関係を有するとは限らないが、管理上、便宜的に、同一のサービス機能Ｓを実現するために必要なモジュール全てが相互に依存すると扱ってもよい。つまり、図８Ａに示す態様と図８Ｂに示す態様を区別して扱うことはシステムの運営上、煩雑となることから、図８Ａに示す態様を図８Ｂに示す態様と同様に扱っても問題はない。

依存関係について更に説明する。例えば、図８Ｃに示すようにサービス機能Ｓを実現するためにモジュールａ１、モジュールａ２、・・・、モジュールａｍが必要である場合、モジュールａ１、モジュールａ２、・・・、モジュールａｍは、サービス機能Ｓに関連して依存関係を有するという。ここで、図８Ｄに示すようにモジュールａ１がモジュールａ２に依存しているとしてもモジュールａ１がモジュールａ２に依存していないとしても、サービス機能Ｓを実現するためにモジュールａ１、モジュールａ２、・・・、モジュールａｍが必要であるならば、サービス機能Ｓに関連してこれらのモジュールは依存関係を有するという。

サービス機能Ｓのメインモジュールが、例えば、モジュールａ１であるならば、モジュールａ１は、直接的または間接的にモジュールａ２、・・・、モジュールａｍに依存するので、モジュールａ１、モジュールａ２、・・・、モジュールａｍは、サービス機能Ｓに関連して依存関係を有するといえる。

モジュールａ１がモジュールａ２に依存するとは、例えば、モジュールａ１で利用されているオブジェクトの実態がモジュールａ２に実装されていることをいう。この場合、モジュールａ１を実行するためには、モジュールａ２が必要となるので、モジュールａ１は、モジュールａ２に依存するという。

さらなる具体例として、例えば、図８Ｅに示すように課金モジュールａ１（Ｖｅｒ１．０）がコピーサービスＳ１には対応しているがファクシミリサービスＳ２には対応しておらず、課金モジュールａ１（Ｖｅｒ２．０）がコピーサービスＳ１およびファクシミリサービスＳ２に対応しているとする。

ここで、課金モジュールａ１（Ｖｅｒ２．０）が、課金モジュールａ１（Ｖｅｒ１．０）に対して上位互換性を有するものであるとする。したがって、利用されたコピーサービスＳ１に対して課金をするために課金モジュールａ１（Ｖｅｒ１．０）を利用することもできるし、課金モジュールａ１（Ｖｅｒ２．０）を利用することもできる。また、利用されたファクシミリサービスＳ２に対して課金をするためには、課金モジュールａ１（Ｖｅｒ１．０）を利用することはできないが、課金モジュールａ１（Ｖｅｒ２．０）を利用することはできる。

例えば、複合機を導入した際には、コピーサービスＳ１を付けてもファクシミリサービスＳ２を付加しなかったため、課金モジュールａ１（Ｖｅｒ１．０）が複合機にダウンロードされているとする。その後、この複合機にファクシミリサービスＳ２を付加するために、課金モジュールａ１（Ｖｅｒ１．０）を課金モジュールａ１（Ｖｅｒ２．０）に更新しても、利用されたコピーサービスＳ１に対して正常に課金をすることができる。この例では、モジュールｘと課金モジュールａ１に依存関係がないため、課金モジュールａ１をＶｅｒ１．０からＶｅｒ２．０に更新しても、モジュールｘを更新する必要はない。

したがって、ファクシミリサービスＳ２を新たに導入する場合、ファクシミリサービスＳ２に関連してモジュールの依存関係を管理すればよい（つまり、ファクシミリサービスＳ２における課金モジュールａ１とモジュールｙとの依存関係に留意すればよい）ことになる。特に、コピーサービスＳ１に関連するモジュールの依存関係は不要となる。

一方、課金モジュールａ１（Ｖｅｒ２．０）が、課金モジュールａ１（Ｖｅｒ１．０）に対して上位互換性を有しない場合には、コピーサービスに関連する他のモジュールのバージョンアップが必要となる。例えば、図８Ｆに示すようにモジュールｘと課金モジュールａ１との間に依存関係があり、課金モジュールａ１をＶｅｒ１．０からＶｅｒ２．０に更新するならば（課金モジュールａ１（Ｖｅｒ２．０）は課金モジュールａ１（Ｖｅｒ１．０）に対して上位互換性を有する）、モジュールｘの更新も必要になる。

したがって、ファクシミリサービスＳ２を新たに導入する場合、ファクシミリサービスＳ２における課金モジュールａ１とモジュールｙとの依存関係のみならず、課金モジュールａ１とモジュールｘとの依存関係にも留意が必要となる。つまり、課金モジュールａ１（Ｖｅｒ２．０）とコピーに関連した他のモジュールが依存関係を有することになる。課金モジュールａ１（Ｖｅｒ２．０）は、ファクシミリサービスＳ２に関連した他のモジュールとの間でも依存関係を有する。よって、ファクシミリサービスＳ２に関連した全てのモジュールとコピーサービスに関連した全てのモジュールは相互に依存関係を有することになる。つまり、複数サービスに跨がったモジュールが相互に依存関係を有することになる。

次に、上述した実施の形態の実施例について説明する。
＜実施例１＞
図９は、実施例１に係る機能アップデートを説明する図である。サーバ１０内には、複合機３０（ＭＦＰ１）用の依存関係データベース４１として、サービス機能Ｘを実現するモジュールａ，ｂ，ｃと、サービス機能Ｙを実現するモジュールｄが格納され、モジュールａ，ｂ，ｃ，ｄそれぞれが、Ｖｅｒ．１からＶｅｒ．２に更新される。依存関係データベース４１がサーバ１０よりＭＦＰ１にダウンロードされることで、ＭＦＰ１は、依存関係データベース４３を取得する。

サーバ１０は、回線容量等から、ＭＦＰ１に対して一度にダウンロードするデータ量を平滑化するため、図９に示すようにバージョンをＶｅｒ．２に更新したモジュールａ，ｄそれぞれをＭＦＰ１にダウンロードする。この場合、ＭＦＰ１において、サービス機能Ｘに関してモジュールａのバージョンのみが更新され、モジュールｂ，ｃについては、更新前のバージョンであるためモジュール間の依存関係が満たされない。

よって、モジュールａ，ｄがダウンロードされた時点では、ＭＦＰ１においてサービス機能Ｘは更新されず、サービス機能Ｙのみが更新される。その結果、ＭＦＰ１は、モジュールａ（Ｖｅｒ．１）、モジュールｂ（Ｖｅｒ．１）、モジュールｃ（Ｖｅｒ．１）に基づくサービス機能Ｘと、モジュールｄ（Ｖｅｒ．２）のみを必要とするサービス機能Ｙとを提供し続ける。
＜実施例２＞
図１０は、複合機において特定サービス機能の優先的なアップデート要求があった場合の機能アップデートを説明する図である。また、図１１は、アップデート要求時における操作部の画面表示例である。

例えば、複合機（ＭＦＰ１）においてサービス機能Ｘ，Ｙが実現される場合、図１１（ａ）に示すように表示部３５ｂには、あらかじめ決められたスケジュールに従って、サービス名が上から下へとアップデート（更新）順に表示される。ここでは、サービスＸが最も早い日時に更新され、その後、サービスＹが更新される。

複合機（ＭＦＰ１）において、サービスＸに優先させてサービスＹを先に実現させる場合、サービスＹが最も早い日時に更新され、次に、サービスＸが更新されるように、図１１（ａ）に示す表示部３５ｂ上の入力部（上下に分かれた２個の三角形のスクロールボタン）３５ａを操作してサービスＸとサービスＹを入れ替える。

その結果、図１１（ｂ）に示すように操作部（ＵＩ部）３５の表示部３５ｂにおいてサービスＸとサービスＹが入れ替わり、サービスＹが最も早い日時に更新され、その後、サービスＸが更新される旨が表示される。

特定のサービス機能を優先的に実行させる変更がなければ、図１０（ａ）に示すように、モジュールａ，ｂがダウンロードされた後、モジュールｃ，ｄがダウンロードされ、複合機（ＭＦＰ１）においてサービスＸ、サービスＹの順に更新される。一方、ユーザの選択により、特定のサービス機能の優先的なアップデート要求があった場合、図１０（ｂ）に示すように、モジュールｃ，ｄが他のモジュールａ，ｂよりも先にダウンロードされ、複合機（ＭＦＰ１）においてサービスＹが他のサービスＸに優先して更新される。
＜実施例３＞
図１２は、複合機において同一サービス機能内の特定機能の優先的なアップデート要求があった場合の機能アップデートを説明する図である。また、図１３は、そのようなアップデート要求時における操作部の画面表示例である。

ここでは、複合機（ＭＦＰ１）においてサービス機能Ｘと、サービス機能Ｙに含まれる機能Ｖ，Ｗとを実現する場合を想定する。機能の優先的なアップデート要求がない場合、図１３（ａ）に示すように表示部３５ｂには、あらかじめ決められたスケジュールに従った順でサービス機能が表示される。その結果、サービスＸが最も早い日時に更新され、その後、サービスＹ（機能Ｖ）、サービスＹ（機能Ｗ）の順に更新される。

一方、複合機（ＭＦＰ１）において、サービスＸに優先させてサービスＹ（機能Ｖ）を先に実現させる場合、ユーザは、表示部３５ｂ上の入力部（スクロールボタン）３５ａを操作して、サービスＸとサービスＹ（機能Ｖ）とを入れ替える。その結果、図１３（ｂ）に示すように操作部（ＵＩ部）３５の表示部３５ｂには、サービスＹ（機能Ｖ）が最も早い日時に更新され、その後、サービスＸ、サービスＹ（機能Ｗ）の順に更新される旨が表示される。

すなわち、サービス機能内の特定の機能を他に優先させて実行させる変更がなければ、図１２（ａ）に示すように、サービスＸに係るモジュールａ，ｂがダウンロードされた後、モジュールｃ，ｄ，ｅ，ｆがダウンロードされる。これにより、複合機（ＭＦＰ１）においてサービスＸ、サービスＹ（機能Ｖ）、サービスＹ（機能Ｗ）の順に更新される。

一方、ユーザの選択により、特定の機能を他のサービス機能より優先的にアップデートする要求があった場合には、図１２（ｂ）に示すように、サービスＹ（機能Ｖ）に係るモジュールｃ，ｄが他のモジュールａ，ｂ，ｅ，ｆよりも先にダウンロードされ、複合機（ＭＦＰ１）においてサービスＹ（機能Ｖ）が他のサービスに優先して更新される。

なお、上記実施例２のように特定のサービス機能の優先的なアップデートを要求する際、あるいは実施例３のように、一サービス機能内の特定の機能の優先的なアップデートを要求する際、複合機の操作部（ＵＩ部）を操作してサービス機能を指定する態様に限定されず、例えば、優先的に更新したいサービス機能を構成するモジュールそのものを指定可能にしてもよい。

図１４は、本発明に係るソフトウェア更新システム全体の詳細構成を示す図である。上述したようにソフトウェア更新システムは、通信ネットワーク（ＮＷ）２０を介して相互に通信可能に接続されたサーバ１０と、複数の複合機（ＭＦＰ）３０ａ〜３０ｎとを含んで構成される。

サーバ１０は、ＣＰＵ５１、通信制御部５２、および記憶部５３を含んで構成される。記憶部５３において、第１記憶部５４には、複合機でのサービス機能の実現に必要なソフトウェアモジュールが格納され、第２記憶部５５には、モジュール間の依存関係を示す依存関係情報が格納され、第３記憶部５６には、ソフトウェアモジュールの取得スケジュールであるスケジュールファイルが格納されている。

複合機（ＭＦＰ１）は、ＣＰＵ６１、通信制御部６２、記憶部６３等を含んで構成される。複合機（ＭＦＰ１）において、サーバ１０よりダウンロードされ、ソフトウェアモジュール取得部７１によって取得されたソフトウェアモジュールは、記憶部６３内の第１記憶部６４に格納される。同様に、サーバ１０よりダウンロードされた依存関係情報は、記憶部６３内の第２記憶部６５に格納される。

判断部７２は、複合機（ＭＦＰ１）においてサービス機能の実現に必要な依存関係を充足する全てのソフトウェアモジュールが取得されたかどうかを判断する。これら全てのソフトウェアモジュールが取得された場合、ソフトウェア更新部７３は、それらのソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを更新する。

ユーザインタフェース（ＵＩ）７４は、ユーザより、特定のサービス機能の実現を優先させる要求があった場合、ソフトウェアモジュールの取得スケジュールを変更するための情報入力部７５と情報表示部７６を含んで構成される。

以上説明したように、サービス機能に対応するモジュールを相互に依存関係を有する複数のモジュールに分割した上で、複合機にダウンロードされた複数のモジュールが依存関係を満たしてから、複数のモジュールに基づいてソフトウェアをアップデートする構成とした。したがって、複数のモジュールを分散してサーバ装置から複合機にダウンロードできるので、ダウンロードにおけるデータ量を分散化かつ平滑化して、回線リソースの枯渇を防ぐとともに、限られた容量の回線を介したアップデートを迅速かつ確実に行うことができる。

また、複数の機能モジュールの依存関係を確認した後、安全かつ優先順位を指定してアップデートすることで、モジュール間の不整合を回避しながら、サービス機能の実現に必要なモジュールが揃う前にアップデートされる不具合を回避できる。

更には、特定のモジュールを他のモジュールに優先してダウンロードするようスケジュール変更が可能に構成することで、ユーザが必要とするサービス機能を迅速に実行できる。

よって、ソフトウェア更新システムの運用管理者の負担が軽減される。また、サーバが管理する複合機の数が多いほど、また、複合機がより遠隔地に配置されているほど、これらの効果が顕著に現れる。

上述した実施の形態では、ユーザが特定のサービス機能の優先的なアップデートを要求する場合、複合機より、そのサービス機能を指定しているが、これに限定されない。例えば、複合機において、更新するサービス機能を構成する複数のモジュールの１つ、あるいはそれ以上のモジュールが指定されると、サーバが、自身の格納する依存関係に基づいて、その依存関係を満たす他のモジュールすべてをダウンロードする構成としてもよい。

こうすることで、サービス機能と無関係なモジュールの更新を回避して、そのサービス機能の実現に必要なすべてのモジュールを確実にダウンロードできる。

さらには、モジュールの取得スケジュールが経過後においても、サーバの記憶部に格納されているソフトウェアモジュールのうち未取得のソフトウェアモジュールを取得できるようにしてもよい。また、モジュールの取得スケジュールが経過後において、その取得スケジュールを変更できるようにしてもよい。

これによりユーザは、取得スケジュールが終了しても、取得し損なったソフトウェアモジュールをダウンロードして、所望のサービス機能を実現できる。

また、複合機に、サーバに格納されたソフトウェアモジュールと、それらのソフトウェアモジュール間の依存関係を示す情報と同じソフトウェアモジュールと依存関係情報とを格納する外部記憶部を設け、複合機において、外部記憶部より読み出した依存関係を満たすソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを更新するようにしてもよい。

こうすることで、サーバに障害等が発生した場合においても、外部記憶部に格納したデータをバックアップデータとして使用して、サービス機能の更新を円滑に行うことができる。

なお、上記のサーバおよび複合機は、ハードウェア、ソフトウェア、またはこれらの組合わせにより実現することができる。また、上記のサーバおよび複合機により行なわれるソフトウェア更新方法も、ハードウェア、ソフトウェア、またはこれらに組合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。

プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ(Programmable ROM)、ＥＰＲＯＭ(Erasable PROM)、フラッシュＲＯＭ、ＲＡＭ(Random Access Memory）を含む。

また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

本発明は上記実施の形態に限定されず、発明の趣旨を逸脱しない範囲で適宜変更することが可能である。上述した実施の形態は例示にすぎず、限定的に解釈されるべきではない。本発明の範囲は特許請求の範囲によって示すものであって、明細書本文にはなんら拘束されない。さらに、特許請求の範囲の均等範囲に属する変形や変更はすべて本発明の範囲内のものである。

１ ソフトウェア更新システム
１０ サーバ
１１ サーバ制御部
１２ 記憶部
１９ 通信制御部
２０ 通信ネットワーク（ＮＷ）
３０ａ〜３０ｎ 複合機（ＭＦＰ）
３１ 端末制御部
３３ 記憶部
３５ 操作部（ＵＩ部）
３５ａ 入力部
３５ｂ 表示部
３９ 通信制御部

?

Claims (17)

1. 搭載された１またはそれ以上のソフトウェアモジュールにより所定の各サービス機能を実現する１またはそれ以上の端末装置と、サーバ装置とが通信ネットワークを介して通信可能に接続されたソフトウェア更新システムであって、
   前記サーバ装置は、
   少なくとも前記ソフトウェアモジュールと、前記ソフトウェアモジュール間の依存関係を示す情報と、前記端末装置による前記ソフトウェアモジュールの取得スケジュールを示すスケジュールファイルとを記憶する記憶手段を備え、
   前記端末装置は、
   前記サーバ装置より前記取得スケジュールに従って前記ソフトウェアモジュールを取得する取得手段と、
   前記依存関係を充足するために必要な全てのソフトウェアモジュールが前記取得手段により取得されたか否かを判断する判断手段と、
   前記判断手段により前記依存関係を充足するために必要な全てのソフトウェアモジュールが取得されたと判断された場合、該ソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを更新する更新手段と、
   を備えることを特徴とするソフトウェア更新システム。
2. 前記依存関係は単一のサービス機能に関連するソフトウェアモジュール間の関係を示す情報であることを特徴とする請求項１に記載のソフトウェア更新システム。
3. 前記依存関係は複数のサービス機能に跨って関連するソフトウェアモジュール間の関係を示す情報であることを特徴とする請求項１に記載のソフトウェア更新システム。
4. 前記スケジュールファイル内の前記ソフトウェアモジュールの取得スケジュールを変更する変更手段を更に備え、
   前記端末装置は、前記変更後の取得スケジュールに従って特定のソフトウェアモジュールを他のソフトウェアモジュールに優先して取得することを特徴とする請求項１に記載のソフトウェア更新システム。
5. 前記変更手段は、前記端末装置に設けた情報入力部と情報表示部を含むユーザインタフェースを備えることを特徴とする請求項４に記載のソフトウェア更新システム。
6. 前記変更手段により、優先して実現するサービス機能を指定することを特徴とする請求項５に記載のソフトウェア更新システム。
7. 前記変更手段により、優先して実現するサービス機能を構成する１またはそれ以上のソフトウェアモジュールを指定することを特徴とする請求項５に記載のソフトウェア更新システム。
8. 前記１またはそれ以上のソフトウェアモジュールが指定されると、該指定されたソフトウェアモジュールとそのソフトウェアモジュールと前記依存関係にある１またはそれ以上のソフトウェアモジュールが優先して取得されることを特徴とする請求項７に記載のソフトウェア更新システム。
9. 前記更新手段は、前記特定のソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを他のサービス機能に対応するソフトウェアに優先して更新することを特徴とする請求項４に記載のソフトウェア更新システム。
10. 前記端末装置は、前記依存関係を充足するために必要な全てのソフトウェアモジュールのうちの一部のソフトウェアモジュールが前記取得手段により取得されていない場合、前記サーバ装置より前記一部のソフトウェアモジュールを取得することを特徴とする請求項１に記載のソフトウェア更新システム。
11. 前記端末装置は、前記取得スケジュールが経過後において前記サーバ装置の前記記憶手段に格納されているソフトウェアモジュールのうち未取得のソフトウェアモジュールを取得する手段を更に備えることを特徴とする請求項１に記載のソフトウェア更新システム。
12. 前記変更手段は、前記取得スケジュールが経過後において前記ソフトウェアモジュールの取得スケジュールを変更することを特徴とする請求項１１に記載のソフトウェア更新システム。
13. 前記端末装置は、前記ソフトウェアモジュールと、該ソフトウェアモジュール間の依存関係を示す情報を格納する記憶手段を更に備え、
    前記更新手段は、前記記憶手段より読み出した前記依存関係を満たすソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを更新することを特徴とする請求項１〜３のいずれか１項に記載のソフトウェア更新システム。
14. 前記端末装置は、画像処理に係る複数の所定の機能を備えた複合機であることを特徴とする請求項１〜１３のいずれか１項に記載のソフトウェア更新システム。
15. ソフトウェア更新システムで利用されるサーバ装置であって、
    端末装置との通信を可能にする通信制御手段と、
    前記端末装置において実現される所定の各サービス機能に対応するソフトウェアモジュールを記憶する第１の記憶手段と、
    前記ソフトウェアモジュール間の依存関係を示す情報を記憶する第２の記憶手段と、
    前記端末装置における前記ソフトウェアモジュールの取得スケジュールを示すスケジュールファイルを記憶する第３の記憶手段と、
    を備え、
    少なくとも前記取得スケジュールに従って、少なくとも前記ソフトウェアモジュールおよび前記依存関係を示す情報を、前記通信制御手段を介して前記端末装置にダウンロードすることを特徴とするサーバ装置。
16. ソフトウェア更新システムで利用される端末装置であって、
    サーバ装置との通信を可能にする通信制御手段と、
    少なくとも、当該端末装置で実現する各サービス機能に対応するソフトウェアモジュールと、該ソフトウェアモジュール間の依存関係を示す情報とを、前記通信制御手段を介して前記サーバ装置より取得する取得手段と、
    前記各サービス機能の実現に必要な前記依存関係を充足するために必要な全てのソフトウェアモジュールが前記取得手段により取得されたか否かを判断する判断手段と、
    前記判断手段により前記依存関係を充足するために必要な全てのソフトウェアモジュールが取得されたと判断された場合、該ソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを更新する更新手段と、
    を備え、
    前記取得手段は、前記サービス機能に対応するソフトウェアモジュールを、少なくとも所定の取得スケジュールに従って取得することを特徴とする端末装置。
17. １またはそれ以上の端末装置と、サーバ装置とが通信ネットワークを介して通信可能に接続されたシステムにおけるソフトウェア更新方法であって、
    前記サーバ装置において、前記端末装置で実現される所定のサービス機能に対応する１またはそれ以上のソフトウェアモジュールと、前記ソフトウェアモジュール間の依存関係を示す情報と、前記端末装置による前記ソフトウェアモジュールの取得スケジュールを示すスケジュールファイルとを記憶する工程と、
    前記端末装置において、前記サーバ装置より前記取得スケジュールに従って前記ソフトウェアモジュールを取得する工程と、
    前記端末装置において、前記依存関係を充足するために必要な全てのソフトウェアモジュールが取得されたか否かを判断する工程と、
    前記端末装置において、前記依存関係を充足するために必要な全てのソフトウェアモジュールが取得されたと判断された場合、該ソフトウェアモジュールにより実現されるサービス機能に対応するソフトウェアを更新する工程と、
    を有することを特徴とするソフトウェア更新方法。
    ?

Images