JP6204637B1 - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

Abstract

ユーザのそれまでの操作も含めた総合的な不正検知を行うことを目的とする。このために、情報処理装置は、ユーザの操作ごとに操作種別に応じた判定項目に基づいて不正判定スコアを算出するスコア算出部と、ユーザの操作に応じて該操作と同種の操作種別の前記不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定部と、前記不正度合いについて不正の可能性が高いと判定された操作を行ったユーザに対して前記操作時に本人確認処理を行う本人確認処理部と、商品購入時に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理部と、を備える。

Description

本発明は、情報処理装置、情報処理方法、プログラム、記憶媒体に関し、具体的には、ユーザの不正操作を検知するための技術に関する。

特開平１１−２５９５７１号公報

インターネットの普及により、ユーザは直接店舗へ赴くことなく様々なことを行うことが可能となってきている。
例えば、自宅にいながら、ＥＣ（Electronic Commerce）サイトを利用した商品購入や、保険の申込や、銀行口座の開設などを情報処理装置（例えばＰＣ：Personal Computer）を用いて行うことができる。
しかし、店舗の従業員と顔を合わせずに商品購入などができてしまうことにより、他人になりすまして商品を購入するなどの不正が容易に行われるようになってきている。

不正操作に基づく被害を防止するためには、ユーザの操作が本人によるものか否かを判定することが重要である。しかし、これを人手で行うことは非効率的であり、取引量が増すにつれて難しくなる。
このような事情を鑑みて、特許文献１には、ユーザの操作が不正であるか否かを自動で判定するための構成が記載されている。

ところが、特許文献１に記載された構成では、対象となった操作自体が不正であるか否かを判定することはできるが、それまでのユーザの各種操作を含めて総合的に不正であるか否かを判定することはできない。
そこで本発明は、このような状況を考慮し、それまでのユーザの操作も含めた総合的な不正検知を行うことを目的とする。

本発明に係る情報処理装置は、ユーザの操作ごとに操作種別に応じた判定項目に基づいて不正判定スコアを算出するスコア算出部と、ユーザの操作に応じて該操作と同種の操作種別の前記不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定部と、前記不正度合いについて不正の可能性が高いと判定された操作を行ったユーザに対して前記操作時に本人確認処理を行う本人確認処理部と、商品購入時に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理部と、を備えたものである。
即ち、ユーザの操作ごとに、当該操作の情報（入力情報や環境情報など）だけでなくそれまでの操作時の情報（入力情報や環境情報など）に応じて、不正度合いが判定される。

上記した情報処理装置の前記スコア算出部は、前記本人確認処理の結果不正の可能性が低いと判定された操作を行ったユーザに対して、既に算出済みの前記不正判定スコアを算出し直すスコア再算出処理を実行することが望ましい。
これにより、正しく算出されていなかった不正判定スコアが訂正され、正しいスコアが算出される。

上記した情報処理装置の前記スコア算出部は、最新のユーザ情報に基づいたユーザごとに管理された正常ステータスに基づいて前記不正判定スコアを算出し、前記正常ステータスは、ユーザについての初期登録情報とされ、本人が行ったと推定されるユーザ情報変更操作の後は該ユーザ情報変更操作時の登録情報とされることが望ましい。
これにより、ユーザの最新の登録情報（ユーザの属性情報や環境情報）に応じて、不正判定スコアが算出される。

上記した情報処理装置の前記スコア算出部は、前記判定項目ごとに設定されたユーザごとの重み付けに基づいて前記不正判定スコアを算出することが望ましい。
これにより、ユーザの状況に応じて不正判定スコアが算出される。

上記した情報処理装置の前記判定部は、前記不正判定スコアの算出回数に応じて変更されるユーザごとの判定閾値に基づいて前記判定を行うことが望ましい。
これにより、ユーザの操作頻度に応じて不正判定スコアが算出される。

上記した情報処理装置において、前記不正度合いは高不正判定、中不正判定、低不正判定の少なくとも３段階とされ、前記中不正判定とされたユーザの識別情報を管理者に通知する通知部を更に備えることが望ましい。
これにより、例えば、不正操作か否か判定が難しいときに管理者が手動でユーザの操作に係る情報を確認する場合などに、管理者に対して選択された一部のユーザ情報が通知される。

上記した情報処理装置の前記通知部は、前記判定項目ごとの処理結果を前記ユーザの識別情報と共に通知することが望ましい。
これにより、例えば、不正操作か否か判定が難しいときに管理者が手動でユーザの操作に係る情報を確認する場合などに、判定項目が不正判定スコアの算出に与えた影響が管理者に通知される。

上記した情報処理装置の前記スコア算出部は、関連する前記不正判定スコアに基づいて前記不正判定スコアを算出することが望ましい。
これにより、他の操作種別の不正判定スコアに応じて不正判定スコアが算出される。例えば、ログイン操作の直後にユーザ情報変更操作を行った場合には、ユーザ情報変更操作の直前のログイン操作は関連する操作と判定し、当該ログイン操作の不正判定スコアに基づいて直後のユーザ情報変更操作の不正判定スコアが算出される。

上記した情報処理装置の前記判定部は、ユーザ情報変更操作後の所定の期間において、通常時よりも前記不正度合いが高く判定されやすいように判定閾値を変更して前記判定を行うことが望ましい。
これにより、例えば、届け先の住所を変更する操作などの後には、通常よりも厳しい（即ち高不正判定となりやすい）不正度合い判定処理が実行される。

本発明に係る情報処理方法は、ユーザの操作ごとに操作種別に応じた判定項目に基づいて不正判定スコアを算出するスコア算出ステップと、ユーザの操作に応じて該操作と同種の操作種別の前記不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定ステップと、前記不正度合いについて不正の可能性が高いと判定された操作を行ったユーザに対して前記操作時に本人確認処理を行う本人確認処理ステップと、商品購入時に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理ステップとを、情報処理装置が実行するものである。
この情報処理方法により、それまでのユーザの操作も含めた総合的な不正検知を行う環境が提供される。

本発明に係るプログラムは、上記情報処理方法として実行する処理を演算処理装置に実行させるプログラムである。
本発明に係る記憶媒体は、上記プログラムを記憶した記憶媒体である。

本発明によれば、それまでのユーザの操作も含めた総合的な不正検知を行うことができる。

本発明の実施の形態の全体の構成を示す図である。 本実施の形態の不正監視装置のブロック図である。 本実施の形態のコンピュータのブロック図である。 スコアＤＢに記憶される情報の一例を示す図である。 全体の流れを説明するためのフローチャートである。 全体の流れを説明するためのフローチャートである。 不正監視装置の処理の流れを説明するためのフローチャートである。 全体の流れの別の例を説明するためのフローチャートである。 要注意ユーザ通知処理についてのフローチャートである。 スコア算出処理の他の例についてのフローチャートである。 スコア算出処理の更に他の例についてのフローチャートである。 不正度合い判定処理の他の例についてのフローチャートである。

本実施の形態においては、不正検知を行う情報処理装置として不正監視装置１を例に挙げる。
以下、実施の形態を次の順序で説明する。

＜１．全体構成＞
＜２．ハードウェア構成＞
＜３．ＤＢ＞
［３−１．ユーザＤＢ］
［３−２．店舗ＤＢ］
［３−３．履歴ＤＢ］
［３−４．商品ＤＢ］
［３−５．ウェブページＤＢ］
［３−６．スコアＤＢ］
［３−７．カードＤＢ］
［３−８．カード利用履歴ＤＢ］
＜４．処理の流れ＞
［４−１．全体の流れ］
［４−２．不正監視装置の処理の流れ］
［４−３．全体の流れの別の例］
［４−４．要注意ユーザ通知処理］
［４−５．スコア算出処理の他の例］
［４−６．スコア算出処理の更に他の例］
［４−７．不正度合い判定処理の他の例］
＜５．変形例＞
＜６．まとめ＞
＜７．プログラム＞

＜１．全体構成＞

本実施の形態としての不正監視装置１を含むネットワークシステム全体の構成について、図１及び図２を用いて説明する。
図１に示すように、本実施の形態の不正監視装置１は、通信ネットワーク２を利用した電子商取引を介して商品の販売等を行うＥＣサーバ３、商品購入の際に使用するクレジットカードに関する各種処理を行うカード会社サーバ４、電子商取引を利用するユーザが使用するユーザ端末５，５，５，・・・と相互に通信可能な状態で接続されている。

不正監視装置１は、ユーザが電子商取引を利用する際に行う種々の操作が不正に基づいたものであるか否かを判定するための各種処理（詳しくは後述する）を行う情報処理装置である。

通信ネットワーク２の構成は特に限定されるものではなく、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網などが想定される。
また通信ネットワーク２の全部または一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。

