JP2018120537A

JP2018120537A - 情報処理システム、情報処理ステムの制御方法およびそのプログラム。

Info

Publication number: JP2018120537A
Application number: JP2017013241A
Authority: JP
Inventors: 克也坂井; Katsuya Sakai
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2017-01-27
Filing date: 2017-01-27
Publication date: 2018-08-02
Anticipated expiration: 2037-01-27
Also published as: CN108366101B; CN108366101A; JP6584440B2; KR102235992B1; EP3355183A1; KR20180088583A; US20180217786A1; US10466942B2

Abstract

【課題】トップダウン型の指示を行うシステムにおいて、中間層における装置でのメッセージ処理プロセスを容易にする。【解決手段】情報伝達の階層構造に対応させてトピックも階層化しパブリッシュ／サブスクライブ型のメッセージ通信により情報伝達を行う。情報伝達の階層構造にあわせてサブスクライバ／パブリッシャを用意してメッセージ通信するが、承認プロセスが不要な場合はシステムがメッセージ通信を代行する。【選択図】図５

Description

本発明はネットワークに接続されている２つの装置間のデータ送受信に関しそのデータを仲介する情報処理システム、情報処理システムの制御方法および損プログラムに関する。

企業内のコンピュータへの更新ソフトウェアの配信を管理するためにアップデートサーバを階層化する技術が特許文献１で知られている。特許文献１は、ルート配信サーバと少なくとも１つの子配信サーバとを備え、各ルート配信サーバは子配信サーバに対して親サーバとして機能することができるような構成をとる。このため、各階層の配信サーバにて配信ポリシーを決めることで、各階層でのソフトウェア配信を制御できるようになる。

特開２００５−２５９１１４号公報

しかしながら特許文献１の技術では、配信されるデータの配信可否を判断したい管理者が複数いた場合、それぞれの管理者が更新サーバを構築することになるためコストが増大する虞、および／または配信システムの構築が容易ではない虞があった。本願発明では、トップダウン型の指示を行うシステムにおいて、中間層における装置でのメッセージ処理プロセスを容易にすることを目的とする。

本願発明の課題を解決する情報処理システムは、テナントの作成指示に従い前記テナントが作成されたことに応じて、前記テナントと他のテナントとの階層関係を反映したメッセージ属性を生成する生成手段と、生成された前記メッセージ属性を設定する設定手段と、特定のテナントからメッセージを受信する受信手段と、前記設定手段により設定された子テナントのメッセージ属性を基に、前記特定のテナントの直下に配置された前記子テナントに対し受信された前記メッセージを送信する送信手段を有することを特徴とする。

トップダウン型の指示を行うシステムにおいて、中間層における装置でのメッセージ処理プロセスを容易にすることが可能となる。

システム構成を示す図システム構成要素のハードウェア構成を示すブロック図ソフトウェアモジュールを示す図更新システム上で管理される各テナント／デバイス情報の例テナント部を追加する際の処理手順を示すシーケンス画像形成装置を追加する際の処理手順を示すシーケンス承認プロセスの要否を変更する際の処理手順を示すシーケンス新バージョン適用要求を画像形成装置に通知する際のシーケンス画像形成装置の処理結果を受け取る際のシーケンスファームウェア更新に関連する操作画面の例

［実施例１］
実施例１では、印刷機能を有するＭＦＰ（Ｍｕｌｔｉ−Ｆｕｎｃｔｉｏｎ−Ｐｅｒｉｐｈｅｒａｌ）を例に本願発明の解決手段を説明する。近年、ＭＦＰを始めとするエンタープライズ向けデバイスは、バグ修正や機能追加等で一度市場に出た後も継続的にファームウェアが更新されるようになっている。このようなエンタープライズ向けデバイスは、デバイス製造会社（ファームウェア提供元）と利用者の関係の中間に、販売会社、ディーラーのサポート担当者および企業のデバイス管理者などのデバイス管理責任者が介在することが多い。よって、デバイスのファームウェアを更新する際も、デバイス利用者個人のみの判断で決まるのではなく、その間に存在する各責任者の承認の後に更新を実施することが望ましい。

例えば、デバイス製造会社からセキュリティ関連のファームウェアの更新バージョンがリリースされた場合を考える。販売会社としてはサポート体制が整うまでは更新を行わせたくない為、すぐには顧客に対して更新バージョンをリリースしたくない。また、顧客企業の管理者としては、社内システムとの連携で問題が発生しないことが確認できるまではファームウェアを更新させたくない。このため、デバイス製造会社がリリースしたファームウェアは、販売会社および顧客企業の承認後に実際にデバイスに適用されることになる。しかしながら、先に述べた様に配信システムの構築が容易ではない虞があり、承認プロセスの実現には非常に手間がかかる。

次に、上述した課題を解決するのに適した実施形態について図面を用いて説明する。本実施形態に係る画像形成装置のファームウェア更新システムは、図１に示すような構成のネットワーク上に実現される。１００はＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ（ＷＡＮ１００）である。１０１は、各構成要素を接続するＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ（ＬＡＮ１０１）である。

ブローカ２００は、ＭＱＴＴと呼ばれる通信プロトコルを用いたデータ通信を行うためのサーバである。ＭＱＴＴは、パブリッシュ／サブスクライブモデルにてメッセージと呼ばれるデータを送受信する通信プロトコルである。パブリッシュ／サブスクライブモデルは、メッセージ送信者（以下、パブリッシャと呼ぶ）からメッセージ受信者（以下、サブスクライバと呼ぶ）に対して、メッセージ仲介者（ブローカ２００）を介してメッセージを配信するモデルである。サブスクライバは、予め受信したいメッセージ属性（以下、トピックと呼ぶ）をブローカに設定（以下、サブスクライブと呼ぶ）しておく。ブローカにより設定された後、サブスクライバはブローカ２００とインターネットを介して確立したネットワークセッションを維持し続ける必要がある。無論、常にネットワークセッションを維持し続ける必要はないが、リアルタイムでメッセージを処理したい場合は高頻度でブローカ２００とネットワーク接続する必要がある。パブリッシャがトピックを指定してブローカに対してメッセージを送信すると、ブローカはそのトピックをサブスクライブしているサブスクライバに対してメッセージを配信する。

トピックは、分離文字（”／”）を使用して階層構造で表現することができる。また、サブスクライブ時のトピックには特殊文字（ワイルドカード）を含めることで、一度に複数のトピックへのサブスクライブが可能である。例えば、“／ｆｏｏ／＃”というトピックをサブスクライブしておくと、“／ｆｏｏ／ｂａｒ“や”／ｆｏｏ／ｂａｒ／ｂａｚ”などのトピックにパブリッシュされたメッセージを受信可能である。また、サブスクライバがサブスクライブしているトピックについてのメッセージの受信を止めたい場合は、購読解除（以下、アンサブスクライブと呼ぶ）することもできる。購買解読するために、サブスクライバはブローカ２００とインターネットを介して確立したネットワークセッションを切断する必要がある。サブスクライバはネットワークセッションを切断することでトピックにパブリッシュされたメッセージを受信できなくなる。トピックをサブスクライブするサブスクライバ―がいない場合、トピックを削除して設定を解除することも可能である。

ブローカ２００は、トピック毎に最後にパブリッシュされたメッセージを保持しておき、新たなサブスクライバが追加された時に最後にパブリッシュされたメッセージを追加されたサブスクライバに送信する機能（以下、リテインと呼ぶ）も備える。これによりサブスクライバはサブスクライブした時点での最新の情報を取得することが可能となっている。なお、実施例１ではＭＱＴＴを前提としたシステムになっているが、ブローカ２００のような仲介装置を用い、データを送信する装置とデータを最終的に受信する装置の２点間の装置におけるデータ送受信を実現するデータ通信プロトコルであれば何でも良い。

