JP2013152706A - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】省メモリでの機能実装を可能とし、将来の拡張や展開に耐えることができる情報処理装置、情報処理方法、及びプログラムを提供する。
【解決手段】管理装置により遠隔管理される情報処理装置において、内部で発生したイベントを受信するイベント受信部と、イベントに対応したイベント処理部への振り分けを決定する処理分配部と、処理分配部により生成した、管理装置に送信するメッセージを生成する複数のイベント処理部と、を備えた。
【選択図】図１

Description

本発明は、情報処理装置、情報処理方法、及びプログラムに関する。

多機能周辺装置ＭＦＰ(Multifunction Peripheral)による遠隔機器管理システムは既に知られている。

しかし、今までは、システムとしてのデバイスの遠隔管理の方法やより良い管理方法などに対する解決は考えられてきているが、デバイス側の省メモリや開発時の拡張性といった点は考慮されていなかったため、今後、様々なデバイスで同様の仕組みを展開していく場合には問題があった。

そこで、種々の提案がなされている（例えば、特許文献１〜３参照。）。特許文献１に記載の発明は、「通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム」に関する発明であり、具体的には「画像形成装置は、トナーニアエンド（異常事前事象）の発生によりそのトナーニアエンドを検出したとき、そのトナーニアエンド（トナーボトルの発注）を知らせるトナーサプライコール情報（事前事象情報）を管理装置へ送信するが、その際にトナーサプライコール情報の送信実行中を示すサプライコール実行中フラグを"１"にセットする。その後、管理装置からトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信したとき、そのトナーサプライコール情報の送信が成功したと判断し、サプライコール実行中フラグを"０"にリセットする」ものである。

特許文献２に記載の発明は、「通信装置とその遠隔管理システムおよび異常発生時の制御方法並びにプログラム」に関する発明であり、具体的には「被管理装置（通信装置）が、ＳＣ（異常）を検出した場合、ＮＶ−ＲＡＭ（不揮発性記憶手段）内のＳＣコール中フラグを"１"にセットし、ＳＣを知らせるＳＣコール情報を管理装置へ送信するが、その送信処理中に主電源がＯＦＦ／ＯＮされた（装置全体への給電が一旦停止された後再開された）とき、ＮＶ−ＲＡＭ内のＳＣコール中フラグが"１"にセットされていることを認識できた場合に、ＳＣコール情報を管理装置へ再送信する。」ものである。

特許文献３に記載の発明は、「緊急通報受信装置及び緊急通報受信方法」に関する発明であり、具体的には「ダイヤル信号の送出により回線接続が行われる公衆回線を通信回線として使用し、通信回線から供給される発信電話番号情報を受信し、発信電話番号情報を検索キーとして、自装置に予め登録されている発信者に関する情報を検索し、また、通信回線から供給される着電話番号情報を受信し、着電話番号情報を検索キーとして、自装置に予め登録されている着電話番号対応の通報種別を検索し、呼出信号の受信前に、発信者の通報種別及び発信者宅の緊急通報端末機の機種を判定し、通報種別及び緊急通報端末機の機種に対応した通報受信動作を行い、また、発信者に関する情報を表示する」ものである。

特許文献１、２に記載の発明では、機器内部で発生したトナーニアエンドや機器異常といったセンターへ送信するべきイベントが発生したが、途中で電源断等で送信処理が中断された場合、再送処理を出来るような方法が開示されている。この他にも、同様の技術は多数提案されているが、主にセンターとデバイスとの間の通信やデバイス管理方法が多く、様々なデバイスに同じ仕組みを展開しようとした場合、メモリ消費が多くそのままでは適用できなかったり、新たな機器の拡張には耐え切れなかったりするといった問題があった。また、特許文献３に記載の発明は、緊急通報システムとしての技術ではあるが、発信／着信電話番号をキーとしたシステム構築の例となっており、上記課題には関係していない。

そこで、本発明の目的は、省メモリでの機能実装を可能とし、将来の拡張や展開に耐えることができる情報処理装置、情報処理方法、及びプログラムを提供することにある。

上記課題を解決するため、本発明は、管理装置により遠隔管理される情報処理装置において、内部で発生したイベントを受信するイベント受信部と、イベントに対応したイベント処理部への振り分けを決定する処理分配部と、前記処理分配部により生成した、前記管理装置に送信するメッセージを生成する複数のイベント処理部と、を備えたことを特徴とする。

本発明によれば、省メモリでの機能実装を可能とし、将来の拡張や展開に耐えることができる情報処理装置、情報処理方法、及びプログラムの提供を実現できる。

