特許 6039352 デバイス管理システム、デバイス管理システムの制御方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6039352

(24)【登録日】2016年11月11日

(45)【発行日】2016年12月7日

(54)【発明の名称】デバイス管理システム、デバイス管理システムの制御方法、及びプログラム

(51)【国際特許分類】

   G06Q 10/00 20120101AFI20161128BHJP

【ＦＩ】

   G06Q10/00 300

【請求項の数】13

【全頁数】23

(21)【出願番号】特願2012-226533(P2012-226533)

(22)【出願日】2012年10月12日

(65)【公開番号】特開2014-78184(P2014-78184A)

(43)【公開日】2014年5月1日

【審査請求日】2015年9月10日

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100145827

【弁理士】

【氏名又は名称】水垣 親房

(74)【代理人】

【識別番号】100199820

【弁理士】

【氏名又は名称】西脇 博志

(72)【発明者】

【氏名】舟根 奈央

【審査官】 阿部 潤

(56)【参考文献】

【文献】 特開２０００−３０５８８６（ＪＰ，Ａ）

【文献】 特開２０１０−２３１３７５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

顧客と該顧客に設置されたデバイスの識別情報との対応に関する第１の顧客情報を記憶管理する管理手段と、
前記第１の顧客情報とは異なる体系である第２の顧客情報に従うインシデント管理システムからインシデントデータを取得する第１の取得手段と、
前記第１の取得手段により取得されたインシデントデータに対象デバイスの識別情報が含まれている場合に、当該識別情報に基づき、当該インシデントデータに対応する顧客を前記第１の顧客情報から特定する特定手段と、
前記第１の顧客情報と、前記特定手段により顧客が特定されたインシデントデータとを用いたレポートの生成を制御する制御手段と、
を有することを特徴とするデバイス管理システム。

【請求項2】

前記特定手段は、前記インシデントデータに対象デバイスの識別情報が含まれていない場合には、デバイスの識別情報を含む前記顧客に設置されたデバイスの障害情報に基づき、当該インシデントデータに対応する顧客を前記第１の顧客情報から特定することを特徴とする請求項１に記載のデバイス管理システム。

【請求項3】

前記障害情報は、前記デバイスの障害を管理する別のシステムから取得されることを特徴とする請求項２に記載のデバイス管理システム。

【請求項4】

前記特定手段は、前記インシデントデータと前記障害情報を比較し、比較条件と合致した障害情報を抽出し、該抽出した障害情報に対応するデバイスが設置された顧客を、前記インシデントデータに対応する顧客と特定することを特徴とする請求項２又は３に記載のデバイス管理システム。

【請求項5】

前記特定手段は、前記インシデントデータに含まれる時刻情報と前記障害情報に含まれる時刻情報を、前記インシデントデータの内容に応じた比較条件で比較することを特徴とする請求項４に記載のデバイス管理システム。

【請求項6】

前記特定手段は、前記インシデントデータに対象デバイスの識別情報が含まれていない場合には、前記インシデントデータと、顧客を特定済みの過去のインシデントデータとを比較し、前記インシデントデータと類似する過去のインシデントデータに対して特定済みの顧客を、前記インシデントデータに対応する顧客に特定することを特徴とする請求項１に記載のデバイス管理システム。

【請求項7】

前記特定手段は、前記インシデントデータに含まれる各項目の情報と前記過去のインシデントデータに含まれる各項目の情報を比較し、一致した項目に付与された重みに応じて類似度を算出し、該類似度の高い過去のインシデントデータに対して特定済みの顧客を、前記インシデントデータに対応する顧客に特定することを特徴とする請求項６に記載のデバイス管理システム。

【請求項8】

前記特定手段は、前記インシデントデータが定期的に発生する内容を示す場合には、該定期的に発生する内容を示す過去のインシデントデータを抽出し、該抽出した過去のインシデントデータに含まれる時刻情報と特定済みの顧客の情報から、特定の顧客における前記定期的に発生する内容の発生周期を推定し、該推定した発生周期と前記インシデントデータに含まれる時刻情報が合致する場合には、前記特定の顧客を、前記インシデントデータに対応する顧客と特定することを特徴とする請求項６に記載のデバイス管理システム。

【請求項9】

前記特定手段は、前記インシデントデータに含まれる障害情報と同一の障害情報を含む過去のインシデントデータを抽出し、該抽出した過去のインシデントデータに含まれる対象デバイスの識別情報から、前記同一の障害の発生頻度が高いデバイスを特定し、該特定されたデバイスが設置された顧客を、前記インシデントデータに対応する顧客と特定することを特徴とする請求項６に記載のデバイス管理システム。

【請求項10】

前記インシデントデータは、前記デバイスを使えるべき時間に本来の品質で該デバイスを使えない状態が発生した場合に該状態に関する情報を記録したデータであることを特徴とする請求項１乃至９のいずれか１項に記載のデバイス管理システム。

【請求項11】

前記顧客に設置されたデバイスから該デバイスの障害情報を取得する第２の取得手段を更に有することを特徴とする請求項１乃至１０のいずれか１項に記載のデバイス管理システム。

【請求項12】

顧客と該顧客に設置されたデバイスの識別情報との対応に関する第１の顧客情報を記憶管理する管理手段を有するデバイス管理システムの制御方法であって、
前記第１の顧客情報とは異なる体系である第２の顧客情報に従うインシデント管理システムからインシデントデータを取得する第１の取得ステップと、
前記第１の取得ステップにより取得されたインシデントデータに対象デバイスの識別情報が含まれている場合に、当該識別情報に基づき、当該インシデントデータに対応する顧客を前記第１の顧客情報から特定する特定ステップと、
前記第１の顧客情報と、前記特定ステップにより顧客が特定されたインシデントデータとを用いたレポートの生成を制御する制御ステップと、
を有することを特徴とするデバイス管理システムの制御方法。

【請求項13】

コンピュータを、請求項１乃至１１のいずれか１項に記載された手段として機能させる
ためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、デバイス管理システム、デバイス管理システムの制御方法、及びプログラムに関するものである。

【背景技術】

【0002】

一般的に、画像形成装置（ＭＦＰ；Multifunction Peripheral）等の入出力装置（以下、デバイス）にエラーが発生した際に、顧客がサービスセンターに連絡し、デバイスを修理するサービスマンが顧客先に派遣されるシステムが存在する。通報には、エラー（障害）の他に、トナーや用紙などの消耗品の発注、操作方法の問合わせ、パスワード忘れの問合わせ等のサービス要求も含まれる。このような顧客からサービスセンターへの通報は、インシデントとして管理される。

【0003】

インシデントとは、サービスの中断又はサービス品質の低下を引き起こす、あるいは引き起こす場合がある、サービスの標準オペレーションに含まれていないあらゆるイベントを示す。即ち、上記デバイスについては、顧客がデバイスを使えるべき時間に本来の品質で使えない状態をインシデントという。
インシデントを記録したインシデントデータには、エラー等が発生したデバイスを特定するデバイスＩＤや、エラー等の内容が含まれる。

【0004】

一方、デバイスを使用する顧客に対し、デバイスの置き換えや新規購入、使用方法などの助言を行うために、デバイスの使用状況等のレポートを生成し提供するデバイス管理システムが存在する。このレポートには、インシデントやカウンタ情報等が含まれ、これにより、顧客にデバイスの使用状況に関する情報を提供している。

【0005】

上記レポートにインシデントを取り込む方法としては、上記サービスセンターで運用されているインシデント管理システムからインシデントデータを取得し、取り込む方法が考えられる。

【0006】

また、上記レポートにカウンタ情報を取り込む方法としては、デバイス管理システムがデバイスと通信してデバイスからカウンタ情報を取得し、取り込む方法が考えられる。
デバイス管理システムが、デバイスからカウンタ情報を取得し管理する方法として、デバイスＩＤ（ＩＰアドレスやＭＡＣアドレス）を用いてデバイスを一意に特定する方法が提案されている（特許文献１参照）。