更新管理サーバ３００は、ファームウェア更新に関わるメッセージを制御するためのサーバである。更新管理サーバ３００は、画像形成装置５００の販売やサポートを行っている販売会社／ディーラーや、画像形成装置を導入している顧客企業と言ったテナント毎にテナント部７２０を備えている。テナント部７２０は、各販売会社や顧客企業の管理者からの承認指示を受けてファームウェア更新に関するメッセージ処理を行う機能であり、端末４００などからの指示を受け更新管理サーバ３００内で動的に実現される機能である。承認プロセスが不要な販売会社や顧客企業については、対応するテナント部で処理を行わずに更新管理サーバ３００内の別のソフトウェア機能がメッセージ処理を代行する。なお、実施例１においては更新管理サーバ３００内にテナント部７２０を配置し、販売会社や顧客企業からの承認プロセスを行う構成としているが、別のサーバを立てテナント部で行う処理を実行する構成としてもよい。その別のサーバが既存のサーバであればサーバ構築のコスト面の課題は解消することになり、ブローカ２００を利用することで承認プロセスも容易に可能となる。

４００ａおよび４００ｂはＰＣやスマートフォンに代表される情報端末でありＷｅｂブラウザ４０１が組み込まれている。デバイス製造会社や販売会社などのファームウェア更新担当者は、Ｗｅｂブラウザ４０１を利用して、更新管理サーバ３００に対して指示を出す。４００ａはデバイス製造会社および販売会社の担当者が利用する端末の接続の例であり、４００ｂは、画像形成装置５００を利用している顧客企業の担当者が利用する端末の接続の例である。この例はあくまで一例であり、ネットワーク通信可能な状態で接続されていればどこに存在しても良い。そのため、以降の説明では４００ａと４００ｂを区別せずに端末４００として説明する。また、実施例１では更新管理サーバ３００への指示をＷｅｂブラウザ４０１を介して行う構成としているが、専用のアプリケーションを利用する構成でもよい。

５００は、ＭＦＰと言った画像形成装置である。画像形成装置５００は、ブローカ２００からファームウェアの更新指示を受けると、受信した情報に基づいて自動的にファームウェアを更新する機能を備える。

ブローカ２００および更新管理サーバ３００は１台の情報処理装置で構成されているように図１では図示されているが、複数台の情報処理装置でブローカ２００および更新管理サーバ３００を構成する形態も考えられる。本願発明で情報処理システムと称した場合、１台、または複数台の情報処理装置で構成されたシステムを示すものとする。

図２は、ブローカ２００、更新管理サーバ３００、端末４００、画像形成装置５００のハードウェア構成の一例を示す図である。図２（ａ）に示されるハードウェアブロック図は、ＰＣ等の一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の各サーバ及び端末には一般的な情報処理装置のハードウェア構成を適用できる。

以下、図２（ａ）のハードウェア構成を、ブローカ２００のハードウェア構成とした場合を例に説明する。ＣＰＵ２０１は、ＲＯＭ２０３或いはハードディスク（ＨＤ）等の外部記憶装置２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行し、システムバス２０４に接続される各ブロックを制御する。本願発明におけるＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。

キーボードコントローラ（ＫＢＣ）２０５は、キーボード２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は、各種データを記憶するハードディスク（ＨＤ）等の外部記憶装置２１１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２０８は、ＷＡＮ１００、ＬＡＮ１０１、もしくは公衆回線を介して接続された他の機器との通信制御処理を実行する。後述する説明においては、特に断りのない限り、ブローカ２００における実行のハード上の主体はＣＰＵ２０１であるものとする。そして、ＣＰＵ２０１が外部記憶装置２１１等に記憶されているアプリケーションプログラムを実行することにより、後述するブローカ２００のソフトウェア構成及びシーケンス図におけるブローカ２００の処理が実現される。

更新管理サーバ３００、端末４００のハードウェア構成についても上述した図２（ａ）の通りである。即ち、それぞれのＣＰＵ２０１がそれぞれの外部記憶装置２１１等に記憶されているアプリケーションプログラムを実行することにより、それぞれの後述するソフトウェア構成及びシーケンス図における処理が実現される。

図２（ｂ）は画像形成装置５００のハードウェア構成を示す。上述した図２（ａ）とほぼ同様の構成であるため差分だけを説明する。画像形成装置５００は、キーボードコントローラ（ＫＢＣ）２０５やＣＲＴコントローラ（ＣＲＴＣ）２０６を備えず、スキャナＩ／Ｆ制御部２３０、プリンタＩ／Ｆ制御部２３１、パネル制御部２３２を備える。スキャナＩ／Ｆ制御部２３０は、原稿からの画像データ入力を行うためにスキャナ２３３を制御する。スキャナ２３３は、原稿を読み込み画像データを生成するためのデバイスである。

プリンタＩ／Ｆ制御部２３１は、画像データを印刷するためにプリンタ２３４を制御する。プリンタ２３４は、画像データを紙に出力するためのデバイスである。パネル制御部２３２は、操作パネル２３５を制御し、各種情報の表示、ユーザからの指示入力を受ける。操作パネル２３５は、ディスプレイ、タッチパネル、ハードキーから構成され、各種設定画面を表示したり、ユーザからの指示を受けたりするためのデバイスである。画像形成装置５００においても実行のハード上の主体はＣＰＵ２０１である。ＣＰＵ２０１が、外部記憶装置２１１に記憶されているファームウェアやアプリケーションプログラムなどを実行することにより、後述する画像形成装置のソフトウェア構成およびシーケンス図における画像形成装置５００の処理が実行される。

図３は、実施例１に係るブローカ２００、更新管理サーバ３００および画像形成装置５００のそれぞれのソフトウェア構成を示す図である。各々がこれらソフトウェア構成に含まれる各種モジュールを実行することでサービスや機能を提供する。本実施形態におけるファームウェア更新システム内の各構成要素が有するソフトウェア構成に含まれる各種モジュールは、各装置のＣＰＵ２０１がＲＡＭ２０２にロードされたソフトウェアプログラムを実行する事で実現される。

ブローカ２００は、ＭＱＴＴサーバモジュール６００を備える。ＭＱＴＴサーバモジュール６００は、パブリッシャからパブリッシュされたメッセージを受信し、受信されたメッセージをサブスクライバに配信するモジュールである。実施例１においては、更新管理部７００、テナント部７２０および画像形成装置５００のそれぞれがパブリッシャおよびサブスクライバとして機能する。また、実施例１において、ＭＱＴＴサーバモジュール６００は更新管理サーバ３００からの要求に従いサブスクライブし、かつパブリッシュするために必要なトークンの発行も行う。ここで発行されるトークンは、ユーザが認証されているか否かを検証するためのトークンである。サブスクライブやパブリッシュされた際にこのトークンを検証することで第三者によって不正にサブスクライブされたりパブリッシュされたりすることを防ぐことができる。

更新管理サーバ３００は、更新管理部７００、テナント部７２０を備える。更新管理部７００は、デバイス製造会社の担当者が端末４００から送信したファームウェア更新の通知を受け、ブローカ２００を介して各テナント部や画像形成装置に通知する制御を行う役割を担う。更新管理部７００は、ＭＱＴＴ通信モジュール７０１、テナント管理モジュール７０２および認証モジュール７０３から構成される。ＭＱＴＴ通信モジュール７０１は、ブローカ２００に対してパブリッシュすることで他のテナントまたは画像形成装置５００へメッセージを送信する。また、ＭＱＴＴ通信モジュール７０１は、ブローカ２００に対してサブスクライブすることで他のテナントまたは画像形成装置５００からのメッセージを受信も行う。