第１の実施形態に係る情報処理装置を用いた遠隔管理システム全体のソフトウェア構成について説明するための説明図である。 図１に示したイベント受信部１０４と、イベント処理部１０５の詳細について説明する説明図である。 図２で説明した構成におけるエラー発生時のシーケンスについて説明する図である。 イベント受信部の状態遷移について説明するための説明図である。 具体的な状態遷移について説明するための説明図である。 図５で説明した状態を起動時に作成するための初期化処理のシーケンス図の一例である。 設置処理を行った際のシーケンスについて説明するための説明図である。 第２の実施形態に係る情報処理装置を用いた遠隔管理システム全体のソフトウェア構成について説明するための説明図である。 第２の実施形態におけるエラー発生時のシーケンスについて説明する図である。

ここで、本願発明は、プロジェクタ、会議システム等のデバイスを管理システムの対象になる可能性があり、これから作るデバイスの開発効率を考慮した。また、管理対象が増加していく場合、今まで通知しなくても良かったものを通知しなければならなくなったり、拡張が考えられるので、拡張性を重視して作った。将来新しく管理対象に入っても、通知しなければならなくなってもすぐに対応できる。

（第１の実施形態）
図１は、第１の実施形態に係る情報処理装置を用いた遠隔管理システム全体のソフトウェア構成について説明するための説明図である。
同図に示すシステムは、情報処理装置としてのプロジェクタ（情報処理装置１０１）と、情報処理装置１０１を遠隔管理する管理装置としてのセンターシステム１１０とを有する。
情報処理装置１０１は、ユーザ操作制御部１０２、機器内状態監視部１０３、イベント受信部１０４、イベント処理部１０５、処理分配部１０６、データ管理部１０７、機器状態管理部１０８、及び通信部１０９で構成されている。
センターシステム１１０は、例えばサーバで構成されている。

遠隔機器管理システムの構成は、管理対象デバイスとなる情報処理装置（プロジェクタ）１０１からセンターシステム１１０に向けてメッセージを送信する（または逆に受けることもある）ことである。この構成によりセンターシステム１１０が数多くの機器の情報を管理し、実現している。

本実施形態は、図１における左側の情報処理装置１０１の内部の設計構成がポイントとなる。

遠隔管理システムにおいて、管理対象デバイスとなる情報処理装置１０１からセンターシステム１１０に向けてメッセージを送信する処理は、主にユーザ操作制御部１０２または機器内状態監視部１０３にて発生するイベントをトリガとして動作する。ユーザ操作制御部１０２による主なイベントとしては、「登録処理」や「通信テストコール実行」等が挙げられる。同様に、機器内状態監視部１０３の主なイベントとしては、「エラー発生通知」等が挙げられる。

ユーザ操作制御部１０２や機器内状態監視部１０３から発生したイベントは、イベント受信部１０４に届く。その後、実際にセンターシステム１１０に向けて通知されるメッセージを作成するために、イベント処理部１０５に処理が渡される。基本的にデバイス内部で必要な機器情報や機器状態が収集され、収集されたデータがメッセージの形式にまとめられ、当該メッセージがセンターシステム１１０に転送される。このため、イベント処理部１０５はデータ管理部１０７と機器状態管理部１０８といった機器情報や状態を取得できる部分を利用する形で設計されている。イベント処理部１０５は、実際にネットワーク越しにメッセージを通知するためには通信部１０９を利用する。これが、管理対象デバイスとなる情報処理装置１０１からセンターシステム１１０にメッセージを送信する場合の基本的な処理の流れとなる。

図２は、図１に示したイベント受信部１０４と、イベント処理部１０５の詳細について説明する説明図である。
図１で説明したように、管理対象デバイスとなる情報処理装置１０１からセンターシステム１１０に対してメッセージを送信する処理では、機器内部のイベントをトリガとして、そのイベントに対応付けられた実際にやり取りするメッセージが、機器内部から情報や状態を収集して構築され、実際に送信される。

図２ではイベント等の処理詳細について説明する。
基本的な処理の流れは、どのようなイベントが発生しても同様であるが、作成するメッセージの種類は異なっている。そのため、実際にはイベント処理部１０５を処理内容別に詳細化している（例えば、「手動コール処理部」）。これらの処理部群はイベント受信部１０４から見ると、全て同じイベント処理部１０５として見えるように設計されている。処理部群は、基本部分をイベント処理部１０５として共通化した上で、各個別の処理部はイベント処理部１０５の拡張という扱いとなる。そのため、共通化された分の省メモリの実現と、今後新たな「○○処理部」が追加されても、イベント受信部１０４や既存のイベント処理部１０５には影響を与えずに拡張が可能となっている。

