JP2019152902A - 情報処理装置及びその制御方法、並びにプログラム - Google Patents

Abstract

【課題】情報処理装置内でイベントログを効率的にバッファリングしながら、サーバ装置に適合したデータ形式でイベントログを送信する技術を提供する。【解決手段】構造化モジュール４０３，４０５，４２１は、ＭＦＰ１２０において行われる処理に関連して発生するデータを収集する。バッファ制御モジュール４０７は、各構造化モジュールによって収集されたデータを、外部の管理サーバへの送信用の第２データ形式と異なる第１データ形式で、バッファＤＢ４０９にバッファリングする。データ変換モジュール４１１は、バッファ制御モジュール４０７によってバッファリングされたデータの管理サーバへの送信前に、当該データの形式を第１データ形式から第２データ形式に変換する。送信モジュール４１２は、データ変換モジュール４１１による変換後の第２データ形式のデータを、ＭＦＰ１２０のイベントログとして管理サーバへ送信する。【選択図】図４

Description

本発明は、情報処理装置及びその制御方法、並びにプログラムに関するものである。

近年、複合機等の画像形成装置では、装置の状態を遠隔から把握する目的で、装置内で行われる各種処理の内容に関するデータを収集し、収集したデータを、イベントログとして管理サーバへ送信することが行われている。例えば、特許文献１には、監視サーバによる監視対象のノードが、複数種類のフォーマットのログメッセージに対してフォーマット変換を行い、フォーマットが統一されたログメッセージを監視サーバへ送信する技術が提案されている。

特開２００９−９４４８号公報

上述のような画像形成装置等の情報処理装置と管理サーバとの間の通信が行われるインターネット等のネットワークでは、一般に、通信速度の低下又は通信の途絶が生じること場合がある。このような場合に備えるために、画像形成装置は、装置内で収集したイベントログを、管理サーバへの送信が完了するまでの間、一時的にバッファ領域に蓄積（バッファリング）しておく必要がある。

しかし、管理サーバへイベントログを送信する際には、管理サーバによる処理が容易なデータ形式を用いる必要があり、一般には比較的大きなデータサイズのデータ形式を用いることが多い。このようなデータ形式を用いてバッファ領域にイベントログを蓄積するためには、大きなサイズのバッファ領域が必要となってしまう。

本発明は、上述の問題に鑑みてなされたものである。本発明は、情報処理装置内でイベントログを効率的にバッファリングしながら、サーバ装置に適合したデータ形式でイベントログを送信する技術を提供することを目的とする。

本発明の一態様に係る情報処理装置は、前記情報処理装置において行われる処理に関連して発生するデータを収集する収集手段と、前記収集手段によって収集されたデータを、外部のサーバ装置への送信用の第２データ形式と異なる第１データ形式でバッファリングするバッファリング手段と、前記バッファリング手段によってバッファリングされたデータの前記サーバ装置への送信前に、当該データの形式を前記第１データ形式から前記第２データ形式に変換する変換手段と、前記変換手段による変換後の前記第２データ形式のデータを、前記情報処理装置のイベントログとして前記サーバ装置へ送信する送信手段と、を備えることを特徴とする。

本発明によれば、情報処理装置内でイベントログを効率的にバッファリングしながら、サーバ装置に適合したデータ形式でイベントログを送信することが可能になる。

通信システムの構成例を示す図。 ＭＦＰのハードウェア構成例を示すブロック図。 情報処理コントローラのハードウェア構成例を示すブロック図。 ＭＦＰのソフトウェア構成例を示すブロック図。 イベントログを一時的に蓄積する処理の手順を示すフローチャート。 イベントログを管理サーバへ送信する処理の手順を示すフローチャート。

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

以下の第１及び第２実施形態では、画像形成装置に本発明を適用した例について説明する。なお、本発明は、情報処理装置であれば適用可能であり、例えば、印刷装置、複写機、複合機及びファクシミリ装置等の画像形成装置（画像処理装置）だけでなく、ＰＣ、サーバ装置等の情報機器にも適用可能である。