【0007】

そして、上述のデバイス管理システムとインシデント管理システムが連携することで、デバイス管理システムにおいて総合的なデバイス使用状況レポートを作成し、顧客に提供することができる。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２００４−０９４９１９号公報

【発明の概要】

【発明が解決しようとする課題】

【0009】

しかしながら、デバイス管理システムはデバイス販売会社で運用しており、一方インシデント管理システムはサービスセンターで運用しているなど、各システムの運用元が異なる場合がある。その場合、それぞれのシステムで管理している顧客の契約単位（即ち、管理単位）が異なる可能性がある。

【0010】

例えば、デバイス販売会社では、甲社の本社と支社をそれぞれ別の顧客（顧客Ａ、顧客Ｂ）として管理しているが、サービスセンターでは、甲社の本社と支社をまとめて一の顧客（顧客１）として管理している可能性がある。

【0011】

その場合、デバイス管理システムは、インシデント管理システムから取得した「顧客１」のインシデントデータを、デバイス管理システム上のどの顧客（顧客Ａｏｒ顧客Ｂ）に振り分けるべきか、判断できない。

【0012】

なお、デバイス管理システムにおいて、各顧客が持っているデバイスの情報を保持しておけば、インシデントデータに含まれるデバイスＩＤと比較して、振り分け先の顧客を特定することができる。

【0013】

しかしながら、インシデントデータの記録は手入力で行われる場合があり、正しい情報が全て入っていない場合がある。
特許文献１では、カウンタ情報について、デバイスＩＤを用いて該当デバイスを特定している。しかし、上述のように、インシデントデータの場合、インシデントデータにデバイスを特定可能な情報が含まれていない場合があり、その場合には、インシデント振り分け先の顧客を特定できないという問題がある。

【0014】

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、インシデント管理システムから取得したインシデントデータの情報が不足している場合でも、適切な顧客にインシデントを振り分け、最適なレポートを顧客に提供することができる仕組みを提供することである。

【課題を解決するための手段】

【0015】

本発明のデバイス管理システムは、顧客と該顧客に設置されたデバイスの識別情報との対応に関する第１の顧客情報を記憶管理する管理手段と、前記第１の顧客情報とは異なる体系である第２の顧客情報に従うインシデント管理システムからインシデントデータを取得する第１の取得手段と、前記第１の取得手段により取得されたインシデントデータに対象デバイスの識別情報が含まれている場合に、当該識別情報に基づき、当該インシデントデータに対応する顧客を前記第１の顧客情報から特定する特定手段と、前記第１の顧客情報と、前記特定手段により顧客が特定されたインシデントデータとを用いたレポートの生成を制御する制御手段と、を有することを特徴とする。

【発明の効果】

【0016】

本発明によれば、インシデント管理システムから取得したインシデントデータの情報が不足している場合でも、適切な顧客にインシデントを振り分け、最適なレポートを顧客に提供することができる。

【図面の簡単な説明】

【0017】

【図1】本発明の一実施例を示すデバイス管理システムを適用可能なシステムの一例を示す図である。

【図2】デバイス管理装置１１０の構成の一例を示すブロック図である。

【図3】デバイス管理装置１１０が管理する顧客と、インシデント管理装置１２０が管理する顧客の関連付け情報を保持する顧客関連付けテーブルの一例を示す図である。

【図4】本発明の実施例１におけるインシデントデータの顧客振り分け処理の一例を示すフローチャートである。

【図5】インシデント管理装置１２０が管理するインシデントデータを保持するインシデントデータテーブルの一例を示す図である。

【図6】顧客ごとのデバイス情報を管理するデバイス情報テーブルの一例を示す図である。

【図7】デバイス管理装置１１０が管理する各デバイスのエラー情報を保持するエラー情報テーブルの一例を示す図である。

【図8】本発明の実施例２におけるデバイスが特定できないインシデントデータの顧客振り分け処理の一例を示すフローチャートである。

【図9】過去のインシデント振り分け実績を格納したテーブルの一例を示す図である。

【発明を実施するための形態】

【0018】

以下、本発明を実施するための形態について図面を用いて説明する。

【実施例1】

【0019】

図１（ａ）は、本発明の一実施例を示すデバイス管理システムを適用可能なシステムの一例を示す図である。
デバイス管理システムを構成するデバイス管理装置１１０は、後述する図２の構成を有するコンピュータである。
デバイス管理装置１１０は、ネットワーク１００に接続する機能を持ち、ネットワーク１００を介してインシデント管理装置１２０およびデバイス１３０と通信を行う機能を有する。

【0020】

以下、図２を参照して、デバイス管理装置１１０の構成について説明する。
図２は、デバイス管理装置１１０の構成の一例を示すブロック図である。
ＣＰＵ２０１は、ＲＡＭ２０３をワークメモリとして、ＲＯＭ２０２およびハードディスクドライブ（ＨＤＤ）２１１に格納されたプログラムを実行し、システムバス２００を介して後述する各構成を制御する。

【0021】

ＨＤＤ２１１は、オペレーティングシステム（ＯＳ）や各種プログラムやデータを格納する。
ＣＰＵ２０１は、ディスクコントローラ（ＤＫＣ）２０７を介して、ＨＤＤ２１１およびディスクドライブ２１２にアクセス可能である。ＣＰＵ２０１は、ディスクドライブ２１２にセットされた記録媒体（例えばＤＶＤ−ＲＯＭ）にコンピュータ読み取り可能に記録された各種プログラム等をＨＤＤ２１１にインストールすることができる。

【0022】

ＣＰＵ２０１は、ネットワークインタフェイスカード（ＮＩＣ）２０８を介して、ネットワーク１００を介した他のコンピュータ、デバイス等とも通信可能である。
ＣＰＵ２０１は、上述のプログラムに従い、ビデオカード（ＶＣ）２０６を介してモニタ２１０にユーザインタフェイス（ＵＩ）を表示する。ユーザは、キーボード（ＫＢ）２０９やマウスなどのポインティングデバイス（不図示）を操作して、ＵＩに対する指示や入力を行なう。ＣＰＵ２０１は、キーボードコントローラ（ＫＢＣ）２０５を介してユーザ指示や入力を受け付け、ユーザ指示や入力に応じて様々な処理を実行する。

【0023】

以下、図１の説明に戻る。
インシデント管理システムを構成するインシデント管理装置１２０は、デバイス管理装置１１０と同じく図２のような構成を有するコンピュータである。
デバイス１３０は、複写機などの画像形成装置（デバイス）である。デバイス１３０は、ネットワーク１００に接続する機能を持ち、ネットワーク１００を介してデバイス管理装置１１０と通信を行う機能を有する。

【0024】

なお、本システムは、デバイス管理装置１１０、インシデント管理装置１２０、及びデバイス１３０等の情報処理装置上で協調動作するプログラムによって実現される。プログラムは、各情報処理装置の不揮発性記憶領域にコンピュータ読み取り可能に記憶されており、ＲＡＭに読みだされＣＰＵによって実行される。

【0025】

以下、デバイス管理装置１１０のデバイス管理機能について説明する。
デバイス管理装置１１０は、顧客ネットワーク内のデバイス１３０を管理する機能を有する。なお、図１では、顧客ネットワークは１つしか示されていないが、複数存在する。また、各顧客ネットワーク内のデバイス１３０も、複数存在してもよい。

【0026】

デバイス管理装置１１０は、顧客と該顧客に設置されたデバイスに関する情報（第１の顧客情報；例えば後述する図６、図７に示す情報）を記憶管理する機能を有する。以下、詳細に説明する。

【0027】

デバイス管理装置１１０は、図６に示すようなデバイス管理テーブルを保持し、顧客ごとにデバイス１３０を管理する。
図６は、顧客ごとのデバイス情報を管理するデバイス情報テーブルの一例を示す図である。なお、図６に示すデバイス情報テーブルは、デバイス管理装置１１０のＨＤＤ２１１に記憶されている。