また、機器でのイベント発生時に、対応した処理部に分配するのは、処理分配部１０６が行っている。イベント受信部１０４は、イベントを受けると処理分配部１０６にイベントを渡す。処理分配部１０６は、機器内での発生イベントと対応するイベント処理部１０５とのマップを持っている。処理分配部１０６は、このマップを参照して、発生したイベントに対応した処理部を決定して渡す。これにより、イベント受信部１０４は、イベント処理部１０５の詳細な種類を意識することなく、処理実行を行うことが出来る構成となっている（シーケンスは次に示す）。

図３は、図２で説明した構成におけるエラー発生時のシーケンスについて説明する図である。図３は、機器内部でエラー発生通知が発行された場合のシーケンス図の一例を示している。
機器内状態監視部１０３よりエラー発生通知（Ｓ３０１）を受けたイベント受信部１０４は、処理分配部１０６に処理分配依頼を行う。この際、エラー発生通知のイベントを渡す（Ｓ３０２）。
処理分配部１０６は、イベントと処理部のマップとを確認し、エラー発生通知に対応する機器イベント処理部２０３を生成して、イベント受信部１０４に渡す（Ｓ３０４）。
イベント受信部１０４は、処理分配部１０６から返された機器イベント処理部２０３に対して処理実行を要求する。この際にも、イベント（エラー発生通知）を渡す（Ｓ３０５）。

処理実行を受けた機器イベント処理部（イベント受信部１０４は機器イベント処理部２０３として認識している）２０３は、データ管理部１０７からエラー通報に必要なエラー通報情報を取得し（Ｓ３０６）、機器状態管理部１０８から通信状態を取得したあと（Ｓ３０８）、メッセージを構築（生成）し（Ｓ３１０）、通信部１０９を経由して機器外にメッセージを送信する（ここでいうメッセージとは、「エラー発生メッセージ」となる。）。

機器イベント処理部２０３から通信部１０９にメッセージが送信されると（Ｓ３１１）、通信部１０９はメッセージをセンターシステム１１０に送信すると共に（Ｓ３１２）、機器イベント処理部２０３に応答する（Ｓ３１３）。機器イベント処理部２０３は、イベント処理部１０５に処理完了通知を送り（Ｓ３１４）、イベント受信部１０４は機器内状態監視部１０３に応答する（Ｓ３１５）。

尚、点線内の処理である、エラー通報情報取得（Ｓ３０６、Ｓ３０７）、通信状態取得（Ｓ３０８、Ｓ３０９）、メッセージ生成（Ｓ３１０）は処理毎に変わる。

ここで、最初のイベントトリガが、ユーザ操作制御部１０２（図１参照）からのイベントになったとしても、基本的な流れは変わらず、機器イベント処理部２０３の内部での「データ管理からの情報取得」と、「機器状態管理からの状態取得」と、「メッセージの生成」とがそれぞれの処理内容に合わせて変化するのみとなる。
このため、新しい処理部を追加する必要が生じたとしても、処理分配部１０６での機器内部イベントと処理部のマップの追加と、新しい処理部を作成するのみで既存部分への影響を少なくすることが出来る。
表１は、具体的な図２で説明した構成のイベントと処理部との対応表（対応情報）の一例である。

表１は、処理分配部１０６が参照しているイベントと処理生成部との対応関係を示す表である。ユーザからの実行要求のみ、大項目と小項目に分かれているため、ユーザからの実行要求のみ、小項目の内容で生成対象となる機器イベント処理部２０３が決定する。
また、エラー発生通知に関するシーケンスは図３、起動完了通知に関するシーケンスは図６、ユーザからの実行要求：照会実施／登録実施に関するシーケンスを図７で説明している。

図４は、イベント受信部の状態遷移について説明するための説明図である。
図４において、イベント処理部１０５での処理をより局所化（高効率化）するため、図１に示した構成でイベント受信部１０４において機器内の状態を管理するようにし、機器の状態が、遠隔機器管理システムが有効ではないような状態（イベント処理部１０５が動作する必要の無い状態）である場合に、イベント処理部１０５に対する処理実行要求を呼ばないような処理を加えている。上記を実現すると、イベント処理部１０５の拡張である各処理部は、実装する際に、自身のメッセージの作成のみを考慮すればよい構成となる（データ管理／機器状態管理からの情報取得と、メッセージ作成、通信部への送信要求のみとなる）。