［第１実施形態］
＜システム構成＞
図１は、本発明の実施形態に係る通信システムの構成例を示す図である。図１に示す通信システムにおいて、イベントログ管理サーバ（以下では「管理サーバ」と称する。）１１０及び複合機（ＭＦＰ）１２０ａ，１２０ｂは、ネットワーク１００に接続されており、ネットワーク１００を介して互いに通信可能である。なお、ネットワーク１００は、例えば、有線ＬＡＮ（ローカルエリアネットワーク）及びインターネットで構成されうる。

管理サーバ１１０には、ＭＦＰ１２０ａ，１２０ｂ等のクライアント装置のイベントログを管理するサーバ装置である。管理サーバ１１０には、各クライアント装置で実行されたジョブ又はユーザ操作の履歴情報をイベントログとして収集し、収集したイベントログを分析するためのアプリケーションがインストールされている。このアプリケーションは、ネットワーク１００を介してＭＦＰ１２０ａ，１２０ｂから送信されるイベントログを収集及び分析する。

ＭＦＰ１２０（１２０ａ，１２０ｂ）は、プリント、コピー、スキャナ、ファクシミリ（ＦＡＸ）送信等の、複数の機能を有する情報機器である。ＭＦＰ１２０は、更に、各機能の実行履歴を保持する機能、各機能により使用される設定値を保持する機能、並びに、実行履歴及び設定値を管理サーバ１１０へ送信する機能を有している。

＜ＭＦＰの構成＞
図２は、本実施形態に係るＭＦＰ１２０のハードウェア構成例を示すブロック図である。ＭＦＰ１２０は、情報処理コントローラ２０１、プリンタコントローラ２０２、スキャナコントローラ２０３、プリンタ２０４、スキャナ２０５、及び操作部２０６を備えている。情報処理コントローラ２０１は、ＭＦＰ１２０の動作に関連する情報処理を制御する。情報処理コントローラ２０１は、プリンタコントローラ２０２、スキャナコントローラ２０３、及び操作部２０６と接続される。プリンタコントローラ２０２は、画像出力デバイスであるプリンタ２０４を制御する。スキャナコントローラ２０３は、画像入力デバイスであるスキャナ２０５を制御する。

図３は、情報処理コントローラ２０１のハードウェア構成例を示すブロック図である。情報処理コントローラ２０１は、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、及びＨＤＤ（ハードディスクドライブ）３０４を有する。情報処理コントローラ２０１は、更に、ネットワークインタフェース（Ｉ／Ｆ）３０５、操作部Ｉ／Ｆ３０６、画像処理部３０７、及びデバイスコントローラＩ／Ｆ３０８を有する。これらのデバイスは、システムバス３０９にそれぞれ接続されている。

ＣＰＵ３０１は、ＲＯＭ３０２に格納されているブートプログラムを実行してＯＳを起動する。ＲＯＭ３０２は、ｅＭＭＣ等のフラッシュメモリとそのコントローラとで構成されている。ＲＯＭ３０２には、ＣＰＵ３０１によって実行される制御プログラムが格納される。ＣＰＵ３０１は、ＯＳ上で、ＲＯＭ３０２又はＨＤＤ３０４に格納されているアプリケーションプログラムを実行することにより、各種処理を実行する。ＲＡＭ３０３は、ＣＰＵ３０１に対して作業領域を提供するとともに、画像データを一時的に格納するための画像メモリ領域を提供する。ＲＯＭ３０２又はＨＤＤ３０４には、上記の上記アプリケーションプログラム、画像データ、及び各種設定値が格納される。なお、ＨＤＤ３０４はＭＦＰ１２０に搭載されていない場合もある。

操作部Ｉ／Ｆ３０６は、操作部２０６とのインタフェースである。操作部２０６は、タッチパネル機能を有するディスプレイ（表示部）を備える。操作部Ｉ／Ｆ３０６は、操作部２０６に表示すべき画面の画面データを、操作部２０６に対して出力する。また、操作部Ｉ／Ｆ３０６は、操作部２０６を介してユーザにより入力された情報を、ＣＰＵ３０１へ送信する。