【0028】

図６に示すように、本実施例のデバイス情報テーブルに保持される各デバイス情報は、顧客６０１、デバイスＩＤ６０２等の情報を有する。
顧客６０１は、デバイス管理装置１１０が管理する顧客単位で顧客を識別する情報である。デバイスＩＤ６０２は、デバイスの識別情報であり、例えば、デバイスのＩＰアドレス、ＭＡＣアドレス、シリアル番号等でもよい。

【0029】

図６に例示するデバイス情報テーブルでは、デバイス管理装置１１０が管理する「顧客Ａ」で使用されているデバイスとして、デバイスＩＤが「ＤｅｖＤ１００」のデバイス、及び「ＤｅｖＤ１０１」のデバイスが対応付けられて管理されている。また、デバイス管理装置１１０が管理する「顧客Ｂ」で使用されているデバイスとして、デバイスＩＤが「ＤｅｖＤ１０２」のデバイスが対応付けられて管理されている。

【0030】

デバイス管理装置１１０は、デバイス１３０と通信して、デバイス１３０のエラー発生状況を取得し、ＨＤＤ２１１に保持し、モニタ２１０にエラー状況を表示する。この際、デバイス管理装置１１０がデバイス１３０から取得するエラー情報は、後述する図７に示すデバイスＩＤ７０２、エラー発生時刻７０３、エラー情報７０４に対応する情報を含む。なお、デバイス管理装置１１０によるエラー情報の取得は、デバイス管理装置１１０からの取得要求に応じて、デバイス１３０がデバイス管理装置１１０にエラー情報を送信する構成でもよいし、デバイス１３０でエラーが発生した際、又は定期的に、デバイス１３０がエラー情報をデバイス管理装置１１０に送信する構成でもよい。

【0031】

なお、デバイス管理装置１１０は、図７に示すようなエラー情報テーブルを保持し、デバイス１３０から取得したエラー情報を記憶し管理する。
図７は、デバイス管理装置１１０が管理する各デバイスのエラー情報（顧客に設置されたデバイスの障害情報）を保持するエラー情報テーブルの一例を示す図である。図７に示すエラー情報テーブルは、デバイス管理装置１１０のＨＤＤ２１１に記憶されている。

【0032】

図７に示すように、本実施例のエラー情報テーブルに保持される各エラー情報は、エラーＮｏ.７０１、デバイスＩＤ７０２、エラー発生時刻７０３、エラー情報７０４、対応インシデントＮｏ.７０５等の情報を有する。

【0033】

エラーＮｏ.７０１は、デバイス１３０から取得したエラー情報ごとに、デバイス管理装置１１０で付加される固有の番号である。
デバイスＩＤ７０２、エラー発生時刻７０３、エラー情報７０４は、デバイス１３０から取得したエラー情報に対応する。以下、個別に説明する。
デバイスＩＤ７０２は、エラーが発生したデバイス１３０のデバイスＩＤを示し、図６のデバイスＩＤ６０２と共通のものである。エラー発生時刻７０３は、デバイス１３０でエラーが発生した日時を示す。エラー情報７０４は、発生したエラーの内容を示す。なお、対応インシデントＮｏ.７０５については後述する。

【0034】

次に、インシデント管理装置１２０のインシデント管理機能について説明する。
デバイス１３０にエラーが発生した場合、デバイス１３０の顧客が、サービスセンターに通報する。

【0035】

なお、インシデントとは、サービスの中断又はサービス品質の低下を引き起こす、あるいは引き起こす場合がある、サービスの標準オペレーションに含まれていないあらゆるイベントを示す。即ち、本実施例では、顧客がデバイスを使えるべき時間に本来の品質で使えない状態をインシデントという。なお、インシデントには、通常の障害や問題の発生だけでなく、パフォーマンスの悪化、ユーザによるパスワード忘れや、消耗品の注文、定期メンテナンスの確認といったサービス要求も含まれる。

【0036】

インシデント管理とは、顧客がデバイスを利用して業務を遂行できない状態を、いかに早く解決し、業務を続けることを支援するプロセスである。インシデントに関する通報は、一元的窓口としてのサービスセンターに対して行われる。サービスセンターでは、顧客から通報のあった全てのインシデントがインシデントデータとして、サービスマン等により入力され、インシデント管理装置１２０内のＨＤＤ２１１に記録される。

【0037】

インシデント管理装置１２０は、インシデントデータを記憶管理する機能を有する。インシデント管理装置１２０は、図５に示すようなインシデントデータテーブルを保持し、デバイス１３０のインシデントデータを記憶し管理する。インシデントデータは、システム管理システムで管理する第１の顧客情報とは異なる体系である第２の顧客情報に従うものである。

【0038】

図５は、インシデント管理装置１２０が管理するインシデントデータを保持するインシデントデータテーブルの一例を示す図である。図５に示すインシデントデータテーブルは、インシデント管理装置１２０のＨＤＤ２１１に記憶されている。

【0039】

図５に示すように、本実施例のインシデントデータテーブルに保持される各インシデントデータは、インシデントＮｏ.５０１、顧客ＩＤ５０２、デバイスＩＤ５０３、通報時刻５０４、出動時刻５０５、分類５０６、内容５０７、設置場所５０８、通報者５０９、サービスマン５１０等の情報を有する。

【0040】

インシデントＮｏ.５０１は、インシデントデータごとの固有の番号である。顧客ＩＤ５０２は、通報のあった顧客を、インシデント管理装置１２０が管理する顧客単位で識別する情報である（システム管理システムで管理する第１の顧客情報とは異なる体系である第２の顧客情報に従って顧客を管理するための顧客の識別情報である）。

【0041】

デバイスＩＤ５０３は、通報に対応するインシデントが発生したデバイス（対象デバイス）のデバイスＩＤ（識別情報）を示し、図６のデバイスＩＤ６０２、図７のデバイスＩＤ７０２と共通のものである。

【0042】

通報時刻５０４は、顧客から通報のあった日時を示す。出動時刻５０５は、顧客からの通報に応じてサービスマンが出動した日時を示す。分類５０６は、通報の内容が、エラー、注文、定期メンテナンス等のいずれの分類に属するかを示す。内容５０７は、通報の具体的内容を示す。

【0043】

設置場所５０８は、通報に対応するインシデントが発生したデバイスの設置場所を示す。通報者５０９は、通報を行った者を特定する情報を示す。サービスマン５１０は、通報に応じて出動したサービスマンを特定する情報を示す。
以上のようなインシデントデータが記憶される。

【0044】

インシデントは、あくまでもイベント（状態）であり、そのインシデントを引き起こした原因を含まない。即ち、インシデントは、原因と分離されて管理される。インシデント管理の目的は、インシデントで中断されたデバイス利用を一刻も早く復旧させて、業務の停滞を最小限に抑えることである。

【0045】

よって、インシデントデータを、発生件数の増減、傾向、解決時間等を分析し、デバイス（関連したサービスを含む）について、デバイスの提供側と顧客側で評価し、インシデント発生原因の究明、改善ポイントの洗い出し、よりよい利用方法の提案、よりよい製品の開発やサービスの向上に結びつけるためには、インシデント管理単体ではなく、インシデントデータを、デバイス管理の一連の流れの中のひとつの要素として捉える必要がある。

【0046】

本実施例では、インシデント管理装置１２０は、定期的に、インシデント管理装置１２０のＨＤＤ２１１からインシデントデータを読み出し、デバイス管理装置１１０に送信する。または、デバイス管理装置１１０からの要求に応じて、インシデント管理装置１２０がインシデントデータを読み出し、デバイス管理装置１１０に送信する構成でもよい。

【0047】

