JP2014134870A - モニタリングシステム、及び計算機 - Google Patents

Abstract

【課題】被融資者個別の状況に基づく途上与信管理を実現する。
【解決手段】所定のイベントの発生の予兆を検知するモニタリングシステムであって、取得するモニタリングデータを特定するための収集設定情報と、属性別データを生成するためのユーザ属性管理情報と、検知パターンの種別及び時系列の組合せである検知モデルを管理する検知モデル情報と、検知パターンに対応する事象の内容を管理する検知パターン情報と、ユーザ属性毎に適用される検知モデルを定義する検知モデル設定情報と、を保持し、収集設定情報に基づいてモニタリングデータを取得するデータ収集部と、ユーザ属性管理情報に基づいて属性別データを生成するデータ抽出部と、属性別データを取得し、検知モデル情報、検知モデル設定情報、及び属性別データに基づいて、ユーザ属性毎に所定のイベントの発生の予兆を検知する検知部と、を有する。
【選択図】図２

Description

本発明は、所定のイベント発生の予兆を検知するモニタリングシステムに関する。

本技術分野の背景技術として、特許文献１がある。特許文献１には、「職種と金額とを予め関連付けて記録する個人信用力記録手段と、被融資者の職種に関する情報を取得する職種情報取得手段と、該職種情報取得手段で取得された被融資者の職種により前記個人信用力記録手段の記録内容を検索し、前記職種に予め関連付けられている金額を被融資者の個人信用力として評定する個人信用力評定手段と、融資の実行の際に設定した担保の現在の評価額に関する情報を取得する担保評価額情報取得手段と、被融資者の現在のローン元本残額に関する情報を取得する元本残額情報取得手段と、前記担保評価額情報取得手段で取得された現在の担保評価額と前記個人信用力評定手段で評定された個人信用力との合計額から前記元本残額情報取得手段で取得された現在のローン元本残額を減算して得られた金額を被融資者の信用余力として設定する信用余力設定手段と、信用余力とポイントとを予め関連付けて記録するポイント記録手段と、前記信用余力設定手段で設定された信用余力により前記ポイント記録手段の記録内容を検索し、前記信用余力に予め関連付けられているポイントを被融資者の途上与信ポイントとして設定するポイント設定手段と、ポイントとアクションとを予め関連付けて記録するアクション記録手段と、前記ポイント設定手段で設定されたポイントにより前記アクション記録手段の記録内容を検索し、前記ポイントに予め関連付けられているアクションを被融資者に対して取るべきアクションとして決定するアクション決定手段とを備えている」と記載されている。

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

しかし、特許文献１に記載された発明のように従来の技術では、信用余力の算出に用いられる個人信用力は、被融資者が属する職種に関連付けられた金額に基づくものであり、被融資者個別の状況に基づくものではない。また、被融資者の経済状況についても、電話契約の異動、個人信用情報、自行の取引情報（実施例）など限定的な情報しか考慮されておらず、被融資者の状況変化に基づく途上与信管理には十分でない。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、所定のイベントの発生の予兆を検知するモニタリングシステムであって、前記モニタリングシステムは、所定の業務を実行する複数のモニタリング対象システムと、前記複数のモニタリング対象システムと接続される一つ以上の計算機と、を備え、前記一つ以上の計算機は、演算装置、前記演算装置に接続される主記憶装置、及び前記演算装置に接続されるネットワーク装置を有し、前記モニタリングシステムは、前記複数のモニタリング対象システム毎に、取得するモニタリングデータを特定するための収集設定情報と、前記モニタリングデータに含まれるユーザ属性に基づいて分類された属性別データを生成するためのユーザ属性管理情報と、所定のイベントの発生に関連する事象である検知パターンの種別及び時系列の組合せである検知モデルを管理する検知モデル情報と、前記検知パターンに対応する前記事象の内容を管理する検知パターン情報と、前記ユーザ属性毎に適用される前記検知モデルを定義する検知モデル設定情報と、を保持し、前記収集設定情報に基づいて、前記複数のモニタリング対象システムの各々から前記モニタリングデータを取得し、所定の前記モニタリングデータを送信するデータ収集部と、前記データ収集部から前記所定のモニタリングデータを取得し、前記ユーザ属性管理情報に基づいて、前記取得された所定のモニタリングデータを用いて前記属性別データを生成するデータ抽出部と、前記データ抽出部から前記属性別データを取得し、前記検知モデル情報、前記検知モデル設定情報、及び前記属性別データに基づいて、前記ユーザ属性毎に前記所定のイベントの発生の予兆を検知する検知部と、を有することを特徴とする。

本発明によれば、ユーザ属性毎の属性データに基づいて、ユーザ属性毎に所定のイベントの発生の予兆を検知することができる。すなわち、各被融資者の操作履歴等に基づいて、被融資者の状況把握が可能となる。

上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明の実施例１におけるモニタリングシステムの構成例を示す説明図である。 本発明の実施例１におけるモニタリングシステムの機能構成を示す説明図である。 本発明の実施例１における検知モデル情報の一例を示す説明図である。 本発明の実施例１における検知サーバのハードウェア構成を示すブロック図である。 本発明の実施例１のデータ管理サーバが保持する収集設定情報の一例を示す説明図である。 本発明の実施例１のユーザ管理サーバが保持するユーザ管理情報の一例を示す説明図である。 本発明の実施例１の検知サーバが保持する検知モデル設定情報の一例を示す説明図である。 本発明の実施例１の検知サーバが保持する検知状態情報の一例を示す説明図である。 本発明の実施例１のデータ管理サーバのデータ収集部が実行するデータ収集処理の一例を説明するフローチャートである。 本発明の実施例１のユーザ管理サーバのユーザデータ抽出部が実行する属性別データ抽出処理の一例を説明するフローチャートである。 本発明の実施例１の検知サーバの検知部が実行する検知処理の一例を説明するフローチャートである。 本発明の実施例１の検知サーバの検知部が実行する検知処理の一例を説明するフローチャートである。 本発明の実施例２のモニタリングシステムの機能構成を示す説明図である。 本発明の実施例２のユーザ管理サーバが保持するユーザ・イベント管理情報の一例を示す説明図である。 本発明の実施例２の検知サーバが保持する抽出状態情報の一例を示す説明図である。 本発明の実施例２のユーザ管理サーバのユーザ属性・イベント別データ抽出部が実行する時系列データ抽出処理を説明するフローチャートである。 本発明の実施例２の検知サーバの検知モデル抽出部が実行する検知モデル抽出処理を説明するフローチャートである。

以下、図面を用いて実施例について説明する。

実施例１におけるモニタリングシステムの構成例について説明する。

図１は、本発明の実施例１におけるモニタリングシステムの構成例を示す説明図である。図２は、本発明の実施例１におけるモニタリングシステムの機能構成を示す説明図である。

実施例１におけるモニタリングシステムは、複数の外部システム１００、データ管理サーバ２００、ユーザ管理サーバ３００、及び検知サーバ４００から構成される。複数の外部システム１００、データ管理サーバ２００、ユーザ管理サーバ３００、及び検知サーバ４００は、ネットワーク１５０を介して互いに通信可能なように接続される。

以下の説明では、データ管理サーバ２００、ユーザ管理サーバ３００、及び検知サーバ４００を区別しない場合、サーバとも記載する。

ネットワーク１５０は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の利用者の組織が管理する通信網である。なお、本発明は、ネットワーク１５０の種別に限定されず、ネットワーク１５０は、インターネット等の公衆通信網、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）又はＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等であってもよい。また、複数種類の通信網が混在したネットワークであってもよい。

外部システム１００は、監視対象のシステムであって、計算機及びネットワーク装置等から構成される計算機システムである。外部システム１００では、所定の業務が実行される。なお、本発明では、外部システム１００が実行する業務に限定されない。

外部システム１００は、制御部１０２を備える。制御部１０２は、データ管理サーバ２００の要求に応じて、ログデータ、取引データ等のモニタリング対象のデータを送信する。以下の説明では、モニタリング対象のデータをモニタリングデータとも記載する。

なお、制御部１０２は、逐次又は周期的に、データ管理サーバ２００にデータを送信する。周期的にデータが送信される場合、制御部１０２は、一定量のデータを蓄積し、蓄積されたデータをデータ管理サーバ２００に送信する。

なお、制御部１０２は、所定のデータ形式に変換し、変換されたデータをデータ管理サーバ２００に送信してもよい。

なお、制御部１０２が送信するデータには、一つ以上のユーザ属性が含まれるものとする。ユーザ属性としては、ユーザ名、組織名、業種、及び地域等が考えられる。