デバイスコントローラＩ／Ｆ３０８には、プリンタコントローラ２０２及びスキャナコントローラ２０３が接続される。デバイスコントローラＩ／Ｆ３０８は、画像データの同期系／非同期系の変換を行う。ネットワークＩ／Ｆ３０５は、ネットワーク１００に接続されており、ネットワーク１００を介して、管理サーバ１１０等の外部装置との通信（情報の入出力）を行う。画像処理部３０７は、プリンタ２０４へ出力する画像データ、及びスキャナ２０５から入力された画像データに対する画像処理を行う。画像処理部３０７は、例えば、画像回転、画像圧縮、解像度変換、色空間変換、階調変換等の処理を行う。

＜ＭＦＰのソフトウェア構成＞
図４は、本実施形態に係るＭＦＰ１２０上で動作するＭＦＰファームウェア４００のソフトウェア構成例を示すブロック図である。ＭＦＰファームウェア４００は、ＲＯＭ３０２、ＲＡＭ３０３、及びＨＤＤ３０４のいずれかの記憶装置に格納され、ＣＰＵ３０１によって実行される。

ジョブ管理モジュール４０１は、ネットワークＩ／Ｆ３０５を介してネットワーク１００と接続されており、特定の通信プロトコルを用いてプリントジョブ等のジョブを外部装置から受信し、受信したジョブを実行する。また、ジョブ管理モジュール４０１は、操作部制御モジュール４０２が受け付けた、コピージョブ、プリントジョブ又はスキャンジョブ等のジョブについての通知を受けると、当該通知に従ってジョブを実行する。ジョブ管理モジュール４０１は、ジョブを実行した際に、当該ジョブの実行履歴をジョブ履歴ＤＢ（データベース）４０４に保存する。

また、ジョブ管理モジュール４０１は、他のモジュールからの問い合わせに応じて、ジョブに関連するデータを提供する機能、及び他のモジュールからイベント購読要求を受け付けて、当該購読要求に従ってイベントを伝達する機能を有する。ジョブ管理モジュール４０１は、例えば、ジョブの開始、一時停止及び終了のタイミングといった、ジョブの実行状態に変化が生じたタイミングに、イベントの伝達を行う。

ジョブ履歴ＤＢ４０４には、ジョブの実行履歴が格納される。実行履歴には、ジョブの開始日時及び終了日時、給紙枚数、排紙枚数、ステイプルの有無等の、ジョブの実行に関連する情報が含まれる。なお、ジョブ履歴ＤＢ４０４に格納されるジョブ実行履歴は、ＨＤＤ３０４に格納される。

操作部制御モジュール４０２は、操作部２０６により受け付けた、コピージョブ又はスキャンジョブ等のジョブの実行を指示するためのユーザ操作の内容を示すデータを、操作部Ｉ／Ｆ３０６を介して操作部２０６から受信する。操作部制御モジュール４０２は、ユーザから受け付けたユーザ操作の内容を、構造化モジュール４０５に伝達する機能を有する。

デバイス制御モジュール４２０は、デバイスコントローラＩ／Ｆ３０８を介してプリンタコントローラ２０２及びスキャナコントローラ２０３を制御することにより、各デバイス（プリンタ２０４及びスキャナ２０５）を制御する。具体的には、デバイス制御モジュール４２０は、処理対象の画像データ及び制御内容をジョブ管理モジュール４０１から受け付けて、受け付けた制御内容に従って、プリンタコントローラ２０２及びスキャナコントローラ２０３を制御する。また、デバイス制御モジュール４２０は、各デバイスの制御内容を、構造化モジュール４２１に伝達する機能を有する。

構造化モジュール４０３は、ジョブ管理モジュール４０１から出力されたデータ（即ち、ジョブの実行に関連するデータ）を、所定のデータスキーマに従って構造化されたデータへ変換する。構造化モジュール４０５は、操作部制御モジュール４０２から出力されたデータ（即ち、ユーザ操作に関連するデータ）を、所定のデータスキーマに従って構造化されたデータへ変換する。構造化モジュール４２１は、デバイス制御モジュール４２０から出力されたデータ（即ち、ＭＦＰ１２０が備えるデバイスの制御に関連するデータ）を、所定のデータスキーマに従って構造化されたデータへ変換する。

