JP5721659B2 - 管理装置、管理システム、及び制御方法 - Google Patents

Description

本発明は、画像形成装置などのネットワークデバイスを管理するための技術に関する。

画像形成装置とインターネット等のネットワークを介して通信する管理サーバを備える管理システムが提案されている。ここで、画像形成装置が配置されたローカルネットワークにファイアウォールが設けられているネットワーク環境下においては、管理サーバから画像形成装置に対して、設定変更指示や再起動指示等を直接行うことはできない。したがって、このようなネットワーク環境下では、画像形成装置が、管理サーバに対してポーリングを行って、指示の有無を問合せる。

特許文献１は、管理サーバが、被管理デバイスからの越えの指示の有無の問合せを受け、指示があれば、問合せを受けた際に張られたセッションにおいて指示を返信するデバイス管理システムを開示している。

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

管理サーバが、画像形成装置に対してリアルタイムに指示したい場合がある。管理サーバがリアルタイムに行う指示は、例えば、画像形成装置に発生した障害を復旧させるための再起動指示や、ファームウェアのアップデート指示などである。

しかし、画像形成装置が、管理サーバに対してポーリングを行って、指示の有無を問合せる従来のシステムにおいては、管理サーバの負荷を考慮して、ポーリング間隔が長くとられている。したがって、従来のシステムでは、管理サーバが画像形成装置への指示をリアルタイムに行うことができない。

管理サーバが画像形成装置への指示をリアルタイムに行うことを可能とするために、管理サーバと画像形成装置との通信の方式を、ポーリング通信からプッシュ通信へと切り替えることが考えられる。プッシュ通信とは、インターネット上での通信方法の一つであり、ある通信リクエストがサーバにより開始されるものを指す。プッシュ通信の例としては、ＷｅｂＳｏｃｋｅｔなどが挙げられる。ＷｅｂＳｏｃｋｅｔは、ＩＥＴＦ（インターネット Engineering Task Force ）が策定したＲＦＣ ６４５５として公表されている。

ファイアウォールを介して管理サーバが画像形成装置などのネットワークデバイスを管理する場合には、前述したとおりポーリング形式による情報のやり取りが行われている。よって、そのような通信形態からＷｅｂＳｏｃｋｅｔなどのプッシュ通信に切り換えて、通信経路を確立する場合に、どのようなシーケンスが必要なのか検討する必要がある。

また、プッシュ通信では、ポーリング形式と違って、必要な時のみデータのやり取りを行うので、通信量は減るが、セッションを維持するため、管理装置（管理サーバ）に負荷がかかる。したがって、管理対象の全ての画像形成装置との間の通信がプッシュ通信になると、セッション維持のために、管理装置のリソース負荷が増えてしまう。このため、所定の場合にのみ、管理装置と画像形成装置との間での通信をプッシュ通信とすることにより、管理装置の負荷の増加を抑えることが必要となる。

本発明は、上述した課題の少なくとも一つを解決するためになされたものである。本発明は、画像形成装置などのネットワークデバイスとの通信の通信方式を、当該デバイスからの要求なしに当該デバイスに指示できる通信方式に、適切に切り替えるための管理装置の機能を提供することを目的とする。また、本発明は、ネットワークデバイスとの通信の通信方式の切り替えに関して、所定の条件を考慮した通信方式の切り替えを可能とする仕組みの提供を目的とする。

よって、本発明における画像形成装置を管理するインターネット上の管理装置は、前記画像形成装置から問合せを受信する受信手段と、前記画像形成装置と前記管理装置との通信の通信方式を前記画像形成装置の要求なしに前記管理装置から指示が可能となる所定の通信方式に切り替える切り替え指示を、前記受信された問合せの応答として前記画像形成装置に送信する送信手段と、前記画像形成装置と前記切り替え指示に応じた初期通信を行うことで、前記所定の通信方式が確立された後に、前記画像形成装置に対する指示を前記確立された所定の通信方式により行う指示手段と、所定の条件に従い、前記所定の通信方式による通信を切断する切断手段と、を有することを特徴とする。

本発明によれば、管理装置とネットワークデバイスとの通信の通信方式を、当該デバイスからの要求なしに当該デバイスに指示できる通信方式に、適切に切り替えることが可能となる。また、その切り替えに際して所定の条件を考慮することで、管理装置側の負荷を抑えつつ効率的な双方向通信を実現することができる。

本実施形態のシステム構成例を示す図である。 画像形成装置のハードウェア構成例を示す図である。 管理サーバのハードウェア構成例を示す図である。 画像形成装置の機能ブロック図の例である。 管理サーバの機能ブロック図の例である。 管理サーバの全体動作処理の例を説明するフローチャートである。 サーバ指示制御処理の例を説明するフローチャートである。 通信切断処理の例を説明するフローチャートである。 画像形成装置の動作処理の例を説明するフローチャートである。 管理サーバが保持するサーバ指示の内容の一例を示す図である。 サーバ指示制御処理の例を説明するフローチャートである。 通信切断処理の例を説明するフローチャートである。 画像形成装置が保持する障害一覧の例を示す図である。 画像形成装置の動作処理の例を説明するフローチャートである。 管理サーバの全体動作処理の例を説明するフローチャートである。 管理サーバが表示する画面の例を示す図である。

図１は、本実施形態のシステム構成例を示す図である。本実施形態の管理システムは、画像形成装置１０２と、画像形成装置１０２を管理するインターネット上の管理装置である管理サーバ１０６とを備える。管理サーバ１０６は、ネットワークの一つであるインターネット１０８を介して画像形成装置１０２と通信する。

１０１は、ＬＡＮ（Local Area Network）である。１０３は、Ｐｒｏｘｙ Ｓｅｒｖｅｒである。１０４は、イントラネット１０７のセキュリティを高めるために設置されたファイアウォールである。１０５は、一般のユーザが業務等で使用するパーソナルコンピュータ（ＰＣ）である。ネットワークデバイスである画像形成装置１０２乃至ＰＣ１０５は、ＬＡＮ１０１を介して相互に接続されている。イントラネット１０７は、画像形成装置１０２、Ｐｒｏｘｙ Ｓｅｒｖｅｒ１０３、Ｆｉｒｅｗａｌｌ１０４がＬＡＮ１０１を介して相互に接続されたローカルネットワークである。図１に示す例では、イントラネット１０７は１つであるが、実際には、複数のイントラネット１０７と管理サーバ１０６とがインターネット１０８を介して相互に接続されている。