ＥＣサーバ３は、通信ネットワーク２を利用した電子商取引として、例えば複数のウェブページで構成された仮想商店街（以降、「ショッピングサイト」と記載）を提供し、そこで販売される商品の閲覧や購入に係る各種機能を提供する。
具体的には、ＥＣサーバ３を用いて運営される仮想商店街に加盟している店舗が複数あり、該店舗のＥＣ担当者（以降、販売者と記載）が販売する商品の情報（商品情報）を登録するための機能や、登録された商品情報を変更する機能をＥＣサーバ３は有する。そのために、ＥＣサーバ３は、加盟店舗情報や商品情報を管理する機能を備える。
また、ＥＣサーバ３は、ショッピングサイトで扱っている商品群の中からユーザが所望する商品を検索して提示する機能や、ユーザが商品の購入操作を行った際に、販売者へ商品を発注する機能や、商品の売買が成立した際の代金のやりとりを仲介する決済処理機能や、各ユーザへ商品を配送するための機能や、商品の購入が確定した際のユーザへの通知機能や、商品を購入したユーザ情報を販売者へ通知する機能などを有する。
ユーザが商品を購入する際には、商品の送付先（住所）情報や、クレジットカード番号や連絡先（電話番号や電子メールアドレスなど）の情報が必要とされる。ユーザが商品を購入するたびにこれらの情報を入力する手間を省くため、ＥＣサーバ３は、ユーザ情報を管理する機能を備える。

そして、ＥＣサーバ３は、上記の各種機能を実現するためのユーザインタフェースとしてのウェブページを他の情報処理装置（ユーザ端末５や店舗端末６）上に表示させるために、ウェブページデータの生成処理と送信処理を行う。
ウェブページデータは、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、商品の説明などのテキストデータや商品画像などの画像データと、それらの配置や表示態様（文字色やフォントや大きさや装飾など）が記述されている。
ウェブページとしては、例えば、ユーザや配信依頼者にログイン情報を入力させるためのログインページや、広告内容を入力させるためのウェブページなどである。
また、ＥＣサーバ３は、ユーザや販売者の認証機能や各種データベースへの情報の登録機能、各種データベースから情報を取得する機能などを備える。

これまで説明してきた各種機能を実現するために、ＥＣサーバ３は、ユーザ情報が記憶されたユーザＤＢ５０、商品を販売する店舗の情報が記憶される店舗ＤＢ５１、ユーザの操作履歴が記憶される履歴ＤＢ５２、ショッピングサイトで扱う商品の情報が記憶される商品ＤＢ５３、各種ウェブページのウェブページデータが記憶されるウェブページＤＢ５４を管理する。
また、ショッピングサイトを利用するユーザの不正を監視する不正監視装置１は、ユーザＤＢ５０、履歴ＤＢ５２に記憶された情報を取得し、後述する不正検知などの各種処理に用いる。そして、ユーザの操作ごとのスコア（不正の度合いを判定するための数値であり後述する）やユーザに対して下した判定結果等をスコアＤＢ５５に記憶する。

カード会社サーバ４は、クレジットカードに関する処理を行う。具体的には、クレジットカードの情報管理や、クレジットカードの番号を指定した与信照会や、売上請求に関する処理等を行う。
これらの処理を行うために、カード会社サーバ４は、クレジットカードの情報が記憶されるカードＤＢ５６、クレジットカードの利用履歴が記憶されるカード利用履歴ＤＢ５７、を管理している。

ユーザ端末５は、ショッピングサイトを利用するユーザが使用する端末である。
店舗端末６は、販売者が利用する端末である。
ユーザ端末５や店舗端末６では、必要に応じて各種の送受信処理や表示処理などが実行される。また、ユーザ端末５や店舗端末６は、例えば、通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistant）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。
また、図示しないが、カード会社サーバ４を運営しているカード会社が提携しているクレジットカードブランドの加盟店舗の端末も、上記したそれぞれの情報処理装置と通信可能な状態で通信ネットワーク２に接続されている。

尚、図１に示すように、不正監視装置１、ＥＣサーバ３、ユーザＤＢ５０、店舗ＤＢ５１、履歴ＤＢ５２、商品ＤＢ５３、ウェブページＤＢ５４、スコアＤＢ５５は、ＥＣサイト運用システム７を構成する。
また、カード会社サーバ４、カードＤＢ５６、カード利用履歴ＤＢ５７は、カード会社システム８を構成する。
尚、不正監視装置１は、ＥＣサイト運用システム７に含まれずに独立していてもよい。

不正監視装置１が備える各部について、図２を参照して説明する。
不正監視装置１は、スコア算出部１ａと、判定部１ｂと、本人確認処理部１ｃと、決済方法変更処理部１ｄと、通知部１ｅと、を備える。

スコア算出部１ａは、ユーザの操作ごとに判定項目に応じた不正判定スコアを算出するスコア算出処理を実行する。判定項目は、操作の種別（以降、「操作種別」と記載）ごとに設定されている。操作種別としては、例えば、「ログイン操作」や「ユーザ情報変更操作」や「購入操作」などである。
操作種別ごとに設定された判定項目の一例を挙げる。「購入操作」に対する判定項目は、例えば、以下の項目である。
（Ｋ１）ＩＰアドレス（Internet Protocol Address）は正常か
（Ｋ２）直近の所定期間に住所変更されていないか
（Ｋ３）購入量は適正か
（Ｋ４）購入商品が属する商品ジャンルは適切か
（Ｋ５）直近の所定期間にクレジットカード情報が変更されていないか
（Ｋ６）ウェブブラウザ（ウェブページをユーザ端末５上に表示するためにユーザ端末５にインストールされているソフトウェア）は変わっていないか
（Ｋ７）ウェブブラウザの設定言語（以降、「ウェブブラウザ言語」と記載）が変わっていないか
（Ｋ８）操作態様は適正か

判定項目に基づく具体的な判定を例示する。
例えば、（Ｋ１）の判定項目では、今まで利用したことのあるＩＰアドレスでＥＣサーバ３へ接続してきたユーザに対しては不正度合いは低いと判定する。
逆に、今まで一度も利用したことのないＩＰアドレスから接続してきた場合は不正度合いは若干高めと判定する。特に、当該ユーザの居住地とは異なる国から接続してきた場合は、不正度合いを高めと判定する。

また、（Ｋ４）の判定項目では、今まで購入したことのある商品ジャンルに属する商品を購入しようとしているユーザに対しては、不正度合いは低いと判定する。
一方、今まで購入したことのない商品ジャンルに属する商品を購入しようとしているユーザに対しては、不正度合いは若干高めと判定する。特に、今まで男性用の商品ばかり購入してきたユーザが女性用の商品を購入しようとしている場合には、不正度合いはかなり高めと判定する。
即ち、本実施の形態における商品ジャンルとは、ショッピングサイトで各商品がカテゴライズされた商品ジャンルのみならず、「男性用」や「女性用」などのように商品をグループ分けできる概念も含む。

不正判定スコアは、不正の疑いの強弱を数値化したものであり、ユーザの操作ごとに上記の判定項目に基づいて算出される。例えば、不正の可能性が高い操作に対しては、高い不正判定スコアが付され、不正の可能性が低い操作に対しては、低い不正判定スコアが付される。一例として、不正判定スコアは０〜１００の数値とされ、不正の可能性が高い操作ほど高い数値が付される。
また、不正判定スコア（０〜１００）は、判定項目ごとの点数を加算したものとされる。判定項目ごとに最大の点数（例えば、８項目であれば、１項目あたり１２．５点）が設定され、８項目それぞれで算出された判定項目ごとのスコア（以降、「項目別スコア」と記載）を加算したものが不正判定スコアとされる。

項目別スコアの最大値（例えば前述の１２．５点）は、全ての判定項目間で一律の値とされてもよいし、判定項目間で重みを付けて設定されてもよい。例えば、重要と思われる判定項目に対して、高めの数値を項目別スコアの最大値としてもよい。具体的には、（Ｋ２）、（Ｋ７）を各２０点満点とし、そのほかの６項目については各１０点満点として、合計を１００点満点としてもよい。
また、判定項目間の重み付けは、ユーザごとに変えてもよい。具体的には、ＩＰアドレスが頻繁に変わるユーザに対しては（Ｋ１）の重みを軽くするが、毎回同一のＩＰアドレスを使用しているユーザに対しては（Ｋ１）の重みを重くすることが考えられる。

判定項目に応じて不正判定スコアを算出する際には、基準となるステータスが必要となる。例えば、ユーザが行った購入操作が不正操作であるか否かを判定するために、（Ｋ１）のＩＰアドレスが正常であるか否かを判定するには、基準となる（即ち比較対象となる）ＩＰアドレスが必要となる。基準となるステータスは、ユーザごとに異なり、ユーザＤＢ５０に記憶される。
以降では、この基準となるステータスを「正常ステータス」と記載する。

正常ステータスは、ユーザ登録を行ったときの初期登録情報が先ず「正常ステータス」として登録される。初期登録情報は、必ずしもユーザによって入力された情報（例えば、住所や年齢や趣味など）に限らない。ユーザ登録を行った際に用いられた端末情報やウェブブラウザ情報（例えばソフトウェアの種類）やＩＰアドレスや入力態様（文字入力速度やキーボードの使用態様やマウスの使用態様を含む）なども初期登録情報とされる。

項目別スコアは、他の項目別スコアに基づいて算出されてもよい。例えば、（Ｋ１）と（Ｋ２）が関連している場合には、（Ｋ１）の項目別スコアに応じて（Ｋ２）の項目別スコアを変動させてもよい。即ち、（Ｋ１）が０点の場合の（Ｋ２）の項目別スコアと、（Ｋ１）が１０点の場合の（Ｋ２）の項目別スコアが異なる数値であってもよい。

また、不正判定スコアについても、他の不正判定スコアに基づいて算出されてもよい。例えば、ユーザ情報変更操作の直後に購入操作を行った場合、双方の操作に関連があると推定し、ユーザ情報変更操作の不正判定スコアに基づいて購入操作の不正判定スコアが算出されてもよい。