テナント管理モジュール７０２は、販売会社や顧客企業の追加や削除にあわせて、それぞれに対応するテナント部７２０の生成や削除を行う。また、各テナントにおいてファームウェア更新時の承認を必要とするか否かの情報の管理も行う。さらに、管理者が端末から送信したファームウェア更新の通知を受信し、テナント部に更新のメッセージを通知するためにＭＱＴＴ通信モジュール７０１を介してブローカ２００にメッセージをパブリッシュする機能を備える。また、各テナント部での承認が不要な場合には、各テナント部に代わりメッセージ処理を代行する機能も備える。承認の要不要は動的に切り替えることができる。認証モジュール７０３は、処理の要求元ユーザの認証を行う機能を備える。実施例１では、認証モジュール７０３がユーザＩＤとパスワードを受け取って認証することを想定しているが、これに限らず生体情報等様々な認証情報を用いて認証することができる。

テナント部７２０は、販売会社や顧客企業の承認指示を受けてメッセージ処理を行うためのものであり、ＭＱＴＴ通信モジュール７２１、テナント処理実行モジュール７２２を備える。ＭＱＴＴ通信モジュール７２１は、ブローカ２００に対してパブリッシュすることで他のテナントまたは画像形成装置５００へメッセージを送信する。また、ＭＱＴＴ通信モジュール７２１は、ブローカ２００に対してサブスクライブすることで他のテナントまたは画像形成装置５００からのメッセージを受信する。テナント処理実行モジュール７２２は、販売会社や顧客企業の担当者に対してファームウェア更新の承認画面を提供する他、承認画面で承認指示された場合に承認プロセスを行う。また、テナント処理実行モジュール７２２はＭＱＴＴ通信モジュール７２１を介してブローカ２００経由で各種メッセージ通信を行う。

画像形成装置５００は、ＭＱＴＴ通信モジュール８００およびファームウェア更新モジュール８０１を備える。ＭＱＴＴ通信モジュール８００は、ブローカ２００に対してパブリッシュすることで他のテナントまたは画像形成装置５００へメッセージを送信する。また、ＭＱＴＴ通信モジュール８００は、ブローカ２００に対してサブスクライブすることで他のテナントまたは画像形成装置５００からのメッセージを受信する。ファームウェア更新モジュール８０１は、ＭＱＴＴ通信モジュール８００経由でファームウェア更新メッセージを受け、ファームウェアの更新する機能を備える。また、ファームウェアを更新後に更新結果を送信する機能も備える。以上、本願発明を実施する上で必要となるソフトウェア機能になる。

次に、テナント管理モジュール７０２が管理する各テナント部の情報（以下、テナント情報と呼ぶ）について図４を用いて説明する。テナント情報はツリー構造で管理され、実際の販売会社や顧客企業の階層関係を反映した構造で管理される。実施例１では、デバイス製造会社の下に２つの販売会社が存在し、１つ目の販売会社の下には１つの顧客企業が存在し、２つ目の販売会社の下には１つのディーラーが存在し、さらにディーラーの下に顧客企業が存在する例を想定している。図４はその階層関係をツリー構造で表現した図である。例えば、デバイス製造会社は販売会社の親テナントであり、その販売会社はデバイス製造会社の子テナントの関係にある。同様に、２つ目の販売会社はディーラーの親テナントであり、ディーラーは販売会社の子テナントとなる。

９００はルートノードでありテナント情報を管理するための一番大元の情報であり、デバイス製造会社の階層に対応する。ルートノード９００は、ＩＤ９０１、要求送信用トピック９０２、子ノード数９０３、ノード９０４の各情報を含む。ＩＤ９０１は、ノードを識別するための識別子である。要求送信用トピック９０２は、更新管理部７００がデバイス製造会社の端末４００からバージョン更新の要求を受けた時に、メッセージをパブリッシュする際に指定するトピックを示す。子ノード数９０３は、ルートノード９００の直下に位置するテナントの数を示す。前述のように図４は２つの販売会社が存在する例であるため、ルートノードの下にはそれぞれの販売会社に対応する２つのテナント部が存在している。ノード９０４は、ルートノードの下に位置する各テナントのテナント情報を格納したノードへのポインタの配列を保持している。

１０００、１０１０、１０２０、１０３０、１０４０はテナント情報を格納したノードである。ＩＤ１００１はテナント情報を格納したノードを識別するための識別子である。要求受信用トピック１００２は、ブローカ２００からファームウェア更新の要求メッセージを受けるためのトピックであり、テナント部はこのトピックに対してサブスクライブを行う。このトピックは、自テナントの一階層上の直上にあるテナントを指定するトピックパスになっている。即ち、子テナントのテナント情報には直上にあるテナントからのメッセージをサブスクライブするための情報が含まれることになる。

要求送信用トピック１００３は、ファームウェア更新の要求を承認した後に、ファームウェア更新要求メッセージをパブリッシュする際に指定するトピックを示す。このトピックは、自テナントに相当するトピックパスになっている。このようなトピックパスにパブリッシュ／サブスクライブする構成を採ることにより、自分に対応するパスにパブリッシュすることで自分の配下に位置するテナント部を送信先としメッセージを配信することが可能となる。これにより、自テナントの直下に配置されたテナント部に対してメッセージを送信することが可能になる。

応答受信用トピック１００４は、ファームウェア更新の要求を受けた画像形成装置５００の処理結果を受信するためのトピックである。このトピックは自テナントに対応するトピックパスより下のパスについてワイルドカードを指定するようになっている。そのため、自テナントの配下にある画像形成装置全ての処理結果を受信できるようになっている。

承認要否情報１００５は、そのテナント部に対応する会社がファームウェア更新の要求に対して承認プロセスを必要とするか否かを示す情報である。この情報がｔｒｕｅである場合、テナント部はファームウェア更新通知メッセージを自ら受信し、テナント部に対応する会社の担当者からのファームウェア更新許可の指示を受け、下の階層にファームウェア更新通知を送信するように制御する。

一方、承認要否情報１００５がｆａｌｓｅである場合、テナント部ではファームウェア更新要求に関する処理を行わず、更新管理サーバ３００の更新管理部７００が代理で処理を行うようになる。子ノード数１００６は、そのテナントの直下に位置するテナントの数を示す。前述したように２つの販売会社の下にはそれぞれ顧客企業とディーラーが存在する前提である。よって図４で示した例では、／ｓｙｓｔｅｍ／ｓａｌｅｓ１の下に／ｓｙｓｔｅｍ／ｓａｌｅｓ１／ｃｕｓｔｏｍｅｒ１が存在し、／ｓｙｓｔｅｍ／ｓａｌｅｓ２の下に／ｓｙｓｔｅｍ／ｓａｌｅｓ２／ｄｅａｌｅｒ１が存在するという構造になり、テナント間の階層関係はトピックパスに反映される形となる。

ノード１００７は、そのテナントの直下に位置するテナントのテナント情報を格納したノードへのポインタの配列が格納される。実施例１においては、販売会社の下に顧客企業が存在する構成および販売会社の下にディーラーがいてさらにその下に顧客企業が存在する構成の例を示している。しかしながら、テナントの構成は図示したテナントに限られるものではなく、また、図示した階層構造よりさらに深い階層構造になっていてもよい。