上述の各構造化モジュールは、変換の結果、中間データ生成モジュール４２２が解釈可能なデータを生成する。変換の具体例としては、データの発生日時、又はデータを一意に特定するためのＵＵＩＤ（Universal Unique ID）を新たに付与する処理、及びデータを所定の階層構造又は表現形式を有するデータへ変換する処理が挙げられる。これらの変換は、複数の種類のデータを統一的に扱うために、又は、処理の効率性のために情報が符号化若しくは簡略化されているデータを、後の分析が容易になるように加工するために行われる。なお、上述の各構造化モジュールは、管理サーバ１１０へ送信されるデータに対して、上述の処理以外にも、必要に応じて、データ構造に関する前加工を更に行ってもよい。

このようにして、構造化モジュール４０３，４０５，４２１は、ＭＦＰ１２０において行われる処理に関連して発生するデータを収集し、中間データ生成モジュール４２２へ提供するデータを生成する。

中間データ生成モジュール４２２は、構造化モジュール４０３，４０５，４２１によって生成された、所定の表現形式で表現されたデータを、バッファリングのために永続化可能なデータ形式のデータである中間データに変換する。本実施形態では、中間データのデータ形式として、外部の管理サーバ１１０への送信用のデータ形式（第２データ形式）とは異なるデータ形式（第１データ形式）が用いられる。この第１データ形式には、ＭＦＰ１２０内でイベントログを効率的にバッファリングすることが可能な形式が採用されうる。

中間データのデータ形式として、データサイズが可能な限り小さくなるデータ形式を用いることにより、バッファＤＢ４０９に蓄積可能なデータを増やすことが可能である。例えば、値域に応じてデータサイズが可変となるＣＢＯＲ（Concise Binary Object Representation）のようなデータ形式が使用されてもよいし、ハフマン符号等の符号化形式が使用されてもよい。あるいは、これらが併用されてもよい。とりわけ、管理サーバ１１０への送信用の、管理サーバ１１０が解釈可能なデータ形式（第２データ形式）よりもデータサイズが小さいデータ形式が、バッファＤＢ４０９に蓄積（バッファリング）される中間データに用いられてもよい。

バッファ制御モジュール４０７は、中間データ生成モジュール４２２によって生成された中間データを、バッファＤＢ４０９に格納することで、中間データのバッファリングを行う。即ち、バッファ制御モジュール４０７は、構造化モジュール４０３，４０５，４２１によって収集されたデータを、管理サーバ１１０への送信用のデータ形式で、バッファＤＢ４０９にバッファリングする。

バッファＤＢ４０９は、中間データの生成タイミングと、この中間データをイベントログとして管理サーバ１１０へ送信するタイミングとの差を吸収するためのバッファとして設けられる。例えば、通信障害等に起因して管理サーバ１１０との通信が滞っている間に生成されてバッファリングされた中間データは、管理サーバ１１０との通信が可能になるまで、バッファＤＢ４０９に保持し続けられる。管理サーバ１１０との通信が可能になると、バッファＤＢ４０９に保持された中間データの送信（データ変換モジュール４１１による変換後のデータの送信）が順次行われる。バッファ制御モジュール４０７は、送信モジュール４１２による送信が完了したデータに対応する中間データ（第１データ形式のデータ）を、バッファＤＢ４０９から削除する。

また、バッファ制御モジュール４０７は、バッファＤＢ４０９への中間データ（イベントログ）のバッファリングに関する通知を、バッファ通知モジュール４１０に指示する機能を有する。バッファ通知モジュール４１０は、バッファ制御モジュール４０７から通知を受けると、中間データ（イベントログ）がバッファＤＢ４０９に格納されている（バッファリングされている）ことを示す格納通知を、送信モジュール４１２へ送る。

データ変換モジュール４１１は、中間データ生成モジュール４２２が生成した、イベントログに相当する中間データ（第１データ形式のデータ）を、管理サーバ１１０が解釈可能なデータ形式のデータ（第２データ形式のデータ）へ変換する。本実施形態では、一例として、データ変換モジュール４１１による変換により生成されるイベントログのデータ形式（第２データ形式）は、ＪＳＯＮ（JavaScript(登録商標) Object Notation）形式である。ＪＳＯＮ形式は、一般的に、インターネット通信で広く用いられるデータ形式である。このような一般的なデータ形式を用いることにより、イベントログの加工、分析又は可視化に使用される各種ソフトウェア間の相互運用性を高めることが可能となる。

