JP6368157B2 - 通信システムとその制御方法 - Google Patents

Description

本発明は、通信システムとその制御方法に関する。

製品のトラブルに対処する処置が複雑になるにつれ、顧客が直接、メーカのコールセンタに質問し、トラブルに対処するための回答を得ることが頻繁に行われている。更に、このようなトラブルに対する処置を迅速に行うため、画像形成装置とコールセンタとの間で、対処法を案内する音声や動画の送受信や、遠隔操作で保守サービスを実施することが考えられている（例えば特許文献１参照）。この遠隔保守サービスでは、支援される画像形成装置や、支援を行うコールセンタの情報処理装置は、一般的に、それぞれファイアウォールの中にある。このため画像形成装置と情報処理装置とが通信を行うために、インターネット上に両者の通信を中継する中継サーバを設置することが提案されている（例えば特許文献２参照）。このような中継サーバを設置することによって、ファイアウォール内にある装置同士の通信が可能となる。

特開２００５−２０８９７４号公報 特開２０１３−０２９９２２号公報 特開平６−３５０７２３号公報

しかしながら、このような中継サーバと画像形成装置と情報処理装置とを接続する回線数が増大することにより、その通信量も増加する。これに対処するために中継サーバの性能を上げたり、中継サーバの数を増やすことが必要となる。しかし中継サーバの数を際限なく増やすことは現実的ではないため、中継サーバの数を所定数に抑えて、中継サーバとの接続に優先度を設けること提案がされている。例えば、特許文献３には、テレビ会議の予約情報を登録する一般予約メモリと、優先予約の予約情報を登録する優先予約メモリを備え、制御装置はそれぞれのメモリに登録された一般予約及び優先予約に基づいて接続を制御することが記載されている。しかし、上記従来技術では、予め優先する会議用端末を予約しておくことが前提であり、優先予約していない端末の優先度を、状況に応じて変更することができないため、柔軟性に欠けるという問題がある。

本発明の目的は、上記従来技術の問題点を解決することにある。

本発明の特徴は、端末を管理する管理サーバを用いて、接続する端末の状態を確認し、端末の状態に応じて端末の接続を許可する技術を提供することにある。

上記目的を達成するために本発明の一態様に係る通信システムは以下のような構成を備える。即ち、
第１の端末と第２の端末と、前記第１と第２の端末を中継する中継サーバと、前記第１の端末を管理する管理サーバとを含む通信システムであって、
前記中継サーバは、
前記第１の端末からの接続要求に応じて検索条件を生成し、前記管理サーバに前記第１の端末の状態を検索するように要求する要求手段と、
前記要求手段により要求に応答して前記管理サーバから送信される前記第１の端末のデバイス情報を取得すると中継情報を生成して前記第１の端末に送信する第１送信手段と、
前記中継情報に従って前記第１と第２の端末の通信を制御する制御手段と、を有し、
前記管理サーバは、
前記要求手段で要求された前記検索条件に応じて前記第１の端末の状態情報を検索して前記デバイス情報として前記中継サーバに通知する通知手段と、
前記第１の端末からの前記中継情報を受信することに応じて、前記第２の端末に当該中継情報を送信する第２送信手段と、を有し、
前記第２の端末は、前記中継サーバを介して前記第１の端末の遠隔支援のための通信を行うことを特徴とする。

本発明によれば、端末を管理する管理サーバを用いて、接続する端末の状態を確認し、端末の状態に応じて端末の接続を許可することができる。

本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

添付図面は明細書に含まれ、その一部を構成し、本発明の実施の形態を示し、その記述と共に本発明の原理を説明するために用いられる。
ネットワークを介したセキュアな遠隔支援サービスを提供できる通信システムの構成の一例を示す図。 実施形態１に係るＭＦＰのハードウェア構成を説明するブロック図。 実施形態１に係るＰＣ、中継サーバ、管理サーバのハードウェア構成を説明するブロック図。 実施形態１に係るＭＦＰ，ＰＣ、中継サーバ、管理サーバの動作を説明するシーケンス図。 実施形態１に係るＭＦＰの動作を説明するフローチャート。 実施形態１に係るＰＣの動作を説明するフローチャート。 実施形態１に係る中継サーバの動作を説明するフローチャート。 実施形態１に係る管理サーバの動作を説明するフローチャート。 実施形態１に係る管理サーバのＨＤＤに記憶されているＭＦＰ情報の一例を説明する図。 実施形態１に係る中継サーバがＭＦＰからのログインに応じて管理サーバからデバイスの状態情報を取得しＭＦＰとの接続を制御する手順を説明するフローチャート。 実施形態１に係る管理サーバの処理を説明するフローチャート。 実施形態２に係るシステム構成例を示す図。 実施形態１に係る中継サーバが、ＭＦＰと接続するかを判定するのに使用するテーブルの一例を示す図。 実施形態３に係る管理サーバが管理しているＭＦＰ群で発生しているエラー数を集計してグラフ化した図。 実施形態３に係る中継サーバの処理を説明するフローチャート。

以下、図面を参照して本発明を実施する形態を詳しく説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。

［実施形態１］
まず、本発明の実施形態１について説明する。

図１は、ネットワークを介したセキュアな遠隔支援サービスを提供できる通信システムの構成の一例を示す図である。

ＭＦＰ（Multi Function Peripheral）１００は、ユーザ環境１０２に配置され、ユーザによって操作される。ＰＣ１１０はコールセンタ１１２の中に配置され、オペレータによって操作される。これらユーザ環境１０２及びコールセンタ１１２は複数あってもよく、更に多くのＭＦＰやＰＣがあってもよい。ユーザ環境１０２とコールセンタ１１２にはファイアフォール１０１，１１１が設置されている。ファイアウォール１０１は、ユーザ環境１０２の内側にある端末からインターネット１４０への接続は許可するが、インターネット１４０からユーザ環境１０２の中にある端末への接続は拒否するように構成されている。またファイアウォール１１１は、コールセンタ１１２の内側にある端末からインターネット１４０への接続は許可するが、インターネット１４０からコールセンタ１１２の内側にある端末への接続は拒否するように構成されている。

中継サーバ群１２１は、インターネット１４０を介して中継サービスを提供するサーバコンピュータを含む中継サーバ群で、この中継サーバは１台であっても複数台であってもよい。図１においては中継サーバ１２０のみを示している。

ＭＦＰ１００とＰＣ１１０は、ＨＴＴＰ（Hyper Text Transfer Protocol）によるデータ通信機能を備えている。ＨＴＴＰによるデータ通信においては、クライアントノード同士はＨＴＴＰ中継サーバから提供されるＵＲＬ（Uniform Resource Locator）にＰＯＳＴ，ＧＥＴを繰り返し行うことでデータ通信を実施する。本実施形態１では、ＰＯＳＴを繰り返し行うことをＰＯＳＴポーリングと呼び、ＧＥＴを繰り返し行うことをＧＥＴポーリングと呼ぶ。これにより、クライアントノード同士がプライベートアドレスエリアやファイアウォールに遮られていてもデータ通信を行うことができる。本実施形態１では、ＭＦＰ１００とＰＣ１１０は、ＨＴＴＰクライアントノードとして動作する。また、ＭＦＰ１００には、ＭＦＰ自身を監視する監視モジュールが組み込まれている。この監視モジュールは、ＭＦＰ１００のステータスを監視し、管理サーバ１３０へＭＦＰ１００の状態を通知する。中継サーバ１２０はＨＴＴＰ中継サーバとして動作する。