図５は、更新管理サーバ３００においてテナント部を追加する際のシーケンスを示した図である。図５（ａ）は、そのテナント部に対応する会社にて承認プロセスを行う場合のシーケンスであり、その会社の上位の会社の管理者が端末４００において更新管理サーバ３００にテナント部の追加を指示した場合のフローを示している。デバイス製造会社が販売会社に対応するテナント部を追加する場合や、販売会社が顧客企業に対応するテナント部を追加する場合などが該当する。以下ではデバイス製造会社が販売会社に対応するテナント部（／ｓｙｓｔｅｍ／ｓａｌｅｓ１）を追加する場合を例に説明する。

まず、デバイス製造会社の担当者が端末４００上のＷｅｂブラウザ４０１にてユーザＩＤとパスワードを入力すると、Ｓ１．１にてＷｅｂブラウザ４０１は入力された情報を認証モジュール７０３に送信する。実施例１では、認証のための情報としてユーザＩＤとパスワードを用いるが、生体情報など他の情報を利用するようにしてもよい。認証モジュール７０３は端末４００からユーザＩＤとパスワードを受け取ると、Ｓ１．２にて受信したユーザＩＤとパスワード情報を照合し認証処理を行う。

認証に成功するとＳ１．３にて端末４００はテナント管理モジュール７０２に対してテナント追加要求を送信する。テナント追加要求には、テナントの親のＩＤ、追加したいテナントのＩＤおよび承認要否情報を含む。ここでは、デバイス製造会社が販売会社（“／ｓｙｓｔｅｍ／ｓａｌｅｓ１”）を追加する想定であるため、親のＩＤとして”／ｓｙｓｔｅｍ”を、追加したいテナントのＩＤとして”／ｓｙｓｔｅｍ／ｓａｌｅｓ１”を送信する。また、図５（ａ）は販売会社にて承認プロセスを行う場合のシーケンスであるため、承認要否情報として”ｔｒｕｅ”を送信する。テナント管理モジュール７０２は、Ｓ１．４にて端末４００からテナントの作成指示を受けるとテナント部を生成する。

テナント部の生成に成功するとテナント管理モジュール７０２は、Ｓ１．５にて既存のテナント情報の更新を行う。具体的にはＳ１．４で受け取った情報を基に図４で示したテナント情報を保持するノードを生成して、親ノードの下に追加する。テナント情報の更新が完了するとテナント管理モジュール７０２は、Ｓ１．６にて、Ｓ１．４で生成したテナント部のテナント処理実行モジュール７２２に対して初期化要求を出す。この際、初期化要求とともにＳ１．５で生成したテナント情報および、承認要否情報として“ｔｒｕｅ”も通知する。

テナント処理実行モジュール７２２は、テナント初期化要求を受け取るとＳ１．７にてＭＱＴＴサーバモジュール６００に対してトークン取得要求を出す。ＭＱＴＴサーバモジュール６００はトークン取得要求を受け取るとトークンを作成し、Ｓ１．８にてテナント処理実行モジュール７２２に送信する。

テナント処理実行モジュール７２２は、受信した要否情報が“ｔｒｕｅ”であるため、トークンを受信するとＳ１．９にてＭＱＴＴ通信モジュール７２１のサブスクライブ要求ＡＰＩを呼び出す。この際、Ｓ１．６で受信したテナント情報に含まれる要求受信用トピックを指定する。ＭＱＴＴ通信モジュール７２１は、サブスクライブ要求ＡＰＩが呼び出されるとＳ１．１０にてＭＱＴＴサーバモジュール６００に対してサブスクライブ要求を送信する。この時、Ｓ１．８で受信したトークンを一緒に送信する。ＭＱＴＴサーバモジュール６００はサブスクライブ要求およびトークンを受信すると、Ｓ１．１１にて受信したトークンを検証し、検証に成功したら要求受信用トピックを設定する。

要求受信用のサブスクライブ処理が完了したら、次にテナント処理実行モジュール７２２は、画像形成装置の処理結果を受け取るためにＳ１．１２にて再度ＭＱＴＴ通信モジュール７２１のサブスクライブ要求ＡＰＩを呼び出す。この際、Ｓ１．６で受信したテナント情報に含まれる応答受信用トピックを指定する。ＭＱＴＴ通信モジュール７２１は、サブスクライブ要求ＡＰＩが呼び出されるとＳ１．１３にてＭＱＴＴサーバモジュール６００に対してサブスクライブ要求を送信する。この時、Ｓ１．８で受信したトークンを一緒に送信する。ＭＱＴＴサーバモジュール６００はサブスクライブ要求およびトークンを受信すると、Ｓ１．１４にて受信トークンを検証し、検証に成功したら要求応答用トピックを設定。なお、実施例１では必ず応答受信用のサブスクライブを行う構成となっているが、Ｓ１．３で処理結果を受信するか否かも指定するようにして応答受信用のサブスクライブを行わないようにしても良い。その場合はＳ１．１２〜Ｓ１．１４のステップは省略される。

図５（ｂ）は、テナントにおける承認が不要な場合のシーケンスであり、管理者が端末４００において更新管理サーバ３００にテナントの追加を指示した場合のフローを示している。図５（ａ）と同様の処理が多いため差分のみを詳細に説明する。Ｓ２．１、Ｓ２．２は図５（ａ）Ｓ１．１、Ｓ１．２と同様である。認証が成功するとＳ２．３にて端末４００はテナント管理モジュール７０２に対してテナント追加要求を送信する。この際、テナント追加要求に含まれる承認要否情報として”ｆａｌｓｅ”を指定する。Ｓ２．４〜Ｓ２．８までの処理は図５（ａ）Ｓ１．４〜Ｓ１．８と承認要否情報が“ｆａｌｓｅ”である事を除き同様である。

Ｓ２．８にてテナント処理実行モジュール７２２はトークンを受信すると、受信した承認要否情報が”ｆａｌｓｅ”であるため、要求受信用のサブスクライブを行わない。そしてＳ２．９にてＭＱＴＴ通信モジュール７２１のサブスクライブ要求ＡＰＩを呼び出す。この際、Ｓ２．６で受信したテナント情報に含まれる応答受信用トピックを指定する。ＭＱＴＴ通信モジュール７２１はサブスクライブ要求ＡＰＩが呼び出されると、Ｓ２．１０にてＭＱＴＴサーバモジュール６００に対してサブスクライブ要求を送信する。この際、Ｓ２．８で受信したトークンも送信する。ＭＱＴＴサーバモジュール６００は、サブスクライブ要求およびトークンを受信すると、Ｓ２．１１にて受信したトークンを検証し、検証に成功したら応答受信用トピックを設定する。なお、テナント部にて処理結果を受信したくない場合は、Ｓ２．７、Ｓ２．８、Ｓ２．９、Ｓ２．１０、Ｓ２．１１の各ステップは省略可能である。