次にどのように状態管理をしているかを、表２及び図５を参照して述べる。
表２及び図５は、具体的な状態遷移について説明するための表及び説明図である。

図５に示すように状態は「初期化状態」、「設置状態」、「通信許可状態」、及び「証明書状態」の４種類の小状態で構成されており、それぞれの組み合わせで４パターンの状態を作っている。それぞれ、実行できる機能の種類が変わる。

まず、「４.遠隔機器管理システム初期化中」（Ｓ５０１）から開始され、「３.遠隔機器管理システム初期化完了」（Ｓ５０２）→「２.遠隔機器管理システム正常利用可能、設置前」（Ｓ５０３）→「１.遠隔機器管理システム正常利用可能」（Ｓ５０４）と状態が変わるにつれて、実行できる機能が増えていく。

最初の「４.」では、実行できる機能は無く、次の「３.」で外部と通信しない機能が利用できる。「２.」となってはじめて、設置／登録のみ実行できる。「２.」の状態は、基本的に全て状態は正常だが、設置状態が「未設置」となっており、これは機器が遠隔機器管理システムの監視対象デバイスとして登録されていない状態を示す。よって、照会／登録処理を行うことで「設置済み」状態となり、「1.遠隔機器管理システム正常利用可能」の状態に遷移することで全機能が利用可能となる。照会登録処理のシーケンスは、図７で示す。

その他の初期状態は、基本的に初期化処理中に決定する（Ｓ５０１）。初期化処理が完了すると「３.」の状態に遷移するが（Ｓ５０２）、初期化処理中に取得した状態が「証明書状態：正常」でかつ「通信許可状態：許可する」であれば状態「２.」になり（Ｓ５０３）、更に加えて、「設置状態：設置済み」であれば「１.」の状態に遷移する（Ｓ５０４）。この初期化処理のシーケンスは図６に示す。

図６は、具体的な図２で説明した構成のシーケンスについて説明するための説明図である。
図６は、図５で説明した状態を起動時に作成するための初期化処理のシーケンス図の一例である。
機器内状態監視部１０３がイベント受信部１０４に起動完了を通知すると（Ｓ６０１）、イベント受信部１０４は、処理分配部１０６に処理分配依頼（起動完了通知）を送る（Ｓ６０２）。処理分配部１０６は、表１を参照して初期化処理部２０４を生成すると共にイベント受信部１０４に応答することになる（Ｓ６０３、Ｓ６０４）。
イベント受信部１０４は、初期化処理部２０４に処理実行（起動完了通知）を行うと（Ｓ６０５）、初期化処理部２０４は機器状態管理部１０８に証明書状態確認を行う（Ｓ６０６、Ｓ６０７）。
初期化処理部２０４は、証明書状態（正常）通知をイベント受信部１０４に送り（Ｓ６０８）、データ管理部１０７に設置状態確認を行い（Ｓ６０９、Ｓ６１０）、イベント受信部に設置状態（設置済み）通知を行う（ステップＳ６１１）。
また、初期化処理部２０４は、データ管理部１０７に通信設定確認を行い（Ｓ６１２）、イベント受信部１０４に通信許可状態（許可する）通知を行い（Ｓ６１４）、初期化完了通知を行う（Ｓ６１５）。

初期化処理部２０４は、メッセージ生成（起動完了通知）を行い（Ｓ６１６）、通信部１０９にメッセージを送信する（Ｓ６１７）。通信部１０９は、センターシステム１１０にメッセージを送信し（Ｓ６１８）、初期化処理部２０４に応答する（Ｓ６１９）。
初期化処理部２０４は、イベント受信部１０４に処理完了通知を行う（Ｓ６２０）。イベント受信部１０４は、機器内状態監視部１０３に応答する（Ｓ６２１）。

すなわち、遠隔機器管理システムの処理は、機器の通信機能などを利用する。このため、プロジェクタ（機器）として起動が完了した時点で初めて初期化処理が実行される設計となっている（起動完了通知のイベントを受けて初めて処理が実行される）。この処理が完了することで、初期化状態が初期化完了に移行し、「３.遠隔機器管理システム初期化完了」状態に遷移する。そして、初期化処理中に行われている「証明書状態」、「設置状態」、「通信状態」の確認結果に基づいて、「２.遠隔機器管理システム正常利用可能、設置前」または「１.遠隔機器管理システム正常利用可能」への遷移が行われる。
また、プロジェクタには時計が存在しないため、初期化処理直後の起動完了通知により、一度ネットワーク経由でセンターシステムと通信完了した時点でサーバ側との時刻同期を完了させる。

