特許 6967575 信用度計算システム、信用度計算方法、及びプログラム

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

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

(11)【特許番号】6967575

(24)【登録日】2021年10月27日

(45)【発行日】2021年11月17日

(54)【発明の名称】信用度計算システム、信用度計算方法、及びプログラム

(51)【国際特許分類】

   G06Q 20/40 20120101AFI20211108BHJP

   G06Q 40/02 20120101ALI20211108BHJP

   G06Q 30/02 20120101ALI20211108BHJP

【ＦＩ】

   G06Q20/40

   G06Q40/02

   G06Q30/02 352

【請求項の数】14

【全頁数】23

(21)【出願番号】特願2019-236804(P2019-236804)

(22)【出願日】2019年12月26日

(65)【公開番号】特開2021-105840(P2021-105840A)

(43)【公開日】2021年7月26日

【審査請求日】2020年5月22日

(73)【特許権者】

【識別番号】399037405

【氏名又は名称】楽天グループ株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】特許業務法人はるか国際特許事務所

(72)【発明者】

【氏名】友田 恭輔

【審査官】 萩島 豪

(56)【参考文献】

【文献】 特開２０１９−０２０９９６（ＪＰ，Ａ）

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

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

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

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

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

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

【請求項1】

サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算手段と、
過去における前記ユーザによる前記サービスの利用状況に基づいて、将来に予測される前記ユーザの利用額を計算する利用額計算手段と、
前記不正度と将来に予測される前記利用額とに基づいて、将来に予測される前記ユーザの信用度を計算する信用度計算手段と、
を含む信用度計算システム。

【請求項2】

サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算手段と、
前記ユーザによる前記サービスの利用状況に基づいて、前記ユーザの利用額を計算する利用額計算手段と、
前記不正度と前記利用額とに基づいて、前記ユーザの信用度を計算する信用度計算手段と、
を含み、
前記不正度計算手段は、過去に行われた行動に基づく前記不正度と、当該行動が実際に不正であったか否かの確定結果と、に基づいて、前記不正度の計算における重み付け係数を決定し、当該決定された重み付け係数に基づいて、前記不正度を計算する、
信用度計算システム。

【請求項3】

前記不正度計算手段は、実際に不正であるか否かが確定した行動が学習された学習モデルに基づいて、不正であるか否かが確定していない行動の前記不正度を計算する、
請求項１又は２に記載の信用度計算システム。

【請求項4】

前記利用額計算手段は、前記ユーザにより登録されたユーザ情報と、前記ユーザによる他のサービスの利用状況と、の少なくとも一方に更に基づいて、前記利用額を計算する、
請求項１〜３の何れかに記載の信用度計算システム。

【請求項5】

前記信用度計算手段は、前記信用度として、前記ユーザからの利益の期待値を計算する、
請求項１〜４の何れかに記載の信用度計算システム。

【請求項6】

前記不正度計算手段は、所定の期間における複数の前記行動の各々に基づいて、各行動の個別不正度を計算し、各行動の個別不正度に基づいて、前記期間における前記ユーザの全体不正度を計算し、
前記信用度計算手段は、前記全体不正度と前記利用額とに基づいて、前記信用度を計算する、
請求項１〜５の何れかに記載の信用度計算システム。

【請求項7】

前記不正度計算手段は、各行動が行われた時点からの経過時間に更に基づいて、前記全体不正度を計算する、
請求項６に記載の信用度計算システム。

【請求項8】

前記不正度計算手段は、前記ユーザの認証方法と、前記ユーザの名義人と、の少なくとも一方に更に基づいて、前記不正度を計算する、
請求項１〜７の何れかに記載の信用度計算システム。

【請求項9】

前記信用度計算システムは、前記信用度に応じた処理を実行する実行手段、
を更に含む請求項１〜８の何れかに記載の信用度計算システム。

【請求項10】

前記処理は、前記サービスに関するクーポンを前記ユーザに付与する処理である、
請求項９に記載の信用度計算システム。

【請求項11】

サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算ステップと、
過去における前記ユーザによる前記サービスの利用状況に基づいて、将来に予測される前記ユーザの利用額を計算する利用額計算ステップと、
前記不正度と将来に予測される前記利用額とに基づいて、将来に予測される前記ユーザの信用度を計算する信用度計算ステップと、
を含む信用度計算方法。

【請求項12】

サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算ステップと、
前記ユーザによる前記サービスの利用状況に基づいて、前記ユーザの利用額を計算する利用額計算ステップと、
前記不正度と前記利用額とに基づいて、前記ユーザの信用度を計算する信用度計算ステップと、
を含み、
前記不正度計算ステップは、過去に行われた行動に基づく前記不正度と、当該行動が実際に不正であったか否かの確定結果と、に基づいて、前記不正度の計算における重み付け係数を決定し、当該決定された重み付け係数に基づいて、前記不正度を計算する、
信用度計算方法。

【請求項13】

サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算手段、
過去における前記ユーザによる前記サービスの利用状況に基づいて、将来に予測される前記ユーザの利用額を計算する利用額計算手段、
前記不正度と将来に予測される前記利用額とに基づいて、将来に予測される前記ユーザの信用度を計算する信用度計算手段、
としてコンピュータを機能させるためのプログラム。

【請求項14】

サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算手段、
前記ユーザによる前記サービスの利用状況に基づいて、前記ユーザの利用額を計算する利用額計算手段、
前記不正度と前記利用額とに基づいて、前記ユーザの信用度を計算する信用度計算手段、
としてコンピュータを機能させるためのプログラムであって、
前記不正度計算手段は、過去に行われた行動に基づく前記不正度と、当該行動が実際に不正であったか否かの確定結果と、に基づいて、前記不正度の計算における重み付け係数を決定し、当該決定された重み付け係数に基づいて、前記不正度を計算する、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、信用度計算システム、信用度計算方法、及びプログラムに関する。

【背景技術】

【0002】

従来、サービスを利用するユーザの行動を解析し、ユーザの信用度を計算する技術が知られている。例えば、特許文献１には、ユーザの就寝時刻や起床時刻といった行動履歴の情報を継続的に取得し、当該取得した行動履歴の情報と、ユーザのライフスタイル、性格、及び嗜好といったパラメータと、に基づいて、ユーザの信用度（信用スコア）を計算するシステムが記載されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第６５１４８１３号公報

【発明の概要】

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

【0004】

しかしながら、信用度の計算精度には限界があり、例えば、決済サービスにおける利用額が高いユーザの信用度が低く計算されることがある。例えば特許文献１の技術では、ユーザの利用額は何ら考慮されておらず、利用額が高いユーザの信用度が低く計算されることがある。利用額が高いユーザの信用度が低く計算され、利用が制限されると、決済サービスにおける収益が低下する可能性がある。一方、利用額が高いというだけで、ユーザを無条件で優遇すると、不正な利用を止めることができない可能性があり、セキュリティが低下する。

【0005】

本発明は上記課題に鑑みてなされたものであって、その目的は、収益性とセキュリティを両立することが可能な信用度計算システム、信用度計算方法、及びプログラムを提供することである。

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

【0006】

上記課題を解決するために、本発明の一態様に係る信用度計算システムは、サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算手段と、前記ユーザによる前記サービスの利用状況に基づいて、前記ユーザの利用額を計算する利用額計算手段と、前記不正度と前記利用額とに基づいて、前記ユーザの信用度を計算する信用度計算手段と、を含む。

【0007】