ネットワークデバイスとしては、画像形成装置や携帯情報端末などのネットワーク接続可能で、インターネットなどに配置されるリモートサーバにより管理されるような機器が含まれる。また、画像形成装置１０２は、例えば、デジタル複合機、ファクシミリ装置、レーザービームプリンタ、インクジェットプリンタ、スキャナ装置などである。画像形成装置１０２は、ＬＡＮ１０１を介して、通信スケジュールに従って通信を行い、画像形成装置１０２の情報（以下、「デバイス情報」と記述）をインターネット１０８経由で管理サーバ１０６へ送信する。デバイス情報は、例えば、カウンタ値、稼動状況ログ、および障害情報である。カウンタ値は、印刷した総枚数である。

管理サーバ１０６は、画像形成装置１０２からデバイス情報を受信して保存する。これにより、管理サーバ１０６は、画像形成装置１０２の稼動状態を一元的に管理する。管理サーバ１０６による画像形成装置１０２からの上記デバイス情報の取得は、ＳＮＭＰを介したＭＩＢのやり取りによって実現される。ＳＮＭＰは、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌの略称である。ＭＩＢは、Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅの略称である。この例では、画像形成装置１０２は、ＨＴＴＰＳを利用して、管理サーバ１０６にデバイス情報を送信するが、通信プロトコルは、ＨＴＴＰであってもよく、とくに限定するものではない。

図２は、画像形成装置のハードウェア構成例を示す図である。画像形成装置１０２は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、記憶装置（ＨＤＤ）２０４、ネットワークＩ／Ｆ（Interface ）２０５、内部バス２０６、デバイス制御２０７、印刷部２０８、入出力Ｉ／Ｆ２０９、入出力装置２１０を備える。ＣＰＵは、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略称である。ＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略称である。ＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略称である。ＨＤＤは、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略称である。

ＣＰＵ２０１は、画像形成装置全体を制御する。ＣＰＵ２０１は、ＲＯＭ２０３に格納されているプログラム（後述する図４に示す各処理部の機能を実現するプログラムも含む）を実行し、内部バス２０６を介して各デバイスを総括的に制御する。例えば、ＣＰＵ２０１は、プログラムを実行することによって、ＨＤＤ２０４等の記録媒体に画像データを記録する処理を行う。

ＲＯＭ２０３には、画像形成装置１０２が出荷される地域を意味する仕向け情報も格納されている。この仕向け情報に従って入出力装置２１０で表示する言語が決定される。ＲＡＭ２０２は、ＣＰＵ２０１のメモリやワークエリアとして機能する。ネットワークＩ／Ｆ２０５は、ＬＡＮ１０１を介して、外部のネットワーク機器またはＰＣ１０５と肩方向または双方向にデータをやり取りする。デバイス制御部２０７は、印刷部２０８を制御する。ＨＤＤ２０４は、外部記憶装置として機能し、画像データ等を記憶する。また、ＨＤＤ２０４は、カウンタ情報、システム情報及び監視情報を保存する。入出力装置２１０は、ユーザからの入力（スキャン、ボタン入力など）を受け付け、入出力Ｉ／Ｆ２０９を介して、各処理部に当該入力を伝える。

図３は、管理サーバのハードウェア構成例を示す図である。管理サーバ１０６は、ＣＰＵ３０１、ＲＡＭ３０２、ＲＯＭ３０３、記憶装置（ＨＤＤ）３０４、ネットワークＩ／Ｆ３０５、内部バス３０６、入出力Ｉ／Ｆ３０７、入出力装置３０８を備える。

ＣＰＵ３０１は、管理サーバ全体を制御する。ＣＰＵ３０１は、ＲＯＭ３０３に格納されているプログラム（後述する図５に示す各処理部を実現するプログラムも含む）を実行し、内部バス３０６を介して各デバイスを総括的に制御する。

内部バス３０６には、ＲＡＭ３０２、ＲＯＭ３０３、ＨＤＤ３０４、ネットワークＩ／Ｆ３０５、入出力Ｉ／Ｆ３０７が接続されている。また、入出力Ｉ／Ｆ３０７は、例えば、ＰＳ／２やＵＳＢ Ｉ／Ｆ、アナログやデジタルのディスプレイＩ／Ｆを備える。ＵＳＢは、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓの略称である。

入出力装置３０８は、キーボードやマウス、ＣＲＴや液晶ディスプレイであり、入出力Ｉ／Ｆ３０７を介して管理サーバ１０６と接続することができる。ＣＲＴは、Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅの略称である。

管理サーバ１０６は、ネットワークＩ／Ｆ３０５を介してインターネット１０８に接続し、画像形成装置１０２や、ＰＣ１０５と通信を行う。ＨＤＤ３０４は、外部記憶装置として機能し、画像形成装置１０２から取得されたデバイス情報を記憶する。また、ＨＤＤ３０４は、ＲＡＭ３０２に代わって、システム情報及び処理情報を保存する。

図４は、画像形成装置の機能ブロック図の例である。画像形成装置１０２は、通信部４０１、記憶部４０２、画像形成部４０３、デバイス情報制御部４０４、操作部４０５、表示部４０６、コマンド生成部４０７、コマンド解析・実施部４０８を備える。

通信部４０１は、画像形成装置１０２のデバイス情報を管理サーバ１０６へ送信する。また、管理サーバ１０６から送信される指示、情報を受信する。通信部４０１は、ＳＭＴＰやＨＴＴＰ／ＨＴＴＰＳなどを用いて管理サーバ１０６と通信する。

通信部４０１は、通信制御部４０９を備える。通信制御部４０９は、通信部４０１が管理サーバ１０６と通信中に、通信方式を変更するなどの制御を行う。通信制御部４０９は、例えば、ＨＴＴＰプロトコルでのポーリング方式から、ＷｅｂＳｏｃｋｅｔプロトコルでのＰｕｓｈ方式に通信方式を変更する。なお、本実施例では、ポーリング方式としてＨＴＴＰプロトコルでのポーリング方式、Ｐｕｓｈ方式としてＷｅｂＳｏｃｋｅｔプロトコルでのＰｕｓｈ方式を用いるが、ポーリング方式やＰｕｓｈ方式の通信が実現可能な他のプロトコルを適用してもよい。