また、スコア算出部１ａは、一度算出した不正判定スコア（及び項目別スコア）を再び算出し直すスコア再算出処理を実行する。スコア再算出処理のタイミングとしては、例えば、正常ステータスが変更になった場合などである。
具体的には、それまで「東京」から接続していることが判別可能なＩＰアドレスを利用していたユーザが、「大阪」から接続していることが判別可能なＩＰアドレスを利用した場合には、当該操作に関する（Ｋ１）の項目別スコアは高く算出される。しかし、後述する本人確認処理によって、「大阪」からの接続が本人によるものと確認され次第、スコア再算出処理が実行されて、高く算出された（Ｋ１）の項目別スコアが再算出され、低くされる。
この際、対象ユーザの正常ステータスには、東京のＩＰアドレスに加えて大阪のＩＰアドレスが追加される。即ち、登録されたＩＰアドレスの何れかに該当すれば、（Ｋ１）の項目別スコアは低く算出される。勿論、引っ越しなどの事情により、東京のＩＰアドレスが使用されなくなった場合には、東京のＩＰアドレスが正常ステータスから削除されることが望ましい。そのために、例えば、不正監視装置１は所定期間使用されないＩＰアドレスを削除するように構成されていてもよい。

尚、「ログイン操作」や「ユーザ情報変更操作」に対する判定項目は、例えば、上記の（Ｋ１）、（Ｋ６）、（Ｋ７）、（Ｋ８）とされる。
また、「ユーザ情報変更操作」に対して項目別スコアを算出する際に、その変更が適切な変更であった場合には、スコアを低く算出してもよい。具体的には、例えば、クレジットカードの情報を変更する操作が、カードの有効期限切れに応じた変更であるならば、当該ユーザ情報変更操作は適切な操作である可能性が高い。

判定部１ｂは、算出された不正判定スコアに応じてユーザの操作の不正度合いを判定する処理（不正度合い判定処理）を実行する。不正度合い判定処理としては、第１の不正度合い判定処理と、第２の不正度合い判定処理を例に挙げる。
また、以下の例においては、３段階（不正度合いが低い「白判定」、不正度合いが高い「黒判定」、白判定と黒判定の中間の「灰判定」）の不正度合いが設けられた例を説明する。

第１の不正度合い判定処理では、判定対象となった一つの操作（以降、「対象操作」と記載）に付された不正判定スコアだけを考慮して判定を行う。
第２の不正度合い判定処理では、対象操作の不正判定スコアに加えて、対象操作と同種の操作種別に対して付された不正判定スコアの履歴も考慮した判定を行う。

例えば、第１の不正度合い判定処理では、第１の判定閾値を用いて不正度合いが判定される。第１の判定閾値は、二つの数字の組で構成され、例えば、「白判定」と「灰判定」を分けるための閾値「３０点」と、「灰判定」と「黒判定」を分けるための閾値「６０点」で構成される。
具体的には、０〜２９点が「白判定」、３０〜５９点が「灰判定」、６０〜１００点が「黒判定」とされる。
従って、第１の不正度合い判定処理では、判定対象となった操作に対して付された不正判定スコアが「２０点」であれば、「白判定」とされ、「５０点」であれば「灰判定」とされ、「９０点」であれば「黒判定」とされる。
第１の不正度合い判定処理における判定結果を第１の判定結果と記載する。

また、第２の不正度合い判定処理では、第２の判定閾値を用いて不正度合いが判定される。第２の判定閾値も、二つの数字の組で構成され、例えば、「白判定」と「灰判定」を分けるための閾値「１５０点」と、「灰判定」と「黒判定」を分けるための閾値「３００点」で構成される。
例えば、直近の１０個の「ログイン操作」の不正判定スコアを加算した「累積不正判定スコア」に応じて、不正度合いが「白判定」と「灰判定」と「黒判定」の何れに該当するのかを判定する。
このとき、累積不正判定スコアが０〜１４９点が「白判定」、１５０〜２９９点が「灰判定」、３００〜１０００点が「黒判定」とする。
第２の不正度合い判定処理における判定結果を第２の判定結果と記載する。

上記の例に示した例示において、第２の判定閾値（例えば「１５０点」）を第１の判定閾値（例えば「３０点」）の１０倍（直近の１０個の不正判定スコアによって累積不正判定スコアを算出するため）よりも小さい数値とすることで、第１の不正度合い判定処理で「白判定」がされ続けたとしても、第２の不正度合い判定処理で「灰判定」や「黒判定」がなされる可能性がある。これにより、一つ一つの操作に対する不正度合いを判定するだけでなく、総合的な不正度合いを判定することができる。

尚、第１の判定閾値や第２の判定閾値は、固定の数値でもよいし、ユーザによって変えてもよい。
例えば、不正判定スコアの算出回数に応じて、ユーザ毎に変えることが考えられる。具体的には、不正判定スコアの算出回数が３回であり、それぞれのスコアが「０点」、「５点」、「５点」のユーザＡと、不正判定スコアの算出回数が１００回であり、全てのスコアが「０点」〜「５点」の間に収まっているユーザＢとでは、不正判定スコアの信頼度が異なる。即ち、ユーザＢの次の不正判定スコアが「１０点」となる可能性は、これまでの履歴から考えるとユーザＡよりも小さいと考えられる。
そこで、ユーザＢの判定閾値は、ユーザＡよりも小さく（換言すれば、より厳しく）することが妥当と考えられる。
また、累積不正判定スコアは、単に直近の１０個の不正判定スコアを加算したものでもよいし、直近のものほど重みを付けて加算したものでもよい。

更に、第１の判定閾値や第２の判定閾値は、タイミングによって変更してもよい。
例えば、商品の配達先を変更する「ユーザ情報変更操作」が行われた後の所定の期間（例えば、３日など）の商品の「購入操作」については、判定閾値を厳しく（即ち低く）してもよい。

本人確認処理部１ｃは、不正度合いの高い操作を行ったユーザに対して、当該操作がユーザ本人によるものかを確認する本人確認処理を実行する。
例えば、第１及び第２の不正度合い判定処理において、「黒判定」がなされたユーザに対して、本人確認処理を実行する。
尚、本人確認処理は、不正度合い判定処理の対象となったユーザ操作全てを対象とする。即ち、「ログイン操作」が「黒判定」された場合には、当該「ログイン操作」に対して本人確認処理が実行される。また、「購入操作」が「黒判定」された場合には、当該「購入操作」に対して本人確認処理が実行される。

本人確認の方法としては、例えば、ユーザ本人しか知り得ない質問を提示し、その回答結果から確認を行うことが考えられる。
また、ユーザ本人が使用していると推測される別の端末（例えば携帯電話）などにメッセージ等を送信し、その返答から本人確認を行うことが考えられる。

決済方法変更処理部１ｄは、不正度合いの高い操作を行ったユーザ（例えば「黒判定」されたユーザ）に対して、決済方法を変更する処理を実行する。
決済方法の変更とは、商品購入の際の代金支払い方法において、例えば、クレジットカードの利用を不可とし、現金振り込みのみ可能とする処理である。
決済方法変更処理の実行タイミングは、「購入操作」を行ったタイミングであるが、決済方法変更処理を行うと判定する契機となる操作種別は、「購入操作」でなくてもよい。
即ち、「ユーザ情報変更操作」が「黒判定」となったことに応じて、その後の「購入操作」の際に決済方法変更処理を実行してもよい。

通知部１ｅは、不正度合いが「灰判定」とされたユーザを管理者（不正検知を行う者）に通知する要注意ユーザ通知処理を実行する。通知タイミングは如何様でもよく、例えば、「灰判定」がなされた直後でもよいし、一日１回など定期的であってもよい。

また、通知部１ｅは、要注意ユーザ通知処理の際には、「灰判定」の判定結果と共に、判定結果に用いられた不正判定スコア及び判定項目ごとの項目別スコアを通知する。

＜２．ハードウェア構成＞

図３は、図１に示した不正監視装置１、ＥＣサーバ３、カード会社サーバ４、ユーザ端末５、店舗端末６、そして、ユーザＤＢ５０、店舗ＤＢ５１、履歴ＤＢ５２、商品ＤＢ５３、ウェブページＤＢ５４、スコアＤＢ５５、カードＤＢ５６、カード利用履歴ＤＢ５７のハードウェアを例示する図である。それぞれのサーバや端末におけるコンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ（Read Only Memory）１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ（Random Access Memory）１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インタフェース１０５も接続されている。
入出力インタフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力部１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力部１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、通信ネットワーク２を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インタフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われる。また、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、不正監視装置１、ＥＣサーバ３、カード会社サーバ４、ユーザ端末５、店舗端末６、そして、ユーザＤＢ５０、店舗ＤＢ５１、履歴ＤＢ５２、商品ＤＢ５３、ウェブページＤＢ５４、スコアＤＢ５５、カードＤＢ５６、カード利用履歴ＤＢ５７のそれぞれにおいて後述する情報処理や通信が実行される。
尚、不正監視装置１、ＥＣサーバ３、カード会社サーバ４、ユーザ端末５、店舗端末６、そして、ユーザＤＢ５０、店舗ＤＢ５１、履歴ＤＢ５２、商品ＤＢ５３、ウェブページＤＢ５４、スコアＤＢ５３、カードＤＢ５６、カード利用履歴ＤＢ５７を構成するそれぞれの情報処理装置は、図３のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮなどによりシステム化されていてもよいし、インターネットなどを利用したＶＰＮ（Virtual Private Network）などにより通信可能な状態で遠隔地に配置されたものでもよい。