本発明の一態様に係る信用度計算方法は、サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算ステップと、前記ユーザによる前記サービスの利用状況に基づいて、前記ユーザの利用額を計算する利用額計算ステップと、前記不正度と前記利用額とに基づいて、前記ユーザの信用度を計算する信用度計算ステップと、を含む。

【0008】

本発明の一態様に係るプログラムは、サービスを利用するユーザの行動に基づいて、前記ユーザの不正度を計算する不正度計算手段、前記ユーザによる前記サービスの利用状況に基づいて、前記ユーザの利用額を計算する利用額計算手段、前記不正度と前記利用額とに基づいて、前記ユーザの信用度を計算する信用度計算手段、としてコンピュータを機能させる。

【0009】

本発明の一態様によれば、前記利用額計算手段は、過去における前記利用状況に基づいて、将来に予測される前記利用額を計算し、前記信用度計算手段は、前記不正度と将来に予測される前記利用額とに基づいて、将来に予測される前記ユーザの信用度を計算する。

【0010】

本発明の一態様によれば、前記不正度計算手段は、実際に不正であるか否かが確定した行動が学習された学習モデルに基づいて、不正であるか否かが確定していない行動の前記不正度を計算する。

【0011】

本発明の一態様によれば、前記利用額計算手段は、前記ユーザにより登録されたユーザ情報と、前記ユーザによる他のサービスの利用状況と、の少なくとも一方に更に基づいて、前記利用額を計算する。

【0012】

本発明の一態様によれば、前記信用度計算手段は、前記信用度として、前記ユーザからの利益の期待値を計算する。

【0013】

本発明の一態様によれば、前記不正度計算手段は、所定の期間における複数の前記行動の各々に基づいて、各行動の個別不正度を計算し、各行動の個別不正度に基づいて、前記期間における前記ユーザの全体不正度を計算し、前記信用度計算手段は、前記全体不正度と前記利用額とに基づいて、前記信用度を計算する。

【0014】

本発明の一態様によれば、前記不正度計算手段は、各行動が行われた時点からの経過時間に更に基づいて、前記全体不正度を計算する。

【0015】

本発明の一態様によれば、前記不正度計算手段は、過去に行われた行動に基づく前記不正度と、当該行動が実際に不正であったか否かの確定結果と、に基づいて、前記不正度の計算における重み付け係数を決定し、当該決定された重み付け係数に基づいて、前記不正度を計算する。

【0016】

本発明の一態様によれば、前記不正度計算手段は、前記ユーザの認証方法と、前記ユーザの名義人と、の少なくとも一方に更に基づいて、前記不正度を計算する。

【0017】

本発明の一態様によれば、前記信用度計算システムは、前記信用度に応じた処理を実行する実行手段、を更に含む。

【0018】

本発明の一態様によれば、前記処理は、前記サービスに関するクーポンを前記ユーザに付与する処理である。

【発明の効果】

【0019】

本発明によれば、収益性とセキュリティを両立することができる。

【図面の簡単な説明】

【0020】

【図1】信用度計算システムの全体構成を示す図である。

【図2】信用度の計算方法の概要を示す図である。

【図3】信用度計算システムで実現される機能の一例を示す機能ブロック図である。

【図4】ユーザデータベースのデータ格納例を示す図である。

【図5】利用状況データベースのデータ格納例を示す図である。

【図6】信用度データベースのデータ格納例を示す図である。

【図7】サービス利用処理の一例を示すフロー図である。

【図8】信用度計算処理の一例を示すフロー図である。

【図9】変形例（２）の概要を示す図である。

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

【0021】

［１．信用度計算システムの全体構成］
以下、本発明に係る信用度計算システムの実施形態の例を説明する。図１は、信用度計算システムの全体構成を示す図である。図１に示すように、信用度計算システムＳは、サーバ１０とユーザ端末２０を含み、これらは、インターネットなどのネットワークＮに接続可能である。なお、図１では、サーバ１０とユーザ端末２０の各々を１台ずつ示しているが、これらは複数台あってもよい。

【0022】

サーバ１０は、サーバコンピュータである。サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。制御部１１は、記憶部１２に記憶されたプログラムやデータに従って処理を実行する。記憶部１２は、主記憶部及び補助記憶部を含む。例えば、主記憶部はＲＡＭなどの揮発性メモリであり、補助記憶部は、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又はハードディスクなどの不揮発性メモリである。通信部１３は、有線通信又は無線通信用の通信インタフェースであり、ネットワークＮを介してデータ通信を行う。

【0023】

ユーザ端末２０は、ユーザが操作するコンピュータである。例えば、ユーザ端末２０は、携帯電話機（スマートフォンを含む）、携帯情報端末（タブレット型コンピュータを含む）、又はパーソナルコンピュータ等である。本実施形態では、ユーザ端末２０は、制御部２１、記憶部２２、通信部２３、操作部２４、及び表示部２５を含む。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

【0024】

操作部２４は、入力デバイスであり、例えば、タッチパネルやマウス等のポインティングデバイス、キーボード、又はボタン等である。操作部２４は、ユーザによる操作内容を制御部２１に伝達する。表示部２５は、例えば、液晶表示部又は有機ＥＬ表示部等である。表示部２５は、制御部２１の指示に従って画像を表示する。

【0025】

なお、記憶部１２，２２に記憶されるものとして説明するプログラム及びデータは、ネットワークＮを介して供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）や外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）が含まれていてもよい。例えば、情報記憶媒体に記憶されたプログラムやデータが読取部や入出力部を介して供給されるようにしてもよい。

【0026】

［２．信用度計算システムの概要］
ユーザは、ユーザ端末２０を操作し、サーバ１０が提供するサービスを利用する。本実施形態では、サービスの一例として、決済サービスを説明する。例えば、実店舗における商品の購入時、実店舗におけるサービスの利用時、インターネットを利用した商品の購入時、又は、インターネットを利用したサービスの予約時において、本サービスを利用した決済が実行される。

【0027】

本実施形態では、決済の一例として、クレジットカード決済を説明するが、決済は、種々のタイプの決済を利用可能である。例えば、電子マネー決済、仮想通貨決済、ウォレット決済、ポイント決済、デビットカード決済、又は口座振替決済であってもよい。更に、これらの決済を実現する方法についても、種々の手法を利用可能である。例えば、ユーザ端末２０に含まれるＩＣチップを利用して決済が実現されてもよいし、ユーザ端末２０又は店舗の端末等に表示された一次元又は二次元コードを利用して決済が実現されてもよい。

【0028】

なお、ユーザは、ユーザ端末２０を操作せずに、サービスを利用してもよい。例えば、ユーザは、実店舗の端末に、クレジットカードやＩＣカード等の媒体を読み込ませることによって、サービスを利用してもよい。また例えば、ユーザは、これらの媒体を利用せずに、生体認証を利用することによって、サービスを利用してもよい。

【0029】

本実施形態では、サーバ１０は、サービスを利用する全てのユーザの決済の履歴を記憶する。サーバ１０は、ユーザごとに、決済の履歴や他の要素に基づいて信用度を計算する。信用度は、ユーザに対する信用の高さを示す情報である。別の言い方をすれば、信用度は、ユーザを信用できる蓋然性を示す情報である。本実施形態では、信用度が将来における信用の推測値を示す場合を説明するが、信用度は、過去の信用の実績値を示してもよい。

【0030】

本実施形態では、スコアによって信用度が表現される場合を説明するが、信用度は、他の指標によって表現されてもよい。例えば、信用度は、スコア以外の数値である確率（パーセンテージ）によって表現されてもよいし、Ｓランク・Ａランク・Ｂランクといった文字によって表現されてもよい。信用度が数値によって表現される場合には、数値が高いほど信用の度合いが高いことを意味する。信用度が文字によって表現される場合には、個々の文字に信用の順位が定められているものとする。

