(57)【要約】【課題】ネットワーク上で提供するサービスを利用するユーザ端末のデバイスＩＤを比較的軽い負担で利用可能にする技術を提供する。【解決手段】デバイス識別情報処理システムは、取引サービスサーバとユーザ端末がネットワークを介して取引を行う取引サービスの手順の中で、前記取引サービスサーバからユーザ端末へデータ取得処理を実行するための取得処理ファイルを送信させ、該データ取得処理を実行した前記ユーザ端末から該データ取得処理で取得したデバイスデータを取得するデータ取得手段と、前記データ取得手段が取得した前記デバイスデータに基づいて、前記ユーザ端末を識別するためのデバイス識別情報を算出するデバイス識別情報処理手段と、を有している。【選択図】図１
2014010526.tif 000002
【特許請求の範囲】
【請求項１】
取引サービスサーバとユーザ端末がネットワークを介して取引を行う取引サービスの手順の中で、前記取引サービスサーバからユーザ端末へデータ取得処理を実行するための取得処理ファイルを送信させ、該データ取得処理を実行した前記ユーザ端末から該データ取得処理で取得したデバイスデータを取得するデータ取得手段と、
前記データ取得手段が取得した前記デバイスデータに基づいて、前記ユーザ端末を識別するためのデバイス識別情報を算出するデバイス識別情報処理手段と、を有するデバイス識別情報処理システム。
【請求項２】
前記デバイス識別情報処理手段は、前記取引を単位として前記デバイス識別情報を算出する、請求項１に記載のデバイス識別情報処理システム。
【請求項３】
前記デバイス識別情報処理手段は、前記ユーザ端末から取引実行の要求が送出されたことを契機として、前記デバイス識別情報を算出する、請求項１または２に記載のデバイス識別情報処理システム。
【請求項４】
前記デバイス識別情報処理手段は、過去の取引で算出したデバイス識別情報をデータベースに蓄積しており、新たな取引で算出したデバイス識別情報と前記データベース内のデバイス識別情報とを所定のマッチング条件で照合する、
請求項１から３のいずれか一項に記載のデバイス識別情報処理システム。
【請求項５】
前記デバイス識別情報処理手段は、同じユーザ端末が同じユーザ端末であると判定される率である一致率を向上するように前記マッチング条件を動的に変化させる、請求項４に記載のデバイス識別情報処理システム。
【請求項６】
前記デバイス識別情報処理手段は、デバイスデータの組み合わせが互いに異なる複数の算出アルゴリズムで複数のデバイス識別情報を算出し、前記複数のデバイス識別情報の中から照合に用いるデバイス識別情報を選択する、請求項５に記載のデバイス識別情報処理システム。
【請求項７】
前記データ取得手段は、前記取引サービスの手順の中で前記ユーザ端末から、更に、該ユーザ端末のユーザを識別するユーザ識別情報を取得し、
前記デバイス識別情報処理手段は、
前記ユーザ識別情報と前記複数のデバイス識別情報を対応づけて前記データベースに蓄積し、あるいは前記ユーザ識別情報と前記複数のデバイス識別情報に加えて更に複数のデバイスデータを互いに対応付けて前記データベースに蓄積し、
前記ユーザ識別情報で示される複数のユーザについての前記複数のデバイス識別情報または前記複数のデバイスデータの時間的な変化傾向に基づいて、特定のデバイス識別情報に変化が生じうる期間であるデータ変化期間を特定し、
前記データ変化期間には前記特定のデバイス識別情報を照合に用いない、
請求項６に記載のデバイス識別情報処理システム。
【請求項８】
前記デバイス識別情報処理手段は、
過去の取引で算出した複数のデバイス識別情報からなるデバイス識別情報群を前記データベースに蓄積しており、
新たな取引で算出した複数のデバイス識別情報と、前記データベース内のデバイス識別情報群の複数のデバイス識別情報とを照合し、全てのデバイス識別情報が一致するデバイス識別情報群があれば、前記新たな取引のユーザ端末が該デバイス識別情報群のユーザ端末と一致したと判定し、
全てのデバイス識別情報が一致するデバイス識別情報群が無く、所定個以下のデバイス識別情報だけが不一致のデバイス識別情報群があった場合、該不一致のデバイス識別情報を履歴に記録し、
複数のユーザについての前記履歴に基づいて、不一致の発生数または発生頻度が所定の閾値よりも高いデバイス識別情報を照合に用いない、
請求項６に記載のデバイス識別情報処理システム。
【請求項９】
前記デバイス識別情報処理手段は、
前記データベースに、前記過去の取引で算出したデバイス識別情報に対応付けて、該デバイス識別情報が示すユーザ端末の過去の取引実績に基づく端末危険度スコアを記録しており、
前記新たな取引で算出したデバイス識別情報との照合でマッチングしたデバイス識別情報に対応した端末危険度スコアを取得する、
請求項４に記載のデバイス識別情報処理システム。
【請求項１０】
前記データ取得手段は、前記取引サービスの手順の中で前記ユーザ端末から、更に、該ユーザ端末のユーザを識別するユーザ識別情報と取引内容との一方または両方を含む取引データを取得し、
前記デバイス識別情報処理手段は、
前記デバイス識別情報と前記取引データを対応付けて前記データベースに蓄積し、
新たな取引で算出したデバイス識別情報と前記マッチング条件でマッチングした前記データベース内のデバイス識別情報に対応する取引データに基づいて取引危険度スコアを算出する、
請求項４に記載のデバイス識別情報処理システム。
【請求項１１】
前記デバイス識別情報処理手段は、
前記データベースに、前記過去の取引で算出したデバイス識別情報に対応付けて、該デバイス識別情報が示すユーザ端末の過去の取引実績に基づく端末危険度スコアを記録しており、
前記新たな取引で算出したデバイス識別情報との照合でマッチングしたデバイス識別情報に対応した端末危険度スコアを取得し、
前記取引危険度スコアと前記端末危険度スコアとに基づいて総合危険度スコアを算出する、
請求項１０に記載のデバイス識別情報処理システム。
【請求項１２】
前記デバイス識別情報処理手段は、デバイス識別情報が同一である所定回数以上の複数の取引が所定時間内に発生した場合において、該複数の取引のユーザ識別情報が同じである場合と、該ユーザ識別情報が異なる場合とで、異なる取引危険度スコアを算出する、請求項１０または１１に記載のデバイス識別情報処理システム。
【請求項１３】
前記デバイス識別情報処理手段は、前記複数の取引のユーザ識別情報が同じである場合の方が該ユーザ識別情報が異なる場合よりも危険が高いことを表わす取引危険度スコアを算出する、請求項１２に記載のデバイス識別情報処理システム。
【請求項１４】
前記データ取得手段が取引サービスサーバに配置され、前記デバイス識別情報処理手段が前記取引サービスサーバからの要求に応じてデバイス識別情報を算出するデバイス識別情報サーバに配置されており、
前記デバイス識別情報サーバの前記デバイス識別情報処理手段は、前記取引サービスサーバからの取引実績に関するフィードバック情報に基づく端末危険度スコアを前記データベースに記録する、
請求項９または１１に記載のデバイス識別情報処理システム。
【請求項１５】
前記デバイス識別情報処理手段は、
取引実行の要求を契機としてデバイス識別情報を算出すると、該デバイス識別情報と当該取引との対応づけを所定時間以上保持し、
前記取引サービスサーバから当該取引に関するフィードバック情報を前記所定時間内に受信すると、当該取引に対応するデバイス識別情報に前記データベース上で対応する端末危険度スコアを更新する、
請求項１４に記載のデバイス識別情報システム。
【請求項１６】
データ取得手段が、取引サービスサーバとユーザ端末がネットワークを介して取引を行う取引サービスの手順の中で、前記取引サービスサーバからユーザ端末へデータ取得処理を実行するための取得処理ファイルを送信させるステップと、
前記データ取得手段が、該データ取得処理を実行した前記ユーザ端末から、該データ取得処理で取得したデバイスデータを取得するステップと、
デバイス識別情報処理手段が、前記データ取得手段が取得した前記デバイスデータに基づいて、前記ユーザ端末を識別するためのデバイス識別情報を算出するステップと、を有するデバイス識別情報処理方法。
【請求項１７】
コンピュータにデバイス識別情報の処理を行わせるためのデバイス識別情報処理プログラムであって、
取引サービスサーバとユーザ端末がネットワークを介して取引を行う取引サービスの手順の中で、前記取引サービスサーバからユーザ端末へデータ取得処理を実行するための取得処理ファイルを送信し、該データ取得処理を実行した前記ユーザ端末から、データ取得手段が、該データ取得処理で取得したデバイスデータを取得する手順と、
デバイス識別情報処理手段が、前記データ取得手段が取得した前記デバイスデータに基づいて、前記ユーザ端末を識別するためのデバイス識別情報を算出する手順と、をコンピュータに実行させるためのデバイス識別情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上で提供する取引サービスの利用者の正当性を計測する技術に関する。
【背景技術】
【０００２】
ネットワークを介して取引を行うサービスがある。この種の取引サービスでは、商品を購入したユーザから料金が支払われない等の不正取引によってサービス提供者が損害を被ることがある。そのような不正取引は特定の不正ユーザによって繰り返される場合が多い。そのため、不正取引を繰り返すような不正ユーザや不正取引を損害が発生する前に判別する技術が求められている。
【０００３】
特許文献１には、サーバにアクセスするユーザ端末に関する情報（デバイスデータ）を収集し、デバイスデータからユーザ端末をある程度の確度で特定することが可能なデバイス識別情報（デバイスＩＤ（Ｉｄｅｎｔｉｆｉｅｒ））を算出する技術が開示されている。不正ユーザが異なる名前を使って不正取引を行おうとしても、デバイスＩＤを照合により、過去に不正取引を行った不正なユーザ端末を判別できれば、ユーザ端末から不正な取引を検知することが可能となる。
【０００４】
特許文献１の技術は、サーバがユーザ端末とＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）接続を確立するときにそのユーザ端末のデバイスデータを取得し、そのデバイスデータを使ってデバイスＩＤを算出するというものである。デバイスＩＤ毎に取引の危険度を管理しておくことにより、不正ユーザがアクセスしてきたとき、その接続を拒否することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２００８／０２４４７４４Ａ１号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載されたシステムでは、サーバがＴＣＰ接続時にユーザ端末上のブラウザからデバイスデータを取得する。そのため、ＴＣＰ接続時にユーザ端末上のブラウザからデバイスデータを取得するという処理を実行するためのプログラムをサーバに予め実装しておく必要がある。
【０００７】
それ故、デバイスＩＤによってユーザ端末を検証する機能を備えたＷｅｂサービスを提供するシステムを新たに構築する場合や、デバイスＩＤの機能を実装せずに既に取引サービスを行っている既存のＷｅｂサービスにデバイスＩＤの機能を追加する場合に、プログラムを実装する作業によってサービス提供事業者への負担が大きなものとなってしまう。
【０００８】
本発明の目的は、ネットワーク上で提供するサービスを利用するユーザ端末のデバイスＩＤを比較的軽い負担で利用可能にする技術を提供することである。
【課題を解決するための手段】
【０００９】
本発明の一つの実施態様に従うデバイス識別情報処理システムは、取引サービスサーバとユーザ端末がネットワークを介して取引を行う取引サービスの手順の中で、前記取引サービスサーバからユーザ端末へデータ取得処理を実行するための取得処理ファイルを送信させ、該データ取得処理を実行した前記ユーザ端末から該データ取得処理で取得したデバイスデータを取得するデータ取得手段と、前記データ取得手段が取得した前記デバイスデータに基づいて、前記ユーザ端末を識別するためのデバイス識別情報を算出するデバイス識別情報処理手段と、を有している。
【発明の効果】
【００１０】
本発明によれば、ネットワーク上で提供するサービスを利用するユーザ端末のデバイス識別情報を比較的軽い負担で利用可能になる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態による取引サービスシステムの構成を示すブロック図である。
【図２】デバイスＩＤが記憶されるデータベースのデータ構成例を示す図である。
【図３】取引サービスサーバ１１の機能構成を示すブロック図である。
【図４】本実施形態によるデバイスＩＤサーバ１２の機能構成を示すブロック図である。
【図５】本実施形態による取引サービスシステムの動作例を示すシーケンス図である。
【図６】実行された取引において不正が発覚した場合の取引サービスシステムの動作例を示すシーケンス図である。
【図７】デバイスＩＤサーバ１２が取引危険度スコアを算出する処理を示すフローチャートである。
【図８】デバイスＩＤデータベースのデータ構成の変形例を示す図である。
【図９】変形例３におけるデバイスＩＤマッチングの処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
本発明の実施形態について図面を参照して説明する。
【００１３】
図１は、本実施形態による取引サービスシステムの構成を示すブロック図である。図１を参照すると、取引サービスシステムは、取引サービスサーバ１１とデバイスＩＤサーバ１２を有している。
【００１４】
取引サービスサーバ１１はインターネット１５を通じてクライアントＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）１３と接続し、クライアントＰＣ１３にＷｅｂショッピング等の取引サービスを提供する。クライアントＰＣ１３は、取引サービスサーバ１１が提供する取引サービスを利用するユーザのユーザ端末である。ここでいうユーザには、正当なユーザと不正なユーザが含まれる。不正なユーザからの不正なアクセスは、取引サービスサーバ１１にて検知され、取引の実行が拒否されることが望ましい。
【００１５】
取引サービスの一連の手順は、取引サービスサーバ１１とクライアントＰＣ１３が、ＴＣＰ接続などで接続された状態で開始される。取引サービスの手順は、ユーザがＷｅｂページ上の商品の表示を閲覧し、その中から購入する商品を選択し、その購入を決定するという一連の流れを構成している。取引サービスサーバ１１は、取引サービスの手順の中で、クライアントＰＣ１３へデータ取得処理を実行するための取得処理ファイルを送信し、そのデータ取得処理を実行したクライアントＰＣ１３からデータ取得処理で取得したデバイスデータを取得する。デバイスデータを取得するタイミングは、一連の手順の中のどのようなタイミングであっても良い。取引サービスサーバ１１は、取得したデバイスデータをデバイスＩＤサーバ１２に送信する。
【００１６】
デバイスデータとして利用できるデータには様々なものがあるが、例えば、クライアントＰＣ１３で使用されているブラウザの種類およびバージョン、使用されているＯＳ（オペレーティングシステム）の種類およびバージョン、ＣＰＵの種類、使用できる文字セット、使用できる言語などがある。またその他に、Ｍｉｍｅｔｙｐｅ（使用できるファイルタイプ（拡張子））、Ｐｌｕｇ−ｉｎ情報（使っているプラグインに関する情報）、フォント情報、画面サイズ（スクリーンサイズ）、Ｗｅｂページのウィンドウのサイズ、ウィンドウ内のＷｅｂページ表示部分のサイズ、Ｃｏｏｋｉｅ、時間情報（時差情報、時計の時刻）などをデバイスデータとして利用しても良い。
【００１７】
デバイスＩＤサーバ１２は、取引単位で、取引サービスサーバ１１から受信したデバイスデータを基に、ユーザや取引内容に依存せずにクライアントＰＣ１３を特定することが可能なデバイスＩＤを算出し、そのデバイスＩＤを基に各取引の危険度スコアを取得し、取引サービスサーバ１１に提供する。危険度スコアは当該取引において不正が行われる危険度を示すものであり、取引サービスサーバ１１が当該取引の処理における取引実行の可否判定に利用する。
【００１８】
ここでいう危険度スコアは、典型的には、取引の危険度を示す取引危険度スコアであるが、クライアントＰＣ１３自体の危険度を示す端末危険度スコアであっても良く、あるいは端末危険度スコアを含むものであっても良い。また、取引危険度スコアは、取引データと端末危険度スコアとから算出されたものであっても良く、取引データのみから算出されたものであっても良い。各取引の取引データは、その取引を行うユーザのユーザ識別情報と、その取引の取引内容とを含んでいる。その取引内容には、例えば取引がＷｅｂショッピングであれば、購入商品を識別する商品識別情報と、その商品の購入代金の金額情報とが含まれる。
【００１９】
デバイスＩＤサーバ１２は、過去の取引においてデバイスデータから算出されたデバイスＩＤと、そのデバイスＩＤで示されるクライアントＰＣ１３の取引における危険度を示す端末危険度スコアとの対応関係をデータベースとして予め記憶している。このデータベース内の端末危険度スコアは、過去の取引実績から決定されたものである。例えば、過去の取引において不正があったデバイスＩＤの端末危険度スコアは高い値となる。
【００２０】
デバイスＩＤは、デバイスデータから所定のアルゴリズムで算出することができる。デバイスデータとしては複数項目のデータがあり、各項目のデバイスデータの値は複数のＰＣで重複し得るようなものであるが、複数種類のデバイスデータを集めてそれらを基に算出したデバイスＩＤは相当程度の確度で個々のクライアントＰＣ１３の特定が可能である。
【００２１】
基本的なデバイスＩＤとしては、いずれかのデバイスデータが１つでも変化すれば、デバイスＩＤの値も変化するようなアルゴリズムで生成されるデバイスＩＤがある。そのため、デバイスＩＤは、実用的には、クライアントＰＣ１３を個々に特定する識別情報として利用可能なものである。端末危険度スコアは、ここでは一例として、過去の取引において不正が発覚したことがあることを示す不正フラグの有無で示されるものとする。
【００２２】
図２は、デバイスＩＤが記憶されるデータベースのデータ構成例を示す図である。この例ではデバイスＩＤ毎に不正フラグが設けられ、不正フラグには１または０が設定されている。不正フラグ＝１は過去に不正があったことを示し、不正フラグ＝０は過去に不正が無かったことを示す。よって、不正フラグ＝１は不正フラグ＝０よりも、そのクライアントＰＣ１３の端末危険度スコアが高いことを示している。なお、この例では端末危険度スコアが１と０の二値で表わされているが、本発明がこれに限定されることは無く、端末危険度スコアは多値で表わされるものであっても良い。
【００２３】
そして、クライアントＰＣ１３から取引実行の要求が送出されたことを契機として、デバイスＩＤサーバ１２は、取引サービスサーバ１１がクライアントＰＣ１３から取得したデバイスデータに基づいてデバイスＩＤを算出する。その結果、デバイスＩＤは取引単位で算出されることになる。更に、デバイスＩＤサーバ１２は、算出したデバイスＩＤに対応する不正フラグの値をデータベースから取得し、不正フラグの値と取引データとに基づき、その取引の危険度スコアを決定して取引サービスサーバ１１に通知する。なお、デバイスＩＤサーバ１２は、取引実行の要求が送出されたことを、取引サービスサーバ１１経由で知ることができる。取引サービスサーバ１１に通知された危険度スコアは、クライアントＰＣ１３へのサービスにおいて、取引の実行を確定させるか、拒否するかを判断する処理に利用される。
【００２４】
以上説明したように、本実施形態によれば、クライアントＰＣ１３から取得したデバイスデータから算出したデバイスＩＤに対応する危険度スコアが取得されるので、ユーザが名前やユーザＩＤなどのユーザ識別情報を変えて不正な取引を行おうとしても、デバイスＩＤで特定されるクライアントＰＣ１３から不正な取引の危険度を判断することが可能である。
【００２５】
またその際、本実施形態によれば、取引サービスサーバ１１が取引サービスの手順の中でクライアントＰＣ１３に取得処理ファイルを送信するだけで、クライアントＰＣ１３からデバイスデータを取得できる。具体例としては、ＨＴＭＬファイルにＪａｖａｓｃｒｉｐｔ（Ｊａｖａは登録商標）等でデータ取得処理を入れて取引サービスサーバ１１に格納しておき、取引サービスの手順において取引サービスサーバ１１からクライアントＰＣ１３にＨＴＴＰ通信でそのＨＴＭＬファイルを送信するだけで、ＨＴＴＰ通信の結果として、クライアントＰＣ１３のブラウザがデバイスデータを取得し、取引サービスサーバ１１に送出してくれる。そのため、クライアントＰＣ１３からデバイスデータを取得するための特別な処理のプログラムを取引サービスサーバ１１に予め実装する必要が無く、サービス提供事業者への負担は軽いものとなる。
【００２６】
また上述した特許文献１に記載されたシステムでは、ＴＣＰ接続時にデバイスＩＤが算出される。このシステムをＷｅｂショッピングのような取引を行うサービスに適用した場合、ユーザが実際の取引を要求しない場合にもデバイスＩＤの算出および照合の処理を実行することになり、デバイスＩＤの処理を実行するサーバの負担が大きい。それに対して、本実施形態では、デバイスＩＤサーバ１３は、クライアントＰＣ１３から取引実行の要求が送出されたことを契機として、デバイスＩＤを算出するので、ユーザが実際の取引の実行を要求した場合にのみデバイス識別情報を算出する処理が実行される。そのため、実際の取引を行わない場合のデバイス識別情報の算出等の処理を省き、デバイスＩＤサーバ１２の負荷を軽減することができる。これを異なる側面から見ると、本実施形態では、デバイスＩＤサーバ１２は取引単位にデバイスＩＤを算出するものであると言える。
【００２７】
図３は、取引サービスサーバ１１の機能構成を示すブロック図である。図３を参照すると、取引サービスサーバ１１は、データ取得部２１と取引処理部２２を有している。例えば、取引サービスサーバ１１は、コンピュータがソフトウェアプログラムを実行することで各機能部の機能が実現される装置である。
【００２８】
取引処理部２２は、アクセスしてきたクライアントＰＣ１３と接続し、クライアントＰＣ１３と通信することでＷｅｂページ上での取引サービスを進行させ、最終的にクライアントＰＣ１３からの要求を受けて取引を確定させる。例えば、販売する商品をＷｅｂページ上に表示し、クライアントＰＣ１３からの指示でユーザが購入する商品を選択し、クライアントＰＣ１３からの要求により商品の売買を確定させる。その後、例えば、商品は別途ユーザに配送され、購入代金はクレジットカードや電子マネーで支払われる。
【００２９】
なお、取引処理部２２は、クライアントＰＣ１３から取引実行の確定の要求を受けると、その旨をデバイスＩＤサーバ１２に通知する。
【００３０】
また、取引処理部２２は、取引実行の後、商品購入代金が支払われないなどの不正が発覚したら、不正が発覚した旨を取引サービスサーバ１１内で記憶すると共に、デバイスＩＤサーバ１２に通知する。取引サービスサーバ１１内に不正発覚の情報が記録されるので、その後、同じユーザが同じ名前などのユーザ識別情報を用いて取引を要求してきた場合には、取引サービスサーバ１１自身でも不正の危険を検知することが可能である。しかし、同じユーザが他人を装い、異なる名前で取引を要求してきた場合には、取引サービスサーバ１１は不正の危険を検知することができない。本実施形態のデバイスＩＤサーバ１２は、そのような場合にも不正の危険を検知できるようにするものである。
【００３１】
データ取得部２１は、取引処理部２２が行う取引サービスの手順の中で、データ取得処理を実行するための取得処理ファイルをクライアントＰＣ１３へ送信し、データ取得処理を実行したクライアントＰＣ１３からデータ取得処理で取得したデバイスデータを取得し、デバイスＩＤサーバ１２に通知する。
【００３２】
図４は、本実施形態によるデバイスＩＤサーバ１２の機能構成を示すブロック図である。図４を参照すると、デバイスＩＤサーバ１２は、デバイスＩＤの算出や照合などのデバイスＩＤ処理を行う装置であって、データ処理部３１、取引危険度スコア処理部３２、端末危険度スコア処理部３３、およびデバイスＩＤデータベース３４を有している。例えば、デバイスＩＤサーバ１２は、コンピュータがソフトウェアプログラムを実行することで、データ処理部３１、取引危険度スコア処理部３２、端末危険度スコア処理部３３といった機能部の機能が実現される装置である。
【００３３】
データ処理部３１は、取引サービスサーバ１１からデバイスデータを受信して保持し、クライアントＰＣ１３から取引実行の要求が送出されたことを取引サービスサーバ１１からの通知によって知得すると、それを契機として、保持していたデバイスデータを用いてデバイスＩＤを算出する。
【００３４】
デバイスＩＤデータベース３４には、過去の取引で算出したデバイスＩＤが蓄積されている。つまり、過去に取引実績のあるデバイスＩＤか否かをデバイスＩＤデータベース３４の参照により知ることができる。端末危険度スコア処理部３３は、データ処理部３１が算出したデバイスＩＤと所定のマッチング条件でマッチングが取れるデバイスＩＤがデバイスＩＤデータベース３４内に存在するか否か判定する。
【００３５】
そのため、本実施形態によれば、取引要求を発したクライアントＰＣ１３が過去に取引実績のあるクライアントＰＣ１３であるか否かを知ることができ、取引実績の有無を取引の危険度の判断に利用することができる。例えば、取引の実行を確定させるか、拒否するかを決めるために、取引の危険度を総合的に判断する際、取引実績がある場合には取引実績が無い場合よりも安全であるという考慮が可能である。
【００３６】
また、デバイスＩＤデータベース３４には、図２に示したように、過去の取引で不正が発覚したことのあるデバイスＩＤに不正フラグ＝１が設定され、過去の取引で不正が無かったデバイスＩＤに不正フラグ＝０が設定されている。この不正フラグの有無が端末危険度スコアの一例である。過去の取引で算出したデバイスＩＤに対応付けて、そのデバイスＩＤが示すクライアントＰＣ１３の過去の取引実績に基づく端末危険度スコアを記録している。
【００３７】
端末危険度スコア処理部３３は、新たな取引で算出したデバイスＩＤとの照合でマッチングしたデバイスＩＤに対応した端末危険度スコアを判定する。具体例として、ここでは、端末危険度スコア処理部３３は、データ処理部３１が算出したデバイスＩＤとマッチングがとれたデバイスＩＤに不正フラグが設定されているか否か判定する。これによれば、取引要求を発したクライアントＰＣ１３が過去に取引実績のあるものであるか否かだけでなく、そのクライアントＰＣ１３の過去の取引実績に基づく危険度スコアも取得し、利用することができる。
【００３８】
なお、実行した取引にて不正が発覚したことは、取引サービスサーバ１１の取引処理部２２から事後的に通知される。上述のように、デバイスＩＤデータベース３４にデバイスＩＤに対応づけた不正フラグが設定されているので、過去の取引実績の有無だけでなく、過去の取引における不正の有無も、取引の危険度を総合的に判断する際に考慮することができる。過去に不正取引があった場合、不正取引が無かった場合よりも危険であると考えることができる。
【００３９】
上述のように、端末危険度スコア処理部３３は、データ処理部３１が新たな取引で算出したデバイスＩＤとデバイスＩＤデータベース３４内の過去の取引のデバイスＩＤとを所定のマッチング条件で照合する。その際、完全一致をマッチング条件としても良く、あるいは完全には一致しなくても一部一致など所定の条件を満たせば一致とみなすことにしても良い。更にマッチング条件を可変にしても良い。
【００４０】
なお、上述した実施形態において、取引サービスサーバ１１のデータ取得部２１は、取引サービスの手順の中でクライアントＰＣ１３から、デバイスデータだけでなく、更に、クライアントＰＣ１３を使用しているユーザを識別するユーザ識別情報（ユーザＩＤ）を取得し、デバイスＩＤサーバ１２に通知することにしても良い。
【００４１】
その場合、例えば、デバイスＩＤサーバ１２のデータ処理部３１は、ユーザＩＤとデバイスＩＤを対応づけてデバイスＩＤデータベース３４に蓄積し、あるいはユーザＩＤとデバイスＩＤに加えて更にデバイスデータを互いに対応付けてデバイスＩＤデータベース３４に蓄積しても良い。そして、端末危険度スコア処理部３３は、ユーザＩＤで示される個別のユーザについてのデバイスＩＤまたはデバイスデータの時間的な変化の傾向を複数のユーザについて調べ、その全体の変化傾向に基づいて、デバイスＩＤに変化が生じうる期間であるデータ変化期間を特定し、データ変化期間にはマッチング条件を緩和あるいは変更することにしてもよい。
【００４２】
例えば、大多数のデバイスＩＤが同時期に変化している場合、その時期には不正でない外部的な要因でデバイスデータに変化が生じているものと判断し、データ変化期間を設定すればよい。これによれば、複数のユーザのデバイスデータの時間的な変化トレンドから判断したデータ変化期間内であれば、デバイスデータが変化しても、マッチング条件を緩和あるいは変更することで、デバイスＩＤのマッチングが取れるようにする。そのため、外部要因など正当な理由によってデバイスデータが変化したクライアントＰＣ１３のデバイスＩＤを継続して判断に利用することが可能となる。例えば、オペレーティングシステムの新バージョンがリリースされ、自動ダウンロードによって配信されるような場合には、一定期間、不正な要因でなく広範囲の多数のＰＣにおいてデバイスＩＤが変化することが考えられる。そのような場合に、デバイスＩＤサーバ１２の端末危険度スコア処理部３３は、同じクライアントＰＣ１３が同じクライアントＰＣ１３であると判定される率である一致率を向上するようにマッチング条件を動的に変化させることにしてもよい。
【００４３】
例えば、データ処理部３１は、用いるデバイスデータの組み合わせが互いに異なる複数の算出アルゴリズムで複数のデバイス識別情報を算出し、複数のデバイス識別情報の中から照合に用いる１つあるいは複数あるいは全てのデバイス識別情報を選択することにしてもよい。
【００４４】
なお、ここではユーザ識別情報（ユーザＩＤ）は、例えば、取引の手順の中でユーザが入力する顧客識別情報（顧客ＩＤ）であってもよい。取引の手順において入力される顧客ＩＤは、ＴＣＰ接続時以前には取得できないため、ＴＣＰ接続時にデバイスＩＤの算出や照合を行う仕様の場合には、デバイスＩＤのそれらの処理を行う段階で顧客ＩＤを利用することはできない。しかし、本実施形態では、取引実行が要求されてからデバイスＩＤの算出および照合を行うようにしているので、デバイスＩＤの照合を行うときまでに顧客ＩＤを利用することが可能となる。
【００４５】
具体的には、ＴＣＰ接続時には顧客ＩＤを含む取引データを取得できないが、ＨＴＴＰ通信の段階では顧客ＩＤの取得が可能である。本実施形態では、その顧客ＩＤを使ってデバイスデータの変化傾向をつかみ、デバイスＩＤのマッチング精度を向上させることができる。
【００４６】
具体例として、デバイスＩＤの算出に用いる複数のデバイスデータの組み合わせが互いに異なる複数の算出アルゴリズムで複数種類のデバイスＩＤ１〜ｎを常時算出しており、あるデバイスデータが変化するデータ変化期間には、変化するデバイスデータを含まない算出アルゴリズムで算出されたデバイスＩＤの一致あるいは不一致によって、マッチング判定をすることにしても良い。これについては変形例１として後述する。
【００４７】
あるいは、デバイスＩＤの算出に用いる複数のデバイスデータの組み合わせが互いに異なる複数の算出アルゴリズムで複数種類のデバイスＩＤ１〜ｎを常時算出しており、あるデバイスＩＤが変化するデータ変化期間には、それとは異なる算出アルゴリズムで算出したデバイスＩＤの一致あるいは不一致によって、マッチング判定をすることにしても良い。これについては変形例２として後述する。
【００４８】
あるいは、デバイスＩＤの算出に用いる複数のデバイスデータの組み合わせが互いに異なる複数の算出アルゴリズムで複数種類のデバイスＩＤ１〜ｎを常時算出し、全てのデバイスＩＤ１〜ｎをそれぞれにマッチング判定し、その結果に基づいて、デバイスＩＤ群として一致か不一致か、つまりクライアントＰＣ１３として一致か不一致かを判定することにしても良い。これについては変形例３として後述する。
【００４９】
あるいは、ブラウザやオペレーティングシステムのように非常に多数のＰＣにおいて共通に利用されるソフトウェアのバージョンアップ情報を外部から取得し、その外部からの情報に基づいてデータ変化期間を決定することにしてもよい。ブラウザやオペレーティングシステムのバージョンアップによるデバイスＩＤの変化によって、多くのクライアントＰＣ１３でマッチングが取れなくなるのを回避することができる。
【００５０】
あるいは、全体的なデバイスＩＤのマッチングの傾向としてマッチ率が低下したら、ブラウザのバージョンアップのような、非常に多数のＰＣにデバイスデータの変化が発生したと推定し、データ変化期間を設定してデバイスＩＤのマッチング条件を緩和することにしてもよい。
【００５１】
また、本実施形態では、データ取得部２１は、取引サービスの手順の中でクライアントＰＣ１３から、更に、クライアントＰＣ１３のユーザを識別するユーザ識別情報と取引内容とのいずれか一方または両方を含む取引データを取得し、デバイスＩＤサーバ１２に通知することにしても良い。その場合、デバイスＩＤデータベース３４には、デバイスＩＤと取引データを対応付けて蓄積しておくとよい。取引危険度スコア処理部３２は、新たな取引で算出したデバイスＩＤと所定のマッチング条件でマッチングしたデータベース内のデバイスＩＤに対応する取引データに基づいて取引危険度スコアを算出する。これによれば、同じクライアントＰＣ１３を利用した過去の取引内容や顧客ＩＤに基づいて、今回の取引の危険度を算出するので、精度の高い危険度の判定が可能となる。例えば、そのクライアントＰＣ１３を使って過去に同種の商品が繰り返し購入されている場合には取引危険度スコアを高くするというようなことが可能である。また、１つのクライアントＰＣ１３を使ってユーザＩＤが異なる多数の取引が行われている場合には取引危険度スコアを高くするようにようなことが可能である。また、同じクライアントＰＣ１３を使った取引において過去の取引よりも商品購入代金が大きく上昇した場合には取引危険度スコアを高くするというようなことが可能である。
【００５２】
なお、ここでは好適な例として、取引危険度スコア処理部３２は、取引危険度スコアを算出するとき、要素として、取引データだけでなく、端末危険度スコアをも演算に用いることにする。そして、取引危険度スコア処理部３２は、算出した取引危険度スコアを取引サービスサーバ１１に通知する。これによれば、取引危険度スコアと端末危険度スコアを併用することで危険度スコアの精度がより高まる。但し、取引危険度スコア処理部３２は、取引データだけから取引危険度スコアを算出し、取引サービスサーバ１１に通知することにしても良い。その場合には、端末危険度スコア処理部３３は、自身が取得した端末危険度スコアを取引サービスサーバ１１に別途通知することにするとよい。
【００５３】
また、他の例として、取引危険度スコア処理部３２は、新たな取引で算出したデバイスＩＤとの照合でマッチングしたデバイスＩＤに対応した端末危険度スコアを端末危険度スコア処理部３３から取得し、自身が算出した取引危険度スコアと、端末危険度スコア処理部３３から取得した端末危険度スコアとに基づいて、総合危険度スコアを算出することにしても良い。これによれば、取引危険度スコアと端末危険度スコアを併用することで危険度スコアの精度がより高まる。演算の具体例として、デバイスＩＤを照合してデバイスＩＤデータベース３４から得られた端末危険度スコアと、取引データから算出した危険度スコアとを重みづけ加算して、最終的な危険度スコアを算出することにしてもよい。
【００５４】
ここでは、取引危険度スコア処理部３２は、デバイスＩＤが同一である所定回数以上の複数の取引が所定時間内に発生した場合において、その複数の取引のユーザＩＤが同じである場合と、ユーザＩＤが異なる場合とで、異なる値の取引危険度スコアを算出する。これによれば、クライアントＰＣ１３とユーザの相互関係を利用して、精度の高い取引危険度スコアを算出することができる。例えば、取引危険度スコア処理部３２は、複数の取引のユーザＩＤが同じである場合の方がユーザＩＤが異なる場合よりも危険が高いことを表わす取引危険度スコアを算出するとよい。これによれば、同じクライアントＰＣ１３から同じユーザＩＤの取引が頻発したときに取引危険度スコアを高い値にするので、不正ユーザが不正取引を頻繁に繰り返すような状態を検知することが可能である。
【００５５】
また、上述のように、取引にて不正が発覚したというフィードバック情報は、取引サービスサーバ１１の取引処理部２２からデバイスＩＤサーバ１２に事後的に通知される。商品購入代金が支払われないというような不正が発覚するのは、通常、取引が成立して暫く期間が経過してからだからである。デバイスＩＤサーバ１２は、取引サービスサーバ１１からの取引実績に関するフィードバック情報に基づく端末危険度スコアをデバイスＩＤデータベース３４に記録することにしてもよい。例えば、取引において不正が発覚したら端末危険度スコアである二値的な不正フラグ＝１に設定することにしても良い。また例えば、取引において不正が発覚したことで多値的なな端末危険度スコアを上昇させることにしても良い。また、取引実行から所定時間内に不正の発覚が通知されなければ、取引において不正が無かったと判断し、端末危険度スコアを下降させることにしても良い。
【００５６】
その場合、端末危険度スコア処理部３３は、データ処理部３１がデバイスＩＤを算出すると、そのデバイスＩＤに対応する端末危険度スコアを取得し、取引危険度スコアを算出して取引サービスサーバ１１に通知すると共に、そのデバイスＩＤと当該取引との対応づけを少なくとも所定時間以上保持する。その後、単膜危険度スコア処理部３３は、取引サービスサーバ１１から当該取引に関するフィードバック情報を当該所定期間内に受信すると、デバイスＩＤデータベース３４上で当該取引に対応するデバイスＩＤの端末危険度スコアを更新することにすればよい。これによれば、取引実行の要求を契機としてデバイスＩＤを算出してから、取引サービスサーバ１１から取引実績のフィードバック情報が得られるまで期間があっても、デバイスＩＤとフィードバック情報を対応付け、そのデバイスＩＤの端末危険度スコアをそのフィードバック情報を基に更新することが可能である。
【００５７】
図５は、本実施形態による取引サービスシステムの動作例を示すシーケンス図である。
【００５８】
図５を参照すると、まず、クライアントＰＣ１３から取引サービスサーバ１１の取引サービスのＷｅｂページへのアクセスがあると、取引サービスサーバ１１はＷｅｂページのデータをクライアントＰＣ１３に通知する。
【００５９】
その後、一連の取引の手順が進行する。その一連の手順の中で、取引サービスサーバ１１は、取得処理ファイルをクライアントＰＣ１３に送信する。その取得処理ファイルを受信したクライアントＰＣ１３は、そのファイルに従って処理を実行し、所望のデバイスデータを取得して取引サービスサーバ１１に通知する。また、一連の取引の手順の中で、購入商品や個数といった取引データも取引サービスサーバ１１に通知される。
【００６０】
取引サービスにおいては、ユーザが取引の確定を要求する操作をすると、クライアントＰＣ１３から取引サービスサーバ１１へ確定要求が送られる。確定要求を受信した取引サービスサーバ１１は、デバイスデータおよび取引データと共に、デバイスＩＤの算出を依頼する通知をデバイスＩＤサーバ１２に送信する。
【００６１】
依頼を受けたデバイスＩＤサーバ１２は、取引サービスサーバ１１から受信したデバイスデータに基づいてデバイスＩＤを算出し、デバイスＩＤのマッチングを経てデバイスＩＤデータベース３４から端末危険度スコアを取得する。更に、デバイスＩＤサーバ１２は、その端末危険度スコアと、取引サービスサーバ１１から受信した取引データとに基づいて、取引危険度スコアを算出する。そして、デバイスＩＤサーバ１２は、算出した取引危険度スコアを取引サービスサーバ１１に通知する。
【００６２】
取引危険度スコアを受信した取引サービスサーバ１１は、その取引危険度スコアを利用して、クライアントＰＣ１３のユーザが要求している取引の実行を許容するか、拒否するか判定する。ここでは、取引危険度スコアが低く取引サービスサーバ１１は取引の実行を許容するという判定をするものとする。取引サービスサーバ１１は、その判定結果をクライアントＰＣ１３に通知する。クライアントＰＣ１３では、取引が実行された旨が表示され、取引が完了する。
【００６３】
今回の処理で算出したデバイスＩＤが未だデバイスＩＤデータベース３４に登録されていなければ、デバイスＩＤサーバ１２は、取引実行の確定を契機として、デバイスＩＤデータベース３４にデバイスＩＤと今回の取引データを追加登録する。一方、今回の処理で算出したデバイスＩＤが既にデバイスＩＤデータベース３４に登録されていれば、デバイスＩＤサーバ１２は、取引実行の確定を契機として、デバイスＩＤデータベース３４の当該デバイスＩＤに対して今回の取引データを追加登録する。
【００６４】
図６は、実行された取引において不正が発覚した場合の取引サービスシステムの動作例を示すシーケンス図である。
【００６５】
図６を参照すると、取引サービスサーバ１１にて実行した取引に不正が発覚すると、取引サービスサーバ１１は不正発覚を通知する実績通知をデバイスＩＤサーバ１２に通知する。デバイスＩＤサーバ１２は、実績通知を受けると、その内容に基づいて、デバイスＩＤデータベース３４の内容を更新する。例えば、あるクライアントＰＣ１３の取引において、不正が発覚すると、そのクライアントＰＣ１３のデバイスＩＤの不正フラグ＝１が登録される。あるいは例えば、あるクライアントＰＣ１３の取引において、不正が発覚すると、そのクライアントＰＣ１３のデバイスＩＤの端末危険度スコアが上昇する。
【００６６】
図７は、デバイスＩＤを算出したデバイスＩＤサーバ１２が取引危険度スコアを取得する処理を示すフローチャートである。
【００６７】
デバイスＩＤを算出したバイスＩＤサーバ１２は、そのデバイスＩＤと一致するデバイスＩＤがデバイスＩＤデータベース３４内にあるか否か判定する（ステップＳ１）。一致するデバイスＩＤがあった場合には、デバイスＩＤサーバ１２は、そのデバイスＩＤに対応する端末危険度スコアの値をデバイスＩＤデータベース３４から取得する（ステップＳ２）。ステップＳ１で一致するデバイスＩＤが無かったとき、あるいはステップＳ２で端末危険度スコアを取得した後、デバイスＩＤサーバ１２は、次に取引危険度スコアを算出する（ステップＳ３）。
【００６８】
取引危険度スコアの算出式に端末危険度スコアが含まれている場合、算出したデバイスＩＤがデバイスＩＤデータベース３４内になく、端末危険度スコアがデバイスＩＤデータベース３４から取得されなかったのであれば、端末危険度スコアとして所定の初期値を用いて取引危険度スコアを算出しても良い。その場合の初期値は、例えば、過去に不正な取引がなかったことを示す不正フラグ＝０であっても良い。また、端末危険度スコアが多値的な場合、過去に不正な取引があった場合と、過去の取引において不正が一度も無かった場合との中間的な値を初期値として設定すればよい。
【００６９】
本実施形態においては上述した以外にも様々な変形が可能である。
【００７０】
例えば、本実施形態の変形例として、デバイスＩＤデータベース３４に蓄積されるデバイスＩＤ毎の不正フラグ（端末危険度レベル）に信頼度を付与することにしても良い。図８は、デバイスＩＤデータベース３４のデータ構成の変形例を示す図である。図８を参照すると、デバイスＩＤに付与されている不正フラグに対して不正フラグ信頼度が設定されている。不正フラグ信頼度は、不正フラグがそのデバイスＩＤについての情報を表わしている程度を表わす情報である。不正が発覚した取引においてデバイスＩＤが完全一致でマッチングが取れた場合には、緩和されたマッチング条件でマッチングが取れた場合よりも不正フラグ信頼度を高く設定すればよい。また、不正フラグが設定されてからの経過時間に応じて不正フラグ信頼度が徐々に低下することにしても良い。また、不正フラグを端末危険度スコアとして利用する場合、あるいは不正フラグを取引危険度スコアの算出に利用する場合、不正フラグ信頼度に応じて重みづけを行っても良い。例えば、不正フラグと不正フラグ信頼度とを乗算した値を端末危険度スコアとしても良い。また、不正フラグと不正フラグ信頼度とを乗算した値を取引危険度スコアの演算式の中で用いても良い。
【００７１】
また、本実施形態の変形例として、データ処理部３１で算出したデバイスＩＤと、デバイスＩＤデータベース３４に蓄積されているデバイスＩＤとのマッチング処理において、端末危険度スコアの高い（例えば不正フラグ＝１）デバイスＩＤとのマッチングでは、端末危険度スコアの低い（例えば不正フラグ＝０）デバイスＩＤとのマッチングよりも緩和されたマッチング条件を用いることにしても良い。これによれば、端末危険度スコアが高く、不正の恐れが強いデバイスＩＤについては、広めにマッチングが取れるので、取引実行の確定可否の判定において、より警戒することが可能となる。また、その場合、端末危険度スコアの高いデバイスＩＤについて、端末危険度スコアを利用するに際し、マッチングの程度に応じた重みづけを行った値を用いても良い。例えば、完全一致でマッチングが取れた場合には、デバイスＩＤデータベース３４に設定されている端末危険度スコアの値をそのまま用い、緩和されたマッチング条件でマッチングが取れた場合には、デバイスＩＤデータベース３４に設定されている端末危険度スコアに１未満の重みを乗算した値を用いることが考えられる。
【００７２】
（変形例１）
変形例１について説明する。変形例１は、デバイスＩＤの算出に用いる複数のデバイスデータの組み合わせが互いに異なる複数の算出アルゴリズムで複数種類のデバイスＩＤ１〜ｎを常時算出しており、複数のクライアントＰＣ１３にわたるトレンドとして、あるデバイスデータが変化するデータ変化期間には、変化するデバイスデータを含まない算出アルゴリズムで算出されたデバイスＩＤの一致あるいは不一致によって、マッチング判定をするという例である。
【００７３】
ここでは、デバイスＩＤサーバ１２において、データ処理部３１は、１回の取引において、１つのクライアントＰＣ１３から、７種類のデバイスデータＤＤ１〜ＤＤ７を取得する。また、データ処理部３１は、その取引のそのクライアントＰＣ１３について、７つのデバイスデータＤＤ１〜ＤＤ７を使って、３つのデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３を生成するものとする。デバイスＩＤ  ＤＩＤ１〜ＤＩＤ３の生成式は以下の式（１）〜（３）の通りであるとする。
ＤＩＤ１＝Ｆ１（ＤＤ１，ＤＤ２，ＤＤ３）  …（１）
ＤＩＤ２＝Ｆ２（ＤＤ４，ＤＤ５，ＤＤ６）  …（２）
ＤＩＤ３＝Ｆ３（ＤＤ４，ＤＤ７，ＤＤ１）  …（３）
【００７４】
データ処理部３１は、取引単位でデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３を算出してデバイスＩＤデータベース３４に蓄積するのとは別に、取得したデバイスデータＤＤ１〜ＤＤ７を顧客ＩＤ毎に一定期間分蓄積する。そして、データ処理部３１は、複数の顧客ＩＤのデバイスデータＤＤ１〜ＤＤ７の変化を調べ、多数の顧客ＩＤにおいて特定のデバイスデータが同時期に変化していれば、その後の一定期間をそのデバイスデータのデータ変化期間と設定する。例えば、所定時間内に所定数あるいは所定割合以上の顧客ＩＤにて変化しているデバイスデータについては、その前後一定時間をそのデバイスデータのデータ変化期間と設定すればよい。
【００７５】
データ処理部３１が新たな取引でデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３を算出したら、端末危険度スコア処理部３３が、算出されたデバイスＩＤと、デバイスＩＤデータベース３４内のデバイスＩＤとのマッチングをとる。そのとき、端末危険度スコア処理部３３は、データ変化期間に該当するデバイスデータを用いずに算出されたデバイスＩＤによってマッチングをとる。例えば、ＤＩＤ１とＤＩＤ３の両方の生成に用いられているＤＤ１がデータ変化期間に該当していれば、端末危険度スコア処理部３３はマッチングにＤＩＤ２を用いる。
【００７６】
（変形例２）
変形例２について説明する。変形例２は、デバイスＩＤの算出に用いる複数のデバイスデータの組み合わせが互いに異なる複数の算出アルゴリズムで複数種類のデバイスＩＤ１〜ｎを常時算出しており、あるデバイスＩＤが変化するデータ変化期間には、それとは異なる算出アルゴリズムで算出したデバイスＩＤの一致あるいは不一致によって、マッチング判定をするという例である。
【００７７】
ここでも、デバイスＩＤサーバ１２において、データ処理部３１は、１つのクライアントＰＣ１３について７種類のデバイスデータＤＤ１〜ＤＤ７を取得する。また、データ処理部３１は、１つのクライアントＰＣ１３について、７つのデバイスデータＤＤ１〜ＤＤ７を使って、３つのデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３を生成するものとする。デバイスＩＤ  ＤＩＤ１〜ＤＩＤ３の生成式は上記の式（１）〜（３）の通りであるとする。
【００７８】
データ処理部３１は、取引単位でデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３を算出してデバイスＩＤデータベース３４に蓄積する。その際、データ処理部３１は、一定期間分のデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３をデバイスＩＤデータベース３４に保持する。更に、データ処理部３１は、多数の顧客ＩＤにおいて特定のデバイスＩＤが同時期に変化していれば、その前後の一定期間をそのデバイスＩＤのデータ変化期間と設定する。例えば、所定時間内に所定数あるいは所定割合以上の顧客ＩＤにて変化しているデバイスＩＤについては、その前後一定時間をそのデバイスＩＤのデータ変化期間と設定すればよい。ここでは、デバイスＩＤ  ＤＩＤ２とＤＩＤ３がデータ変化期間であると設定されるものとする。
【００７９】
データ処理部３１が新たな取引でデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３を算出したら、端末危険度スコア処理部３３が、算出されたデバイスＩＤと、デバイスＩＤデータベース３４内のデバイスＩＤとのマッチングをとる。そのとき、端末危険度スコア処理部３３は、データ変化期間に該当しないデバイスＩＤによってマッチングをとる。ここでは、ＤＩＤ２とＤＩＤ３がデータ変化期間に該当しているので、端末危険度スコア処理部３３はマッチングにＤＩＤ１を用いる。
【００８０】
（変形例３）
変形例３について説明する。変形例３は、デバイスＩＤの算出に用いる複数のデバイスデータの組み合わせが互いに異なる複数の算出アルゴリズムで複数種類のデバイスＩＤ１〜ｎを常時算出し、全てのデバイスＩＤ１〜ｎをそれぞれにマッチング判定し、その結果に基づいて、デバイスＩＤ群として一致か不一致か、つまりクライアントＰＣ１３として一致か不一致かを判定する例である。
【００８１】
図９は、変形例３におけるデバイスＩＤマッチングの処理を示すフローチャートである。
【００８２】
ここでも、デバイスＩＤサーバ１２において、データ処理部３１は、１つのクライアントＰＣ１３について７種類のデバイスデータＤＤ１〜ＤＤ７を取得する。また、データ処理部３１は、１つのクライアントＰＣ１３について、７つのデバイスデータＤＤ１〜ＤＤ７を使って、３つのデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３を生成するものとする。デバイスＩＤ  ＤＩＤ１〜ＤＩＤ３の生成式は上記の式（１）〜（３）の通りであるとする。
【００８３】
図９を参照すると、まず、端末危険度スコア処理部３３は、全ての処理対象デバイスＩＤのマッチング判定を行う（ステップＴ１）。通常時には、全てのデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３がマッチング処理対象となる。全ての処理対象のデバイスＩＤが一致した場合のみ（ステップＴ２のＹｅｓ）、端末危険度スコア処理部３３はデバイスＩＤ群として一致と判断する（ステップＴ３）。
【００８４】
いずれか１つでも不一致のデバイスＩＤがあれば（ステップＴ２のＮｏ）、端末危険度スコア処理部３３はデバイスＩＤ群としては不一致と判断する（ステップＴ４）。その場合、端末危険度スコア処理部３３はどのデバイスＩＤが不一致であったかの履歴を記録する（ステップＴ５）。例えば、デバイスＩＤ群のうち所定個（例えば１個）以下のデバイスＩＤだけが不一致であり、他の全てのデバイスが一致であった場合に、不一致であったデバイスＩＤを履歴に記録することにすればよい。
【００８５】
所定個が１個である例では、あるデバイスＩＤ群の照合において１つのデバイスＩＤが不一致となっても、そのデバイスＩＤ群の照合を終了せず、次にデバイスＩＤの照合に移行し、不一致のデバイスＩＤが２個目になったらそのデバイスＩＤ群の照合を終了する。不一致のデバイスＩＤが１個でその他のデバイスＩＤが全て一致したデバイスＩＤ群は履歴に記録する候補として保持し、全てのデバイスＩＤが一致するデバイスＩＤ群が見つからなければ、保持しておいたデバイスＩＤ群の不一致であったデバイスＩＤを履歴に記録する。
【００８６】
ステップＴ３あるいはＴ５の後、端末危険度スコア処理部３３は、履歴において一定期間内の不一致の発生数が所定の閾値より多いデバイスＩＤがあるか否か判定する（ステップＴ６）。一定期間内の不一致の発生数が所定の閾値より多いデバイスＩＤがあれば、端末危険度スコア処理部３３は、そのデバイスＩＤを処理対象から除外して（ステップＴ７）、ステップＴ１に戻り、次は、それ以外のデバイスＩＤを対象としてマッチング判定を行う。
【００８７】
一方、一定期間内の不一致の発生数が所定の閾値より多いデバイスＩＤが無ければ、端末危険度スコア処理部３３は、全てのデバイスＩＤ  ＤＩＤ１〜ＤＩＤ３を処理対象として（ステップＴ８）、ステップＴ１に戻り、次は、全てのデバイスＩＤを対象としてマッチング判定を行う。
【００８８】
上述した本発明の実施形態および変形例は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態等にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【００８９】
例えば、上述においては、取引サービスサーバ１１とデバイスＩＤサーバ１２とが別々の装置として存在する例を示したが、本発明がその構成に限定されることは無い。他の例として、取引サービスサーバ１１とデバイスＩＤサーバ１２とが物理的には一つの装置に実装されていても良い。
【符号の説明】
【００９０】
１１…取引サービスサーバ、１２…デバイスＩＤサーバ、１３…クライアントＰＣ、１５…インターネット、２１…データ取得部、２２…取引処理部、３１…データ処理部、３２…取引危険度スコア処理部、３３…端末危険度スコア処理部、３４…デバイスＩＤデータベース
【図１】
2014010526.tif 000003
【図２】
2014010526.tif 000004
【図３】
2014010526.tif 000005
【図４】
2014010526.tif 000006
【図５】
2014010526.tif 000007
【図６】
2014010526.tif 000008
【図７】
2014010526.tif 000009
【図８】
2014010526.tif 000010
【図９】
2014010526.tif 000011