管理サーバ１３０は、インターネット１４０に設置され、各ユーザ環境１０２に設置されているＭＦＰ内の監視モジュールと通信を行うことによって、ＭＦＰの情報を収集してＭＦＰを管理する。管理サーバ１３０の収集するＭＦＰの情報（以下、管理情報）は、カウンタ値、稼動ログ、ＭＦＰ内で使用されている各部品の消耗度を表す部品カウンタ値などの稼動情報、及びハード障害やジャム等の障害情報などを含む。

管理サーバ１３０は、管理する全てのＭＦＰ１００が、どこのコールセンタ１１２によって管理されているかを対応づけているＭＦＰ情報テーブル１３１を保管している。図１では、２つのＭＦＰの情報として、Device001とDevice002の白黒とカラー印刷のカウンタ情報が日時とともに保管されている。尚、このＭＦＰ情報テーブル１３１の詳細は、図９を参照して後述する。このＭＦＰ情報テーブル１３１によって、ＭＦＰの基本的な利用状況や、障害発生時の緊急連絡などを、適切なコールセンタ１１２へ提供できる。

具体的には、管理サーバ１３０のユーザであるオペレータが管理サーバ１３０にログインすると、監視対象のＭＦＰ１００から収集した管理情報が管理サーバ１３０の表示部に表示される。これによりオペレータは、ＭＦＰ１００の状態を確認できる。また、サービスコールエラーやハード障害などの緊急性の高い情報は、そのＭＦＰに対応するＭＦＰ情報テーブル１３１に登録されている通知先へメールを送信して通知することができる。また、ＭＦＰ１００と管理サーバ１３０との通信により、ＭＦＰ１００が中継サーバ１２０と接続した情報も、イベント情報として即時に管理サーバ１３０を介してオペレータに通知される。こうして管理サーバ１３０は、ＭＦＰ１００とそれに対応するコールセンタ１１２の情報を管理する。

尚、実施形態１では、ＭＦＰ１００とＰＣ１１０は、インターネット１４０に対してファイアフォール１０１，１１１を介して通信する構成であるが、ファイアフォール１０１，１１１を介さないネットワーク構成でもよい。また実施形態１では、通信プロトコルとしてはＨＴＴＰでなくてもよい。

図２は、実施形態１に係るＭＦＰ１００のハードウェア構成を説明するブロック図である。

ＣＰＵ２１１を含む制御部２１０は、ＭＦＰ１００全体の動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２に記憶されたブートプログラムを実行してＨＤＤ２１４に記憶されているＯＳやプログラムをＲＡＭ２１３に展開し、そのプログラムに従って読取制御や送信制御などの各種制御を行う。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。尚、ＭＦＰ１００の場合は、１つのＣＰＵ２１１が１つのメモリ（ＲＡＭ２１３）を用いて後述するフローチャートに示す各処理を実行するものとするが、他の態様であっても構わない。例えば、複数のＣＰＵや複数のＲＡＭ又はＨＤＤを協働させて、後述するフローチャートで示す各処理を実行するようにすることもできる。ＨＤＤ（ハードディスクドライブ）２１４は、画像データや各種プログラムを記憶する。操作部Ｉ／Ｆ２１５は、操作部２１９と制御部２１０とを接続する。操作部２１９には、タッチパネル機能を有する表示部やキーボード等が設けられている。プリンタＩ／Ｆ２１６は、プリンタ２２０と制御部２１０とを接続する。プリンタ２２０で印刷すべき画像データは、プリンタＩ／Ｆ２１６を介して制御部２１０からプリンタ２２０に転送され、プリンタ２２０により記録媒体（シート）上に印刷される。スキャナＩ／Ｆ２１７は、スキャナ２２１と制御部２１０とを接続する。スキャナ２２１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。ＭＦＰ１００は、スキャナ２２１で生成された画像データをファイル送信或いはメールで送信することができる。ネットワークＩ／Ｆ２１８は、制御部２１０をネットワークに接続する。

図３は、実施形態１に係るＰＣ１１０、中継サーバ１２０、管理サーバ１３０のハードウェア構成を説明するブロック図である。

ＣＰＵ３１１を含む制御部３１０は、全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２に記憶されたブートプログラムを実行してＨＤＤ３１４に格納されているＯＳやプログラムを読み出してＲＡＭ３１３に展開し、それを実行することにより各種制御を実行する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、画像データや各種プログラムを記憶する。操作部Ｉ／Ｆ３１５は、操作部３１７と制御部３１０とを接続する。操作部３１７には、タッチパネル機能を有する表示部やキーボード、ポインティングデバイス等が備えられている。ネットワークＩ／Ｆ３１６は、ネットワーク或いはインターネット１４０に接続する。

図４は、実施形態１に係るＭＦＰ１００，ＰＣ１１０、中継サーバ１２０、管理サーバ１３０の動作を説明するシーケンス図である。このシーケンス図で説明する動作は、ＭＦＰ１００のＣＰＵ２１１がＨＤＤ２１４に記憶された制御プログラムをＲＡＭ２１３に展開して実行することによって実現される。またＰＣ１１０及び中継サーバ１２０、管理サーバ１３０の処理は、各装置のＣＰＵ３１１がそれぞれＨＤＤ３１４に記憶された制御プログラムをＲＡＭ３１３に展開して実行することによって実現される。

ＭＦＰ１００は、操作部２１９を介してユーザにより支援開始要求が入力されると、Ｓ４０１で中継サーバ１２０へログインする。そしてＳ４０２でＭＦＰ１００は、中継サーバ１２０へ支援ＵＲＬの作成を要求する。この支援ＵＲＬは、中継サーバ１２０を介してＭＦＰ１００とＰＣ１１０が通信するために必要な中継情報である。

これにより中継サーバ１２０はＳ４０３で、管理サーバ１３０にＭＦＰ１００の状態情報を問い合わせる。そしてＳ４０４で管理サーバ１３０は、その問い合わせに対する情報を中継サーバ１２０に返却する。そして中継サーバ１２０は、Ｓ４０４で受信した管理サーバ１３０からの返却情報（デバイス情報）を基に、その支援ＵＲＬの作成要求を受け付けるか否かを判定する。ここで支援ＵＲＬの作成を行わないと判定した場合は、Ｓ４０５で、支援ＵＲＬを作成できない旨のエラー情報をＭＦＰ１００に通知する。一方、支援ＵＲＬを作成すると判定した場合は、Ｓ４０６で支援ＵＲＬを作成し、Ｓ４０７で、その作成した支援ＵＲＬをＭＦＰ１００に通知する。ここでの中継サーバ１２０のＳ４０１〜Ｓ４０７の処理は、図１０以降を参照して後述する。

次にＳ４０８或いはＳ４１２で、中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬへの参加要求を受信すると、ＭＦＰ１００やＰＣ１１０の情報を参加者としてＲＡＭ３１３にバッファリングする。

またＳ４０９或いはＳ４１５で中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬへの参加者情報のＧＥＴポーリングを受信すると、ＲＡＭ３１３にバッファリングされた参加者の更新情報をＭＦＰ１００やＰＣ１１０に返す。またＳ４１８或いはＳ４１９で、中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬへの脱退要求を受信すると、ＲＡＭ３１３にバッファリングされた参加者情報から、それらＭＦＰ１００やＰＣ１１０の情報を削除する。

また中継サーバ１２０はＳ４１４，Ｓ４１５で、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬへの支援データのＰＯＳＴポーリングを受信すると、支援データをＲＡＭ３１３にバッファリングする。この支援データとしては、例えば、動画や音声、或いは遠隔操作の命令データなどがあげられる。