【0031】

なお、本実施形態のサービスの提供者は、あくまで決済サービスを提供しているだけであり、クレジットカード会社そのものではないものとする。支払い自体は、クレジットカード会社で保証することなので、本実施形態の信用は、ユーザの支払い能力ではなく、サービスを正常に利用することに関連する。例えば、信用は、ユーザが優待されてもサービスを不正せずに（正常に）利用することに関連する。信用度は、サービスとしてユーザを信用できるか否かを示す情報ということもできる。

【0032】

図２は、信用度の計算方法の概要を示す図である。図２の例では、現時点が２０１９年１１月３０日であり、２０１９年におけるユーザＡの決済の履歴が示されている。図２では、決済の履歴として、個々の決済の利用日（実行日）と、その時の利用額（決済額）と、が示されている。個々の決済は、トランザクションと呼ばれることもある。

【0033】

本実施形態では、決済が実行された後に、所定の確定タイミングが訪れると、当該決済が実際に不正であるか否か（不正であるか正常であるか）が確定する。本実施形態では、確定タイミングを利用日から３ヶ月後とするが、確定タイミングは、任意のタイミングであってよい。例えば、確定タイミングは、予め定められた日付（例えば、毎月１５日）であってもよいし、サービスの管理者が不正の有無を判断する業務をする時であってもよい。他にも例えば、確定タイミングは、ユーザから不正決済の疑いの報告を受けた時であってもよい。例えば、確定タイミングが訪れると、後述する不正度に基づいて仮の確定結果が取得され、管理者に提示される。仮の確定結果は、不正度が閾値以上であれば不正となり、不正度が閾値未満であれば正常となる。管理者は、仮の確定結果をチェックし、誤りがあれば修正する。管理者による修正によって、決済が不正であるか正常であるかが確定する。

【0034】

図２の例では、２０１９年８月末までの決済は、確定タイミングが訪れているので、不正であるか否かが確定している。図２では、不正ではないことが確定した決済（正常であることが確定した決済）の不正度を、０％と示している。不正であることが確定した決済（正常ではないことが確定した決済）が存在すれば、不正度は１００％となる。一方、２０１９年９月以降の決済は、確定タイミングが訪れていないので、不正であるか否かが確定していない。以降、不正であるか否かが確定した決済を確定済み決済と記載し、不正であるか否かが確定していない決済を未確定決済と記載する。

【0035】

サーバ１０は、未確定決済については、学習モデルを利用して不正度を計算する。例えば、決済処理が実行されると、リアルタイムで不正度が計算される。学習モデルは、機械学習で用いられるモデルであり、確定済み決済の内容（例えば、利用額及び利用日時）と、不正であるか否かの確定結果と、の関係を学習している。機械学習自体は、公知の種々の手法を利用可能であり、例えば、ニューラルネットワーク、強化学習、又は深層学習といった手法を利用可能である。機械学習は、教師有り機械学習に限られず、半教師有り機械学習が用いられてもよいし、教師無し機械学習が用いられてもよい。

【0036】

不正度は、不正の度合いを示す情報である。別の言い方をすれば、不正度は、不正の疑いの高さを示す情報である。本実施形態では、確率（パーセンテージ）によって不正度が表現される場合を説明するが、不正度は、他の指標によって表現されてもよい。例えば、不正度は、確率以外の数値であるスコアによって表現されてもよいし、Ｓランク・Ａランク・Ｂランクといった文字によって表現されてもよい。不正度が数値によって表現される場合には、数値が高いほど不正の度合いが高いことを意味する。不正度が文字によって表現される場合には、個々の文字に不正の順位が定められているものとする。

【0037】

サーバ１０は、未確定決済の内容を学習モデルに入力し、学習モデルから出力された不正度を取得する。学習モデルは、自身に入力された決済の内容に応じた不正度を出力するようになっているので、不正度は、学習モデルが計算した不正の蓋然性ということもできる。図２の例であれば、２０１９年９月３日に行われた６５００円の未確定決済については、０．２０％の不正度が計算されている。すなわち、この未確定決済は、０．２０％の確率で不正であることが推定されている。他の日の未確定決済についても同様に、サーバ１０は、学習モデルを利用して、未確定決済ごとに不正度を計算する。

【0038】

未確定決済の不正度が高いユーザは、今後も不正と疑われる決済を継続する可能性がある。このため、このユーザによるサービスの利用を制限することが考えられる。しかしながら、学習モデルの精度には限界があり、多額の利用をすると思われるユーザの不正度が高く計算されてしまうと、将来得られる利益を逃す可能性がある。一方、このようなユーザを無条件で優遇すると、不正利用に対応できない可能性があり、セキュリティが低下する。

【0039】

そこで、信用度計算システムＳは、学習モデルが出力した不正度と、将来利用すると予測される利用額と、を総合的に判断し、ユーザの信用度を計算する。信用度は、不正度と関連する概念であるが、利用額も考慮される点で不正度とは異なる。先述したように、信用度は、サービスとしてのユーザに対する信用の度合いを示し、個々の決済の不正の度合いとは異なる。このため、ユーザの不正度がある程度高かったとしても、利用額が非常に多ければ、そのユーザの信用度は高くなることがある。一方、ユーザの不正度が低かったとしても、利用額が非常に低ければ、そのユーザの信用度は低くなることがある。

【0040】

例えば、サーバ１０は、ユーザＡの各未確定決済の不正度に基づいて、現時点における総合的な不正度を計算する。以降、個々の未確定決済の不正度を個別不正度と記載し、総合的な不正度を全体不正度と記載する。全体不正度の計算方法については、後述する。図２の例では、ユーザＡの全体不正度は、０．５３％である。

【0041】

また例えば、サーバ１０は、過去におけるユーザＡのサービスの利用状況と、ユーザの性別や年収等の情報と、に基づいて、今後ｎヶ月（ｎは任意の正数）で予測されるユーザＡの利用額を計算する。利用額の計算方法についても後述する。図２の例では、今後ｎヶ月で予測されるユーザＡの利用額は、８２４５０円である。本実施形態では、この利用額が今後ｎヶ月における合計値である場合を説明するが、利用額は、今後ｎヶ月において予測される個々の決済の利用額であってもよい。例えば、今後ｎヶ月でユーザＡが１０回の決済をすることが予測される場合、個々の決済の利用額として、８２４５円が計算されてもよい。

【0042】

サーバ１０は、全体不正度である０．５３％と、今後ｎヶ月で予測される利用額である８２４５０円と、を所定の計算式に代入し、ユーザＡの信用度を計算する。図２の例では、ユーザＡの信用度は、２０３６ポイントとなる。例えば、この数値は、今後ｎヶ月におけるユーザＡからの利益の予測値を示す。サーバ１０は、ユーザの信用度に応じてクーポン等の優待を付与する。

【0043】

以上のように、本実施形態の信用度計算システムＳは、学習モデルにより出力された不正度と、サービスの利用状況等をもとに計算された利用額と、が総合的に考慮された信用度を計算することによって、収益性とセキュリティのバランスを保ち、これらを両立するようにしている。以降、この技術の詳細を説明する。

【0044】

［３．信用度計算システムにおいて実現される機能］
図３は、信用度計算システムＳで実現される機能の一例を示す機能ブロック図である。図３に示すように、サーバ１０では、データ記憶部１００、不正度計算部１０１、利用額計算部１０２、信用度計算部１０３、及び実行部１０４が実現される。

【0045】