デバイス管理装置１１０は、インシデント管理装置１２０が送信したインシデントデータを受信し、デバイス管理装置１１０のＨＤＤ２１１に保持する。
さらに、デバイス管理装置１１０は、上記インシデントデータと、デバイス管理装置１１０で管理する顧客情報（後述するエラー情報等）とを対応付け（振り分け）、該対応付けられた顧客情報を用いて、インシデントデータを含めたデバイスの使用状況レポートを生成し提供する。以下、詳細に説明する。

【0048】

デバイス管理装置１１０のＣＰＵ２０１は、インシデントデータの振り分け先の顧客が特定できた場合、そのインシデントデータを該当顧客のレポートに含めてレポート出力する。そして、出力されたレポート（インシデントデータを含めたレポート）を顧客に提供する。

【0049】

このレポートの提供を含む、インシデントデータを一要素としたデバイス管理を行うことによって、デバイス及びデバイスに関連したサービスについて、デバイスの提供側と顧客側で評価を行い、インシデント発生原因の究明、改善ポイントの洗い出し、よりよい利用方法の提案、よりよい製品の開発やサービスの向上に結びつけることが可能となる。その結果、顧客側では、デバイスの利用に対する顧客満足度の向上、デバイスの可用性の向上、業務の効率化、やり直しと損失時間の削減、コスト削減等を実現することが可能となる。また、デバイス提供側では、デバイスの使用状況や運用コスト等の集計や、デバイスのセッティングの集中管理、ジョブマネジメントの強化、顧客の環境に合わせた適切なサービスの提供、新たなデバイスやサービスメニューの開発、さらなるビジネスの効率化と新たな付加価値の提案、さらなるコスト削減を実現する最適配置提案等が可能となる。

【0050】

なお、デバイス管理システムはデバイス販売会社等で運用され、一方、インシデント管理システムはサービスセンター等で運用される等のように、各システムの運用元が異なる場合がある。この場合、顧客の契約単位が異なる可能性があり、それぞれのシステムで管理されている顧客の管理単位が異なる可能性がある。即ち、インシデント管理装置１２０とで、管理している顧客単位が異なる可能性がある。

【0051】

このため、本実施例のデバイス管理装置１１０では、デバイス管理装置１１０で管理している顧客と、インシデント管理装置１２０で管理している顧客との関連付け情報を設定し、該情報を図３に示すようなテーブルに保持する。

【0052】

図３は、デバイス管理装置１１０が管理する顧客と、インシデント管理装置１２０が管理する顧客の関連付け情報を保持する顧客関連付けテーブルの一例を示す図である。なお、図３に示す顧客関連付けテーブルは、デバイス管理装置１１０のＨＤＤ２１１に記憶される。

【0053】

図３に示すように、本実施例の顧客関連付けテーブルに記憶される顧客関連付け情報は、デバイス管理装置１１０が管理する顧客情報３０１と、インシデント管理装置１２０が管理する顧客情報３０２とを関連付けるものである。

【0054】

即ち、この顧客関連付けテーブルにより、デバイス管理テーブルの顧客６０１（図６）とインシデントデータテーブルの顧客ＩＤ５０２（図５）とを関連付けることができる。

【0055】

図３の例では、デバイス管理装置１１０が管理する「顧客Ａ」および「顧客Ｂ」と、インシデント管理装置１２０が管理する「顧客１」が関連づけられている。また、デバイス管理装置１１０が管理する「顧客Ｃ」と、インシデント管理装置１２０が管理する「顧客２」および「顧客３」が関連づけられている。また、デバイス管理装置１１０が管理する「顧客Ｄ」と、インシデント管理装置１２０が管理する「顧客４」が関連づけられている。

【0056】

デバイス管理装置１１０は、インシデント管理装置１２０からインシデントデータを取得して、インシデントデータの解析を実行し、該インシデントデータ内の顧客ＩＤ５０２を用いて、該インシデントデータをデバイス管理装置１１０が管理する該当顧客に振り分ける。

【0057】

例えば、取得したインシデントデータの顧客ＩＤ５０２が「顧客２」又は「顧客３」であった場合、デバイス管理装置１１０は、自身が管理する「顧客Ｃ」に該インシデントデータを振り分ける。また、取得したインシデントデータの顧客ＩＤが「顧客４」であった場合、デバイス管理装置１１０は、自身が管理する「顧客Ｄ」に該インシデントを振り分ける。

【0058】

次に、取得したインシデントデータの顧客ＩＤが「顧客１」であった場合について説明する。デバイス管理装置１１０では、図３に示したように、自身が管理する「顧客Ａ」および「顧客Ｂ」に、インシデント管理装置１２０が管理する「顧客１」が関連づけられている。このため、デバイス管理装置１１０は、顧客ＩＤだけでは、顧客ＩＤ５０２が「顧客１」であるインシデントデータを、自身が管理する「顧客Ａ」と「顧客Ｂ」のどちらに振り分けるべきか、判断ができない。

【0059】

以下、図４を参照して、本発明の実施例１におけるインシデントデータの顧客振り分け処理について説明する。
図４は、本発明の実施例１におけるインシデントデータの顧客振り分け処理の一例を示すフローチャートである。このフローチャートの処理は、デバイス管理装置１１０のＣＰＵ２０１がＨＤＤ２１１にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより実現されるものである。なお、図中、Ｓ４００〜Ｓ４１３は各ステップを示す。

【0060】

デバイス管理装置１１０のＣＰＵ２０１は、インシデント管理装置１２０からインシデントデータを取得すると、図４（ａ）のフローチャート処理を開始する。
まず、デバイス管理装置１１０のＣＰＵ２０１は、上記取得した全てのインシデントデータに対して、Ｓ４０１〜Ｓ４０５に示す処理を実行するように制御する（Ｓ４００）。
まず、Ｓ４０１において、デバイス管理装置１１０のＣＰＵ２０１は、受信したインシデントデータの中から未処理のインシデントデータを１つ取得し、該取得したインシデントデータ（以下、現在のインシデントデータ）を解析し、現在のインシデントデータにデバイスＩＤが含まれているかを確認する。

【0061】

例えば、現在のインシデントデータが、図５のインシデントＮｏ.「１０００」の場合、デバイスＩＤ５０３に「ＤｅｖＤ１００」が格納されているので、Ｓ４０１でＹｅｓと判定されることになる。また、現在のインシデントデータが、図５のインシデントＮｏ.「１００１」の場合、デバイスＩＤ５０３にデバイスＩＤが格納されていないため、Ｓ４０１でＮｏと判定されることになる。

【0062】

上記Ｓ４０１において、現在のインシデントデータにデバイスＩＤが含まれていないと判定した場合（Ｓ４０１でＮｏの場合）、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４００に処理を戻す。

【0063】

一方、現在のインシデントデータにデバイスＩＤが含まれていると判定した場合（Ｓ４０１でＹｅｓの場合）、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４０２に処理を進める。

【0064】

Ｓ４０２では、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータに含まれる顧客ＩＤ５０２と顧客関連付けテーブル（図３）で関連付けされているデバイス管理装置１１０が管理する顧客情報３０１を、対応付けの候補となる顧客（候補顧客）と特定する。さらに、デバイス管理装置１１０のＣＰＵ２０１は、上記候補顧客とデバイス情報テーブル（図６）で関連付けされているデバイスＩＤ６０２のうちに、現在のインシデントデータに含まれているデバイスＩＤ５０３と一致するものがあるか判定する。

【0065】

上記Ｓ４０２において、候補顧客のデバイスＩＤ６０２のうち、現在のインシデントデータに含まれているデバイスＩＤ５０３と一致するものがないと判定した場合（Ｓ４０２でＮｏの場合）、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４００に処理を戻す。

【0066】

一方、候補顧客のデバイスＩＤ６０２のうち、現在のインシデントデータに含まれているデバイスＩＤ５０３と一致するものがあると判定した場合（Ｓ４０２でＹｅｓの場合）、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４０３に処理を進める。

【0067】

