以下、図面に基づいて本発明の実施の形態を説明する。
図1は、本発明の実施の形態における情報処理システムの構成例を示す図である。図1に示されるように、本発明の実施の形態における情報処理システムは、情報処理装置1、管理用端末2、機器3及びユーザ端末4を有し、ネットワーク5を介して互いに接続されている。
情報処理装置1は、機器3を管理及び監視するサーバ装置である。情報処理装置1は、機器3の機器情報、管理状況に関する情報、保守作業に関する情報等を管理し、所定期間ごと又は必要に応じて、当該情報に基づきレポートの作成を行う。特に、機器3における障害発生状況は、インシデント情報として情報処理装置1に収集される。
管理用端末2は、管理者が使用する端末であり、情報処理装置1にアクセスして、レポートを取得し、機器管理を行う。
機器3は、情報処理装置1に管理及び監視される機器であり、例えば、画像形成装置等である。機器3は、管理者によって保守される。
ユーザ端末4は、ユーザが使用する一般的なPC(Personal Computer)等である。ユーザ端末4は、機器3が有する機能を利用するクライアント端末である。
ネットワーク5は、上記装置、機器又は端末を相互に接続するネットワークである。ネットワーク5は、例えば、無線LAN(Local Area Network)でもよいし、有線LANでもよい。
図2は、本発明の実施の形態における情報処理装置1のハードウェア構成例を示す図である。図2に示されるように、情報処理装置1は、CPU101(Central Processing Unit)、RAM102(Random Access Memory)、HDD103(Hard Disk Drive)、ROM104(Read Only Memory)、入力装置105、ドライブ装置106、表示装置107及びインタフェース装置108を有する。
CPU101は、プロセッサ及び周辺回路から構成され、情報処理装置1全体を制御する。ROM104は、CPU101で実行されるプログラム及び使用されるデータを格納する不揮発性の記憶装置である。RAM102は、CPU101で実行されるプログラムが制御を行うときのワークエリアとして使用される記憶装置である。HDD103は、CPU101で実行されるプログラム及び使用されるデータを格納する補助記憶装置である。HDD103は、例えば、ハードディスクドライブであってもよいし、フラッシュメモリで構成される記憶装置であってもよい。
入力装置105は、ユーザ又は管理者等が各種入力操作を行うための装置である。入力装置105は、例えば、マウス、キーボード、タッチパネル等を含む。表示装置107は、ユーザ又は監視者等に対して、各種情報の表示を行う。表示装置107は、例えば、液晶ディスプレイであってもよいし、入力装置105と一体化されたタッチパネルであってもよい。ドライブ装置106は、記憶媒体106aに対する読み取り又は書き込みを行う装置である。記憶媒体106aは、例えば、CD−ROM(Compact Disk - ROM)であってもよいし、DVD(Digital Versatile Disk)であってもよいし、その他のメディアであってもよい。インタフェース装置108は、ネットワーク5を介したデータの送受信を行う通信装置である。インタフェース装置108は、例えば、無線LANインタフェースであってもよいし、有線LANインタフェースであってもよいし、その他の方式を使用する通信ネットワークとのインタフェースであってもよい。
なお、管理用端末2、機器3及びユーザ端末4が、図2に示される情報処理装置1と同様のハードウェア構成を有していてもよい。
図3は、本発明の実施の形態における情報処理システムの機能構成例を示す図である。図3に示されるように、情報処理システムは、Group情報管理部10、機器情報管理部20、Ticket情報管理部30、Customer情報管理部40及びReport生成部50を有する。これら各部は、情報処理装置1において、CPU101がプログラムを実行することによって実現されてもよい。また、これら各部の全部又は一部が、他の装置、例えば、ネットワーク5に接続された他の情報処理装置1又は管理用端末2等において実現されてもよい。
Group情報管理部10は、Group管理情報入力部11、Group管理DBコネクタ12及びGroup管理DB13を有する。「DB」は、データベースを意味する。Group情報管理部10は、グループに係る情報を管理する。グループとは、顧客(Customer)を細分化するものである。グループに係る情報は、例えば、GroupID、CustomerID、名称等を含む。「ID(Identifier)」は、識別子を意味する。Group管理情報入力部11は、グループに係る情報の入力を、他の情報管理部、管理者又はユーザ等から受け付ける。Group管理DBコネクタ12は、Group管理DB13にアクセスするためのインタフェースである。Group管理DB13は、グループに係る情報を記憶する。
機器情報管理部20は、機器管理DB21、機器管理DBコネクタ22、機器情報収集部23、Device24a、Device24b及びDevice24cを有する。Device24は、機器3であり、機能構成として、機器情報管理部20に含まれてもよいし、含まれずに別個の機能であってもよい。機器情報管理部20は、機器3に係る情報を管理する。機器管理DB21に記憶される機器3に係る情報は、例えば、シリアルナンバ、IPアドレス、設置日、GroupID、ポーリング状況等を含む。ポーリング状況については後述する。機器管理DBコネクタ22は、機器管理DB21にアクセスするためのインタフェースである。機器情報収集部23は、機器3である各Device24から、機器3に係る情報を収集し、ポーリングの応答に基づいて、故障の発生又は解消等の判定を行い、他の情報管理部に収集した情報及び判定結果を送信する。
Ticket情報管理部30は、Ticket管理情報入力部31、Ticket管理DBコネクタ32及びTicket管理DB33を有する。Ticket情報管理部30は、チケットに係る情報を管理する。チケットとは、機器3で発生する故障ごとに発行される故障情報を含み、例えば、TicketID、発生日、故障カテゴリ、ベンダ名、シリアルナンバ等の情報を含み、主に機器情報収集部23から受信する情報に基づいて入力される。故障は、インシデント又はIncidentと呼ばれてもよい。Ticket管理情報入力部31は、チケットに係る情報の入力を他の情報管理部、管理者又はユーザ等から受け付ける。Ticket管理DBコネクタ32は、Ticket管理DB33にアクセスするためのインタフェースである。Ticket管理DB33は、チケットに係る情報を記憶する。
Customer情報管理部40は、Customer管理DB41、Customer管理DBコネクタ42及びCustomer管理情報入力部43を有する。Customer情報管理部40は、顧客(Customer、カスタマ)に係る情報を管理する。Customer管理DB41に記憶される顧客に係る情報は、例えば、CustomerID、名称、ポーリング閾値等を含む。ポーリング閾値については後述する。Customer管理DBコネクタ42は、Customer管理DB41にアクセスするためのインタフェースである。Customer管理情報入力部43は、顧客に係る情報を、他の情報管理部、管理者又はユーザ等から受け付ける。
Report生成部50は、Report出力エンジン51及びReport計算エンジン52を有する。Report生成部50は、各情報管理部から通知される情報、特にチケットに基づいて、機器3の稼働状況に関するレポートを生成する。Report出力エンジン51は、Report計算エンジン52から出力されるデータに基づいて、所定の型式で稼働状況に関するレポートを出力する。Report計算エンジン52は、各情報管理部から通知される情報に基づいて、機器3の稼働状況、例えば、故障発生回数、故障時間、平均稼働率等を集計する。
以下、実施例1について説明する。図4は、本発明の実施の形態におけるポーリングに基づいてインシデント情報を収集する情報処理システムの機能構成例を示す図である。図4において、図3に示される機器情報管理部20の詳細を示す。Ticket情報管理部30及びCustomer情報管理部40は、図3に示されるTicket情報管理部30及びCustomer情報管理部40と同様である。
図3に示されるように、機器情報管理部20が有する機器情報収集部23は、Incident情報送信部231、自社機Incident情報受付部232、他社機Incident情報収集部233を有する。
Ticket情報管理部30のTicket管理情報入力部31に対する入力は、機器情報管理部20から自動的に実行されるケースと、オペレータによる手動で実行されるケースとがある。本発明の実施の形態における機器情報管理部20は、従来自社機のインシデント情報のみであったTicket管理情報入力部31に対する出力を、他社機のインシデント情報についても実行できるようにする。
自社機でインシデントが発生した場合、自社Device24a又は24bである機器3は、自社機Incident情報受付部232にインシデント情報を送信する。一方、他社Device24c又は24dである機器3は、他社機Incident情報収集部233からのポーリングに応答してインシデント情報を送信する。ポーリングにあたり、他社機Incident情報収集部233は、Customer管理DBコネクタ42を介して、Customer管理DB41に記憶される情報を参照する。自社機Incident情報受付部232又は他社機Incident情報収集部233は、Incident情報送信部231にDevice24から取得したインシデント情報を送信する。Incident情報送信部231は、当該インシデント情報をTicket管理情報入力部31に送信して、当該インシデント情報に係るチケットがTicket情報管理部30で発行される。なお、他社機Incident情報収集部233は、自社Device24にポーリングを行ってもよい。
図5は、本発明の実施の形態におけるポーリングに基づいてインシデント情報を収集する情報処理システムのデータ構造について説明するための図である。図5に示されるように、本発明の実施の形態におけるポーリングに基づいてインシデント情報を収集する情報処理システムのDBは、Customer管理DB、Group管理DB、機器管理DB、Ticket管理DBが存在し、図3に示されるCustomer管理DB41、Group管理DB13、機器管理DB21、Ticket管理DB33にそれぞれ対応する。
Customer管理DBは、データとして、「GUID」、「CustomerID」、「Name」、「ポーリング閾値」を少なくとも有する。「GUID」は、データを識別するIDである。「CustomerID」は、顧客を識別するIDであり、Customer管理DBにおける主キーである。「Name」は、顧客の名称である。「ポーリング閾値」は、インシデント発生を検出する際のポーリング回数の閾値を示す。「ポーリング閾値」の詳細は後述する。
Group管理DBは、データとして、「GUID」、「GroupID」、「CustomerID」、「親GroupID」、「Name」を少なくとも有する。「GUID」は、データを識別するIDである。「GroupID」は、グループを識別するIDであり、Group管理DBにおける主キーである。「CustomerID」は、顧客を識別するIDであり、グループと顧客とを関連付ける。「親GroupID」は、「GroupID」で識別されるグループの親グループの識別子であり、グループの階層構造を形成することができる。「Name」はグループの名称である。
機器管理DBは、データとして、「GUID」、「Serial Number」、「MAC Address」、「IP Address」、「Host名」、「Vendor名」、「Model名」、「Firmware Version」、「設置日」、「リース期限日」、「初期導入費用」、「GroupID」、「ポーリング状況」、「ポーリング状況連続回数」を少なくとも有する。「GUID」は、データを識別するIDである。「Serial Number」は、機器3のシリアルナンバであり、機器管理DBにおける主キーである。「MAC Address」は、機器3が有するMAC(Media Access Control)アドレスである。「IP Address」は、機器3が有するIP(Internet Protocol)アドレスである。「Host名」は、機器3が有するネットワーク5上のホスト名である。「Vendor名」は、機器3のベンダ名である。「Model名」は、機器3のモデル名である。「Firmware Version」は、機器3のファームウェアのバージョンである。「設置日」は、機器3が設置された日付である。「リース期限日」は、機器3のリース期限日である。「初期導入費用」は、機器3が導入された際の費用である。「GroupID」は、グループを識別するIDであり、機器3とグループとを関連付ける。「ポーリング状況」は、機器3がポーリングされたときの応答状況を示す。「ポーリング状況連続回数」は、機器3が複数回のポーリングされたときの応答状況を含む履歴である。「ポーリング状況連続回数」は、「ポーリング応答あり」又は「ポーリング応答なし」がそれぞれ連続した回数をカウントした値である。「ポーリング状況」及び「ポーリング状況連続回数」の詳細は後述する。
Ticket管理DBは、データとして「GUID」、「TicketID」、「発生日」、「解決日」、「Closeまでにかかった時間」、「故障カテゴリ」、「故障概要」、「対応概要」、「PersonID」、「Vendor名」、「Model名」、「Serial Number」を少なくとも有する。「GUID」は、データを識別するIDである。「TicketID」は、チケットを識別するIDであり、Ticket管理DBの主キーである。「発生日」は、インシデントが発生した日付である。「解決日」は、インシデントが解決された日付である。「Closeまでにかかった時間」は、インシデントが発生してから怪異決されるまでに要した時間である。「故障カテゴリ」は、インシデントに係る故障の分類を示す。「故障概要」は、インシデントに係る故障の概要である。「対応概要」は、インシデントに対応する作業の概要である。「PersonID」は、インシデントに対応した担当者を示す。「Vendor名」は、インシデントが発生した機器3のベンダ名である。「Model名」は、インシデントが発生した機器3のモデル名である。「Serial Number」は、インシデントが発生した機器3のシリアルナンバであり、機器管理DBのデータと関連付けられる。
図6は、本発明の実施の形態におけるポーリングに基づいてインシデント情報を収集する情報処理システムのデータの関連付けについて説明するための図である。図6に示されるように、Customerは、複数のGroupと関連付けられる。Groupは、複数のDeviceと関連付けられる。Deviceは、複数のTicketと関連付けられる。具体的には各DB上の情報において、「CustomerID」は複数の「GroupID」に関連付けられ、「GroupID」は複数の「Serial Number」に関連付けられ、「Serial Number」は複数の「TicketID」に関連付けられる。
図7は、本発明の実施の形態におけるポーリングに基づいてインシデント情報を収集する情報処理方法を説明するためのフローチャート(1)である。図7において、機器3は、あるひとつの機器に対応するものとする。当該機器は、他社機であってもよいし、自社機であってもよい。ステップS101のポーリングは、所定の周期で定期的に実行されてもよい。
ステップS101において、他社機Incident情報収集部233は、機器3に対してポーリングを実施する。機器3からポーリングに対する応答があった場合(S102のYES)、ステップS103に進む。機器3からポーリングに対する応答がなかった場合(S102のNO)、ステップS110に進む。
ステップS103において、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を読み出す。直近のポーリングとは、直前のポーリング1回でもよいし、直前の所定の回数のポーリングでもよい。機器3から直近のポーリングに対する応答があった場合(S103のYES)、ステップS104に進む。機器3から直近のポーリングに対する応答がなかった場合(S103のNO)、ステップS106に進む。
ステップS104において、機器情報管理部20は、機器3においてインシデントは発生していないと判定する。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を「ポーリング応答あり」で更新して(S105)、フローを終了する。
ステップS106において、機器情報管理部20は、機器3においてインシデントは既に発生していたと判定する。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を「ポーリング応答あり」で更新する(S107)。続いて、他社機Incident情報収集部233は、機器3に係るインシデントが解消されたことをIncident情報送信部231に送信する。Incident情報送信部231は、機器3に係るインシデント解消情報をTicket情報管理部30のTicket管理情報入力部31に通知する(S108)。続いて、Ticket情報管理部30は、Ticket管理DB33に記憶されている機器3に係るインシデントに対応するチケットをインシデントが解消された内容で更新して(S109)、フローを終了する。
ステップS110において、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を読み出す。機器3から直近のポーリングに対する応答があった場合(S110のYES)、ステップS111に進む。機器3から直近のポーリングに対する応答がなかった場合(S110のNO)、ステップS115に進む。
ステップS111において、機器情報管理部20は、機器3において新規でインシデントが発生したと判定する。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を「ポーリング応答なし」で更新する(S112)。続いて、他社機Incident情報収集部233は、機器3に係るインシデントが発生したことをIncident情報送信部231に送信する。Incident情報送信部231は、機器3に係るインシデント発生情報をTicket情報管理部30のTicket管理情報入力部31に通知する(S113)。続いて、Ticket情報管理部30は、機器3に係るインシデント発生に対応するチケットを発行してTicket管理DB33に記憶させ(S114)、フローを終了する。
ステップS115において、機器情報管理部20は、機器3においてインシデントは既に発生していたと判定する。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を「ポーリング応答なし」で更新して(S116)、フローを終了する。
図8は、本発明の実施の形態におけるポーリングに基づいてインシデント情報を収集する情報処理方法を説明するためのフローチャート(2)である。図8において、機器3は、あるひとつの機器に対応するものとする。当該機器は、他社機であってもよいし、自社機であってもよい。図8で説明する情報処理方法は、図7で説明した情報処理方法と異なり、複数回のポーリング状況及び閾値に基づいて、インシデントが発生したか否かを判定する。ステップS201のポーリングは、所定の周期で定期的に実行されてもよい。
ステップS201において、他社機Incident情報収集部233は、機器3に対してポーリングを実施する。機器3からポーリングに対する応答があった場合(S202のYES)、ステップS203に進む。機器3からポーリングに対する応答がなかった場合(S202のNO)、ステップS212に進む。
ステップS203において、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を読み出す。機器3から直近のポーリングに対する応答があった場合(S203のYES)、ステップS204に進む。機器3から直近のポーリングに対する応答がなかった場合(S203のNO)、ステップS207に進む。
ステップS204において、機器情報管理部20は、機器3においてインシデントは発生していないと判定する。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を「ポーリング応答あり」で更新する(S205)。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の「ポーリング状況連続回数」に「ポーリング応答あり」で加算して更新し(S206)、フローを終了する。
ステップS207において、機器情報管理部20は、機器3においてインシデントは既に発生していたと判定する。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を「ポーリング応答あり」で更新する(S208)。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の「ポーリング状況連続回数」をリセットする(S209)。続いて、他社機Incident情報収集部233は、機器3に係るインシデントが解消されたことをIncident情報送信部231に送信する。Incident情報送信部231は、機器3に係るインシデント解消情報をTicket情報管理部30のTicket管理情報入力部31に通知する(S210)。続いて、Ticket情報管理部30は、Ticket管理DB33に記憶されている機器3に係るインシデントに対応するチケットをインシデントが解消された内容で更新して(S211)、フローを終了する。
ステップS212において、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を読み出す。機器3から直近のポーリングに対する応答があった場合(S212のYES)、ステップS213aに進む。機器3から直近のポーリングに対する応答がなかった場合(S212のNO)、ステップS213bに進む。
ステップS213aにおいて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を「ポーリング応答なし」で更新する。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の「ポーリング状況連続回数」をリセットして「ポーリング応答なし:1回」を設定し(S214a)、ステップS215に進む。
ステップS213bにおいて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の直近の「ポーリング状況」を「ポーリング応答なし」で更新する。続いて、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスし、機器3の「ポーリング状況連続回数」に「ポーリング応答なし」で加算して更新し(S214b)、ステップS215に進む。
ステップS215において、他社機Incident情報収集部233は、機器管理DBコネクタ22を介して機器管理DB21にアクセスして機器3の「ポーリング状況連続回数」を取得するか、又は他社機Incident情報収集部233がステップS214から保持している「ポーリング状況連続回数」を取得する。また、他社機Incident情報収集部233は、Customer管理DBコネクタ42を介してCustomer管理DB41にアクセスし、機器3の「ポーリング閾値」を取得する。
続いて、ステップS216において、ステップS215で取得された「ポーリング状況連続回数」と「ポーリング閾値」とを比較する。「ポーリング状況連続回数」は、「ポーリング応答なし」が連続した回数である。「ポーリング状況連続回数」が「ポーリング閾値」以上であった場合(S216のYES)、ステップS217に進む。「ポーリング状況連続回数」が「ポーリング閾値」未満であった場合(S216のYES)、ステップS217に進む。
ステップS217において、機器情報管理部20は、機器3において新規でインシデントが発生したと判定する。続いて、他社機Incident情報収集部233は、機器3に係るインシデントが発生したことをIncident情報送信部231に送信する。Incident情報送信部231は、機器3に係るインシデント発生情報をTicket情報管理部30のTicket管理情報入力部31に通知する(S218)。続いて、Ticket情報管理部30は、機器3に係るインシデント発生に対応するチケットを発行してTicket管理DB33に記憶させ(S219)、フローを終了する。
上述のように、実施例1によれば、情報処理装置1は、ネットワーク5を介して接続された機器3にポーリングを行って機器3からの応答を収集することにより、インシデントの発生又は解消を判定して、当該インシデント情報に応じたチケットを発行又は更新することができる。
すなわち、インシデント情報を自動的に収集し、管理システムへ通知することによって、管理システムにおいて生成されるレポートの精度を改善することができる。
以下、実施例2を説明する。実施例2では実施例1と異なる点について説明する。したがって、特に言及されない点については、実施例1と同様であってよい。図9は、本発明の実施の形態におけるカウンタ値に基づいてインシデント情報を収集する情報処理システムの機能構成例を示す図である。図9において、実施例1における図4の構成に、Counter情報管理部60が追加されている構成例を示す。
Counter情報管理部60は、Counter管理DB61、Counter管理DBコネクタ62及びCounter管理情報入力部63を有する。Counter情報管理部60は、機器3の稼働に係る度数を示すカウンタ値を管理する。Counter管理DB61は、例えば、カウンタ値及びカウンタ値の最終更新日等の情報を記憶する。Counter管理DBコネクタ62は、Counter管理DB61にアクセスするためのインタフェースである。Counter管理情報入力部63は、他の情報管理部、管理者又はユーザ等からカウンタ値に関する情報の入力を受け付ける。図9に示されるように、他社機Incident情報収集部233とCounter管理情報入力部63は、情報の入出力を行う。
図10は、本発明の実施の形態におけるカウンタ値に基づいてインシデント情報を収集する情報処理システムのデータ構造について説明するための図である。
図10に示されるCustomer管理DBは、図5に示されるCustomer管理DBに加えて、データ「カウントアップ監視期間」を有する。「カウントアップ監視期間」は、カウンタ値が更新されない期間の閾値を示しており、インシデント発生に関する判定に使用される。「カウントアップ監視期間」の詳細は後述する。
図10に示されるCounter管理DBは、データとして、「GUID」、「CounterID」、「Serial Number」、「Total Counter」、「Total Counter最終カウントアップ更新日」を少なくとも有する。「GUID」は、データを識別するIDである。「CounterID」は、カウンタ値を識別するIDであり、Counter管理DBの主キーである。「Serial Number」は、機器3のシリアルナンバであり、機器管理DBのデータと関連付けられる。「Total Counter」は、機器3の稼働に係る度数を示すカウンタ値である。「Total Counter最終カウントアップ更新日」は、「Total Counter」がカウントアップして更新された最終更新日である。
図11は、本発明の実施の形態におけるポーリングに基づいてインシデント情報を収集する情報処理システムのデータの関連付けについて説明するための図である。図11に示されるように、Customerは、複数のGroupと関連付けられる。Groupは、複数のDeviceと関連付けられる。Deviceは、複数のTicketと関連付けられる。具体的には各DB上の情報において、「CustomerID」は複数の「GroupID」に関連付けられ、「GroupID」は複数の「Serial Number」に関連付けられ、「Serial Number」は複数の「TicketID」に関連付けられる。また、「Serial Number」は、それぞれ「CounterID」に関連付けられる。
図12は、本発明の実施の形態におけるカウンタ値に基づいてインシデント情報を収集する情報処理方法を説明するためのフローチャート(1)である。図12において、機器3は、あるひとつの機器に対応するものとする。当該機器は、他社機であってもよいし、自社機であってもよい。ステップS301のポーリングは、所定の周期で定期的に実行されてもよい。
ステップS301において、他社機Incident情報収集部233は、機器3に対してポーリングを実施する。機器3からポーリングに対する応答としてカウンタ値を収集できた場合(S302のYES)、ステップS303に進む。機器3からポーリングに対する応答としてカウンタ値を収集できなかった場合(S302のNO)、フローを終了する。
ステップS303において、他社機Incident情報収集部233は、Counter管理DBコネクタ62を介してCounter管理DB61にアクセスし、機器3のカウンタ値すなわち「Total Counter」を読み出す。機器3から収集されたカウンタ値と、DBのカウンタ値とで差分がある場合(S303のYES)、ステップS304に進む。機器3から収集されたカウンタ値と、DBのカウンタ値とで差分がない場合(S303のNO)、ステップS306に進む。
ステップS304において、機器情報管理部20は、機器3においてインシデントは発生していないと判定する。続いて、他社機Incident情報収集部233は、Counter管理DBコネクタ62を介してCounter管理DB61にアクセスし、機器3の「Total Conuter」を収集されたカウンタ値で更新し、「Total Counter最終カウントアップ更新日」を現在日時で更新して(S305)、フローを終了する。
ステップS306において、他社機Incident情報収集部233は、Counter管理DBコネクタ62を介してCounter管理DB61にアクセスし、機器3の「Total Counter最終カウントアップ更新日」を読み出す。読み出された「Total Counter最終カウントアップ更新日」と現在日時との差分が、1日以上である場合(S306のYES)、ステップS307に進み、1日未満である場合(S306のNO)、ステップS310に進む。
ステップS307において、機器情報管理部20は、機器3において新規でインシデントが発生したと判定する。続いて、他社機Incident情報収集部233は、機器3に係るインシデントが発生したことをIncident情報送信部231に送信する。Incident情報送信部231は、機器3に係るインシデント発生情報をTicket情報管理部30のTicket管理情報入力部31に通知する(S308)。続いて、Ticket情報管理部30は、機器3に係るインシデント発生に対応するチケットを発行してTicket管理DB33に記憶させ(S309)、フローを終了する。
ステップS310において、機器情報管理部20は、機器3においてインシデントは発生していないと判定し、フローを終了する。
図13は、本発明の実施の形態におけるカウンタ値に基づいてインシデント情報を収集する情報処理方法を説明するためのフローチャート(2)である。図13において、機器3は、あるひとつの機器に対応するものとする。当該機器は、他社機であってもよいし、自社機であってもよい。ステップS401のポーリングは、所定の周期で定期的に実行されてもよい。
ステップS401において、他社機Incident情報収集部233は、機器3に対してポーリングを実施する。機器3からポーリングに対する応答としてカウンタ値を収集できた場合(S402のYES)、ステップS403に進む。機器3からポーリングに対する応答としてカウンタ値を収集できなかった場合(S402のNO)、インシデントの発生に係る判定は行われずに、フローを終了する。
ステップS403において、他社機Incident情報収集部233は、Counter管理DBコネクタ62を介してCounter管理DB61にアクセスし、機器3のカウンタ値すなわち「Total Counter」を読み出す。機器3から収集されたカウンタ値と、DBのカウンタ値とで差分がある場合(S403のYES)、ステップS404に進む。機器3から収集されたカウンタ値と、DBのカウンタ値とで差分がない場合(S403のNO)、ステップS406に進む。
ステップS404において、機器情報管理部20は、機器3においてインシデントは発生していないと判定する。続いて、他社機Incident情報収集部233は、Counter管理DBコネクタ62を介してCounter管理DB61にアクセスし、機器3の「Total Conuter」を収集されたカウンタ値で更新し、「Total Counter最終カウントアップ更新日」を現在日時で更新して(S405)、フローを終了する。
ステップS406において、他社機Incident情報収集部233は、Customer管理DBコネクタ42を介してCustomer管理DB41にアクセスし、機器3の「カウントアップ監視期間」を読み出す。続いて、ステップS407において、他社機Incident情報収集部233は、Counter管理DBコネクタ62を介してCounter管理DB61にアクセスし、機器3の「Total Counter最終カウントアップ更新日」を読み出す。読み出された「Total Counter最終カウントアップ更新日」と現在日時との差分が、「カウントアップ監視期間」以上である場合(S407のYES)、ステップS408に進み、「カウントアップ監視期間」未満である場合(S407のNO)、ステップS411に進む。
ステップS408において、機器情報管理部20は、機器3において新規でインシデントが発生したと判定する。続いて、他社機Incident情報収集部233は、機器3に係るインシデントが発生したことをIncident情報送信部231に送信する。Incident情報送信部231は、機器3に係るインシデント発生情報をTicket情報管理部30のTicket管理情報入力部31に通知する(S409)。続いて、Ticket情報管理部30は、機器3に係るインシデント発生に対応するチケットを発行してTicket管理DB33に記憶させ(S410)、フローを終了する。
ステップS411において、機器情報管理部20は、機器3においてインシデントは発生していないと判定し、フローを終了する。
上述のように、実施例2によれば、情報処理装置1は、ネットワーク5を介して接続された機器3にポーリングを行って機器3からのカウンタ値及び最終更新日を収集して、情報処理装置1が有するDBに記録されているカウンタ値及び最終更新日と比較することにより、インシデントの発生を判定して、当該インシデント情報に応じたチケットを発行又は更新することができる。
すなわち、インシデント情報を自動的に収集し、管理システムへ通知することによって、管理システムにおいて生成されるレポートの精度を改善することができる。
なお、本発明の実施の形態において、他社機Incident情報収集部233は、収集部の一例である。機器情報収集部23は、判定部の一例である。Report生成部50は、生成部の一例である。
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。