＜３．ＤＢ＞

ＥＣサーバ３やカード会社サーバ４が管理する各種ＤＢについて説明する。

［３−１．ユーザＤＢ］
ユーザＤＢ５０にはＥＣサーバ３が提供するショッピングサイトを利用するユーザの情報が記憶される。例えば、一つのユーザＩＤ（Identification）に対して、ログインパスワード、氏名、年齢、性別、住所、メールアドレス、年収、趣味などの個人的な情報が紐付けられて記憶される。

また、ユーザＤＢ５０には、先の「正常ステータス」としての情報が記憶される。
例えば、ユーザが興味ある商品ジャンルの情報が記憶される。商品ジャンルとしては、例えば、「アウトドア用品」や「スポーツ用品」などの比較的大きな枠であってもよいし、更に細かく絞られた「○○社のスポーツシューズ」や「ジョギングシューズ」などであってもよいし、「イタリア製」などのキーワードであってもよい。
また、ユーザの操作態様の情報が記憶される。操作態様とは、例えば、ウェブページに設けられた検索欄を切り換えるための操作手段として、「マウス」と「キーボード」の何れを用いるユーザであるのか記憶される。
他にも、入力の際の癖などが記憶されてもよい。例えば、文字の入力速度や、文字入力の方法が複数ある言語であれば入力方法（例えば、かな入力であるのか、ローマ字入力であるのかなど）や、サジェストワードの利用の有無などが記憶されてもよい。
更に、マウス軌跡を取得できる環境であれば、マウス軌跡の癖が記憶されてもよい。

［３−２．店舗ＤＢ］
店舗ＤＢ５１には、店舗や販売者の情報が記憶される。例えば、一つの店舗ＩＤに対して、ログインパスワード、店舗名、住所、電話番号、メールアドレス、店舗ページのＵＲＬ（Uniform Resource Locator）情報、販売商品情報（例えば、商品ＩＤや商品ページＵＲＬ）、店舗ロゴ情報などが紐付けられて記憶される。
商品ページＵＲＬは、商品ページごとに付されるＵＲＬであり、同一商品であっても販売者が異なる場合には、異なる商品ページＵＲＬが付される。
店舗ロゴの情報は、画像データそのものでもよいし、保存されている画像データのリンク情報（ＵＲＬ情報）などでもよい。

［３−３．履歴ＤＢ］
履歴ＤＢ５２には、ユーザの操作に関する各種履歴が記憶される。
具体的には、ユーザが行った操作ごとに、履歴ＩＤ、操作種別、操作対象（「購入操作」であれば対象となった商品ＩＤ、「ユーザ情報変更操作」であれば変更対象となった項目名など）、操作日時、操作結果（「ログイン操作」であればログイン可否、「ユーザ情報変更操作」であれば変更可否、「購入操作」であれば購入したのかキャンセルしたのかを示す情報）などが記憶される。

［３−４．商品ＤＢ］
商品ＤＢ５３には、ショッピングサイトを介して売買が可能な各商品についての情報が記憶される。例えば、商品を一意に識別可能な商品ＩＤに対して、商品ジャンル、商品画像、製造者（メーカー）情報、製造者によって付与される型番情報、販売開始日、取扱商品提供者情報、在庫情報などが紐付けられて記憶される。
商品画像の情報は、画像データそのものでもよいし、保存されている画像データのリンク情報（ＵＲＬ情報など）でもよい。
また、商品ＤＢ５２には、上記以外にも、生産地や商品のスペック（色、大きさ、性能情報）などが記憶されてもよい。

［３−５．ウェブページＤＢ］
ウェブページＤＢ５４には、ＥＣサーバ３がユーザや販売者に提供する各種ウェブページのデータが記憶される。具体的には、ログインページや検索ページや検索結果ページや商品ページや各種管理ページなどのウェブページデータである。
ウェブページデータとしては、ウェブページのＵＲＬ情報と各ウェブページ上に配置されるオブジェクト（画像やテキストやバナーなど）の配置情報が記憶される。配置情報とは、ウェブページ上における各オブジェクトの配置態様（位置や大きさ、色等）が記載された情報である。
尚、ウェブページＤＢ５４に記憶される情報は、例えば、ＨＴＭＬなどの構造化文書ファイルで記憶されてもよい。

［３−６．スコアＤＢ］
スコアＤＢ５５には、操作ごとの不正判定スコアや判定項目ごとの項目別スコアが記憶される。
具体例を図４に示す。
図４に示すスコアＤＢ５５には、履歴ＩＤが「Ｈ０１３２」とされた操作履歴に対して、操作種別として「購入操作」、不正判定スコアとして「１０点」、項目別スコアとして（Ｋ１）〜（Ｋ８）のそれぞれの項目別スコアが紐付けられている。
また、履歴ＩＤが「Ｈ０１３３」とされた操作履歴に対して、操作種別として「ログイン操作」、不正判定スコアとして「３８点」、項目別スコアとして（Ｋ１）、（Ｋ６）、（Ｋ７）、（Ｋ８）の項目別スコアが紐付けられている。

また、スコアＤＢ５５には、操作ごとのの第１の判定結果及び第２の判定結果が記憶される。
具体的には、図４に示すように、履歴ＩＤが「Ｈ０１３２」とされた操作履歴に対して、第１の判定結果である「白判定」、第２の判定結果である「灰判定」が紐付けられて記憶されている。
また、履歴ＩＤが「Ｈ０１３３」とされた操作履歴に対して、第１の判定結果である「灰判定」、第２の判定結果である「黒判定」が紐付けられて記憶されている。

尚、履歴ＩＤからは、ユーザＩＤが一意に特定可能とされている。従って、どのユーザの操作履歴であるかは、履歴ＩＤに基づいて特定可能である。
もちろん、スコアＤＢに記憶される履歴ごとにユーザＩＤが併せて記憶されてもよい。

［３−７．カードＤＢ］
カードＤＢ５６には、カード会社が管理しているユーザＩＤに対してクレジットカードのカード番号、名義人、セキュリティコード、与信枠、利用可能額、有効期限などの情報が紐付けて記憶される。

尚、与信枠は、例えば１ヶ月など所定期間ごとのカード利用限度額を定めたものであり、利用可能額は、該利用限度額から上記所定期間におけるカード利用総額を減じた額である。上記所定期間内に与信枠分のカード利用を行うと利用可能額は０円となり、該所定期間においてはそれ以上のカード利用が不能となる。

また、ここでは説明の便宜上、セキュリティコードの情報がカードＤＢ５６に記憶されるものとしているが、実際においては、安全面等を考慮して、セキュリティコードの情報をカードＤＢ５６とは別の記憶手段に記憶させることができる。

前述したＥＣサイト運用システム７を利用するユーザに付されるユーザＩＤと、ここで述べたカード会社システム８を利用するユーザに付されるユーザＩＤは異なるものであってもよい。

［３−８．カード利用履歴ＤＢ］
カード利用履歴ＤＢ５７には、クレジットカードのカード番号ごとに利用金額、利用日、利用店舗等の利用履歴情報が紐付けられて記憶されている。
カード利用履歴ＤＢ５７には、クレジットカードが利用されるごとに、該クレジットカードのカード番号に対し利用金額、利用日、利用店舗等の情報がカード会社サーバ４によって新たに紐付けられて記憶される。

＜４．処理の流れ＞

以下、処理の流れについて、説明する。

［４−１．全体の流れ］
全体の流れについて、ユーザがログイン操作と購入操作を行う例を挙げて図５及び図６を参照して説明する。

ユーザ端末５はステップＳ１０１において、ユーザがログインページを表示させる操作を行ったことに応じ、ログインページ要求処理を実行する。ログインページ要求処理によりユーザ端末５からＥＣサーバ３へログインページ要求が送信されると、ＥＣサーバ３はステップＳ２０１において、ログインページ送信処理を実行する。
これにより、例えば、ＥＣサーバ３から受信したショッピングサイトへのログイン画面情報（ウェブページデータ）に応じたウェブページがユーザ端末５上に表示される。

次に、ユーザ端末５はステップＳ１０２において、ユーザによって入力されたログイン情報（ユーザＩＤとログインパスワード）ＥＣサーバ３へ送信するログイン情報送信処理を実行する。ユーザ端末５からＥＣサーバ３へログイン情報が送信されると、ＥＣサーバ３はステップＳ２０２において認証処理を実行し、続くステップＳ２０３において認証結果通知処理を実行する。
具体的には、ＥＣサーバ３は、ユーザ端末５上で入力されたユーザＩＤとログインパスワードをユーザＤＢ５０に記憶された情報と比較して当該ユーザのログイン可否を判定し、認証結果をユーザ端末５へ通知する。尚、認証結果をユーザ端末５へ返すと共に、ショッピングサイトのトップページのウェブページデータを送信してもよい。これにより、ユーザ認証がなされると共に、ユーザ端末５上にショッピングサイトのトップページが表示される。

尚、図５に示す一連の流れは、ステップＳ２０２の認証処理においてログイン可と判定された場合を示している。ステップＳ２０２においてログイン不可と判定した場合は、ユーザ端末５は再度ステップＳ１０２の処理を実行し、これに応じてＥＣサーバ３はステップＳ２０２の処理を実行する。