記憶部４０２は、ＲＡＭ２０２、ＲＯＭ２０３、記憶装置２０４の記憶領域と情報のやり取りを行う。また、記憶部４０２は、管理サーバ情報や、画像形成装置１０２の動作履歴や、各種異常状態を表すデータなどを記憶する。管理サーバ情報には、画像形成装置１０２を管理する管理サーバ１０６のＩＰアドレスなどの通信情報が含まれる。

画像形成部４０３は、印刷データを生成し出力する機能を持つ。デバイス情報制御部４０４は、デバイス情報を管理する。デバイス情報制御部４０４は、例えば、画像形成装置１０２の印刷制御や異常状態の管理などを行うとともに、カウンタ情報の管理や通知情報の管理も行う。また、デバイス情報制御部４０４は、色味調整や印刷モード、その他機能の設定に関する制御も行う。

操作部４０５は、ユーザによる印刷指示等の、画像形成装置１０２に対する操作指示を可能とするインタフェースである。表示部４０６は、画像形成装置１０２の状態情報、設定情報等を表示する。また、表示部４０６は、各種ボタンの表示も行い、ボタン押下によるユーザからの指示を検知する。

コマンド生成部４０７は、デバイス情報制御部４０４が管理しているデバイス情報を管理サーバ１０６へ送信するための送信コマンドを生成する。この送信コマンドは、通信部４０１によって管理サーバ１０６に送信される。コマンド解析・実施部４０８は、送信コマンドに対する管理サーバ１０６からのレスポンスを解析する。また、コマンド解析・実施部４０８は、管理サーバ１０６が送信したコマンドを通信部４０１を介して受け取り、受け取ったコマンドを解析し、実施する。

図５は、管理サーバの機能ブロック図の例である。管理サーバ１０６は、通信部５０１、記憶部５０２、制御部５０３、表示部５０９、コマンド解析・実施部５１０、コマンド生成部５１１を備える。本実施形態の管理装置の制御方法は、図５中に示す管理サーバ１０６が備える各処理部の機能によって実現される。また、本実施形態のコンピュータプログラムは、上記管理装置の制御方法をコンピュータに実行させることを特徴とする。

通信部５０１は、画像形成装置１０２と通信を行う機能を持つ。具体的には、通信部５０１は、画像形成装置１０２から送信されるデバイス情報を受信する。また、通信部５０１は、画像形成装置１０２からサーバ指示問合せを受信する。サーバ指示問合せは、管理サーバ１０６が、画像形成装置１０２に対するサーバ指示を保持しているかについての問合せである。この問い合わせは、１日に２回など、定期的に行われる。サーバ指示は、管理サーバ１０６が外部装置に対して行う指示で、管理サーバ１０６側で、ユーザ（オペレータ）が必要に応じて１以上の指示を登録した場合に、それら指示が記憶部５０２に蓄積される。また、通信部５０１は、画像形成装置１０２へ必要な指示、情報を送信する。

記憶部５０２は、ＲＡＭ３０２、ＲＯＭ３０３、記憶装置３０４の記憶領域と情報のやりとりを行う。具体的には、記憶部５０２は、デバイス情報や販売会社情報、顧客情報などを保存する。また、記憶部５０２には、サーバ指示が記憶される。制御部５０３は、画像形成装置１０２を監視し保守を行うために必要な情報を管理する制御機能を持つ。

制御部５０３は、通知管理部５０４、販売会社情報管理部５０５、デバイス情報管理部５０６、顧客情報管理部５０７を備える。通知管理部５０４は、各種通知に対応する通知情報の生成や通知先の指定を行う。通知は、例えば、画像形成装置１０２を保守するサービスマンへの保守依頼通知や消耗品の補充依頼通知、画像形成装置１０２が管理サーバからの指示に応じた処理の実行に失敗したことの通知等である。

販売会社情報管理部５０５は、顧客に設置された画像形成装置１０２の管理、サポートを行う販売会社の情報を管理する。デバイス情報管理部５０６は、画像形成装置１０２から通信部５０１を介して取得したデバイス情報を管理する。これにより、保守対象の画像形成装置１０２を管理する。デバイス情報管理部５０６は、例えば、画像形成装置識別情報、画像形成装置の異常状態情報、保守履歴、画像形成装置管理者情報、画像形成装置の消耗品管理情報などを管理する。

顧客情報管理部５０７は、顧客情報を管理する。顧客情報は、画像形成装置１０２が設置された顧客の情報である。顧客情報は、例えば、販売会社との保守契約に関する情報を含む。消耗品在庫管理部５０８は、トナー／インク、部品等の消耗品の在庫管理を行う。具体的には、消耗品在庫管理部５０８は、画像形成装置１０２から送信されるトナー／インク残量を示す情報、部品交換を示す情報を元に在庫減算を行う。そして、消耗品在庫管理部５０８は、在庫減算結果が予め設定された閾値を超えた場合に、通知管理部と連動することで、消耗品の補充依頼通知などの通知を行う。

表示部５０９は、記憶部５０２に格納されたデバイス情報をＷｅｂ画面として表示する。管理サーバ１０６内では、ＷＷＷサーバプログラムが動作しており、これにより販売会社のサービスマン等がＰＣ上のＷｅｂブラウザを用いて、デバイス情報を閲覧することが可能となる。

コマンド解析・実施部５１０は、画像形成装置１０２から送信されたコマンドを通信部５０１から受け取り、解析、実施する。また、コマンド解析・実施部５１０は、解析結果を記憶部５０２、制御部５０３、表示部５０９に反映させる。コマンド生成部５１１は、コマンド解析部５１０によるコマンドの解析結果に基づいて、当該コマンドの送信元の画像形成装置１０２へのレスポンスを生成する。また、コマンド生成部５１１は、画像形成装置１０２への指示に対応するコマンドを生成する。画像形成装置１０２への指示は、例えば、再起動要求やファームアップ要求などである。通信部５０１が、このコマンドを画像形成装置１０２に送信する。

デバイス指示受付部５１２は、ＵＩなどを通してユーザからの指示を受け付ける。デバイス指示受け付け部５１２は、受け付けた指示をサーバ指示として記憶部５０２に記憶する。コマンド生成部５１１は、記憶部５０２からサーバ指示を取り出して、取り出したサーバ指示に対応するコマンドを生成する。

（実施例１）
図６は、実施例１における管理サーバの全体動作処理の例を説明するフローチャートである。
まず、管理サーバ１０６の通信部５０１が、画像形成装置１０２から送信された情報を受信する（ステップＳ６０１）。続いて、コマンド解析・実施部５１０が、ステップＳ６０１で受信された情報が画像形成装置１０２のサーバ指示問合せであるかを判断する（ステップＳ６０２）。