図７は、設置処理を行った際のシーケンスについて説明するための説明図である。
図７は、設置処理のシーケンスであるが、遠隔機器管理システムにおける「設置処理」とは、ユーザ操作制御部１０２からの要求で「照会実施」と「登録実施」（表１のイベント小項目参照）が行われ、それぞれ成功することで「設置済み」状態となることを意味する。
この設置処理を行うのが、設置処理部２０２ａ、２０２ｂである。

まず、ユーザ操作制御部１０２から「照会実施」の要求がイベント受信部１０４に届き（Ｓ７０１）、イベント受信部１０４は処理分配部１０６に照会実施のイベントを渡す（Ｓ７０２）。
処理分配部１０６は、表１のマップを参照し、設置処理部２０２ａを生成し（Ｓ７０３）、イベント受信部１０４に渡す。イベント受信部１０４は、設置処理部２０２に対して処理実行を要求する（Ｓ７０４）。ここまでが照会実施の流れである。
設置処理部２０２ａから機器状態管理部１０８に照会状態確認が行われ（Ｓ７０５、Ｓ７０６）、メッセージが生成され（照会実施：Ｓ７０７）、通信部１０９にメッセージが送信される（Ｓ７０８）。

通信部１０９は、メッセージをセンターシステム１１０に送信し（Ｓ７０９）、設置処理部２０２ａに応答する（Ｓ７１０）。
設置処理部２０２ａは、処理完了通知をイベント受信部１０４に送る（Ｓ７１１）。イベント受信部１０４はユーザ操作制御部１０２に応答する（Ｓ７１２）。
処理完了後に同様にユーザ操作制御部１０２から「登録実施」の要求が来る（Ｓ７１２、Ｓ７１３）。

ユーザ操作制御部１０２からイベント受信部１０４に登録実施の要求が来ると（Ｓ７１３）、イベント受信部１０４は処理分配部１０６に処理分配依頼（照会実施）を行う（Ｓ７１４）。処理分配部１０６は、設置処理部２０２ｂを生成する（Ｓ７１５）。
イベント受信部１０４から設置処理部２０２ｂに処理実行（登録実施）が要求されると（Ｓ７１６）、設置処理部２０２ｂは、機器状態管理部１０８に登録状態確認を行う（Ｓ７１７）。設置処理部２０２ｂは、データ管理部１０７からバージョン情報を取得し（Ｓ７１８、Ｓ７１９）、メッセージを生成する（監視登録実施：Ｓ７１９）。設置処理部２０２ｂは、通信部１０９にメッセージを送信する（Ｓ７２０）。通信部１０９は、メッセージをセンターシステム１１０に送信する（Ｓ７２０）。通信部１０９は設置処理部２０２ｂに応答する（Ｓ７２２）。
設置処理部２０２ｂは、メッセージを生成し（お客様番号問い合わせ実施：Ｓ７２３）、メッセージを通信部１０９に送信する。通信部１０９は、設置処理部２０２ｂに応答する（Ｓ７２６）。
設置処理部２０２ｂは、データ管理部１０７にモデル名を取得し（Ｓ７２７、Ｓ７２８）、メッセージを通信部１０９に送信する（Ｓ７３０）。通信部１０９は設置処理部２０２ｂに応答する（Ｓ７３２）。
設置処理部２０２ｂは、イベント受信部１０４に処理完了通知を行う（Ｓ７３３）。

このケースでも流れは同様であるが、センターシステムとやり取りするメッセージが３回ある点のみが変わっている。
ここまで、図２ではエラー発生時、図６で初期化処理、図７で設置処理のそれぞれシーケンス図を示してきた。各処理部の詳細シーケンスは異なるが、「処理部の詳細に入るまでの処理の流れ」と、「処理部のやり取りする相手先（「データ管理」／「機器状態管理」／「通信部」）」は全て共通化されていることが分かる。

これは、処理が共通化できていることと、それぞれの処理部がセンターシステム１１０とやり取りするメッセージを作成し送信するという変動部に分けられていることを意味している。これにより、共通化による省メモリでの遠隔機器管理システムの実現と、将来の拡張に容易に対応することが可能になる。