このようにして、データ変換モジュール４１１は、バッファＤＢ４０９にバッファリングされた中間データの送信前に、当該中間データの形式を、管理サーバ１１０への送信用のデータ形式（本実施形態ではＪＳＯＮ形式）に変換する。

送信モジュール４１２は、データ変換モジュール４１１による変換後のデータを、ＭＦＰ１２０のイベントログとして、ネットワーク１００を介して管理サーバ１１０へ送信する。フィルタリングモジュール４１３は、送信モジュール４１２による送信対象のイベントログの内容を確認し、当該イベントログを実際に管理サーバ１１０へ送信すべきか否かを判定するフィルタリング処理を行う。送信モジュール４１２は、フィルタリングモジュール４１３による判定の結果に従って、イベントログを管理サーバ１１０へ送信する。

＜イベントログのバッファリング処理＞
図５は、イベントログを中間データとしてバッファリングする処理の手順を示すフローチャートである。本フローチャートの各ステップの処理は、ＲＯＭ３０２又はＨＤＤ３０４に格納されたコンピュータプログラムを、ＣＰＵ３０１が必要に応じてＲＡＭ３０３に展開して実行することによって実現されうる。なお、本フローチャートの手順による処理を実行する前準備として、構造化モジュール４０３は、中間データの生成に必要なイベントデータを取得するために、ＭＦＰファームウェア４００の起動時にジョブ管理モジュール４０１に対してイベント購読要求を行う。イベント購読要求に対応してジョブ管理モジュール４０１から何らかのイベントが伝達されると、構造化モジュール４０３は、本フローチャートの手順による処理を開始する。

Ｓ５０１で、構造化モジュール４０３は、ジョブ管理モジュール４０１からイベントデータを受信すると、受信したイベントデータが示すイベントの内容を確認する。確認されるイベントの内容には、イベントの種別が含まれる。イベントの種別とは、例えば、ジョブの開始、一時停止及び終了のタイミングといった、ジョブの実行状態に変化の具体的な内容に対応する。

イベントの内容の確認が完了すると、Ｓ５０２で、構造化モジュール４０３は、確認したイベントの内容に基づいて、中間データに含められるデータの一部を構成するデータ共通部を生成する。

データ共通部は、イベントの具体的な内容に関わらず中間データに対して必ず付与される情報で構成され、例えば、イベントの発生日時、イベントの種別、及びイベントが発生した装置の識別ＩＤ等から構成される。なお、構造化モジュール４０３は、データ共通部の生成に必要な情報を中間データ生成モジュール４２２に送信することによって、中間データ生成モジュール４２２にデータ共通部を生成させる。

次にＳ５０３で、構造化モジュール４０３は、Ｓ５０１で確認したイベントの種別に応じて、中間データに含めるべきデータ（中間データの生成に必要なデータ）を決定する。例えば、ジョブの種別がジョブの開始イベントである場合には、ジョブの投入者、及びコピー又はプリントといったジョブの種別等のデータが、必要なデータとして決定される。また、イベントの種別がジョブの終了イベントである場合、ジョブの実行の成否等のデータが、必要なデータとして決定される。なお、決定されるデータは、これらのデータに限定されず、任意の方法でデータが決定されてよい。

必要なデータを決定すると、次にＳ５０４で、構造化モジュール４０３は、決定したデータをジョブ管理モジュール４０１から取得する。このようにして、構造化モジュール４０３は、ＭＦＰ１２０において発生したイベントの種別に応じて、当該イベントに関連するデータを収集する。更にＳ５０５で、構造化モジュール４０３は、所定のデータスキーマに従って、イベント種別ごとに個別に定められた、中間データに含められるデータの一部を構成するデータ個別部を生成する。

Ｓ５０５で使用されるデータスキーマは、各データに対して付与される識別子、及びデータ間の階層構造を規定している。データスキーマには、例えば、ジョブの投入者のデータには識別用の文字列として「JobCreator」を関連付ける、といった規定が含まれる。なお、データスキーマに関する情報は、構造化モジュール４０３に対応するプログラムに含まれてもよいし、又は、当該プログラムとは別にＨＤＤ３０４に格納され、必要に応じてＨＤＤ３０４から読み出されてもよい。なお、構造化モジュール４０３は、データ個別部の生成に必要な情報を中間データ生成モジュール４２２に送信することによって、中間データ生成モジュール４２２にデータ個別部を生成させる。