コマンド解析・実施部５１０が、受信された情報がサーバ指示問合せであると判断した場合は、処理がステップＳ６０３に進む。続いて、コマンド生成部５１１が、記憶部５０２にサーバ指示があるかを判断する（ステップＳ６０３）。コマンド生成部５１１が、サーバ指示がないと判断した場合は、処理が終了する。コマンド生成部５１１が、サーバ指示があると判断した場合は、処理がステップＳ６０４に進む。そして、コマンド生成部５１１が、サーバ指示制御処理を実行して（ステップＳ６０７）、処理が終了する。サーバ指示制御処理は、サーバ指示の種類に応じて、画像形成装置１０２に対して通信方式の切り替えを指示する処理である。サーバ指示制御処理の詳細については、図７を参照して説明する。

上記ステップＳ６０２における判断処理で、コマンド解析・実施部５１０が、受信された情報がサーバ指示問合せでないと判断した場合は、処理がステップＳ６０５に進む。続いて、コマンド解析・実施部５１０が、受信された情報がサーバ指示の実施結果であるかを判断する（ステップＳ６０５）。

コマンド解析・実施部５１０が、受信された情報がサーバ指示の実施結果でないと判断した場合は、処理がステップＳ６０９に進む。そして、管理サーバ１０６が備える所定の処理部が、受信された情報に基づいて、各種情報処理を行う（ステップＳ６０９）。

コマンド解析・実施部５１０が、受信された情報が、画像形成装置１０２によるサーバ指示の実施結果であると判断した場合は、処理がステップＳ６０７に進む。そして、コマンド解析・実施部５１０が、サーバ指示の実施結果に基づいて、画像形成装置１０２がサーバ指示に応じた処理の実行に成功したかを判断する（ステップＳ６０６）。すなわち、コマンド解析・実施部５１０は、通信部５０１から受けたサーバ指示に応じた処理を実行した画像形成装置１０２から返される処理の実行結果に基づいて、処理の実行が成功したかを判断する。

コマンド解析・実施部５１０が、画像形成装置１０２がサーバ指示に応じた処理の実行に失敗したと判断した場合は、処理がステップＳ６０８に進む。そして、通知管理部５０４が、サーバ指示が失敗したことをユーザに通知する（ステップＳ６０８）。

コマンド解析・実施部５１０が、画像形成装置１０２がサーバ指示に応じた処理の実行に成功したと判断した場合は、処理がステップＳ６０７に進む。そして、通信部５０１が、通信切断処理を行う（ステップＳ６０７）。通信切断処理の詳細については、図８を参照して説明する。

図７は、図６のステップＳ６０４におけるサーバ指示制御処理の例を説明するフローチャートである。
コマンド生成部５１１が、サーバ指示が通信切り替え指示であるかを判断する（ステップＳ７０１）。通信切り替え指示は、画像形成装置１０２に対する指示であって、管理サーバ１０６との通信の通信方式をプッシュ通信に切り替える指示である。プッシュ通信は、画像形成装置１０２の要求なしに管理サーバ１０６から指示が可能となる所定の通信方式である。

コマンド生成部５１１が、サーバ指示が通信切り替え指示であると判断した場合、コマンド生成部５１１は、画像形成装置１０２からのサーバ指示問合せのレスポンスに通信切り替え指示を設定する（ステップＳ７０２）。通信部５０１が、このレスポンスを画像形成装置１０２に返す。ステップＳ７０１で判断した結果、サーバ指示が通信切り替え指示でない場合、コマンド生成部５１１は、画像形成装置１０２からのサーバ指示問合せのレスポンスにその他のサーバ指示を設定する（ステップＳ７０３）。

図８は、図６のステップＳ６０７における通信切断処理の例を説明するフローチャートである。
通信部５０１が、画像形成装置１０２とプッシュ通信中であるかを判断する（ステップＳ８０１）。通信部５０１が、画像形成装置１０２とプッシュ通信中でないと判断した場合は、通信切断処理を終了する。通信部５０１が、画像形成装置１０２とプッシュ通信中であると判断した場合は、通信部５０１は、プッシュ通信を切断する（ステップＳ８０２）。この通信切断処理によれば、必要な時だけプッシュ通信を行い、必要なくなったらセッションを切断することで、プッシュ通信によってかかる管理サーバ１０６の負荷を軽減することができる。

図９は、実施例１における画像形成装置の動作処理の例を説明するフローチャートである。
まず、画像形成装置１０２が、管理サーバ１０６に対して、サーバ指示問合せを行う（ステップＳ９０１）。具体的には、画像形成装置１０２が備える通信部４０１が、管理サーバ１０６が備える通信部５０１に対してサーバ指示問合せを送信する。この例では、画像形成装置１０２は、ｈｔｔｐプロトコルのｇｅｔリクエストを管理サーバ１０６に送信することによって、サーバ指示問合せを実行する。すなわち、画像形成装置１０２は、自分に対する指示があるかを管理サーバ１０６に問合せる。この問合せはある一定間隔で行われる。

次に、画像形成装置１０２が、管理サーバ１０６から、サーバ指示問合せに対するレスポンスを受信する（ステップＳ９０２）。サーバ指示問合せに対するレスポンスに通信切り替え指示が含まれる場合には、画像形成装置１０２が備える通信部４０１は、サーバ指示問合せの応答として通信切り替え指示を受信する。続いて、画像形成装置１０２が、上記ステップＳ９０２において受信したレスポンスをコマンド解析・実施部４０８で解析し、レスポンスに含まれるサーバ指示が通信切り替え指示であるかを判断する（ステップＳ９０３）。

レスポンスに含まれるサーバ指示が通信切り替え指示である場合、画像形成装置１０２は、コマンド解析・実施部４０８によって通信切り替えを実施し（ステップＳ９０４）、ステップＳ９０５に進む。具体的には、コマンド解析・実施部４０８および通信部４０１が、通信切り替え指示に従って、以下の処理を実行する。管理サーバ１０６と通信切り替え指示に応じた初期通信を行うことによって、画像形成装置１０２と管理サーバ１０６との通信の通信方式が、プッシュ通信に切り替わる。