テナント部初期化が完了するとテナント管理モジュール７０２は、受信した承認要否情報が”ｆａｌｓｅ”であるため、以下の処理を実施する事でテナント部７２０のテナント処理実行モジュール７２２に変わって要求受信のサブスクライブを行う。Ｓ２．１２にてＭＱＴＴサーバモジュール６００に対してトークン取得要求を出す。ＭＱＴＴサーバモジュール６００はトークン取得要求を受け取ると、Ｓ２．１３にてトークンを作成し、作成したトークンをテナント管理モジュール７０２に送信する。テナント管理モジュール７０２はトークンを受信すると、Ｓ２．１４にてＭＱＴＴ通信モジュール７０１のサブスクライブ要求ＡＰＩを呼び出す。この際、Ｓ２．５で作成したテナント情報を参照し要求受信用トピックの情報を指定する。ＭＱＴＴ通信モジュール７０１は、サブスクライブ要求ＡＰＩが呼び出されるとＳ２．１５にてＭＱＴＴサーバモジュール６００に対してサブスクライブ要求を送信する。この時、Ｓ２．１３で受信したトークンを一緒に送信する。ＭＱＴＴサーバモジュール６００はサブスクライブ要求およびトークンを受信すると、Ｓ２．１６にて受信したトークンを検証し、検証に成功したら要求受信用トピックの設定を行う。

このように、テナント部を作成した更新管理部７００、即ち図４におけるルートノードに相当する装置が作成されたテナント部に代わりサブスクライブすることも可能である。ルートノードに相当する装置をルートシステムと称し、ルートシステムは作成されたテナントに相当する会社の承認の基、承認プロセスを代行することが可能になる。なお、この場合の承認プロセスは自動的に承認される形態であっても良い。

なお、サブスクライブ処理が完了すると、ＭＱＴＴサーバモジュール６００のリテイン機能によりサブスクライブされたトピックに関するその時点の最新のメッセージをＭＱＴＴ通信モジュールに対して送信する場合がある。Ｓ１．１１後に最新メッセージをＭＱＴＴ通信モジュール７２１に送信する場合の処理については図８のＳ６．４以降の処理と同様になる。また、Ｓ２．１６後に最新メッセージをＭＱＴＴ通信モジュール７０１に送信する場合の処理については図８のＳ６．１１以降の処理と同様になる。さらに、Ｓ１．１４およびＳ２．１１後に最新メッセージをＭＱＴＴ通信モジュール７２１に送信する場合の処理については図９のＳ７．４以降の処理と同様になる。夫々の詳細な説明は後述する。

図６は、画像形成装置５００をファームウェア更新システムの対象に追加する際のシーケンスを示した図である。Ｓ３．１にて顧客企業の管理者が画像形成装置５００のＷｅｂ設定ページを操作すると、Ｗｅｂブラウザ４０１はファームウェア更新モジュール８０１に対してファーム自動更新要求を送信する。このファーム自動更新要求には、Ｗｅｂブラウザ上で入力された顧客ＩＤの情報が含まれる。顧客ＩＤは、画像形成装置５００を操作する顧客の顧客テナントに割り当てられるＩＤであり、図４で示す１０４０のように最も階層が低い顧客テナントのＩＤに相当する。これを指定することで画像形成装置５００は最も階層が低いテナントからのメッセージをサブスクライブすることが可能になる。ファーム自動更新要求を受け取ると画像形成装置５００のファームウェア更新モジュール８０１はＳ３．２にて認証モジュール７０３に対して認証情報を送信する。ここでは認証情報として画像形成装置内に事前に組み込まれたＩＤとパスワードを送付することとする。認証モジュール７０３は、認証情報を受け取るとＳ３．３にて認証処理を行う。実施例１では説明を簡略化するために単純なＩＤとパスワードによる認証を行うようになっているが、もちろんこれ以外の認証方式を採用してもよい。

認証が成功するとＳ３．４にてファームウェア更新モジュール８０１はテナント管理モジュール７０２に対してサブスクライブ情報取得要求を出す。サイブスクライブ情報取得要求には、Ｓ３．１で受信した顧客ＩＤの情報も含まれるものとする。テナント管理モジュール７０２はサブスクライブ情報取得要求を受信すると、Ｓ３．５にて画像形成装置５００がサブスクライブすべきトピックを特定する。具体的には、図４で示したテナント情報の中の指定された顧客ＩＤに対応するテナント情報ノードに含まれる要求送信用トピック１００３の情報をサブスクライブすべきトピックと判断する。

トピックパスの特定が完了したら、テナント管理モジュール７０２はＳ３．６にてＭＱＴＴサーバモジュール６００に対し、画像形成装置がサブスクライブを行うためのトークン取得要求を送信する。ＭＱＴＴサーバモジュールはトークン取得要求を受けるとＳ３．７にてトークンを生成し、生成したトークンをテナント管理モジュール７０２に送信する。テナント管理モジュール７０２はトークンを受信するとＳ３．８にて画像形成装置がサブスクライブすべきトピック情報およびサブスクライブに必要なトークンをファームウェア更新モジュール８０１に送信する。

ファームウェア更新モジュール８０１は、トピック情報およびトークンを受信するとＳ３．９にてＭＱＴＴ通信モジュール８００のサブスクライブ要求ＡＰＩを呼び出す。ＭＱＴＴ通信モジュール８００はサブスクライブ要求ＡＰＩが呼び出されると、Ｓ３．１０にてＭＱＴＴサーバモジュール６００に対してサブスクライブ要求を送信する。この時、Ｓ３．８で受信したトピックを指定し、トークンも一緒に送信する。ＭＱＴＴサーバモジュール６００はサブスクライブ要求およびトークンを受信すると、Ｓ３．１１にて、受信したトークンを検証し検証に成功したらサブスクライブ処理を行う。

なお、サブスクライブ処理が完了すると、ＭＱＴＴサーバモジュール６００のリテイン機能によりサブスクライブされたトピックに関するその時点の最新のメッセージをＭＱＴＴ通信モジュール８００に対して送信する場合がある。この時の処理は、図８のＳ６．１５以降の処理と同じであるためここでの説明は割愛する。このようにテナント部での承認要否情報によってサブスクライブをする主体を動的に切り替えることにより、承認プロセスが不要な場合にはテナント部に余計なメッセージを通知することなくシステム部が処理を代行することができるようになる。

図７は、販売会社や顧客企業におけるファームウェア更新において、承認プロセスの有無を切り替える際のシーケンスを示した図である。図７（ａ）は、テナント部で承認プロセスを行わずルートシステムで承認プロセスを行っている状態から、テナント部で承認プロセスを行う状態に変更する場合のシーケンスである。

まず、販売会社、ディーラーもしくは顧客企業の担当者が端末４００上のＷｅｂブラウザ４０１にて認証情報を入力すると、Ｓ４．１にてＷｅｂブラウザ４０１は、認証モジュール７０３に認証情報を送信する。ここでは認証情報としてユーザＩＤとパスワードを送信するものとする。認証モジュール７０３は、端末４００からユーザＩＤとパスワードを受け取ると、Ｓ４．２にて受信したユーザＩＤとパスワード情報を照合し認証処理を行う。

認証に成功するとＳ４．３にてＷｅｂブラウザは、担当者の操作を受けてテナント処理実行モジュール７２２に対して承認フローの追加要求を送信する。テナント処理実行モジュール７２２は承認フロー追加要求を受信するとＳ４．４にて、テナント管理モジュール７０２に対して承認フロー追加要求を出す。承認フロー追加要求を受信すると、Ｓ４．５にてテナント管理モジュール７０２はＭＱＴＴサーバモジュール６００に対し、ＭＱＴＴサーバモジュールを利用するためのトークン発行要求を送信する。ＭＱＴＴサーバモジュール６００はトークン発行要求を受信すると、トークンを発行しＳ４．６にてテナント管理モジュール７０２に対して発行したトークンを送信する。