最後にＳ５０６で、構造化モジュール４０３は、Ｓ５０２で生成したデータ共通部と、Ｓ５０５で生成したデータ個別部とを連結して中間データを生成し、生成した中間データをバッファ制御モジュール４０７に送信する。これにより、バッファ制御モジュール４０７は、受信した中間データをバッファＤＢ４０９に格納（バッファリング）するとともに、中間データをバッファリングしたことをバッファ通知モジュール４１０へ通知する。以上により、図５の手順による処理が終了する。

このようにして、構造化モジュール４０３によって収集されたデータ（イベントログ）を、管理サーバ１１０への送信用のデータ形式とは異なるデータ形式の中間データとしてバッファＤＢ４０９にバッファリングする処理を実現できる。なお、構造化モジュール４０５，４２１によって収集されたデータ（イベントログ）を、管理サーバ１１０への送信用のデータ形式とは異なるデータ形式の中間データとしてバッファＤＢ４０９にバッファリングする処理も、同様の処理により実現可能である。

＜イベントログの送信処理＞
図６は、中間データとしてバッファリングされたイベントログを管理サーバ１１０へ送信する処理の手順を示すフローチャートである。本フローチャートの各ステップの処理は、ＲＯＭ３０２又はＨＤＤ３０４に格納されたコンピュータプログラムを、ＣＰＵ３０１が必要に応じてＲＡＭ３０３に展開して実行することによって実現されうる。中間データ生成モジュール４２２によって生成された中間データを、バッファ制御モジュール４０７が受け付けてバッファＤＢ４０９に格納すると、本フローチャートの手順による処理が開始される。

Ｓ６０１で、バッファ制御モジュール４０７は、中間データ生成モジュール４２２によって生成された中間データをバッファＤＢ４０９に格納すると、中間データの格納通知を、バッファ通知モジュール４１０を介して送信モジュール４１２へ伝達する。この通知を行う際、バッファ通知モジュール４１０は、データ変換モジュール４１１を通じて、中間データを、管理サーバ１１０への送信用のデータ形式（本実施形態では、ＪＳＯＮ形式）のデータに変換する。

Ｓ６０２で、送信モジュール４１２は、バッファ通知モジュール４１０から中間データ（イベントログ）の格納通知を受信すると、当該イベントログを実際に管理サーバ１１０に送信するか否かを判定する。送信モジュール４１２は、イベントログを管理サーバ１１０へ送信すると判定した場合には、Ｓ６０３へ処理を進め、送信しないと判定した場合には、Ｓ６０４へ処理を進める。

本実施形態では、この判定を行うために、送信モジュール４１２は、フィルタリングモジュール４１３にイベントログを与えて、管理サーバ１１０へ送信すべきか否かをフィルタリングモジュール４１３に問い合わせる。このフィルタリング処理は、例えば、通信回線の状態に合わせて送信データ量を削減するため、又は所定の状態にある装置のみから管理サーバ１１０が特定のイベントを取得できるようにするために行われる。

Ｓ６０３で、送信モジュール４１２は、ネットワークＩ／Ｆ３０５及びネットワーク１００を通じて、管理サーバ１１０を宛先としてイベントログを送信する。イベントログの送信に用いられる通信プロトコルは、例えば、ＨＴＴＰ（Hypertext Transfer Protocol）である。この場合、ＪＳＯＮ形式で表現されたイベントログは、ＨＴＴＰデータのペイロードに格納された状態で、管理サーバ１１０へ送信される。なお、ＨＴＴＰ以外の通信プロトコルをイベントログの送信に使用してもよい。例えば、ＭＱＴＴ（Message Queue Telemetry Transport）等のプロトコルを、イベントログの送信に使用することも可能である。送信モジュール４１２は、管理サーバ１１０へのイベントログの送信が完了すると、Ｓ６０４へ処理を進める。