[３−１．データ記憶部]
データ記憶部１００は、記憶部１２を主として実現される。データ記憶部１００は、ユーザの信用度を計算するために必要なデータを記憶する。ここでは、データ記憶部１００が記憶するデータの一例として、ユーザデータベースＤＢ１、利用状況データベースＤＢ２、及び信用度データベースＤＢ３について説明する。

【0046】

図４は、ユーザデータベースＤＢ１のデータ格納例を示す図である。図４に示すように、ユーザデータベースＤＢ１は、ユーザに関する各種情報が格納されたデータベースである。例えば、ユーザデータベースＤＢ１には、ユーザＩＤ、ユーザ名、認証情報、及び決済情報が格納される。ユーザＩＤは、ユーザを一意に識別する情報である。ユーザ名は、ユーザの氏名である。

【0047】

認証情報は、認証時の正解（インデックス）となる情報である。認証自体は、種々のタイプの認証を利用可能であり、例えば、パスワード認証、証明書認証、又は生体認証を利用可能である。認証は、１段階であってもよいし、２段階以上であってもよい。ユーザがどの認証を利用するかを指定できるようにしてもよい。

【0048】

決済情報は、決済に必要な情報である。本実施形態では、クレジットカード決済が行われるので、決済情報には、ユーザが登録したクレジットカード番号、名義人、及び有効期限などの情報が含まれる。複数のクレジットカードの各々の決済情報が登録されてもよい。決済情報は、サービスで利用される決済のタイプに応じた情報が登録されるようにすればよく、例えば、電子マネー決済であればユーザのアカウント情報や残高情報等が登録される。他の決済についても同様であり、決済に必要な情報が登録される。ユーザが複数のタイプの決済を併用する場合には、各タイプの決済情報が登録されてもよい。

【0049】

ユーザがサービスの利用登録をすませると、サーバ１０は、所定の発行ルールに基づいて、当該ユーザのユーザＩＤを発行する。サーバ１０は、ユーザデータベースＤＢ１に新たなレコードを作成し、当該発行されたユーザＩＤとともに、利用登録時に指定されたユーザ名、認証情報、及び決済情報を格納する。認証情報及び決済情報については、事後的に変更可能である。

【0050】

図５は、利用状況データベースＤＢ２のデータ格納例を示す図である。図５に示すように、利用状況データベースＤＢ２は、ユーザによるサービスの利用状況が格納されたデータベースである。例えば、利用状況データベースＤＢ２には、決済ＩＤ、支払先ＩＤ、ユーザＩＤ、利用額、利用日時、及び個別不正度が格納される。

【0051】

なお、本実施形態では、確定済み決済と未確定決済の両方が利用状況データベースＤＢ２に格納される場合を説明するが、確定済み決済又は未確定決済の何れか一方のみが利用状況データベースＤＢ２に格納されてもよい。また、利用状況データベースＤＢ２には、他の情報が格納されてもよく、例えば、後述する利用額の計算に必要な利用状況が格納されていてもよい。

【0052】

決済ＩＤは、決済を一意に識別する情報である。支払先ＩＤは、支払先を一意に識別する情報である。実店舗の決済であれば、支払先ＩＤは実店舗を識別する情報となり、オンライン上の仮想の店舗の決済であれば、支払先ＩＤは仮想の店舗を識別する情報となる。利用額は、個々の決済における金額である。利用日時は、決済が実行された日時である。個別不正度は、個々の決済の不正度である。

【0053】

サーバ１０は、決済を実行するたびに、所定の発行ルールに基づいて、当該決済の決済ＩＤを発行する。サーバ１０は、利用状況データベースＤＢ２に新たなレコードを作成し、決済ＩＤ、支払先ＩＤ、ユーザＩＤ、利用額、及び利用日時を格納する。支払先ＩＤ、ユーザＩＤ、及び利用額は、決済時にサーバ１０が受信する決済要求に含まれているものとする。利用日時は、決済実行時の現在日時である。

【0054】

個別不正度は、後述する不正度計算部１０１によって格納される。本実施形態では、確定済み決済の個別不正度として、不正の有無の確定結果に応じて０％又は１００％の数値が格納される場合を説明するが、確定済み決済の個別不正度としては、当該確定済み決済が確定する前に計算された個別不正度（０％以上１００％以下の数値）が格納されていてもよい。

【0055】

図６は、信用度データベースＤＢ３のデータ格納例を示す図である。図６に示すように、信用度データベースＤＢ３は、ユーザの信用度が格納されたデータベースである。例えば、信用度データベースＤＢ３には、ユーザＩＤ、不正度計算部１０１により計算された全体不正度、利用額計算部１０２により計算された利用額、信用度計算部１０３により計算された信用度、及びクーポン情報が格納される。

【0056】

クーポン情報は、実行部１０４により付与されたクーポンに関する情報である。例えば、複数のクーポンが用意されている場合、クーポン情報は、ユーザに付与されたクーポンの種類を示す。クーポンに有効期限が設定されている場合、クーポン情報には、有効期限が含まれていてもよい。本実施形態では、信用度が閾値未満の場合にはクーポンが付与されないので、信用度が閾値未満のユーザについては、クーポン情報は格納されない。

【0057】

なお、データ記憶部１００に記憶されるデータは、上記の例に限られない。例えば、データ記憶部１００は、学習モデルのプログラム（アルゴリズム）やパラメータを記憶する。学習モデルには教師データが学習済みであり、学習モデルのパラメータは、調整済みであるものとする。例えば、教師データには、確定済み決済の内容を入力とし、不正の有無の確定結果を出力としたペアが多数格納されている。このペアの入力は、学習モデルに入力される決済の内容と同じデータ形式である。

【0058】

教師データの入力となる決済の内容は、決済の特徴を示す情報であり、例えば、利用額、利用場所、利用日時、及び、決済対象の商品又はサービスの種類のうちの少なくとも１つである。決済の内容は、利用状況データベースＤＢ２に格納されているものとする。本実施形態では、決済の内容の一例として、利用額と利用日時を説明する。教師データには、決済の内容として、利用額等の情報がそのまま格納されていてもよいし、ベクトル又は配列等で表現した特徴量が格納されていてもよい。

【0059】

教師データの出力となる確定結果は、不正であるか否かを示す情報であり、例えば、不正であることを示す１００％、又は、正常であることを示す０％の何れかの値となる。なお、確定結果は、これらの２値で表現されなければならないわけではなく、管理者が見ても不正であるか否かを断定できなかった決済については、３０％等の中間値が存在してもよい。また、確定結果は、数値で表現されなくてもよく、不正であるか否かを示す文字で表現されてもよい。

【0060】

教師データは、データ記憶部１００に記憶されていてもよいし、サーバ１０以外のコンピュータ又は情報記憶媒体に記憶されていてもよい。例えば、教師データは、管理者によって作成される。サーバ１０は、教師データに基づいて、学習モデルの学習処理を実行する。学習処理自体は、機械学習で用いられる種々の手法を適用可能であり、例えば、ニューラルネットワークにおける学習処理を利用可能である。サーバ１０は、教師データが示す入力と出力の関係が得られるように、学習モデルのパラメータを調整する。

【0061】

［３−２．不正度計算部］
不正度計算部１０１は、制御部１１を主として実現される。不正度計算部１０１は、サービスを利用するユーザの行動に基づいて、ユーザの不正度を計算する。不正度計算部１０１は、ユーザごとに、当該ユーザの行動に基づいて当該ユーザの不正度を計算する。不正度計算部１０１は、全てのユーザの不正度を計算してもよいし、一部のユーザの不正度を計算してもよい。

【0062】