テナント管理モジュール７０２はトークンを受信するとＳ４．７にてＭＱＴＴ通信モジュール７０１のアンサブスクライブ要求ＡＰＩを呼び出す。ＭＱＴＴ通信モジュール７０１はアンサブスクライブ要求ＡＰＩが呼び出されたら、Ｓ４．８にてＭＱＴＴサーバモジュール６００に対してアンサブスクライブ要求を送信する。ＭＱＴＴサーバモジュール６００は、アンサブスクライブ要求を受信すると、Ｓ４．９にてトークンの検証を行い、アンサブスクライブ処理を実行する。アンサブスクライブ処理が完了するとテナント管理モジュール７０２はＳ４．１０にてテナント情報の更新を行う。具体的には、図４の承認要否情報をｆａｌｓｅに設定する。

テナント情報の更新が完了すると、Ｓ４．１１にてテナント管理モジュール７０２はテナント処理実行モジュール７２２に対してＳ４．６で受信したトークンを送信する。テナント処理実行モジュール７２２は、トークンを受信すると、Ｓ４．１２にてＭＱＴＴ通信モジュール７２１のサブスクライブ要求ＡＰＩを呼び出す。この際、テナント情報に含まれる要求受信用トピックを指定する。即ち、親テナントを指定するトピックパスの指定となる。ＭＱＴＴ通信モジュール７２１はサブスクライブ要求ＡＰＩが呼び出されるとＳ４．１３にて、ＭＱＴＴサーバモジュール６００に対してサブスクライブ要求と、Ｓ４．１１にて受信したトークンを送信する。ＭＱＴＴサーバモジュール６００は、サブスクライブ要求およびトークンを受信すると、Ｓ４．１４にてトークンの検証を行い、検証に成功したら要求受信用トピックの設定を行う。なお、Ｓ４．１４のサブスクライブ処理完了後にリテイン機能によりＭＱＴＴサーバモジュール６００からＭＱＴＴ通信モジュール７２１に最新のメッセージが送信されることがあるが、図８のＳ６．４以降の処理と同様になるため、ここでの説明は割愛する。

図７（ｂ）は、テナント部で承認プロセスを行う状態から、テナント部で承認プロセスを行わずルートシステムで承認プロセスを行う状態に変更する場合のシーケンスである。Ｓ５．１、Ｓ５．２の処理はＳ４．１、Ｓ４．２と同様であるため説明を割愛する。

認証に成功するとＳ５．３にてＷｅｂブラウザは担当者の操作を受けてテナント処理実行モジュール７２２に対して承認フローの削除要求を出す。テナント処理実行モジュール７２２は承認フロー削除要求を受信するとＳ５．４にて、テナント管理モジュール７０２に対して承認フロー削除要求を出す。承認フロー削除要求を受信すると、Ｓ５．５にてテナント管理モジュール７０２はＭＱＴＴサーバモジュール６００に対し、ＭＱＴＴサーバモジュールを利用するためのトークン発行要求を送信する。ＭＱＴＴサーバモジュール６００はトークン発行要求を受信すると、トークンを発行しＳ５．６にてテナント管理モジュール７０２に対して発行したトークンを送信する。テナント管理モジュール７０２はトークンを受信するとＳ５．７にてテナント処理実行モジュール７２２に対してトークンを送信する。

テナント処理実行モジュール７２２はトークンを受信するとＳ５．８にてＭＱＴＴ通信モジュール７２１のアンサブスクライブ要求ＡＰＩを呼び出す。ＭＱＴＴ通信モジュール７２１は、アンサブスクライブ要求ＡＰＩが呼び出されるとＳ５．９にてＭＱＴＴサーバモジュール６００に対してアンサブスクライブ要求を送信する。この際、Ｓ５．７で受信したトークンもあわせて送信する。ＭＱＴＴサーバモジュール６００は、アンサブスクライブ要求およびトークンを受信するとＳ５．１０にてトークンの検証を行い、検証に成功した場合に要求受信用の設定を削除しアンサブスクライブ処理が完了する。アンサブスクライブ処理が完了するとテナント処理実行モジュール７２２は、Ｓ５．１１にてテナント管理モジュール７０２に対してアンサブスクライブ完了通知を送信する。

テナント管理モジュール７０２は、アンサブスクライブ完了通知を受信すると、Ｓ５．１２にてＭＱＴＴ通信モジュール７０１のサブスクライブＡＰＩを呼び出す。この際、テナント情報に含まれる要求受信用トピックを指定する。この際の要求受信用トピックのトピックパスは、アンサブスクライブした子テナントに対する親テナントへのトピックパスである。ＭＱＴＴ通信モジュール７０１はサブスクライブＡＰＩが呼び出されるとＳ５．１３にてＭＱＴＴサーバモジュール６００に対してサブスクライブ要求を送信する。この際、Ｓ５．６で受信したトークンをあわせて送信する。

ＭＱＴＴサーバモジュール６００はサブスクライブ要求およびトークンを受信するとＳ５．１４にてトークンの検証を行い、検証に成功した場合はサブスクライブ処理を実行する。サブスクライブ処理が完了するとテナント管理モジュール７０２はＳ５．１５にてテナント情報を更新する。具体的には、テナント情報の中の承認プロセスの要否情報をｆａｌｓｅに書き換える。なお、Ｓ５．１４のサブスクライブ処理完了後にリテイン機能により最新のメッセージがＭＱＴＴサーバモジュール６００からＭＱＴＴ通信モジュール７０１に送信されることがあるが、図８のＳ６．１１以降の処理と同様になるため、ここでの説明は割愛する。このように要求を受けて動的にサブスクライブを実行する主体を切り替えることができるようにすることにより柔軟に承認フローを変更することが可能になる。

図８は、デバイス製造会社の担当者がファームウェア更新情報を更新システムに通知した場合に、更新通知が画像形成装置に送信されるまでの処理の流れを示したシーケンスである。なお、このシーケンスは図４における１０００および１０１０に対応するテナント部だけが存在する場合の情報通知の例となっている。

デバイス製造会社の担当者が端末４００上のＷｅｂブラウザ４０１上でファームの更新情報を入力すると、Ｓ６．１にてＷｅｂブラウザ４０１はテナント管理モジュール７０２に対してファーム更新通知を送信する。テナント管理モジュール７０２は、ファーム更新通知を受信するとＳ６．２にてＭＱＴＴ通信モジュール７０１のパブリッシュＡＰＩを呼び出す。この際、ルートノードに含まれる要求送信用トピックを指定する。パブリッシュするメッセージの内容は、ファームウェアの更新情報が記載されたＵＲＬである。このＵＲＬにアクセスすることでファームウェアのバージョンや更新内容やファームウェアの入手先などの詳細情報を取得することができる。なお、実施例１においては、メッセージとしてＵＲＬを送信し、ＵＲＬを基に詳細情報を取得するような構成としているが、メッセージ自体に詳細情報を埋め込むような構成としてもよい。メッセージの形式はこの形態に限定されるものではなく、ファームの更新に関係なく任意の情報を含めることも可能である。

ＭＱＴＴ通信モジュール７０１はパブリッシュ要求ＡＰＩを呼び出されると、Ｓ６．３にてＭＱＴＴサーバモジュール６００に対してパブリッシュ要求を送信する。ＭＱＴＴサーバモジュール６００はパブリッシュ要求を受信すると、トピックをサブスクライブしているテナント部のＭＱＴＴ通信モジュール７２１に対してメッセージ（ＵＲＬ情報）を送信する。ＭＱＴＴ通信モジュール７２１はメッセージ（ＵＲＬ情報）を受信すると、Ｓ６．５にてテナント処理実行モジュール７２２に対してメッセージ（ＵＲＬ情報）を通知する。ＵＲＬ情報の通知を受けるとテナント処理実行モジュール７２２は、Ｓ６．６にてＵＲＬからファームウェアの更新情報を取得して管理者向けにＷｅｂブラウザからアクセス可能なファームウェア更新確認ページ１１００を生成する。実施例１においては、ここでＷｅｂページ生成しか行なっていないが、リアルタイムに担当者に情報を通知するためにメールを送信するようにしてもよい。

