(57)【要約】【課題】ネットワークデバイスが管理装置との間のセッションを中断する必要がある状態へ遷移した場合であっても、ネットワークデバイスにおいて発生したイベントを漏れなく管理することができる管理装置を提供する。【解決手段】ＮＥＴＣＯＮＦを利用してＭＦＰ１０２を管理する管理サーバ１０１であって、ＭＦＰ１０２に対して、ＭＦＰ１０２が管理サーバ１０１に対してイベント通知を行うべき条件の指定を登録し、ＭＦＰ１０２から、該ＭＦＰ１０２と管理サーバ１０１との間のイベント通知が可能なセッションを確立している第１状態から該セッションを切断する必要がある第２状態に遷移することを示す第１通知と、第２状態から第１状態に復帰することを示す第２通知とを受信し、第２通知の受信に応じて、条件の指定をＭＦＰ１０２に対して再登録する。【選択図】図１１
2018061142.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して、所定のプロトコルを利用して、ネットワークデバイスを管理する管理装置であって、
ネットワークデバイスに対して、該ネットワークデバイスが前記管理装置に対してイベント通知を行うべき条件の指定を登録する登録手段と、
ネットワークデバイスから、該ネットワークデバイスと前記管理装置との間の前記イベント通知が可能なセッションを確立している第１状態から該セッションを切断する必要がある第２状態に遷移することを示す第１通知と、前記第２状態から前記第１状態に復帰することを示す第２通知とを受信する受信手段と、を有し、
前記登録手段は、前記第２通知の受信に応じて、前記条件の指定を前記ネットワークデバイスに対して再登録する、ことを特徴とする管理装置。
【請求項２】
前記所定のプロトコルは、ＮＥＴＣＯＮＦである、ことを特徴とする請求項１に記載の管理装置。
【請求項３】
前記所定のプロトコルで利用される前記ネットワークデバイスの複数のデータストアは、Ｒｕｎｎｉｎｇのデータストアに加えて、Ｃａｎｄｉｔａｔｅのデータストア、及びＳｔａｒｔｕｐのデータストアの少なくともいずれかを含む、ことを特徴とする請求項１または２に記載の管理装置。
【請求項４】
前記登録手段は、前記第２通知の受信に応じて、前記条件の指定を前記ネットワークデバイスに対して再登録する際に、前記条件に合致するイベントのなかで通知対象を決定するために利用される時間情報として、前記第１通知に従い前記セッションを用いたイベント通知に係る処理を中断した時間を設定する、ことを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。
【請求項５】
前記第１通知に従い前記セッションを用いたイベント通知に係る処理を中断した時間を記憶する記憶手段を有する、ことを特徴とする請求項４に記載の管理装置。
【請求項６】
ネットワークデバイスからポーリングにより該ネットワークデバイスの状態を取得する取得手段を有し、
前記セッションが中断された場合であって、前記第１通知に従い前記セッションを用いたイベント通知に係る処理を中断した時間が前記記憶手段に記憶されていないときに、前記取得手段は、前記ネットワークデバイスが前記第１状態に復帰するまで該ネットワークデバイスの状態を取得しつづける、ことを特徴とする請求項５に記載の管理装置。
【請求項７】
前記登録手段は、前記第２通知の受信に応じて、前記条件の指定を前記ネットワークデバイスに対して再登録する際に、前記条件に合致するイベントのなかで通知対象を決定するために利用される時間情報として、前記第１通知を受信した時刻から前記第２通知を受信する前の時刻までの間の時間を設定する、ことを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。
【請求項８】
前記第２状態は、前記ネットワークデバイスがスリープ状態、または電源ＯＦＦの状態である、ことを特徴とする請求項１乃至７のいずれか１項に記載の管理装置。
【請求項９】
前記登録手段は、前記条件として前記第２状態への遷移を示すイベントを指定する、ことを特徴とする請求項１乃至８のいずれか１項に記載の管理装置。
【請求項１０】
前記条件は、各イベントの重要度を含む、ことを特徴とする請求項１乃至９のいずれか１項に記載の管理装置。
【請求項１１】
ネットワークを介して、所定のプロトコルを利用して、ネットワークデバイスを管理する管理装置の制御方法であって、
ネットワークデバイスに対して、該ネットワークデバイスが前記管理装置に対してイベント通知を行うべき条件の指定を登録する工程と、
ネットワークデバイスから、該ネットワークデバイスと前記管理装置との間の前記イベント通知が可能なセッションを確立している第１状態から該セッションを切断する必要がある第２状態に遷移することを示す第１通知を受信する工程と、
前記第２状態から前記第１状態に復帰することを示す第２通知を受信する工程と、
前記第２通知の受信に応じて、前記条件の指定を前記ネットワークデバイスに対して再登録する工程と、を有することを特徴とする制御方法。
【請求項１２】
請求項１乃至１０のいずれか１項に記載の管理装置が備える各手段としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理装置、制御方法、及びプログラムに関する。
【背景技術】
【０００２】
ルータやコンピュータ、ＭＦＰ（多機能周辺装置）等のネットワークデバイスを管理するシステムがある。このようなシステムでは、管理サーバがネットワークデバイスから障害の発生や状態の遷移などのイベントを受信し、受信したイベントに応じて管理者にメールを送信する等の処理を行う。ネットワークデバイスがイベントを通知する方法としては、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）のｔｒａｐやＮＥＴＣＯＮＦがある。
【０００３】
ＳＮＭＰとは、デバイスをネットワーク経由で監視・制御するためのプロトコルである。ＳＮＭＰのｔｒａｐとは、管理の対象となるネットワークデバイスが管理を行う管理サーバへ発生したイベントを通知する機能である。ＳＮＭＰは、ＵＤＰを利用して送信することが一般的であり、データの到達保証性がない。そのため、ＳＮＭＰのｔｒａｐにおいてもイベントの到達保証性がない。
【０００４】
ＮＥＴＣＯＮＦは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）において標準化が進められているプロトコルである。ＮＥＴＣＯＮＦは、デバイスと管理サーバとの間をＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）でやりとりする。また、ＮＥＴＣＯＮＦでは、ＵＤＰではなくＴＣＰ等を用いてコネクション指向のセッションを確立してデータを送ることが規定されている。そのためイベントの到達保証性も含めた信頼性の高いイベント通知を実現できる。
【０００５】
一方、ＭＦＰ等のデバイスは、シャットダウンによる電源ＯＦＦやスリープ状態などの省電力モードへの状態遷移により、管理サーバとのセッションを維持できないことがある。このような場合に、デバイスは、イベント通知を継続できず、管理サーバが受信するイベントに漏れが生じてしまうことがある。
【０００６】
特許文献１は、画像形成装置が監視装置に自発的に状態情報を通知することに加え、監視装置が、定期的に行っている情報取得（ポーリング）により状態情報を取得する監視装置を開示している。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−２８６２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、管理サーバのポーリングによるイベントの取得では、タイミングによっては、ネットワークデバイスがイベント通知を行えない状態に遷移したことの検知が遅れる場合がある。
【０００９】
本発明は、ネットワークデバイスが管理装置との間のセッションを中断する必要がある状態へ遷移した場合であっても、ネットワークデバイスにおいて発生したイベントを漏れなく管理することを可能とする管理装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一実施形態の管理装置は、ネットワークを介して、所定のプロトコルを利用して、ネットワークデバイスを管理する管理装置であって、ネットワークデバイスに対して、該ネットワークデバイスが前記管理装置に対してイベント通知を行うべき条件の指定を登録する登録手段と、ネットワークデバイスから、該ネットワークデバイスと前記管理装置との間の前記イベント通知が可能なセッションを確立している第１状態から該セッションを切断する必要がある第２状態に遷移することを示す第１通知と、前記第２状態から前記第１状態に復帰することを示す第２通知とを受信する受信手段と、を有し、前記登録手段は、前記第２通知の受信に応じて、前記条件の指定を前記ネットワークデバイスに対して再登録する。
【発明の効果】
【００１１】
本発明の管理装置によれば、ネットワークデバイスが管理装置との間のセッションを中断する必要がある状態へ遷移した場合であっても、ネットワークデバイスにおいて発生したイベントを漏れなく管理することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態におけるシステム構成の一例を示す図である。
【図２】管理サーバ及びＭＦＰのハードウェア構成を示す図である。
【図３】管理サーバ及びＭＦＰのソフトウェア構成を示す図である。
【図４】管理サーバ及びＭＦＰが管理するテーブルの構成を示す図である。
【図５】デバイス管理サービスのＵＩの一例を示す図である。
【図６】イベント購読の登録からイベント通知までの処理を示す図である。
【図７】デバイス管理サービスの通知設定を登録する処理を示す図である。
【図８】イベント購読の登録内容の一例を示す図である。
【図９】セッションが維持できない状態へ遷移した際の処理を示す図である。
【図１０】ＭＦＰのスリープへの状態遷移を判断する処理を示す図である。
【図１１】セッションを確立できる状態へ遷移した際の処理を示す図である。
【図１２】イベント購読の再登録を行う際の登録内容の一例を示す図である。
【図１３】予期せぬセッション切断時の処理を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための形態について図面などを参照して説明する。
（第１実施形態）
【００１４】
＜システム構成＞
図１は、本発明の第１実施形態におけるシステム構成の一例を示す図である。
管理サーバ１０１は、ネットワークデバイスの管理装置として機能する。管理サーバ１０１は、ＬＡＮ１０３を介して、ネットワークデバイスと接続される。管理サーバ１０１では、後述するデバイス管理サービスが稼働しており、管理サーバ１０１は、ＮＥＴＣＯＮＦプロトコルを用いて、ネットワークデバイスで発生したイベントを受信する。
【００１５】
なお、本実施形態では、管理サーバ１０１はＮＥＴＣＯＮＦプロトコルを用いてネットワークデバイスからイベントを受信するが、これに限られるものではない。管理サーバ１０１が用いるプロトコルは、所定のプロトコルであって、例えば、ネットワークデバイスで確保される設定情報を管理する複数のデータストア（領域）を利用した設定操作を制御するための要求を定義している。
【００１６】
ＮＥＴＯＣＯＮＦにおける複数のデータストアは、Ｒｕｎｎｉｎｇのデータストアに加えて、Ｃａｎｄｉｔａｔｅのデータストア、及びＳｔａｒｔｕｐのデータストアの少なくともいずれかを含む。Ｒｕｎｎｉｎｇのデータストアとは、現在の設定データを保持する領域であり、デバイス上でアクティブなデータストアである。
【００１７】
Ｃａｎｄｉｄａｔｅのデータストアとは、設定データを一時的に保持する領域であり、ＮＥＴＣＯＮＦで定義されるデバイスの現在の構成に影響を与えることなく操作することができるアクティブでないデータストアである。Ｓｔａｒｔｕｐのデータストアとは、デバイスの起動時に反映する設定データを保持する領域である。Ｒｕｎｎｉｎｇのデータストアは、ＮＥＴＣＯＮＦの仕様上必須のデータストアであり、Ｃａｎｄｉｄａｔｅ及びＳｔａｒｔｕｐのデータストアは、仕様上オプションのデータストアである。
【００１８】
本実施形態では、ネットワークデバイスの一例としてＭＦＰ１０２を用いて説明するが、ネットワークデバイスはＭＦＰに限られるものではない。ネットワークデバイスは、例えば、プリンタやスキャナ、ネットワーク中継機器（ルータ）やネットワークカメラ等の機器をであってもよい。ＭＦＰ１０２は、ＮＥＴＣＯＮＦプロトコルに対応しており、ＭＦＰ１０２で発生したイベントを他の装置に送信する。ＮＥＴＣＯＮＦプロトコルを用いた管理サーバ１０１とＭＦＰ１０２の処理の詳細については、図６を用いて後述する。
【００１９】
＜管理サーバのハードウェア構成＞
図２（Ａ）は、管理サーバ１０１のハードウェア構成の一例を示すブロック図である。
ＣＰＵ２０１を含む制御部２００は、管理サーバ１０１全体の動作を制御する。ＣＰＵ２０１は、ＲＯＭ２０２に記憶された制御プログラムを読み出して各種制御処理を実行する。
【００２０】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリであり、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２０４は、画像データや各種プログラム、または後述する各種情報テーブルを記憶する。ネットワークＩ／Ｆ（インタフェース）２０５は、制御部２００をＬＡＮに接続する。ネットワークＩ／Ｆ２０５は、ネットワークを介して他の装置との間で各種情報を送受信する。
【００２１】
＜ＭＦＰのハードウェア構成＞
図２（Ｂ）は、ＭＦＰ１０２のハードウェア構成の一例を示すブロック図である。
ＭＦＰ１０２は、コントローラユニット２５０、操作部２５８、画像入力デバイスであるスキャナ２６４、及び画像出力デバイスであるプリンタ２６５を備える。コントローラユニット２５０は、スキャナ２６４やプリンタ２６５と接続されるとともに、操作部２５８と接続される。
【００２２】
コントローラユニット２５０は、スキャナ２６４で読み取られた画像データをプリンタ２６５により印刷出力するコピー機能を実現するための制御を行う。コントローラユニット２５０は、プロセッサであるＣＰＵ２５１を有し、ＣＰＵ２５１は、ＲＯＭ２５５に記憶されているブートプログラムによりオペレーションシステム（ＯＳ）を立ち上げる。ＣＰＵ２５１は、ＯＳ上で、ＨＤＤ（ハードディスクドライブ）２５６に記憶されているプログラムを実行することにより各種処理を実行する。
【００２３】
ＲＡＭ２５２は、ＣＰＵ２５１のワークエリアとして用いられる。ＲＡＭ２５２は、ワークエリアを提供するとともに、画像データを一時記憶するための画像メモリ領域を提供する。ＨＤＤ２５６は、プログラムや画像データを記憶する。ＣＰＵ２５１は、システムバス２５９を介して、ＲＯＭ２５５、ＲＡＭ２５２、操作部Ｉ／Ｆ２５３と接続されている。ＣＰＵ２５１は、さらにネットワークＩ／Ｆ２５４及び画像バスＩ／Ｆ２５７と接続されている。
【００２４】
操作部Ｉ／Ｆ２５３は、タッチパネルを有する操作部２５８のインタフェースであり、操作部２５８に表示する画像データを操作部２５８に対して出力する。また、操作部Ｉ／Ｆ２５３は、操作部２５８においてユーザが入力した情報をＣＰＵ２５１に送信する。ネットワークＩ／Ｆ２５４は、ＭＦＰ１０２をＬＡＮに接続するためのインタフェースである。画像バスＩ／Ｆ２５７は、システムバス２５９と画像データを高速で転送する画像バス２６０とを接続し、データ形式を変換するためのバスブリッジである。画像バス２６０は、ＰＣＩバスまたはＩＥＥＥ１３９４等によって構成される。
【００２５】
画像バス２６０上には、デバイスＩ／Ｆ２６１、スキャナ画像処理部２６２、プリンタ画像処理部２６３が設けられる。デバイスＩ／Ｆ２６１には、スキャナ２６４及びプリンタ２６５が接続され、デバイスＩ／Ｆ２６１は、画像データの同期系／非同期系の変換を行う。スキャナ画像処理部２６２は、入力画像データに対して、補正、加工、及び編集を行う。プリンタ画像処理部２６３は、プリント出力する画像データに対して、プリンタ２６５に応じた補正または解像度変換などを行う。
【００２６】
＜管理サーバのソフトウェア構成＞
図３（Ａ）は、管理サーバ１０１のソフトウェア構成の一例を示す図である。
管理サーバ１０１では、デバイス管理サービス３００が動作する。デバイス管理サービス３００は、ＮＥＴＣＯＮＦを用いてＭＦＰ１０２のイベントを受信し、受信したイベントに応じた処理を行うことでデバイスを管理するサービスである。
【００２７】
デバイス管理サービス３００は、管理サーバ１０１が有しているＨＤＤ２０４に記憶されているプログラムである。ＣＰＵ２０１は、デバイス管理サービス３００のプログラムをＲＡＭ２０３に読み出して実行することによって、各種機能を実現する。デバイス管理サービス３００は、図４を用いて後述する監視設定テーブル４００及びデバイステーブル４１０を管理する。
【００２８】
デバイス管理サービス３００は、ＵＩ部３０１、制御部３０２、監視設定管理部３０３、デバイス管理部３０４、及び通信部３０５を備える。ＵＩ部３０１は、Ｗｅｂブラウザから、通信部３０５を介して受け取ったページ取得要求などに応じてＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書を作成するソフトウェアモジュールである。制御部３０２は、ＵＩ部３０１や通信部３０５から要求を受け付けて、監視設定管理部３０３やデバイス管理部３０４、通信部３０５に処理を指示するソフトウェアモジュールである。
【００２９】
監視設定管理部３０３は、監視設定テーブル４００に格納される監視設定を管理する。監視設定は、ＭＦＰ１０２で発生するどのイベントをＮＥＴＣＯＮＦで監視するか、及び当該ＮＥＴＣＯＮＦで監視するイベントを受信した場合に通知する通知先等の設定等を含む。デバイス管理部３０４は、デバイステーブル４１０に格納されるデバイス情報を管理する。デバイス情報は、ＭＦＰ１０２のＩＰアドレスなどの情報を含む。通信部３０５は、ＭＦＰ１０２に対してＮＥＴＣＯＮＦによるイベント購読の登録を行ったり、ＭＦＰ１０２から通知されるイベントを受信したりするソフトウェアモジュールである。
【００３０】
＜ＭＦＰのソフトウェア構成＞
図３（Ｂ）は、ＭＦＰ１０２のソフトウェア構成の一例を示す図である。
ＭＦＰ１０２は、ＵＩ部３５１、制御部３５２、通信部３５３、及びイベント管理部３５４を備える。これらの各部の機能は、ＣＰＵ２５１が、ＭＦＰ１０２のＨＤＤ２５６に記憶されているプログラムをＲＡＭ２５２に読み出して実行することによって実現する。
【００３１】
ＵＩ部３５１は、ＭＦＰ１０２のコピー等の各種機能の実行を受け付けるためのＵＩ（ユーザインタフェース）を表示するソフトウェアモジュールである。ＵＩ部３５１は、ＭＦＰ１０２のシャットダウンを受け付けるためのＵＩを表示する。制御部３５２は、ＵＩ部３５１や通信部３５３から要求を受け付けて、各部に処理を指示するソフトウェアモジュールである。また、制御部３５２は、シャットダウンやスリープなどＭＦＰ１０２の状態遷移（状態変更）の判断を行う。状態遷移の判断処理については、図９及び図１０を用いて後述する。
【００３２】
通信部３５３は、ＮＥＴＣＯＮＦによるイベント購読の登録を受け付けたり、ＭＦＰ１０２で発生したイベントの通知を行ったりするソフトウェアモジュールである。イベント管理部３５４は、図４を用いて後述するイベントログテーブル４５０及び通知条件テーブル４６０を管理する。イベント管理部３５４は、イベント受信部３５５、イベント記録部３５６、及びイベント通知部３５７を備えるソフトウェアモジュールである。イベント受信部３５５は、制御部３５２やＭＦＰ１０２のその他のアプリケーションから障害の発生やＭＦＰ１０２の状態遷移等のイベントを受信するソフトウェアモジュールである。
【００３３】
イベント記録部３５６は、イベントログテーブル４５０にイベントの情報を書き込むソフトウェアモジュールである。イベント通知部３５７は、通知条件テーブル４６０に格納される通知条件を管理するソフトウェアモジュールである。イベント通知部３５７は、通知条件テーブルを基に、イベント受信部３５５やイベント記録部３５６から受け取ったイベントを管理サーバ１０１に通知すべきか判断する。
【００３４】
＜テーブル構成＞
図４（Ａ）は、管理サーバ１０１のデバイス管理サービス３００が管理する監視設定テーブルの一例である。
監視設定テーブル４００は、各ＭＦＰ１０２にイベント購読の登録をしている情報、及びイベントを受信した際に通知する通知先を管理するテーブルである。監視設定テーブル４００は、カラム４０１〜カラム４０５で構成される。
【００３５】
１レコードが１つの監視設定を表している。カラム４０１は、デバイスＩＤを表している。デバイスＩＤは、ＭＦＰ１０２を一意に識別するための識別子であり、監視設定の対象のＭＦＰ１０２を表している。カラム４０２は、深刻度であり、どのような障害のイベントを監視対象とするかを表している。例えば、“ｃｒｉｔｉｃａｌ”であればすぐに対処すべき障害のイベントを監視することを表している。
【００３６】
カラム４０３は、イベント購読の状態を表している。例えば、“購読中”であればＭＦＰ１０２とセッションを確立している第１状態であり、ＭＦＰ１０２からのイベント通知を待ち受けていることを表している。“中断中”であれば、ＭＦＰ１０２のシャットダウンやスリープなどの理由でＭＦＰ１０２とのセッションを切断する必要がある第２状態であることを表している。
【００３７】
カラム４０４は、中断日時を表している。中断日時は、監視対象のＭＦＰ１０２のシャットダウンやスリープなどの理由でイベント購読を中断した日時を表している。カラム４０５は、該当するレコードのイベントを管理サーバ１０１が受信した際に通知する通知先を表している。
【００３８】
図４（Ｂ）は、管理サーバ１０１のデバイス管理サービス３００が管理するデバイステーブルの一例である。
デバイステーブル４１０は、デバイス管理サービス３００が管理対象としているＭＦＰ１０２の情報を管理するテーブルである。デバイステーブル４１０は、カラム４１１〜カラム４１３で構成される。
【００３９】
１レコードが１台のＭＦＰ１０２の情報を表している。カラム４１１は、デバイスＩＤを表している。デバイスＩＤは、ＭＦＰ１０２を一意に識別するための識別子である。カラム４１２は、デバイス名を表している。デバイス名は、ＭＦＰ１０２の表示名であり、ＵＩなどに表示するときに使用される。カラム４１３は、ＭＦＰ１０２のＩＰアドレスを表している。
【００４０】
図４（Ｃ）は、ＭＦＰ１０２のイベント管理部３５４が管理するイベントログテーブルの一例である。
イベントログテーブル４５０は、ＭＦＰ１０２で発生したイベントの情報を管理するテーブルである。イベントログテーブル４５０は、カラム４５１〜カラム４５５で構成される。
【００４１】
１レコードが１つのイベントの情報を表している。カラム４５１は、イベントＩＤを表している。イベントＩＤは、イベントを一意に識別するための識別子である。カラム４５２は、イベントの発生日時を表している。カラム４５３は、イベントクラスを表している。イベントクラスは、発生したイベントが障害のイベントなのか、ＭＦＰ１０２の状態遷移のイベントなのかを表している。例えば、“Ｆａｕｌｔ”であれば、障害の発生のイベントであることを表している。
【００４２】
カラム４５４は、発生したイベントが障害のイベントである場合に、障害の深刻度を表している。例えば、“ｃｒｉｔｉｃａｌ”であれば、すぐに対処すべき障害のイベントであることを表している。カラム４５５は、イベントの内容を表している。例えば、“ＴＯＮＥＲ＿ＥＭＰＴＹ”であれば、ＭＦＰ１０２のトナーが切れていることを表している。
【００４３】
図４（Ｄ）は、ＭＦＰ１０２のイベント管理部３５４が管理する通知条件テーブルの一例である。
通知条件テーブル４６０は、イベントの通知条件を管理するテーブルである。通知条件テーブル４６０は、カラム４６１〜カラム４６４で構成される。イベントの通知条件は、デバイス管理サービス３００などからのイベント購読の登録要求により作成される。イベント購読の登録処理については図６を用いて後述する。
【００４４】
１レコードが１つのイベントの通知条件を表している。カラム４６１は、通知条件ＩＤを表している。通知条件ＩＤは、通知条件を一意に識別するための識別子である。カラム４６２は、障害が発生した場合（障害のイベントが発生した場合）に管理サーバ１０１に通知すべき障害の深刻度を表している。例えば、“ｃｒｉｔｉｃａｌ”であれば、発生した障害のイベントの深刻度が“ｃｒｉｔｉｃａｌ”である場合に、管理サーバ１０１に通知することを表している。
【００４５】
カラム４６３は、ＭＦＰ１０２の状態が変更した場合（状態遷移のイベントが発生した場合）に、管理サーバ１０１に通知すべき状態遷移を表している。例えば、“ｓｌｅｅｐ”であれば、ＭＦＰ１０２がスリープ状態に遷移した際に管理サーバ１０１に通知することを表している。カラム４６４は、イベントが発生した際に通知する通知先のＩＰアドレスを表している。
【００４６】
＜デバイス管理サービス３００のＵＩ＞
図５は、デバイス管理サービス３００のＵＩ部３０１が提供するＵＩ（画面）の一例である。
ＵＩ５００は、ユーザのコンピュータのＷｅｂブラウザからデバイス管理サービス３００のＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）にアクセスすることで表示される。ＵＩ５００は、監視設定を行うためのＵＩであり、ボタンやテキストボックスなどのコントロール（５０１〜５０５）で構成される。
【００４７】
コンボボックス５０１は、監視対象とするＭＦＰ１０２を選択するためのコンボボックスである。チェックボックス５０２は、監視する障害の深刻度（重要度）を選択するためのチェックボックスである。テキストボックス５０３は、ＭＦＰ１０２で発生したイベントを受信した際にメールで通知する通知先（メールアドレス）を設定するためのテキストボックスである。ボタン５０４は、コントロール（５０１〜５０３）にて設定した内容を監視設定として登録するためのボタンである。デバイス管理サービス３００がボタン５０４の押下を検知した後の処理については、図６〜図８を用いて説明する。ボタン５０５は、ＵＩ５００上で編集した監視設定を破棄するためのボタンである。
【００４８】
＜イベント通知の処理＞
図６〜図８を用いて、デバイス管理サービス３００が、ＵＩ５００上で監視設定の登録するボタン５０４の押下を検知してから、イベントを通知するまでの処理について説明する。
【００４９】
図６は、デバイス管理サービス３００が、ＵＩ５００のボタン５０４の押下を検知してから、イベントを通知するまでの管理サーバ１０１及びＭＦＰ１０２の処理を示すシーケンス図である。
ステップＳ６０１で、デバイス管理サービス３００の監視設定管理部３０３は、通信部３０５を介して、ＵＩ５００で設定された内容を受信する。監視設定管理部３０３は、受信した内容を監視設定テーブル４００に登録する。ここで、ステップＳ６０１の処理の詳細について、図７を用いて説明する。
【００５０】
図７は、デバイス管理サービス３００の監視設定管理部３０３が監視設定を登録する処理を示すフローチャートである。
ステップＳ７０１で、監視設定管理部３０３は、ＵＩ５００で設定された監視設定の内容を監視設定テーブル４００に登録する。ステップＳ７０２で、監視設定管理部３０３は、ＵＩ５００で設定された監視設定の内容に加えて、シャットダウンへの遷移を示すイベントを監視対象のイベントに追加する。このようにシャットダウンへの遷移を示すイベントを監視対象とすることで、ＭＦＰ１０２の状態がシャットダウンへの遷移を示すイベントを、デバイス管理サービス３００が受信できる。
【００５１】
ステップＳ７０３で、監視設定管理部３０３は、ＵＩ５００で設定された監視設定の内容に加えて、スリープのイベントを監視対象のイベントに追加する。このようにスリープのイベントを監視対象とすることで、ＭＦＰ１０２の状態がスリープ状態への遷移を示すイベントを、デバイス管理サービス３００が受信できる。ステップＳ７０２及びＳ７０３の処理により、デバイス管理サービス３００は、ＭＦＰ１０２がセッションを維持できない状態に遷移したことを知ることができる。
【００５２】
図６の説明に戻る。ステップＳ６０２で、デバイス管理サービス３００の通信部３０５は、ＭＦＰ１０２の通信部３５３を介してイベント管理部３５４とセッションを確立する。セッションの確立は、コネクション指向のセッションを扱えるＳＳＨ（Ｓｅｃｕｒｅ  Ｓｈｅｌｌ）やＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｏｒ  Ｓｅｃｕｒｉｔｙ）等のプロトコルを用いて行われる。
【００５３】
ステップＳ６０３で、デバイス管理サービス３００の監視設定管理部３０３は、通信部３０５を介して、ＭＦＰ１０２にＮＥＴＣＯＮＦのイベント購読の登録を行う。ステップＳ６０３の通信は、ステップＳ６０２で確立したセッションを用いて行う。以下、図８を用いて、ステップＳ６０３の処理で送信するＮＥＴＣＯＮＦのイベント購読登録の内容について説明する。
【００５４】
図８は、デバイス管理サービス３００がＭＦＰ１０２に送信するＮＥＴＣＯＮＦのイベント購読登録の内容の一例を示す図である。
登録内容８００は、ＸＭＬで構成されている。＜ｆｉｌｔｅｒ＞タグ８０１は、ＭＦＰ１０２に通知してほしいイベントが何かを表している。＜ｆｉｌｔｅｒ＞タグ８０１内で指定されたイベントのみがＭＦＰ１０２から通知されることになる。＜ｅｖｅｎｔ＞タグ８０２〜８０４は、ＭＦＰ１０２に通知してほしいイベントの１つ１つを表している。
【００５５】
＜ｅｖｅｎｔ＞タグ８０２は、深刻度が“ｃｒｉｔｉｃａｌ”である障害のイベントを通知してほしいことを示している。＜ｅｖｅｎｔ＞タグ８０３は、シャットダウンへの状態遷移のイベントを通知してほしいことを示している。なお、＜ｅｖｅｎｔ＞タグ８０３の内容は、ステップＳ７０２の処理により追加された内容である。＜ｅｖｅｎｔ＞タグ８０４は、スリープ状態への遷移を示すイベントを通知してほしいことを示している。なお、＜ｅｖｅｎｔ＞タグ８０４の内容は、ステップＳ７０３の処理により追加された内容である。
【００５６】
図６の説明に戻る。ステップＳ６０４で、ＭＦＰ１０２が有するイベント管理部３５４のイベント通知部３５７は、ステップＳ６０３で受信したイベント購読の内容を通知条件として通知条件テーブル４６０に登録する。ステップＳ６０４までの処理でイベント購読の登録が完了する。以降の処理は、ＭＦＰ１０２内でイベントが発生した場合の処理を示す。ＭＦＰ１０２は、イベントが発生すると、ステップＳ６０４までの処理で保存された通知条件を参照して、デバイス管理サービス３００にイベントを通知するか否かを判断する。
【００５７】
以下、ＭＦＰ１０２がイベント通知を行う処理について説明する。ステップＳ６０５で、ＭＦＰ１０２の制御部３５２は、イベントを検知すると、ステップＳ６０６に進む。ステップＳ６０６で、制御部３５２は、発生したイベントをイベント管理部３５４のイベント受信部３５５に送信する。イベント管理部３５４のイベント記録部３５６は、イベント受信部３５５が受信したイベントの内容をイベントログテーブル４５０に登録する。
【００５８】
ステップＳ６０７で、イベント管理部３５４のイベント通知部３５７は、ステップＳ６０６で受信したイベントがデバイス管理サービス３００に通知すべきイベントか否かを判断する。詳細には、イベント通知部３５７は、通知条件テーブル４６０から通知条件を取得し、ステップＳ６０６で受信したイベントと通知条件テーブル４６０の通知条件とを比較し、当該受信したイベントが通知すべきイベントか否かを判断する。
【００５９】
例えば、通知条件ＩＤが“Ｎ００１”の通知条件によると、ステップＳ６０６で受信したイベントが“ｃｒｉｔｉｃａｌ”な障害であるか、またはスリープまたはシャットダウンへの状態遷移である場合、ＭＦＰ１０２はイベントを通知すべきであると判断する。イベント通知部３５７が通知すべきイベントであると判断した場合、処理はステップＳ６０８に進む。
【００６０】
イベント通知部３５７が通知すべきイベントではないと判断した場合、イベント管理部３５４は、次にイベントを受信するまで待機する。ステップＳ６０８で、イベント通知部３５７は、通信部３５３を介して、デバイス管理サービス３００に発生したイベントを通知する。ステップＳ６０９で、デバイス管理サービス３００の監視設定管理部３０３は、監視設定テーブル４００のカラム４０５に登録されている通知先に対して、イベントの内容をメールで通知する。
【００６１】
＜セッションを維持できない状態への遷移＞
次に、ＭＦＰ１０２にてセッションを維持できない状態（第２状態）への遷移を示すイベントが発生した際の処理について図９及び図１０を用いて説明する。
図９は、セッションを維持できない状態への遷移を示すイベントが発生した際のＭＦＰ１０２及び管理サーバ１０１の処理を示すシーケンス図である。
【００６２】
ステップＳ９０１で、ＭＦＰ１０２の制御部３５２は、セッションを維持できない状態への遷移を示すイベントが発生したかを判断する。制御部３５２がセッションを維持できない状態への遷移を示すイベントが発生したと判断した場合、処理はステップＳ９０２に進む。セッションを維持できない状態とは、例えば、シャットダウン（電源ＯＦＦ）やスリープ状態等である。シャットダウンへの状態遷移は、例えば、ＵＩ部３５１がシャットダウン操作を受け付けたか否かで判断できる。以下、図１０を用いて、ステップＳ９０１にて制御部３５２がスリープへの状態遷移を判断する処理について説明する。
【００６３】
図１０は、ＭＦＰ１０２の制御部３５２がスリープへの状態遷移を判断する処理を示すフローチャートである。
ステップＳ１００１で、制御部３５２は、一定時間操作がなされていないかを判断する。一定時間操作がなされていない場合、処理はステップＳ１００２に進む。操作がなされている場合、制御部３５２は、監視を続ける。
【００６４】
ステップＳ１００２で、制御部３５２は、通信部３５３に問い合わせて、確立されているセッションがＮＥＴＣＯＮＦのイベント購読のセッションのみであるかを取得する。セッションがＮＥＴＣＯＮＦのイベント購読のみであった場合、制御部３５２は、スリープへの状態遷移と判断し、処理はステップＳ９０２に進む。セッションがＮＥＴＣＯＮＦのイベント購読のみでない場合、制御部３５２は、ステップＳ１００１に進み、監視を続ける。
【００６５】
ＭＦＰ１０２等は、スリープへ状態遷移が行われるとセッションを維持できない。このため、セッションがある場合は、他の機器との通信を優先してスリープ状態に遷移しないように構成することがある。したがって、本実施形態では、ＮＥＴＣＯＮＦのイベント購読のセッションのみの場合に限り、スリープへ状態遷移を行うように構成した。これにより、ＮＥＴＣＯＮＦのイベント購読を行っていた場合であってもＭＦＰ１０２はスリープ状態に遷移することができる。
【００６６】
図９の説明に戻る。ステップＳ９０２で、制御部３５２は、イベントをイベント管理部３５４のイベント受信部３５５に送信する。イベント管理部３５４のイベント記録部３５６は、イベント受信部３５５が受信したイベントの情報をイベントログテーブル４５０に登録する。ステップＳ９０３で、イベント管理部３５４のイベント通知部３５７は、ステップＳ６０７の処理と同様に、ステップＳ９０２で受信したイベントがデバイス管理サービス３００に通知すべきイベントであるか否かを判断する。
【００６７】
イベント通知部３５７が通知すべきイベントであると判断した場合、処理はステップＳ９０４に進む。なお、図９に示す例では、ステップＳ９０２で受信したイベントがシャットダウンやスリープなどのセッションを維持できない状態への遷移を示すイベントであるとする。そして、ＵＩ５００で設定された監視設定には、ステップＳ７０２及びＳ７０３の処理により必ずシャットダウンとスリープへの状態遷移のイベントがデバイス管理サービス３００に通知されるように登録されている。
【００６８】
そのため、イベント通知部３５７は、シャットダウンやスリープなどのセッションを維持できない状態への遷移を示すイベント（第１通知）を、必ずデバイス管理サービス３００に通知すべきイベントであると判断する。なお、本実施形態では、デバイス管理サービス３００がステップＳ７０２及びＳ７０３の処理にて必ずシャットダウンとスリープへの状態遷移のイベントを通知するように登録しているが、この方法に限られるものではない。例えば、ＭＦＰ１０２のイベント管理部３５４が、ステップＳ６０３で受信したイベント購読の内容をステップＳ６０４で通知条件として保存する際に、シャットダウンやスリープも通知するイベントとして追加するように構成してもよい。
【００６９】
ステップＳ９０４で、イベント管理部３５４のイベント通知部３５７は、通信部３５３を介して、デバイス管理サービス３００に発生したイベントを通知する。すなわち、管理サーバ１０１は、ＭＦＰ１０２から、該ＭＦＰ１０２と管理サーバ１０１との間のイベント通知のためのセッションを確立している第１状態から該セッションを切断する必要がある第２状態に遷移することを示す第１通知を受信する。
【００７０】
ステップＳ９０５で、デバイス管理サービス３００の監視設定管理部３０３は、ステップＳ９０４で受信したイベントがセッションを維持できない状態への遷移を示すイベントであるため、監視設定テーブル４００のカラム４０４に現在の日時を登録する。これによりイベント購読を中断した日時を記録することができる。
【００７１】
ステップＳ９０６で、デバイス管理サービス３００の通信部３０５は、ＭＦＰ１０２の通信部３５３を介してイベント管理部３５４とのセッションの切断を行う。なお、本実施形態では、管理サーバ１０１のデバイス管理サービス３００がＭＦＰ１０２とのセッションの切断を行ったが、ＭＦＰ１０２のイベント管理部３５４が通信部３５３を介してセッションの切断を行うように構成してもよい。ステップＳ９０７で、ＭＦＰ１０２の制御部３５２は、ステップＳ９０１で発生したと判断したイベント、すなわちシャットダウンやスリープなどのセッションを維持できない状態への遷移を実行する。
【００７２】
＜セッションを確立できる状態への復帰＞
次に、ＭＦＰ１０２にてセッションを確立できる状態への復帰のイベントが発生した際の処理について図１１及び図１２を用いて説明する。
図１１は、セッションを確立できる状態（第１状態）への復帰のイベントが発生した際のＭＦＰ１０２及び管理サーバ１０１の処理を示すシーケンス図である。
【００７３】
ステップＳ１１０１で、ＭＦＰ１０２の制御部３５２は、セッションを確立できる状態への復帰のイベントが発生したか否かを判断する。制御部がセッションを確立できる状態への復帰のイベントが発生したと判断した場合、処理はステップＳ１１０２に進む。例えば、シャットダウンの状態であれば電源投入、スリープ状態であればＵＩ部３５１が操作されたことにより、制御部３５２は、セッションを確立できる第１状態へ復帰するイベントが発生したと判断する。
【００７４】
ステップＳ１１０２で、制御部３５２は、イベントをイベント管理部３５４のイベント受信部３５５に送信する。イベント管理部３５４のイベント記録部３５６は、イベント受信部３５５が受信したイベントの情報をイベントログテーブル４５０に登録する。ステップＳ１１０３で、イベント管理部３５４のイベント通知部３５７は、通信部３５３を介して、デバイス管理サービス３００に復帰通知を行う。
【００７５】
すなわち、管理サーバ１０１は、ＭＦＰ１０２から、該ＭＦＰ１０２との間のイベント通知のためのセッションを切断する必要がある第２状態から該セッションを確立している第１状態に復帰することができる状態に遷移することを示す第２通知を受信する。なお、ステップＳ１１０３を実行する際には、ＭＦＰ１０２は、デバイス管理サービス３００とセッションを確立していないため、復帰通知は、ＳＮＭＰのｔｒａｐやｉｎｆｏｒｍＲｅｑｕｅｓｔを用いて行われる。
【００７６】
ステップＳ１１０４で、デバイス管理サービス３００の監視設定管理部３０３は、ステップＳ１１０３で復帰通知を送信したＭＦＰ１０２に対する監視設定が中断されているかを確認する。監視設定が中断されている場合、デバイス管理サービス３００は、イベント購読の再開を行うため、ステップＳ１１０５に進む。監視設定が中断されていない場合、デバイス管理サービス３００は、ステップＳ１１０５以降の処理を行わない。ステップＳ１１０５で、デバイス管理サービス３００の通信部３０５は、ＭＦＰ１０２の通信部３５３を介してＭＦＰ１０２のイベント管理部３５４とセッションを確立する。
【００７７】
ステップＳ１１０６で、デバイス管理サービス３００の監視設定管理部３０３は、通信部３０５を介して、ＭＦＰ１０２にＮＥＴＣＯＮＦのイベント購読の再登録を行う。ステップＳ１１０６の通信は、ステップＳ１１０５で確立したセッションを用いて行う。ＭＦＰ１０２のイベント管理部３５４は、ステップＳ１１０６で受信したイベント購読の内容を通知条件として通知条件テーブル４６０に登録する。
【００７８】
図１２は、デバイス管理サービス３００がＭＦＰ１０２に送信するＮＥＴＣＯＮＦのイベント購読登録の内容の一例を示す図である。
なお、図１２に示す例は、ステップＳ６０３で登録したイベント購読（図８）をＭＦＰ１０２に再登録（再開）する場合の例を示す。ここでは、図８で説明したイベント購読の内容との差分についてのみ説明する。
【００７９】
登録内容１２００と登録内容８００（図８）との差分は、登録内容１２００に＜ｓｔａｒｔＴｉｍｅ＞タグ１２０１が追加されている点である。＜ｓｔａｒｔＴｉｍｅ＞タグ１２０１は、いつから発生したイベントを購読するかを示すタグである。＜ｓｔａｒｔＴｉｍｅ＞タグ１２０１で設定されている時間は、イベント購読を中断した日時であり、監視設定テーブル４００のカラム４０４に格納されている情報である。
【００８０】
すなわち、デバイス管理サービス３００は、通知条件テーブル４６０の通知条件に合致するイベントのなかで通知対象を決定するために利用される時間情報として、カラム４０４に格納されている、イベント購読を中断した日時を設定する。これにより、イベント購読を中断した日時以降にＭＦＰ１０２にて発生したイベントを購読できる。
【００８１】
なお、本実施形態では、＜ｓｔａｒｔＴｉｍｅ＞タグ１２０１にイベント購読を中断した日時を設定したが、これに限られるものではない。例えば、イベント購読を中断した時刻から、復帰通知を受信する前の時刻までの間の時間を設定してもよい。
【００８２】
図１１の説明に戻る。ステップＳ１１０７で、ＭＦＰ１０２が有するイベント管理部３５４のイベント通知部３５７は、イベント記録部３５６を介して、＜ｓｔａｒｔＴｉｍｅ＞タグ１２０１で指定されている日時以降に発生したイベントをすべて取得する。ステップＳ１１０８で、イベント管理部３５４のイベント通知部３５７は、ステップＳ６０７の処理と同様に、ステップＳ１１０７で取得したイベントと通知条件テーブル４６０の通知条件とを比較し、取得したイベントが通知すべきイベントか否かを判断する。
【００８３】
イベント通知部３５７が通知すべきイベントであると判断した場合、処理はステップＳ１１０９に進む。イベント通知部３５７が通知すべきイベントではないと判断した場合、イベント管理部３５４は、次にイベントを受信するまで待機する。ステップＳ１１０９で、イベント通知部３５７は、通信部３５３を介して、デバイス管理サービス３００に発生したイベントを通知する。
【００８４】
ステップＳ１１１０で、デバイス管理サービス３００の監視設定管理部３０３は、ステップＳ６０９の処理と同様に、監視設定テーブル４００のカラム４０５に登録されている通知先に対して、イベントの内容をメールで通知する。このように、イベント購読の再開時には、イベント購読を中断した日時以降のイベントを通知するように構成することで、デバイス管理サービス３００は、漏れなくイベントを管理することができる。
【００８５】
＜予期せぬセッション切断時の処理＞
上述したように、本実施形態では、シャットダウンやスリープ等の通常のセッションを維持できない状態への遷移においては、ＭＦＰ１０２から管理サーバ１０１のデバイス管理サービス３００にイベントが通知される。これに対して、以下では、ＭＦＰ１０２のコンセントが抜けてしまった場合など、予期しない理由でセッションが切断されてしまった場合に、デバイス管理サービス３００が行う処理について説明する。
【００８６】
図１３は、予期しない理由でセッションが切断されてしまった場合に、管理サーバ１０１のデバイス管理サービス３００が実行する処理を示すフローチャートである。
ステップＳ１３０１で、デバイス管理サービス３００の通信部３０５は、セッションが切断されたかを監視する。セッションが切断された場合、処理はステップＳ１３０２に進む。セッションが切断されていない場合、通信部３０５は、監視を続ける。
【００８７】
ステップＳ１３０２で、デバイス管理サービス３００の監視設定管理部３０３は、ステップＳ１３０１でセッションが切断されたＭＦＰ１０２の監視設定が中断中であるかを判断する。監視設定が中断中でない場合、処理はステップＳ１３０３に進む。監視設定が中断中である場合、スリープやシャットダウンなどのイベントをＭＦＰ１０２から受信したことにより監視を中断したと判断し、図１３の処理を終了する。
【００８８】
ステップＳ１３０３で、監視設定管理部３０３は、ステップＳ１３０１でセッションが切断されたＭＦＰ１０２の監視設定を中断中とする。具体的には、監視設定管理部３０３は、監視設定テーブル４００のカラム４０４（中断日時）に現在の日時を登録する。ステップＳ１３０４で、デバイス管理サービス３００の制御部３０２は、通信部３０５を介してＭＦＰ１０２から状態を取得する。
【００８９】
ステップＳ１３０５で、制御部３０２は、取得したＭＦＰ１０２の状態がセッションを確立できる状態であるかを判断する。制御部３０２が、ＭＦＰ１０２はセッションを確立できる状態であると判断した場合、処理はステップＳ１３０６に進む。制御部３０２が、ＭＦＰ１０２はセッションを確立できる状態ではないと判断した場合、またはステップＳ１３０４においてＭＦＰ１０２の状態を取得できなかった場合、処理はステップＳ１３０４に戻る。
【００９０】
ステップＳ１３０４及びＳ１３０５では、制御部３０２がＭＦＰ１０２の状態をポーリングする。これにより、デバイス管理サービス３００は、ＭＦＰ１０２がセッションを確立できる状態に復帰したか否かを判断する。ＭＦＰ１０２がスリープ状態の場合に、デバイス管理サービス３００がＭＦＰ１０２の状態を取得すると、ＭＦＰ１０２はスリープ状態から復帰する。しかし、本実施形態では、スリープへの状態遷移の際に、デバイス管理サービス３００は、ＭＦＰ１０２からイベントを受信する構成になっている。
【００９１】
このため、ＭＦＰ１０２がスリープ状態では、ステップ１３０４及びＳ１３０５の処理は行われない。したがって、イベント購読を行うためだけにＭＦＰ１０２をスリープ状態から不要に復帰させることがないため、ＭＦＰ１０２の省電力を保つことができる。ステップＳ１３０６で、デバイス管理サービス３００の通信部３０５は、ステップＳ１１０５の処理と同様に、ＭＦＰ１０２のイベント管理部３５４とセッションを確立する。
【００９２】
ステップＳ１３０７で、デバイス管理サービス３００の監視設定管理部３０３は、ステップＳ１１０６の処理と同様に、通信部３０５を介して、ＭＦＰ１０２にＮＥＴＣＯＮＦのイベント購読の登録を行う。ここで、イベント購読の登録が行われたため、以降はＭＦＰ１０２でイベントが発生した場合には、管理サーバ１０１のデバイス管理サービス３００にイベントが通知される。
【００９３】
以上のように、本実施形態によれば、管理装置は、ＭＦＰ１０２等のネットワークデバイスが管理装置との間のセッションを中断する必要がある状態へ遷移した場合であっても、ネットワークデバイスにおいて発生したイベントを漏れなく管理することができる。
【００９４】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００９５】
以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形及び変更が可能である。
【図１】
2018061142.tif 000003
【図２】
2018061142.tif 000004
【図３】
2018061142.tif 000005
【図４】
2018061142.tif 000006
【図５】
2018061142.tif 000007
【図６】
2018061142.tif 000008
【図７】
2018061142.tif 000009
【図８】
2018061142.tif 000010
【図９】
2018061142.tif 000011
【図１０】
2018061142.tif 000012
【図１１】
2018061142.tif 000013
【図１２】
2018061142.tif 000014
【図１３】
2018061142.tif 000015