Ｓ４０３では、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータに対応するインシデントを、上記Ｓ４０２で一致するデバイスＩＤを持つと判定した顧客のインシデントと判断する（振り分ける）。さらに、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータと振り分け先の顧客情報をデバイス管理装置１１０のＨＤＤ２１１に記録し（例えば、実施例２の図９（ａ）に示すようなテーブルの形式）、Ｓ４０４に処理を進める。

【0068】

Ｓ４０４では、デバイス管理装置１１０のＣＰＵ２０１は、デバイス管理装置１１０のＨＤＤ２１１内のエラー情報テーブル（図７）から、現在のインシデントデータに含まれているデバイスＩＤに対応するデバイスのエラー情報であって、まだインシデントデータと対応つけられていないもの（対応インシデントＮｏ.７０５にデータが格納されていないもの）を、候補エラー情報として全て読み出して、Ｓ４０５に処理を進める。

【0069】

Ｓ４０５では、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータと上記Ｓ４０４で読み出したエラー情報（候補エラー情報）とのマッチングを行う（図４（ｂ）のマッチング処理）。ここで、図４（ｂ）を用いて、実施例１のマッチング処理については説明する。

【0070】

以下、図４（ｂ）を用いて、上記Ｓ４０５及び後述するＳ４０８のマッチング処理について詳細に説明する。
図４（ｂ）は、本発明の実施例１におけるマッチング処理の詳細を示すフローチャートである。
まず、Ｓ４１０において、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータのインシデントの分類５０６及び内容５０７から、現在のインシデントがデバイスエラー発生前に顧客から通報される可能性があるものかどうかを判定する。なお、デバイスエラー発生前に顧客から通報される可能性があるものを判別するための条件は、予めデバイス管理装置１１０に設定しておく。例えば、分類５０６が「注文」で内容５０７が「Ａ４用紙」の場合、デバイスで紙切れエラーが発生する前に顧客が通報する可能性があるため、デバイスエラー発生前に顧客から通報される可能性があるインシデントと設定しておく。

【0071】

そして、デバイスエラー発生前に顧客から通報される可能性があると判定した場合（Ｓ４１０でＹｅｓの場合）、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４１１に処理を進める。

【0072】

Ｓ４１１では、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータの通報時刻５０４と、エラー発生時刻７０３との時間差が一定期間内である候補エラー情報を対象に、現在のインシデントデータとのマッチングを行い、Ｓ４１３に処理を進める。なお、Ｓ４１１の「一定期間」は、顧客毎に設定できるようにしてもよい。

【0073】

一方、デバイスエラー発生前に顧客から通報される可能性がないと判定した場合（Ｓ４１０でＮｏの場合）、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４１２に処理を進める。

【0074】

Ｓ４１２では、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータの通報時刻５０４よりエラー発生時刻７０３が前の候補エラー情報を対象に、現在のインシデントデータとのマッチングを行い、Ｓ４１３に処理を進める。

【0075】

Ｓ４１３では、デバイス管理装置１１０のＣＰＵ２０１は、上記Ｓ４１１又はＳ４１２でマッチングされたマッチング情報（インシデントデータとエラー情報の対応情報）を保存する。即ち、現在のインシデントデータとマッチングされたエラー情報内の対応インシデントＮｏ.７０５に、現在のインシデントデータのインシデントＮｏ.５０１の値を格納し、デバイス管理装置１１０のＨＤＤ２１１に保持する。

【0076】

以上示したように、マッチング処理（図４（ｂ））では、インシデントデータに含まれる時刻情報（通報時刻５０４）とエラー情報に含まれる時刻情報（エラー発生時刻７０３）を、インシデントデータの内容（分類５０６、内容５０７）に応じた比較条件（Ｓ４１１又はＳ４１２）で比較し、比較条件と合致したエラー情報を抽出し、マッチングを行う。以上により、図４（ｂ）のマッチング処理を終了し、図４（ａ）に処理を戻す。

【0077】

以下、図４（ａ）の説明に戻る。
上記Ｓ４０５の処理を終了すると、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４００に処理を戻す。
そして、上記Ｓ４００において、デバイス管理装置１１０のＣＰＵ２０１は、取得した全てのインシデントデータに対して、Ｓ４０１〜Ｓ４０５に示す処理を終了したと判定した場合（Ｓ４００でＹｅｓの場合）、Ｓ４０６に処理を進める。

【0078】

Ｓ４０６では、デバイス管理装置１１０のＣＰＵ２０１は、上記取得したインシデントデータのうち、未振り分けのインシデントデータが存在するか判定する。
そして、未振り分けのインシデントデータが存在すると判定した場合（Ｓ４０６でＹｅｓの場合）、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４０７に処理を進める。
Ｓ４０７では、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータに含まれる顧客ＩＤ５０２と顧客関連付けテーブル（図３）で関連付けされているデバイス管理装置１１０が管理する顧客情報３０１を、候補顧客と特定する。さらに、デバイス管理装置１１０のＣＰＵ２０１は、上記各候補顧客とデバイス情報テーブル（図６）で関連付けされているデバイスＩＤ６０２に対応するエラー情報であって、まだインシデントデータと対応つけられていないもの（対応インシデントＮｏ.７０５にデータが格納されていないもの）を、候補エラー情報として全て読み出して、Ｓ４０８に処理を進める。

【0079】

Ｓ４０８では、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータと上記Ｓ４０７で読み出したエラー情報（候補エラー情報）とのマッチングを行う（図４（ｂ）のマッチング処理）。

【0080】

そして、上記Ｓ４０８のマッチング処理を終了すると、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ４０９に処理を進める。
Ｓ４０９では、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータに対応するインシデントを、上記Ｓ４０８でマッチングされたエラー情報のデバイスＩＤ７０２に対応する顧客６０１に振り分ける。そして、デバイス管理装置１１０のＣＰＵ２０１は、現在のインシデントデータと振り分け先の顧客情報をデバイス管理装置１１０のＨＤＤ２１１に記録し（例えば、実施例２の図９（ａ）に示すようなテーブルの形式）、Ｓ４０６に処理を戻す。

【0081】

なお、図４（ｂ）のＳ４１１において、現在のインシデントデータの通報時刻５０４と、エラー発生時刻７０３との時間差が一定期間内である候補エラー情報が存在しない場合、または、Ｓ４１２において、現在のインシデントデータの通報時刻５０４よりエラー発生時刻７０３が前の候補エラー情報が存在しない場合、現在のインシデントデータを「振り分けできないインシデントデータ」とし、「未振り分けのインシデントデータ」とは区別するようにしてもよい。なお、デバイス管理装置１１０のＣＰＵ２０１は、「振り分けできないインシデントデータ」を、デバイス管理システムの担当者に通知するようにしてもよい。

【0082】

そして、上記Ｓ４０６において、デバイス管理装置１１０のＣＰＵ２０１は、未振り分けのインシデントデータが存在しないと判定した場合（Ｓ４０６でＮｏの場合）、本フローチャートの処理を終了する。

【0083】