図１０（ａ）は、ファームウェア更新確認ページ１１００の一例を示す図である。１１０１はバージョン情報であり、Ｓ６．５にて受信したＵＲＬから取得した情報を表示している。１１０２は、バージョン１１０１にて更新された内容の情報が表示される領域である。この情報の内容もＳ６．５にて受信したＵＲＬにアクセスすることで取得できる。１１０３は許可ボタンであり、押下すると更新許可を指示するためのボタンである。１１０４は拒否ボタンでありファームウェアの更新をせずにファームウェア更新確認ページを閉じる。拒否ボタン１１０４が押下された場合は、Ｓ６．７以降の処理が行われないためファームウェア更新通知が配下のテナント部や画像形成装置に通知されずファームウェアの更新が行われないことになる。担当者がファームウェア更新確認ページにアクセスして許可ボタン１１０３を押すと、Ｗｅｂブラウザ４０１はＳ６．７にてテナント処理実行モジュール７２２に対して更新許可通知を送信する。

テナント処理実行モジュール７２２は、更新許可通知を受信すると、Ｓ６．８にてファームウェア更新確認ページを削除する。なお、本実施形態ではページを削除してアクセス出来ないようにしているが、ページの内容を書き変えるだけでもよい。Ｗｅｂページの削除が完了するとＳ６．９にてテナント処理実行モジュール７２２はＭＱＴＴ通信モジュール７２１のパブリッシュ要求ＡＰＩを呼び出す。この際、テナント情報に含まれる要求送信用トピックを指定する。メッセージの本体はＳ６．５にて受信した内容（ＵＲＬ情報）をそのまま指定することとするが、メッセージを処理したテナント部がＳ６．５にて受信した内容を基に新たなメッセージを生成する他、メッセージに情報を追加、メッセージから情報を削除しても良い。

ＭＱＴＴ通信モジュール７２１はパブリッシュＡＰＩが呼び出されると、Ｓ６．１０にてＭＱＴＴサーバモジュール６００に対してパブリッシュ要求を送信する。ＭＱＴＴサーバモジュール６００はパブリッシュ要求を受信すると、指定されたトピックをサブスクライブしているサブスクライバにメッセージを送信する。１０１０のテナント部は承認プロセスを不要としているため、ルートシステム内のテナント管理モジュール７０２が１０１０のテナントの代わりにサブスクライブをしている。よってＭＱＴＴサーバモジュール６００は、Ｓ６．１１にて更新管理部７００に含まれるＭＱＴＴ通信モジュール７０１に対してメッセージを送信する。

ＭＱＴＴ通信モジュール７０１はメッセージを受信すると、Ｓ６．１２にてテナント管理モジュール７０２に対して受信したメッセージを通知する。テナント管理モジュール７０２は、メッセージの通知を受けると、１０１０のテナントの処理を代行するためＳ６．１３にてＭＱＴＴ通信モジュール７０１のパブリッシュＡＰＩを呼び出す。この時、１０１０のテナント情報に含まれる要求送信用トピックを指定する。なお、ルートシステムが代行する場合はメッセージ処理、今回の場合は承認プロセスが不要になるため、メッセージの内容に関わらずパブリッシュを行うようになっている。ＭＱＴＴ通信モジュール７０１は、パブリッシュＡＰＩを呼び出されるとＳ６．１４にてＭＱＴＴサーバモジュール６００に対してパブリッシュ要求を送信する。

ＭＱＴＴサーバモジュール６００はパブリッシュ要求を受信すると指定されたトピックをサブスクライブしているサブスクライバにメッセージを送信する。ここでは１台の画像形成装置が１０１０の顧客企業の管理下に存在していた場合のシーケンスを想定している。よって、ＭＱＴＴサーバモジュール６００はＳ６．１５にて画像形成装置５００のＭＱＴＴ通信モジュール８００に対してメッセージ（ＵＲＬ情報）を送信する。画像形成装置５００が複数台あれば、夫々の画像形成装置が図６で示したフローに従いテナント部からメッセージをサブスクライブしていることになっているので、ＭＱＴＴサーバモジュール６００は複数台の画像形成装置へメッセージを送信することになる。

ＭＱＴＴ通信モジュール８００はメッセージを受信すると、ファームウェア更新モジュール８０１に対してメッセージ（ＵＲＬ情報）を通知する。ファームウェア更新モジュール８０１はメッセージを受信すると、Ｓ６．１７にて受け取ったＵＲＬからファームウェアのダウンロード先を取得する。そして、ファームウェアをダウンロードしてファームウェアの更新を行う。

この例では、販売会社において承認プロセスを必要としていたため、更新通知のメッセージがテナント部７２０に通知されテナント部において承認に関する処理が行われていた。しかし全テナント部において承認プロセスを行わない設定になっている場合には、テナント部を一切介さずに更新管理部７００の処理だけで画像形成装置に対してメッセージが伝達されることになる。逆に、全テナント部において承認が必要な設定になっている場合、更新管理部７００は、Ｓ６．３でのパブリッシュを行った後はメッセージ処理を一切行わず、各テナント部７２０のメッセージ処理によって画像形成装置へメッセージが送信されることになる。

図９は、ファームウェア更新の結果を各テナント部に通知する際のシーケンスを示した図である。図４に示したテナント構成である場合に、／ｓｙｓｔｅｍ／ｓａｌｅｓ１／ｃｕｓｔｏｍｅｒ１の顧客企業にある画像形成装置のファームウェアを更新した場合を例に説明を行う。なお、１０００〜１０４０の各テナント部は応答受信用トピックをサブスクライブしている前提である。

まずファームウェア更新モジュール８０１がＳ７．１にてファームウェア更新を行う。ファームウェアの更新が完了すると、Ｓ７．２にてＭＱＴＴ通信モジュール８００のパブリッシュＡＰＩを呼び出す。この際のトピックとしては画像形成装置が存在する階層を示すトピックを指定するが、画像形成装置はテナントではないため図４に示すテナントのようにテナント情報として管理されているわけではない。画像形成装置５００は顧客が所有するので最下層のテナントを指定するトピックパスの更に下に位置することになる。よって、この例では”／ｒｅｓｐｏｎｓｅ／ｖｅｒｓｉｏｎ／ｓｙｓｔｅｍ／ｓａｌｅｓ１／ｃｕｓｔｏｍｅｒ１／ｄｅｖｉｃｅ１”を指定する。

処理結果を通知するためのメッセージの内容は、更新バージョン、更新日時、処理結果コードを含む。更新バージョンは更新されたファームウェアのバージョンであり、更新日時はファームウェアを更新した日時である。処理結果コードは、処理結果を示す定数であり、１が成功、０が失敗と定義する。なお、結果として返す情報はこれに限られるものではなく、処理結果の詳細情報が格納されたサーバのＵＲＬ情報などを通知するようにしてもよい。