行動は、サービスをどのように利用したかを示す情報である。行動は、サービスの利用内容、又は、サービス利用時の挙動ということもできる。本実施形態では、利用状況データベースＤＢ２に格納された利用額と利用日時がユーザの行動に相当する場合を説明するが、サービス利用時にサーバ１０に入力される他の情報が行動に相当してもよい。例えば、利用頻度、利用場所、決済対象の商品の種類、又は決済対象のサービスの種類といった情報が行動に相当してもよい。

【0063】

本実施形態では、不正度計算部１０１は、実際に不正であるか否かが確定した行動が学習された学習モデルに基づいて、不正であるか否かが確定していない行動の不正度を計算する。不正度計算部１０１は、ユーザの行動を示す情報（例えば、利用額と利用日時）を学習モデルに入力する。学習モデルは、入力された情報の特徴量を計算し、特徴量に応じた不正度を出力する。不正度計算部１０１は、学習モデルから出力された不正度を取得する。なお、特徴量は、学習モデル以外のアルゴリズムによって計算されてもよい。この場合、当該アルゴリズムによって計算された特徴量が学習モデルに入力される。

【0064】

例えば、不正度計算部１０１は、所定の期間における複数の行動の各々に基づいて、各行動の個別不正度を計算し、各行動の個別不正度に基づいて、この期間におけるユーザの全体不正度を計算する。この期間は、不正度の計算対象となる期間である。本実施形態では、この期間は、不正であるか否かが確定していない期間であり、直近３ヶ月である。なお、期間の長さは、３ヶ月に限られず、任意の長さを設定可能である。また、期間は、直近に限られず、直近の期間よりも前の期間であってもよい。

【0065】

例えば、不正度計算部１０１は、決済における利用額が高いほど個別不正度が高くなるように、個別不正度を計算する。また例えば、不正度計算部１０１は、決済における利用時間にばらつきがあるほど個別不正度が高くなるように、個別不正度を計算する。また例えば、不正度計算部１０１は、決済における利用頻度が高いほど個別不正度が高くなるように、個別不正度を計算する。また例えば、不正度計算部１０１は、決済における利用場所にばらつきがあるほど個別不正度が高くなるように、個別不正度を計算する。また例えば、不正度計算部１０１は、決済対象の商品又はサービスの種類にばらつきがあるほど個別不正度が高くなるように、個別不正度を計算する。

【0066】

不正度計算部１０１は、所定の期間における各行動の個別不正度を所定の計算式に代入し、全体不正度を計算する。この計算式は、個別不正度を代入すると、全体不正度が算出される式であればよい。本実施形態では、全体不正度が個別不正度の単純平均である場合を説明するが、後述する変形例のように、利用日時からの経過時間に応じた重み付けがされた加重平均であってもよいし、指数移動平均であってもよい。他にも例えば、計算式は、特に平均を算出するものでなくてもよい。

【0067】

なお、個別不正度は、予め定められた方法に基づいて計算されるようにすればよく、学習モデルを利用した例に限られない。例えば、不正度計算部１０１は、ユーザの行動を数値化し、所定の計算式に代入することによって、個別不正度を計算してもよい。また例えば、不正度計算部１０１は、ユーザの行動と個別不正度の関係を定義したプログラムコードに基づいて、個別不正度を計算してもよい。

【0068】

また、全体不正度についても、予め定められた方法に基づいて計算されるようにすればよく、計算式を利用した例に限られない。例えば、不正度計算部１０１は、個別不正度と全体不正度の関係を学習させた学習モデルを利用して、全体不正度を計算してもよい。また例えば、不正度計算部１０１は、個別不正度と全体不正度の関係を定義したプログラムコードに基づいて、全体不正度を計算してもよい。

【0069】

［３−３．利用額計算部］
利用額計算部１０２は、制御部１１を主として実現される。利用額計算部１０２は、ユーザによるサービスの利用状況に基づいて、ユーザの利用額を計算する。利用額計算部１０２は、ユーザごとに、当該ユーザの利用状況に基づいて当該ユーザの利用額を計算する。利用額計算部１０２は、全てのユーザの利用額を計算してもよいし、一部のユーザの利用額を計算してもよい。

【0070】

利用状況とは、サービスの利用結果である。別の言い方をすれば、利用状況は、過去のユーザの行動ということもできる。利用状況は、不正であるか否かが確定した行動であってもよいし、不正であるか否かが確定していない行動であってもよい。例えば、利用状況は、過去における利用額、利用頻度、利用店舗数、又はキャンペーンへのエントリー有無である。これらの情報は、利用状況データベースＤＢ２に格納されているものとする。

【0071】

本実施形態では、利用額の一例として、今後ｎヶ月で予測される予測値を説明するが、利用額は、過去における平均値であってもよい。平均値は、過去の全期間の平均値であってもよいし、直近の一部の期間の平均値であってもよい。利用額計算部１０２は、過去における利用状況に基づいて、将来に予測される利用額を計算する。例えば、利用額計算部１０２は、サービスの利用状況を数値化し、所定の計算式に代入することによって、利用額を計算する。この計算式には、利用状況と利用額の関係が示されている。

【0072】

例えば、利用額計算部１０２は、利用状況が示す過去の利用額が高いほど、将来に予測される利用額が高くなるように、将来に予測される利用額を計算する。また例えば、利用額計算部１０２は、利用状況が示す過去の利用頻度が高いほど、将来に予測される利用額が高くなるように、将来に予測される利用額を計算する。また例えば、利用額計算部１０２は、利用状況が示す過去の利用店舗数が多いほど、将来に予測される利用額が高くなるように、将来に予測される利用額を計算する。また例えば、利用額計算部１０２は、利用状況が示すキャンペーンへのエントリーが多いほど、将来に予測される利用額が高くなるように、将来に予測される利用額を計算する。

【0073】

なお、利用額は、サービスの利用状況以外の情報も考慮されてもよい。例えば、利用額計算部１０２は、ユーザにより登録されたユーザ情報と、ユーザによる他のサービスの利用状況と、の少なくとも一方に更に基づいて、利用額を計算してもよい。

【0074】

ユーザ情報は、ユーザの特性を示す情報である。例えば、ユーザ情報は、性別、住所、年収、家族構成、勤務先、又は役職である。ユーザ情報は、ユーザデータベースＤＢ１に格納されていてもよい。他のサービスの利用状況は、本実施形態で説明する決済サービス以外のサービスの利用状況である。利用状況の意味は先述した通りである。例えば、他のサービスは、電子商取引サービス、旅行予約サービス、金融サービス、保険サービス、又は通信サービス等である。本実施形態のサービスは、他のサービスと連携しており、サーバ１０は、他のサービスのシステムからユーザの利用状況を取得しているものとする。例えば、サーバ１０は、他のサービスの利用状況として、ユーザ端末２０にインストールされている他のサービスに関連するアプリケーションの利用状況を取得してもよい。

【0075】

例えば、利用額を計算するための計算式には、利用状況だけでなく、ユーザ情報と他のサービスの利用状況の少なくとも一方も代入できるようになっている。利用額計算部１０２は、ユーザ情報と他のサービスの利用状況の少なくとも一方を数値化し、所定の計算式に代入することによって、利用額を計算する。この計算式には、ユーザ情報と他のサービスの利用状況の少なくとも一方と利用額との関係が示されている。

【0076】