データ管理サーバ２００は、外部システム１００から受信したモニタリングデータを管理し、また、ユーザ管理サーバ３００の要求に応じて、所定のモニタリングデータをユーザ管理サーバ３００に送信する。

データ管理サーバ２００は、データ収集部２０２を備え、また、収集設定情報２０４及び収集データ２０６を管理する。

データ収集部２０２は、外部システム１００から受信したモニタリングデータを収集データ２０６として格納する。なお、データ収集部２０２は、外部システム１００から受信したモニタリングデータを所定のデータ形式で管理する。

また、データ収集部２０２は、ユーザ管理サーバ３００の要求に応じて、収集データ２０６からモニタリングデータを読み出し、読み出されたモニタリングデータをユーザ管理サーバ３００に送信する。

収集データ２０６は、外部システム１００から受信したモニタリングデータである。収集設定情報２０４は、ユーザ管理サーバ３００に送信するモニタリングデータを特定するための情報である。収集設定情報２０４の詳細については、図５を用いて後述する。

なお、収集データ２０６はデータベースを用いて管理されてもよい。

ユーザ管理サーバ３００は、データ管理サーバ２００からモニタリングデータを取得し、取得されたモニタリングデータを所定のユーザ属性毎に分類する。また、ユーザ管理サーバ３００は、所定のユーザ属性毎に分類された複数のデータを検知サーバ４００に送信する。以下の説明では、所定のユーザ属性毎に分類されたデータを属性別データとも記載する。

ユーザ管理サーバ３００は、属性別データ抽出部３０２を備え、また、ユーザ属性管理情報３０４を保持する。

属性別データ抽出部３０２は、データ管理サーバ２００から取得されたモニタリングデータをユーザ属性に従って複数の属性別データに分類し、また、複数の属性別データを検知サーバ４００に送信する。本実施例では、属性別データ抽出部３０２は、属性別データを時系列順に並びかえ、時刻情報（例えば、タイムスタンプ）が古いデータから順に、当該属性別データを検知サーバ４００に送信する。

ユーザ属性管理情報３０４は、受信したモニタリングデータから属性別データを生成するための情報である。本実施例では、属性別データ抽出部３０２は、ユーザ属性管理情報３０４に基づいて、データ管理サーバ２００から所定のモニタリングデータを取得する。なお、ユーザ属性管理情報３０４の詳細については、図６を用いて後述する。

検知サーバ４００は、ユーザ管理サーバ３００から受信した属性別データに基づいて特定のイベントの発生の予兆を検知する。

検知サーバ４００は、検知部４０２を備え、また、検知モデル情報４０４、検知モデル設定情報４０５、検知パターン情報４０６、及び検知状態情報４０８を保持する。

検知部４０２は、ユーザ管理サーバ３００から受信した属性別データを解析し、解析結果に基づいて、特定のイベントの発生の予兆を検知する。本実施例では、検知部４０２は、検知モデル情報４０４に基づいて、特定のイベントが発生する可能性があるか否かを判定する。ここで、検知モデル情報４０４について説明する。

図３は、本発明の実施例１における検知モデル情報４０４の一例を示す説明図である。

検知モデル情報４０４は、複数の検知モデルの情報を格納する。図３に示す例では、検知モデル情報４０４には、検知モデル１（５０１）、検知モデル２（５０２）、及び検知モデル３（５０３）の三つの検知モデルの情報が含まれる。

検知モデルとは、特定のイベントの発生に関連する検知パターンの組合せを示すモデルである。ここで、検知パターンは、検知モデルを構成する事象を示す。例えば、「ログイン回数の増加率が所定の比率以上」、「振り込みによる入金回数が所定の回数以上」となる事象等が考えられる。また、検知パターンの組合せとは、検知パターンの種別及び時系列の組合せを示す。

なお、検知パターンの具体的な内容は、後述する検知パターン情報４０６に格納される。

検知モデル１（５０１）は、検知パターン「Ａ」が発生後、検知パターン「Ｂ」が発生した場合に異常発生の可能性があることを示すモデルである。検知モデル２（５０２）は、検知パターン「Ｂ」、「Ｃ」及び「Ｄ」が同時に発生した場合に異常発生の可能性があることを示すモデルである。検知モデル３（５０３）は、検知パターン「Ｂ」の発生後、検知パターン「Ａ１」又は「Ａ２」のいずれかが発生した場合に異常発生の可能性があることを示すモデルである。

検知モデル設定情報４０５は、属性別データ毎に適用される検知モデルを示す情報である。検知モデル設定情報４０５の詳細については、図７を用いて後述する。

検知パターン情報４０６は、検知パターンの具体的な内容を示す情報である。具体的には、検知パターン情報４０６には、検知パターンの識別子と、検知パターンの内容とが対応づけられた情報が格納される。例えば、検知パターンの識別子が「Ａ」の検知パターンは「ログイン回数の増加率が所定の比率以上」となる事象であることを示す情報が格納される。

検知状態情報４０８は、データの解析状況を示す情報である。検知状態情報４０８の詳細については、図８を用いて後述する。

図４は、本発明の実施例１における検知サーバ４００のハードウェア構成を示すブロック図である。

検知サーバ４００は、演算装置６０１、主記憶装置６０２、副記憶装置６０３、通信装置６０４、入力装置６０５、及び出力装置６０６を備える。演算装置６０１、主記憶装置６０２、副記憶装置６０３、通信装置６０４、入力装置６０５、及び出力装置６０６は、バス６０７を介して互いに接続される。

演算装置６０１は、演算処理を実行する装置であり、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等が考えられる。演算装置６０１は、主記憶装置６０２に格納されるプログラム等を実行することによって、検知部４０２等の検知サーバ４００が有する機能を実現することができる。

主記憶装置６０２は、演算装置６０１によって実行されるプログラム及び当該プログラムの実行に必要な情報を格納する装置であり、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等が考えられる。主記憶装置６０２は、また、演算処理に必要なワークエリアを提供する。

副記憶装置６０３は、プログラム及び情報を格納する装置であり、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）及びフラッシュメモリ等の不揮発性記憶装置が考えられる。

主記憶装置６０２に格納されるプログラム及び情報は、副記憶装置６０３に格納されていてもよい。この場合、演算装置６０１が、副記憶装置６０３からプログラム及び情報を読み出し、読み出されたプログラム及び情報を主記憶装置６０２上に展開する。さらに、演算装置６０１は、主記憶装置６０２に展開されたプログラム及び情報を用いて所定の演算処理を実行する。

通信装置６０４は、外部の装置と通信するための装置であり、例えば、アンテナを介した無線通信を行うための無線通信装置、又は、ネットワークケーブルを介した有線通信を行うための有線通信装置である。

入力装置６０５は、検知サーバ４００に各種情報を入力するための装置であり、例えば、キーボード、マウス、タッチペン、及びポインティングデバイス等が考えられる。

出力装置６０６は、検知サーバ４００の利用者に各種情報を出力するための装置であり、例えば、ディスプレイ等が考えられる。

なお、外部システム１００を構成する計算機、データ管理サーバ２００、及びユーザ管理サーバ３００も同様のハードウェアを備える。なお、外部システム１００を構成する計算機は、入力装置６０５及び出力装置６０６を備えていなくともよい。

なお、外部システム１００を構成する計算機、及び各サーバの主記憶装置６０２には、以下のようなプログラム及び情報が格納される。

外部システム１００を構成する計算機の主記憶装置６０２には、制御部１０２を実現するためのプログラムが格納される。データ管理サーバ２００の主記憶装置６０２には、データ収集部２０２を実現するためのプログラム、収集設定情報２０４、及び収集データ２０６が格納される。ユーザ管理サーバ３００の主記憶装置６０２には、属性別データ抽出部３０２、及びユーザ属性管理情報３０４が格納される。検知サーバ４００の主記憶装置６０２には、検知部４０２を実現するためのプログラム、検知モデル情報４０４、検知モデル設定情報４０５、検知パターン情報４０６、及び検知状態情報４０８が格納される。

次に、図５から図８を用いて、各サーバが保持する情報の詳細について説明する。

図５は、本発明の実施例１のデータ管理サーバ２００が保持する収集設定情報２０４の一例を示す説明図である。

収集設定情報２０４は、システムＩＤ７０１、システム名７０２、対象データ７０３、最終取得日時７０４、取得間隔７０５、及びアドレス７０６を含む。

システムＩＤ７０１は、外部システム１００を一意に識別するための識別子を格納する。システム名７０２は、外部システム１００が実行する業務に関連するシステム名を格納する。対象データ７０３は、外部システム１００から取得するモニタリングデータの種別を示す情報を格納する。

