(57)【要約】【課題】処理対象のデータ外の情報を用いて前処理の判定を行うことができ、複雑、柔軟な前処理の実行判定を可能にすること。【解決手段】前処理サーバ１０１は、データ蓄積サーバ１０２に蓄積されたデータに対し、ルールに従った判定条件を用いて前処理を実行するか否かを判定し、前処理を実行すると判定した場合に、データに対して前処理を行う。なお、前処理サーバ１０１は、ＦＷ情報管理サーバ１０４、出動履歴ＤＢ１０５、デバイスマスタＤＢ１０６等の外部システムへのアクセスを含む判定ロジックを管理し、前記ルールに判定ロジックの指定を含む判定条件が設定されている場合には、該判定ロジックを実行し、該実行結果に基づいて、前処理の判定を行う。【選択図】図１
2016051426.tif 000002
【特許請求の範囲】
【請求項１】
蓄積されたデータに対して予め設定されたルールに従った処理を行って分析に適したデータとする分析システムであって、
前記蓄積されたデータに対し、前記ルールに従った判定条件を用いて前記処理を実行するか否かを判定する判定手段と、
前記判定手段により前記処理を実行すると判定された場合に、前記データに対して前記処理を行う処理手段と、
外部システムへのアクセスを含むロジックを実行する実行手段と、を有し、
前記判定手段は、前記ルールに前記ロジックの指定を含む判定条件が設定されている場合には、該ロジックを前記実行手段に実行させ、該実行の結果に基づいて、前記判定を行うことを特徴とする分析システム。
【請求項２】
前記判定手段は、前記ルールに、前記ロジックを指定を含まない第１の判定条件、及び、前記ロジックの指定を含む第２の判定条件が含まれている場合には、前記第１の判定条件、前記第２の判定条件の順に判定を行うことを特徴とする請求項１に記載の分析システム。
【請求項３】
前記判定手段は、前記第１の判定条件を用いた判定結果が処理を実行しないことを表す場合には、前記第２の判定条件を用いた判定を省略することを特徴とする請求項２に記載の分析システム。
【請求項４】
前記ロジックは、所定の情報の真偽を外部システムに問い合わせるロジック、又は、所定の情報を外部システムから取得するロジックであることを特徴とする請求項１乃至３のいずれか１項に記載の分析システム。
【請求項５】
前記ロジックに対応するプログラムの実行ファイルを格納する格納手段を有し、
前記実行手段は、前記実行ファイルを実行するものであり、
前記ロジックの指定を含む判定条件には、前記ロジックに引き渡す引数の情報が含まれることを特徴とする請求項１乃至４のいずれか１項に記載の分析システム。
【請求項６】
前記ルールは、前記蓄積されるデータの種類ごとに設定されることを特徴とする請求項１乃至５のいずれか１項に記載の分析システム。
【請求項７】
前記蓄積されたデータは、デバイスで生成されたログデータ、デバイスが記録した環境データの少なくともいずれかを含み、
前記デバイスは、画像形成装置、携帯電話、スマートフォン、パーソナルコンピュータ、家電の少なくともいずれかを含むことを特徴とする請求項１乃至６のいずれか１項に記載の分析システム。
【請求項８】
前記処理は、文字コード変換処理、コード削除処理、全角／半角変換処理、コード修正処理、コード挿入処理、桁揃え処理の少なくともいずれかを含むことを特徴とする請求項１乃至７のいずれか１項に記載の分析システム。
【請求項９】
蓄積されたデータに対して予め設定されたルールに従った処理を行って分析に適したデータとする分析システムの制御方法であって、
前記蓄積されたデータに対し、前記ルールに従った判定条件を用いて前記処理を実行するか否かを判定する判定ステップと、
前記判定ステップにより前記処理を実行すると判定された場合に、前記データに対して前記処理を行う処理ステップと、
外部システムへのアクセスを含むロジックを実行する実行ステップと、を有し、
前記ルールに前記ロジックの指定を含む判定条件が設定されている場合には、該ロジックを前記実行ステップで実行し、前記判定ステップでは、該実行の結果に基づいて、前記判定を行うことを特徴とする分析システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ分析に必要な前処理を実行する分析システムの制御に関する。
【背景技術】
【０００２】
現在、市場で稼働する大量のデバイスの情報をサーバ上に収集、蓄積することが行われている。その目的は、蓄積したデータを集計、分析することで、デバイスの品質向上や、ユーザビリティの向上、さらには故障予測などを行うためである。ここでいうデバイスとは、ＭＦＰ（ＭｕｌｔｉＦｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）や、プリンタ、携帯電話、スマートフォン、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）など多岐にわたる。また、デバイスから収集したデータだけでなく、例えばデバイスの修理などのサポートのためのサービスマンの出動履歴データや、コールセンターへのクレーム情報なども分析対象となっている。このように、分析対象のデータのサイズや種別はますます多様化、大規模化している。
【０００３】
このようなデータを効率的に分析するために、蓄積したデータに対して前処理を行うことが一般的となっている。前処理とは、データに含まれる不正なデータの除去、文字コード補正、符号の付与、正規化、フォーマットの統一などのことである。
【０００４】
従来の前処理方法として、予め定義されたルールに従って前処理を施すものがある。特許文献１では、ルールに従ってある項目が条件を満たすかどうかによって前処理を適用し、適用結果をユーザに提示する技術が示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−１４１８４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、特許文献１に記載の技術では、処理対象のデータに基づいて前処理するべきか否かを判定する構成であるため、より柔軟な条件で前処理するべきか否かを判定することはできなかった。すなわち、従来では、処理対象のデータ外の情報を用いて前処理の判定を行うことができなかった。例えば、外部システムへ問い合わせた結果に基づいて前処理するべきか否かを判定することができないなどの課題があった。
【０００７】
サービスマンの出動履歴データや、コールセンターへのクレーム情報などは外部システムに登録されているため、従来技術では、例えば、前処理対象のデータがサービスマンによるパーツ交換時点より前に生成されたデータであるか等により前処理するべきか判定することができなかった。このため、従来では、データ分析に必要な前処理を十分に行うことができない場合があった。
【０００８】
本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、処理対象のデータ外の情報を用いて前処理の判定を行うことができ、複雑、柔軟な前処理の実行判定を行うことを可能にする仕組みを提供することである。
【課題を解決するための手段】
【０００９】
本発明は、蓄積されたデータに対して予め設定されたルールに従った処理を行って分析に適したデータとする分析システムであって、前記蓄積されたデータに対し、前記ルールに従った判定条件を用いて前記処理を実行するか否かを判定する判定手段と、前記判定手段により前記処理を実行すると判定された場合に、前記データに対して前記処理を行う処理手段と、外部システムへのアクセスを含むロジックを実行する実行手段と、を有し、前記判定手段は、前記ルールに前記ロジックの指定を含む判定条件が設定されている場合には、該ロジックを前記実行手段に実行させ、該実行の結果に基づいて、前記判定を行うことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、処理対象のデータ外の情報を用いて前処理の判定を行うことができ、複雑、柔軟な前処理の実行判定を行うことが可能になる。
【図面の簡単な説明】
【００１１】
【図１】本実施例の分析システムの構成図
【図２】サーバ、クライアントコンピュータのハードウェア構成図
【図３】前処理サーバのソフトウェア構成図
【図４】判定ロジックのソフトウェア構成図
【図５】判定ロジックＡのソフトウェア構成図
【図６】判定ロジックＢのソフトウェア構成図
【図７】判定ロジックＣのソフトウェア構成図
【図８】データ蓄積サーバのソフトウェア構成図
【図９】前処理サーバの前処理を例示するフローチャート
【図１０】判定ロジックＡの処理を例示するフローチャート
【図１１】判定ロジックＢの処理を例示するフローチャート
【図１２】判定ロジックＣの処理を例示するフローチャート
【図１３】前処理サーバへの前処理ルールの追加画面を例示する図
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための形態について図面を用いて説明する。
【実施例１】
【００１３】
＜システム構成＞
図１は、本発明の一実施例を示す分析システムの構成を例示する図である。
図１において、１００はインターネットを表わしている。以下に説明する各サーバ１０１〜１０６や、デバイス１０７、クライアントコンピュータ１０８は、インターネット１００を介して相互に接続されている。なお、インターネット１００は、インターネットに限定されず、企業内ネットワーク（イントラネット）等の他のネットワークであってもよい。
【００１４】
収集サーバ１０３は、市場で稼働するデバイス１０７から、デバイス１０７に関わるデータを受け付ける。ここでいうデバイスとは、例えば、ＭＦＰ（ＭｕｌｔｉＦｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）や、プリンタ、携帯電話、スマートフォン、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）のことであるが、これに限定されるものではなく、その他のネットワーク機器であってもよい。また、デバイス１０７に関わるデータとは、例えばデバイス１０７内で生成されたアラーム履歴、ジャム履歴、エラー履歴などのログデータや、デバイス１０７が記録した温度、湿度、場所などのデータであるが、その他のデータを含んでいてもよい。
【００１５】
なお、図１においては省略のために１台のデバイス１０７を記載しているが、実際は多種多様な多数のデバイスが、インターネット１００等を介してデバイスデータ収集サーバ１０３（以下、収集サーバ１０３）と接続されている。
【００１６】
収集サーバ１０３は、デバイス１０７の情報を収集するためのサーバである。データ蓄積サーバ１０２は、収集サーバ１０３が収集したデータを蓄積するためのサーバである。
【００１７】
前処理サーバ１０１は、データ蓄積サーバ１０２に蓄積された元データを、分析に適したデータに前処理する。また、前処理サーバ１０１は、前処理を施した処理後データをデータ蓄積サーバ１０２に保存する。前処理サーバ１０１は、ＦＷ情報管理サーバ１０４や、出動履歴ＤＢ１０５、デバイスマスタＤＢ１０６に対して問い合わせを行い、前処理を施すべきデータに適切に前処理を施すことができる。この結果、ユーザは、データ蓄積サーバ１０２から処理後のデータを取得して、クライアントコンピュータ１０８を用いて効率的なデータ分析を行うことができるようになる。
【００１８】
上述のように、データ蓄積サーバ１０２は、収集サーバ１０３から取得した元データと、前処理サーバ１０１が元データに対して前処理を実施した結果の処理後データを保持する。また、データ蓄積サーバ１０２は、処理後データをクライアントコンピュータ１０８に対して公開する。一般的に、データに対する分析は、過去のデータや、長期間のデータに対して行う可能性があるため、データ蓄積サーバ１０２においてはデータの破棄は積極的に行われない。一方、収集サーバ１０３は、市場におけるデバイス１０７の情報を収集し、把握するためのものであるから、一定期間が経過したデータに関しては破棄する。そのため、定期的にデータ蓄積サーバ１０２上に収集サーバ１０３のデータが移動、または複製されることが望ましい。なお、収集サーバ１０３と、データ蓄積サーバ１０２が同一のサーバとして運用される場合は、データの移動や複製は不要である。
【００１９】
ファームウェア情報管理サーバ１０４（以下、ＦＷ情報管理サーバ１０４）は、デバイス１０７のファームウェア更新情報を管理しているサーバである。
出動履歴ＤＢ１０５は、サービスマンの出動履歴を管理するデータベースである。サービスマンは、例えばトナー交換、修理、定期メンテナンスのために出動するが、その履歴を出動履歴ＤＢ１０５が管理する。
【００２０】
デバイスマスタＤＢ１０６は、デバイス名、生産日時、機種出荷開始日付、パーツ名、オプション名などの情報を保持するデータベースである。これらの情報は、新機種が発売されるたびに、管理者により更新される。また、デバイス１０７が生産されるたびに、該精算されたデバイス１０７の情報が、デバイスマスタＤＢ１０６に登録される。
【００２１】
クライアントコンピュータ１０８は、ユーザがデータに対する集計、分析、可視化を行う端末を表わしている。近年、集計、分析、可視化を行うアプリケーションは、ＢＩ（Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｒｉｇｅｎｃｅ）ツールと呼ばれており、ＢＩツールをクライアントコンピュータ１０８にインストールして利用することが一般的である。図１では、クライアントコンピュータ１０８をユーザが直接利用するように図示しているが、クライアントコンピュータ１０８をサーバとして利用して、ユーザが他の端末からクライアントコンピュータ１０８に接続することで利用する形態であってもよい。
【００２２】
なお、図１では、サーバ１０１〜１０６は、物理的に別々のサーバとして記載しているが、サーバ１０１〜１０６の一部又は全てを同一の物理サーバ内にサーバ機能として配置してもよい。
【００２３】
＜ハードウェア構成＞
図２は、前処理サーバ１０１、データ蓄積サーバ１０２、収集サーバ１０３、ＦＷ情報管理サーバ１０４、出動履歴ＤＢ１０５、デバイスマスタＤＢ１０６、クライアントコンピュータ１０８のハードウェア構成を例示する図である。なお、サーバ１０１〜１０６、クライアントコンピュータ１０８としては、一般的な情報処理装置を適用可能である。
【００２４】
図２において、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０２は、装置全体の制御を行う。ＣＰＵ２０２は、ＲＯＭ２０４に格納されているプログラムや、ハードディスク（ＨＤＤ）２０５等に格納されているアプリケーションプログラム、ＯＳ（オペレーティングシステム）等を実行し、ＲＡＭ（Ｒａｎｄａｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。
【００２５】
ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０４は記憶部であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は、一時記憶部であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は、外部記憶部の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、関連プログラム等を格納している。
【００２６】
ディスプレイ２０６は表示部であり、キーボード２０７から入力したコマンド等を表示したりするものである。インタフェース２０８は、外部装置Ｉ／Ｆであり、プリンタ、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は、指示入力部である。システムバス２０１は、装置内におけるデータの流れを司るものである。
【００２７】
ネットワークインタフェースカード（ＮＩＣ）２０９は、不図示のＬＡＮ、インターネット１００を介して外部装置とのデータのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。
【００２８】
＜前処理サーバ１０１のソフトウェア構成＞
図３は、前処理サーバ１０１の提供する機能モジュールを説明するためのソフトウェアブロック図である。図３に示す機能モジュール３０１〜３０８は、ソフトウェアとして実装されるものであり、前処理サーバ１０１のＣＰＵ２０２が、ＨＤＤ２０５等に格納されたプログラムを読み出して実行することにより機能する。図３に示す機能モジュール３０１〜３０８は、必要に応じてデータを前処理サーバ１０１のＲＡＭ２０３やＨＤＤ２０５に格納する。
【００２９】
制御部３０１は、以下に説明する機能モジュール３０２〜３０８を呼び出して前処理を実行するメイン実行部である。
【００３０】
ルール管理部３０２は、前処理の実行を制御するための前処理ルールを管理する。ルール管理部３０２は、データベースまたはＸＭＬなどのテキストファイルとして前処理ルールを、前処理サーバ１０１のＨＤＤ２０５等に保持する。ルール管理部３０２で管理する前処理ルールについての説明は、後述する表１を用いて詳述する。
【００３１】
データ読込部３０３は、前処理対象のデータをデータ蓄積サーバ１０２から読み込む機能を提供する。データ蓄積サーバ１０２は、ＨＴＴＰ、ＦＴＰ，一般的なデータベース接続方式などの１つ以上のデータ公開方式を有している。データ読込部３０３は、データ蓄積サーバ１０２の公開方式に合わせてデータを読み込み、一時的に中間データ管理部３０５に保存する。
【００３２】
データ保存部３０４は、処理後データをデータ蓄積サーバ１０２に保存するための機能を有する。データ読込部３０３と同様に、データ蓄積サーバ１０２の公開方式に合わせて処理後のデータを保存する。
中間データ管理部３０５は、前処理の途中のデータを保存するための記憶領域であり、例えば前処理サーバ１０１のＨＤＤ２０５内の記憶領域である。
【００３３】
判定ロジック管理部３０６は、判定ロジックに関する管理情報を保持する。判定ロジック管理部３０６は、データベースまたはＸＭＬなどのテキストファイルとして判定ロジックに関する情報を、前処理サーバ１０１のＨＤＤ２０５等に保持する。判定ロジック管理部３０６で管理する判定ロジックの情報についての説明は、後述する表２を用いて詳述する。
【００３４】
判定ロジック格納部３０７は、判定ロジックの実行ファイルを格納するための記憶領域であり、例えば前処理サーバ１０１のＨＤＤ２０５内の記憶領域である。判定ロジックは、例えばスクリプトや実行ファイル（ｅｘｅ、ｊａｒ）などのファイル形式であるがこれに限定しない。前処理サーバ１０１は１つ以上の判定ロジックを有している。それぞれの判定ロジックは、例えば、ＦＷ情報管理サーバ１０４、出動履歴ＤＢ１０５、デバイスマスタＤＢ１０６等の外部システムへのアクセス（例えば問い合わせ）を含むロジックであり、独自、複雑、柔軟な前処理の実行判定を行うことが可能となる。それぞれの判定ロジックの詳細は、後述する図４〜図７を用いて説明する。
【００３５】
前処理実行部３０８は、前処理を実行する。前処理とは、例えば文字コード変換処理、改行コード削除処理、全角／半角変換処理、コード挿入処理（例えばｎｕｌｌ値挿入処理）、コード修正処理（例えばＪＡＭコード修正処理）、桁揃え処理などの処理であるが、これに限定されるものではない。
【００３６】
【表１】
2016051426.tif 000003
【００３７】
表１に前処理サーバ１０１のルール管理部３０２で管理される前処理ルールの例を示す。
表示１において、「ファイル名ルール」列は、ファイル名の該否判定ルールである。前処理サーバ１０１の制御部３０１は、データ読込部３０３を介してデータ蓄積サーバ１０２に保存されたファイルのファイル名を取得し、前処理ルールを特定する。例えば、ファイル名が"DEVICE_SMART_.*.csv"で表現されるファイルに対しては、表１の１行目、２行目の前処理ルールを適用する。なお、後述の「簡易判定列」、「簡易判定条件」、「判定ロジックＩＤ」を指定せず、ファイル名の該否判定ルールだけを元に前処理を適用してもよい。例えば、表１の１行目は、"DEVICE_SMART_.*.csv"で表現されるファイルは、全ての列（ALL）に対して「文字コード変換」を施すという前処理ルールであり、「簡易判定列」、「簡易判定条件」、「判定ロジックＩＤ」は指定されていない。
【００３８】
デバイスデータ収集サーバ１０３により収集されたデータの種類毎にファイル名ルールを設け、該ファイル名ルールに基づいたファイル名を付けて収集データを、データ蓄積サーバ１０２に蓄積しておくことにより、蓄積されるデータの種類ごとに前処理ルールを設定することができる。
【００３９】
「簡易判定列」列は、簡易な判定を行うための判定基準となる列を示す。
「簡易判定条件」列は、「簡易判定列」列の値に対して適用する比較演算子と比較対象の値を示す。なお、後述の「判定ロジックＩＤ」を指定せず、「簡易判定列」、「簡易判定条件」だけを指定して、前処理を実施してもよい。例えば、表１の２行目は、２列目（データ送信日時）が"ｘ＜２０１５／０８／０１（２０１５年８月１日以前）"のデータの"８列目"の"改行コード削除（改行コードをすべて削除する）"という前処理ルールである。なお、表１の２行目のルールでは、「簡易判定列」、「簡易判定条件」は指定され、「判定ロジックＩＤ」は指定されていない。
【００４０】
「判定ロジックＩＤ」列は、判定ロジックのＩＤである。
「判定引数」列は、判定ロジックに引き渡す引数である。
「判定戻り値」列は、期待される判定ロジックからの戻り値である。「判定戻り値」列に指定された値と、判定ロジックからの戻り値が一致した場合に、前処理が実施される。
【００４１】
「処理対象列」列は、前処理が施される列番号である。なお、「処理対象列」列に"ＡＬＬ"と指定された場合は、全ての列に対して処理が適用される。
「処理ＩＤ」列は、前処理のＩＤである。「処理ＩＤ」列には、前処理サーバ１０１の制御部が実行可能な前処理のＩＤが指定される。「処理順」列は、前処理の順序である。「処理順」序列によって、同じファイルに対して複数の前処理を順次実行する際の順序が決定される。
【００４２】
【表２】
2016051426.tif 000004
【００４３】
表２に、前処理サーバ１０１の判定ロジック管理部３０６で管理される判定ロジックの管理情報の例を示す。
表２において、「判定ロジックＩＤ」列は、判定ロジックのＩＤを表す。
「実行ファイルパス」列は、判定ロジックの実行ファイルの所在を表わす文字列である。
「戻り値型」列は、判定ロジックの実行結果として返却される戻り値の型を表す。
「引数数」列は、判定ロジックに引き渡すことが可能な引数の数を表す。
「説明」列は、判定ロジックの判定内容を示す文字列であるが、これは判定ロジック管理部３０６の管理者が判定ロジックを管理するために利用するものであり、前処理サーバ１０１は参照しない。
【００４４】
＜判定ロジックの構成＞
上述したように、前処理サーバ１０１は、１つ以上の判定ロジックを有しており、それぞれの判定ロジックは、独自の前処理の実行判定を行うことが可能である。
各判定ロジックは、スクリプトや実行ファイル（ｅｘｅ、ｊａｒ）などのファイル形式であり、任意のプログラム言語として実装される。特に、前処理サーバ１０１のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のサポートするプログラム言語として実装されることが望ましい。各判定ロジックは、前処理サーバ１０１のＣＰＵ２０２が、ＨＤＤ２０５等にファイル形式で格納された判定ロジックに対応するプログラムを読み出して実行することにより機能するものであり、必要に応じてデータを前処理サーバ１０１のＲＡＭ２０３やＨＤＤ２０５に格納する。前処理サーバ１０１は、判定ロジックを前処理ルールに応じて呼び出すことで、柔軟な前処理の実行判定を可能としている。また、判定ロジックはプログラム可能であるため、外部のシステムへのアクセスを行った結果をもとに、前処理判定を行うなどの高度な判定処理を組み込むことが可能である。
【００４５】
まず、図４を用いて各判定ロジックの共通の機能モジュールを説明し、続いて図５、図６、図７を用いて具体的な判定ロジックＡ、Ｂ、Ｃについて説明する。
【００４６】
図４は、判定ロジック４００の機能モジュールを説明するためのソフトウェアブロック図である。
判定ロジック４００において、判定要求受付部４０１は、前処理サーバ１０１の制御部３０１から判定要求を受け付ける。判定要求には、判定の基準となる１つ以上の引数を含めることが可能であり、判定ロジックを複数の前処理の判定のために利用することができる。判定ロジックは、受け取った引数と、後述の外部問い合わせ部４０２の戻り値から、判定戻り値を生成する。
【００４７】
外部問い合わせ部４０２は、判定に必要となるデータを外部のシステムに問い合わせて取得するためのインタフェースである。外部問い合わせ部４０２は、外部のシステムの提供するインタフェースからデータを取得可能であればどのような形態であってもよい。例えば、外部問い合わせ部４０２を、Ｗｅｂサービスのクライアントモジュールや、データベース接続のドライバとするが、これに限定されるものではない。
【００４８】
判定戻り値生成部４０３は、判定要求受付部４０１で受け取った引数と、外部問い合わせ部４０２で取得したデータをもとに判定戻り値を生成する。
判定戻り値返却部４０４は、前処理サーバ１０１の制御部３０１に、判定戻り値生成部４０３が生成した戻り値を返却する。
【００４９】
以上のような構成により、判定ロジックは、所定の情報の真偽を外部システムに問い合わせて取得する処理や、所定の情報を外部システムに問い合わせて取得する処理等を実現することができる。
【００５０】
図５は、判定ロジックＡ５００の提供する機能モジュールを説明するためのソフトウェアブロック図である。
判定ロジックＡ５００は、ＦＷ情報管理サーバ１０４に問い合わせて、前処理サーバ１０１の制御部３０１から引き渡された特定のファームウェアバージョンであるかどうかを判定するための判定プログラムである。本実施例においては、ＦＷ情報管理サーバ１０４は、ファームウェア更新情報を、ＲＥＳＴ形式のＷｅｂサービスとして公開しているものとして説明する。
【００５１】
判定要求受付部５０１は、下記のようにファームウェア該当判定を受け付ける。
"confirm_firmware.jar 2.2 HEOGMXWTJW 20140101 9:35"
なお、"confirm_firmware.jar"とは、判定ロジックＡ５００のファイル名である。
"2.2"とは、ファームウェアバージョンである。
"HEOGMXWTJW"とは、デバイス１０７を一意に識別するデバイスＩＤである。
"20140101 9:35"は、「２０１４年０１月０１日０９時３５分」という日時分を表す。
【００５２】
外部問い合わせ部５０２は、ＦＷ情報管理サーバ１０４にファームウェアバージョンを問い合わせる。このとき、下記のようなリクエストを生成する。
"https://confirm.firmware.service.jp?/machine_id= HEOGMXWTJW &date=201401010935"
【００５３】
上記のリクエストは、デバイスＩＤが"HEOGMXWTJW"であるデバイス１０７の、"２０１４年３月１２日"時点でのファームウェアを問い合わせるためのリクエストである。上記のリクエストに対して、ＦＷ情報管理サーバ１０４は、ファームウェア番号を返却する。
【００５４】
判定戻り値生成部５０３は、外部問い合わせ部５０２によって取得したファームウェアバージョンと、判定要求受付部５０１で引数として受け付けたファームウェアバージョンを比較して、判定戻り値を生成する。上記のファームウェア該当判定要求の場合、ファームウェアバージョンが"2.2"だった場合に"真"、そうでない場合に"偽"の判定戻り値を生成する。
判定戻り値返却部５０４は、判定戻り値生成部５０３で判定した結果を前処理サーバ１０１の制御部３０１に返却する。
【００５５】
なお、判定要求受付部５０１、外部問い合わせ部５０２、判定戻り値生成部５０３、判定戻り値返却部５０４は、それぞれ判定ロジック４００の判定要求受付部４０１、外部問い合わせ部４０２、判定戻り値生成部４０３、判定戻り値返却部４０４に相当する。
【００５６】
図６は、判定ロジックＢ６００の提供する機能モジュールを説明するためのソフトウェアブロック図である。
判定ロジックＢ６００は、出動履歴ＤＢ１０５に問い合わせて、前処理サーバ１０１の制御部３０１から引き渡されたパーツがすでに交換済であるかどうかを判定するための判定プログラムである。本実施例においては、出動履歴ＤＢ１０５は、パーツ交換履歴が保存されている出動履歴を、データベースとして公開しているものとして説明する。
【００５７】
判定要求受付部６０１は、下記のようにパーツ交換判定を受け付ける。
"check_exchange.jar 917JIEOQRT ADF 20140101 9:02"
なお、"check_exchange.jar"とは、判定ロジックＢ６００のファイル名である。
"917JIEOQRT"とは、デバイス１０７を一意に識別するデバイスＩＤである。
"ADF"とは、パーツＩＤである。
"20140101 9:02"とは、「２０１４年０１月０１日０９時０２分」という日時分を表す。
【００５８】
外部問い合わせ部６０２は、出動履歴ＤＢ１０５にパーツ交換履歴を問い合わせる。このとき、下記のようなリクエストを生成する。
"SELECT * FROM EXCHANGE_HISTORY WHERE DeviceId = "917JIEOQRT" AND PartsId = "ADF" AND Date ＜ "201401010902""
上記のリクエストは、デバイスＩＤが"917JIEOQRT"であるデバイス１０７の、２０１４年０１月０１日０９時０２分以前のパーツ交換履歴を問い合わせるＳＱＬ文である。
【００５９】
判定戻り値生成部６０３は、外部問い合わせ部６０２の問い合わせの結果、パーツ交換履歴が取得できた場合に"真"、そうでない場合に"偽"の判定戻り値を生成する。
判定戻り値返却部６０４は、判定戻り値生成部６０３で判定した結果を前処理サーバ１０１の制御部３０１に返却する。
【００６０】
なお、判定要求受付部６０１、外部問い合わせ部６０２、判定戻り値生成部６０３、判定戻り値返却部６０４は、それぞれ判定ロジック４００の判定要求受付部４０１、外部問い合わせ部４０２、判定戻り値生成部４０３、判定戻り値返却部４０４に相当する。
【００６１】
図７は、判定ロジックＣ７００の提供する機能モジュールを説明するためのソフトウェアブロック図である。
判定ロジックＣ７００は、デバイスマスタＤＢ１０６に問い合わせて、デバイス１０７の生産日時を返却する。本実施例においては、デバイスマスタＤＢ１０６は、市場で稼働するデバイスに関する情報を管理している、デバイスマスタデータを、データベースとして公開しているものとして説明する。
【００６２】
判定要求受付部７０１は、下記のように生産日時の問い合わせを受け付ける。
"confirm_manifactured_date.jar  UPJNDSD0RD"
なお、"confirm_manifactured_date.jar"とは、判定ロジックＣ７００のファイル名である。
"UPJNDSD0RD"とは、デバイス１０７を一意に識別するデバイスＩＤである。
【００６３】
外部問い合わせ部７０２は、デバイスマスタＤＢ１０６に生産日時を問い合わせる。このとき、下記のようなリクエストを生成する。
"SELECT Manifactured_Date FROM DEVICE_MASTER WHERE DeviceId = "UPJNDSD0RD""
上記のリクエストは、デバイスＩＤが"UPJNDSD0RD"であるデバイス１０７の、生産日時を取得するＳＱＬ文である。
【００６４】
判定戻り値生成部７０３は、外部問い合わせ部７０２の問い合わせの結果をそのまま判定戻り値とする。
判定戻り値返却部７０４は、判定戻り値生成部７０３で生成した生産日時を前処理サーバ１０１の制御部３０１に返却する。
【００６５】
なお、判定要求受付部７０１、外部問い合わせ部７０２、判定戻り値生成部７０３、判定戻り値返却部７０４は、それぞれ判定ロジック４００の判定要求受付部４０１、外部問い合わせ部４０２、判定戻り値生成部４０３、判定戻り値返却部４０４に相当する。
【００６６】
＜データ蓄積サーバ１０２のソフトウェア構成＞
図８は、データ蓄積サーバ１０２の提供する機能モジュールを説明するためのソフトウェアブロック図である。図８に示す機能モジュール８０１〜８０３は、ソフトウェアとして実装されるものであり、データ蓄積サーバ１０２のＣＰＵ２０２が、ＨＤＤ２０５等に格納されたプログラムを読み出して実行することにより機能する。図８に示す機能モジュール８０１〜８０３は、必要に応じてデータをデータ蓄積サーバ１０２のＲＡＭ２０３やＨＤＤ２０５に格納する。
【００６７】
元データ取得部８０１は、収集サーバ１０３から元データを取得する。収集サーバ１０３は、ＨＴＴＰ、ＦＴＰ、一般的なデータベース接続方式などの１つ以上のデータ公開方式を有している。元データ取得部８０１は、収集サーバ１０３の公開方式に合わせてデータを取得し、取得データ格納部８０２に保存する。
【００６８】
取得データ格納部８０２は、収集サーバ１０３から取得した元データを格納するための記憶領域である。
前処理後データ格納部８０３は、前処理サーバ１０１が処理した処理後データを格納するための記憶領域である。
【００６９】
なお、取得データ格納部８０２、前処理後データ格納部８０３は、データ蓄積サーバ１０３のＨＤＤ２０５にデータを格納するファイルサーバや、データベースとするが、データを不揮発的に格納することができれば、その他のモジュールとして提供されてもよい。また、取得データ格納部８０２、前処理後データ格納部８０３は、物理的には同一の記憶領域であってもよい。
【００７０】
【表３】
2016051426.tif 000005
【００７１】
表３に、収集サーバ１０３が収集するアラーム履歴データの例を示す。
アラーム履歴とは、デバイス１０７に何らかの問題が発生した際に収集サーバ１０３に通知するアラームの履歴のことである。本実施例においては、表３で表わされるデータは"DEVICE_ALARM_*.csv"というファイル名で保存されるものとする。また、データ蓄積サーバ１０２は、収集サーバ１０３からこのデータを取得し、取得データ格納部８０２に格納する。
【００７２】
表３において、「国コード」列は、デバイス１０７が稼働している国を表わすコードである。
「発生日時分」列は、アラームが発生した日時分を表す。
「解除日時分」列は、アラームがユーザ、またはサービスマンに解除された日時分を表す。
「データ送信日時分」列は、デバイス１０７がアラーム履歴を収集サーバ１０３に送信した日時分を表す。
「機種」列は、機種を識別するためのコードである。
「機番」列は、デバイス１０７のＩＤ（識別子）である。
「アラームコード」列は、アラームの発生区分コードである。
「アラームレベル」列は、アラームの深刻さを表わす数値である。
【００７３】
表示に例示するアラーム履歴データにおいて、「国コード」列、「機種」列の２行目、４行目に"＜LF＞"という改行コードが含まれている。これは、不正な改行コードが含まれている一例である。前処理サーバ１０１は、この不正な改行コードを取り除くという前処理を実行する。
【００７４】
【表４】
2016051426.tif 000006
【００７５】
表４に、前処理サーバ１０１が前処理を実施した結果のアラーム履歴データの例を示す。
表４に示すアラーム履歴データは、表３に示したアラーム履歴データを、前処理サーバ１０１が前処理した結果に対応する。
表４に示すアラーム履歴データは、表３と比較して、２、５行目から、"＜LF＞"という不正な改行コードが取り除かれていることがわかる。このような不正な改行コードの混入は、デバイス１０７内でデータを生成する際のソフトウェアバグや、デバイス１０７、収集サーバ１０３のＯＳの不一致などにより発生する。
【００７６】
不正な改行コードが混入した場合、例えば、クライアントコンピュータ１０８でデータを分析しようとした際に、データを正しく読み込めない問題が発生する。前処理サーバ１０１によって、このような不正な改行コードを取り除くことで、クライアントコンピュータ１０８でデータを正しく読み込むことが可能である。
【００７７】
【表５】
2016051426.tif 000007
【００７８】
表５に、収集サーバ１０３が収集するデバイス内環境データの例を示す。
本実施例においては、表５で表わされるデータは、"DEVICE_ENVIRONMENT_*.csv"というファイル名で保存されるものとする。データ蓄積サーバ１０２は、収集サーバ１０３からこのデータを取得し、取得データ格納部８０２に格納する。
【００７９】
表５において、「国コード」列は、デバイス１０７が稼働している国を表わすコードである。
「データ取得日時分」列は、機内温度、機内湿度、定着ローラ表面温度を測定、記録した日時分を表す。
「データ送信日時分」列は、デバイス１０７がデバイス内環境データを収集サーバ１０３に送信した日時分を表す。
「機種」列は、機種を識別するためのコードである。
「機番」列は、デバイス１０７のＩＤ（識別子）である。
「機内温度」列は、デバイスの内部の温度である。
「機内湿度」列は、デバイスの内部の湿度である。
「定着ローラ表面温度」列は、デバイス内の定着ローラの表面温度を表す。
【００８０】
上記のデバイス内環境データにおいて、２、６行目の「定着ローラ表面温度」列の値が異常に高温となっている。これは、デバイス１０７内の温度計測機器が故障しており、サービスマンにパーツ交換が施されていないため不正なデータとなっている一例である。前処理サーバ１０１は、この不正なデータをすべてｎｕｌｌ値に変換するという前処理を実行する。
【００８１】
【表６】
2016051426.tif 000008
【００８２】
表６に、前処理サーバ１０１が前処理を実施した結果のデバイス内環境データの例を示す。
表６に示すデバイス内環境データは、表５に示したデバイス内環境データを、前処理サーバ１０１が前処理した結果に対応する。
表６に示すデバイス内環境データは、表５と比較して、２、７行目の、「機内温度」列、「機内湿度」列、「定着ローラ表面温度」列のデータがｎｕｌｌになっていることがわかる。
【００８３】
上記のような異常な値がデータに混入していると、クライアントコンピュータ１０８での分析の際に、正しい分析結果が得られない。例えば、統計分析による外れ値検出を行うことができない。そのため、前処理サーバ１０１による前処理によって、予めｎｕｌｌ値としておくことによって、クライアントコンピュータ１０８での分析対象から除外することができ、分析結果の精度向上が期待できる。
【００８４】
【表７】
2016051426.tif 000009
【００８５】
表７に、収集サーバ１０３が収集する紙詰まり履歴データの一例を示す。
本実施例においては、表７で表わされるデータは、"DEVICE_JAM_*.csv"というファイル名で保存される。また、データ蓄積サーバ１０２は収集サーバ１０３からこのデータを取得し、取得データ格納部８０２に格納する。
【００８６】
表７において、「国コード」列は、デバイス１０７が稼働している国を表わすコードである。「発生日時分」列は、紙詰まりが発生した日時分を表す。
「解除日時分」列は、紙詰まりがユーザ、またはサービスマンに解除された日時分を表す。
「データ送信日時分」列は、デバイス１０７が紙詰まり履歴を収集サーバ１０３に送信した日時分を表す。
「機種」列は、機種を識別するためのコードである。
「機番」列は、デバイス１０７のＩＤ（識別子）である。
「発生区分」列は、その紙詰まりが発生した要因を大まかに区分した発生区分コードである。
「ＪＡＭコード」列は、紙詰まりの詳細な発生区分コードである。
「用紙サイズ」列は、紙詰まりを起こした紙のサイズを表わすコードである。
【００８７】
上記の紙詰まり履歴データにおいて、２、５行目の「ＪＡＭコード」列のコードだけが"JAM"という文字列から始まっていないことが分かる。これは、ＪＡＭコードに不正なコードが混在している一例である。前処理サーバ１０１は、この不正なＪＡＭコードを適正なＪＡＭコードに変換するという前処理を実行する。
【００８８】
【表８】
2016051426.tif 000010
【００８９】
表８に、前処理サーバ１０１が前処理を実施した結果のＪＡＭ履歴データの例を示す。
表８に示すＪＡＭ履歴データは、表７に示したＪＡＭ履歴データを、前処理サーバ１０１が前処理した結果に対応する。
表８に示すＪＡＭ履歴データは、表７と比較して、２、５行目の「ＪＡＭコード」列のデータがすべて"JAM-"という文字列から始まるコードに変換されていることがわかる。
【００９０】
このように不正なコードが混入することは、デバイス１０７上でコードを生成する際の仕様が統一されていない場合や、ソフトウェアバグによって発生する。コードが不正な場合、ユーザがクライアントコンピュータ１０８で分析を行う際に、正しく分析対象のレコードを抽出できないため、分析結果の精度が低下してしまう。前処理サーバ１０１の前処理によって予めコードを修正することによって、分析結果の精度向上が可能である。
【００９１】
＜前処理サーバ１０１による前処理＞
次に、前処理サーバ１０１による前処理の実行について、図９のフローチャートを用いて説明する。
図９は、前処理サーバ１０１による前処理を例示するフローチャートである。このフローチャートに示す各ステップの処理は、前処理サーバ１０１のＣＰＵ２０２が、ＨＤＤ２０５等に格納されたプログラムを読み出して実行することにより実現されるものである。
【００９２】
ステップＳ９０１において、前処理サーバ１０１の制御部３０１は、一定間隔で、Ｓ９０２以降の処理を開始するように制御する。一定間隔で実行する機能は、例えば、前処理サーバ１０１のＯＳの提供するスケジュール実行機能を利用する。
【００９３】
ステップＳ９０２では、制御部３０１は、データ読込部３０３を呼び出して、データ蓄積サーバ１０２の取得データ格納部８０２に新規データが格納されたかどうかを判断する。
そして、新規データが格納されていないと判断した場合（Ｓ９０２でＮｏの場合）、制御部３０１は、Ｓ９１９へ処理を分岐させ、本フローチャートの処理を終了する。
【００９４】
一方、新規データが格納されていると判断した場合（Ｓ９０２でＹｅｓの場合）、制御部３０１は、新規データ（新規ファイル）を取得し、中間データ管理部３０５に格納し、Ｓ９０３へ処理を分岐させる。
ステップＳ９０３では、制御部３０１は、上記Ｓ９０２で取得した全ての新規ファイルに対して、Ｓ９０３〜Ｓ９１８に示すループ処理を実行するように制御する。制御部３０１は、上記Ｓ９０２で取得した新規ファイルから未処理の新規ファイルを１つ取得し（現在のファイル）、Ｓ９０４に処理を進める。
【００９５】
ステップＳ９０４では、制御部３０１は、現在のファイルのファイル名から前処理ルールを取得する。例えば、ファイル名が"DEVICE_SMART_*.csv"で表現されるファイル名であれば、表１の中で１、２行目が前処理ルールとして取得される。
【００９６】
次に、ステップＳ９０５において、制御部３０１は、上記Ｓ９０４で取得した全ての前処理ルールに対して、Ｓ９０５〜Ｓ９１６に示すループ処理を実行するように制御する。制御部３０１は、未処理の前処理ルールを１つ取得し（現在の前処理ルール）、Ｓ９０６に処理を進める。
【００９７】
ステップＳ９０６では、制御部３０１は、現在のファイル内の全ての行に対して、Ｓ９０６〜Ｓ９１４に示すループ処理を実行するように制御する。制御部３０１は、現在のファイル内から未処理の行を１つ取得し（現在の行）、Ｓ９０７に処理を進める。
【００９８】
ステップＳ９０７では、制御部３０１は、現在の前処理ルールに簡易判定指定があるか否かを判断する。簡易判定とは、表１で示される前処理ルール内で表現可能な簡易な判定のことであり、表１の「簡易判定」列、「簡易判定条件」列で指定されている。例えば、表１の２行目の前処理ルールにおいては、現在の行の２列目（データ送信日時を表わす）が、「２０１５年８月１日より前」であるかという判定を行う簡易判定が指定されている。
【００９９】
そして、簡易判定指定がないと判断した場合（Ｓ９０７でＮｏの場合）、制御部３０１は、Ｓ９１０へ処理を分岐させる。
一方、簡易判定指定があると判断した場合（Ｓ９０７でＹｅｓの場合）、制御部３０１は、Ｓ９０８へ処理を進める。
ステップＳ９０８では、制御部３０１は、簡易判定を実施する。
【０１００】
次に、ステップＳ９０９において、制御部３０１は、簡易判定結果が"真"であるか否かを判断する。
そして、簡易判定結果が"偽"であると判断した場合（Ｓ９０９でＮｏの場合）、制御部３０１は、Ｓ９１４へ処理を分岐させる。ここで、Ｓ９１４への処理の分岐は、この行に対しての前処理は実施しないということと同義である。
【０１０１】
一方、簡易判定結果が"真"であると判断した場合（Ｓ９０９でＹｅｓの場合）、制御部３０１は、Ｓ９１０に処理を進める。
ステップＳ９１０では、制御部３０１は、現在の前処理ルールに判定ロジック指定があるか否かを判定する。
【０１０２】
そして、現在の前処理ルールに判定ロジック指定がないと判断した場合（Ｓ９１０でＮｏの場合）、制御部３０１は、Ｓ９１３に処理を分岐させる。
一方、現在の前処理ルールに判定ロジック指定があると判断した場合（Ｓ９１０でＹｅｓの場合）、制御部３０１は、Ｓ９１１に処理を分岐させる。
【０１０３】
ステップＳ９１１では、制御部３０１は、判定ロジックに引き渡す引数をルール管理部３０２から読み出して、現在の行に対する判定ロジックを、引数付きで実行する。判定ロジックの内部処理に関しては、それぞれの判定ロジックによって異なるため、図１０、図１１、図１２で後述するものとする。
【０１０４】
次に、ステップＳ９１２において、制御部３０１は、前処理実施判定を行う。前処理実施判定は、上記Ｓ９１１で実行した判定ロジックの戻り値と、現在の前処理ルールに指定された判定戻り値（「判定戻り値」列の値）とを比較して、一致すれば"真"、一致しなければ"偽"と判定する。
【０１０５】
そして、前処理実施判定の結果が"偽"であると判定した場合（Ｓ９１２でＮｏの場合）、制御部３０１は、Ｓ９１４に処理を分岐させる。
一方、前処理実施判定の結果が"真"であると判定した場合（Ｓ９１２でＹｅｓの場合）、制御部３０１は、Ｓ９１３に処理を分岐させる。
【０１０６】
ステップＳ９１３では、制御部３０１は、現在の前処理ルールの「処理対象列」列で指定される現在の行の列に対して、「処理ＩＤ」列で指定される前処理を適用する。例えば、「処理対象列」列に"ALL"と指定されていた場合は、現在の行の全ての列に対して、「処理ＩＤ」列で指定される前処理を適用する。そして、Ｓ９１３の後、制御部３０１は、Ｓ９１４に処理を進める。
【０１０７】
ステップＳ９１４では、制御部３０１は、現在の行が、現在のファイル内の終端行であるか否かを判断する。
そして、現在のファイル内の終端行でないと判断した場合、制御部３０１は、Ｓ９０６に処理を戻し、次の行に処理を遷移する。
一方、現在のファイル内の終端行であると判断した場合（Ｓ９１４でＹｅｓの場合）、制御部３０１は、ファイル内行ループ（Ｓ９０６〜Ｓ９１４）を抜けて、Ｓ９１５に処理を進める。
【０１０８】
ステップＳ９１５では、制御部３０１は、前処理を適用したファイルを中間データ管理部３０５に一時保存する。
次に、ステップＳ９１６において、制御部３０１は、全ての前処理ルールを実行したか否かを判断する。
【０１０９】
そして、まだ実行していない前処理ルールがあると判定した場合、制御部３０１は、Ｓ９０５に処理を戻し、次の前処理ルールに処理を遷移する。
一方、全ての前処理ルールを実行したと判定した場合、制御部３０１は、前処理ルールループ（Ｓ９０５〜Ｓ９１６）を抜けて、Ｓ９１７に処理を進める。
【０１１０】
ステップＳ９１７では、制御部３０１は、前処理を適用した現在のファイルをデータ蓄積サーバの前処理後データ格納部８０３に保存する。
次に、ステップＳ９１８において、制御部３０１は、全ての新規ファイルに対して前処理を適用したか否かを判断する。
【０１１１】
そして、まだ前処理を適用していない新規ファイルがあると判断した場合、制御部３０１は、Ｓ９０３に処理を戻し、次の新規ファイルに処理を遷移する。
一方、全ての新規ファイルに対して前処理を適用したと判断した場合、制御部３０１は、前処理ルールループ（Ｓ９０３〜Ｓ９１８）を抜けて、本フローチャートの処理を終了する。
【０１１２】
以上、説明したように、前処理サーバ１０１による前処理ルールに基づいた前処理が可能である。特に、ステップＳ９１１の判定ロジックの実行による戻り値の取得と、続くステップＳ９１２における前処理実施判定により、柔軟な前処理の実施判定を行うことが可能である。例えば、判定ロジックとして外部システムへの問い合わせができるが、その処理については、図１０、図１１、図１２を用いて詳述する。
【０１１３】
次に、判定ロジックＡ５００の前処理判定について図１０のフローチャートを用いて説明する。なお、本実施例において、判定ロジックＡ５００には、「判定ロジックＩＤ」として"confirm_firmware"が割り当てられているものとする。
図１０は、判定ロジックＡ５００の処理を例示するフローチャートである。このフローチャートに示す各ステップの処理は、前処理サーバ１０１のＣＰＵ２０２が、ＨＤＤ２０５等に格納されたプログラムを読み出して実行することにより実現されるものである。
【０１１４】
ステップＳ１００１において、判定ロジックＡ５００は、制御部３０１から判定要求受付部５０１を介してファームウェア該当判定を受け付ける。このとき、表１の「判定引数」列に指定された引数を受け取る。
【０１１５】
次に、ステップＳ１００２において、判定ロジックＡ５００は、外部問い合わせ部５０２を用いて、ＦＷ情報管理サーバ１０４にファームウェアバージョンを問い合わせる。このときの問い合わせ方法については、図５の説明で説明済である。
【０１１６】
ステップＳ１００３において、判定ロジックＡ５００は、引数として指定されたファームウェアバージョンと、ＦＷ情報管理サーバ１０４に問い合わせた結果のファームウェアが一致するかどうかを判断する。
そして、一致すると判断した場合（Ｓ１００３でＹｅｓの場合）、判定ロジックＡ５００は、Ｓ１００４に処理を分岐する。
ステップＳ１００４では、判定ロジックＡ５００の判定戻り値生成部５０３は、戻り値として"真"の値を生成し、Ｓ１００６に処理を進める。
【０１１７】
一方、一致しないと判断した場合（Ｓ１００３でＮｏの場合）、判定ロジックＡ５００は、Ｓ１００５に処理を分岐する。
ステップＳ１００５では、判定ロジックＡ５００の判定戻り値生成部５０３は、戻り値として"偽"の値を生成し、Ｓ１００６に処理を進める。
【０１１８】
ステップＳ１００６では、判定ロジックＡ５００の判定戻り値返却部５０４は、上記Ｓ１００４、または、上記Ｓ１００５で生成された戻り値を、前処理サーバ１０１の制御部３０１へ返却して、本フローチャートの処理を終了する。
【０１１９】
次に、判定ロジックＢ６００の前処理判定について図１１のフローチャートを用いて説明する。本実施例において、判定ロジックＢ６００には、「判定ロジックＩＤ」として"check_exchange"が割り当てられているものとする。
図１１は、判定ロジックＢ６００の処理を例示するフローチャートである。このフローチャートに示す各ステップの処理は、前処理サーバ１０１のＣＰＵ２０２が、ＨＤＤ２０５等に格納されたプログラムを読み出して実行することにより実現されるものである。
【０１２０】
ステップＳ１１０１において、判定ロジックＢ６００は、前処理サーバ１０１の制御部３０１から判定要求受付部６０１を介してパーツ交換判定を受け付ける。このとき、表１の「判定引数」列に指定された引数を受け取る。
【０１２１】
次に、ステップＳ１１０２において、判定ロジックＢ６００は、外部問い合わせ部６０２を用いて、出動履歴ＤＢ１０５にパーツ交換済であるかどうかを問い合わせる。このときの問い合わせ方法については、図６の説明で説明済である。
【０１２２】
次に、ステップＳ１１０３において、判定ロジックＢ６００は、上記Ｓ１１０２での問い合わせの結果、パーツ交換済であるか否かを判断する。
そして、パーツ交換済であると判断した場合（Ｓ１１０３でＹｅｓの場合）、判定ロジックＢ６００は、Ｓ１１０４へ処理を分岐させる。
ステップＳ１１０４では、判定ロジックＢ６００の判定戻り値生成部６０３は、戻り値として"真"の値を生成し、Ｓ１１０６に処理を進める。
【０１２３】
一方、パーツ交換済でないと判断した場合（Ｓ１１０３でＮｏの場合）、判定ロジックＢ６００は、Ｓ１１０５へ処理を分岐させる。
ステップＳ１１０５で、判定ロジックＢ６００の判定戻り値生成部６０３は、戻り値として"偽"の値を生成し、Ｓ１１０６に処理を進める。
【０１２４】
ステップＳ１００６では、判定ロジックＢ６００の判定戻り値返却部６０４は、上記Ｓ１１０４又はＳ１１０５で生成された戻り値を、前処理サーバ１０１の制御部３０１へ返却して、本フローチャートの処理を終了する。
【０１２５】
次に、判定ロジックＣ７００の前処理判定について図１２のフローチャートを用いて説明する。本実施例において、判定ロジックＢ６００は、「判定ロジックＩＤ」として"confirm_manifactured_date"が割り当てられているものとする。
図１２は、判定ロジックＣ７００の処理を例示するフローチャートである。このフローチャートに示す各ステップの処理は、前処理サーバ１０１のＣＰＵ２０２が、ＨＤＤ２０５等に格納されたプログラムを読み出して実行することにより実現されるものである。
【０１２６】
ステップＳ１２０１において、判定ロジックＣ７００は、前処理サーバ１０１の制御部３０１から判定要求受付部７０１を介してパーツ交換判定を受け付ける。このとき、表１の「判定引数」列に指定された引数を受け取る。
【０１２７】
次に、ステップＳ１２０２において、判定ロジックＣ７００は、外部問い合わせ部７０２を用いて、デバイスマスタＤＢ１０６にデバイス１０７の生産日時を問い合わせる。このときの問い合わせ方法については、図７の説明で説明済である。
【０１２８】
次に、ステップＳ１２０３において、判定ロジックＣ７００の判定戻り値生成部７０３は、上記Ｓ１２０２で問い合わせた生産日時をそのまま戻り値とする。
次に、ステップＳ１２０４において、判定ロジックＣ７００の判定戻り値返却部７０４は、上記Ｓ１２０３で生成した戻り値を、前処理サーバ１０１の制御部３０１へ返却して、本フローチャートの処理を終了する。
【０１２９】
＜具体例１＞
前処理サーバ１０１の前処理の一例として、アラーム履歴データの前処理における表１、表２、表３、表４の関係について説明する。なお、表３、表４で示したアラーム履歴データのファイル名は、"DEVICE_ALARM_*.csv"で表わされるものとする。
【０１３０】
表１から、このアラーム履歴データ（"DEVICE_ALARM_*.csv"）に対して、６行目の前処理が実施されることが分かる。また、「簡易判定列」列、「簡易判定条件」列にそれぞれ"5列目"、"X-5051"と指定されていることから、表３の１，２，５，７行目が前処理対象として絞り込まれる。また、「判定ロジックＩＤ」は"confirm_firmware"であることがわかる。
"confirm_firmware"は、条件を満たすファームウェアであった場合に"真"を、そうでない場合に"偽"を返却する判定ロジックＡ５００である。
【０１３１】
表１の「判定引数」には、"6 2 2.1 ＜"が指定されている。この「判定引数」について説明する。表２の「引数数」列の通り、判定ロジックＡ５００が受け付ける引数の数は"4"つである。引数１は「機番」列番号である。表３のアラーム履歴の「機番」列は６列目であることから「機番」列番号として"6"が指定されている。引数２は「発生日時分」列番号である。表３のアラーム履歴の「発生日時分」列は２列目であることから「発生日時分」列番号として"2"が指定されている。引数３は、基準値である。ファームウェアバージョンが２．１以上のデータであるかを判定するために、"2.1"と指定されている。引数４は、検証演算子である。問い合わせた結果のファームウェア番号と、基準値との比較を行うための演算子が指定される。「判定引数」では、"＜"が指定されていることから、ファームウェア番号が、"2.1"よりも大きい場合に"真"、そうでない場合に"偽"を返却する。
【０１３２】
表３と表４を比較すると、表４では、２，５行目の「国コード」列、「機種」列の"＜LF＞"という改行コードが取り除かれていることがわかる。これは、１，２，５，７行目のデータの中で、機番"HEOGMXWTJW"、"UPJNDSD0RD"のファームウェア番号が"2.1"よりも大きかったため、改行コードを取り除く前処理が実施された結果である。
【０１３３】
従来の技術では、本実施例のアラーム履歴データの前処理のように、特定のファームウェアであるかを判定することができないため、特定のファームウェアのデバイス１０７が発生させたデータから不正な改行コードを取り除くことができない。本提案における、前処理サーバ１０１と、前処理サーバ１０１から実行される判定ロジックＡ５００によって、特定のファームウェアのデバイス１０７が発生させたデータから不正な改行コードを取り除くことができ、クライアントコンピュータ１０８で正しくデータを読み込むことが可能となる。
【０１３４】
＜具体例２＞
前処理サーバ１０１の前処理の一例として、デバイス内環境データの前処理における表１、表２、表５、表６の関係について説明する。なお、表５、表６で示したデバイス内環境データのファイル名は"DEVICE_ENVIRONMENT*.csv"で表わされるものとする。
【０１３５】
表１から、このデバイス内環境データ（"DEVICE_ENVIRONMENT*.csv"）に対して、８行目の前処理が実施されることが分かる。また、「簡易判定列」列、「簡易判定条件」列には何も指定されていないことから、判定ロジック４００の実行結果のみから前処理の実施判定を行うことがわかる。また、「判定ロジックＩＤ」は"confirm_firmware"であることがわかる。"check_exchange"は、あるパーツがすでにサービスマンによって交換済であるかどうかを判定する判定ロジックＢ６００である。
【０１３６】
表１の「判定引数」には、"5 ADF 2"が指定されている。この「判定引数」について説明する。表２の「引数数」列の通り、判定ロジックＢ６００が受け付ける引数の数は３つである。引数１は、「機番」列番号である。表５のデバイス内環境データの「機番」列は５列目であることから「機番」列番号として"5"が指定されている。引数２は、パーツＩＤである。「判定引数」には、"ADF"が指定されている。すなわち、ＡＤＦ（Ａｕｔｏ Ｄｏｃｕｍｅｎｔ Ｆｅｅｄｅｒ）のパーツ交換が実施されているかどうかを判定する。引数３は、「データ生成日時分」列番号である。表５のデバイス内環境データの「データ生成日時分」列は２列目であることからデータ生成日時分列番号として"2"が指定されている。
【０１３７】
表５と表６を比較すると、表６では、２，７行目の、「機内温度」列、「機内湿度」列、「定着ローラ表面温度」列のデータがｎｕｌｌになっていることがわかる。これは、判定ロジックＢ６００の実行の結果、２，７行目のデータは、サービスマンによるパーツ交換前のデータであったため、ｎｕｌｌ値が挿入された結果である。
【０１３８】
従来の技術では、本実施例のデバイス内環境データの前処理のように、サービスマンによるパーツ交換前のデータであるかどうかは判定することができず、上記のｎｕｌｌ値の挿入を行うことはできない。本提案における、前処理サーバ１０１と、前処理サーバ１０１から実行される判定ロジックＢ６００によって、サービスマンによるパーツ交換前のデータにｎｕｌｌ値を挿入することで、分析結果の精度向上が可能となる。
【０１３９】
＜具体例３＞
前処理サーバ１０１の前処理の一例として、紙詰まり履歴データの前処理における表１、表２、表７、表８の関係について説明する。なお、表７、表８で示した紙詰まり履歴データのファイル名は"DEVICE_JAM*.csv"で表わされるものとする。
【０１４０】
表１から、この紙詰まり履歴データ（"DEVICE_JAM*.csv"）に対して、７，９行目の前処理が実施されることが分かる。なお、７行目に関しては、アラーム履歴データの前処理と同様のため、省略し、以下９行目の前処理について説明する。
【０１４１】
「簡易判定列」列、「簡易判定条件」列には何も指定されていないことから、判定ロジック４００の実行結果のみから前処理の実施判定を行うことがわかる。また、「判定ロジックＩＤ」は"confirm_manifactured_date"であることがわかる。
"confirm_manifactured_date"は、デバイス１０７の製造年月日を返却する判定ロジックＣ７００である。
【０１４２】
表１の「判定引数」には、"2000/01/01 ＜= X  and  X ＜ 2010/01/01"が指定されている。この「判定引数」について説明する。
表２の「引数数」列の通り、判定ロジックＣ７００が受け付ける引数の数は１つである。引数１は「機番」列番号である。表７の紙詰まり履歴データの「機番」列は６列目であることから「機番」列番号として"6"が指定されている。
【０１４３】
表７と表８を比較すると、表８では、２，５行目の「ＪＡＭコード」列のデータがすべて"JAM-"という文字列から始まるコードに変換されていることがわかる。これは、２，５行目のデータを送信したデバイス１０７は、生産日時が「２０００年０１月０１日」から「２０１０年０１月０１日」までの間（ただし「２０１０年０１月０１日」は含まない）であったことから、ＪＡＭコード修正の前処理が実施された結果である。
【０１４４】
従来の技術では、本実施例の紙詰まり履歴データの前処理のように、特定の日時に生産されたデバイス１０７であるかどうかは判定することができず、上記のＪＡＭコード修正を行うことができない。本提案における、前処理サーバ１０１と、前処理サーバ１０１から実行される判定ロジックＣ７００によって、ＪＡＭコード修正すべきデータを判定、修正することで、クライアントコンピュータ１０８における分析結果の精度向上が可能となる。
【０１４５】
以上のように、実施例１では、前処理サーバ１０１の実施する前処理について、ルール管理部３０２、判定ロジック管理部３０６に従って判定ロジックを呼び出し、柔軟な前処理実施判定を行う方法について説明した。特に、判定ロジックが外部システムへ問い合わせることによって、前処理対象のデータだけでは判定できない条件も、前処理実施判定とすることができる。その効果として、分析に必要な前処理を効果的に行うことができる。
【実施例２】
【０１４６】
上記実施例１で説明した前処理サーバ１０１の前処理は、ルール管理部３０２と、判定ロジック管理部３０６を前処理サーバ１０１の管理者が適切に管理することによって実現できる。さらに、実施例２では、ルール管理部３０２へのルールの登録時に、判定ロジック管理部３０６の情報をもとに、管理者に対して登録画面を表示するように構成する。この構成により、管理者が判定ロジック管理部３０６で管理される判定ロジックについての仕様を熟知していない場合であても、ルール管理部３０２への前処理ルールに適切かつ容易に設定することができる仕組みを提供する。なお、実施例２では実施例１と異なる部分のみを説明し、同一の部分については説明を省略する。
【０１４７】
図１３は、前処理サーバ１０１がルール管理部３０２へ新規の前処理ルールの登録を受け付けるために表示する前処理ルールの新規追加画面である。この画面は、例えば、クライアントコンピュータ１０８からのアクセスに応じて、前処理サーバ１０１の制御部３０１の制御により、クライアントコンピュータ１０８のディスプレイ２０６に表示される。
【０１４８】
ファイル名ルール１３０１は、ファイル名の条件を指定できる文字入力エリアである。
簡易判定列１３０２は、簡易判定を行うための判定対象となる列番号を指定できる数値入力エリアである。
簡易判定条件１３０３は、簡易判定を行うための判定条件を指定できる文字入力エリアである。
【０１４９】
処理ＩＤ１３０４は、前処理のＩＤを指定できるリスト選択コントロールである。該リスト選択コントロールにより、処理ＩＤ１３０４に指定可能な、前処理サーバ１０１が有する前処理機能を表示し、ユーザはその中から選択することで前処理を指定することが可能である。
前処理対象列１３０５は、前処理が施される対象の列番号である。ただし、"All"と指定された場合は全ての列に対して前処理が施される。
処理順１３０６は、１つのファイルに対して複数の前処理が実行される際の処理順を入力できる数値入力エリアである。
【０１５０】
判定ロジック１３０７は、前処理サーバ１０１の判定ロジック管理部３０６が管理する判定ロジックを選択させるリスト選択コントロールである。該リスト選択コントロールにより、判定ロジック１３０７に指定可能な、前処理サーバ１０１が有する判定ロジックを表示し、ユーザはその中から選択することで判定ロジックを指定することが可能である。
【０１５１】
引数１〜４（１３０８〜１３１１）は、判定ロジック１３０７で選択した判定ロジックによって表示される引数入力エリアである。図１３に示す例では、判定ロジックには、判定ロジックＩＤが"confirm_firmware"、すなわち判定ロジックＡ５００が指定されているため、引数入力エリアが４つ表示されている。このように、判定ロジックの選択によって、入力エリアを生成することで、ユーザは判定ロジックに対して適切な引数を指定することができる。
【０１５２】
戻り値１３１２は、判定ロジックの戻り値を指定できる入力エリアである。この戻り値に一致した場合に、処理ＩＤ１３０４で指定した前処理が、「処理対象列」１３０５に施される。
【０１５３】
１３１３はＯＫボタンで、このＯＫボタン１３１３が押下されると、図１３の画面が表示されているクライアントコンピュータから、図１３の画面で入力された前処理ルールが前処理サーバ１０１に送信され、該前処理ルールが、制御部３０１の制御により、ルール管理部３０２に登録される。
【０１５４】
以上示したように、実施例２によれば、ルール管理部３０２の管理者が、ルール管理部３０２への前処理ルールに適切かつ容易に設定することができる。
【０１５５】
以上示したように、本発明の各実施例によれば、データ分析に必要なデータ前処理を実行する分析システムに、外部システムへアクセス可能な判定ロジックを組み込んだルールを設定可能にし、該ルールに従って前処理の実行判定を行う構成を有する。判定ロジックは、外部のサービスやデータベース等の外部システムへ接続することが可能であり、処理対象のデータ外の情報を用いて前処理の判定を行うことができるため、複雑、柔軟な前処理の実行判定を行うことが可能になる。
従って、画像形成装置などの事務機、携帯電話、スマートフォン、パーソナルコンピュータ、家電等のデバイスから吸い上げた履歴情報（ジョブや操作）、センサデータ、設置環境情報、顧客情報や、さらにデバイスを保守するクラウドシステムから収集した保守履歴やサポート情報などを含むビックデータを分析するための分析システムの質を向上させることができる。
【０１５６】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。
【０１５７】
（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
【図１】
2016051426.tif 000011
【図２】
2016051426.tif 000012
【図３】
2016051426.tif 000013
【図４】
2016051426.tif 000014
【図５】
2016051426.tif 000015
【図６】
2016051426.tif 000016
【図７】
2016051426.tif 000017
【図８】
2016051426.tif 000018
【図９】
2016051426.tif 000019
【図１０】
2016051426.tif 000020
【図１１】
2016051426.tif 000021
【図１２】
2016051426.tif 000022
【図１３】
2016051426.tif 000023