例えば、利用額計算部１０２は、ユーザの性別が所定の性別だった場合に、他の性別だった場合よりも高くなるように、利用額を計算する。また例えば、利用額計算部１０２は、ユーザの住所が都心部だった場合に、郊外部だった場合よりも高くなるように、利用額を計算する。また例えば、利用額計算部１０２は、ユーザの年収が高いほど利用額が高くなるように、利用額を計算する。また例えば、利用額計算部１０２は、ユーザの家族構成の人数が多いほど利用額が高くなるように、利用額を計算する。また例えば、利用額計算部１０２は、ユーザの勤務先の平均収入が多いほど利用額が高くなるように、利用額を計算する。また例えば、利用額計算部１０２は、ユーザの役職が高いほど利用額が高くなるように、利用額を計算する。

【0077】

例えば、利用額計算部１０２は、他のサービスにおける利用額が高いほど利用額が高くなるように、利用額を計算する。また例えば、利用額計算部１０２は、他のサービスにおける利用頻度が高いほど、利用額が高くなるように、利用額を計算する。また例えば、利用額計算部１０２は、他のサービスにおける利用店舗数が多いほど、利用額が高くなるように、利用額を計算する。また例えば、利用額計算部１０２は、他のサービスにおけるキャンペーンへのエントリーが多いほど、利用額が高くなるように、利用額を計算する。

【0078】

なお、利用額は、予め定められた方法に基づいて計算されるようにすればよく、計算式を利用した例に限られない。例えば、利用額計算部１０２は、利用状況と利用額との関係を学習させた学習モデルを利用して、利用額を計算してもよい。また例えば、利用額計算部１０２は、利用状況と利用額の関係を定義したプログラムコードに基づいて、利用額を計算してもよい。

【0079】

［３−４．信用度計算部］
信用度計算部１０３は、制御部１１を主として実現される。信用度計算部１０３は、不正度と利用額とに基づいて、ユーザの信用度を計算する。信用度計算部１０３は、ユーザごとに、当該ユーザの不正度と利用額に基づいて当該ユーザの信用度を計算する。信用度計算部１０３は、全てのユーザの信用度を計算してもよいし、一部のユーザの信用度を計算してもよい。本実施形態では、信用度計算部１０３は、不正度と将来に予測される利用額とに基づいて、将来に予測されるユーザの信用度を計算する。

【0080】

本実施形態では、個別不正度と全体不正度が存在するので、信用度計算部１０３は、全体不正度と利用額とに基づいて、信用度を計算する。信用度計算部１０３は、全体不正度と利用額を所定の計算式に代入することによって、信用度を計算してもよい。この計算式には、全体不正度及び利用額と、信用度と、の関係が示されている。

【0081】

例えば、信用度計算部１０３は、全体不正度が低くかつ利用額が高いほど、信用度が高くなるように、信用度を計算する。全体不正度が信用度に及ぼす影響と、利用額が信用度に及ぼす影響と、は同じであってもよいし異なっていてもよい。全体不正度が信用度に及ぼす影響が、利用額が信用度に及ぼす影響よりも大きい場合には、セキュリティを重視することができる。利用額が信用度に及ぼす影響が、全体不正度が信用度に及ぼす影響よりも大きい場合には、収益性を重視することができる。

【0082】

本実施形態では、信用度計算部１０３は、信用度として、ユーザからの利益の期待値を計算する。この期待値は、将来予測されるユーザの利用額に応じた利益の期待値である。計算式には、全体不正度及び利用額と、利益の期待値と、の関係が示されていることになる。利用額に所定の利益率を乗じた額が利益になるのであれば、計算式には、当該利益率が示されている。例えば、信用度計算部１０３は、利用額に利益率を乗じた値から、利用額に全体不正度を乗じた値を引くことによって、利益の期待値を計算する。

【0083】

なお、信用度は、予め定められた方法に基づいて計算されるようにすればよく、計算式を利用した例に限られない。例えば、信用度計算部１０３は、全体不正度及び利用額と、信用度と、の関係を学習させた学習モデルを利用して、利用額を計算してもよい。また例えば、利用額計算部１０２は、全体不正度及び利用額と、信用度と、の関係を定義したプログラムコードに基づいて、利用額を計算してもよい。

【0084】

［３−５．実行部］
実行部１０４は、制御部１１を主として実現される。実行部１０４は、信用度に応じた処理を実行する。実行部１０４は、ユーザごとに、当該ユーザの信用度に応じた処理を実行する。実行部１０４は、全てのユーザについて処理を実行してもよいし、一部のユーザについてのみ処理を実行してもよい。

【0085】

信用度に応じた処理とは、実行するか否かが信用度によって決まる処理、又は、信用度によって内容が変わる処理である。本実施形態では、この処理の一例として、サービスに関するクーポンをユーザに付与する処理を説明するが、この処理は、任意の処理であってよい。クーポンは、サービスに係るものであればよく、例えば、サービス利用時に割引を受けることができる権利、サービス利用時にポイントが付与される権利、又は、サービス利用時にコンテンツや物を受け取ることができる権利などである。なお、実行部１０４が実行する処理は、サービスの利用を制限する処理、追加の認証を要求する処理、又は、クーポン以外の優待を付与する処理であってもよい。

【0086】

例えば、実行部１０４は、信用度が閾値未満のユーザにはクーポンを付与せず、信用度が閾値以上のユーザに対し、クーポンを付与する。閾値は、固定値であってもよいし、可変値であってもよい。閾値は、ユーザごとに定められてもよい。また例えば、複数種類のクーポンが用意されている場合、実行部１０４は、ユーザの信用度に応じたクーポンを付与する。実行部１０４は、ユーザの信用度が高いほど価値が高いクーポンを付与する。この場合、クーポンは、信用度によってランク分けされているものとする。

【0087】

［４．本実施形態において実行される処理］
次に、信用度計算システムＳにおいて実行される処理について説明する。ここでは、ユーザがサービスを利用するためのサービス利用処理と、ユーザの信用度を計算するための信用度計算処理と、について説明する。

【0088】

［４−１．サービス利用処理］
図７は、サービス利用処理の一例を示すフロー図である。図７に示すサービス利用処理は、制御部１１，２１が、それぞれ記憶部１２，２２に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図３に示す機能ブロックにより実行される処理の一例である。なお、サービス利用処理が実行されるにあたり、ユーザは、利用登録を済ませているものとする。

【0089】

図７に示すように、ユーザ端末２０は、サーバ１０に対し、決済要求を送信する（Ｓ１００）。決済要求は、決済を実行するための要求である。決済要求は、所定形式のデータが送信されることによって行われるようにすればよく、例えば、支払先ＩＤ、ユーザＩＤ、利用額、及び認証情報が含まれる。認証情報は、ユーザ端末２０の記憶部２２に記憶されていてもよいし、操作部２４から入力されてもよい。他にも例えば、生体認証を利用する場合、ユーザ端末２０のカメラ等から認証情報が入力されてもよい。例えば、決済要求は、実店舗で所定の支払操作をした場合、オンライン上で商品を購入する場合、又は、オンライン上でサービスを予約する場合に送信される。なお、上述したように、ユーザがユーザ端末２０を操作せずにサービスを利用する場合、Ｓ１００の処理は省略されてもよく、決済要求は実店舗の端末等から送信されてもよい。

【0090】

サーバ１０は、決済要求を受信すると、ユーザデータベースＤＢ１に基づいて、決済処理を実行する（Ｓ１０１）。Ｓ１０１においては、サーバ１０は、決済要求に含まれるユーザＩＤと認証情報に基づいて、ユーザ認証を実行する。ユーザ認証が成功した場合、サーバ１０は、ユーザＩＤに関連付けられた決済情報に基づいて、決済処理を実行する。決済処理自体は、公知の処理を適用可能であり、本実施形態では、クレジットカード会社のシステムに対する与信問い合わせ等が送信される。ユーザ認証が成功しなかった場合、決済処理は実行されず、本処理は終了する。