最終取得日時７０４は、外部システム１００から取得されたモニタリングデータの日時のうち、最新の日時を格納する。取得間隔７０５は、外部システム１００からモニタリングデータを取得する時間間隔を格納する。なお、取得間隔７０５が空欄の場合、取得間隔７０５が設定されていないことを示す。

アドレス７０６は、対象データの送信要求を送信する制御部１０２のネットワークアドレスを格納する。

図６は、本発明の実施例１のユーザ管理サーバ３００が保持するユーザ属性管理情報３０４の一例を示す説明図である。

ユーザ属性管理情報３０４は、システムＩＤ８０１、対象データ８０２、ユーザ属性８０３、及びデータ期間８０４を含む。システムＩＤ８０１及び対象データ８０２は、システムＩＤ７０１及び対象データ７０３と同一のものである。

ユーザ属性８０３は、モニタリングデータを属性別データに分類する場合に用いられるユーザ属性を格納する。データ期間８０４は、検知サーバ４００に送信する属性別データの時間幅を格納する。

なお、ユーザ属性８０３が空欄の場合、個別のユーザ毎にモニタリングデータが分類されることを示す。例えば、ユーザＩＤ毎にモニタリングデータが分類される。

図７は、本発明の実施例１の検知サーバ４００が保持する検知モデル設定情報４０５の一例を示す説明図である。

検知モデル設定情報４０５は、モデルＩＤ９０１及びユーザ属性９０２を含む。モデルＩＤ９０１は、検知モデルを一意に識別するための識別子を格納する。ユーザ属性９０２は、ユーザ属性８０３と同一のものである。

なお、ユーザ属性９０２は、どのユーザ属性に基づいて分類された属性別データであるかを示す情報である。すなわち、検知モデルＩＤ９０１に対応する検知モデルが適用される属性別データを特定するための情報として用いられる。

なお、ユーザ属性９０２が空欄の場合、個別のユーザ毎に分類された属性別データに適用される検知モデルであることを示す。

図８は、本発明の実施例１の検知サーバ４００が保持する検知状態情報４０８の一例を示す説明図である。

検知状態情報４０８は、対象ユーザ属性１００１、モデルＩＤ１００２、検知パターン１００３、及び検知日時１００４を含む。

対象ユーザ属性１００１は、検知処理の対象となる属性別データを識別するための識別子を格納する。モデルＩＤ１００２は、属性別データに適用される検知モデルを一意に識別するための識別子を格納する。なお、モデルＩＤ１００２に格納される情報は、モデルＩＤ９０１と同一の情報である。

検知パターン１００３は、検知対象の検知パターンの識別子を格納する。検知日時１００４は、検知パターン１００３に設定された検知パターンと一致する事象が検知された日時を格納する。

後述するように、検知サーバ４００は、データの解析結果に基づいて、検知パターン１００３に設定された検知パターンと一致する事象が検知されたか否かを判定する。

検知状態情報４０８は、検知サーバ４００が後述する検知処理の実行時に生成される情報である。例えば、図８の１行目のエントリは、「ユーザＡ」のデータに対して、「検知モデル１」に一致するか否かが判定されていることを示す。また、検知サーバ４００は、次に検知パターン「Ｂ」が検知されるか否かを判定することが分かる。

以下、モニタリングシステムにおける処理の詳細について図を説明する。

図９は、本発明の実施例１のデータ管理サーバ２００のデータ収集部２０２が実行するデータ収集処理の一例を説明するフローチャートである。

データ収集部２０２は、周期的に処理を実行するものとする。なお、本発明は、データ収集部２０２の処理開始のタイミングに限定されない。例えば、データ管理サーバ２００の利用者等から指示を受け付けた場合、又は、ユーザ管理サーバ３００から収集データの送信要求を受信した場合に、処理が開始されてもよい。

データ収集部２０２は、外部システム１００から取得する対象データを特定し、モニタリングデータの送信要求を外部システム１００に送信する（ステップＳ１０１）。具体的には以下のような処理が実行される。

データ収集部２０２は、収集設定情報２０４を参照して、上のエントリから順に処理を実行する。まず、データ収集部２０２は、選択されたエントリのシステムＩＤ７０１を参照して、データを取得する外部システム１００を特定する。

データ収集部２０２は、選択されたエントリのシステム名７０２及び対象データ７０３に基づいて、特定された外部システム１００から取得するモニタリングデータを特定する。例えば、インターネットバンキングにおける操作履歴データ、又は勘定系システムにおける取引データ等がモニタリングデータとして特定される。

データ収集部２０２は、選択されたエントリの取得間隔７０５に値が格納されているか否かを判定する。

選択されたエントリの取得間隔７０５に値が格納されていない場合、データ収集部２０２は、特定された外部システム１００にモニタリングデータの送信要求を送信する。具体的には、データ収集部２０２は、アドレス７０６に格納されたネットワークアドレス宛に、モニタリングデータの送信要求に対応するパケットを送信する。

選択されたエントリの取得間隔７０５に値が格納されている場合、データ収集部２０２は、現在の日時と選択されたエントリの最終取得日時７０４とを比較し、取得間隔７０５に格納された値だけ時間が経過しているか否かを判定する。例えば、取得間隔７０５が「１時間」である場合、データ収集部２０２は、現在の日時が最終取得日時７０４から１時間以上経過しているか否かを判定する。

取得間隔７０５に格納された値だけ時間が経過していないと判定された場合、データ収集部２０２は、取得間隔７０５に格納された値だけ時間が経過するまで待ち続ける。なお、データ収集部２０２は、時間の経過を待たずに当該エントリについての処理を終了してもよい。

取得間隔７０５に格納された値だけ時間が経過していると判定された場合、データ収集部２０２は、特定された外部システム１００にモニタリングデータの送信要求を送信する。具体的には、データ収集部２０２は、アドレス７０６に格納されたネットワークアドレス宛に、モニタリングデータの送信要求に対応するパケットを送信する。

データ収集部２０２は、収集設定情報２０４に含まれる全てのエントリについて前述した処理を繰り返し実行する。なお、データ収集部２０２は、複数のエントリについて同時に前述した処理を実行するようにしてもよい。

外部システム１００の特性に応じて、特に、他銀行のシステム等では提供されるモニタリングデータの更新頻度が異なる場合がある。そのため、本発明では、取得間隔７０５を設定することによって、外部システム１００に対する不要な送信要求の送信を防ぐことができる。

以上がステップＳ１０１の処理である。

次に、データ収集部２０２は、外部システム１００から受信したモニタリングデータを収集データ２０６に格納し、また、収集設定情報２０４を更新する（ステップＳ１０２）。

具体的には、データ収集部２０２は、収集設定情報２０４を参照し、受信したモニタリングデータに対応するエントリを検索する。データ収集部２０２は、検索されたエントリの最終取得日時７０４に、外部システム１００からモニタリングデータを受信した日時の情報を格納する。

なお、受信したデータに対応するエントリを検索する方法としては以下のような方法が考えられる。まず、データ収集部２０２は、受信したパケット（モニタリングデータ）のヘッダを参照して、当該パケットの送信元のアドレスを取得する。データ収集部２０２は、収集設定情報２０４のアドレス７０６を参照して、取得されたアドレスと一致するエントリを検索する。

次に、データ収集部２０２は、ユーザ管理サーバ３００からモニタリングデータの送信要求を受信したか否かを判定する（ステップＳ１０３）。後述するように、モニタリングデータの送信要求には、システム名、データの種別、及びタイムスタンプが含まれる。

ユーザ管理サーバ３００からモニタリングデータの送信要求を受信していないと判定された場合（ステップＳ１０３がＮＯ）、データ収集部２０２は処理を終了する。

ユーザ管理サーバ３００からモニタリングデータの送信要求を受信していると判定された場合（ステップＳ１０３がＹＥＳ）、データ収集部２０２は、要求されたモニタリングデータをユーザ管理サーバ３００に送信し（ステップＳ１０４）、処理を終了する。

具体的には、データ収集部２０２は、モニタリングデータの送信要求に含まれるシステム名、及びデータ種別に基づいて、要求されたモニタリングデータを特定する。さらに、データ収集部２０２は、モニタリングデータの送信要求に含まれるタイムスタンプに基づいて、特定されたモニタリングデータのうち、更新分のモニタリングデータのみをユーザ管理サーバ３００に送信する。

なお、外部システム１００からモニタリングデータを取得する処理と、ユーザ管理サーバ３００にモニタリングデータを送信する処理とは、別々の処理として実行されてもよい。

図１０は、本発明の実施例１のユーザ管理サーバ３００の属性別データ抽出部３０２が実行する属性別データ抽出処理の一例を説明するフローチャートである。