Ｓ６０４で、送信モジュール４１２は、バッファ制御モジュール４０７に対して、イベントログの送信が完了したことを伝達する。これに応じて、バッファ制御モジュール４０７は、送信が完了したデータに対応する中間データ（第１データ形式のデータ）をバッファＤＢ４０９から削除する。以上により、図６の手順による処理が終了する。

なお、本実施形態では、バッファＤＢ４０９をＭＦＰファームウェア４００内で管理しているが、バッファＤＢ４０９を管理するバッファＤＢサーバをネットワーク１００上に配置する構成を採用することも可能である。この構成においては、ＭＦＰ１２０は、中間データをバッファＤＢサーバに対して送信する。バッファＤＢサーバは、ＭＦＰ１２０から受信した中間データをバッファリングし、適宜、当該中間データをイベントログのデータ形式（ＪＳＯＮ形式等）に変換して管理サーバ１１０に送信する。

以上説明したように、本実施形態では、構造化モジュール４０３，４０５，４２１は、ＭＦＰ１２０において行われる処理に関連して発生するデータを収集する。バッファ制御モジュール４０７は、各構造化モジュールによって収集されたデータを、外部の管理サーバ１１０への送信用の第２データ形式（ＪＳＯＮ形式等）と異なる第１データ形式（ＣＢＯＲ形式等）で、バッファＤＢ４０９にバッファリングする。データ変換モジュール４１１は、バッファ制御モジュール４０７によってバッファリングされたデータの管理サーバ１１０への送信前に、当該データの形式を第１データ形式から第２データ形式に変換する。送信モジュール４１２は、データ変換モジュール４１１による変換後の第２データ形式のデータを、ＭＦＰ１２０のイベントログとして管理サーバ１１０へ送信する。

このように、本実施形態では、ＭＦＰ１２０は、管理サーバ１１０へイベントログを送信する際のデータ形式（ＪＳＯＮ形式等）とは異なるデータ形式（ＣＢＯＲ形式等）で、イベントログのバッファリングを行う。これにより、ＭＦＰ１２０内でイベントログを効率的にバッファリングしながら、管理サーバ１１０に適合したデータ形式（管理サーバ１１０が解釈可能又は処理が容易なデータ形式）でイベントログを送信することが可能になる。特に、管理サーバ１１０へイベントログを送信する際のデータ形式よりもデータサイズが小さいデータ形式を、バッファリングされる中間データのデータ形式として用いることで、ＭＦＰ１２０内にバッファリング可能なデータ量を増やすことが可能である。その結果、管理サーバ１１０との通信が途絶した場合等に、送信対象のイベントログを喪失する可能性を低減することが可能である。

［第２実施形態］
第２実施形態では、上述のＭＦＰ１２０において、必要に応じてバッファＤＢ４０９に格納（バッファリング）するデータのデータ形式を変更することにより、イベントログの送信処理を効率的に行うことを可能にする。以下では、第１実施形態と共通する部分については説明を省略する。

本実施形態では、図５のフローチャートのＳ５０５において、構造化モジュール４０３は、以下の処理を実行する。構造化モジュール４０３は、バッファリング対象の中間データのデータ個別部のサイズが所定の閾値（第１閾値）より小さい場合に、当該データを管理サーバ１１０への送信用のデータ形式のデータとしてバッファＤＢ４０９にバッファリングする。即ち、構造化モジュール４０３は、データ変換モジュール４１１によって中間データから生成されるデータを、バッファＤＢ４０９に格納する。なお、構造化モジュール４０３は、データ個別部とデータ共通部とを連結したデータのサイズと所定の閾値とを比較して、このような制御を行ってもよい。

また、構造化モジュール４０３は、データ個別部に含まれるデータ項目（属性等）の数が所定の閾値（第２閾値）より小さい場合に、当該データを管理サーバ１１０への送信用のデータ形式のデータとしてバッファＤＢ４０９にバッファリングしてもよい。Ｓ６０３で、送信モジュール４１２は、送信用のデータ形式（ＪＳＯＮ形式等）でバッファＤＢ４０９にバッファリングされたデータについては、当該バッファリングされたデータをそのままイベントログとして管理サーバ１１０へ送信する。