続いて、ＥＣサーバ３はステップＳ２０４において、ユーザの操作（ログイン操作）の履歴を履歴ＤＢ５２に記憶する操作履歴記憶処理を実行し、続くステップＳ２０５において、履歴ＤＢ５２に操作履歴が追加（更新）されたことを不正監視装置１へ通知する履歴追加通知処理を実行する。

追加通知を受信した不正監視装置１は、ステップＳ３０１において、スコア算出処理を実行する。スコア算出処理では、判定項目ごとの項目別スコアと、それらを積算した不正判定スコアを算出する。
続いて、不正監視装置１はステップＳ３０２において、不正度合い判定処理を実行する。ここでは、第１の不正度合い判定処理及び第２の不正度合い判定処理を行う。
尚、対象操作と同種の操作種別に対して付された不正判定スコアの履歴が存在しない場合は、第２の不正度合い判定処理は行わない。即ち、今回のログイン操作以外に他のログイン操作の履歴がない場合には、第２の不正度合い判定処理は行わない。

次に、不正監視装置１はステップＳ３０３において、算出した各スコア等をスコアＤＢ５５に記憶する処理を実行する。
これにより、図４に示すスコアＤＢ５５にログイン操作の履歴に応じた項目別スコアと不正判定スコアが新たに記憶される（例えば図４に示す履歴ＩＤ＝Ｈ０１３３とされたレコード）。更に、この処理では、不正度合い判定処理における判定結果がスコアＤＢ５５に記憶される。

続いて、不正監視装置１はステップＳ３０４において、本人確認処理を実行する。尚、ステップＳ３０２の不正度合い判定処理の結果によっては本人確認処理が不要な場合もあり、その場合には、ステップＳ３０４の処理は実行しない。
本人確認処理では、対象操作（即ち、ステップＳ３０１におけるスコア算出の対象となった操作）が本人によるものかを確認する処理を行う。

次に、不正監視装置１はステップＳ３０５において、スコア再算出処理を実行する。この処理は、先のステップＳ３０４の本人確認処理によって正常ステータスが更新された場合に実行される処理であり、高く算出された（即ち不正度合いが高い）不正判定スコアを適正な数値へと算出し直す処理である。

そして、不正監視装置１はステップＳ３０６の不正度合い判定処理とステップＳ３０７のスコア記憶処理を再度実行する。
これらの処理により、判定結果としての不正度合いが更新され、スコアＤＢ５５に記憶された不正判定スコアや項目別スコアが更新される。

続いて、ユーザ端末５を利用しているユーザが商品の検索を行い、検索結果として抽出された商品の購入を行った際の各情報処理装置の処理について、図６を参照して説明する。
先ず、ユーザ端末５はステップＳ１０３において、ユーザの検索操作に基づいた検索クエリ送信処理を実行する。この処理により、検索クエリがＥＣサーバ３へ送信される。

検索クエリを受信したＥＣサーバ３は、ステップＳ２０６において、検索処理を実行する。この処理では、商品ＤＢ５３に記憶された商品から検索クエリに応じた商品を抽出する処理である。
続いて、ＥＣサーバ３はステップＳ２０７において、検索結果通知処理を実行する。この処理では、例えば、ユーザの属性等に応じて優先順位が付与された検索結果をユーザ端末５に送信する。

検索結果を受信したユーザ端末５は、検索結果をユーザに提示する。そして、ユーザが検索結果から商品を選択して購入する操作を行ったことに応じ、ユーザ端末５はステップＳ１０４において、購入操作受付処理を実行する。
購入操作受付処理では、ユーザ端末５を利用するユーザのユーザＩＤと共にユーザの購入操作の対象となった商品の商品ＩＤや購入条件（例えば、個数や送付先や支払い方法など）を購入情報として送信する。

購入情報を受信したＥＣサーバ３はステップＳ２０８において、注文受付処理を実行する。
注文受付処理では、ユーザが購入する商品を出品している店舗に対して購入された商品の商品ＩＤや購入数などの購入情報を通知する処理や、クレジットカードを使用する上で必要となる与信照会などの各種処理を実行する。
これらの処理は、ＥＣサイト運用システム７に属する他の情報処理装置や店舗端末６やカード会社システム７に属する情報処理装置と連携しながら実行される。

続いて、ＥＣサーバ３はステップＳ２０９において、確認メール送信処理を実行する。確認メール送信処理では、ユーザ端末５に対して、注文を受け付けたことを確認する電子メールを送信する。
尚、確認メールの送信先をユーザ端末５とするのではなく、ユーザ端末５を利用しているユーザが指定した端末（例えば携帯電話端末など）を送信先としてもよい。

続くステップＳ２１０において、ＥＣサーバ３は操作履歴記憶処理を実行する。
操作履歴記憶処理では、ユーザがユーザ端末５を用いて行った購入操作に基づく履歴を履歴ＤＢ５２に記憶する。
そして、ＥＣサーバ３はステップＳ２１１において、履歴追加通知処理を実行する。
履歴追加通知処理では、操作履歴（ここでは購入操作の履歴）が追加（更新）されたことを不正監視装置１へ通知する。

追加通知を受信した不正監視装置１は、ステップＳ３０８乃至Ｓ３１４において、スコア算出処理、不正度合い判定処理、スコア記憶処理、本人確認処理、スコア再算出処理、不正度合い判定処理、スコア記憶処理を順に実行する。これらの各処理は、先のステップＳ３０１乃至Ｓ３０７の各処理と同様の処理となるため、詳細は省略する。

続いて、不正監視装置１はステップＳ３１５において、決済方法変更処理を実行する。
決済方法変更処理は、不正度合いの高い操作を行ったユーザに対して決済方法を変更する処理である。
尚、不正度合いの低い操作しか行っていないユーザに対しては、決済方法変更処理を実行しない。

不正度合いの高い操作を行ったユーザとは、例えば、先のステップＳ３１３の不正度合い判定処理において、直前の購入操作（ステップＳ１０４）の不正度合いが高いとして「黒判定」されたユーザである。
また、直前の購入操作だけでなく、それまでに不正度合いの高い操作を行ったユーザに対して決済方法変更処理を実行してもよい。
他にも、直前の購入操作のためのログイン操作が行われてから当該購入操作までの各操作の中に、不正度合いが高いとして「黒判定」された操作が含まれる場合に、決済方法変更処理を実行してもよい。

尚、決済方法変更処理を実行した不正監視装置１は、ステップＳ３１５の処理の後に、ユーザに対して（即ちユーザ端末５に対して）、決済方法が変更された旨を通知する処理を実行してもよい。また、決済方法として現金振り込みのみ可能とする場合には、振り込み先の情報などを併せて通知してもよい。

また、ステップＳ２０９の確認メール送信処理は、ステップＳ３１５の決済方法変更処理の後に実行してもよい。即ち、決済方法として何れの方法が利用可能であるのか（振り込みのみとするのか、クレジットカードを利用可能であるのか）が確定してから、ユーザに確認メールを送信してもよい。

［４−２．不正監視装置の処理の流れ］
先の図５，図６に示した処理の流れを実現するために不正監視装置１が実行する処理例について、図７を参照して説明する。
先ず、不正監視装置１はステップＳ４０１において、履歴の追加通知を受信したか否かを判定する処理を実行する。
この処理は、ユーザ操作に応じた操作履歴が履歴ＤＢ５２に記憶された際にＥＣサーバ３から通知される追加通知を受信したか否かを判定する処理である。追加通知は、先の図５のステップＳ２０５や図６のステップＳ２１１で発行される。

続いて、不正監視装置１はステップＳ４０２（図７）において、スコア算出処理を実行する。スコア算出処理では、項目別スコアと、不正判定スコアを算出する。
この処理は、図５のステップＳ３０１や図６のステップＳ３０８の処理である。

そして、不正監視装置１はステップＳ４０３（図７）において、不正度合い判定処理を実行する。不正度合い判定処理では、第１の不正度合い判定処理及び第２の不正度合い判定処理を実行する。
この処理は、図５のステップＳ３０２、ステップＳ３０６、図６のステップＳ３０９、ステップＳ３１３の処理である。

次に、不正監視装置１はステップＳ４０４（図７）において、スコア記憶処理を実行する。この処理は、スコア算出処理で算出した各種スコアと不正度合い判定処理の判定結果をスコアＤＢ５５に記憶する処理であり、図５のステップＳ３０３，Ｓ３０７や図６のステップＳ３１０，Ｓ３１４の処理である。

ステップＳ４０１乃至Ｓ４０４が実行されることにより、操作履歴の通知処理を受信したことに応じたスコアの算出と不正度合いの判定とが行われ、その結果がスコアＤＢ５５に記憶される。

続いて、不正監視装置１はステップＳ４０５（図７）において、本人確認処理が必要か否かを判定する処理を実行する。
この処理では、例えば、直前のユーザ操作が「黒判定」とされた場合、即ち、第１の不正度合い判定処理において「黒判定」がなされた場合に、本人確認処理が必要と判定される。
また、それ以外にも、同種のユーザ操作（例えばログイン操作）のうち直近の所定数の不正判定スコアを累積したもの（累積不正判定スコア）が「黒判定」とされた場合、即ち、第２の不正判定度合い判定処理において「黒判定」がなされた場合に、本人確認処理が必要とされる。