属性別データ抽出部３０２は、検知サーバ４００から属性別データの送信要求を受信した場合に処理を実行するものとする。後述するように、属性別データの送信要求には、システム名、ユーザ属性、及びデータの種別が含まれる。

なお、本発明は、属性別データ抽出部３０２の処理開始のタイミングに限定されない。例えば、ユーザ管理サーバ３００の利用者等から指示を受け付けた場合、又は、周期的に、処理が実行されてもよい。

属性別データ抽出部３０２は、データ収集部２０２にモニタリングデータの送信要求を送信し、モニタリングデータを受信する（ステップＳ２０１）。

モニタリングデータの送信要求には、システム名、及びデータの種別が含まれる。システム名、及びデータの種別は属性別データの送信要求に含まれるものと同一である。

また、モニタリングデータの送信要求には、これまで受信したモニタリングデータの最新のタイムスタンプが含まれる。属性別データ抽出部３０２は、前回取得したモニタリングデータのタイムスタンプのうち、最新のタイムスタンプを一時的に保持する。これによって、データ管理サーバ２００は、収集データ２０６に格納されるデータのうち、前回までに受信したモニタリングデータ以外のデータ、すなわち、更新分のモニタリングデータを取得できる。

本実施例では、属性別データ抽出部３０２は、受信したモニタリングデータを一時的に保持する。なお、属性別データ抽出部３０２は、受信したモニタリングデータを一定期間経過した後に破棄してもよいし、副記憶装置６０３に格納してもよい。

次に、属性別データ抽出部３０２は、ユーザ属性管理情報３０４に基づいて、受信したモニタリングデータを用いて複数の属性別データを生成する（ステップＳ２０２）。具体的には、以下のような処理が実行される。

属性別データ抽出部３０２は、ユーザ属性管理情報３０４を参照して、属性別データの送信要求に含まれるユーザ属性に対応するエントリを選択する。属性別データ抽出部３０２は、受信したモニタリングデータから、選択されたエントリのシステムＩＤ８０１、対象データ８０２、ユーザ属性８０３、及びデータ期間８０４に一致するデータを抽出する。

このとき、ユーザ属性８０３が空の場合、属性別データ抽出部３０２は、受信したモニタリングデータからユーザ毎にデータを抽出する。ユーザ属性８０３に所定のユーザ属性が格納される場合、属性別データ抽出部３０２は、受信したモニタリングデータから当該ユーザ属性に対応するデータを抽出する。

また、属性別データ抽出部３０２は、受信したモニタリングデータのうち、タイムスタンプが最新のモニタリングデータからデータ期間８０４に格納された期間だけ遡った時間間隔のデータを抽出する。

さらに、属性別データ抽出部３０２は、タイムスタンプが古い順に、抽出されたデータを並び替えることによって属性別データを生成する。前述のように、本実施例の属性別データは時系列データとして生成される。

本実施例では、ユーザ属性８０３に特定のユーザ属性が格納される場合、一つの属性別データが生成され、ユーザ属性８０３が空の場合、複数の属性別データが生成されることとなる。

以上が、ステップＳ２０２の処理である。

次に、属性別データ抽出部３０２は、検知サーバ４００に生成された属性別データを送信し（ステップＳ２０３）、処理を終了する。

図６に示すユーザ属性管理情報３０４の場合、ステップＳ２０２では、以下のような属性別データが生成される。

一番目のエントリが選択された場合、属性別データ抽出部３０２は、受信したモニタリングデータから、システムＩＤが「０００１」、データの種別が「操作ログ」であるデータを、ユーザ毎に３ヶ月分抽出する。属性別データ抽出部３０２は、抽出されたユーザ毎のデータを時系列順に並び替えることによって、属性別データを生成する。なお、生成された属性別データにはユーザ属性としてユーザの識別子が含まれる。

また、三番目のエントリが選択された場合、属性別データ抽出部３０２は、システムＩＤが「０００２」、データの種別が「取引データ」、ユーザ属性が「製造業」であるデータを１ヶ月分抽出する。属性別データ抽出部３０２は、抽出されたデータを時系列順に並び替えることによって、ユーザ属性が「製造業」である属性別データを生成する。

図１１Ａ及び図１１Ｂは、本発明の実施例１の検知サーバ４００の検知部４０２が実行する検知処理の一例を説明するフローチャートである。

まず、検知部４０２は、検知モデル情報４０４及び検知モデル設定情報４０５を読み出し（ステップＳ３０１）、また、検知状態情報４０８を読み出す（ステップＳ３０２）。

検知部４０２は、読み出された検知モデル設定情報４０５に基づいて検知モデルを一つ選択する（ステップＳ３０３）。ここでは、検知モデル設定情報４０５の上のエントリから順に選択されるものとする。

検知部４０２は、検知状態情報４０８に、選択された検知モデルに対応するエントリが存在するか否かを判定する（ステップＳ３０４）。

具体的には、検知部４０２は、モデルＩＤ１００２が、ステップＳ３０３において選択された検知モデルの識別子と一致するエントリを検索する。

検知状態情報４０８に、選択された検知モデルに対応するエントリが存在すると判定された場合（ステップＳ３０４がＹＥＳ）、検知部４０２は、検知状態情報４０８に基づいて、検知対象の検知パターンを設定し（ステップＳ３０５）、ステップＳ３０７に進む。

具体的には、検知部４０２は、検知状態情報４０８の対応するエントリの検知パターン１００３に格納される検知パターンを、検知対象の検知パターンとして設定する。

検知状態情報４０８に、選択された検知モデルに対応するエントリが存在しないと判定された場合（ステップＳ３０４がＮＯ）、検知部４０２は、検知モデル情報４０４に基づいて、検知対象の検知パターンを設定し（ステップＳ３０６）、ステップＳ３０７に進む。

具体的には、検知部４０２は、選択された検知モデルの識別子に基づいて、検知モデル情報４０４を参照し、最初の検知パターンを特定する。検知部４０２は、特定された最初の検知パターンを、検知対象の検知パターンとして設定する。

次に、検知部４０２は、ユーザ管理サーバ３００に属性別データの送信要求を送信する（ステップＳ３０７）。当該送信要求には、システム名、ユーザ属性、及びデータの種別が含まれる。

ここで、システム名及びデータの種別は、設定された検知パターンに基づいて決定される。例えば、設定された検知パターンがインターネットバンキングの操作ログに関連する内容である場合、検知部４０２は、システム名を「インターネットバンキングシステム」と、データ種別を「操作ログ」と決定する。

本実施例では、検知部４０２は、受信した属性別データを一時的に保持する。なお、検知部４０２は、受信した属性別データを一定期間経過した後に破棄してもよいし、副記憶装置６０３に格納してもよい。

次に、検知部４０２は、属性別データを取得した後、一つの属性別データを選択し、選択された属性別データに対してステップＳ３０８からステップＳ３１３の処理を実行する。

このとき、検知部４０２は、複数の属性別データを受信した場合、取得された全ての属性別データに対して、ステップＳ３０８からステップＳ３１３の処理を繰り返し実行する。例えば、「ユーザＡ」及び「ユーザＢ」の属性別データが取得された場合、検知部４０２は、「ユーザＡ」の属性別データに対してステップＳ３０８からステップＳ３１３の処理を実行し、「ユーザＢ」の属性別データに対してステップＳ３０８からステップＳ３１３の処理を実行する。

検知部４０２は、ユーザ管理サーバ３００から受信した属性別データを用いて、所定の解析処理を実行する（ステップＳ３０８）。さらに、検知部４０２は、解析結果、及び選択された検知モデルに対して設定された検知パターンに基づいて、マッチング処理を実行する（ステップＳ３０９）。

本実施例では、検知モデル毎に、解析処理の処理内容が予め設定されているものとする。なお、解析処理が必要ない場合には、当該ステップを省略してもよい。

検知部４０２は、マッチング処理の結果に基づいて、設定された検知パターンに一致する事象が発生しているか否かを判定する（ステップＳ３１０）。

設定された検知パターンに一致する事象が発生していないと判定された場合（ステップＳ３１０がＮＯ）、検知部４０２はステップＳ３１４に進む。

設定された検知パターンに一致する事象が発生していると判定された場合（ステップＳ３１０がＹＥＳ）、検知部４０２は、検知状態情報４０８を更新する（ステップＳ３１１）。

具体的には、検知部４０２は、検知モデル情報４０４に基づいて、検知状態情報４０８の対応するエントリの検知パターン１００３に次の検知対象となる検知パターンの識別子を設定する。