以下、図５に示したインシデントデータを用いて、上記図４に示したインシデントデータの顧客振り分け処理について具体的に説明する。
まず、インシデントＮｏ.「１０００」のインシデントデータを解析する例を説明する。
インシデントＮｏ.「１０００」のインシデントデータは、デバイスＩＤ「ＤｅｖＤ１００」を含む（Ｓ４０１でＹｅｓ）。また、インシデントＮｏ.「１０００」のインシデントデータは、顧客ＩＤ「顧客１」を含み、「顧客１」は「顧客Ａ」及び「顧客Ｂ」と対応付けられているため（図３）、この２顧客がインシデント振り分け先の候補であると判断される。また、「顧客Ａ」はデバイスＩＤ「ＤｅｖＤ１００」及び「ＤｅｖＤ１０１」と対応付けられ、「顧客Ｂ」はデバイスＩＤ「ＤｅｖＤ１０２」と対応付けられている（図６）また、「顧客Ａ」に含まれるデバイスＩＤ「ＤｅｖＤ１００」は、インシデントＮｏ.「１０００」のデバイスＩＤ「ＤｅｖＤ１００」と一致する（Ｓ４０２でＹｅｓ）。よって、インシデントＮｏ.「１０００」のインシデントデータは、「顧客Ａ」に振り分けられる（Ｓ４０３）。次に、デバイスＩＤ「ＤｅｖＤ１００」のエラー情報が読み出され（Ｓ４０４）、インシデントＮｏ.「１０００」のインシデントデータと、上記読みだされたデバイスＩＤ「ＤｅｖＤ１００」のエラー情報のマッチング処理が行われる（Ｓ４０５）。インシデントＮｏ.「１０００」のインシデントデータは、分類５０６が「エラー」で内容５０７が「ジャム」であるので、ジャム発生前に顧客が通報する可能性は無い（Ｓ４１０でＮｏ）。そのため、上記Ｓ４０４で読みだされたエラー情報のうち、エラー発生時刻７０３が通報時刻５０４よりも前のエラー情報でマッチングされる（Ｓ４１２）。ここでは、エラーＮｏ.７０１「６０００」のエラー情報とマッチングされる。そして、エラーＮｏ.７０１「６０００」のエラー情報の対応インシデントＮｏ.７０５に「１０００」が保持される（Ｓ４１３）。

【0084】

次に、インシデントＮｏ.「１００１」のインシデントデータを解析する例を説明する。
インシデントＮｏ.「１００１」のインシデントデータは、デバイスＩＤを含まない（Ｓ４０１でＮｏ）。また、インシデントＮｏ.「１００１」のインシデントデータは、顧客ＩＤ「顧客１」を含み、「顧客１」は「顧客Ａ」及び「顧客Ｂ」と対応付けられているため（図３）、この２顧客がインシデント振り分け先の候補であると判断される。また、「顧客Ａ」はデバイスＩＤ「ＤｅｖＤ１００」及び「ＤｅｖＤ１０１」と対応付けられ、「顧客Ｂ」はデバイスＩＤ「ＤｅｖＤ１０２」と対応付けられている（図６）。よって、デバイスＩＤ「ＤｅｖＤ１００」、「ＤｅｖＤ１０１」、又は「ＤｅｖＤ１０２」を含み、対応インシデントＮｏ.７０５が空白であるエラー情報が全て読みだされる（Ｓ４０７）。ここでは、エラーＮｏ.「６００１」のエラー情報が読み出される。そして、インシデントＮｏ.「１００１」のインシデントデータと、上記読みだされたエラーＮｏ.「６００１」のエラー情報のマッチング処理が行われ、エラーＮｏ.７０１「６００１」のエラー情報とマッチングされる（Ｓ４０８）。なお、マッチング処理の詳細は、インシデントＮｏ.「１０００」のインシデントデータの場合と同様であるので説明は省略する。そして、インシデントＮｏ.「１００１」のインシデントデータは、エラーＮｏ.７０１「６００１」のエラー情報に対応するデバイスＩＤ「ＤｅｖＤ１０２」に対応付けられている「顧客Ｂ」に振り分けられる（Ｓ４０９）。

【0085】

次に、インシデントＮｏ.「１００２」のインシデントデータを解析する例を説明する。
インシデントＮｏ.「１００２」のインシデントデータは、デバイスＩＤを含まない（Ｓ４０１でＮｏ）。また、インシデントＮｏ.「１００２」のインシデントデータは、顧客ＩＤ「顧客３」を含み、「顧客３」は「顧客Ｃ」と対応付けられているため（図３）、この「顧客Ｃ」がインシデント振り分け先の候補であると判断される。また、「顧客Ｃ」はデバイスＩＤ「ＤｅｖＤ２００」と対応付けられている（図６）。よって、デバイスＩＤ「ＤｅｖＤ２００」を含み、対応インシデントＮｏ.７０５が空白であるエラー情報が全て読みだされる（Ｓ４０７）。ここでは、エラーＮｏ.「６００２」のエラー情報が読み出される。そして、インシデントＮｏ.「１００２」のインシデントデータと、上記読みだされたエラーＮｏ.「６００２」のエラー情報のマッチング処理が行われる（Ｓ４０８）。インシデントＮｏ.「１００２」のインシデントデータは、分類５０６が「注文」で内容５０７が「Ａ４用紙」であるので、デバイスで紙切れエラーが発生する前に、顧客が通報する可能性がある（Ｓ４１０でＹｅｓ）。そのため、上記Ｓ４０７で読みだされたエラー情報のうち、エラー発生時刻７０３と通報時刻５０４の近さが一定時間以内のエラー情報とマッチングされる。ここでは、エラーＮｏ.７０１「６００２」のエラー情報とマッチングされる。そして、エラーＮｏ.７０１「６００２」のエラー情報の対応インシデントＮｏ.７０５に「１００２」が保持される（Ｓ４１３）。そして、インシデントＮｏ.「１００２」のインシデントデータは、エラーＮｏ.７０１「６００２」のエラー情報に対応するデバイスＩＤ「ＤｅｖＤ２００」に対応付けられている「顧客Ｃ」に振り分けられる（Ｓ４０９）。

【0086】

以上、図４のフローチャートの説明を終了する。以上、図４に示したインシデントデータの顧客振り分け処理により、デバイス管理装置１１０は、インシデント管理装置１２０で管理されているインシデントデータと、デバイス管理装置１１０で管理されている顧客の情報、及びエラー情報を対応付けることができる。

【0087】

なお、デバイスＩＤで顧客に振り分けられたインシデントデータに関しては、振り分けた結果が確実である。しかし、デバイスＩＤで顧客に振り分けられなかったインシデントに関しては、振り分けた結果が確実ではない場合がある。そのため、デバイス管理装置１１０のＣＰＵ２０１は、デバイスＩＤで顧客に振り分けられなかったインシデントに関しては、デバイス設置場所や通報者など、セキュリティ上、他の顧客に知られては問題のある項目をマスクして出力するようにしてもよい。もしくは、この場合、レポート出力する前に、候補顧客を管理するデバイス販売会社の担当者に、振り分け結果を通知してもよい。通知方法としては、予め設定された担当者のメールアドレスに、前記振り分け結果を送信する構成でもよい。また、デバイス管理装置１１０のＣＰＵ２０１は、図４に示した処理で振り分け先の顧客が特定できなかったインシデントデータに関しても、同様に、候補顧客を管理するデバイス販売会社の担当者に結果を通知するようにしてもよい。

【0088】

以上説明したように、インシデント管理システムと、デバイス管理システムがそれぞれ管理する顧客単位が異なる場合において、インシデントデータにデバイスＩＤが無くても、エラー情報などの値を用いることで、インシデントの振り分け先の顧客を特定することができる。また、それにより顧客に最適なレポートを提供することが可能となる。

【0089】

すなわち、インシデント管理システムから取得したインシデントデータの情報が不足している場合でも、適切な顧客にインシデントを振り分け、最適なレポートを顧客に提供することができる。

【0090】

なお、上述の実施例では、デバイス管理装置１１０が、デバイス１３０と通信して、デバイス１３０のエラー発生状況を取得する例を示したが、デバイス管理装置１１０は、外部のシステムからエラー発生状況を取得しても良い。以下、この実施例について図１（ｂ）を用いて説明する。

【0091】

図１（ｂ）は、デバイス管理装置１１０が障害・在庫管理装置１４０と連携して動作を行う場合の構成例を示す図である。なお、図１（ａ）と同一のものには同一の符号を付してある。

【0092】

障害・在庫管理システムを構成する障害・在庫管理装置１４０は、デバイス管理装置１１０と同じく、図２の構成を有するコンピュータであり、インターネット上に配置する。なお、障害・在庫管理システムは、デバイス管理システムとは別のシステムであり、デバイス１３０の障害を管理する。