本人確認処理を実行する必要なしと判定された場合、不正監視装置１はステップＳ４０６，Ｓ４０７の処理を実行せずにステップＳ４１０の処理へと遷移する。
一方、本人確認処理を実行する必要ありと判定された場合、不正監視装置１はステップＳ４０６の本人確認処理を実行する。

本人確認処理では、本人確認処理部１ｃで説明したように、本人しか知り得ないような質問を提示することなどを行い、本人確認を行う。本人確認のための処理は、ユーザ端末５と直接通信することによって実行してもよいし、ＥＣサーバ３を介して通信することによって実行してもよい。
そして、本人確認処理の結果をＥＣサーバ３へ通知する。
尚、本人確認処理の結果を受信したＥＣサーバ３は、例えば、ショッピングサイトにおけるそれ以降のユーザ操作を制限するなどの不正対策を行ってもよい。

本人確認処理を終えた不正監視装置１は、続くステップＳ４０７において、本人確認処理の結果、本人による操作と確認できたか否かを判定する処理を実行する。
本人による操作と確認できた場合、即ち「ＯＫ」判定の場合、不正監視装置１はステップＳ４０８において、正常ステータス更新処理を実行する。
これは、本人確認処理によって本人確認がなされた際の情報（キーボードやマウスにおけるユーザの操作態様やＩＰアドレスや端末情報などの環境情報や、閲覧している商品のジャンル情報などの嗜好情報など）に応じて、正常ステータスを更新する処理であり、以降では、この更新された正常ステータスに基づいてスコア算出処理が実行される。

尚、対象操作が「ユーザ情報変更操作」である場合には、本人によるユーザ情報変更操作であると確認できたことに応じて変更されたユーザ情報を正常ステータスとして更新する。従って、例えば、本人以外が商品の送付先住所の変更を行ったとしても、本人確認が取れない限り正常ステータスは更新されないため、以降において算出される不正判定スコアが高く不正度合いの高い数値となり、不正度合い判定処理において「黒判定」とされやすくなる。

正常ステータスを更新した後、不正監視装置１はステップＳ４０９において、スコア再算出処理を実行する。
この処理は、更新された正常ステータスに基づいて、これまでの項目別スコアや不正判定スコアを更新する処理である。

不正判定スコアを更新した不正監視装置１は、ステップＳ４０３及びＳ４０４の処理を実行する。
そして、ステップＳ４０５の判定処理では、既に本人確認処理を実行済みであるため、本人確認処理を実行する必要なしと判定されて、ステップＳ４１０の処理へと遷移する。

ステップＳ４１０では、不正監視装置１は、図７に示す一連の処理を実行する契機となった対象操作（換言すれば、図５のステップＳ２０５や図６のステップＳ２１１において追加通知の対象となった操作であり、項目別スコアの算出対象となった操作）の操作種別が「購入操作」であるか否かを判定する処理を実行する。

対象操作が「購入操作」でなかった場合、不正監視装置１はステップＳ４０１の処理を再び実行する。
一方、対象操作が「購入操作」であった場合、不正監視装置１はステップＳ４１１において、当該購入操作の判定結果（第１の判定結果または第２の判定結果）が「黒判定」であったか否かを判定する。

「黒判定」であった場合、不正監視装置１はステップＳ４１２において、決済方法変更処理を実行する。決済方法変更処理では、決済方法の変更（例えば、クレジットカードの利用を不可とし、現金振り込みに切り換える処理）を行い、決済方法が変更されたことをユーザに通知する。

ステップＳ４１２の処理を実行した後、或いは、ステップＳ４１０において対象操作が「購入操作」でないと判定した場合、或いは、ステップＳ４１１において対象操作（購入操作）が「黒判定」でないと判定した場合、不正監視装置１は再びステップＳ４０１の処理を実行する。

即ち、ユーザが行った「購入操作」に対して不正度合い判定処理をおこなった場合には、必要に応じて本人確認処理やスコア再算出処理などを実行した後、当該「購入操作」が「黒判定」であったか否かを確認し、「黒判定」であった場合には、決済方法が変更される。

［４−３．全体の流れの別の例］
全体の流れの別の例では、先の例に対して、認証処理を行った後の処理が相違する。
具体的に、図８を参照して説明する。
ユーザ端末５で実行するステップＳ１０１及びＳ１０２の各処理は、先の例と同様である。また、ＥＣサーバ３で実行するステップＳ２０１及びＳ２０２の各処理についても、先の例と同様である。

ステップＳ２０２の認証処理を実行した後、ＥＣサーバ３は認証結果の通知をすぐに行わずに、ステップＳ２０４の操作履歴記憶処理を行い、続けて、ステップＳ２０５の履歴追加通知処理を実行する。
これにより、ユーザに対して認証結果が通知される前に、不正監視装置１に対して履歴が追加されたことの通知が行われる。尚、図８では、ステップＳ２０２の認証処理（即ち、ユーザＩＤとログインパスワードの照合処理）が正常に認証された場合を示している。

追加通知を受信した不正監視装置１は、ステップＳ３０１乃至ステップＳ３０４の各処理を行う。これらの処理は、先の例と同様の処理であるため、詳述は略す。
尚、本人確認処理において、不正監視装置１は、確認結果をＥＣサーバ３へ通知する。

確認結果を通知されたＥＣサーバ３は、ステップＳ２０３において、認証結果通知処理を実行する。これにより、ユーザに対して認証結果が通知される。
尚、本人確認処理の確認結果がＯＫであった場合（即ち本人による操作であると確認がとれた場合）には、認証結果通知処理において、認証が正しく行われたことをユーザ端末５に通知する。また、本人確認処理自体が不要であった場合（例えば、不正判定スコアが「白判定」であった場合など）にも、認証が正しく行われたことをユーザ端末５に通知する。

一方、本人確認処理の確認結果がＮＧであった場合、いくつかの例が考えられる。
例えば、ステップＳ２０２の認証処理自体（即ち、ユーザＩＤとログインパスワードの照合処理自体）は正しく認証されたとしても、本人確認が取れなかった場合、ユーザのログインは許可するが、その後のユーザ操作に制限を掛けることが考えられる。
また、認証処理が正しく認証されたとしても、ユーザのログイン自体を不許可にすることが考えられる。即ち、本人確認が正常に行われるまで、ログインを不許可とする。

本人確認処理を実行した不正監視装置１は、続くステップＳ３０５乃至Ｓ３０７の各処理を実行する。これらの処理は、先の例と同様の処理となるため、詳述を略す。

［４−４．要注意ユーザ通知処理］
要注意ユーザ通知処理は、不正監視装置１の通知部１ｅによって実行される処理であり、例えば、２４時間に一度など定期的にバッチ処理等によって実行される。
バッチ処理の例について、図９を参照して説明する。

先ず、不正監視装置１はステップＳ５０１において、とある一人のユーザ（例えばユーザＡ）についての第１の判定結果及び第２の判定結果をスコアＤＢ５５から取得する。
尚、ここでは、前回のバッチ処理によって取得した判定結果の後に更に追加された追加分の判定結果のみを取得する。

続いて、不正監視装置１はステップＳ５０２において、取得した第１及び第２の判定結果が「灰判定」であるか否かを確認する処理を行う。
確認した結果、「灰判定」であることが確認された場合、不正監視装置１はステップＳ５０３において、当該ユーザを通知ユーザとして選択する処理を実行する。

一方、ステップＳ５０２において各判定結果が「灰判定」ではないと確認した場合、または、ステップＳ５０３を実行した後、不正監視装置１はステップＳ５０４において、全てのユーザについてステップＳ５０１乃至Ｓ５０３の各処理を実行したか否かを判定する。
全てのユーザについて実行していない場合、不正監視装置１は再びステップＳ５０１の処理を行い、次のユーザ（例えばユーザＢ）の判定結果を取得する。

全てのユーザについて、ステップＳ５０１乃至Ｓ５０３の各処理を実行した場合、不正監視装置１は続くステップＳ５０５において、通知ユーザとして選択した各ユーザの識別情報（例えばユーザＩＤ）を管理者（不正検知を行う者）に通知する処理を実行する。
尚、通知処理の際、ユーザの識別情報だけでなく、「灰判定」がなされる元となった情報として、判定項目ごとの項目別スコアを管理者に通知してもよい。

［４−５．スコア算出処理の他の例］
上述した図７のステップＳ４０２のスコア算出処理や、ステップＳ４０９のスコア再算出処理では、不正判定スコア（一つのユーザ操作に対応して算出されるスコア）は、対象操作に関する判定項目のみに基づいて算出する例を説明した。
スコア算出処理の他の例では、対象操作に対応した不正判定スコアを算出する際に、対象操作だけでなく関連した操作も加味して算出する例を説明する。

図１０を参照して、一例を説明する。
先ず、不正監視装置１はステップＳ６０１において、対象操作の前の所定時間内に、同一ユーザによる他の操作が行われているかどうかを判定する処理を実行する。
例えば、対象操作が「購入操作」であり、所定時間が１０分とされているときに、当該購入操作前の１０分間に他の操作（例えば、「ログイン操作」や「ユーザ情報変更操作」や「商品閲覧操作」など）が実行されているかどうかを判定する。