通信切り替えは、例えば、以下のようにして実行される。まず、画像形成装置１０２が、管理サーバ１０６と初期通信を行う。この例では、初期通信は、ＷｅｂＳｏｃｋｅｔハンドシェークというＨＴＴＰリクエストにより行われる。具体的には、画像形成装置１０２が備えるブラウザなどのアプリケーションが、ＷｅｂＳｏｃｋｅｔハンドシェークを管理サーバ１０６に送信する（ハンドシェーク要求を行う）。管理サーバ１０６が、ブラウザからのハンドシェーク要求に対してハンドシェーク応答を返すことにより、ＷｅｂＳｏｃｋｅｔの接続が確立、すなわちプッシュ通信が確立する。プッシュ通信が確立された後、管理サーバ１０６のコマンド生成部５１１および通信部５０１が、画像形成装置１０２に対する指示（サーバ指示）を、上記確立されたプッシュ通信を用いて行うことになる。

レスポンスに含まれるサーバ指示が通信切り替え指示でない場合、画像形成装置１０２はコマンド解析・実施部４０８によってサーバ指示を実施し（ステップＳ９０６）、ステップＳ９０５に進む。そして、画像形成装置１０２が、実施結果を管理サーバ１０６に送信して（ステップＳ９０５）、処理を終了する。図９を参照して説明した処理によれば、管理サーバ１０６は、画像形成装置１０２へリアルタイムに指示をかけ、実施結果を取得することができる。

本実施例では管理サーバ１０６がユーザから受け付けた通信切り替え指示を画像形成装置１０２に実施させ、サーバ、クライアント間の通信方式をプッシュ通信に切り替えるまでの処理を説明してきた。また、管理サーバ１０６、画像形成装置１０２の構成、ソフトモジュールの構成、情報テーブル、登録確認からの監視サービス開始に関するフローを示してきたが、これらは一例であり、これに限るものではない。

実施例１における管理サーバ１０６は、画像形成装置との通信の通信方式を、画像形成装置からの要求なしに画像形成装置へ指示できるプッシュ通信に切り替え可能である。また、管理サーバ１０６は、所定の場合にのみ画像形成装置１０２とプッシュ通信で通信する。したがって、管理サーバ１０６によれば、画像形成装置１０２との間の通信セッションの維持のための負荷を抑えつつ、効率的な双方向通信を実現することができる。

（実施例２）
実施例２においては、管理サーバ１０６が、管理サーバ１０６の記憶部５０２内に登録されているサーバ指示の内容に基づいて、プッシュ通信に切り替えるか否かを判断する。

図１０は、管理サーバが保持するサーバ指示の内容の一例を示す図である。順番は、画像形成装置１０２に実施させる順番を示す。サーバ指示内容は、サーバ指示の内容を示す。

スケジュール変更要求は、画像形成装置１０２が管理サーバ１０６に対してデバイス情報を送信するタイミングの変更を求める要求である。再起動要求は、画像形成装置１０２の再起動を求める要求である。設定情報送信要求は、画像形成装置１０２の設定情報の送信を求める要求である。監視対象追加要求は、画像形成装置１０２に監視対象の追加を求める要求である。ファームウェアアップ要求は、画像形成装置１０２のファームウェアのアップデートを求める要求である。

図１１は、実施例２におけるサーバ指示制御処理の例を説明するフローチャートである。実施例２における管理サーバ１０６の全体動作処理は、図６に示すフローチャートに対応する全体動作処理と同様である。図１１に示すフローチャートは、図６のステップＳ６０４の処理に対応する。

管理サーバ１０６のコマンド生成部５１１が、サーバ指示の内容を確認する（ステップＳ１１０１）。サーバ指示の内容は、例えば図１０に示される内容である。
次に、コマンド生成部５１１が、画像形成装置１０２に対して通信切り替え指示を行う必要があるかを判断する（ステップＳ１１０２）。具体的には、コマンド生成部５１１は、プッシュ通信で行う必要のあるサーバ指示があるかを判断する。プッシュ通信で行う必要のあるサーバ指示は、障害が発生した時等、即座に復旧させるために画像形成装置１０２に対してリアルタイムに行う必要がある指示である。例えば、ファームウェアアップ要求が、プッシュ通信で行う必要のあるサーバ指示である。プッシュ通信で行う必要のあるサーバ指示がある場合、コマンド生成部５１１は、画像形成装置１０２に対して通信切り替え指示を行う必要があると判断して、処理がステップＳ１１０３に進む。

上記ステップＳ１１０２において、コマンド生成部５１１が、画像形成装置に対して行うサーバ指示が複数ある場合に、画像形成装置１０２に対して通信切り替え指示を行う必要があると判断してもよい。この判断により、画像形成装置１０２からの問合せをサーバ指示の数分だけ待機する分の時間を省略できるといったメリットがある。また、コマンド生成部５１１が、再起動要求がある場合、つまり画像形成装置１０２の再起動が必要である場合に、画像形成装置１０２に対して通信切り替え指示を行う必要があると判断してもよい。

すなわち、コマンド生成部５１１および通信部５０１は、サーバ指示が複数ある場合、リアルタイムに行う必要がある指示がある場合、及び画像形成装置１０２の再起動が必要である場合などに、通信切り替え指示を送信する。

次に、コマンド生成部５１１が、画像形成装置１０２からのサーバ指示問合せのレスポンスに、通信切り替え指示を設定し（ステップＳ１１０３）、通信部５０１を介してレスポンスを画像形成装置１０２に送信する。

プッシュ通信へ切り替える必要のあるサーバ指示がない場合、コマンド生成部５１１は、画像形成装置１０２に対して通信切り替え指示を行う必要がないと判断して、処理がステップＳ１１０４に進む。そして、コマンド生成部５１１が、画像形成装置１０２からのサーバ指示問合せのレスポンスに、その他のサーバ指示を設定し（ステップＳ１１０４）、通信部５０１を介してレスポンスを画像形成装置１０２に送信する。

本実施例では、サーバ指示の内容に基づいて管理サーバ１０６が通信切り替えの判断を行うことを説明したが、これに限るものではない。例えば、コマンド生成部５１１は、対象となる画像形成装置１０２の重要度に基づいて通信の切り替えを判断してもよい。また、コマンド生成部５１１は、画像形成装置１０２が属する顧客との契約内容を含む顧客情報に基づいて通信の切り替えを判断してもよい。

また、通信切断処理で用いる所定の条件が、ユーザ装置からプッシュ通信の切断要求を受けたことを含むようにしてもよい。