このように、バッファＤＢ４０９にデータをバッファリングする際のデータ形式を必要に応じて切り替えることにより、管理サーバ１１０への送信に関連する処理速度を向上させることが可能である。具体的には、中間データのサイズが小さい場合には、例えば、中間データに用いられるＣＢＯＲ形式と、送信用データに用いられるＪＳＯＮ形式とで、データサイズの差が小さい。このような場合には、中間データをバッファリングして、バッファＤＢ４０９に格納するデータのサイズを削減することよりも、送信用のデータに変換してバッファリングすることで、データの送信時のデータ形式の変換を省略することを優先してもよい。これにより、イベントログの送信に関連するＭＦＰ１２０の処理効率を向上させることが可能である。

［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１２０（１２０ａ，１２０ｂ）：ＭＦＰ、１１０：管理サーバ、１００：ネットワーク、２０１：情報処理コントローラ、２０２：プリンタコントローラ、２０３：スキャナコントローラ、３０１：ＣＰＵ

Claims (10)

1. 情報処理装置であって、
   前記情報処理装置において行われる処理に関連して発生するデータを収集する収集手段と、
   前記収集手段によって収集されたデータを、外部のサーバ装置への送信用の第２データ形式と異なる第１データ形式でバッファリングするバッファリング手段と、
   前記バッファリング手段によってバッファリングされたデータの前記サーバ装置への送信前に、当該データの形式を前記第１データ形式から前記第２データ形式に変換する変換手段と、
   前記変換手段による変換後の前記第２データ形式のデータを、前記情報処理装置のイベントログとして前記サーバ装置へ送信する送信手段と、
   を備えることを特徴とする情報処理装置。
2. 前記第２データ形式は、前記サーバ装置が解釈可能なデータ形式であり、
   前記第１データ形式は、前記第２データ形式よりもデータサイズが小さいデータ形式であるさ
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記バッファリング手段は、前記送信手段による前記サーバ装置への送信が完了するまで、バッファリングしたデータを保持し続ける
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記バッファリング手段によってバッファリングされる前記第１データ形式のデータが格納される記憶手段を更に備え、
   前記バッファリング手段は、前記送信手段による前記第２データ形式のデータの送信が完了すると、当該送信が完了したデータに対応する前記第１データ形式のデータを前記記憶手段から削除する
   ことを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
5. 前記バッファリング手段は、バッファリング対象の前記第１データ形式のデータのサイズが第１閾値より小さければ、当該データを前記第２データ形式のデータとしてバッファリングし、
   前記送信手段は、前記第２データ形式でバッファリングされたデータについては、当該バッファリングされたデータをそのまま前記サーバ装置へ送信する
   ことを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記バッファリング手段は、バッファリング対象の前記第１データ形式のデータに含まれる属性の数が第２閾値より小さければ、当該データを前記第２データ形式のデータとしてバッファリングし、
   前記送信手段は、前記第２データ形式でバッファリングされたデータについては、当該バッファリングされたデータをそのまま前記サーバ装置へ送信する
   ことを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
7. 前記収集手段は、前記情報処理装置において発生したイベントの種別に応じて、当該イベントに関連するデータを収集する
   ことを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
8. 前記収集手段は、前記情報処理装置におけるジョブの実行に関連するデータ、前記情報処理装置が備えるデバイスの制御に関連するデータ、及び、前記情報処理装置の操作部におけるユーザ操作に関連するデータを収集する
   ことを特徴とする請求項１から７のいずれか１項に記載の情報処理装置。
9. 情報処理装置の制御方法であって、
   前記情報処理装置において行われる処理に関連して発生するデータを収集する収集工程と、
   前記収集工程で収集されたデータを、外部のサーバ装置への送信用の第２データ形式と異なる第１データ形式でバッファリングするバッファリング工程と、
   前記バッファリング工程でバッファリングされたデータの前記サーバ装置への送信前に、当該データの形式を前記第１データ形式から前記第２データ形式に変換する変換工程と、
   前記変換工程における変換後の前記第２データ形式のデータを、前記情報処理装置のイベントログとして前記サーバ装置へ送信する送信工程と、
   を含むことを特徴とする情報処理装置の制御方法。
10. 請求項９に記載の情報処理装置の制御方法の各工程を、コンピュータに実行させるためのプログラム。

Images