(57)【特許請求の範囲】
【請求項１】
ネットワークに接続された複数の画像形成装置と、前記画像形成装置からの情報を送受信するクラウドサーバとを有するネットワークシステムにおいて、
前記画像形成装置は、
装置情報を保存する装置情報保存部と、
前記クラウドサーバに前記装置情報を送信するとともに、前記クラウドサーバからの情報を受信する送信部と、
前記クラウドサーバからの情報に基づいて装置動作を制御する制御部とを備え、
前記クラウドサーバは、
複数の前記画像形成装置のそれぞれに対応付けられたユーザ情報を保存するユーザ情報保存部と、
複数の前記画像形成装置の何れかから、保守的管理が必要な事象が発生したときに送信された前記装置情報から送信元の画像形成装置を特定するとともに、当該画像形成装置に対応した保守情報を送信元の画像形成装置に送信させる解析部とを備え、
前記制御部は、前記クラウドサーバから受信した前記保守情報に基づいて装置動作を制御するものであって、
前記保守情報には保守的管理が必要な事象を解決する複数の解決方法が含まれ、
前記解析部は、
前記画像形成装置に対する前記解決方法の適用順番を決定し、一の解決方法の成否を確認しながら前記画像形成装置に対して前記保守情報を送信させること
を特徴とするネットワークシステム。
【請求項２】
前記装置情報には前記画像形成装置を識別するための識別情報が含まれ、
前記解析部は、
前記識別情報と前記ユーザ情報とから前記画像形成装置を特定すること
を特徴とする請求項１に記載のネットワークシステム。
【請求項３】
前記ユーザ情報には前記画像形成装置の使用環境に関する情報が含まれ、
前記解析部は、
前記前記画像形成装置の使用環境に応じて、前記画像形成装置に対する前記解決方法の適用順番を決定することを特徴とする請求項１又は請求項２に記載のネットワークシステム。
【請求項４】
保守的管理が必要な事象とは、ネットワークにおける名前解決に係る事象であること
を特徴とする請求項１乃至請求項３の何れか１項に記載のネットワークシステム。
【請求項５】
前記解析部は、ユーザが使用する前記画像形成装置が所属するネットワークの規模に応じてＤＮＳサーバによる要因分析を他の要因分析に優先して実行するか否かを決定すること
を特徴とする請求項４に記載のネットワークシステム。
【請求項６】
前記解析部は、ユーザが使用する前記画像形成装置が所属するネットワークの規模が所定の規模より大きい場合に、ＤＮＳサーバによる要因分析を他の要因分析に優先して実行するか否かを決定すること
を特徴とする請求項５に記載のネットワークシステム。
【請求項７】
前記解析部は、ユーザが使用する前記画像形成装置が所属するネットワークの規模が所定の規模より小さい場合に、ＮｅｔＢＩＯＳによる要因分析を他の要因分析に優先して実行するか否かを決定すること
を特徴とする請求項５に記載のネットワークシステム。
【請求項８】
前記画像形成装置は原稿を読み取ることにより画像データを生成する読取機能を有し、
保守的管理が必要な事象とは、ネットワーク上の情報処理装置に対する前記画像データの格納障害であること
を特徴とする請求項１乃至請求項７の何れか１項に記載のネットワークシステム。
【請求項９】
ネットワークを介して接続されたクラウドサーバから受信した情報に基づき装置動作を制御する制御部と、
保守的管理が必要な事象が発生したときに装置情報を前記クラウドサーバに対して送信する送信部とを備える画像形成装置であって、
前記クラウドサーバは、前記装置情報から送信元の前記画像形成装置を特定するとともに、当該画像形成装置に対応するものであって、保守的管理が必要な事象を解決する複数の解決手段を含み、その適用順番が決定された保守情報を一の解決方法の成否を確認しながら送信元の前記画像形成装置に送信させる解析部を有し、
前記制御部は、前記クラウドサーバから受信した前記保守情報に基づいて装置動作を制御すること
を特徴とする画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステム及び画像形成装置に関するものである。
【背景技術】
【０００２】
従来から、原稿を読み取ることにより生成した画像データをネットワークを介して接続されたコンピュータ等の情報処理装置上の共有フォルダに格納することが可能な画像形成装置が知られている。
【０００３】
特許文献１には、画像形成装置としてのスキャナ装置のユーザが、送信先に指定するコンピュータの状態を意識することなく画像データたるスキャンデータを確実に送信し、保存させることができるとするスキャナ装置について記載がなされている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−９４４４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、例えば、情報処理装置に設けられた共有フォルダに対する画像データの格納が失敗した場合、その原因をユーザが特定することは容易ではなかった。このように、ネットワークに接続された画像形成装置において、例えば、接続不良といった保守的管理が必要な事象が発生した場合、その障害を把握し、原因を特定、解決に導くためには、画像形成装置の製造会社が提供するサービスセンタに問い合わせる、保守要員の派遣を要請するといった、ユーザにとって煩わしい手間を要するものであった。
【０００６】
ところで、昨今の画像形成装置はイントラネット、インターネット問わず、ネットワーク回線に接続されて利用される形態が主であり、複数台の画像形成装置が常時ネットワーク上に存在している。これらの画像形成装置の型番、使用環境等はそれぞれ異なるものであり、これらの画像形成装置において、上記事象が発生した場合、各画像形成装置に応じた原因解決方法を柔軟に提供することができるネットワークシステムは構築されていなかったのが現状である。
【０００７】
本発明はこのような実状に鑑みてなされたものであり、本発明の課題は、ネットワークに接続された複数の画像形成装置において、例えば、接続不良といった保守的管理が必要な事象が発生した場合において、当該画像形成装置に対応した原因解決方法を提供することが可能なネットワークシステムを提供することである。
【０００８】
上記課題を解決するために、本発明に係るネットワークシステムは、ネットワークに接続された複数の画像形成装置と、前記画像形成装置からの情報を送受信するクラウドサーバとを有するネットワークシステムにおいて、前記画像形成装置は、装置情報を保存する装置情報保存部と、前記クラウドサーバに前記装置情報を送信するとともに、前記クラウドサーバからの情報を受信する送信部と、前記クラウドサーバからの情報に基づいて装置動作を制御する制御部とを備え、前記クラウドサーバは、複数の前記画像形成装置のそれぞれに対応付けられたユーザ情報を保存するユーザ情報保存部と、複数の前記画像形成装置の何れかから、保守的管理が必要な事象が発生したときに送信された前記装置情報から送信元の画像形成装置を特定するとともに、当該画像形成装置に対応した保守情報を送信元の画像形成装置に送信させる解析部とを備え、前記制御部は、前記クラウドサーバから受信した前記保守情報に基づいて装置動作を制御するものであって、前記保守情報には保守的管理が必要な事象を解決する複数の解決方法が含まれ、前記解析部は、前記画像形成装置に対する前記解決方法の適用順番を決定し、一の解決方法の成否を確認しながら前記画像形成装置に対して前記保守情報を送信させることを特徴としている。
【０００９】
また、本発明に係る画像形成装置は、ネットワークを介して接続されたクラウドサーバから受信した情報に基づき装置動作を制御する制御部と、保守的管理が必要な事象が発生したときに装置情報を前記クラウドサーバに対して送信する送信部とを備える画像形成装置であって、前記クラウドサーバは、前記装置情報から送信元の前記画像形成装置を特定するとともに、当該画像形成装置に対応するものであって、保守的管理が必要な事象を解決する複数の解決手段を含み、その適用順番が決定された保守情報を一の解決方法の成否を確認しながら送信元の前記画像形成装置に送信させる解析部を有し、前記制御部は、前記クラウドサーバから受信した前記保守情報に基づいて装置動作を制御することを特徴としている。
【発明の効果】
【００１０】
本発明によれば、ネットワークに接続された複数の画像形成装置において、保守的管理が必要な事象が発生した場合においても、当該画像形成装置に対応した原因解決方法を提供することが可能なネットワークシステム及び画像形成装置を提供することができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態に係るネットワークシステムの接続形態を説明する図である。
【図２】本実施形態に係るスキャナの構成を説明する概略構成図である。
【図３】パネル部としてのオペレータパネルの構成例を示す図である。
【図４】本実施形態に係るクラウドサービス・サーバの構成を説明する概略構成図である。
【図５】スキャナによる画像データの共有フォルダへの格納機能を説明するフローチャートである。
【図６】スキャン  Ｔｏ  共有フォルダ機能が失敗した場合において、この障害をクラウドサービス・サーバが解決する処理を説明するフローチャートである。
【図７】パネル部の表示例を説明する図である。
【図８】ユーザ情報保存部に保存されているユーザ情報を説明する図である。
【図９】解析部による解決方法の適用順番の決定方法の一形態を説明するフローチャートである。
【図１０】ログ情報の例を説明する図である。
【図１１】小規模ネットワークでの名前解決に失敗したときの解析部による障害解析の流れを説明するフローチャートである。
【図１２】ＮｅｔＢＩＯＳ、ＤＮＳサーバ、ＷＩＮＳサーバによる名前解決に失敗した際に実行される、問題の切り分けに係る処理を説明するフローチャートである。
【図１３】ＮｅｔＢＩＯＳの名前解決に失敗したときのクラウドサービス・サーバ、スキャナ、ＰＣ間で行われる通信の例を説明するシーケンス図である。
【図１４】大規模ネットワークでの名前解決に失敗したときの解析部による障害解析の流れを説明するフローチャートである。
【図１５】ＤＮＳサーバの名前解決に失敗したときのクラウドサービス・サーバ、スキャナ、ＤＮＳサーバ間で行われる通信の例を説明するシーケンス図である。
【図１６】パネル部の表示例を説明する図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態について図面を参照して説明する。なお、本実施形態の説明においては、ネットワークに接続された画像形成装置において発生した保守的管理が必要な事象として、画像形成装置たるスキャナが原稿を読み取ることにより生成した画像データを、同じくネットワーク上の情報処理装置たるＰＣ（Personal Computer）に設けられた共有フォルダに格納させる際に、格納エラーによる障害が発生した事象について説明するが、本発明は以下の記述に限定されるものではなく、本発明の要旨を逸脱しない範囲において適宜変更可能である。
【００１３】
図１は、本実施形態に係るネットワークシステム１の接続形態を説明する図である。本実施形態の説明においては、説明の便宜上、画像形成装置としてのスキャナ１０を使用するユーザが所属する所属組織が個人事業であるグループをローカルグループＡとし、同じく画像形成装置としてのスキャナ５０を使用するユーザが所属する所属組織が１００人規模であるグループをローカルグループＢとし、これらのローカルグループがインターネット４を介してクラウドサービス・サーバ４０に接続された例について説明する。
【００１４】
まず、スキャナ１０は、ＬＡＮ（Local Area network）ケーブル２を介し、ゲートウェイを通じてインターネット４に接続可能となるように構成されている。また、スキャナ１０と同様にＬＡＮケーブル２にはＰＣ２０が接続されている。ＰＣ２０には、ネットワーク経由でアクセス可能な共有フォルダが設定されており、当該共有フォルダはスキャナ１０からもアクセス可能となっている。またＬＡＮケーブル２には、ホスト名等のドメイン名とＩＰアドレスとの対応づけを管理するＤＮＳ（Domain Name System）サーバ３０が接続されており、ＬＡＮケーブル２０を介して、スキャナ１０、ＰＣ２０、ＤＮＳサーバ３０はローカルグループＡを構成する。
【００１５】
ローカルグループＢは、ローカルグループＡと同様に、スキャナ５０、ＰＣ６０、ＤＮＳサーバ７０等がＬＡＮケーブル３を介して接続されることにより構成されている。なお、ローカルグループＢに属するスキャナ５０、ＰＣ６０、ＤＮＳサーバ７０は、ローカルグループＡに属するスキャナ１０、ＰＣ２０、ＤＮＳサーバ３０と略同構成とすることができるため、以下の説明においては、ローカルグループＡを中心にして説明する。
【００１６】
ローカルグループＡ及びローカルグループＢには、インターネット４上に障害が発生した際に、その障害の解決をサポートするクラウドサービス・サーバ４０が接続されており、スキャナ１０及びスキャナ５０は当該クラウドサービス・サーバ３０にインターネット４経由で接続可能である。
【００１７】
図２は、スキャナ１０の構成を説明する概略構成図である。スキャナ１０は、送受信部１０１と、装置情報保存部としてのログ保存部１０２，設定値保存部１０３と、制御部１０４と、パネル部１０５と、スキャナ部１０６とを備える。
【００１８】
送受信部１０１は、ＬＡＮケーブル２と接続可能なネットワークカード等のインタフェースを備え、情報の送受信を行う。
【００１９】
ログ保存部１０２は、例えば、書き換え可能なフラッシュメモリ等の記憶装置を備え、スキャナ１０の動作（原稿の読み取り、画像データの送信等）の履歴を示すログ情報を保存する。
【００２０】
設定値保存部１０３は、例えば、書き換え可能なフラッシュメモリ等の記憶装置を備え、スキャナ１０が動作するために必要な設定値を保存する。ここで保存される設定値としては、スキャナ１０に割り当てられたＩＰアドレス、サブネットマスク、デフォルトゲートウェイアドレス、ホスト名の名前解決に使用されるＤＮＳサーバ３０のＩＰアドレス、ＷＩＮＳサーバのＩＰアドレス、スキャナ部１０５により生成された画像データを格納させるためのＰＣ２０上の共有フォルダへのパス情報、当該共有フォルダにアクセスするためのユーザ名とパスワード等があり得る。
【００２１】
制御部１０４は、障害の解析指示や、原稿の読み取りを行うためにパネル部１０５や、スキャナ部１０６を制御するとともに、送受信部１０１を介し、クラウドサービス・サーバ４０との情報の送受信を制御する。また、制御部１０４は、クラウドサービス・サーバ４０から送信された、後述する保守情報に基づき装置動作を制御して障害の解決を図る。
【００２２】
パネル部１０５は、例えば、ＬＣＤ（Liquid Crystal Display）等の表示手段やタッチパネル、ボタン等の情報入力手段を備え、ユーザに対する装置情報表示、操作情報の入力を受付けるオペレータパネルである。図３は、パネル部１０５としてのオペレータパネルの構成例を示す図である。パネル部１０５は、タッチパネル１２１を備え、スキャナ１０の状態等のメッセージを表示することができる。タッチパネル１２１は、ボタン１２２を表示させることができ、図３に示す例においては、原稿読み取りの詳細設定の入力を受付けるためのボタンとして「Ｏｐｔｉｏｎ  Ｓｅｔｔｉｎｇｓ」ボタンを表示させている例である。ボタン１２３は、原稿読み取り開始指示を受付けるスタートボタンであり、ボタン１２４は、障害発生時に障害の発生原因の調査を開始させる指示を受付けるヘルプボタンである。
【００２３】
スキャナ部１０６は、少なくとも原稿に光を照射する光源と、原稿により反射された光を集光するレンズと、レンズで集光された光を受光し、受光した光を電気信号に変換するＣＣＤ（Charge Coupled Device）等の光電変換素子とを備え、読み取り画像に基づく画像データを生成する。
【００２４】
ＰＣ２０は、図示せぬＣＰＵ（Central Processing Unit）や、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）等のメモリ、ネットワークカード等のＬＡＮケーブル２に接続可能な情報送受信手段を格納する本体部と、キーボード等の入力手段、液晶ディスプレイ等の表示手段を備え、オペレーティングシステムによる制御に基づき、スキャナ１０から送信された画像データを保存することができる共有フォルダを作成することが可能となるように構成されている。
【００２５】
ＤＮＳサーバ３０は、例えば、ＰＣ、専用のネットワーク機器等のハードウェア資源や専用のソフトウェア資源を用いて構築することができ、ホストの識別子（ドメイン名）とＩＰアドレスとを対応付ける。
【００２６】
クラウドサービス・サーバ４０は、例えば、ＰＣ、専用のネットワーク機器等のハードウェア資源やソフトウェア資源を用いて構築することができ、一般的には、スキャナ製造会社により提供されるクラウドサービスの一形態である。このよなクラウドサービス・サーバ４０は、図４に示すように、送受信部４０１と、ガイダンス情報保存部４０２と、ユーザ情報保存部４０３と、解析部４０４とを備える。
【００２７】
送受信部４０１は、ＬＡＮケーブルを介してインターネット４に接続可能となるように構成され、情報の送受信を行う。
【００２８】
ガイダンス情報保存部４０２は、例えば、書き換え可能なフラッシュメモリ等の記憶装置を備え、解析部４０４による障害解析の結果に基づき、スキャナに提示する情報を保存する。ガイダンス情報保存部４０２が保存する情報としては、スキャナが備えるパネル部に表示させるためのメッセージ等を挙げることができる。当該情報は、クラウドサービス・サーバ４０以外のクラウド上のサーバからの取得することができ、スキャナの障害を扱うサービスセンタや保守要員等が収集した障害事例等に基づき更新された結果が反映されるようになっている。
【００２９】
ユーザ情報保存部４０３は、例えば、書き換え可能なフラッシュメモリ等の記憶装置を備え、スキャナを購入したユーザの情報を保存する。ユーザ情報保存部４０３が保存する情報としては、例えば、はがき、電話、ＦＡＸ、スキャナ製造会社が提供するインターネット上のＷｅｂサイトを介してユーザにより登録されたユーザ自身の情報（名前、住所、電話番号、Ｅメールアドレス、職種、ユーザが所属する所属組織（規模）、スキャナの使用方法等）に加え、ユーザがサービスセンタ等に問い合わせた内容（例えば、ネットワークに接続できない、契約プロバイダを変更したら画像データを共有フォルダに格納できなくなった、等）も含まれる。
【００３０】
解析部４０４は、送受信部４０１を介して受信したログ情報をユーザ情報保存部４０３及びガイダンス情報保存部４０２に保存された情報に基づき解析し、解決方法としてのコマンドを生成する。
【００３１】
次に、本実施形態に係る動作について説明する。なお、本実施形態においては、ホスト名として、上記説明したＰＣ２０には"ＴＥＳＴ（ＩＰアドレス：１９２．１６８．１００．２）"が、クラウドサービス・サーバ４０には"ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ"がそれぞれ割り当てられており、ＤＮＳサーバ３０にはＩＰアドレスとして"１９２．１６８．１００．２００"が割り当てられているものとして説明する。
【００３２】
まず、本実施形態に係るスキャナ１０による画像データの共有フォルダへの格納機能（スキャン  Ｔｏ  共有フォルダ機能）について図５のフローチャートを用いて説明する。
【００３３】
まず、スキャナ１０の制御部１０４は、スキャナ部１０６を制御することにより原稿上の画像を読み取り、読み取り画像に基づく画像データを生成すると、共有フォルダが存在する端末（ＰＣ２０）のホスト名の名前解決を行う（ステップＳ１１０）。本実施形態においては、名前解決の手段として、ＤＮＳサーバ３０や図示せぬＷＩＮＳサーバに問い合わせる方法、ＮｅｔＢＩＯＳによる方法を例にして後ほど説明する。
【００３４】
名前解決の結果、ホスト名からＩＰアドレスが得られた場合（ステップＳ１１１  ＹＥＳ）、制御部１０４は、設定値保存部１０３に保存されている共有フォルダにアクセスするためのユーザ名とパスワードとを送受信部１０１を介してＰＣ２０に送信させ、ログインを試みる（ステップＳ１１２）。ログインに成功すると（ステップＳ１１３  ＹＥＳ）、制御部１０４は画像データをＰＣ２０に対して送信させる（ステップＳ１１４）。画像データの送信が成功すると（ステップＳ１１５）、制御部１０４は一連の処理を終了する。
【００３５】
ところで、例えば、ＤＮＳサーバ３０、ＷＩＮＳサーバ等のアドレスが間違っていたり、サーバからの応答が遅かった理由等により、ホスト名からＩＰアドレスが得られず、名前解決が失敗した場合（ステップＳ１１１  ＮＯ）、制御部１０４はパネル部１０５を介してエラーを表示させ処理を終了する（ステップＳ１１６）。
【００３６】
また、ＰＣ２０に対するログイン時にユーザ名やパスワードが誤っていたり、共有フォルダに適切なアクセス権限が割り当てられていない等の理由によりログインに失敗した場合（ステップＳ１１３  ＮＯ）、制御部１０４はパネル部１０５を介してエラーを表示させ処理を終了する（ステップＳ１１６）。
【００３７】
さらに、共有フォルダに対して書き込み権限が無かったり、画像データのデータサイズが共有フォルダに書き込めるデータサイズを超えていた等の理由により画像データの送信が失敗した場合（ステップＳ１１５  ＮＯ）、制御部１０４はパネル部１０５を介してエラーを表示させ処理を終了する（ステップＳ１１６）。
【００３８】
次に、スキャン  Ｔｏ  共有フォルダ機能が失敗した場合において、この障害をクラウドサービス・サーバ４０が解決する処理について図６のフローチャートを用いて説明する。
【００３９】
まず、スキャナ１０において、スキャン  Ｔｏ  共有フォルダ機能に失敗すると、ユーザは、パネル部１０５のボタン１２４（ヘルプボタン）を押下する。ボタン１２４の押下を受け、制御部１０４は、ログ保存部１０２に保存されたログ情報を設定値保存部１０３に保存された設定値を用いてインターネット４に接続し、送受信部１０１を介してクラウドサービス・サーバ４０に送信させる（ステップＳ１２０）。
【００４０】
ここで、このときにスキャナ１０のパネル部１０５が表示する表示例を図７に示す。図７に示す例においては、パネル部１０５のタッチパネル部１２１は、スキャナ１０がクラウドサービス・サーバ４０と接続してスキャン  Ｔｏ共有フォルダ機能が失敗した原因を分析中である旨を表示し、ボタン１２２'はその分析のキャンセル指示の入力を受け付ける「Ｃａｎｃｅｌ」ボタンを表示している。
【００４１】
そして、送受信部４０１を介してログ情報を受信したクラウドサービス・サーバ４０の解析部４０４は、ログ情報の解析を開始する（ステップＳ１２１）。解析部４０４は、ログ情報に含まれれている識別情報としてのシリアル番号の情報を用いて、スキャナ１０の所有者情報をユーザ情報保存部４０３に保存した情報から引き出し、この引き出した情報を用いて解析を行う。
【００４２】
なお、ログ情報の解析の際に、クラウドサービス・サーバ４０は、スキャナ１０に対してコマンドを送信し、スキャナ１０の振る舞いを変えて、スキャン  Ｔｏ  共有フォルダ機能を実行することもある。
【００４３】
解析部４０４は、解析した結果とガイダンス情報保存部４０２に保存された情報を用いて、スキャナ１０に解決方法を提示する（ステップＳ１２２）。解析部４０４が提示する解決方法としては、スキャナ１０の設定値を変更することもあるし、スキャナ１０のパネル部１０５を介して解決方法をユーザに対して表示させたり、解析結果自体をパネル部１０５を介して表示させたりする。
【００４４】
解決方法の提示により、原因が解決され、スキャン  Ｔｏ  共有フォルダ機能が成功すると（ステップＳ１２３  ＹＥＳ）、解析部４０４は処理を終了する。一方、原因が解決されない場合には（ステップＳ１２３  ＮＯ）、解析部４０４はその旨をスキャナ１０の制御部１０４に通知し、再度ログ情報の送信からやり直させる。
【００４５】
ここで、クラウドサービス・サーバ４０のユーザ情報保存部４０３に保存されているユーザ情報について図８を用いて説明する。本実施形態に係るユーザ情報１６０は、装置のシリアル番号１６１と、スキャナを所有しているユーザ名１６２と、ユーザが所属している所属組織の分類１６３と、スキャナを使用する凡そのユーザ数１６４と、ユーザがスキャナについてサービスセンタ等に問い合わせた履歴情報１６５からなる。
【００４６】
そして、クラウドサービス・サーバ４０の解析部４０４は、このユーザ情報を用いて障害の解決方法や順番を決定する。図９は、解析部４０４による解決方法の適用順番の決定方法の一形態を説明するフローチャートである。
【００４７】
例えば、ローカルグループＡに属するシリアル番号が「ＰＲＮ００１−１２３４５６」のスキャナ１０からログ情報が送信された場合、解析部４０４は、送信されたログ情報に記述されているシリアル番号とユーザ情報１６０に保存されているシリアル番号１６１とを比較する。
【００４８】
シリアル番号が一致する場合（ステップＳ１３０  ＹＥＳ）、解析部４０４は、ユーザ情報１６０のユーザが所属している所属組織の分類１６３と、スキャナを使用する凡そのユーザ数１６４とを参照する。
【００４９】
スキャナ１０の場合、スキャナ１０を使用するユーザ数１６４は５名程度であり、所属組織の分類１６３は個人事業であるため（ステップＳ１３１  ＹＥＳ）、解析部４０４は、スキャナ１０は小規模ネットワークに接続されていると判断し、スキャナ１０に対しては小規模ネットワークで遭遇しそうな障害として、ＮｅｔＢＩＯＳによる要因分析を行うものと決定する（ステップＳ１３２）。
【００５０】
一方、ローカルグループＢに属するシリアル番号が「ＰＲＮ００１−９８７６５４」のスキャナ５０からログ情報が送信された場合、解析部４０４は、送信されたログ情報に記述されているシリアル番号とユーザ情報１６０に保存されているシリアル番号１６１とを比較する。
【００５１】
シリアル番号が一致する場合（ステップＳ１３０  ＹＥＳ）、解析部４０４は、ユーザ情報１６０のユーザが所属している所属組織の分類１６３と、スキャナを使用する凡そのユーザ数１６４とを参照する。
【００５２】
スキャナ５０の場合、スキャナ１０を使用するユーザ数１６４は１００名程度であり、所属組織の分類１６３は１００人規模であるため（ステップＳ１３１  ＮＯ）、解析部４０４は、スキャナ５０は大規模ネットワークに接続されていると判断し、スキャナ５０に対しては大規模ネットワークで遭遇しそうな障害として、ＤＮＳサーバによる要因分析を行うものと決定する（ステップＳ１３３）。
【００５３】
なお、送信されたログ情報に含まれるシリアル番号がユーザ情報１６０に記述されているシリアル番号と一致しない場合（ステップＳ１３０  ＮＯ）、解析部４０４は、スキャナのパネル部に対してエラー表示を表示させ（ステップＳ１３４）、処理を終了する
【００５４】
図１０は、シリアル番号が「ＰＲＮ００１−１２３４５６」のスキャナ１０がスキャン  Ｔｏ  共有フォルダ機能に失敗したときのログ情報の例を示した図である。
【００５５】
本例に係るログ情報は、設定情報（［Ｓｅｔｔｉｎｇ］で始まる部分）とログ情報本文（［Ｌｏｇ］で始まる部分）とで構成されている。設定情報には、シリアル番号、ＩＰアドレス、サブネットマスク、デフォルトゲートウェイアドレス、ホスト名の解決に使用されるＤＮＳサーバ、ＷＩＮＳサーバのＩＰアドレス、スキャン結果を格納させる共有フォルダへのパス情報、共有フォルダにアクセスするためのユーザ名とパスワードが記載されている。なお、パスワードは決まった方式で暗号化する等の考慮が必要である。
【００５６】
ログ情報には、各行ごとに実行した処理とその時刻とが記載されている。本例では、スキャン  Ｔｏ  共有フォルダ機能が実行され、ＤＮＳサーバによる名前解決が失敗し、次に、ＷＩＮＳサーバによる名前解決が失敗し、最後にＮｅｔＢＩＯＳによる名前解決が失敗したログが記載されている。最後に、スキャン  Ｔｏ  共有フォルダ機能が失敗した情報が記載され、ログ情報は終了している。
【００５７】
前述したように、解析部４０４は、上記ログ情報を受信した場合、シリアル番号とユーザ情報保存部４０３に保存したユーザ情報１６０とを組み合わせることによって、このスキャナ１０が小規模なネットワークに接続されていると判断し、小規模ネットワークで遭遇しそうな障害の解決から試みることになる。
【００５８】
図１１は、小規模ネットワークでの名前解決に失敗したときの解析部４０４による障害解析の流れを説明するフローチャートである。
【００５９】
図９で示した処理により、小規模ネットワークで遭遇しそうな障害としてＮｅｔＢＩＯＳによる要因分析を決定した解析部４０４は、ＮｅｔＢＩＯＳによる要因分析を開始する（ステップＳ１４０）。そして、ＮｅｔＢＩＯＳによる名前解決の障害が解決した場合（ステップＳ１４１  ＹＥＳ）、解析部４０４は要因分析を終了し、再度スキャナによるスキャンを実施するよう促すメッセージをスキャナのパネル部に表示させる。
【００６０】
一方、ＮｅｔＢＩＯＳによる名前解決の障害が解決しない場合（ステップＳ１４１  ＮＯ）、解析部４０４は、ＤＮＳサーバによる要因分析を開始する（ステップＳ１４２）。そして、ＤＮＳサーバによる名前解決の障害が解決した場合（ステップＳ１４３  ＹＥＳ）、解析部４０４は要因分析を終了し、再度スキャナによるスキャンを実施するよう促すメッセージをスキャナのパネル部に表示させる。
【００６１】
ＤＮＳサーバによる名前解決の障害が解決しない場合（ステップＳ１４３  ＮＯ）、解析部４０４は、ＷＩＮＳサーバによる要因分析を開始する（ステップＳ１４４）。そして、ＷＩＮＳサーバによる名前解決の障害が解決した場合（ステップＳ１４５  ＹＥＳ）、解析部４０４は要因分析を終了し、再度スキャナによるスキャンを実施するよう促すメッセージをスキャナのパネル部に表示させる。
【００６２】
図１２は、ＮｅｔＢＩＯＳ、ＤＮＳサーバ、ＷＩＮＳサーバによる名前解決に失敗した際に実行される、問題の切り分けに係る処理を説明するフローチャートである。
【００６３】
まず、解析部４０４は、名前解決に対する応答を待つ時間を延ばして障害が解決しないか否かを確認する（ステップＳ１５０）。障害が解決した場合（ステップＳ１５１  ＹＥＳ）、解析部４０４は、スキャナに対して、応答の待ち時間を延ばす設定を行い、問題の切り分けに係る処理を終了する。
【００６４】
応答の待ち時間を延ばしても障害が解決しない場合（ステップＳ１５１  ＮＯ），解析部４０４は、リトライ回数を延ばして障害が解決しないか否かを確認する（ステップＳ１５２）。障害が解決した場合（ステップＳ１５３  ＹＥＳ）、解析部４０４は、スキャナに対して、リトライ回数を延ばす設定を行い、問題の切り分けに係る処理を終了する。
【００６５】
リトライ回数を延ばしても障害が解決しない場合（ステップＳ１５３  ＮＯ），解析部４０４は、名前解決に使用される名前の変更して障害が解決しないか否かを確認する（ステップＳ１５４）。例えば、ＮｅｔＢＩＯＳによる名前解決の場合、ＮｅｔＢＩＯＳに使用されるホスト名は大文字と小文字とが区別される。よって、解析部４０４は、それらの組み合わせを試して名前解決の障害が解決しないか否かを確認する。障害が解決した場合（ステップＳ１５５  ＹＥＳ）、解析部４０４は、スキャナに対して、名前変更に係る設定を行い、問題の切り分けに係る処理を終了する。
【００６６】
図１３は、ＮｅｔＢＩＯＳの名前解決に失敗したときのクラウドサービス・サーバ４０、スキャナ１０、ＰＣ２０間で行われる通信の例を説明するシーケンス図である。
【００６７】
まず、スキャナ１０において、スキャン  Ｔｏ  共有フォルダ機能が失敗すると、ユーザは、パネル部１０５のボタン１２４（ヘルプボタン）を押下する。ボタン１２４の押下を受け、制御部１０４は、ログ保存部１０２に保存されたログ情報を設定値保存部１０３に保存された設定値を用いてインターネット４に接続し、送受信部１０１を介してクラウドサービス・サーバ４０に送信させる。
【００６８】
ログ情報は、ＨＴＴＰのＰＯＳＴメソッドによって、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ／ｌｏｇ．ｃｇｉ宛に送信される（Ｓ２１）。クラウドサービス・サーバ４０は、ログ情報を送受信部４０１を介して受信すると、スキャナ１０に対して、ＨＴＴＰレスポンスコード「２００  ＯＫ」を用いて応答する（Ｓ２２）。
【００６９】
スキャナ１０は、クラウドサービス・サーバ４０からの応答を受け取ると、クラウドサービス・サーバ４０の解析結果を取得するために、クラウドサービス・サーバ４０に対して、自身のシリアル番号を添えて、ＨＴＴＰのＧＥＴメソッドで、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ／ｒｅｓｕｌｔ．ｃｇｉ？ｓｅｒｉａｌ＝ＰＲＮ００１−１２３４５６のＵＲＬにアクセスする（Ｓ２３）。
【００７０】
クラウドサービス・サーバ４０は、ＧＥＴメソッドに対して、ＨＴＴＰレスポンスコード「２００  ＯＫ」とともに、スキャナ１０で実行させる動作を示す解決方法としてのコマンドを返す（Ｓ２４）。本例においては、
｛
"ｎｅｔｂｉｏｓ"：｛
"ｔｉｍｅｏｕｔ"："１２０"，
｝
｝
となっており、クラウドサービス・サーバ４０の解析部４０４は、ＮｅｔＢＩＯＳによる応答待ち時間を１２０秒に変更することを示している。
【００７１】
クラウドサービス・サーバ４０からの応答を受けて、スキャナ１０は、ＮｅｔＢＩＯＳによる名前解決を実施する。具体的には、スキャナ１０は、ＮｅｔＢＩＯＳコマンド「Ｎａｍｅ  ｑｕｅｒｙ  ＮＢ  ＴＥＳＴ＜００＞」をブロードキャストする（Ｓ２５）。
【００７２】
そして、１２０秒待っても応答が無い場合、クラウドサービス・サーバ４０による指示は失敗したことと、次の解析結果を取得するために、スキャナ１０は、クラウドサービス・サーバ４０に対して、自身のシリアル番号と結果情報をを添えて、ＨＴＴＰのＧＥＴメソッドで、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ／ｒｅｓｕｌｔ．ｃｇｉ？ｓｅｒｉａｌ＝ＰＲＮ００１−１２３４５６＆ｒｅｓｕｌｔ＝ｆａｉｌのＵＲＬにアクセスする（Ｓ２６）。
【００７３】
クラウドサービス・サーバ４０は、ＧＥＴメソッドに対して、ＨＴＴＰレスポンスコード「２００  ＯＫ」とともに、スキャナ１０で実行させる動作を示す解決方法としてのコマンドを返す（Ｓ２７）。本例においては、
｛
"ｎｅｔｂｉｏｓ"：｛
"ｒｅｔｒｙ"："３"，
｝
｝
となっており、クラウドサービス・サーバ４０の解析部４０４は、ＮｅｔＢＩＯＳによるリトライ回数を３回に変更することを示している。
【００７４】
クラウドサービス・サーバ４０からの応答を受けて、スキャナ１０は、ＮｅｔＢＩＯＳによる名前解決を実施し、応答が無い場合でも３回リトライを実施する。なお、使用されるＮｅｔＢＩＯＳコマンドは一緒であるが、再試行する動作は異なる（Ｓ２８）。
【００７５】
そして、３回リトライしても応答が無い場合、クラウドサービス・サーバ４０による指示は失敗したことと、次の解析結果を取得するために、スキャナ１０は、クラウドサービス・サーバ４０に対して、自身のシリアル番号と結果情報をを添えて、ＨＴＴＰのＧＥＴメソッドで、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ／ｒｅｓｕｌｔ．ｃｇｉ？ｓｅｒｉａｌ＝ＰＲＮ００１−１２３４５６＆ｒｅｓｕｌｔ＝ｆａｉｌのＵＲＬにアクセスする（Ｓ２９）。
【００７６】
クラウドサービス・サーバ４０は、ＧＥＴメソッドに対して、ＨＴＴＰレスポンスコード「２００  ＯＫ」とともに、スキャナ１０で実行させる動作を示す解決方法としてのコマンドを返す（Ｓ３０）。本例においては、
｛
"ｎｅｔｂｉｏｓ"：｛
"ｈｏｓｔｎａｍｅ"："ｔｅｓｔ"，
"ｈｏｓｔｎａｍｅ"："Ｔｅｓｔ"，
"ｈｏｓｔｎａｍｅ"："ｔＥｓｔ"，
"ｈｏｓｔｎａｍｅ"："ｔｅＳｔ"，
"ｈｏｓｔｎａｍｅ"："ｔｅｓＴ"，
"ｈｏｓｔｎａｍｅ"："Ｔｅｓｔ"，
・・・（省略）
｝
｝
となっており、クラウドサービス・サーバ４０の解析部４０４は、名前を変更してＮｅｔＢＩＯＳによる名前解決を実施することを示している。
【００７７】
クラウドサービス・サーバ４０からの応答を受けて、スキャナ１０は、提示された名前でＮｅｔＢＩＯＳによる名前解決の実施を試みる（Ｓ３１）。
【００７８】
図１４は、大規模ネットワークでの名前解決に失敗したときの解析部４０４による障害解析の流れを説明するフローチャートである。
【００７９】
図９で示した処理により、大規模ネットワークで遭遇しそうな障害としてＤＮＳサーバによる要因分析を決定した解析部４０４は、ＤＮＳサーバによる要因分析を開始する（ステップＳ１６０）。そして、ＤＮＳサーバによる名前解決の障害が解決した場合（ステップＳ１６１  ＹＥＳ）、解析部４０４は要因分析を終了し、再度スキャナによるスキャンを実施するよう促すメッセージをスキャナのパネル部に表示させる。
【００８０】
一方、ＤＮＳサーバによる名前解決の障害が解決しない場合（ステップＳ１６１  ＮＯ）、解析部４０４は、ＷＩＮＳサーバによる要因分析を開始する（ステップＳ１６２）。そして、ＷＩＮＳサーバによる名前解決の障害が解決した場合（ステップＳ１６３  ＹＥＳ）、解析部４０４は要因分析を終了し、再度スキャナによるスキャンを実施するよう促すメッセージをスキャナのパネル部に表示させる。
【００８１】
ＷＩＮＳサーバによる名前解決の障害が解決しない場合（ステップＳ１６３  ＮＯ）、解析部４０４は、ＮｅｔＢＩＯＳによる要因分析を開始する（ステップＳ１６４）。そして、ＮｅｔＢＩＯＳによる名前解決の障害が解決した場合（ステップＳ１６５  ＹＥＳ）、解析部４０４は要因分析を終了し、再度スキャナによるスキャンを実施するよう促すメッセージをスキャナのパネル部に表示させる。
【００８２】
ＮｅｔＢＩＯＳの要因によって名前解決の障害が解決しない場合は、解析部４０４は、サーバのＩＰアドレスの確認等の設定情報の見直しを促すメッセージをスキャナのパネル部に表示させる（ステップＳ１６６）。
【００８３】
図１５は、ＤＮＳサーバの名前解決に失敗したときのクラウドサービス・サーバ４０、スキャナ５０、ＤＮＳサーバ７０間で行われる通信の例を説明するシーケンス図である。なお、スキャナ５０において、スキャナ１０の構成と同一なものについては同じ符号を付して説明する。
【００８４】
まず、スキャナ５０において、スキャン  Ｔｏ  共有フォルダ機能が失敗すると、ユーザは、パネル部１０５のボタン１２４（ヘルプボタン）を押下する。ボタン１２４の押下を受け、制御部１０４は、ログ保存部１０２に保存されたログ情報を設定値保存部１０３に保存された設定値を用いてインターネット４に接続し、送受信部１０１を介してクラウドサービス・サーバ４０に送信させる。
【００８５】
ログ情報は、ＨＴＴＰのＰＯＳＴメソッドによって、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ／ｌｏｇ．ｃｇｉ宛に送信される（Ｓ４１）。クラウドサービス・サーバ４０は、ログ情報を送受信部４０１を介して受信すると、スキャナ１０に対して、ＨＴＴＰレスポンスコード「２００  ＯＫ」を用いて応答する（Ｓ４２）。
【００８６】
スキャナ１０は、クラウドサービス・サーバ４０からの応答を受け取ると、クラウドサービス・サーバ４０の解析結果を取得するために、クラウドサービス・サーバ４０に対して、自身のシリアル番号を添えて、ＨＴＴＰのＧＥＴメソッドで、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ／ｒｅｓｕｌｔ．ｃｇｉ？ｓｅｒｉａｌ＝ＰＲＮ００１−９８７６５４のＵＲＬにアクセスする（Ｓ４３）。
【００８７】
クラウドサービス・サーバ４０は、ＧＥＴメソッドに対して、ＨＴＴＰレスポンスコード「２００  ＯＫ」とともに、スキャナ５０で実行させる動作を示す解決方法としてのコマンドを返す（Ｓ４４）。本例においては、
｛
"ｄｎｓ"：｛
"ｔｉｍｅｏｕｔ"："１２０"，
｝
｝
となっており、クラウドサービス・サーバ４０の解析部４０４は、ＤＮＳサーバ７０による応答待ち時間を１２０秒に変更することを示している。
【００８８】
クラウドサービス・サーバ４０からの応答を受けて、スキャナ５０は、ＤＮＳサーバ７０による名前解決を実施する。具体的には、スキャナ５０は、ＤＮＳサーバ７０への問い合わせ「ＱＥＥＲＹ  ０ｘ１２３４ＰＴＲ  ＴＥＳＴ２」を送信する（Ｓ４５）。なお、問い合わせに含まれる「０ｘ１２３４」はＤＮＳサーバ７０とのやり取りで重複が無いように問い合わせる側が割り当てるコードであり、問い合わせの毎に異なるコードが割り当てられる。「ＴＥＳＴ２」は、ローカルグループＢのＰＣ６０の割り当てられたホスト名である。
【００８９】
そして、１２０秒待っても応答が無い場合、クラウドサービス・サーバ４０による指示は失敗したことと、次の解析結果を取得するために、スキャナ１０は、クラウドサービス・サーバ４０に対して、自身のシリアル番号と結果情報をを添えて、ＨＴＴＰのＧＥＴメソッドで、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ／ｒｅｓｕｌｔ．ｃｇｉ？ｓｅｒｉａｌ＝ＰＲＮ００１−９８７６５４＆ｒｅｓｕｌｔ＝ｆａｉｌのＵＲＬにアクセスする（Ｓ４６）。
【００９０】
クラウドサービス・サーバ４０は、ＧＥＴメソッドに対して、ＨＴＴＰレスポンスコード「２００  ＯＫ」とともに、スキャナ１０で実行させる動作を示す解決方法としてのコマンドを返す（Ｓ４７）。本例においては、
｛
"ｄｎｓ"：｛
"ｒｅｔｒｙ"："３"，
｝
｝
となっており、クラウドサービス・サーバ４０の解析部４０４は、ＤＮＳサーバ７０に対するリトライ回数を３回に変更することを示している。
【００９１】
クラウドサービス・サーバ４０からの応答を受けて、スキャナ５０は、ＤＮＳサーバ７０による名前解決を実施し、応答が無い場合でも３回リトライを実施する。なお、使用されるＤＮＳサーバ７０に対するコマンドは一緒であるが、再試行する動作は異なる（Ｓ４８）。
【００９２】
そして、３回リトライしても応答が無い場合、クラウドサービス・サーバ４０による指示は失敗したことと、次の解析結果を取得するために、スキャナ１０は、クラウドサービス・サーバ４０に対して、自身のシリアル番号と結果情報をを添えて、ＨＴＴＰのＧＥＴメソッドで、ｈｔｔｐ：／／ｓｕｐｐｏｒｔ．ｃｌｏｕｄ．ｃｏｍ／ｒｅｓｕｌｔ．ｃｇｉ？ｓｅｒｉａｌ＝ＰＲＮ００１−９８７６５４＆ｒｅｓｕｌｔ＝ｆａｉｌのＵＲＬにアクセスする（Ｓ４９）。
【００９３】
クラウドサービス・サーバ４０は、ＧＥＴメソッドに対して、ＨＴＴＰレスポンスコード「２００  ＯＫ」とともに、スキャナ５０で実行させる動作を示す解決方法としてのコマンドを返す（Ｓ５０）。本例においては、
｛
"ｄｉｓｐｌａｙ"：｛
"ｍｅｓｓａｇｅ"："ＤＮＳサーバの設定を確認してください。"，
｝
｝
となっており、クラウドサービス・サーバ４０の解析部４０４は、スキャナ５０のパネル部１０５に対してメッセージ表示を実施させることを示している。
【００９４】
そして、スキャナ５０のパネル部１０５は、例えば、図１６に示すようなメッセージを表示する。
【００９５】
以上のように、本実施形態によれば、ネットワークの接続不良に伴う画像データの共有フォルダへの格納機能失敗といった、ネットワークに接続された複数の画像形成装置において、保守的管理が必要な事象が発生した場合においても、当該画像形成装置に対応した原因解決方法を提供することが可能なネットワークシステムを提供することができる。
【００９６】
なお、本実施形態の説明において、保守的管理が必要な事象としてネットワークの接続不良の形態について説明したが、本発明はこれに限定されるものではない。すなわち、例えば、画像形成装置がプリンタである場合、クラウドサービス・サーバが有するユーザ情報保存部の履歴情報に、トナー等の消耗品の消費状況を保存させ、当該クラウドサービス・サーバにアクセスしたプリンタに応じ、このプリンタに最適な消耗品の交換順番に関する情報を提供することも可能である。
【００９７】
また、本実施形態の説明において、画像形成装置としてスキャナを一例にして説明したが、本発明は、他にも複写機、ＭＦＰ、ＦＡＸ等にも適用可能である。
【符号の説明】
【００９８】
１  ネットワークシステム
２，３ ＬＡＮケーブル
４  インターネット
１０，５０  スキャナ
２０，６０  ＰＣ
３０，７０  ＤＮＳサーバ
４０  クラウドサービス・サーバ
１０１  送受信部
１０２  ログ保存部
１０３  設定値保存部
１０４  制御部
１０５  パネル部
１０６  スキャナ部
４０１  送受信部
４０２  ガイダンス情報保存部
４０３  ユーザ情報保存部
４０４  解析部
【図１】
0006336377.tif 000002
【図２】
0006336377.tif 000003
【図３】
0006336377.tif 000004
【図４】
0006336377.tif 000005
【図５】
0006336377.tif 000006
【図６】
0006336377.tif 000007
【図７】
0006336377.tif 000008
【図８】
0006336377.tif 000009
【図９】
0006336377.tif 000010
【図１０】
0006336377.tif 000011
【図１１】
0006336377.tif 000012
【図１２】
0006336377.tif 000013
【図１３】
0006336377.tif 000014
【図１４】
0006336377.tif 000015
【図１５】
0006336377.tif 000016
【図１６】
0006336377.tif 000017