図１２は、実施例２における通信切断処理の例を説明するフローチャートである。図１２に示すフローチャートは、図６のステップＳ６０７の処理に対応する。
通信部５０１が、記憶部５０２にサーバ指示が残っているかを判断する（ステップＳ１２０１）。通信部５０１が、記憶部５０２にサーバ指示が残っていると判断した場合、通信部５０１が、サーバ指示の内容を確認する（ステップＳ１２０２）。そして、通信部５０１が、サーバ指示がプッシュ通信で行う必要のあるサーバ指示であるかを判断する（ステップＳ１２０３）。サーバ指示がプッシュ通信で行う必要のあるサーバ指示である場合、通信切断処理を終了する。サーバ指示がプッシュ通信で行う必要のあるサーバ指示でない場合は、処理が、ステップＳ１２０４に進む。

上記ステップＳ１２０１の判断処理において、通信部５０１が、記憶部５０２にサーバ指示が残っていないと判断した場合は、処理がステップＳ１２０４に進む。そして、通信部５０１が、画像形成装置１０２とプッシュ通信中であるかを判断する（ステップＳ１２０４）。通信部５０１が、画像形成装置１０２とプッシュ通信中でないと判断した場合は、通信切断処理を終了する。通信部５０１が、画像形成装置１０２とプッシュ通信中であると判断した場合は、通信部５０１は、プッシュ通信を切断する（ステップＳ１２０５）。

実施例２における通信切断処理によれば、管理サーバ１０６が、プッシュ通信への切り替えが必要であると判定するための条件に従い、画像形成装置１０２との通信方式をプッシュ通信に切り換えることが可能となる。また、プッシュ通信の必要がなくなった場合はプッシュ通信を切断する（通信方式を戻す）ことでサーバリソースを増やさずに効率的な双方向通信が可能となる。

本実施例では、管理サーバ１０６がユーザより受け付けたサーバ指示の内容によりプッシュ通信へ切り替えるか否かを判断する処理と、プッシュ通信の必要がない場合に通信切断する処理を説明した。また、管理サーバ１０６による通信切り替え判断、通信切断判断の基準について、サーバ指示の内容を例に挙げて説明してきたが、これは一例であり、通信切り替え判断、通信切断判断の基準は、サーバ指示の内容に限定されない。

（実施例３）
実施例３においては、画像形成装置１０２に障害が発生したタイミングで、画像形成装置１０２側から管理サーバ１０６に対して通信切り替えを実施する。このために、画像形成装置１０２は、障害一覧を記憶装置２０４に保持する。障害一覧は、画像形成装置１０２に発生する障害に関する情報である。

図１３は、実施例３における画像形成装置が保持する障害一覧の例を示す図である。障害一覧は、障害コードとサービスマン派遣の要／不要といったデータ項目を有する。障害コードは、障害を一意に識別する識別情報である。サービスマン派遣の要／不要は、当該障害が発生した場合にサービスマンの派遣が必要か不要かを示す。サービスマン派遣の要／不要に設定された「不要」は、当該障害が発生した場合にサービスマン派遣が不要であることを示す。サービスマンの派遣が不要な障害は、画像形成装置１０２の再起動や、ファームウェアのアップデートによって復旧する障害である。すなわち、サービスマンの派遣が不要な障害が発生した場合、当該障害を復旧させるために行うサーバ指示は、プッシュ通信で行う必要があるサーバ指示である。サービスマン派遣の要／不要に設定された「要」は、当該障害が発生した場合にサービスマン派遣が必要であることを示す。

図１４は、実施例３における画像形成装置の動作処理の例を説明するフローチャートである。
まず、画像形成装置１０２が、自身に発生した障害、または障害からの復旧を検知する（ステップＳ１４０１）。すなわち、画像形成装置１０２が備える所定の処理部（例えば、デバイス情報制御部４０４）が、画像形成装置１０２において発生した障害を検知する。続いて、画像形成装置１０２が備える通信部４０１が、検知した障害に関する情報（障害情報）または復旧に関する情報（復旧情報）を管理サーバ１０６に送信する（ステップＳ１４０２）。

次に、画像形成装置１０２が備えるコマンド解析・実施部４０８が、障害が検知され、かつ、当該障害を復旧させるために行うサーバ指示が、プッシュ通信で行う必要があるサーバ指示であるかを判断する（ステップＳ１４０３）。具体的には、画像形成装置１０２が、図１３に示す障害一覧を参照し、検知された障害の障害コードに対応するサービスマン派遣の要／不要に「不要」が設定されているかを判断する。検知された障害の障害コードに対応するサービスマン派遣の要／不要に「不要」が設定されている場合、画像形成装置１０２は、当該障害を復旧させるために行うサーバ指示が、プッシュ通信で行う必要があるサーバ指示であると判断する。検知された障害の障害コードに対応するサービスマン派遣の要／不要に「要」が設定されている場合、画像形成装置１０２は、当該障害を復旧させるために行うサーバ指示が、プッシュ通信で行う必要がないサーバ指示であると判断する。

障害が検知され、かつ、検知された障害を復旧させるために行うサーバ指示が、プッシュ通信で行う必要があるサーバ指示である場合は、処理がステップＳ１４０４に進む。そして、画像形成装置１０２が、管理サーバ１０６との間の通信の通信方式をプッシュ通信に切り替える処理を開始する（ステップＳ１４０４）。そして、画像形成装置１０２が、通信方式の切り替えの実施結果を管理サーバ１０６へ送信し（ステップＳ１４０５）、処理を終了する。

障害が検知されなかった場合、または検知された障害を復旧させるために行うサーバ指示が、プッシュ通信で行う必要がないサーバ指示である場合は、処理がステップＳ１４０６に進む。

次に、画像形成装置１０２が、障害からの復旧が検知されたかを判断する（ステップＳ１４０６）。障害からの復旧が検知されなかった場合は、処理を終了する。障害からの復旧が検知された場合は、処理がステップＳ１４０７に進む。続いて、画像形成装置１０２が、管理サーバ１０６とプッシュ通信中であるかを判断する（ステップＳ１４０７）。管理サーバ１０６とプッシュ通信中でない場合は、処理を終了する。管理サーバ１０６とプッシュ通信中である場合は、処理がステップＳ１４０８に進む。そして画像形成装置１０２が、プッシュ通信を切断して（ステップＳ１４０８）、処理を終了する。