例えば、「検知モデル１」が適用される「ユーザＡ」において検知パターン「Ａ」と一致する事象が発生すると判定された場合、図８の一番上のエントリのように、検知パターン「Ｂ」が設定される。また、「検知モデル３」が適用される「ユーザＢ」において検知パターン「Ｅ」と一致する事象が発生すると判定された場合、図８の二番上のエントリのように、検知パターン「Ｆ１」及び検知パターン「Ｆ２」が設定される。

なお、特定のイベントが発生の条件である全ての検知パターンが検知されている場合には、次の検知対象は存在しないため検知パターン１００３には終了を示す情報が格納される。

次に、検知部４０２は、特定のイベントが発生する可能性があるか否かを判定する（ステップＳ３１２）。

具体的には、特定された検知モデルについて、特定のイベントが発生条件である検知パターンが全て検知されたか否かを判定する。例えば、図３に示す検知モデル１の場合、検知パターン「Ａ」及び検知パターン「Ｂ」の両方の検知パターンが検知されたか否かが判定される。特定のイベントが発生条件である検知パターンが全て検知された場合、検知部４０２は、特定のイベントが発生する可能性があると判定する。

特定のイベントが発生する可能性がないと判定された場合（ステップＳ３１２がＮＯ）、検知部４０２はステップＳ３１４に進む。

特定のイベントが発生する可能性があると判定された場合（ステップＳ３１２がＹＥＳ）、検知部４０２は、特定された検知モデルに対応する異常発生のアラートを外部システム１００に対して出力し（ステップＳ３１３）、ステップＳ３１４に進む。なお、アラートの出力先は外部システム１００に限定されず、各サーバ、又はその他の装置に対してアラートが出力されてもよい。

検知部４０２は、検知モデル設定情報４０５に含まれる全ての検知モデルについて処理が完了したか否かを判定する（ステップＳ３１４）。

検知モデル設定情報４０５に含まれる全ての検知モデルについて処理が完了していないと判定された場合（ステップＳ３１４がＮＯ）、検知部４０２はステップＳ３０３に戻る。

検知モデル設定情報４０５に含まれる全ての検知モデルについて処理が完了していると判定された場合（ステップＳ３１４がＹＥＳ）、検知部４０２は処理を終了する。

なお、本発明は、外部システム１００又は各サーバから送信されるデータの送信タイミングに限定されない。したがって、逐次到来するデータ、すなわち、ストリームデータを処理するシステム（ストリームデータ処理システム）にも適用可能である。

ストリームデータ処理システムに本発明を適用する場合、外部システム１００は逐次ストリームデータ（モニタリングデータ）をデータ管理サーバ２００に送信し、データ管理サーバ２００は逐次ストリームデータ（モニタリングデータ）をユーザ管理サーバ３００に送信し、またユーザ管理サーバ３００は逐次ユーザ属性毎のストリームデータ（属性別データ）を検知サーバ４００に送信する。この場合、各サーバは各送信要求を送信する必要はない。

ここで、具体例を用いて検知処理について説明する。

まず、図３に示す「検知モデル１」を例に説明する。以下の説明では、「検知モデル１」の検知パターン「Ａ」は「１回のログイン中に残高照会と手続き説明ページ閲覧とを実行」、検知パターン「Ｂ」は「１回の取引で１００万円以上の入金」であるものとする。

また、図７に示すように、検知モデル１では、ユーザ属性９０２が設定されていないため、ユーザ毎に分類されたモニタリングデータ、すなわち属性別データに対して検知モデル１に対する検知処理が実行される。そのため、以下の説明では、「ユーザＡ」、「ユーザＢ」、及び「ユーザＣ」の三つの属性別データがユーザ管理サーバ３００によって生成されたものとする。

ステップＳ３０４において、「検知モデル１」に対応するエントリが存在しないと判定された場合、検知部４０２は、「検知モデル１」の最初の検知パターン「Ａ」を検知対象の検知パターンとして設定する（ステップＳ３０５）。

ステップＳ３０７において、検知パターン「Ａ」はインターネットバンキングの操作に関するパターンであるため、検知部４０２は、ユーザ管理サーバ３００に、ユーザ毎のインターネットバンキングシステムの操作ログデータの送信要求を送信する。

ステップＳ３０９において、検知部４０２は、「ユーザＡ」、「ユーザＢ」、及び「ユーザＣ」のそれぞれの操作ログデータの解析結果と、設定された検知パターン「Ａ」とのマッチング処理を実行する。さらに、ステップＳ３１０において、検知部４０２は、検知パターン「Ａ」と一致する事象が発生するか否かを判定する。

ここで、「ユーザＡ」において検知パターン「Ａ」に一致する事象が発生すると判定された場合、検知部４０２は、図８の一番目のエントリを追加することによって検知状態情報４０８を更新する。なお、検知日時１００４には、ステップＳ３１０の処理が実行された日時が格納される。

さらに、検知部４０２は、追加されたエントリの検知パターン１００３に検知パターン「Ｂ」を格納する。

所定期間が経過した後、検知処理が開始された場合、検知部４０２は、ステップＳ３０５において、検知パターン「Ｂ」を検知対象の検知パターンとして設定する。

ステップＳ３０７において検知部４０２は、ユーザ管理サーバ３００に勘定系システムの取引データの送信要求を送信する。ステップＳ３０９において、検知部４０２は、「ユーザＡ」について検知パターン「Ｂ」に一致する事象が発生するか否かを判定する。

「ユーザＡ」について検知パターン「Ｂ」と一致する事象が発生すると判定された場合、検知モデルに含まれる全ての検知パターンが検知されたことになる。したがって、ステップＳ３１２において、検知部４０２は、「ユーザＡ」について異常が発生する可能性があると判定し、ステップＳ３１３において該当する外部システム１００に対してアラートを出力する。

以上のように、対象となる検知パターンを絞ることによって、マッチング処理に必要なデータの種別、及び取得期間を限定できるため、通信及び処理量を低減することができる。

次に、図３に示す「検知モデル３」を例に説明する。以下の説明では、「検知モデル３」の検知パターン「Ｅ」は「残高照会回数が３カ月連続増加」、検知パターン「Ｆ１」は「１カ月の入金回数が５回以上」、検知パターン「Ｆ２」は「１カ月の入金合計が１０万円以上」であるものとする。また、月の区切りは、該当ユーザのローン返済引き落とし日とする。

「検知モデル３」では、検知パターン「Ｅ」が検知された後、検知パターン「Ｆ１」又は検知パターン「Ｆ２」が検知された場合、異常が発生する可能性があると判定される検知モデルである。

また、図７に示すように、「検知モデル３」では、ユーザ属性９０２が設定されていないため、以下の説明では、「ユーザＡ」、「ユーザＢ」、及び「ユーザＣ」の三つの属性別データがユーザ管理サーバ３００によって生成されたものとする。

ステップＳ３０４において、「検知モデル３」に対応するエントリが存在しないと判定された場合、検知部４０２は、「検知モデル３」の最初の検知パターン「Ｅ」を検知対象の検知パターンとして設定する（ステップＳ３０５）。

ステップＳ３０７において、検知パターン「Ｅ」はインターネットバンキングの操作に関するパターンであるため、検知部４０２は、ユーザ管理サーバ３００に、ユーザ毎のインターネットバンキングシステムの操作ログデータの送信要求を送信する。

ステップＳ３０９において、検知部４０２は、「ユーザＡ」、「ユーザＢ」、及び「ユーザＣ」のそれぞれの操作ログデータの解析結果と、設定された検知パターン「Ｅ」とのマッチング処理を実行する。さらに、ステップＳ３１０において、検知部４０２は、検知パターン「Ｅ」と一致する事象が発生するか否かを判定する。

ここで、「ユーザＢ」において検知パターン「Ｅ」に一致する事象が発生すると判定された場合、検知部４０２は、図８の二番目のエントリを追加することによって検知状態情報４０８を更新する。なお、検知日時１００４には、ステップＳ３１０の処理が実行された日時が格納される。すなわち、３カ月目の残高参照回数が前月の回数を越えた日時が検知日時１００４に格納される。

さらに、検知部４０２は、追加されたエントリの検知パターン１００３に検知パターン「Ｆ１」及び検知パターン「Ｆ２」を格納する。

所定期間が経過した後、検知処理が開始された場合、検知部４０２は、ステップＳ３０５において、検知パターン「Ｆ１」及び検知パターン「Ｆ２」を検知対象の検知パターンとして設定する。

ステップＳ３０７において検知部４０２は、ユーザ管理サーバ３００に勘定系システムの取引データのうち、「ユーザＢ」が検知日時１００４以降かつ検知日時１００４に直近する時間間隔の取引データの送信要求を送信する。ステップ３０９において、検知部４０２は、「ユーザＢ」について検知パターン「Ｆ１」又は検知パターン「Ｆ２」に一致する事象が発生するか否かを判定する。