【0093】

障害・在庫管理装置１４０は、デバイス１３０のエラー発生状況の管理やトナーや用紙などの消耗品の在庫管理を行う機能と、自身が管理するエラー発生状況および在庫管理情報を外部のシステムに提供するためのＷｅｂインターフェイスを持つ。

【0094】

デバイス管理装置１１０は、障害・在庫管理装置１４０からデバイスのエラー発生状況を取得することで、デバイス１３０から直接エラー発生状況を取得しなくても、本実施例を実現可能である。

【実施例2】

【0095】

実施例２では、デバイスＩＤで顧客に振り分けられなかったインシデントに関しては、振り分けた結果が確実ではないため、該当顧客が特定できないインシデントデータとし、過去にインシデントデータを顧客に振り分けた実績を使用して顧客を特定する。すなわち、実施例２では、インシデントデータと、顧客を特定済みの過去のインシデントデータとを比較し、前記インシデントデータと類似する過去のインシデントデータに対して特定済みの顧客を、前記インシデントデータに対応する顧客に特定する。なお、実施例１と同様の構成や手順については、その詳細説明を省略する。

【0096】

以下、図８を用いて、デバイスＩＤで顧客に振り分けられなかったインシデントの顧客の特定方法（デバイスが特定できないインシデントデータの顧客振り分け処理）について説明する。

【0097】

図８は、本発明の実施例２におけるデバイスが特定できないインシデントデータの顧客振り分け処理の一例を示すフローチャートである。このフローチャートの処理は、デバイス管理装置１１０のＣＰＵ２０１がＨＤＤ２１１にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより実現されるものである。なお、図中、Ｓ８００〜Ｓ８０５は各ステップを示す。

【0098】

デバイス管理装置１１０のＣＰＵ２０１は、実施例１で説明したインシデントデータの顧客振り分け処理（図４）で顧客が特定できなかった各インシデントデータに対してそれぞれ図８の処理を実行する。

【0099】

まず、デバイス管理装置１１０のＣＰＵ２０１は、インシデントデータに含まれる顧客ＩＤ５０２と顧客関連付けテーブル（図３）で関連付けされているデバイス管理装置１１０が管理する顧客情報３０１を、対応付けの候補となる顧客（候補顧客）と特定する。さらに、デバイス管理装置１１０のＣＰＵ２０１は、該候補顧客の一定期間内の過去のインシデント振り分け実績レコード（図９（ａ））を、ＨＤＤ２１１から読み出す（Ｓ８００）。

【0100】

図９（ａ）は、過去のインシデント振り分け実績を格納したテーブルの一例を示す図である。
デバイス管理装置１１０のＣＰＵ２０１は、インシデントに該当するデバイスが判別でき、顧客に振り分けることができると、インシデントデータと振り分け先顧客情報を、図９（ａ）に示すようなテーブルの形式で、デバイス管理装置１１０のＨＤＤ２１１に保存する。即ち、振り分け先顧客情報を、対応するインシデントの振り分け先顧客５１１に保存する。

【0101】

図９（ａ）の例は、インシデントＮｏ.「９９９」を「顧客Ａ」に、インシデントＮｏ.「９９８」および「９９７」を「顧客Ｂ」に振り分けたことを示している。このように、デバイス管理装置１１０は、顧客を特定済みの過去のインシデントデータを保持する。

【0102】

以下、図８のフローチャートの説明に戻る。
次に、Ｓ８０１において、デバイス管理装置１１０のＣＰＵ２０１は、候補顧客の一定期間内の過去のインシデント振り分け実績レコードの全てに対して、Ｓ８０２、Ｓ８０３の処理（確認）を実行するように制御する。

【0103】

まず、Ｓ８０２において、デバイス管理装置１１０のＣＰＵ２０１は、まだ確認していないインシデント振り分け実績レコード（過去のレコード）を読み出し、該読み出した過去のレコードと今回振り分けるインシデントデータの各項目を比較する。

【0104】

図５のインシデントＮｏ.「１００１」を例にあげて説明する。
インシデントＮｏ.「１００１」は、顧客ＩＤが「顧客１」であるため、図３の顧客の関連付けから、デバイス管理システムが管理する「顧客Ａ」および「顧客Ｂ」が、振り分け先顧客の候補となる。したがって、図９（ａ）の実績レコードにおいては、
「顧客Ａ」のインシデントであるインシデントＮｏ.「９９９」、及び、「顧客Ｂ」のインシデントであるインシデントＮｏ.「９９８」、「９９７」を比較対象とする。

【0105】

比較する項目は、例えば、設置場所５０８、通報者５０９、サービスマン５１０など、インシデントデータの中で、顧客を特定できる可能性のある項目とする。また、比較対象のレコードは、古いデータの場合、設置場所など変更されている可能性があるため、一定期間以内のレコードを対象とする。図５のインシデントＮｏ.「１００１」については、設置場所５０８が「オフィスＡ ３Ｆ」、通報者５０９が「Ｊ」、サービスマン５１０が「Ｘ」のいずれかと一致する過去のデータを検索する。

【0106】

図９の実績レコードにおいて、インシデントＮｏ.「９９９」は、設置場所５０８と通報者５０９がインシデントＮｏ.「１００１」と一致している。インシデントＮｏ.「９９８」は、サービスマン５１０がインシデントＮｏ.「１００１」一致している。インシデントＮｏ.「９９７」はインシデントＮｏ.「１００１」と一致している項目が無い。

【0107】

デバイス管理装置１１０のＣＰＵ２０１は、項目ごとに重み付けを行い（重みを付与し）、一致したレコードごとに値（スコア）を算出する（Ｓ８０３）。
例えば、設置場所５０８が同じであれば、同じ顧客である可能性は高いので、重み付け大（例えば「１０」とする）。次に、通報者５０９を重み付け「５」、サービスマン５１０は、複数顧客を受け持っている可能性があるため、重み付け「１」とする。この他、日付が近いレコードの方が現在とデバイスに関する情報が変わっていない可能性が高いため、レコードの日付によって重み付けを変えても良い。

【0108】

上述の例では、インシデントＮｏ.「９９９」のスコアが「１０＋５＝１５」、インシデントＮｏ.「９９８」のスコアが「１」、インシデントＮｏ.「９９７」のスコアが「０」となる。スコア算出（Ｓ８０３）が終了すると、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ８０１に処理を戻す。

【0109】

デバイス管理装置１１０のＣＰＵ２０１は、まだ確認していない一定期間内の過去のレコードが存在するかどうかを判定し、まだ確認していない一定期間内の過去のレコードが存在すると判定した場合（Ｓ８０１でＹｅｓの場合）、Ｓ８０２、Ｓ８０３の処理を実行する。

【0110】

一方、確認していない一定期間内の過去のレコードが存在しないと判定した場合（Ｓ８０１でＮｏの場合）、デバイス管理装置１１０のＣＰＵ２０１は、Ｓ８０４に処理を進める。

【0111】

Ｓ８０４では、デバイス管理装置１１０のＣＰＵ２０１は、上記Ｓ８０３で算出したスコアの最も高い過去のレコードの振り分け先顧客５１１が、インシデントデータの振り分け先であると判断し、該スコアの最も高い過去のレコードの振り分け先顧客を確認する。上述の例では、スコアの値から、インシデントＮｏ.「９９９」の振り分け先顧客５１１に格納されている「顧客Ａ」を、インシデントＮｏ.「１００１」の振り分け先顧客であると判断する。即ち、上記算出されたスコアは、過去のインシデントデータとの類似度を示すものであり、類似度の高い過去のインシデントデータに対して特定済みの顧客を、振り分け先顧客と判断する。

【0112】