＜プログラム＞
以上で説明した本実施形態にかかる情報処理装置は、コンピュータで処理を実行させるプログラムによって実現されている。コンピュータとしては、例えばパーソナルコンピュータやワークステーションなどの汎用的なものが挙げられるが、本発明はこれに限定されるものではない。よって、一例として、プログラムにより本発明を実現する場合の説明を以下で行う。

例えば、管理装置により遠隔管理される情報処理装置のコンピュータに、ユーザ操作制御部が、ユーザの操作によりイベントを発生する手順、機器内状態監視部が、イベントを発生する手順、イベント受信部が、内部で発生したイベントを受信する手順、処理分配部が、イベントに対応したイベント処理部への振り分けを決定する手順、イベント処理部が、処理分配部により生成した、管理装置に送信するメッセージを生成する手順、通信部が、メッセージを管理装置に送信する手順、を実行させるプログラムが挙げられる。

これにより、プログラムが実行可能なコンピュータ環境さえあれば、どこにおいても本発明にかかる情報処理装置を実現することができる。このようなプログラムは、コンピュータに読み取り可能な記憶媒体に記憶されていてもよい。

＜記憶媒体＞
ここで、記憶媒体としては、例えば、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（CD Recordable）などのコンピュータで読み取り可能な記憶媒体、フラッシュメモリ、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＦｅＲＡＭ（強誘電体メモリ）等の半導体メモリやＨＤＤ（HardDisc Drive）が挙げられる。

＜作用効果＞
本実施形態によれば、遠隔機器管理システムの監視対象デバイスにおいて、ユーザ操作制御部と機器内状態監視部からのイベントを元に処理する際に、共通化されたイベント受信部を持つことにより、共通化による省メモリ構成を実現することができる。

本実施形態によれば、上記構成に加え、データ管理や機器状態管理、通信部を用いる構成で、それらを利用して処理する部分としてイベント処理部を共通部として用意し、各処理に応じた独自部分を拡張として用意する構成をとることにより、共通化による省メモリと共通／変動部の分割による拡張性の向上を図ることができる。

本実施形態によれば、上記構成に加え、機器内で発生するイベントとセンターシステムとやり取りするべきメッセージ（処理内容）をマップしたデータを持ち、イベントから各処理部を生成する処理分配部を配置したことにより、各処理部とイベントのマップを処理分配部に集約させることで、イベント受信部からはイベント処理部の詳細を意識させることがなくなり、より拡張の際の影響範囲を小さく出来る。

本実施形態によれば、上記構成に加え、イベント処理部の拡張部として、手動コール処理部を用意し、通信テストコール／ポーリング手動実行／サービスマン作業／終了といった手動（主にユーザ操作制御部）のイベント処理を行うことにより、各メッセージ作成に特化した部分の実装のみで対応可能となる。

本実施形態によれば、上記構成に加え、イベント処理部の拡張部として、機器イベント処理部を用意し、エラー通報等の機器状態変化のイベント処理を行うことにより、機器内状態監視からのイベント関連は似たものが多く存在するため機器イベント処理部で実装する。この処理部も、イベント受信部／イベント処理部の共通部があるため、各メッセージ作成に特化した部分の実装のみで対応可能となる。

本実施形態によれば、上記構成に加え、イベント処理部で全体状態を管理する構成をとることにより、処理部で行う処理を、よりメッセージの作成／送信に限定できるため、拡張性が向上する。

本実施形態によれば、上記構成に加え、初期化処理部において、「設置状態」、「通信許可状態」、「証明書状態」を確認し、イベント受信部に通知を行うことで起動時の状態を確立することにより、基本的なイベント処理部と同様の構成で状態遷移に関する通知も行えるようにすることで、余計な処理を用意することなく状態遷移を実現できる。

本実施形態によれば、上記構成に加え、基本的なイベント処理部と同様の構成で状態遷移に関する通知も行えるようにすることで、余計な処理を用意することなく状態遷移を実現できる。

すなわち、デバイスがシステムとしてセンター側とやり取りするメッセージと、デバイス内で発生するイベントとを紐付けた上で、イベント処理部をインターフェースとして各処理部の共通部分を共通化するので、遠隔管理システムに対応したデバイスを省メモリで実現し、将来のデバイス向けへの拡張にも備えることができる。

要するに、本実施形態に係る情報処理装置は、機器内で発生するイベントと、センターシステムとやり取りするべきメッセージ（処理内容）が対応付けられて管理されている。