所定時間内に他の操作が行われていると判定した場合、不正監視装置１はステップＳ６０２において、当該他の操作を加味して対象操作の項目別スコアや不正判定スコアや累積不正判定スコアを算出する。
例えば、対象操作としての「購入操作」のみから算出した不正判定スコアは低かったとする。しかし、「購入操作」の５分前に不正判定スコアの高い「ユーザ情報変更操作」が行われていた場合、関連操作としての「ユーザ情報変更操作」の高い不正判定スコアを加味して、対象操作としての「購入操作」に対する不正判定スコアも高く算出される。
高く算出するためには、一定の係数（例えば１．２のような数値）を乗算して算出してもよいし、関連操作の不正判定スコアの高さに応じた数値を係数として乗算して算出してもよい。

ステップＳ６０１において、所定時間内に他操作が無いと判定した場合、不正監視装置１はステップＳ６０３において、対象操作のみから項目別スコアや不正判定スコアや累積不正判定スコアを算出する処理を実行する。

尚、所定の時間内に他の操作が行われたか否かに応じて各スコアの算出方法（或いは算出式）を変更する例を説明したが、特定の操作が行われたか否かに応じて変更してもよい。
例えば、対象操作が「購入操作」である場合に、配達先を変更する「ユーザ情報変更操作」が所定時間内に行われた場合に、各スコアを高めに算出してもよい。
また、クレジットカードの有効期限に余裕があるにもかかわらず、クレジットカード情報を変更する「ユーザ情報変更操作」が所定時間内に行われた場合に同様の処理を行ってもよい。

［４−６．スコア算出処理の更に他の例］
スコア算出処理の更に他の例では、所定時間内に行われた他の操作の中に「ユーザ情報変更操作」が含まれているか否かを加味する例について、図１１を参照して説明する。

先ず、不正監視装置１はステップＳ７０１において、対象操作の前の所定時間内に、同一ユーザによる他の操作が行われているかどうかを判定する処理を実行する。この処理は、図１０のステップＳ６０１の処理と同様である。

所定時間内に他の操作が行われたと判定した場合、不正監視装置１はステップＳ７０２において、当該他の操作の中に「ユーザ情報変更操作」が含まれているか否かを判定する処理を実行する。
他の操作の中に「ユーザ情報変更操作」が含まれている場合、不正監視装置１はステップＳ７０３において、前述したよりも更に高めの数値となるように各スコアを算出する。

一方、他の操作は実行されたが、その中に「ユーザ情報変更操作」が含まれていなかった場合、不正監視装置１はステップＳ７０４において、高めの数値（但し、ステップＳ７０３よりは低めの数値）となるように各スコアを算出する。

また、ステップＳ７０１において所定時間内に他の操作が行われていないと判定した場合、不正監視装置１はステップＳ７０５において、対象操作のみから各スコアを算出する処理を実行する。この処理は、図１０のステップＳ６０３と同様の処理である。

［４−７．不正度合い判定処理の他の例］
スコア算出処理の更に他の例では、他の操作の中に「ユーザ情報変更操作」が含まれているか否かに基づいて各スコアを算出する例を説明した。
しかし、算出する各スコア（即ち数値自体）は変えずに、不正度合い判定処理に用いる閾値（第１の判定閾値や第２の判定閾値）を変えてもよい。
ここでは、他の操作の中に「ユーザ情報変更操作」が含まれているか否かに基づいて不正度合いを判定する例について、図１２を参照して説明する。

先ず、不正監視装置１はステップＳ８０１において、対象操作の前の所定時間内に、同一ユーザによる他の操作が行われているかどうかを判定する処理を実行する。この処理は、図１０のステップＳ６０１及び図１１のステップＳ７０１の処理と同様である。

所定時間内に他の操作が行われたと判定した場合、不正監視装置１はステップＳ８０２において、当該他の操作の中に「ユーザ情報変更操作」が含まれているか否かを判定する処理を実行する。
他の操作の中に「ユーザ情報変更操作」が含まれている場合、不正監視装置１はステップＳ８０３において、閾値をより低めに設定（後述するステップＳ８０４よりも低めに設定）する処理を実行する。
このとき設定し直す閾値は、第１の判定閾値の二つの閾値と第２の判定閾値の二つの閾値、計四つの閾値のうち、何れか一つの閾値であってもよいし、複数の閾値であってもよいし、全ての閾値であってもよい。

一方、他の操作は実行されたが、その中に「ユーザ情報変更操作」が含まれていなかった場合、不正監視装置１はステップＳ８０４において、低めの閾値を設定（但し、ステップＳ８０３よりは高めの閾値を設定）する処理を実行する。
また、ステップＳ８０１において、所定時間内に他の操作が行われていないと判定した場合、不正監視装置１はステップＳ８０５において、通常の閾値を設定する処理を実行する。
尚、通常の閾値が初めから設定されている場合には、ステップＳ８０５を実行しなくてもよい。

続けて、不正監視装置１はステップＳ８０６において、それぞれの条件に基づいて設定された閾値に基づいて不正度合いを判定する処理を実行する。

＜５．変形例＞

尚、図５に示すフローチャートでは、「検索操作」に対するスコア算出処理や記憶処理、本人確認処理は実行しない例を説明したが、「検索操作」を対象操作としてもよい。
その場合には、例えば、「検索操作」について設定された判定項目に基づいたスコア算出や判定処理が実行される。
他にも、「商品閲覧操作」や商品をお気に入りに登録する「お気に入り登録操作」などが対象操作とされてもよい。

＜６．まとめ＞

これまで述べてきたように、不正監視装置１は、ユーザの操作ごとに操作種別に応じた判定項目（例えばＫ１〜Ｋ８）に基づいて不正判定スコアを算出するスコア算出部１ａと、ユーザの操作に応じて該操作と同種の操作種別の不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定部１ｂと、不正度合いについて不正の可能性が高いと判定された（即ち、「黒判定」された）操作を行ったユーザに対して操作時に本人確認処理を行う本人確認処理部１ｃと、商品購入時（即ち「購入操作」時）に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理部１ｄと、を備えている。
即ち、ユーザの操作ごとに、当該操作の情報（入力情報や環境情報など）だけでなくそれまでの操作時の情報（入力情報や環境情報など）に応じて、不正度合いが判定される。
従って、それまでのユーザの操作に応じた総合的な不正検知を行うことができる。
また、異なるユーザが同じ操作を行ったとしても、それまでのユーザの操作ごとの不正判定スコアの履歴が異なり、不正度合いの判定結果も異なるため、ユーザごとの適切な不正検知を行うことができる。
更に、商品購入時に決済方法変更処理を行うことにより、金銭的被害を防止することを可能とする。
そして、適切に不正検知を行うことにより、その後に不正操作を受け付けた際の情報処理装置の処理負担を軽減或いは削減することができる。
また、操作種別（前述した「ログイン操作」や「ユーザ情報変更操作」や「購入操作」など）ごとに積算された累積不正判定スコアに基づいて、操作種別ごとの判定結果を算出することにより、操作種別に対する不正度合いの判定を正しく行うことができる。例えば、「ログイン操作」の不正判定スコアが高くなりがちなユーザに対して、操作種別を区別せず直近の不正判定スコアに基づく累積不正判定スコアを算出した場合、「ログイン操作」の不正判定スコアによって累積不正判定スコアが高くなってしまい、他の操作種別（「ユーザ情報変更操作」や「購入操作」）に対する不正度合いを正しく把握することができない。従って、ユーザの状況に応じて問題のある操作種別を特定して不正対策を行う場合などに、当該ユーザに対する対策が適切に行われない虞がある。上記した構成であれば、操作種別ごとの不正度合いを正しく判定することができるため、適切な不正対策を行うことも可能となる。

また、項目別スコアについての説明や図７のステップＳ４０９の説明にあったように、スコア算出部１ａは、本人確認処理の結果不正の可能性が低いと判定された操作を行ったユーザに対して、既に算出済みの不正判定スコアを算出し直すスコア再算出処理を実行する。
これにより、正しく算出されていなかった不正判定スコアが訂正され、正しいスコアが算出される。
従って、ユーザの不正度合いを正しく判定することができる。
例えば、東京からアクセスしていたユーザのユーザＩＤを用いて大阪からアクセスがあった場合、不正判定スコアはそれまでよりも高めに算出される。しかし、大阪からのアクセスも本人と確認された時点で、再度、算出済みの不正判定スコアの再算出が行われるため、不正判定スコアが通常通りの値へと更改され、更に、蓄積された累積不正判定スコアも正常となる。

更に、項目別スコアについての説明にあったように、スコア算出部１ａは、最新のユーザ情報に基づいたユーザごとに管理された正常ステータスに基づいて不正判定スコアを算出する。このとき、正常ステータスは、ユーザについての初期登録情報とされ、本人が行ったと推定されるユーザ情報変更操作の後は該ユーザ情報変更操作時の登録情報とされる。
これにより、ユーザの最新の登録情報（ユーザの属性情報や環境情報）に応じて、不正判定スコアが算出される。
従って、適切に不正度合いを判定することができる。

更にまた、項目別スコアについての説明にあったように、スコア算出部１ａは、判定項目ごとに設定されたユーザごとの重み付けに基づいて不正判定スコアを算出してもよい。
これにより、ユーザの状況に応じて不正判定スコアが算出される。
従って、ユーザの状況を反映して適切に不正度合いを判定することができる。

加えて、判定部１ｂは、不正判定スコアの算出回数に応じて変更されるユーザごとの判定閾値に基づいて前記判定を行う。
これにより、ユーザの操作頻度に応じて不正判定スコアが算出される。
従って、ユーザごとに適切な不正度合いを判定することができる。