図１４を参照して説明した処理によれば、画像形成装置１０２に障害が発生した場合に、プッシュ通信によりリアルタイム処理が可能となり、迅速な対応によりユーザのダウンタイムを軽減することができる。また、画像形成装置１０２が障害から復旧したタイミングでプッシュ通信を切断することで、無駄なサーバリソース消費を防ぐことができる。本実施例では、画像形成装置１０２が、自身に発生した障害の種類に応じて、管理サーバ１０６との通信方式を切り替える処理について説明したが、通信方式を切り替える判断基準は、障害の種類に限られない。

（実施例４）
実施例４における管理サーバは、画像形成装置１０２にプッシュ通信機能が無い、または、画像形成装置１０２が管理サーバからの切り替え指示に応じた通信方式の切り替えに対応していない場合に、画像形成装置１０２のファームウェアをアップデートさせる。これによりプッシュ通信を可能とする。

図１５は、実施例４における管理サーバの全体動作処理の例を説明するフローチャートである。図１５のステップＳ１５０１乃至Ｓ１５０７は、図６のステップＳ６０１乃至Ｓ６０７と同様である。また、図１５のステップＳ１５１２は、図６のステップＳ６０９と同様である。

実施例４では、ステップＳ１５０６の判断処理で、コマンド解析・実施部５１０が、画像形成装置１０２がサーバ指示に応じた処理の実行に失敗したと判断した場合に、処理がステップＳ１５０８に進む。具体的には、管理サーバからのプッシュ通信への通信方式の切り替え指示を受けた画像形成装置からの失敗を示す通知を受けた場合などに、ステップＳ１５０８に進む。

続いて、コマンド生成部４０７が、画像形成装置１０２がサーバ指示に応じた処理の実行に失敗した原因を特定する。コマンド生成部４０７は、特定した原因が、画像形成装置１０２のファームウェアが、プッシュ通信に対応していない、または、管理サーバからの切り替え指示に応じた通信方式の切り替えに対応していないことであるかを判断する（ステップＳ１５０８）。ここで、プッシュ通信に対応していない、または、管理サーバからの切り替え指示に応じた通信方式の切り替えに対応していない場合（ステップＳ１５０８でＹｅｓ）は、処理がステップＳ１５０９に進む。ステップＳ１５０８でＮｏと判定された場合には、処理がステップＳ１５１１に進む。そして、通信部５０１が、画像形成装置１０２がサーバ指示に応じた処理の実行に失敗したことをユーザに通知し（ステップＳ１５１１）、処理が終了する。

ステップＳ１５０９では、コマンド生成部４０７が、ファームアップ要求を発行する。このファームアップ要求を受けた画像形成装置１０２は、各種ファームウェアを管理する配信サーバ（不図示）から、所望のファームウェアをダウンロードして、適用することでファームアップを実現する。続いて、コマンド生成部４０７がサーバ指示として通信切り替え指示を記憶部５０２に追加し（ステップＳ１５１０）、処理が終了する。

図１５を参照して説明した処理によれば、画像形成装置１０２にプッシュ通信機能が無くても、ファームウェアをアップデートさせることで、プッシュ通信が可能となる。

（実施例５）
実施例５においては、管理サーバ１０６が、画像形成装置１０２とプッシュ通信を行っている最中は、ユーザに、プッシュ通信中であることを通知する。

図１６は、実施例５における管理サーバが表示する画面の例を示す図である。管理サーバ１０６が備える表示部５０９は、画像形成装置１０２との通信方式がプッシュ通信である場合は、図１６中の符号１６０１に示すように、ポータル画面にプッシュ通信中（図中では“Ｗｅｂ Ｓｏｃｋｅｔ通信中”）であることを表示（ユーザに提供）する。また、符号１６０２に示すように、プッシュ通信中である画像形成装置１０２をハイライト表示する。この表示部５０９の機能により、ユーザは、画像形成装置１０２に対して、リアルタイム処理が可能であるかどうかを画面にて判断することができる。本実施例では、プッシュ通信中であることを画面の表示でユーザに知らせると説明してきたが、メールによる通知などでも良い。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

１０１ ＬＡＮ
１０２ 画像形成装置
１０３ Ｐｒｏｘｙ Ｓｅｒｖｅｒ
１０４ Ｆｉｒｅｗａｌｌ
１０５ ＰＣ
１０６ 管理サーバ
１０７ イントラネット
１０８ インターネット

Claims (18)

1. 画像形成装置を管理するインターネット上の管理装置であって、
   前記画像形成装置から問合せを受信する受信手段と、
   前記画像形成装置と前記管理装置との通信の通信方式を前記画像形成装置の要求なしに前記管理装置から指示が可能となる所定の通信方式に切り替える切り替え指示を、前記受信された問合せの応答として前記画像形成装置に送信する送信手段と、
   前記画像形成装置と前記切り替え指示に応じた初期通信を行うことで、前記所定の通信方式が確立された後に、前記画像形成装置に対する指示を前記確立された所定の通信方式により行う指示手段と、
   所定の条件に従い、前記所定の通信方式による通信を切断する切断手段と、を有することを特徴とする管理装置。
2. 前記画像形成装置に対して行うべき指示を蓄積する蓄積手段をさらに有し、
   前記送信手段は、前記蓄積手段により蓄積された前記指示が複数ある場合、前記蓄積手段により蓄積された前記指示にリアルタイムに前記画像形成装置に対して行う必要がある指示が含まれる場合、及び前記画像形成装置の再起動が必要である場合のうちの少なくともいずれかの場合に、前記切り替え指示を送信することを特徴とする請求項１に記載の管理装置。
3. 前記送信手段は、前記画像形成装置の顧客との契約内容を含む顧客情報に基づいて前記切り替え指示を送信するかを判断し、前記切り替え指示を送信すると判断した場合に該切り替え指示を送信することを特徴とする請求項１に記載の管理装置。
4. 前記切断手段は、前記指示手段による指示に応じた処理を実行した前記画像形成装置からの前記処理の実行結果を受信した際に、前記画像形成装置との前記所定の通信方式による通信を切断することを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。
5. 前記切断手段は、前記処理の実行結果が該処理の成功を示す際に、前記画像形成装置に対して前記所定の通信方式で行うべき他の指示がない場合に、前記画像形成装置との前記所定の通信方式による通信を切断することを特徴とする請求項４に記載の管理装置。
6. 前記指示手段は、前記所定の通信方式、または前記切り替え指示に応じた前記所定の通信方式への切り替えに対応していない前記画像形成装置に対して、前記所定の通信方式への切り替えが可能となるように、前記画像形成装置からの問合せに応答してファームウェアのアップデートの指示を送信することを特徴とする請求項１乃至５のいずれか１項に記載の管理装置。
7. 前記画像形成装置との間で、前記所定の通信方式が確立していることを示す情報を、ユーザに提供する提供手段をさらに有することを特徴とする請求項１乃至６のいずれか１項に記載の管理装置。
8. 前記所定の条件は、ユーザ装置から前記所定の通信方式による通信の切断要求を受けたことを含むことを特徴とする請求項１乃至７のいずれか１項に記載の管理装置。
9. 前記所定の通信方式は、ＷｅｂＳｏｃｋｅｔプロトコルであり、
   前記初期通信は、前記ＷｅｂＳｏｃｋｅｔプロトコルによる通信を確立するためのハンドシェークであることを特徴とする請求項１乃至８のいずれか１項に記載の管理装置。