また中継サーバ１２０は、ＭＦＰ１００やＰＣ１１０から支援ＵＲＬにＧＥＴポーリングされると、ＲＡＭ３１３にバッファリングされた支援データをＭＦＰ１００やＰＣ１１０に返す。支援ＵＲＬは複数存在してもよく、複数存在する場合は、支援ＵＲＬ毎にＲＡＭ３１３のバッファリング領域が割り当てられることになる。

またＭＦＰ１００はＳ４０８で、支援ＵＲＬへの参加要求を中継サーバ１２０に送信する。次にＳ４０９で、ＭＦＰ１００は支援ＵＲＬへの参加者情報のＧＥＴポーリングを開始する。そしてＭＦＰ１００は、Ｓ４１０で、ＭＦＰ識別子と支援ＵＲＬを管理サーバ１３０に送信する。ここでＭＦＰ識別子は、ＭＦＰ１００を特定するための全世界でユニークな識別子である。後述するが、管理サーバ１３０は、ＭＦＰ１００とコールセンタ１１２との対応テーブルを有している。

管理サーバ１３０はＳ４１１で、ＭＦＰ識別子から通知先のコールセンタ１１２を特定した上で、支援ＵＲＬと管理サーバ１３０のＵＲＬをＰＣ１１０に送信する。本実施形態１では、Ｓ４１１の送信に使用するプロトコルは電子メールとするが、電子メール以外でもよい。例えば、ファイアウォール１１１を超えるために、ＰＣ１１０から管理サーバ１３０へＨＴＴＰのＧＥＴポーリングを行うことによって、データを取得する方法であってもよい。

ここで管理サーバ１３０は、ＭＦＰ情報としてＭＦＰのエラー履歴を管理している。従って、管理サーバ１３０のＵＲＬに接続することにより、ＭＦＰ１００のエラー履歴を取得できる。これによりオペレータは、ＭＦＰ１００を支援する際に、そのＭＦＰの過去のエラー発生状況を参考にすることが可能となる。実施形態１では、ＭＦＰ情報の一例としてエラー履歴を扱うが、部品の交換情報やカウンタ情報等他の情報であってもよい。

ＰＣ１１０はＳ４１２で、支援ＵＲＬへの参加要求を中継サーバ１２０に送信する。これにより中継サーバ１２０は、Ｓ４１３で、参加者情報をＭＦＰ１００に送信する。

こうしてＭＦＰ１００とＰＣ１１０は、Ｓ４１４とＳ４１５で、支援ＵＲＬへの支援データのＰＯＳＴポーリングと、ＧＥＴポーリングを開始する。そしてＰＣ１１０はＳ４１６で、管理サーバ１３０のＵＲＬへＭＦＰ情報の取得要求を送信する。これにより管理サーバ１３０はＳ４１７で、ＭＦＰ１００のＭＦＰ情報をＰＣ１１０へ送信する。こうしてＭＦＰ１００とＰＣ１１０は、中継サーバ１２０を介した支援データの通信を行う。例えば、ＭＦＰ１００にてジャムエラー等の障害が発生し、ユーザが障害復旧できない場合、その原因を探るため、障害情報をＭＦＰ１００からコールセンタ１１２のオペレータに通知する。この場合、ＭＦＰ１００は、障害を示す情報を支援ＵＲＬにＰＯＳＴすると、中継サーバ１２０は、その情報をＲＡＭ３１３に格納する。その後、コールセンタ１１２のＰＣ１１０が支援ＵＲＬに対してＧＥＴ要求を送信すると、中継サーバ１２０はＲＡＭ３１３に格納された情報を応答としてＰＣ１１０に送信する。続いてＭＦＰ１００から送信された情報に基づいて障害の原因を把握したコールセンタ１１２のオペレータがＭＦＰ１００のユーザに対してエラーの解除方法を動画で伝える。この場合、コールセンタ１１２のオペレータは、ＰＣ１１０を操作することにより、支援ＵＲＬに対して動画データのＰＯＳＴ要求を送信すると、中継サーバ１２０は、その動画データをＲＡＭ３１３に格納する。その後ＭＦＰ１００が支援ＵＲＬに対してＧＥＴ要求を送信すると、中継サーバ１２０のＲＡＭ３１３に格納された動画データがＭＦＰ１００に送信されて操作部２１９に表示される。

こうしてオペレータによる支援が終了するとＳ４１８とＳ４１９で、ＭＦＰ１００とＰＣ１１０は、支援ＵＲＬへ脱退要求を送信する。これにより中継サーバ１２０はＳ４２０で、不要になった支援ＵＲＬを破棄して、この処理を終了する。

図５は、実施形態１に係るＭＦＰ１００の動作を説明するフローチャートである。このフローチャートで示す各動作（ステップ）は、ＭＦＰ１００のＣＰＵ２１１がＲＡＭ２１３に展開された制御プログラムを実行することによって実現される。尚、以下の説明では図５のステップに対応する図４のステップを括弧内で示す。

まずＳ５０１でＣＰＵ２１１は、ＭＦＰ１００でエラーが発生したことを検知するとＳ５０２に進み、ＣＰＵ２１１は、管理サーバ１３０へエラーを送信する。尚、ＭＦＰ１００は、エラーの重要度、緊急度を基にエラーのレベル分けをし、レベルの高いエラーのみを管理サーバ１３０へ送信するようにしてもよい。次にＳ５０３に進みＣＰＵ２１１は、ユーザが操作部２１９を介して支援開始要求を入力するのを待ち、支援開始要求が入力されるとＳ５０４に進み、ＣＰＵ２１１は中継サーバ１２０へログインする（Ｓ４０１）。そしてＳ５０５でＣＰＵ２１１は、中継サーバ１２０へ問題なくログインできたか否かを判定し、ログインに成功したときはＳ５０６に進み、そうでないときはＳ５１６に進む。Ｓ５０６でＣＰＵ２１１は、中継サーバ１２０へ支援ＵＲＬの作成要求を送信する（Ｓ４０２）。そしてＳ５０７に進みＣＰＵ２１１は、中継サーバ１２０から支援ＵＲＬを受信する（Ｓ４０７）。次にＳ５０８に進みＣＰＵ２１１は、支援ＵＲＬへ参加要求を送信し（Ｓ４０８）、Ｓ５０９でＣＰＵ２１１は、支援ＵＲＬへ参加者情報のＧＥＴポーリングを開始する（Ｓ４０９）。

次にＳ５１０に進みＣＰＵ２１１は、管理サーバ１３０へＭＦＰ識別子と支援ＵＲＬを送信する（Ｓ４１０）。そしてＳ５１１に進みＣＰＵ２１１は、管理サーバ１３０への送信が成功したかを判定し、管理サーバ１３０への送信が成功したと判定した場合はＳ５１２に進み、そうでないときはＳ５２０に進む。Ｓ５１２でＣＰＵ２１１は、中継サーバ１２０から参加者情報を受信する（Ｓ４１３）。これにより、ＭＦＰ１００は自身の支援を行うＰＣ１１０を特定することができる。次にＳ５１３に進みＣＰＵ２１１は、支援ＵＲＬへ支援データのＰＯＳＴポーリングとＧＥＴポーリングを開始する（Ｓ４１４）。ここでの支援データとしては、例えば、動画や音声、或いは遠隔操作の命令データなどが挙げられる。具体的には、上述のように、支援ＵＲＬへの支援データのＰＯＳＴ要求及びＧＥＴ要求を送信することにより、ＰＣ１１０から送信される支援データを受信したり、ＰＣ１１０へ支援データを送信したりする。これによりＭＦＰ１００のユーザは、ＰＣ１１０のオペレータから、音声や動画通信、遠隔操作による支援を受けることが可能となる。