「ユーザＢ」について検知パターン「Ｆ１」又は検知パターン「Ｆ２」の少なくともいずれかと一致する事象が発生すると判定された場合、検知モデルに含まれる全ての検知パターンが検知されたことになる。したがって、ステップＳ３１２において、検知部４０２は、「ユーザＢ」について異常が発生する可能性があると判定し、ステップＳ３１３において該当する外部システム１００に対してアラートを出力する。

以上のように、対象となる検知パターン及びその特長に基づいて、マッチング処理に必要なデータ種別、及び取得期間を限定できるため、通信及び処理量を低減することができる。

以上説明したように、実施例１のモニタリングシステムでは、ユーザ個別の操作履歴データ等のデータをリアルタイムにモニタリングすることができ、モニタリング結果に基づいて、ユーザ毎に異常発生の予兆等を検知することができる。

また、ユーザ属性、すなわち、ユーザ毎に検知モデルを設定することによって、ユーザ毎に適したイベント発生の予兆を検知することができる。

実施例１では、予め検知モデルが登録されていたが、実施例２では、モニタリングの履歴等から検知モデルを抽出する点が異なる。

以下、実施例１との差異を中心に説明する。なお、実施例１の構成と同一の符号が付与された構成は、同一の機能又は構成であることを示す。

図１２は、本発明の実施例２のモニタリングシステムの機能構成を示す説明図である。

外部システム１００及びデータ管理サーバ２００は、実施例１と同一であるため説明を省略する。

実施例２のユーザ管理サーバ３００は、データ管理サーバ２００から受信したデータからユーザ属性毎のイベントに関連するデータを生成し、生成されたユーザ属性毎のイベントに関連するデータを検知サーバ４００に送信する。実施例２のユーザ管理サーバ３００は、ユーザ属性・イベント別データ抽出部１１０２を備え、及びユーザ属性・イベント管理情報１１０４を保持する。

以下の説明では、ユーザ属性毎のイベントに関連するデータを、ユーザ属性・イベント別データとも記載する。

ユーザ属性・イベント別データ抽出部１１０２は、ユーザ属性・イベント別データを抽出する。ユーザ属性・イベント管理情報１１０４は、ユーザ属性毎の過去に発生したイベントに関する情報を格納する。ユーザ属性・イベント管理情報１１０４の詳細については、図１３を用いて後述する。

実施例２の検知サーバ４００は、ユーザ管理サーバ３００から受信したユーザ属性・イベント別データに基づいて、検知モデルを生成する。実施例２の検知サーバ４００は、検知モデル抽出部１２０２を備え、また、検知モデル情報４０４、検知パターン情報４０６、及び抽出状態情報１２０４を保持する。

検知モデル抽出部１２０２は、ユーザ属性・イベント別データを用いて検知モデルを生成する。抽出状態情報１２０４は、生成中の検知モデルに関する情報を格納する。抽出状態情報１２０４の詳細については、図１４を用いて後述する。検知モデル情報４０４及び検知パターン情報４０６は、実施例１と同一であるため説明を省略する。

なお、各サーバのハードウェア構成は実施例１と同一であるため説明を省略する。また、データ管理サーバ２００が実行する処理は実施例１と同一であるため説明を省略する。

図１３は、本発明の実施例２のユーザ管理サーバ３００が保持するユーザ属性・イベント管理情報１１０４の一例を示す説明図である。

ユーザ属性・イベント管理情報１１０４は、対象ユーザ属性１３０１、イベント１３０２、及び発生時期１３０３を含む。

対象ユーザ属性１３０１は、対象のイベントに関連するユーザ属性を格納する。イベント１３０２は、発生したイベントを特定するための情報を格納する。発生時期１３０３は、対象のイベントが発生した時期を格納する。

図１４は、本発明の実施例２の検知サーバ４００が保持する抽出状態情報１２０４の一例を示す説明図である。

抽出状態情報１２０４は、対象ユーザ属性１４０１、イベント１４０２、及び抽出パターン１４０３を含む。

対象ユーザ属性１４０１及びイベント１４０２は、対象ユーザ属性１３０１及びイベント１３０２と同一のものである。抽出パターン１４０３は、対象のイベントに関連する検知パターンの情報を格納する。なお、抽出パターン１４０３には、検知パターンの発生順が把握可能な形式でデータが格納される。

以下、実施例２におけるユーザ管理サーバ３００及び検知サーバ４００が実行する処理の詳細について説明する。

図１５は、本発明の実施例２のユーザ管理サーバ３００のユーザ属性・イベント別データ抽出部１１０２が実行する時系列データ抽出処理を説明するフローチャートである。

ユーザ属性・イベント別データ抽出部１１０２は、ユーザ属性・イベント管理情報１１０４を読み出し（ステップＳ４０１）、処理対象のユーザ属性を選択する（ステップＳ４０２）。

本実施例では、ユーザ属性・イベント別データ抽出部１１０２は、ユーザ属性・イベント管理情報１１０４の上のエントリから順に選択するものとする。

ユーザ属性・イベント別データ抽出部１１０２は、選択されたユーザ属性に対応するエントリに基づいて、データ管理サーバ２００にモニタリングデータの送信要求を送信し、所定のモニタリングデータを受信する（ステップＳ４０３）。

モニタリングデータの送信要求には、ユーザ属性、及びデータ期間が含まれる。ユーザ属性は、ステップＳ４０２において選択されたユーザ属性、すなわち、選択されたエントリの対象ユーザ属性１３０１に対応する。また、データ期間は、イベント１３０２及び発生時期１３０３から決定される。本実施例では、イベント１３０２毎にデータを取得する期間が予め決定されているものとする。したがって、発生時期１３０３を起点として、予め設定された期間がデータ期間となる。

これによって、データ管理サーバ２００は、要求されたモニタリングデータを収集データ２０６から取得することができる。

次に、ユーザ属性・イベント別データ抽出部１１０２は、受信したモニタリングデータを用いてユーザ属性・イベント別データを生成する（ステップＳ４０４）。このとき、ユーザ属性・イベント別データ抽出部１１０２は、受信したモニタリングデータを時系列順に並び替え、また、ステップ４０２において選択されたエントリのイベント１３０２の情報を付加する。

ユーザ属性・イベント別データ抽出部１１０２は、生成されたユーザ属性・イベント別データを検知サーバ４００に送信する（ステップＳ４０５）。

ユーザ属性・イベント別データ抽出部１１０２は、全てのユーザ属性について処理が完了したか否かを判定する（ステップＳ４０６）。

全てのユーザ属性について処理が完了していないと判定された場合、ユーザ属性・イベント別データ抽出部１１０２は、ステップＳ４０２に戻る。

全てのユーザ属性について処理が完了したと判定された場合、ユーザ属性・イベント別データ抽出部１１０２は、処理を終了する。

図１６は、本発明の実施例２の検知サーバ４００の検知モデル抽出部１２０２が実行する検知モデル抽出処理を説明するフローチャートである。

検知モデル抽出部１２０２は、ユーザ管理サーバ３００から、ユーザ属性・イベント別データを受信し（ステップＳ５０１）、また、抽出状態情報１２０４を更新する（ステップＳ５０２）。さらに、検知モデル抽出部１２０２は、ユーザ属性に基づいて、処理対象のユーザ属性・イベント別データを選択する（ステップＳ５０３）。

具体的には、検知モデル抽出部１２０２は、抽出状態情報１２０４に、受信したユーザ属性・イベント別データに対応するエントリを追加する。検知モデル抽出部１２０２は、追加されたエントリの対象ユーザ属性１４０１に受信した時系列データに含まれるユーザ属性を格納し、イベント１４０２に受信した時系列データに付加されたイベント１３０２の情報を格納する。なお、抽出パターン１４０３は空欄のままである。

また、検知モデル抽出部１２０２は、検知パターン情報４０６を読み出し、処理対象の検知パターンを選択する（ステップＳ５０４）。

検知モデル抽出部１２０２は、選択されたユーザ属性・イベント別データの解析処理を実行する（ステップＳ５０５）。

具体的には、検知モデル抽出部１２０２は、選択されたユーザ属性・イベント別データに対して、選択された検知パターンに対応する解析処理を実行する。

例えば、選択された検知パターンが「１カ月の入金回数が５回以上」である場合、検知モデル抽出部１２０２は、選択されたユーザ属性・イベント別データから１ヶ月分のデータを抽出し、さらに、当該抽出されたデータから取引データを抽出する。検知モデル抽出部１２０２は、抽出された取引データを参照することによって、入金回数が５回以上であるか否かを解析する。