10. 前記画像形成装置から受信される問合せは、ｈｔｔｐプロトコルのｇｅｔリクエストであることを特徴とする請求項１乃至９のいずれか１項に記載の管理装置。
11. 画像形成装置を管理するインターネット上の管理装置における制御方法であって、
    前記画像形成装置から問合せを受信する工程と、
    前記画像形成装置と前記管理装置との通信の通信方式を前記画像形成装置の要求なしに前記管理装置から指示が可能となる所定の通信方式に切り替える切り替え指示を、前記受信された問合せの応答として前記画像形成装置に送信する工程と、
    前記画像形成装置と前記切り替え指示に応じた初期通信を行うことで、前記所定の通信方式が確立された後に、前記画像形成装置に対する指示を前記確立された所定の通信方式により行う工程と、
    所定の条件に従い、前記所定の通信方式による通信を切断する工程と、を有することを特徴とする制御方法。
12. 請求項１乃至８のいずれか１項に記載の手段としてコンピュータを機能させるためのプログラム。
13. ネットワークデバイスと、当該ネットワークデバイスを管理するインターネット上の管理装置とを備える管理システムであって、
    前記管理装置は、
    前記ネットワークデバイスから問合せを受信する受信手段と、
    前記ネットワークデバイスと前記管理装置との通信の通信方式を、前記ネットワークデバイスの要求なしに前記管理装置から指示が可能となる所定の通信方式に切り替える切り替え指示を、前記受信された問合せの応答として前記ネットワークデバイスに送信する送信手段と、
    前記ネットワークデバイスと前記切り替え指示に応じた初期通信を行うことで、前記所定の通信方式が確立された後に、前記ネットワークデバイスに対する指示を前記確立された所定の通信方式により行う指示手段と、を有し、
    前記ネットワークデバイスは、
    前記管理装置に対する指示の問合せの応答として、前記切り替え指示を受信する受信手段と、
    前記受信された切り替え指示に従って、前記管理装置と前記所定の通信方式のための初期通信を行うことによって、前記ネットワークデバイスと前記管理装置との間で前記所定の通信方式を確立する確立手段と、を有することを特徴とする管理システム。
14. 前記管理装置は、前記ネットワークデバイスに対して行うべき指示を蓄積する蓄積手段をさらに有し、
    前記送信手段は、前記蓄積手段により蓄積された前記指示が複数ある場合、前記蓄積手段により蓄積された前記指示にリアルタイムに前記ネットワークデバイスに対して行う必要がある指示が含まれる場合、及び前記ネットワークデバイスの再起動が必要である場合のうちの少なくともいずれかの場合に、前記切り替え指示を送信することを特徴とする請求項１３に記載の管理システム。
15. 前記ネットワークデバイスは、さらに、
    前記ネットワークデバイスにおいて発生した障害を検知する検知手段と、
    前記検知された障害を復旧させるために行う前記管理装置からの指示が、前記所定の通信方式を利用する必要があるかを判断する判断手段と、を有し、
    前記確立手段は、前記検知された障害を復旧させるために行う前記管理装置からの指示が、前記所定の通信方式を利用する必要があると判断された場合に、前記ネットワークデバイスと前記管理装置との間で前記所定の通信方式を確立することを特徴とする請求項１３または１４に記載の管理システム。
16. ネットワークデバイスと、当該ネットワークデバイスを管理するインターネット上の管理装置とを備える管理システムにおける制御方法であって、
    前記管理装置が、前記ネットワークデバイスから問合せを受信する受信工程と、
    前記管理装置が、前記ネットワークデバイスと前記管理装置との通信の通信方式を、前記ネットワークデバイスの要求なしに前記管理装置から指示が可能となる所定の通信方式に切り替える切り替え指示を、前記受信された問合せの応答として前記ネットワークデバイスに送信する送信工程と、
    前記管理装置が、前記ネットワークデバイスと前記切り替え指示に応じた初期通信を行うことで、前記所定の通信方式が確立された後に、前記ネットワークデバイスに対する指示を前記確立された所定の通信方式により行う指示工程と、
    前記ネットワークデバイスが、前記管理装置に対する指示の問合せの応答として、前記切り替え指示を受信する受信工程と、
    前記ネットワークデバイスが、前記受信された切り替え指示に従って、前記管理装置と前記所定の通信方式のための初期通信を行うことによって、前記ネットワークデバイスと前記管理装置との間で前記所定の通信方式を確立する確立工程と、を有することを特徴とする制御方法。
17. 前記管理装置が、前記ネットワークデバイスに対して行うべき指示を蓄積する蓄積工程をさらに有し、
    前記送信工程では、前記蓄積工程により蓄積された前記指示が複数ある場合、前記蓄積工程により蓄積された前記指示にリアルタイムに前記ネットワークデバイスに対して行う必要がある指示が含まれる場合、及び前記ネットワークデバイスの再起動が必要である場合のうちの少なくともいずれかの場合に、前記切り替え指示を送信することを特徴とする請求項１６に記載の制御方法。
18. 前記ネットワークデバイスにおいて発生した障害を検知する検知工程と、
    前記検知された障害を復旧させるために行う前記管理装置からの指示が、前記所定の通信方式を利用する必要があるかを判断する判断工程と、を有し、
    前記確立工程では、前記検知された障害を復旧させるために行う前記管理装置からの指示が、前記所定の通信方式を利用する必要があると判断された場合に、前記ネットワークデバイスと前記管理装置との間で前記所定の通信方式を確立することを特徴とする請求項１６または１７に記載の制御方法。
    

Images