こうして支援が終了するとＳ５１４に進みＣＰＵ２１１は、ユーザが操作部２１９を介して支援停止要求の入力を入力するのを待つ。Ｓ５１４でＣＰＵ２１１は、操作部２１９から支援停止要求の入力を受けるとＳ５１５に進みＣＰＵ２１１は、支援ＵＲＬへ脱退要求を送信して（Ｓ４１８）、この処理を終了する。

一方、Ｓ５０５でＣＰＵ２１１は、中継サーバ１２０へのログインに失敗した場合はＳ５１６に進みＣＰＵ２１１は、管理サーバ１３０に中継サーバ１２０への接続失敗を送信する。次にＳ５１７に進みＣＰＵ２１１は、管理サーバ１３０への送信が成功したかを判定する。ここでＣＰＵ２１１は、管理サーバ１３０への送信が成功したと判定するとＳ５１８に進みＣＰＵ２１１は、コールセンタ１１２へ通知した旨を操作部２１９へ表示して、この処理を終了する。一方、Ｓ５１７でＣＰＵ２１１は、管理サーバ１３０へ送信が失敗したと判定した場合はＳ５１９に進む。Ｓ５１９でＣＰＵ２１１は、コールセンタ１１２の電話番号と、コールセンタ１１２への連絡を促すメッセージ（例えば、「コールセンタに電話して下さい」等）を操作部２１９へ表示して、この処理を終了する。

またＳ５１１でＣＰＵ２１１は、管理サーバ１３０への送信が失敗したと判定した場合はＳ５２０に進みＣＰＵ２１１は、支援ＵＲＬ、コールセンタの電話番号と、コールセンタ１１２への連絡を促すメッセージを操作部２１９へ表示してこの処理を終了する。

図６は、実施形態１に係るＰＣ１１０の動作を説明するフローチャートである。このフローチャートに示す各動作（ステップ）は、ＰＣ１１０のＣＰＵ３１１がＲＡＭ３１３に展開された制御プログラムを実行することによって実現される。尚、以下の説明では図６のステップに対応する図４のステップを括弧内で示す。

先ずＳ６０１でＰＣ１１０のＣＰＵ３１１（以下、ＣＰＵ３１１）は、管理サーバ１３０から支援ＵＲＬ、管理サーバのＵＲＬを受信する（Ｓ４１１）。次にＳ６０２に進みＣＰＵ３１１は、操作部３１７に、支援ＵＲＬ、管理サーバのＵＲＬを表示する。これは、受信した電子メールの情報をそのまま操作部３１７に表示しても良く、或いはアプリケーションの画面として表示しても良い。そしてＳ６０３に進みＣＰＵ３１１は、操作部３１７から支援ＵＲＬへ接続する入力指示を受け付けるのを待ち、支援ＵＲＬへの接続指示を受け付けるとＳ６０４に進みＣＰＵ３１１は、支援ＵＲＬへ参加要求を送信する（Ｓ４１２）。

次にＳ６０５に進みＣＰＵ３１１は、中継サーバ１２０を介した支援データの送受信を開始する。ここでは支援ＵＲＬへ支援データのＰＯＳＴ，ＧＥＴポーリングを開始する（Ｓ４１５）。これによりＰＣ１１０のオペレータは、ＭＦＰ１００のユーザに対して、音声や動画通信、遠隔操作による支援を行うことが可能となる。

次にＣＰＵ３１１はＳ６０６で、操作部３１７から管理サーバ１３０のＵＲＬに接続する指示の入力を待ち、管理サーバ１３０のＵＲＬに接続する指示を受け付けるとＳ６０７に進む。Ｓ６０７でＣＰＵ３１１は、管理サーバ１３０のＵＲＬへＭＦＰ情報を要求する（Ｓ４１６）。次にＳ６０８に進みＣＰＵ３１１は、管理サーバ１３０からＭＦＰ情報を受信すると（Ｓ４１７）Ｓ６０９に進みＣＰＵ３１１は、その受信したＭＦＰ情報を操作部３１７に表示する。これによりＰＣ１１０のオペレータは、支援を行う際に、ＭＦＰ１００の過去のエラーの発生状況を参考にすることが可能となる。こうして支援が終了するとＳ６１０でＣＰＵ３１１は、オペレータが操作部３１７を介して支援停止要求を入力するのを待ち、オペレータが操作部３１７を介して支援停止要求を入力するとＳ６１１に進む。Ｓ６１１でＣＰＵ３１１は、その支援ＵＲＬへ脱退要求を送信して（Ｓ４１９）、この処理を終了する。

こうして、ＭＦＰ１００でエラーが発生すると、ＭＦＰ１００のユーザは中継サーバ１２０を介してＰＣ１１０のオペレータと接続し、ＰＣ１１０のオペレータはＭＦＰ１００のユーザに対して、音声や動画通信、遠隔操作による支援を行うことができる。

図７は、実施形態１に係る中継サーバ１２０の動作を説明するフローチャートである。このフローチャートに示す各動作（ステップ）は、中継サーバ１２０のＣＰＵ３１１がＲＡＭ３１３に展開された制御プログラムを実行することによって実現される。尚、以下の説明では図７のステップに対応する図４のステップを括弧内で示す。

先ずＳ７０１で中継サーバ１２０のＣＰＵ３１１（以下、ＣＰＵ３１１）は、ＭＦＰ１００からログインを受信する（Ｓ４０１）のを待つ。Ｓ７０１でＣＰＵ３１１は、ＭＦＰ１００からログインを受けるとＳ７０２に進み、ＭＦＰ１００から支援ＵＲＬの作成要求を受信する（Ｓ４０２）。次にＳ７０３に進みＣＰＵ３１１は、支援ＵＲＬを作成するか否かを判定するために、管理サーバ１３０にＭＦＰ１００の状態情報を要求する（Ｓ４０３）。ここで要求する情報は、ＭＦＰ１００に限定した状態情報に限定されるものではなく、同じ顧客の複数のＭＦＰ１００に対する状態情報でも良い。ＭＦＰ１００の状態情報の要求以外の例については後述する。

次にＳ７０４に進みＣＰＵ３１１は、その要求に応答して管理サーバ１３０から送信されるＭＦＰ１００の状態情報を受信する（Ｓ４０４）。そしてＳ７０５に進みＣＰＵ３１１は、その受信したＭＦＰ１００の状態情報と、予めＨＤＤ３１４に記憶している条件とに基づいて、支援ＵＲＬを生成するか否かを判定する。ここで支援ＵＲＬを生成しないと判定した場合はＳ７１５に進みＣＰＵ３１１は、ＭＦＰ１００に対し支援ＵＲＬ作成が不可であることを通知して（Ｓ４０５）、この処理を終了する。尚、この通知はエラーメッセージでも、或いはエラーコードのいずれでも良い。