【0091】

サーバ１０は、Ｓ１０１で実行された決済の内容と、記憶部１２に記憶された学習モデルと、に基づいて、この決済に応じた個別不正度を計算する（Ｓ１０２）。Ｓ１０２においては、サーバ１０は、Ｓ１０１で実行された決済の利用額と利用日時を学習モデルに入力し、学習モデルが出力した個別不正度を取得する。なお、Ｓ１０２の処理をＳ１０１の処理よりも先に実行し、個別不正度が非常に高かった場合には、決済処理が保留になってもよい。

【0092】

サーバ１０は、利用状況データベースＤＢ２を更新し（Ｓ１０３）、本処理は終了する。Ｓ１０３においては、サーバ１０は、決済ＩＤを新たに発行し、利用状況データベースＤＢ２に新たなレコードを作成する。サーバ１０は、当該レコードに、決済ＩＤ、支払先ＩＤ、ユーザＩＤ、利用額、利用日時、及び個別不正度を格納する。

【0093】

［４−２．信用度計算処理］
図８は、信用度計算処理の一例を示すフロー図である。図８に示す信用度計算処理は、制御部１１が記憶部１２に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図３に示す機能ブロックにより実行される処理の一例である。信用度計算処理は、任意のタイミングで実行されるようにすればよく、例えば、管理者が所定の操作をした場合に実行されてもよいし、所定の日時が訪れた場合に実行されてもよい。

【0094】

図８に示すように、まず、サーバ１０は、利用状況データベースＤＢ２に基づいて、各ユーザの全体不正度を計算する（Ｓ２００）。Ｓ２００においては、サーバ１０は、利用状況データベースＤＢ２を参照し、ユーザごとに、未確定決済（直近３ヶ月の決済）の個別不正度を取得する。サーバ１０は、ユーザごとに、各未確定決済の個別不正度に基づいて全体不正度を計算する。サーバ１０は、各ユーザの全体不正度を、信用度データベースＤＢ３に格納する。

【0095】

サーバ１０は、利用状況データベースＤＢ２に基づいて、各ユーザの将来予測される利用額を計算する（Ｓ２０１）。Ｓ２０１においては、サーバ１０は、利用状況データベースＤＢ２を参照し、ユーザごとに、サービスの利用状況を取得する。サーバ１０は、ユーザごとに、サービスの利用状況を所定の計算式に代入して利用額を計算する。サーバ１０は、各ユーザの利用額を、信用度データベースＤＢ３に格納する。なお、先述したように、サーバ１０は、ユーザデータベースＤＢ１を参照し、ユーザごとに、ユーザ情報を取得して利用額を計算してもよいし、他のサービスから利用状況を取得して利用額を計算してもよい。

【0096】

サーバ１０は、各ユーザの全体不正度と利用額とに基づいて、各ユーザの信用度を計算する（Ｓ２０２）。Ｓ２０２においては、サーバ１０は、ユーザごとに、Ｓ２００で計算した全体不正度とＳ２０１で計算した利用額を所定の計算式に代入して信用度を計算する。サーバ１０は、各ユーザの信用度を、信用度データベースＤＢ３に格納する。

【0097】

サーバ１０は、各ユーザの信用度に基づいて、クーポンを付与し（Ｓ２０３）、本処理は終了する。Ｓ２０３においては、サーバ１０は、ユーザごとに、当該ユーザの信用度に応じたクーポンを特定する。サーバ１０は、各ユーザに対して特定されたクーポンを、信用度データベースＤＢ３に格納する。信用度データベースＤＢ３に格納されたクーポンは、ユーザが次回サービスにログインした際に使用可能となり、次回以降のサービス利用処理で使用することができる。

【0098】

本実施形態の信用度計算システムＳによれば、ユーザの行動に応じた不正度と、サービスの利用状況に応じた利用額と、に基づいて、ユーザの信用度を計算することによって、収益性とセキュリティのバランスを保ち、これらを両立させることができる。例えば、不正度だけを考慮した場合において、利用額が高いユーザの不正度が高く計算されると、このユーザの利用が過度に制限されてしまい収益性が低下する。また例えば、利用額が高いユーザを無条件で優遇すると、不正利用を止めることができない可能性があり、セキュリティ性が低下する。信用度計算システムＳは、ユーザの信用度を計算することによって、収益性とセキュリティを適したバランスとすることができる。

【0099】

また、信用度計算システムＳは、過去におけるサービスの利用状況に基づいて、将来に予測される利用額を計算することによって、今後のユーザの利用額を予測して信用度に反映させ、将来における収益性とセキュリティのバランスをより好適に保つことができる。

【0100】

また、信用度計算システムＳは、実際に不正であるか否かが確定した行動が学習された学習モデルに基づいて、不正であるか否かが確定していない行動の不正度を計算することによって、不正度の計算精度を高めることができる。例えば、新しい教師データを学習モデルに学習させることによって、最新の不正のトレンドに対応した高精度の不正度を計算することができる。不正度の計算精度を高めることによって、信用度の計算精度も高めることができ、収益性とセキュリティのバランスをより好適に保つことができる。

【0101】

また、信用度計算システムＳは、ユーザにより登録されたユーザ情報と、ユーザによる他のサービスの利用状況と、の少なくとも一方に更に基づいて、利用額を計算することによって、利用額の計算精度を高めることができる。利用額の計算精度を高めることによって、信用度の計算精度も高めることができ、収益性とセキュリティのバランスをより好適に保つことができる。

【0102】

また、信用度計算システムＳは、信用度として、ユーザからの利益の期待値を計算することによって、サービス全体として利益を高めることが可能な信用度を計算し、収益性をより高めることができる。

【0103】

また、信用度計算システムＳは、所定の期間における各行動の個別不正度に基づいて、ユーザの全体不正度を計算し、全体不正度と利用額とに基づいて信用度を計算することによって、あるユーザの行動を総合的に考慮して信用度を計算し、信用度の計算精度を高めることができ、収益性とセキュリティのバランスをより好適に保つことができる。

【0104】

また、信用度計算システムＳは、信用度に応じた処理を実行することによって、例えば、信用度に応じたサービスを提供したり、信用度に応じた優待を付与したりすることができる。

【0105】

また、信用度計算システムＳは、信用度に応じて、サービスに関するクーポンをユーザに付与する処理を実行することによって、信用度に応じた優待を付与することができる。

【0106】

［５．変形例］
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。

【0107】

（１）例えば、実施形態では、未確定決済の個別不正度の単純平均を全体不正度とする場合を説明したが、不正度計算部１０１は、各行動が行われた時点からの経過時間に更に基づいて、全体不正度を計算してもよい。行動が行われた時点とは、サービスの利用日時である。経過時間とは、当該時点から現時点までの時間の長さである。経過時間は、利用状況データベースＤＢ２に格納された利用日時と現時点との間隔ということもできる。

【0108】

例えば、不正度計算部１０１は、経過時間が長いほど（行動が行われた時点が古いほど）重み付け係数が小さくなるように、全体不正度を計算する。別の言い方をすれば、不正度計算部１０１は、経過時間が短いほど（行動が行われた時点が新しいほど）重み付け係数が大きくなるように、全体不正度を計算する。経過時間が長いとは、行動が行われた時点が古いことであり、経過時間が短いとは、行動が行われた時点が新しいことである。

【0109】

なお、重み付け係数を決定するための重み関数は、定数関数であってもよいし、指数関数であってもよい。不正度計算部１０１は、上記のように決定した重み付け係数に基づいて、未確定決済の個別不正度の加重平均を計算し、全体不正度として取得する。ある行動の経過時間が短いほど、この行動が全体不正度に与える影響が高くなる。