（第２の実施形態）
第１の実施形態で説明したように、基本的に、機器上で発生したイベントを、イベント処理部が一旦全て受ける。次に、そのイベントを処理分配部に渡し、そのイベントを処理すべきイベント処理部が返却される。イベント受信部からみると、イベント処理部の詳細は知らずに、単に「イベント処理部」として捕らえており、発生したイベントを渡すだけで処理が完結する。つまり、発生イベントの種類と、そのイベントを処理すべきイベント処理部の種類は全て処理分配部が知っているという構成である。

第２の実施形態では、その発生イベントとイベント処理部との対応付けを更新する場合の構成例を示す。

図８は、第２の実施形態に係る情報処理装置を用いた遠隔管理システム全体のソフトウェア構成について説明するための説明図である。図８に示すシステムは、情報処理装置１０１−２と、情報処理装置１０１−２を遠隔管理する管理装置としてのセンターシステム１１０とを有する。

情報処理装置１０１−２は、ユーザ操作制御部１０２、機器内状態監視部１０３、イベント受信部１０４、イベント処理部１０５、処理分配部１０６−２、データ管理部１０７、機器状態管理部１０８、通信部１０９、処理生成部１１０−２、対応付け管理部１１１−２、及び、記憶部１１３−２を備えている。

第２の実施形態では、処理分配部１０６−２の機能と、処理生成部１１０−２、対応付け管理部１１１−２、及び、記憶部１１３−２を追加したことと、が第１の実施形態と異なっている。その他の構成および機能は、第１の実施形態のブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。

処理生成部１１０−２は、対応付け管理部１１１−２と処理生成部とに関連づけられる。対応付け管理部１１１−２は、処理分配部１０６−２から発生したイベントを渡されると、記憶部１１３−２に格納された「イベントと生成する処理部との対応表」を参照する。対応付け管理部１１１−２は、この対応表（マップ）を参照して、イベントに対応する生成すべきイベント処理部の名称を返却する。

イベント発生時に、対応付け管理部１１１−２が対応表を読み込む構成にしておくことで、対応表（表１など）を更新することが可能となる。例えば、ユーザが事前に記憶部１１３−２に記憶されるマップを更新しておけば、イベント発生時等に、更新後のマップにより処理が実行されるようになる。この読み込みのタイミングは、デバイスの種類等に応じて変更してもよい。例えば、ＭＦＰのような常に電源が入っているデバイスでは、イベント発生ごとに読み込み、プロジェクタなどの電源のオンおよびオフの多いデバイスでは電源オン時に読み込むように構成してもよい。

なお、図８では、記憶部１１３−２を情報処理装置１０１−２の内部に備えているが、ネットワーク等を介して接続される外部記憶装置内に記憶部１１３−２を備えるように構成してもよい。

図９は、第２の実施形態におけるエラー発生時のシーケンスについて説明する図である。図９は、機器内部でエラー発生通知が発行された場合のシーケンス図を示している。なお、図３と同様の処理については同一の符号を付し、適宜説明を省略する。

機器内状態監視部１０３からエラー発生通知を受けたイベント受信部１０４は、処理分配部１０６−２に処理分配依頼を行う（ステップＳ３０２）。この際、エラー発生通知のイベントを渡す。

処理分配部１０６−２は、対応付け管理部１１１−２にイベントを渡す（ステップＳ９０１）。対応付け管理部１１１−２は、記憶部１１３−２からイベントと対応する処理部のマップを読み込み（ステップＳ９０２）、読み込み完了を通知する（ステップＳ９０３）。
処理分配部１０６−２は、エラー発生イベントに対応する対応付けの取得を、対応付け管理部１１１−２に要求する（ステップＳ９０４）。対応付け管理部１１１−２は、エラー発生イベントに対応する処理部は機器イベント処理部であることを、処理分配部１０６−２に渡す（ステップＳ９０５）。

処理分配部１０６−２は、発生イベントと処理すべきイベント処理部（ここでは機器イベント処理部）の情報を処理生成部１１０−２に渡す（ステップＳ９０６）。この際、処理分配部１０６−２は、対応付け管理部１１１−２から返された情報とイベントを流すだけなので、処理部の詳細を把握する必要はない。

次に、処理生成部１１０−２は、機器イベント処理部を生成して（ステップＳ９０７）、処理分配部１０６−２経由してイベント受信部１０４に渡す（ステップＳ９０８、ステップＳ９０９）。イベント受信部１０４は、処理分配部１０６−２から返されたイベント処理部に対して処理実行を要求する（ステップＳ３０５）。イベント受信部１０４は、この際にも、イベント（エラー発生通知）を渡す。処理実行を受けた機器イベント処理部（イベント受信部１０４は「イベント処理部」として認識している）は、メッセージを構築し、送信部を経由して機器外にメッセージを送信する（ステップＳ３０６〜ステップＳ３１２）。ここでいうメッセージとは、「エラー発生メッセージ」となる。ここで、最初のイベントトリガが、ユーザ操作制御部１０２からのイベントになったとしても、基本的な流れは変わらない。