次に、検知モデル抽出部１２０２は、解析結果に基づいて、選択された検知パターンに対応する事象が発生しているか否かを判定する（ステップＳ５０６）。

選択された検知パターンに対応する事象が発生していないと判定された場合（ステップＳ５０６がＮＯ）、検知モデル抽出部１２０２は、ステップＳ５０８に進む。

選択された検知パターンに対応する事象が発生していると判定された場合（ステップＳ５０６がＹＥＳ）、検知モデル抽出部１２０２は、抽出状態情報１２０４に検知パターンを抽出パターン１４０３に登録し（ステップＳ５０７）、ステップＳ５０８に進む。

検知モデル抽出部１２０２は、検知パターン情報４０６に含まれる全ての検知パターンについて処理が完了したか否かを判定する（ステップＳ５０８）。

検知パターン情報４０６に含まれる全ての検知パターンについて処理が完了していないと判定された場合（ステップＳ５０８がＮＯ）、検知モデル抽出部１２０２はステップＳ５０４に戻る。

検知パターン情報４０６に含まれる全ての検知パターンについて処理が完了していると判定された場合（ステップＳ５０８がＹＥＳ）、検知モデル抽出部１２０２は、抽出パターン１４０３に格納された検知パターンの組合せを、検知モデルとして検知モデル情報４０４に登録する（ステップＳ５０９）。

検知モデル抽出部１２０２は、受信した全ての時系列データについて処理が完了したか否かを判定する（ステップＳ５１０）。

受信した全ての時系列データについて処理が完了していないと判定された場合（ステップＳ５１０がＮＯ）、検知モデル抽出部１２０２は、ステップＳ５０３に戻る。

受信した全ての時系列データについて処理が完了していると判定された場合（ステップＳ５１０がＹＥＳ）、検知モデル抽出部１２０２は、処理を終了する。

前述した処理では、ユーザ属性別、かつイベント別に検知モデルが抽出される。検知モデル抽出部１２０２は、同一のイベント毎に検知モデルもまとめて、多くのユーザ属性に共通する検知モデルを、優先的にモニタリングする検知モデルとしてもよい。

実施例２によれば、自動的にユーザ属性毎の検知モデルを生成することができる。これによって、ユーザ属性毎に検知モデルと一致するか否かを判定するため、効率的かつ適切な検知処理が実現できる。また、処理速度の向上を実現することが可能である。

実施例３では、検知処理における検知パターンとのマッチング処理が異なる。なお，モニタリングシステムの構成、各サーバの構成は、実施例１と同一であるため説明を省略する。また、各サーバが保持する情報も実施例１と同一であるため説明を省略する。さらに、データ管理サーバ２００、及びユーザ管理サーバ３００が実行する処理は実施例１と同一であるため説明を省略する。

以下、実施例３の検知サーバ４００が実行する検知処理を実施例１との差異を中心に説明する。

以下の説明では、ステップＳ３０５又はステップＳ３０６において、複数の検知パターンが設定されるものとする。

実施例３では、以下のような処理が実行される。

まず、検知部４０２は、検知モデル情報４０４を参照して、設定された検知パターンに対応する検知モデルの数を算出し、算出された検知モデルの数が多い順に、検知パターンに高い優先度を付与する。

次に、検知部４０２は、現在の処理負荷が高いか否かを判定する。

現在の処理負荷が高いと判定された場合、検知部４０２は、設定された複数の検知パターンのうち、優先度が高い検知モデルのみを選択する。なお、ここでは、一つの検知パターンのみを選択するものとしたが、複数の検知パターンが選択されてもよい。

その他の処理は実施例１と同一であるため説明を省略する。

実施例３によれば、処理負荷に応じて、優先度の高い検知パターンのみについてマッチング処理を実行することによって、処理性能の低減を実現できる。

モニタリング対象の外部システム１００の機能が変更され、また、新たな外部システム１００がモニタリング対象として追加される等、モニタリングシステムの状態が変化した場合、同一の検知モデルのままでは、イベント発生の予兆検知の精度が低下する可能性がある。

実施例４では、モニタリングシステムの状態に応じて、検知モデル情報４０４を更新する点が、実施例１と異なる。以下、実施例１との差異を中心に実施例４について説明する。

実施例４のモニタリングシステムの構成、各サーバの構成は、実施例１と同一であるため説明を省略する。また、収集設定情報２０４、ユーザ属性管理情報３０４、検知モデル設定情報４０５、検知パターン情報４０６、及び検知状態情報４０８も実施例１と同一であるため説明を省略する。さらに、データ管理サーバ２００、及びユーザ管理サーバ３００が実行する処理は実施例１と同一であるため説明を省略する。

実施例４では、検知モデル情報４０４が異なる。具体的には、アラート回数及びイベント発生回数のカラムが新たに追加される。

また、実施例４の検知部４０２が実行する処理は以下のステップが異なる。

ステップＳ３１３において、検知部４０２は、検知モデル情報４０４の選択された検知モデルのアラート回数の値を更新する。また、検知部４０２は、選択された検知モデルに対応するイベントの発生を検知した場合に、検知モデル情報４０４の選択された検知モデルのイベント発生回数を更新する。

検知部４０２は、周期的に、アラート回数と事象発生回数との比を算出し、算出された比が予め設定されたしきい値以下となる検知モデルが存在する場合、検知モデル情報４０４から当該検知モデルを削除する。

実施例４によれば、モニタリングシステムの状態変化に応じてイベントの検知精度が低下した検知モデルを削除することによって、イベント発生の予兆検知の精度の低下を防ぐことができる。

本発明は、前述した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換をすることが可能である。

また、前述の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、専用のハードウェアも用いて実現してもよい。また、前述の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、及びＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、又は、ＩＣカード、ＳＤカード、及びＤＶＤ等の記録媒体に格納することができる。

また、本発明は、データ管理サーバ２００、ユーザ管理サーバ３００、及び検知サーバ４００が備える機能、及び情報を一つの計算機にまとめることもできる。例えば、仮想化技術を用いて、一つの計算機上にデータ管理サーバ２００、ユーザ管理サーバ３００、及び検知サーバ４００を実現する方法が考えられる。

本発明は、実施例で示したイベントに関する利用目的に限定されるものではない。例えば、不正取引の監視などに利用することもできる。

１００ 外部システム
１０２ 制御部
１５０ ネットワーク
２００ データ管理サーバ
２０２ データ収集部
２０４ 収集設定情報
２０６ 収集データ
３００ ユーザ管理サーバ
３０２ 属性別データ抽出部
３０４ ユーザ属性管理情報
４００ 検知サーバ
４０２ 検知部
４０４ 検知モデル情報
４０５ 検知モデル設定情報
４０６ 検知パターン情報
４０８ 検知状態情報
６０１ 演算装置
６０２ 主記憶装置
６０３ 副記憶装置
６０４ 通信装置
６０５ 入力装置
６０６ 出力装置
６０７ バス
１１０２ ユーザ属性・イベント別データ抽出部
１１０４ ユーザ属性・イベント管理情報
１２０２ 検知モデル抽出部
１２０４ 抽出状態情報

Claims (10)

1. 所定のイベントの発生の予兆を検知するモニタリングシステムであって、
   前記モニタリングシステムは、
   所定の業務を実行する複数のモニタリング対象システムと、
   前記複数のモニタリング対象システムと接続される一つ以上の計算機と、を備え、
   前記一つ以上の計算機は、演算装置、前記演算装置に接続される主記憶装置、及び前記演算装置に接続されるネットワーク装置を有し、
   前記モニタリングシステムは、
   前記複数のモニタリング対象システム毎に、取得するモニタリングデータを特定するための収集設定情報と、
   前記モニタリングデータに含まれるユーザ属性に基づいて分類された属性別データを生成するためのユーザ属性管理情報と、
   所定のイベントの発生に関連する事象である検知パターンの種別及び時系列の組合せである検知モデルを管理する検知モデル情報と、
   前記検知パターンに対応する前記事象の内容を管理する検知パターン情報と、
   前記ユーザ属性毎に適用される前記検知モデルを定義する検知モデル設定情報と、を保持し、
   前記収集設定情報に基づいて、前記複数のモニタリング対象システムの各々から前記モニタリングデータを取得し、所定の前記モニタリングデータを送信するデータ収集部と、
   前記データ収集部から前記所定のモニタリングデータを取得し、前記ユーザ属性管理情報に基づいて、前記取得された所定のモニタリングデータを用いて前記属性別データを生成するデータ抽出部と、
   前記データ抽出部から前記属性別データを取得し、前記検知モデル情報、前記検知モデル設定情報、及び前記属性別データに基づいて、前記ユーザ属性毎に前記所定のイベントの発生の予兆を検知する検知部と、を有することを特徴とするモニタリングシステム。