【0110】

変形例（１）によれば、各行動が行われた時点からの経過時間に更に基づいて、全体不正度を計算することによって、例えば、最近の行動のトレンドをより強く全体不正度に反映させることができ、全体不正度の計算精度を高めることができる。全体不正度の計算精度を高めることによって、信用度の計算精度も高めることができ、収益性とセキュリティのバランスをより好適に保つことができる。

【0111】

（２）また例えば、不正度計算部１０１は、過去に行われた行動に基づく不正度と、当該行動が実際に不正であったか否かの確定結果と、に基づいて、不正度の計算における重み付け係数を決定し、当該決定された重み付け係数に基づいて、不正度を計算してもよい。重み付け係数は、不正度の計算に用いられる係数である。重み付け係数は、仮の不正度を補正するために用いられる。仮の不正度は、実施形態で説明した方法で計算された不正度である。例えば、不正度計算部１０１は、過去に計算した不正度と、その後の確定結果と、の分布から適切な重み付け係数を決定し、当該重み付け係数に基づいて不正度を計算する。

【0112】

図９は、変形例（２）の概要を示す図である。図９についても、図２と同様に、現時点を２０１９年１１月３０日とする。図９では、２０１９年におけるユーザＡの確定済み決済の不正度と、不正であるか否かの確定結果と、を示す。図９の不正度は、学習モデルによって出力された値であり、図２の値とは異なる。即ち、図９の不正度は、確定済み決済が未確定決済だった時に、学習モデルによって出力された値である。

【0113】

図９に示すように、サーバ１０は、図２に示すユーザＡの利用状況に基づいて、複数のデータセットを抽出する。個々のデータセットに含まれる決済は、互いに異なる。例えば、サーバ１０は、ランダムに期間を区切ってデータセットを抽出する。他にも例えば、サーバ１０は、不正が確定した決済を探索し、不正が確定した決済を見つけた場合に、その時点までに含まれる決済をデータセットとして抽出してもよい。

【0114】

例えば、不正度の計算式の重み関数が時間の経過のみに依存する関数であったと仮定すると、学習モデルが出力する不正度と、実際に不正であるか否かの確定結果と、の乖離度（いわゆるＬｏｓｓ）を重み関数に応じて設定することができる。サーバ１０は、この乖離度をデータ全体に対して最小化するような重み関数を推定する。例えば、この推定は、損失関数と重み関数の定義によって解析的に解かれてもよいし、最適化ソルバー等によって近似的に解かれてもよい。重み関数としては、指数関数、ロジスティック曲線、又は線形関数などを定義することができる。

【0115】

例えば、不正度計算部１０１は、学習モデルが出力する不正度と、実際に不正であるか否かの確定結果と、の乖離度が小さくなるように、学習モデルが出力した仮の不正度を補正する。この補正量は、重み関数における重み付け係数によって決まる。この乖離度は、ユーザによって異なることがあるので、不正度計算部１０１は、乖離度が高いほど仮の不正度の補正量が多くなるように、仮の不正度を補正する。例えば、過去の確定済み決済から計算されたユーザごとに乖離度が高い場合には、不正度計算部１０１は、学習モデルが計算した仮の不正度が低くなるように補正する。

【0116】

変形例（２）によれば、過去に行われた行動に基づく不正度と、当該行動が実際に不正であったか否かの確定結果と、に更に基づいて、不正度を計算することによって、不正度の計算精度を高めることができる。不正度の計算精度を高めることによって、信用度の計算精度も高めることができ、収益性とセキュリティのバランスをより好適に保つことができる。

【0117】

（３）また例えば、不正度計算部１０１は、ユーザの認証方法と、ユーザの名義人と、の少なくとも一方に更に基づいて、不正度を計算してもよい。例えば、不正度計算部１０１は、ユーザが指定した認証方法の強度が高いほど、不正度が低くなるように、不正度を計算する。認証方法の強度は、パスワードの強度、二段階認証の登録の有無、又は生体認証の種類によって判定されるようにすればよい。

【0118】

また例えば、不正度計算部１０１は、ユーザが登録したクレジッドカードの名義人と、ユーザがユーザデータベースＤＢ１に登録した氏名と、の差異が大きいほど、不正度が高くなるように、不正度を計算する。なお、上述したような名義人又は氏名と、不正度との関係を学習させた学習モデルを作成し、この学習モデルに基づいて不正度を計算し、信用度を計算することもできる。また、特に学習モデルを利用せずに、クレジットカードの名義人の文字列と、ユーザの氏名の文字列と、の間で相違する文字数に基づいて、不正度が計算されてもよい。

【0119】

変形例（３）によれば、ユーザの認証方法と、ユーザの名義人と、の少なくとも一方に更に基づいて、不正度を計算することによって、不正度の計算精度を高めることができる。不正度の計算精度を高めることによって、信用度の計算精度も高めることができ、収益性とセキュリティのバランスをより好適に保つことができる。

【0120】

（４）また例えば、上記変形例を組み合わせてもよい。

【0121】

また例えば、実施形態では、決済処理が実行されてから一定期間が経過すると、不正であるか否かが確定する場合を説明したが、決済処理が実行されてすぐに、管理者の確認が行われて不正であるか否かが確定してもよい。また例えば、信用度は、利益の期待値ではなく、売上の期待値を示してもよいし、利益及び売上以外の指標であってもよい。

【0122】

また例えば、個別不正度に基づいて全体不正度が計算される場合を説明したが、特に全体不正度は計算されなくてもよい。この場合、複数の決済の各々の個別不正度と利用額が計算式に代入されて、信用度が計算されるようにしてもよい。更に、所定の期間内に決済が一度しか実行されなければ、１つの個別不正度と利用額が計算式に代入されて、信用度が計算される。

【0123】

また例えば、信用度計算システムＳが信用度に応じた処理を実行する場合を説明したが、この処理は、特に実行されずに管理者によって信用度の解析が行われてもよいし、外部のシステムによって実行されるようにしてもよい。即ち、信用度計算システムＳは、実行部１０４を含まなくてもよい。

【0124】

また例えば、サービスの一例として決済サービスを説明したが、信用度計算システムＳは、電子商取引サービス、旅行予約サービス、金融サービス、保険サービス、又は通信サービスといった任意のサービスにおける信用度を計算する場面に適用可能である。更に、サービスの管理者がクレジットカード会社ではない場合を説明したが、サービスの管理者は、クレジットカード会社であってもよい。

【0125】

また例えば、主な機能がサーバ１０で実現される場合を説明したが、各機能は、複数のコンピュータで分担されてもよい。例えば、サーバ１０とユーザ端末２０で機能が分担されてもよい。また例えば、信用度計算システムＳが複数のサーバコンピュータを含む場合には、これら複数のサーバコンピュータで機能が分担されてもよい。また例えば、データ記憶部１００で記憶されるものとして説明したデータは、サーバ１０以外のコンピュータによって記憶されてもよい。

【符号の説明】

【0126】

Ｓ 信用度計算システム、Ｎ ネットワーク、１０ サーバ、１１，２１ 制御部、１２，２２ 記憶部、１３，２３ 通信部、２０ ユーザ端末、２４ 操作部、２５ 表示部、１００ データ記憶部、１０１ 不正度計算部、１０２ 利用額計算部、１０３ 信用度計算部、１０４ 実行部、ＤＢ１ ユーザデータベース、ＤＢ２ 利用状況データベース、ＤＢ３ 信用度データベース。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】