ＭＱＴＴ通信モジュール８００はパブリッシュＡＰＩが呼び出されると、Ｓ７．３にてＭＱＴＴサーバモジュール６００に対してパブリッシュ要求を送信する。ＭＱＴＴサーバモジュール６００はパブリッシュ要求を受信すると、トピックをサブスクライブしているサブスクライバに対してメッセージを送信する（Ｓ７．４、Ｓ７．４‘）。この例では１０００および１０１０のテナント部がサブスクライブしているトピックに合致するため、１０００および１０１０のテナント部のＭＱＴＴ通信モジュールにメッセージを送信する。これは、各テナント部がブローカ２００に設定した応答受信用トピックにおいて、自テナント以下のトピックパスにワイルドカードを指定したことで条件に合致し、メッセージが送信されることを意味する。

それぞれのテナント部のＭＱＴＴ通信モジュール７２１はメッセージを受信すると、テナント処理実行モジュール７２２にメッセージの内容を通知する（Ｓ７．５、Ｓ７．５‘）。テナント処理実行モジュール７２２は、メッセージ通知を受けるとデバイス情報確認ページの情報を更新する（Ｓ７．６、Ｓ７．６‘）。図１０（ｂ）はデバイス情報確認画面１２００の一例である。１２０１はデバイス情報リスト表示領域であり、そのテナントの管理下にある画像形成装置のリストが表示される。リストの内容としてはデバイス名称およびバージョンおよびファーム更新日時である。各会社の担当者はこのデバイス情報確認画面１２００を確認することでいつどのようなファームウェアに更新されたかを把握することができる。なお、本実施形態では結果をＷｅｂブラウザで表示可能なＷｅｂページに表示するのみであるが、メールで通知を行うなどの処理を行ってもよい。このように、更新要求とは別のトピックを用いて処理結果に関するメッセージを受信するような構成にすることにより、各階層において関係する画像形成装置の処理結果だけを各階層において同時に受信することが可能になる。

以上、説明してきたように、販売会社やディーラーや顧客企業の関係をトピックパスの階層に対応させて管理している。そして、自テナントの一つ上の階層に対応するトピックにサブスクライブし、自点との階層に対応するトピックにパブリッシュすることにより、自テナントの関係者だけに効率的に情報伝達を行うことが可能になる。また、ルートシステム部がテナント部の代わりにメッセージの送信処理を代行するような構成に動的に切り替えられるようにすることで更に容易に承認フローの追加や削除を行うことが可能になる。さらには、処理要求用のトピックとは別に応答通知用のトピックを定義することにより承認プロセスの有無に関わらず処理結果を受信することが可能になる。

［その他の実施例］
実施例１はファームウェア配信のユースケースを例に説明したが、本特許はこの用途に限られるものではなく、例えば設定配信やアプリケーション配信などを始めとするあらゆるトップダウン型の指示による情報伝達に適用可能である。

実施例１はエンタープライズ向けデバイスの代表であるＭＦＰを例に説明したが、デバイスの使用目的がホーム向けであったとしても本願発明は適用可能であり、プリンタに限られるモノでもない。本願発明は如何なデバイスが対象であっても、適用可能な構成である。

また、各会社の管理者が端末４００を用いて更新管理サーバ３００にテナント部７２０を作成したが、更新管理サーバ３００ではない別のサーバにテナント部７２０を作成する形態であってもよい。その場合であっても、図４の階層構造でテナント管理がなされていればブローカ２００とテナント部７２０によるメッセージ送受信が可能になる。

２００ブローカ
３００更新管理サーバ
４００端末
５００画像形成装置
６００ＭＱＴＴサーバモジュール
７００更新管理部
７２０テナント部
８００ＭＱＴＴ通信モジュール
８０１ファームウェア更新モジュール

Claims

テナントの作成指示に従い前記テナントが作成されたことに応じて、前記テナントと他のテナントとの階層関係を反映したメッセージ属性を生成する生成手段と、
生成された前記メッセージ属性を設定する設定手段と、
特定のテナントからメッセージを受信する受信手段と、
前記設定手段により設定された子テナントのメッセージ属性を基に、前記特定のテナントの直下に配置された前記子テナントに対し受信された前記メッセージを送信する送信手段と、を有する情報処理システム。
前記受信手段は、前記メッセージを受信した前記子テナントによって更に送信されたメッセージを処理する情報処理装置から処理結果のメッセージを受信し、
前記送信手段は、前記設定手段により設定されている前記子テナントのメッセージ属性を基に、前記子テナントに対し前記処理結果のメッセージを送信することを特徴とする請求項１に記載の情報処理システム。
前記設定手段は、メッセージを受信するための要求受信用のメッセージ属性と、処理結果に関するメッセージを受信するための応答受信用のメッセージ属性の２つのメッセージ属性を設定し、
前記送信手段は、前記子テナントの要求受信用のメッセージ属性を基に、前記特定のテナントの直下に配置された前記子テナントに対し受信された前記メッセージを送信し、前記子テナントの応答受信用のメッセージ属性を基に、前記子テナントに対し前記処理結果のメッセージを送信することを特徴とする請求項２に記載の情報処理システム。
前記受信手段が前記処理結果のメッセージを受信した場合、前記送信手段は、前記設定手段により設定された前記応答受信用のメッセージ属性を基に、前記子テナントおよび前記特定のテナントを含む前記子テナントより上に配置された複数のテナントに対して前記処理結果のメッセージを送信することを特徴とする請求項３に記載の情報処理システム。
前記送信手段は、前記設定手段により設定された前記応答受信用のメッセージ属性の内、パスにワイルドカードを指定し前記処理結果のメッセージを受信するための複数のメッセージ属性を基に、前記子テナントおよび前記特定のテナントを含む前記子テナントより上に配置された複数のテナントに対して前記処理結果のメッセージを送信することを特徴とする請求項４に記載の情報処理システム。
前記設定手段が設定するメッセージ属性はテナント間の階層関係をパスで表現しており、前記メッセージ属性が示す前記メッセージの送信先はパスで指定されていることを特徴とする請求項１乃至５の何れか１項に記載の情報処理システム。
前記設定手段は、前記作成指示に従い作成された前記テナントに代わりルートシステムでメッセージを処理することが指定された場合、前記ルートシステムからメッセージ属性を受け付けて設定し、
前記送信手段は、前記設定手段により設定された子テナントのメッセージ属性を基に、前記子テナントに代わり前記メッセージ属性の設定を要求した前記ルートシステムに対し受信された前記メッセージを送信する請求項１乃至６の何れか１項に記載の情報処理システム。
前記設定手段は、前記作成指示に従い作成された前記テナントに代わりルートシステムでメッセージを処理することをメッセージ属性が設定された後に指定された場合、前記テナントにより既に設定されているメッセージ属性を削除し、前記ルートシステムからメッセージ属性を受け付けて設定することを特徴とする請求項７に記載の情報処理システム。
テナントの作成指示に従い前記テナントが作成されたことに応じて、前記テナントと他のテナントとの階層関係を反映したメッセージ属性を生成する生成ステップと、
生成された前記メッセージ属性を設定する設定ステップと、
特定のテナントからメッセージを受信する受信ステップと、
前記設定ステップにおいて設定された子テナントのメッセージ属性を基に、前記特定のテナントの直下に配置された前記子テナントに対し受信された前記メッセージを送信する送信ステップと、を含む情報処理システムの制御方法。
テナントの作成指示に従い前記テナントが作成されたことに応じて、前記テナントと他のテナントとの階層関係を反映したメッセージ属性を生成する生成ステップと、
生成された前記メッセージ属性を設定する設定ステップと、
特定のテナントからメッセージを受信する受信ステップと、
前記設定ステップにおいて設定された子テナントのメッセージ属性を基に、前記特定のテナントの直下に配置された前記子テナントに対し受信された前記メッセージを送信する送信ステップと、を含む情報処理システムで実行されるプログラム。