一方、Ｓ７０５でＣＰＵ３１１が、支援ＵＲＬを作成すると判定するとＳ７０６に進みＣＰＵ３１１は、支援ＵＲＬを作成する（Ｓ４０６）。そしてＳ７０７に進みＣＰＵ３１１は、その作成した支援ＵＲＬをＭＦＰ１００に送信する（Ｓ４０７）。次にＳ７０８に進みＣＰＵ３１１は、ＭＦＰ１００から支援ＵＲＬへの参加要求を受信し（Ｓ４０８）、次にＳ７０９でＣＰＵ３１１は、ＭＦＰ１００から参加者情報のＧＥＴポーリングを受信する（Ｓ４０９）。そしてＳ７１０でＣＰＵ３１１は、支援ＵＲＬへの参加要求をＰＣ１１０から受信する（Ｓ４１２）とＳ７１１に進みＣＰＵ３１１は、参加者情報をＭＦＰ１００へ送信する（Ｓ４１３）。こうしてＳ７１２でＣＰＵ３１１は、ＭＦＰ１００とＰＣ１１０から支援データのＰＯＳＴポーリングを受信すると、その支援データをＲＡＭ３１３に格納する。また、ＭＦＰ１００又はＰＣ１１０から支援データのＧＥＴ要求を受信すると、ＲＡＭ３１３に格納されていた支援データを要求元に送信する。これにより、ＭＦＰ１００とＰＣ１１０間で支援データが送受信され、その上でＰＣ１１０のオペレータは、ＭＦＰ１００のユーザの支援を行うことができる（Ｓ４１４，Ｓ４１５）。

こうして支援が終了するとＳ７１３でＣＰＵ３１１は、ＭＦＰ１００とＰＣ１１０から、支援ＵＲＬへ脱退要求を受信するのを待つ（Ｓ４１８，Ｓ４１９）。そしてＳ７１３でＣＰＵ３１１は、支援ＵＲＬへ脱退要求を受信するとＳ７１４に進み、ＣＰＵ３１１は支援ＵＲＬを破棄して（Ｓ４２０）、この処理を終了する。

こうして、ＰＣ１１０のオペレータはＭＦＰ１００のユーザに対して、音声や動画通信、遠隔操作による支援を行うことができる。

図８は、実施形態１に係る管理サーバ１３０の動作を説明するフローチャートである。このフローチャートに示す各動作（ステップ）は、管理サーバ１３０のＣＰＵ３１１がＲＡＭ３１３に展開された制御プログラムを実行することによって実現される。尚、以下の説明では図８のステップに対応する図４のステップを括弧内で示す。

まずＳ８０１で管理サーバ１３０のＣＰＵ３１１（以下、ＣＰＵ３１１）は、ＭＦＰ１００からＭＦＰ識別子と支援ＵＲＬを受信するのを待つ（Ｓ４１０）。ＭＦＰ識別子と支援ＵＲＬを受信するとＳ８０２に進みＣＰＵ３１１は、ＭＦＰ管理テーブル１３１に基づいて、ＭＦＰ１００に対応するコールセンタ１１２のＰＣ１１０を特定し、ＰＣ１１０へ支援ＵＲＬと管理サーバ１３０のＵＲＬを送信する（Ｓ４１１）。次にＳ８０３に進みＣＰＵ３１１は、ＰＣ１１０から管理サーバ１３０のＵＲＬへＭＦＰ情報要求が送られてくるのを待つ（Ｓ４１６）。ＭＦＰ情報要求を受信するとＳ８０４に進みＣＰＵ３１１は、その要求されたＭＦＰ１００のデバイス情報をＰＣ１１０に送信して（Ｓ４１７）、この処理を終了する。

こうして管理サーバ１３０は、ＰＣ１１０が支援するＭＦＰ１００の情報をＰＣ１１０に知らせることができる。

図９は、実施形態１に係る管理サーバ１３０のＨＤＤ３１４に記憶されているＭＦＰ情報の一例を説明する図である。

このＭＦＰ情報はＭＦＰ管理テーブル１３１に記憶されており、このＭＦＰ管理テーブル１３１は、ＭＦＰＩＤ９１０、ユーザ（顧客）ＩＤ９２０、コールセンタＩＤ９３０、支援ＩＤ９４０を含む。ＭＦＰＩＤ９１０は、各ＭＦＰを一意に識別するための識別情報で、図４のＳ４１０でＭＦＰ１００から管理サーバ１３０へ送信されるＭＦＰ識別子に該当する。図９では、ＭＦＰＩＤ９１０には「Device001」が登録されている。情報９１１は、ＭＦＰ１００の製品名称（ここでは「MFP-A」）を示す情報である。情報９１２は、ＭＦＰ１００の過去の通報を識別するための情報で、この情報９１２は通報の数に応じて複数あってもよい。図９では、情報９１２は一つだけで「Call001」である。情報９１３は通報の日時を示す情報である。情報９１４は、通報の内容を示す情報である。情報９１５は、通報のステータスを示す情報である。これら情報９１２〜９１５は、図４のＳ４１７で管理サーバ１３０からＰＣ１１０に送信されるＭＦＰ情報に該当する。

ユーザＩＤ９２０は、ＭＦＰ１００の顧客を識別するための情報で、ここでは「User001」である。ユーザ名称９２１は、顧客の名称を示す情報である。

コールセンタＩＤ９３０は、ＭＦＰ１００のコールセンタ１１２を識別するための識別情報（コールセンタＩＤ）である。名称９３１はコールセンタの名称を示し、メールアドレス９３２は、コールセンタ１１２のメールアドレスを示す情報で、このメールアドレス９３２は、図４のＳ４１１での電子メールの送信先として使われる情報である。

支援ＩＤ９４０は、支援作業を識別するための情報（支援ＩＤ）である。図４のＳ４１０でＭＦＰ１００から管理サーバ１３０にＭＦＰ識別子と支援ＵＲＬが送信されたタイミングで、この支援ＩＤ９４０が更新される。支援ＵＲＬ９４１は、図４のＳ４０７，Ｓ４１１で送信される支援ＵＲＬに該当する。

このように、管理サーバ１３０は、ＭＦＰ１００と、そのＭＦＰ１００を使用しているユーザ、及びそのＭＦＰの保守運用を行っているコールセンタ１１２を対応付けて管理している。よって管理サーバ１３０の管理下にあるＭＦＰ１００であれば、どのＭＦＰ１００において支援開始操作が行われた場合であっても、適切なコールセンタに対して支援に必要な情報（支援ＵＲＬ等）を通知することができる。

以上説明したように実施形態１によれば、ＭＦＰ１００が中継サーバ１２０から割り当てられた支援ＵＲＬを管理サーバ１３０に通知し、管理サーバ１３０が適切なコールセンタ１１２のＰＣ１１０へ、そのＵＲＬを通知する。これによりＭＦＰ１００のユーザは、支援開始の指示を行うだけで、ＰＣ１１０とＭＦＰ１００との間で中継サーバ１２０を介した通信が可能となり、ＰＣ１１０のオペレータにより遠隔から支援を受けることができる。

図１０は、実施形態１に係る中継サーバ１２０がＭＦＰ１００からのログインに応じて管理サーバ１３０からデバイスの状態情報を取得しＭＦＰ１００との接続を制御する手順を説明するフローチャートである。