2. 請求項１に記載のモニタリングシステムであって、
   前記モニタリングシステムは、前記属性別データに対応する前記ユーザ属性、前記ユーザ属性に適用される検知モデルの識別情報、及び検知対象の前記検知パターンの識別情報が対応づけられた検知状態情報を保持し、
   前記検知部は、
   前記検知モデル設定情報に基づいて、前記検知モデルを選択し、
   前記検知状態情報を参照して、検知対象となる第１の検知パターンを特定し、
   前記データ抽出部から、前記選択された検知モデルが適用される前記ユーザ属性に対応する前記属性別データを取得し、
   前記取得された属性別データ、及び前記第１の検知パターンに基づいて、前記第１の検知パターンに対応する事象が発生するか否かを判定し、
   前記判定の結果に基づいて、前記属性別データに対応するユーザ属性について前記選択された検知モデルに対応する前記所定のイベントの発生の予兆を検知することを特徴とするモニタリングシステム。
3. 請求項２に記載のモニタリングシステムであって、
   前記検知部は、
   前記第１の検知パターンに対応する事象が発生すると判定された場合に、前記検知モデル情報に基づいて、前記第１の検知パターンの次の検知対象である第２の検知パターンを特定し、
   前記取得された属性データに対応するユーザ属性、前記選択された検知モデルの識別情報、及び前記第２の検知パターンの識別情報を対応づけて前記検知状態情報に格納し、
   前記選択された検知モデルに対応する所定のイベントの発生の予兆となる全ての前記検知パターンが検知されたか否かを判定し、
   前記選択された検知モデルに対応する所定のイベントの発生の予兆となる全ての検知パターンが検知されたと判定された場合に、アラートを出力することを特徴とするモニタリングシステム。
4. 請求項２に記載のモニタリングシステムであって、
   前記検知部は、
   対象となるモニタリング対象システムの識別情報、対象となる前記ユーザ属性、及び対象となるデータ期間を含む属性別データ送信要求を前記データ抽出部に送信し、
   前記データ抽出部は、
   前記属性別データ送信要求に含まれる前記モニタリング対象システムの識別情報及び前記ユーザ属性を含むモニタリングデータの送信要求を前記データ収集部に送信し、
   前記属性別データ送信要求に含まれる前記ユーザ属性、及び前記ユーザ属性管理情報に基づいて、前記データ収集部から取得したモニタリングデータを分類し、
   前記分類されたモニタリングデータを時系列順に並び替えることによって前記属性別データを生成し、
   前記生成された属性別データを前記検知部に送信し、
   前記データ収集部は、
   前記モニタリングデータの送信要求に含まれる前記モニタリング対象システムの識別情報及び前記ユーザ属性に基づいて、前記複数のモニタリング対象システムから受信した前記モニタリングデータの中から、前記所定のモニタリングデータを読み出し、
   前記読み出された所定のモニタリングデータを前記データ抽出部に送信することを特徴とするモニタリングシステム。
5. 請求項２に記載のモニタリングシステムであって
   前記検知部は、
   前記選択された検知モデルに含まれる検知対象となる検知パターンが複数存在する場合に、前記検知パターン情報を参照して、前記複数の検知パターンの各々について、当該検知パターンを含む前記検知モデルの数を算出し、
   前記検知部の処理負荷が所定のしきい値以上の場合には、前記算出された検知モデルの数が多い前記検知パターンを選択し、
   前記選択された検知パターンに対応する事象が発生するか否かを判定することを特徴とするモニタリングシステム。
6. 請求項２に記載のモニタリングシステムであって、
   前記検知モデル情報には、前記検知モデルの識別情報、前記検知モデルに対応する所定のイベントの発生の予兆が検知された第１の回数、及び前記イベントが実際に発生した第２の回数が対応づけられた情報が格納され、
   前記検知部は、
   前記選択された検知モデルに対応する所定のイベントの発生の予兆が検知された場合に、当該検知モデルに対応する前記第１の回数を更新し、
   前記検知された所定のイベントが発生した場合に、前記選択された検知モデルに対応する前記第２の回数を更新し、
   前記第１の回数に対する前記第２の回数の比率を算出し、
   前記算出された比率が予め設定されたしきい値以下の場合、前記検知モデル情報から前記選択された検知モデルに関する情報を削除することを特徴とするモニタリングシステム。
7. 請求項２に記載のモニタリングシステムであって、
   前記モニタリングシステムは、
   発生したイベントの識別情報、前記発生したイベントに関連する前記ユーザ属性、及び前記発生したイベントの発生時間を示す時刻情報が対応づけられたイベント管理情報を保持し、
   前記データ抽出部は、
   前記イベント管理情報を参照して、前記発生したイベントに関連するモニタリングデータの送信要求を前記データ収集部に送信し、
   前記発生したイベントの識別情報を含めて、前記データ収集部から受信したモニタリングデータを前記検知部に送信し、
   前記検知部は、
   前記検知パターンに基づいて、前記データ抽出部から受信したモニタリングデータを解析することによって、前記検知パターンの種別及び時系列を特定し、
   前記特定された検知パターンの種別、及び時系列に基づいて、新たな検知モデルを生成し、
   前記生成された検知モデルに対応する情報を前記検知モデル情報に格納することを特徴とするモニタリングシステム。
8. 所定の業務を実行する複数のモニタリング対象システムからモニタリングデータを取得し、所定のイベントの発生の予兆を検知する計算機であって、
   前記計算機は、演算装置、前記演算装置に接続される主記憶装置、及び前記演算装置に接続されるネットワーク装置を備え、
   前記複数のモニタリング対象システム毎に、取得する前記モニタリングデータを特定するための収集設定情報と、
   前記モニタリングデータに含まれるユーザ属性に基づいて分類された属性別データを生成するためのユーザ属性管理情報と、
   所定のイベントの発生に関連する事象である検知パターンの種別及び時系列の組合せである検知モデルを管理する検知モデル情報と、
   前記検知パターンに対応する前記事象の内容を管理する検知パターン情報と、
   前記ユーザ属性毎に適用される前記検知モデルを定義する検知モデル設定情報と、を保持し、
   前記収集設定情報に基づいて、前記複数のモニタリング対象システムの各々から前記モニタリングデータを取得し、所定の前記モニタリングデータを送信するデータ収集部と、
   前記データ収集部から前記所定のモニタリングデータを取得し、前記ユーザ属性管理情報に基づいて、前記取得された所定のモニタリングデータを用いて前記属性別データを生成するデータ抽出部と、
   前記データ抽出部から前記属性別データを取得し、前記検知モデル情報、前記検知モデル設定情報、及び前記属性別データに基づいて、前記ユーザ属性毎に前記所定のイベントの発生の予兆を検知する検知部と、を有することを特徴とする計算機。
9. 請求項８に記載の計算機であって、
   前記計算機は、前記属性別データに対応する前記ユーザ属性、前記ユーザ属性に適用される検知モデルの識別情報、及び前記属性別データに対する検知対象の前記検知パターンの識別情報が対応づけられた検知状態情報を保持し、
   前記検知部は、
   前記検知モデル設定情報に基づいて、前記検知モデルを選択し、
   前記検知状態情報を参照して、検知対象となる第１の検知パターンを特定し、
   前記データ抽出部から、前記選択された検知モデルが適用される前記ユーザ属性に対応する前記属性別データを取得し、
   前記取得された属性別データ、及び前記第１の検知パターンに基づいて、前記第１の検知パターンに対応する事象が発生するか否かを判定し、
   前記判定の結果に基づいて、前記属性別データに対応するユーザ属性について前記選択された検知モデルに対応する前記所定のイベントの発生の予兆を検知することを特徴とする計算機。
10. 請求項９に記載の計算機であって、
    前記検知部は、
    前記第１の検知パターンに対応する事象が発生すると判定された場合に、前記検知モデル情報に基づいて、前記第１の検知パターンの次の検知対象である第２の検知パターンを特定し、
    前記取得された属性データに対応するユーザ属性、前記選択された検知モデルの識別情報、及び前記第２の検知パターンの識別情報を対応づけて前記検知状態情報に格納し、
    前記選択された検知モデルに対応する所定のイベントの発生の予兆となる全ての前記検知パターンが検知されたか否かを判定し、
    前記選択された検知モデルに対応する所定のイベントの発生の予兆となる全ての検知パターンが検知されたと判定された場合に、アラートを出力することを特徴とする計算機。

Images