次に、デバイス管理装置１１０のＣＰＵ２０１は、インシデントＮｏ.「１００１」を「顧客Ａ」に振り分けて、インシデントデータと振り分け先顧客５１１の情報を、図９（ａ）に示すようなテーブルの形式で、デバイス管理装置１１０のＨＤＤ２１１に保存する。そして、本フローチャートの処理を終了する。

【0113】

以上のように、インシデントデータに含まれる各項目の情報と、過去のインシデントデータに含まれる各項目の情報を比較し、一致した項目に付与された重みに応じて類似度を算出し、該類似度の高い過去のインシデントデータに対して特定済みの顧客を、前記インシデントデータに対応する顧客に特定することにより、デバイスＩＤで顧客に振り分けられなかったインシデントデータであっても、過去の振り分け実績に基づいて、顧客を振り分けることができる。

【実施例3】

【0114】

実施例３では、インシデントデータからインシデントの該当顧客が特定できない場合、かつインシデントの分類５０６が定期的な内容である場合、過去の実績を使用して顧客を特定する方法を説明する。

【0115】

実施例１および実施例２と同様の構成や手順については、その詳細説明を省略する。
以下は、実施例１で説明した顧客ＩＤおよびデバイスＩＤを使用してインシデントに対応する顧客を特定する方法で顧客が特定できなかった場合の、顧客の特定方法である。
デバイス管理装置１１０のＣＰＵ２０１は、振り分け先の候補となる顧客の過去のインシデント振り分け実績レコードを、デバイス管理装置１１０のＨＤＤ２１１から読み出す。

【0116】

ここでは、図５のインシデントＮｏ.「１００４」を振り分ける場合を例に説明する。
インシデントＮｏ.「１００４」は、顧客ＩＤが「顧客１」であるため、図３の顧客の関連付けから、デバイス管理装置１１０が管理する「顧客Ａ」および「顧客Ｂ」が、候補顧客となる。

【0117】

振り分けを行うインシデントの分類５０６が「定期メンテナンス」である場合、デバイス管理装置１１０のＣＰＵ２０１は、候補顧客の実績レコードから、分類５０６が「定期メンテナンス」であるものを抽出する。

【0118】

図９（ｂ）は、過去のインシデント振り分け実績を格納したテーブルの一例を示す図である。
図９（ｂ）の例の場合、顧客ＩＤ５０２が候補顧客である「顧客Ａ」又は「顧客Ｂ」であって、分類５０６が「定期メンテナンス」であるレコードは、インシデントＮｏ.「９２０」およびインシデントＮｏ.「９９５」である。

【0119】

インシデントＮｏ.「９２０」の出動時刻５０５は「２０１２／４／１５・・・」で、インシデントＮｏ.「９９５」の出動時刻５０５は「２０１２／５／１５・・・」であることから、デバイス管理装置１１０のＣＰＵ２０１は、「顧客Ａ」では、１ヶ月に１回、「定期メンテナンス」が行われているものと判断する。即ち、デバイス管理装置１１０のＣＰＵ２０１は、「顧客Ａ」における「定期メンテナンス」の発生周期を推定する。

【0120】

実績レコードに、「顧客Ａ」に対する「６月」分の「定期メンテナンス」のインシデントデータが存在しないため、デバイス管理装置１１０のＣＰＵ２０１は、インシデントＮｏ.「１００４」の出動時刻５０５が「２０１２／６／１５・・・」であることから、「顧客Ａ」に対する「６月」分の「定期メンテナンス」であると判断する。すなわち、推定した発生周期と、インシデントデータに含まれる時刻情報（出動時刻５０５）が合致すると判断する。

【0121】

そして、デバイス管理装置１１０のＣＰＵ２０１は、インシデントＮｏ.「１００４」を「顧客Ａ」に振り分けて、インシデントデータと振り分け先顧客５１１の情報を、図９（ｂ）に示すようなテーブルの形式で、デバイス管理装置１１０のＨＤＤ２１１に保存する。

【0122】

以上の処理により、デバイスＩＤで顧客に振り分けられなかったインシデントデータであっても、インシデントの分類５０６が「定期メンテナンス」である場合、過去の振り分け実績に基づいて、顧客を振り分けることができる。

【実施例4】

【0123】

実施例４では、インシデントの該当顧客が特定できない場合、デバイスごとのエラー発生実績を使用して顧客を特定する方法を説明する。
実施例１および実施例２と同様の構成や手順については、その詳細説明を省略する。
以下は、実施例１で説明した顧客ＩＤおよびデバイスＩＤを使用してインシデントに対応する顧客を特定する方法で顧客が特定できなかった場合の、顧客の特定方法である。
デバイス管理装置１１０のＣＰＵ２０１は、振り分け先の候補となる顧客（候補顧客）の過去のインシデント振り分け実績レコードをＨＤＤ２１１から読み出す。
図５のインシデントＮｏ.「１００５」を振り分ける場合を説明する。
インシデントＮｏ.「１００５」は、顧客ＩＤが「顧客１」であるため、図３の顧客の関連付けから、デバイス管理装置１１０が管理する「顧客Ａ」および「顧客Ｂ」が、候補顧客となる。

【0124】

インシデントＮｏ.「１００５」は、分類５０６が「エラー」で内容５０７が「ジャム（発生個所：Ｊ１）」である。
デバイス管理装置１１０のＣＰＵ２０１は、候補顧客の実績レコードから分類５０６が「エラー」で内容が「ジャム（発生個所：Ｊ１）」であるものを抽出する。
デバイス個体の特性として、ある特定のエラーが起こりやすい場合がある。そのため、あるデバイスで特定のエラーが一定回数以上発生している実績があれば、同様のエラーのインシデントは、そのデバイスに該当する可能性が高いと判断できる。

【0125】

図９（ｂ）の例の場合、顧客ＩＤ５０２が候補顧客である「顧客Ａ」又は「顧客Ｂ」であって、分類５０６が「エラー」で内容５０７が「ジャム（発生個所：Ｊ１）」であるのはインシデントＮｏ.「９９３」および「９９４」である。いずれもデバイスＩＤ５０３は「ＤｅｖＤ１００」となっている。

【0126】

そのため、デバイス管理装置１１０のＣＰＵ２０１は、インシデントＮｏ.「１００５」に対応するデバイスは、「ＤｅｖＤ１００」である可能性が高いと判断し、インシデントＮｏ.「１００５」を「顧客Ａ」に振り分けて、インシデントデータと振り分け先顧客５１１の情報を、図９（ｂ）に示すようなテーブルの形式で、デバイス管理装置１１０のＨＤＤ２１１に保存する。

【0127】

以上示したように、インシデントデータに含まれる障害情報と同一の障害情報を含む過去のインシデントデータを抽出し、該抽出した過去のインシデントデータに含まれる対象デバイスのデバイスＩＤから、前記同一の障害の発生頻度が高いデバイスを特定し、該特定されたデバイスが設置された顧客を、前記インシデントデータに対応する顧客と特定することにより、デバイスＩＤで顧客に振り分けられなかったインシデントデータであっても、インシデントの分類５０６が「エラー」である場合、過去の振り分け実績に基づいて、顧客を振り分けることができる。

【0128】

以上より、インシデント管理システムから取得したインシデントデータの情報が不足している場合でも、適切な顧客にインシデントを振り分け、最適なレポートを顧客に提供することができる仕組みを提供することである。

【0129】

即ち、インシデント管理システムと、デバイス管理システムがそれぞれ管理する顧客単位が異なる場合において、インシデントデータにデバイスＩＤが無くても、エラー情報などの値を用いることで、インシデントの振り分け先の顧客を特定することができる。また、それにより顧客に最適なレポートを提供することが可能となる。
上記実施例では、デバイスを画像形成装置として説明したが、デバイスはパーソナルコンピュータ等の情報処理装置やその他の電子器機であってもよい。

【0130】

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

【0131】

（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

【0132】

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

【符号の説明】

【0133】

１００ ネットワーク
１００１ デバイス管理装置
１００２ インシデント管理装置
１００３ デバイス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】