この前提となる動作を図４を参照して説明する。図４のＳ４０１でＭＦＰ１００がログインした後、Ｓ４０２で、ＭＦＰ１００が、空き会議室の確保を中継サーバ１２０に要求する。このとき中継サーバ１２０は、自身の支援用に利用できるリソースの状況に応じて管理サーバ１３０に対しデバイス情報を要求し（Ｓ４０３）、ログインしてきたＭＦＰ１００のデバイスの状態を問い合わせる。管理サーバ１３０は、ＭＦＰ１００からの状態情報を逐次受信しているので、中継サーバ１２０からのデバイス情報の要求に対して、Ｓ４０４でデバイスの情報を提供できる。これにより中継サーバ１２０は、その受信したデバイスの情報に応じて、ＭＦＰ１００との接続が可能かどうかをＭＦＰ１００に通知する（Ｓ４０７）。また或いは、空いている会議室がないときは、会議室を提供できない旨のエラーコードをＭＦＰ１００に通知する（Ｓ４０５）。これにより、中継サーバ１２０は、要求してきたＭＦＰ１００の状態に応じて接続を許可或いは拒否する制御が可能になる。尚、図４では、ＭＦＰ１００との接続後に管理サーバ１３０へのデバイス情報要求を行っているが、Ｓ４０１のログイン処理時に行っても良い。

次に図１０のフローチャートを参照して、実施形態１に係る中継サーバ１２０の処理を説明する。尚、このフローチャートに示す各動作（ステップ）は、中継サーバ１２０のＣＰＵ３１１がＲＡＭ３１３に展開された制御プログラムを実行することによって実現される。ここではＭＦＰ１００からの、空いている会議室があるかどうかの問い合わせに対して、管理サーバ１３０が管理しているＭＦＰのデバイス情報を基に、そのＭＦＰと中継サーバ１２０とを接続するかどうかを判定する。

まずＳ１００１で中継サーバ１２０のＣＰＵ３１１（以下、ＣＰＵ３１１）は、管理サーバ１３０にログインする。このログインを行う方法としてはＩＤ、パスワードによるログインでも良く、或いはプロトコルによるネゴシエーションでも良い。又は、互いに管理サーバ１３０の情報を把握しているのでルータなどにより接続制限を行い、ＩＤ、パスワード無しで常時接続を行っても良い。次にＳ１００２に進みＣＰＵ３１１は、ＭＦＰ１００からの接続要求を待つ。図４で説明したように、Ｓ１００２は、ＭＦＰ１００からのログイン要求時、或いは支援用ＵＲＬ作成時のいずれの処理でも良い。

ＭＦＰ１００からの接続要求があるとＳ１００３に進み、ＣＰＵ３１１は、支援するためのリソース（ここでは空いている会議室）があるかをチェックする。リソースのチェック方法は、支援用のＵＲＬの最大発行可能数をＨＤＤ３１４に保有しておいてもよいし、支援中の利用形態に応じてリソースの不足を判定してもよい。例えば音声と遠隔操作の通信が大半で、動画があまり利用されていない等の条件でリソース利用状況の判定を行ってもよい。

図１３は、実施形態１に係る中継サーバ１２０が、ＭＦＰ１００と接続するかを判定するのに使用するテーブルの一例を示す図である。

図１３（Ａ）では、接続が可能な残りのリソース数（未使用会議室数）を閾値として持っており、この値を下回っている場合は支援用ＵＲＬが作成できないと判定する。この場合はＳ１００３からＳ１０１０に進み、ＣＰＵ３１１は、ＭＦＰ１００に対しエラーコードを返却し、コネクションを切断して、この処理を終了する。

リソース数（空き会議室の数）がゼロより大きく、かつ閾値を上回っている場合は、リソースに空きがあり、新たに支援用のＵＲＬ作成が可能であると判定してＳ１００４に進む。Ｓ１００４でＣＰＵ３１１は、管理サーバ１３０に対して、ＭＦＰ１００の識別情報と検索条件を通知する。ＭＦＰ１００の識別情報はユニークに発番されるシリアル番号などを用いる。また検索条件は、管理サーバ１３０にＭＦＰ１００単体の状態について情報を取得するのか、或いはＭＦＰ１００を管理している顧客に設置されている全てのＭＦＰの状態情報を取得するのか等を指定する。またエラーが発生しているだけか、警告も含めて状態情報があるかなど、中継サーバ１２０のリソースの都合に合わせて動的に検索条件を変更してもよい。尚、リソース数がゼロの場合は遠隔支援はできないと判定してＳ１０１０で、エラーコードをＭＦＰ１００に返却し、通信を切断する。

図１３（Ｂ）は、検索条件の一例を示す図である。

支援ＵＲＬの作成を要求してきたＭＦＰ１００のみのＭＦＰの情報を管理サーバ１３０に要求する「デバイス単体」指定や、同じ環境内にあるＭＦＰ１００も含めたＭＦＰの情報を要求する「グループ単位」、「販社単位」を例に挙げている。図１３（Ｂ）では、「デバイス単位」で検索する有効フラグがオン「１」に設定されている。

管理サーバ１３０は、受信したデバイス識別情報と検索条件に従って検索を実施し、そのＭＦＰ１００が管理サーバ１３０の監視対象外であれば中継サーバ１２０に対し、条件に合致するＭＦＰ１００がないことを通知する。これによりＳ１００５でＣＰＵ３１１は、通知された情報に含まれる管理サーバ１３０が要求したＭＦＰ１００を管理対象であるか否かの情報に従って、対象デバイスかどうかを判定する。ここで管理対象のデバイスであると判定するとＳ１００６に進み、デバイス状態情報の比較処理を実行する。

図１３（Ｃ）は、優先接続条件に指定されている優先対象情報番号と、その発生コードを説明する図である。

Ｓ１００６のデバイス情報の比較処理では、図１３（Ｃ）の優先対象情報番号の全てに対して、検索と比較処理を実施する。Ｓ１００７でＣＰＵ３１１は、デバイス情報が、発生コードに一つでも合致している場合は、接続優先条件を満たしていると判定してＳ１００８に処理を進め、接続許可処理を実行して、ＭＦＰ１００との接続を許可して接続制御処理を終了する。一方、接続優先条件を満たしていないと判定するとＳ１０１０に進みＣＰＵ３１１は、エラーコードをＭＦＰ１００に返却し通信を切断して、この処理を終了する。一方、Ｓ１００５でＣＰＵ３１１は、ＭＦＰ１００が管理サーバ１３０の管理対象でないと判定した場合はＳ１００９に進み、管理サーバ１３０で管理されていない場合の判定情報を確認する。

図１３（Ｄ）は、実施形態１に係る判定情報の一例を示す図である。

図１３（Ｄ）では、管理サーバ１３０に登録されていない場合に、接続を優先する有効フラグに「１」が設定されている。従ってこの場合は、ＭＦＰ１００との接続を許可するようにＳ１００８の接続許可処理に進む。管理サーバ１３０で管理されていないためにＭＦＰ１００の状態を把握することができない場合は、この有効フラグに「１」を設定する。これにより、ＭＦＰ１００の状態が不明であっても接続要求を優先することができる。逆に有効フラグに「０」を設定すれば、管理サーバ１３０の管理対象外のときは、遠隔支援を受け付けないようにできる。その場合はＳ１００９からＳ１０１０に進んで、ＭＦＰ１００に対してエラーコードを返却して通信を切断し、この処理を終了する。

またＳ１００７で、図１３（Ｃ）の優先接続条件に指定されている優先対象情報番号のいずれにも合致しない場合は、ＭＦＰ１００が優先的に接続する条件を満たしていないと判定する。このときはＳ１０１０でＭＦＰ１００に対してエラーコードを返却して通信を切断し、この処理を終了する。図１３（Ｃ）では、ＭＦＰ１００が利用できなくなるエラーコードや、紙詰まり（ジャム）が多発といった発生コードを格納しているが、コードで表すことができれば画像不良を警告するワーニング情報などを格納してもよい。

