ホーム > 特許ランキング > ＬＩＮＥヤフー株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-02
(45)【発行日】2024-08-13
(54)【発明の名称】不正判定装置、不正判定方法、及び不正判定プログラム
(51)【国際特許分類】
G06Q 20/40 20120101AFI20240805BHJP
【ＦＩ】
G06Q20/40 320
【請求項の数】
6
(21)【出願番号】P 2022031897
(22)【出願日】2022-03-02
(65)【公開番号】P2023127917
(43)【公開日】2023-09-14
【審査請求日】2022-06-17
(73)【特許権者】
【識別番号】500257300
【氏名又は名称】ＬＩＮＥヤフー株式会社
(74)【代理人】
【識別番号】110000637
【氏名又は名称】弁理士法人樹之下知的財産事務所
(72)【発明者】
【氏名】塚原 剛
(72)【発明者】
【氏名】平山 孔亮
【審査官】田上 隆一
(56)【参考文献】
【文献】特開２０１３－１５６７７１（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
ユーザの所定のサービスの利用に係るユーザ情報を取得するユーザ情報取得部と、サービスの不正利用に係るルールを記録したルール情報を取得するルール取得部と、
前記ユーザ情報、及び前記ルール情報に基づいて、前記ユーザによるターゲットサービスの前記不正利用を判定する不正判定部と、
前記ターゲットサービスの前記ユーザ情報であるターゲットユーザ情報を記録するユーザＤＢと、を備え、
前記ユーザＤＢにおいて、前記ターゲットユーザ情報は、前記ターゲットサービスとは異なる他の前記サービスのユーザ情報である関連ユーザ情報に紐付けられており、
前記ルール情報は、前記ターゲットユーザ情報に対する前記ルールである第一ルール情報と、前記関連ユーザ情報に対する前記ルールである第二ルール情報とを含み、
前記ユーザ情報取得部は、前記ターゲットユーザ情報と、前記ターゲットユーザ情報に紐づく前記関連ユーザ情報とを取得し、
前記不正判定部は、前記ターゲットユーザ情報と前記第一ルール情報とに基づいて前記不正利用の判定処理を実施し、さらに、前記ターゲットユーザ情報と紐づけられた前記関連ユーザ情報と前記第二ルール情報とに基づいて前記不正利用の判定処理を実施する、不正判定装置。
【請求項2】
サービスの提供を要求する提供要求を受信する提供要求受信部を備え、前記ルール取得部は、所定期間内に受信した前記提供要求の受信数が閾値以上である場合に、前記第一ルール情報のみを取得し、前記閾値未満である場合に、前記第一ルール情報及び前記第二ルール情報を取得する、
請求項１に記載の不正判定装置。
【請求項3】
前記ルール取得部は、予め設定された前記ターゲットサービスのキャンペーン期間であるか否かを判定し、前記キャンペーン期間である場合に、前記第一ルール情報のみを取得し、前記キャンペーン期間ではない場合に、前記第一ルール情報及び前記第二ルール情報を取得する、請求項１に記載の不正判定装置。
【請求項4】
新規の前記ルール情報をテストルール情報として設定するルール設定部と、前記不正判定部による前記テストルール情報を用いた前記不正利用の判定処理を実施した際の判定結果を判定審査部に送信する審査要求部と、
を備える請求項１から請求項３のいずれか１項に記載の不正判定装置。
【請求項5】
コンピュータにより、サービスの不正利用を判定する不正判定方法であって、前記コンピュータは、ユーザＤＢ、ユーザ情報取得部、ルール取得部、不正判定部を備え、
前記ユーザＤＢは、ユーザのターゲットサービスの利用に係るターゲットユーザ情報を記録し、前記ターゲットユーザ情報は、前記ターゲットサービスとは異なる他の前記サービスのユーザ情報である関連ユーザ情報に紐付けられており、
前記ユーザ情報取得部が、ユーザの所定のサービスの利用に係るユーザ情報を取得するユーザ情報取得ステップと、
前記ルール取得部が、サービスの不正利用に係るルールを記録したルール情報を取得するルール取得ステップと、
前記不正判定部が、前記ユーザ情報、及び前記ルール情報に基づいて、前記ユーザによる前記ターゲットサービスの前記不正利用を判定する不正判定ステップと、を実施し、
前記ルール情報は、前記ターゲットユーザ情報に対する前記ルールである第一ルール情報と、前記関連ユーザ情報に対する前記ルールである第二ルール情報とを含み、
前記ユーザ情報取得ステップは、前記ターゲットユーザ情報と、前記ターゲットユーザ情報に紐づく前記関連ユーザ情報とを取得し、
前記不正判定ステップは、前記ターゲットユーザ情報と前記第一ルール情報とに基づいて前記不正利用の判定処理を実施し、さらに、前記ターゲットユーザ情報と紐づけられた前記関連ユーザ情報と前記第二ルール情報とに基づいて前記不正利用の判定処理を実施する、不正判定方法。
【請求項6】
コンピュータにより読み取り実行可能な不正判定プログラムであって、前記コンピュータを請求項１から請求項４のいずれか１項に記載の不正判定装置として機能させる、不正判定プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サービスの不正利用を判定する不正判定装置、不正判定方法、及び不正判定プログラムに関する。
【背景技術】
【0002】
従来、インターネット上のサービスの利用に関し、不正な情報を入力して当該サービスを受けようとする不正行為を判定する不正判定装置が知られている（例えば、特許文献１参照）。
特許文献１は、クレジットカードの不正利用を判定するシステムに関するものである。このシステムでは、店舗端末から送信された不正判定依頼にかかるオーソリデータを受信し、履歴情報を付加して記憶部に格納する。この際、オーソリデータに含まれる基本的な因子である利用日、利用時間、商品コード及び金額に加え、当日利用回数、前回利用商品コード、前回利用時間との差、及び前回利用金額との差が履歴情報として付加される。そして、所定のロジック（ルール）に基づいて、オーソリデータ及び履歴情報から不正に係るスコアを算出する。
特許文献１は、クレジットカードの不正利用を判定するシステムに関するものである。このシステムでは、店舗端末から送信された不正判定依頼にかかるオーソリデータを受信し、履歴情報を付加して記憶部に格納する。この際、オーソリデータに含まれる基本的な因子である利用日、利用時間、商品コード及び金額に加え、当日利用回数、前回利用商品コード、前回利用時間との差、及び前回利用金額との差が履歴情報として付加される。そして、所定のロジック（ルール）に基づいて、オーソリデータ及び履歴情報から不正に係るスコアを算出する。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２００４－３４８５３６号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上記特許文献１に記載のような従来の不正判定処理では、利用目的に対応する１サービスのデータに基づいて不正を判定する。例えば、特許文献１では、クレジットカードサービスに係るオーソリデータ及びその履歴情報に基づいて、不正を判定している。しかしながら、１種のサービスのユーザデータのみに基づいた不正判定であるため、不正判定の精度は決して高くない。つまり、オーソリデータは、クレジットカードの利用日、利用時間、商品コード、及び金額を含むデータであり、履歴情報は、当該オーソリデータの蓄積結果によって得られたものである。したがって、クレジットカードサービスの利用履歴のみに基づいた不正判定となり、判定精度には限度がある。
【0005】
本発明は、より精度の高い不正判定を実施可能な不正判定装置、不正判定方法、及び不正判定プログラムを提供することを目的とする。
【課題を解決するための手段】
【0006】
本発明の不正判定装置は、ユーザの所定のサービスの利用に係るユーザ情報を取得するユーザ情報取得部と、ターゲットサービスの不正利用に係るルールを記録したルール情報を取得するルール取得部と、前記ユーザ情報、及び前記ルール情報に基づいて、前記ユーザによる前記ターゲットサービスの前記不正利用を判定する不正判定部と、を備え、前記ルール情報は、前記ターゲットサービスの前記ユーザ情報であるターゲットユーザ情報に対する前記ルールと、前記ターゲットサービスとは異なる他の前記サービスの前記ユーザ情報である関連ユーザ情報に対する前記ルールとを含み、前記ユーザ情報取得部は、前記ターゲットユーザ情報と、前記ターゲットユーザ情報に紐づく前記関連ユーザ情報とを取得し、前記不正判定部は、前記ターゲットユーザ情報と、複数の前記サービスの前記関連ユーザ情報と、前記ルール情報とに基づいて前記不正利用の判定処理を実施する。
【発明の効果】
【0007】
本発明では、ターゲットユーザ情報に対するルールの他、ターゲットサービスとは異なる他のサービスのユーザ情報である関連ユーザに対するルールを用いて、ターゲットサービスにおける不正利用を判定する。これにより、単一のサービスのユーザ情報のみに基づいて不正利用の判定をする場合に比べて、より精度の高い不正判定を実施することができる。
【図面の簡単な説明】
【0008】
【発明を実施するための形態】
【0009】
以下、本発明の一実施形態について説明する。
図１は、本実施形態の不正判定システムの一例を示す概略図である。
不正判定システム１は、図１に示すように、複数のサービスサーバ１０と、ユーザ端末２０とを備え、これらのサービスサーバ１０、及びユーザ端末２０がインターネットを介して通信可能に接続されている。また、サービスサーバ１０は、不正判定処理のルールを管理するルール管理者が操作するルール管理端末３０や、不正判定結果を審査する審査者が操作する審査端末４０等と通信可能に接続されている。図１に示す図では、ルール管理端末３０及び審査端末４０がインターネットを介してサービスサーバ１０に接続される構成を例示するが、例えば社内ネットワーク等の専用線を介してサービスサーバ１０に接続される構成としてもよい。
図１は、本実施形態の不正判定システムの一例を示す概略図である。
不正判定システム１は、図１に示すように、複数のサービスサーバ１０と、ユーザ端末２０とを備え、これらのサービスサーバ１０、及びユーザ端末２０がインターネットを介して通信可能に接続されている。また、サービスサーバ１０は、不正判定処理のルールを管理するルール管理者が操作するルール管理端末３０や、不正判定結果を審査する審査者が操作する審査端末４０等と通信可能に接続されている。図１に示す図では、ルール管理端末３０及び審査端末４０がインターネットを介してサービスサーバ１０に接続される構成を例示するが、例えば社内ネットワーク等の専用線を介してサービスサーバ１０に接続される構成としてもよい。
【0010】
本実施形態の不正判定システム１では、個々のユーザ端末２０がサービスサーバ１０からサービスの提供を受ける際に、ユーザ端末２０が当該サービスサーバ１０にサービスの提供を要求する提供要求を送信する。そして、サービスサーバ１０は、ルール管理者によって設定されたルール情報に基づいて、不正判定を実施し、不正がない場合にユーザ端末２０に不正がない旨の判定結果が送信され、サービスサーバ１０からユーザ端末２０にサービスが提供される。一方、サービスサーバ１０による不正判定処理により、不正があると判定された場合に、ユーザ端末２０にその旨が通知され、サービスサーバ１０からユーザ端末２０へのサービス提供が行われない。
以下、このような不正判定システム１の各構成について詳細に説明する。
以下、このような不正判定システム１の各構成について詳細に説明する。
【0011】
［サービスサーバ１０の構成］
サービスサーバ１０は、本開示の不正判定装置として機能する。このサービスサーバ１０は、コンピュータにより構成され、通信部１１と、記憶部１２と、制御部１３と、等を含んで構成されている。なお、サービスサーバ１０を構成するコンピュータの数は特に限定されない。例えば、１台のコンピュータによってサービスサーバ１０が構成されてもよく、複数のコンピュータをネットワークで接続して構築されるクラウドサーバによりサービスサーバ１０が構成されてもよい。
通信部１１は、例えばＬＡＮ等を介してネットワーク（インターネット）に接続されており、ユーザ端末２０、ルール管理端末３０、及び審査端末４０等と通信する。
サービスサーバ１０は、本開示の不正判定装置として機能する。このサービスサーバ１０は、コンピュータにより構成され、通信部１１と、記憶部１２と、制御部１３と、等を含んで構成されている。なお、サービスサーバ１０を構成するコンピュータの数は特に限定されない。例えば、１台のコンピュータによってサービスサーバ１０が構成されてもよく、複数のコンピュータをネットワークで接続して構築されるクラウドサーバによりサービスサーバ１０が構成されてもよい。
通信部１１は、例えばＬＡＮ等を介してネットワーク（インターネット）に接続されており、ユーザ端末２０、ルール管理端末３０、及び審査端末４０等と通信する。
【0012】
記憶部１２は、例えばメモリ、ハードディスク等により構成されたデータ記録装置である。この記憶部１２は、サービスを利用するユーザの不正利用を判定するためのルール情報が記録されたルールデータベース（ルールＤＢ１２１）、ユーザデータベース（ユーザＤＢ１２２）、ブロックリスト（ＢＬ１２３）、判定ログデータベース（判定ログＤＢ１２４）を備える。
なお、ここでは、サービスサーバ１０の記憶部１２に、ルールＤＢ１２１、ユーザＤＢ１２２、ＢＬ１２３、及び判定ログＤＢ１２４が設けられる例を示すが、サービスサーバ１０とネットワークを介して通信可能に接続された他のデータサーバやクラウドストレージに、これらのデータが記録される構成としてもよい。
また、記憶部１２には、サービスサーバ１０により不正判定処理を実施するための不正判定プログラム等の各種プログラムが記憶されている。
なお、ここでは、サービスサーバ１０の記憶部１２に、ルールＤＢ１２１、ユーザＤＢ１２２、ＢＬ１２３、及び判定ログＤＢ１２４が設けられる例を示すが、サービスサーバ１０とネットワークを介して通信可能に接続された他のデータサーバやクラウドストレージに、これらのデータが記録される構成としてもよい。
また、記憶部１２には、サービスサーバ１０により不正判定処理を実施するための不正判定プログラム等の各種プログラムが記憶されている。
【0013】
ルールＤＢ１２１は、各サービスの不正判定を実施するための複数のルール情報を記憶する。
このルール情報には、ルールＩＤ、ルール名、アクションコード、ＢＬ登録フラグ、テストモードフラグ、更新日時、負荷利用フラグ等の情報が記録されている。
ルールＩＤは、ルール情報を識別するための識別情報である。
ルール名は、ルール情報の名称であり、ルール管理者によって適宜設定される。
このルール情報には、ルールＩＤ、ルール名、アクションコード、ＢＬ登録フラグ、テストモードフラグ、更新日時、負荷利用フラグ等の情報が記録されている。
ルールＩＤは、ルール情報を識別するための識別情報である。
ルール名は、ルール情報の名称であり、ルール管理者によって適宜設定される。
【0014】
アクションコードは、ルールの詳細であり、サービスサーバ１０のサービス利用に係るユーザ情報や他のサービスサーバ１０のサービス利用に係るユーザ情報に対し、不正を判定するための条件（ルール）が記録される。１つのルール情報のアクションコードには、複数のルールが記録されていてもよい。例えば、サービスサーバ１０（自身）が提供するサービス（ターゲットサービス）の利用に係るユーザ情報（ターゲットユーザ情報）に対する１つまたは複数のルールと、他のサービスサーバ１０が提供するサービスの利用に係るユーザ情報（関連ユーザ情報）に対する１つまたは複数のルールとが記録されていてもよい。また、ターゲットユーザ情報のみに対する１つまたは複数のルールが記録されていてもよく、関連ユーザ情報のみに対する１つ又は複数のルールが記録されていてもよい。
ここで、ターゲットユーザ情報のみに対する１つまたは複数のルールが記録されているルール情報を第一ルール情報とし、関連ユーザ情報に対する１つまたは複数のルールが含まれているルール情報を第二ルール情報とする。
ここで、ターゲットユーザ情報のみに対する１つまたは複数のルールが記録されているルール情報を第一ルール情報とし、関連ユーザ情報に対する１つまたは複数のルールが含まれているルール情報を第二ルール情報とする。
【0015】
ＢＬ登録フラグは、アクションコードに記録されたルールに基づいて不正と判定されたユーザをＢＬ１２３に登録するか否かを示すフラグ情報である。
【0016】
テストモードフラグは、当該ルール情報がテストモードに設定されているか否か、つまり、本発明のテストルール情報であるか否かを示す情報である。本実施形態では、ルール管理者がルール管理端末３０を操作することで、各ルール情報が設定（作成）されるが、新規に設定されたルール情報は、テストモードフラグがＯＮとなり、テストルール情報として登録される。そして、ルール情報に基づいた不正判定を行い、ルール管理者が適正に不正判定ができていると判断した場合に、ルール管理者の操作によってテストモードフラグがＯＦＦに設定され、正式なルール情報として登録される。
【0017】
更新日時は、ルール情報が設定（新規作成、又は更新）された日時を示す情報である。
負荷利用フラグは、負荷増大時に当該ルール情報に基づいた不正判定処理を実施するか否かを示すフラグ情報である。なお、負荷増大時としては、例えば、本サービスサーバ１０が提供するサービス（ターゲットサービス）のキャンペーン期間であってもよく、サービスサーバ１０に閾値以上のアクセスがあった場合を負荷増大時としてもよい。本実施形態では、第一ルール情報の負荷利用フラグがＯＮとなり、第二ルール情報の負荷利用フラグがＯＦＦとなる例を示す。
負荷利用フラグは、負荷増大時に当該ルール情報に基づいた不正判定処理を実施するか否かを示すフラグ情報である。なお、負荷増大時としては、例えば、本サービスサーバ１０が提供するサービス（ターゲットサービス）のキャンペーン期間であってもよく、サービスサーバ１０に閾値以上のアクセスがあった場合を負荷増大時としてもよい。本実施形態では、第一ルール情報の負荷利用フラグがＯＮとなり、第二ルール情報の負荷利用フラグがＯＦＦとなる例を示す。
【0018】
また、ルール情報としては、上記の他、不正判定結果を審査端末４０等に送信するか否かのフラグ情報で通知フラグや、不正判定を実施する上での優先順位を示す優先度等が含まれていてもよい。
【0019】
ユーザＤＢ１２２は、サービスサーバ１０が提供するサービス（すなわち、ターゲットサービス）を利用するユーザに関するユーザ情報が記録される。
ユーザ情報としては、例えば、ユーザＩＤ、ユーザ名、通知先情報、ユーザ属性、履歴情報などが含まれる。
ユーザＩＤは、ユーザを識別するための識別情報である。
ユーザ名は、ユーザのアカウント名である。
通知先情報は、ユーザの連絡先であり、例えばメールアドレスや、メッセンジャー等のアカウント名が記録される。
ユーザ属性は、サービスサーバ１０が提供するサービスを利用する上で利用される各種ユーザの属性情報である。例えば、サービスサーバ１０がネットショッピングサービスを提供する場合、ユーザの性別、年齢、居所、職業、趣味等の嗜好情報、ユーザの年収等が含まれてもよい。サービスサーバ１０がナビゲーションサービスを提供する場合、ユーザの居所やユーザが頻繁に訪れる場所、興味があるスポット等が含まれていてもよい。
履歴情報は、サービスサーバ１０が提供するサービスの利用履歴等、各種履歴情報を記録する。例えば、サービスサーバ１０がネットショッピングサービスを提供する場合、ユーザの商品の購入履歴や商品検索履歴、コメント履歴等が含まれていてもよい。サービスサーバ１０がナビゲーションサービスを提供する場合、ユーザの移動履歴等が含まれていてもよい。
なお、上記のようなユーザ情報は、サービスサーバ１０が提供するサービスによって変化するものであるため、各々のサービスサーバ１０において、ユーザ情報に含まれる各種情報は異なっていてもよい。
ユーザ情報としては、例えば、ユーザＩＤ、ユーザ名、通知先情報、ユーザ属性、履歴情報などが含まれる。
ユーザＩＤは、ユーザを識別するための識別情報である。
ユーザ名は、ユーザのアカウント名である。
通知先情報は、ユーザの連絡先であり、例えばメールアドレスや、メッセンジャー等のアカウント名が記録される。
ユーザ属性は、サービスサーバ１０が提供するサービスを利用する上で利用される各種ユーザの属性情報である。例えば、サービスサーバ１０がネットショッピングサービスを提供する場合、ユーザの性別、年齢、居所、職業、趣味等の嗜好情報、ユーザの年収等が含まれてもよい。サービスサーバ１０がナビゲーションサービスを提供する場合、ユーザの居所やユーザが頻繁に訪れる場所、興味があるスポット等が含まれていてもよい。
履歴情報は、サービスサーバ１０が提供するサービスの利用履歴等、各種履歴情報を記録する。例えば、サービスサーバ１０がネットショッピングサービスを提供する場合、ユーザの商品の購入履歴や商品検索履歴、コメント履歴等が含まれていてもよい。サービスサーバ１０がナビゲーションサービスを提供する場合、ユーザの移動履歴等が含まれていてもよい。
なお、上記のようなユーザ情報は、サービスサーバ１０が提供するサービスによって変化するものであるため、各々のサービスサーバ１０において、ユーザ情報に含まれる各種情報は異なっていてもよい。
【0020】
また、本実施形態では、ユーザ情報は、他のサービスサーバ１０の記憶部１２に記憶されているユーザ情報と互いに紐づけられている。例えば、複数のサービスサーバ１０において、同一ユーザに対して共通のユーザＩＤが付されていてもよい。または、メールアドレス等の通知先情報が同一であるユーザ情報を、同一ユーザとして紐づけてもよい。各サービスサーバ１０が保有するユーザ情報に、他のサービスサーバ１０のどのユーザ情報が同一ユーザとして紐づけられているかを示す連動情報がさらに記録されていてもよい。
【0021】
ＢＬ１２３は、サービスの利用を提供しないユーザのリストを記録した情報であり、例えばユーザを特定するユーザＩＤが記録される。このＢＬ１２３は、複数回に亘って不正利用を行ったユーザや、過度の損害を与えかねない不正を実施したユーザのユーザＩＤが記録される。
【0022】
判定ログＤＢ１２４は、不正判定処理により得られた判定結果を蓄積するデータベースである。
【0023】
制御部１３は、ＣＰＵ（Central Processing Unit）等の演算回路、ＲＡＭ（Random Access Memory）等の記録回路により構成される。制御部１３は、記憶部１２等に記録されている各種プログラムをＲＡＭに展開し、ＲＡＭに展開されたプログラムとの協働により各種処理を実行する。そして、制御部１３は、記憶部１２に記録された不正判定プログラムを含む各種プログラムを読み込み実行することで、図１に示すように、提供要求受信部１３１、ルール取得部１３２、ユーザ情報取得部１３３、不正判定部１３４、サービス提供部１３５、ルール設定部１３６、及び審査要求部１３７等として機能する。
【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】
１…不正判定システム、１０…サービスサーバ（不正判定装置）、１２…記憶部、１３…制御部、２０…ユーザ端末、３０…ルール管理端末、４０…審査端末（審査判定部）、１２１…ルールＤＢ（ルールデータベース）、１２２…ユーザＤＢ（ユーザデータベース）、１２３…ブロックリスト（ＢＬ）、１２４…判定ログＤＢ（判定ログデータベース）、１３１…提供要求受信部、１３２…ルール取得部、１３３…ユーザ情報取得部、１３４…不正判定部、１３５…サービス提供部、１３６…ルール設定部、１３７…審査要求部。
【図1】
【図2】
【図3】