なお、上述した実施形態は、本発明の好適な実施形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。

１０１ 情報処理装置（プロジェクタ）
１０２ ユーザ操作制御部
１０３ 機器内状態監視部
１０４ イベント受信部
１０５ イベント処理部
１０６ 処理分配部
１０７ データ管理部
１０８ 機器状態管理部
１０９ 通信部
１１０ 管理装置（センターシステム）
２０１ 手動コール処理部
２０２ａ、２０２ｂ 設置処理部
２０３ 機器イベント処理部
２０４ 初期化処理部

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

Claims (12)

1. 管理装置により遠隔管理される情報処理装置において、
   内部で発生したイベントを受信するイベント受信部と、
   イベントに対応したイベント処理部への振り分けを決定する処理分配部と、
   前記処理分配部により生成した、前記管理装置に送信するメッセージを生成する複数のイベント処理部と、
   を備えたことを特徴とする情報処理装置。
2. 前記イベントを発生する手段は、ユーザの操作でイベントを発生するユーザ操作制御部と、
   情報処理装置内で発生するイベントを監視する機器内状態監視部と、
   を備えたことを特徴とする請求項１記載の情報処理装置。
3. 前記イベント処理部は、初期化処理中に、エラー通信情報取得、通信状態取得、及びメッセージ生成を行うことを特徴とする請求項１または２記載の情報処理装置。
4. 前記イベント処理部は、初期化処理中に、証明書状態確認、設置状態確認、通信設定遷移、及びメッセージ生成を行うことを特徴とする請求項１または２記載の情報処理装置。
5. 前記イベント処理部は、照会実施の際には、初期化処理中に、照会状態確認、及びメッセージ生成を行い、登録実施の際には、初期化処理中に、バージョン情報もしくはモデル名取得、及びメッセージ生成を行うことを特徴とする請求項１または２記載の情報処理装置。
6. 前記処理分配部は、イベントを項目別に分類し、その分類に応じた処理のマップを有し、
   前記イベント処理部は、
   通信テストコール、サービスマン作業開始、サービスマン作業終了、及びポーリング手動実行を含む手動コール処理部と、
   照会実施及び登録実施を含む設置処理部と、
   定期情報通知及びエラー発生通知を含む機器イベント処理部と、
   起動通知を含む初期化処理部と、を有すること
   を特徴とする請求項１記載の情報処理装置。
7. 前記イベントと、前記イベントに対応するイベント処理部とを対応づけた対応情報を記憶する記憶部から前記対応情報を読み込む対応付け管理部をさらに備え、
   前記処理分配部は、読み込まれた前記対応情報を参照して前記イベントに対応した前記イベント処理部への振り分けを決定すること、
   を特徴とする請求項１記載の情報処理装置。
8. 前記対応付け管理部は、予め定められたタイミングで前記対応情報を読み込むこと、
   を特徴とする請求項７記載の情報処理装置。
9. 前記対応付け管理部は、外部記憶装置の記憶部から前記対応情報を読み込むこと、
   を特徴とする請求項７記載の情報処理装置。
10. 前記処理分配部の要求に応じて、前記イベントに対応した前記イベント処理部を生成する処理生成部をさらに備える、
    を特徴とする請求項１記載の情報処理装置。
11. 管理装置により遠隔管理される情報処理装置から前記管理装置に対して、前記情報処理装置に関するイベントをトリガとして、そのイベントに対応付けられた実際にやり取りするメッセージを、前記情報処理装置内部から情報及び状態を収集して構築し、送信することを特徴とする情報処理装置の情報処理方法。
12. 管理装置により遠隔管理される情報処理装置のコンピュータに、
    ユーザ操作制御部が、ユーザの操作によりイベントを発生する手順、
    機器内状態監視部が、イベントを発生する手順、
    イベント受信部が、内部で発生したイベントを受信する手順、
    処理分配部が、イベントに対応したイベント処理部への振り分けを決定する手順、
    イベント処理部が、前記処理分配部により生成した、前記管理装置に送信するメッセージを生成する手順、
    通信部が、前記メッセージを前記管理装置に送信する手順、
    を実行させることを特徴とするプログラム。

Images