このように実施形態１に係る中継サーバ１２０によれば、ＭＦＰからの接続要求に対して管理サーバが管理しているＭＦＰの情報を参照することにより、ＭＦＰとの接続を許可するかどうかを判定できる。

図１１は、実施形態１に係る管理サーバ１３０の処理を説明するフローチャートである。この処理は、図１０のフローチャートで示す中継サーバ１２０の処理と対になる処理を示す。尚、このフローチャートに示す各動作（ステップ）は、管理サーバ１３０のＣＰＵ３１１がＲＡＭ３１３に展開された制御プログラムを実行することによって実現される。

先ずＳ１１０１で管理サーバ１３０のＣＰＵ３１１（以下、ＣＰＵ３１１）は、中継サーバ１２０からのログイン要求を受信するとＳ１１０２に進む。Ｓ１１０２でＣＰＵ３１１は、所定のルールに従って、中継サーバ１２０からのログイン要求が成功したかどうかを判定する。ここで、もし中継サーバ１２０が未登録の場合や、パスワードの期限切れなどによりログインを許可できない場合はＳ１１０８に進みＣＰＵ３１１は、中継サーバ１２０に対してログイン失敗であることを示す情報を返却して、この処理を終了する。

Ｓ１１０２でＣＰＵ３１１は、中継サーバ１２０によるログインが成功したと判定するとＳ１１０３に進みＣＰＵ３１１は、中継サーバ１２０より、ＭＦＰ１００の識別情報と検索条件が通知されるのを待つ。ＭＦＰ１００の識別情報と検索条件が通知されるとＳ１１０４に進みＣＰＵ３１１は、その通知されたＭＦＰ１００の識別情報と検索条件とに従って、ＨＤＤ３１４に格納しているＭＦＰ１００の情報の履歴の検索を実行する。ここでは最初、ＭＦＰ１００が管理サーバ１３０に登録されているかを検索する。ＨＤＤ３１４にＭＦＰ１００の識別情報が登録されていない場合は管理対象ではないため、そのＭＦＰの情報の履歴も存在しない。この場合はＳ１００９に進みＣＰＵ３１１は、対象のＭＦＰ１００の情報を返せないとして、検索対象のＭＦＰ１００が管理対象外である旨のエラーを中継サーバ１２０に返却して、この処理を終了する。この情報は、前述の図１０のＳ１００５で中継サーバ１２０が受信する。

Ｓ１１０５でＣＰＵ３１１が、ＭＦＰ１００が登録されていると判定するとＳ１１０６に進み、ＣＰＵ３１１は、検索条件に従ってＨＤＤ３１４の履歴データを検索する。ここで検索条件に合致する情報が見つからない場合はＳ１１１０に進みＣＰＵ３１１は、情報がない旨の応答を中継サーバ１２０に返して、この処理を終了する。Ｓ１１０６でＣＰＵ３１１が、検索条件に合致する情報が存在すると判定するとＳ１１０７に進みＣＰＵ３１１は、その情報を中継サーバ１２０に返して、この処理を終了する。ここで検索される情報の具体例として、「エラーが発生している」「現時点から一定期間前にジャムが多発している」等のように、ユーザがＭＦＰ１００の使用上、問題であると考えられるものが挙げられる。また管理サーバ１３０が中継サーバ１２０に返す情報は、中継サーバ１２０が検索条件として「エラー」「ジャムの多発」等を指定することで、それに対応する情報として取得できるようにする。

以上説明したように実施形態１によれば、中継サーバ１２０は、ＭＦＰ１００の状態に応じて、そのＭＦＰを支援する優先度を制御することが可能となる。

［実施形態２］
次に本発明の実施形態２を説明する。この実施形態２では、検索条件を変えることにより、異常が発生していないＭＦＰ１００からの接続要求を優先させる例を説明する。尚、実施形態２に係るＭＦＰ１００，ＰＣ１１０，中継サーバ１２０、管理サーバ１３０の構成は前述の実施形態１と同様であるため、その説明を省略する。

図９を参照して前述したように、ＭＦＰ１００は、ＭＦＰＩＤ９１０で管理サーバ１３０により管理されている。またＭＦＰ１００は、顧客ＩＤ９２０と顧客の名称９２１と関連付けられている。ここでは一つの顧客に２台以上のＭＦＰ１００を登録することもでき、任意のＭＦＰ１００から、同じ顧客で管理されている他のＭＦＰを検索することもできる。これを利用して、中継サーバ１２０は、ＭＦＰ１００の情報を管理サーバ１３０にデバイス情報や検索条件等を要求する際、検索条件として同一顧客内の他のＭＦＰの状態情報も検索するように要求する。これにより、ユーザが問い合わせをしたいＭＦＰ１００が異常状態にあるために利用できない場合、同じ環境内にある、同一顧客の他の正常なＭＦＰからの問い合わせと同様に扱うことができる。このときは、ＭＦＰ単体でなく、どの範囲で検索するかは、前述の図１３（Ｂ）で、グループ単位や販社単位の有効フラグを「１」にすることにより指定できる。こうしてＭＦＰ単体でない検索条件で状態情報を検索することにより、正常なＭＦＰが、異常が発生しているＭＦＰの代わりに遠隔サポートを要求してきたとみなすことができる。また、同一顧客が所有しているＭＦＰの台数が多い場合、顧客情報を分割して、例えばＭＦＰの管理者別にグループ分けすることで、検索対象のＭＦＰの台数を抑えることができる。これにより、例えば、異常が発生している第１のＭＦＰと全く異なる設置場所にある第２のＭＦＰの場合、第１のＭＦＰからの遠隔サポート要求の対象にならないとみなせる。

図１２は、実施形態２に係るシステム構成例を示す図である。

管理サーバ１３０の管理対象であるＭＦＰ群は、企業Ａ１０２の顧客１（１２０１）、顧客２（１２０２）として登録、管理されている。このように大企業などでは、ファイアウォール１０１の内側で、各部単位や建物単位でＭＦＰが配置されることが多く、管理者も異なる場合がある。従って管理サーバ１３０は、ＭＦＰの管理元や設置場所に応じてＭＦＰを登録することで、各ＭＦＰがそれぞれ近傍にあるのか、管理者が同一であるかを把握することができる。

実施形態２では、顧客１のＭＦＰ−ａが異常でダウンした場合、同一顧客内のＭＦＰ−ｂからの遠隔サポート要求もＭＦＰ−ａと同じ状態として扱い、ＭＦＰ−ｂとの接続を優先させることができる。また、何も問題が発生していない別顧客２のＭＦＰ−ｃからの遠隔サポート要求は、状態が正常とみなし、中継サーバ１２０の接続数がひっ迫している場合は、その接続優先度を下げる。

以上説明したように実施形態２によれば、中継サーバ１２０は、接続要求を発行したＭＦＰが属するグループの他のＭＦＰの状態を調べることで、適切に支援の優先度を制御することが可能となる。

尚、この実施形態２では、図１３（Ｃ）の発生コードの条件を、エラーとジャム多発としたが、元のＭＦＰ以外の検索時は、別の優先条件を設けてもよい。例えばＭＦＰの表示部が利用できない液晶エラーや電源異常のエラー通知に限定する。これにより、異常のないＭＦＰからの接続要求時に、近隣で異常が発生しているＭＦＰが遠隔支援要求を行うことができないと見なすなど、接続条件を厳しくすることもできる。