また、図９のバッチ処理の例において説明したように、不正度合いは高不正判定（即ち「黒判定」）、中不正判定（即ち「灰判定」）、低不正判定（即ち「白判定」）の少なくとも３段階とされ、中不正判定とされたユーザの識別情報を管理者に通知する通知部１ｅを更に備える。
これにより、例えば、不正操作か否か判定が難しいときに管理者が手動でユーザの操作に係る情報を確認する場合などに、管理者に対して選択された一部のユーザ情報が通知される。
従って、管理者に通知する情報量を少なくすることができると共に、管理者の確認作業に要する負担を軽減することができる。
換言すれば、第１の不正度合い判定処理や第２の不正度合い判定処理において、「黒判定」とされたユーザは、不正度合いの可能性が極めて高いため、不正監視装置１によって自動的に対処することが、人員コストの削減の観点からも望ましい。
ところが、各不正度合い判定処理において「灰判定」とされたユーザは、不正度合いの可能性が高めのユーザではあるが、本来の正規ユーザによる操作に基づいている可能性もある。このようなユーザに対して、一律自動的に不正監視装置１によってアクセス制限を掛けたりユーザの操作に制限を掛けたりすることは、必ずしも適切とは限らない。
そこで、そのようなユーザに対しては、不正対策を行う管理者によって適宜判断することが望ましいと考えられる。
一方、「灰判定」とされたユーザ以外のユーザも含めた全てのユーザに対して管理者の目によって不正操作がなされたか否かを判定することは、人員コストが増大しすぎてしまうため、好ましくない。
本構成によれば、「灰判定」とされたユーザのみ管理者の手動による不正検知・不正対策がなされるため、人員コストの増加を抑制しつつ、適切な不正検出・不正対策を行うことが可能となる。

更に、図９のバッチ処理の例において説明したように、通知部１ｅは、判定項目ごとの処理結果をユーザの識別情報と共に通知する。
これにより、例えば、不正操作か否か判定が難しいときに管理者が手動でユーザの操作に係る情報を確認する場合などに、判定項目が不正判定スコアの算出に与えた影響が管理者に通知される。
従って、管理者の確認作業に要する負担を更に軽減することができる。
換言すれば、本構成により、「灰判定」とされたユーザを特定する情報（例えばユーザＩＤ）と共に、判定項目ごとの項目別スコアが管理者に通知される。
これにより、例えば、不正操作か否か判定が難しいときに管理者が手動でユーザの操作に係る情報を確認する場合などに、判定項目が不正判定スコアの算出に与えた影響が容易に把握できる。
従って、管理者の不正検知や不正対策の作業に要する負担を軽減することができる。

更にまた、項目別スコアについての説明や、スコア算出処理の他の例での説明や、図１０の説明にあったように、スコア算出部１ａは、関連する不正判定スコアに基づいて不正判定スコアを算出する。
これにより、他の操作種別の不正判定スコアに応じて不正判定スコアが算出される。例えば、ログイン操作の直後にユーザ情報変更操作を行った場合には、ユーザ情報変更操作の直前のログイン操作は関連する操作と判定し、当該ログイン操作の不正判定スコアに基づいて直後のユーザ情報変更操作の不正判定スコアが算出される。
従って、複合的に各操作の不正判定スコアが算出されるため、適切な不正度合いの判定処理を行うことができる。

加えて、不正度合い判定処理の他の例や図１２で説明したように、判定部１ｂは、ユーザ情報変更操作後の所定の期間において、通常時よりも不正度合いが高く判定されやすいように判定閾値を変更して前記判定を行う。
これにより、例えば、届け先の住所を変更する操作などの後には、通常よりも厳しい（即ち高不正判定となりやすい）不正度合い判定処理が実行される。
特に、実際に金銭的な被害の出る可能性がある購買操作において、ユーザ情報変更操作後の所定の期間である場合には判定閾値を高めに設定することにより、不正操作による被害を未然に防ぐ可能性を高めることができる。

＜７．プログラム＞

各実施の形態におけるプログラムは、不正監視装置１が備える演算処理装置（ＣＰＵなど）に実行させるプログラムである。

このプログラムは、ユーザの操作ごとに操作種別に応じた判定項目に基づいて不正判定スコアを算出するスコア算出機能を演算処理装置に実行させる。
また、ユーザの操作に応じて該操作と同種の操作種別の前記不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定機能を演算処理装置に実行させる。
更に、前記不正度合いについて不正の可能性が高いと判定された操作を行ったユーザに対して前記操作時に本人確認処理を行う本人確認処理機能を演算処理装置に実行させる。
そして、商品購入時に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理機能を演算処理装置に実行させる。
即ちこのプログラムは、演算処理装置に対して、図５のステップＳ３０１乃至Ｓ３０７の各処理、図６のステップＳ３０８乃至Ｓ３１５の各処理、図７の各処理、図８のステップＳ３０１乃至Ｓ３０７の各処理、図９乃至図１２の各処理を実行させるプログラムである。

このようなプログラムにより、上述した不正監視装置１を実現できる。
そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭなどに予め記憶しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的或いは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

１ 不正監視装置、１ａ スコア算出部、１ｂ 判定部、１ｃ 本人確認処理部、１ｄ 決済方法変更処理部、１ｅ 通知部、２ 通信ネットワーク、３ ＥＣサーバ、４ カード会社サーバ、５ ユーザ端末、６ 店舗端末、７ ＥＣサイト運営システム、８ カード会社システム、５０ ユーザＤＢ、５１ 店舗ＤＢ、５２ 履歴ＤＢ、５３ 商品ＤＢ、５４ ウェブページＤＢ、５５ スコアＤＢ、５６ カードＤＢ、５７ カード利用履歴ＤＢ

Claims (12)

1. ユーザの操作ごとに操作種別に応じた判定項目に基づいて不正判定スコアを算出するスコア算出部と、
   ユーザの操作に応じて該操作と同種の操作種別の前記不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定部と、
   前記不正度合いについて不正の可能性が高いと判定された操作を行ったユーザに対して前記操作時に本人確認処理を行う本人確認処理部と、
   商品購入時に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理部と、を備えた
   情報処理装置。
2. 前記スコア算出部は、前記本人確認処理の結果不正の可能性が低いと判定された操作を行ったユーザに対して、既に算出済みの前記不正判定スコアを算出し直すスコア再算出処理を実行する
   請求項１に記載の情報処理装置。
3. 前記スコア算出部は、最新のユーザ情報に基づいたユーザごとに管理された正常ステータスに基づいて前記不正判定スコアを算出し、
   前記正常ステータスは、ユーザについての初期登録情報とされ、本人が行ったと推定されるユーザ情報変更操作の後は該ユーザ情報変更操作時の登録情報とされる
   請求項１に記載の情報処理装置。
4. 前記スコア算出部は、前記判定項目ごとに設定されたユーザごとの重み付けに基づいて前記不正判定スコアを算出する
   請求項１に記載の情報処理装置。
5. 前記判定部は、前記不正判定スコアの算出回数に応じて変更されるユーザごとの判定閾値に基づいて前記判定を行う
   請求項１に記載の情報処理装置。
6. 前記不正度合いは高不正判定、中不正判定、低不正判定の少なくとも３段階とされ、前記中不正判定とされたユーザの識別情報を管理者に通知する通知部を更に備えた
   請求項１に記載の情報処理装置。
7. 前記通知部は、前記判定項目ごとの処理結果を前記ユーザの識別情報と共に通知する
   請求項６に記載の情報処理装置。
8. 前記スコア算出部は、関連する前記不正判定スコアに基づいて前記不正判定スコアを算出する
   請求項１に記載の情報処理装置。
9. 前記判定部は、ユーザ情報変更操作後の所定の期間において、通常時よりも前記不正度合いが高く判定されやすいように判定閾値を変更して前記判定を行う
   請求項１に記載の情報処理装置。
10. ユーザの操作ごとに操作種別に応じた判定項目に基づいて不正判定スコアを算出するスコア算出ステップと、
    ユーザの操作に応じて該操作と同種の操作種別の前記不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定ステップと、
    前記不正度合いについて不正の可能性が高いと判定された操作を行ったユーザに対して前記操作時に本人確認処理を行う本人確認処理ステップと、
    商品購入時に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理ステップとを、
    情報処理装置が実行する情報処理方法。
11. ユーザの操作ごとに操作種別に応じた判定項目に基づいて不正判定スコアを算出するスコア算出機能と、
    ユーザの操作に応じて該操作と同種の操作種別の前記不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定機能と、
    前記不正度合いについて不正の可能性が高いと判定された操作を行ったユーザに対して前記操作時に本人確認処理を行う本人確認処理機能と、
    商品購入時に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理機能とを、
    情報処理装置に実現させるプログラム。
12. ユーザの操作ごとに操作種別に応じた判定項目に基づいて不正判定スコアを算出するスコア算出機能と、
    ユーザの操作に応じて該操作と同種の操作種別の前記不正判定スコアの履歴に基づき該操作の不正度合いを判定する判定機能と、
    前記不正度合いについて不正の可能性が高いと判定された操作を行ったユーザに対して前記操作時に本人確認処理を行う本人確認処理機能と、
    商品購入時に不正の可能性が高いと判定されたユーザに対して決済方法変更処理を行う決済方法変更処理機能とを、
    情報処理装置に実現させるプログラムを記憶した記憶媒体。

Images