以上説明したように実施形態２によれば、中継サーバ１２０は、管理サーバ１３０が管理しているＭＦＰの管理情報を用いて、条件付きで、ＭＦＰ１００以外からの接続要求に対し柔軟に優先度を制御することが可能となる。

［実施形態３］
次に本発明の実施形態３を説明する。この実施形態３では、管理サーバ１３０から中継サーバにに送られるデバイス情報の内容を変更することにより、異常が発生しているＭＦＰ１００からの接続要求の比率や接続台数を、中継サーバ１２０が変更する。尚、実施形態３に係るＭＦＰ１００，ＰＣ１１０，中継サーバ１２０、管理サーバ１３０の構成は前述の実施形態１と同様であるため、その説明を省略する。

図１４は、実施形態３に係る管理サーバ１３０が管理しているＭＦＰ群で発生しているエラー数を集計してグラフ化した図である。

図１４（Ａ）の１４０１は、各地域の１日（２４時間）で発生したエラーの数を示している。集計の方法は、昨日、先週、毎日の平均など様々な条件で集計してよい。図１４（Ｂ）の１４０３は、１週間の曜日ごとに発生したエラーの数を示している。集計の方法は先週のみとか、過去何カ月分の平均など状況に応じた条件で集計する。

遠隔支援サービスは、エラーが発生することで接続を要求されるケースがあり、エラーの発生数が多い曜日、時間帯は、中継サーバ１２０が混みあう可能性がある。そこで、過去のエラー発生状況に基づいて混みあう時間帯（１４０２，１４０４）を予測し、その時間帯では、正常なＭＦＰからの接続優先度を低下させて、異常が発生しているＭＦＰからの接続要求を優先させる。

図１５は、実施形態３に係る中継サーバ１２０の処理を説明するフローチャートである。尚、このフローチャートに示す各動作（ステップ）は、中継サーバ１２０のＣＰＵ３１１がＲＡＭ３１３に展開された制御プログラムを実行することによって実現される。

まずＳ１５０１で中継サーバ１２０のＣＰＵ３１１（以下、ＣＰＵ３１１）は、管理サーバ１３０にログインする。このログインは、前述のＭＦＰ１００の検索要求時のログインを代用してもよいし、この集計処理のためだけにログインを行ってもよい。次にＳ１５０２に進みＣＰＵ３１１は、管理サーバ１３０より集計情報を取得する。次にＳ１５０３に進みＣＰＵ３１１は、Ｓ１５０２で取得した集計情報より、ある一定の数のエラー数が発生している時間帯を抽出する（１４０２，１４０４）。ここで、所定数のエラー数は、図１３（Ｅ）のエラー数閾値テーブルに予め設定しておく。図１３（Ｅ）では、どの期間で、何件のエラーを閾値とするかを格納しておく。図１３（Ｅ）では、パラメータゼロを日単位とし、１日の中でのエラー数「８００」件を閾値としている。

従って、この例では、Ｓ１５０３で、１日の中で８００件以上のエラーが発生している時間帯を先の集計情報より抽出するとＳ１５０４に進む。Ｓ１５０４でＣＰＵ３１１は、その該当する時間帯では、図１３（Ａ）の未使用会議室閾値で設定している閾値を一時的に大きくする。これにより、エラーの発生数が閾値を越えている時間帯は、未使用のリソース数が大きく取られるため、エラーが発生していないＭＦＰ１００からの遠隔支援の要求を、通常より多く拒否することができる。これによりエラーが発生しているＭＦＰのために予め多くのリソースを確保でき、エラーが発生しているＭＦＰの接続数を多くとることになる。

実施形態３では、エラーが発生する例に挙げたが、用紙詰まりの多発数や、電源が入っているＭＦＰの台数が多い時間など、管理サーバ１３０が管理可能な集計情報で、かつ中継サーバ１２０が接続制御の情報として利用できるものであれば何でもよい。

以上説明したように実施形態３によれば、中継サーバ１２０は、管理サーバ１３０の集計情報を用いて、問題が発生しているＭＦＰ１００からの接続要求数を多めに確保することが可能となる。

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

本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

１００…ＭＦＰ，１０１，１１１…ファイアウォール、１１０…ＰＣ，１２０…中継サーバ、１３０…管理サーバ、２１１…ＣＰＵ、２１９…操作部、３１１…ＣＰＵ、操作部…３１７。

Claims (6)

1. 第１の端末と第２の端末と、前記第１と第２の端末を中継する中継サーバと、前記第１の端末を管理する管理サーバとを含む通信システムであって、
   前記中継サーバは、
   前記第１の端末からの接続要求に応じて検索条件を生成し、前記管理サーバに前記第１の端末の状態を検索するように要求する要求手段と、
   前記要求手段により要求に応答して前記管理サーバから送信される前記第１の端末のデバイス情報を取得すると中継情報を生成して前記第１の端末に送信する第１送信手段と、
   前記中継情報に従って前記第１と第２の端末の通信を制御する制御手段と、を有し、
   前記管理サーバは、
   前記要求手段で要求された前記検索条件に応じて前記第１の端末の状態情報を検索して前記デバイス情報として前記中継サーバに通知する通知手段と、
   前記第１の端末からの前記中継情報を受信することに応じて、前記第２の端末に当該中継情報を送信する第２送信手段と、を有し、
   前記第２の端末は、前記中継サーバを介して前記第１の端末の遠隔支援のための通信を行うことを特徴とする通信システム。
2. 前記検索条件は、前記第１の端末だけ、或いは前記第１の端末を含むグループを検索対象とする条件を含むことを特徴とする請求項１に記載の通信システム。
3. 前記管理サーバは、前記要求手段で要求された前記第１の端末が管理対象でない場合は対象デバイスでない旨を前記中継サーバに通知し、
   前記中継サーバは、前記管理対象でない端末を優先するように設定されている場合、前記第１の端末の中継情報を生成して前記第１の端末に送信することを特徴とする請求項１又は２に記載の通信システム。
4. 前記中継サーバの前記要求手段は、前記第１の端末から会議室の接続要求を受け取ると、未使用の会議室の数が閾値よりも多い場合に、前記管理サーバに前記第１の端末の状態を検索するように要求することを特徴とする請求項１に記載の通信システム。
5. 前記管理サーバが管理している前記第１の端末で発生しているエラー数が所定数よりも大きい時間帯では前記閾値を大きく設定する設定手段を更に有することを特徴とする請求項４に記載の通信システム。
6. 第１の端末と第２の端末と、前記第１と第２の端末を中継する中継サーバと、前記第１の端末を管理する管理サーバとを含む通信システムを制御する制御方法であって、
   前記中継サーバは、
   前記第１の端末からの接続要求に応じて検索条件を生成し、前記管理サーバに前記第１の端末の状態を検索するように要求する要求工程と、
   前記要求工程での要求に応答して前記管理サーバから送信される前記第１の端末のデバイス情報を取得すると中継情報を生成して前記第１の端末に送信する第１送信工程と、
   前記中継情報に従って前記第１と第２の端末の通信を制御する制御工程と、を実行し、
   前記管理サーバは、
   前記要求工程で要求された前記検索条件に応じて前記第１の端末の状態情報を検索して前記デバイス情報として前記中継サーバに通知する通知工程と、
   前記第１の端末からの前記中継情報を受信することに応じて、前記第２の端末に当該中継情報を送信する第２送信工程と、を実行し、
   前記第２の端末は、前記中継サーバを介して前記第１の端末の遠隔支援のための通信を行うことを特徴とする通信システムの制御方法。

Images