特許 7514341 支払支援システム、支払支援サービスの案内方法、及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-07-02

(45)【発行日】2024-07-10

(54)【発明の名称】支払支援システム、支払支援サービスの案内方法、及びプログラム

(51)【国際特許分類】

   G06Q 20/02 20120101AFI20240703BHJP

【ＦＩ】

G06Q20/02

【請求項の数】 14

(21)【出願番号】P 2023011639

(22)【出願日】2023-01-30

【審査請求日】2023-01-30

(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】

【文献】特開２０２１－１４９６５８号公報

【発明の概要】

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

【0004】

例えば、特許文献１のような支払支援サービスでは、支払支援サービスの利用を促進するために、ユーザに対し、支払支援サービスを案内することが考えられる。しかしながら、ただやみくもに支払支援サービスを案内しても、効果が薄いと考えられる。ユーザに応じた適切な案内を行うのが効果的と考えられる。この点、従来の技術では、このような案内が行われていないので、支払支援サービスの利用を十分に促進できなかった。

【0005】

本開示の目的の１つは、支払支援サービスの利用を促進することである。

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

【0006】

本開示に係る支払支援システムは、支払の支援に関する支払支援サービスの案内に関する推定が行われる推定ユーザに関する推定ユーザ情報を取得する推定ユーザ情報取得部と、前記推定ユーザ情報と、前記推定に関する案内推定モデルと、に基づいて、前記推定ユーザの前記推定を実行する案内推定部と、前記推定ユーザの前記推定の実行結果に基づいて、前記推定ユーザに対し、前記支払支援サービスを案内する案内部と、を含む。

【発明の効果】

【0007】

本開示によれば、支払支援サービスの利用を促進できる。

【図面の簡単な説明】

【0008】

【図1】支払支援システムの全体構成の一例を示す図である。

【図2】余力推定モデルによりユーザの余力が推定されて、支払支援サービスがユーザに案内される流れの一例を示す図である。

【図3】支払支援サービスが案内される様子の一例を示す図である。

【図4】第１実施形態の支払支援システムで実現される機能の一例を示す図である。

【図5】ユーザデータベースの一例を示す図である。

【図6】訓練データベースの一例を示す図である。

【図7】第１実施形態の支払支援システムで実行される処理の一例を示す図である。

【図8】第２実施形態の支払支援システムで実現される機能の一例を示す図である。

【図9】第２実施形態のユーザデータベースの一例を示す図である。

【図10】訓練データベースの一例を示す図である。

【図11】第２実施形態の支払支援システムで実行される処理の一例を示す図である。

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

【0009】

［１．第１実施形態］
本開示に係る支払支援システムの実施形態の一例である第１実施形態を説明する。

【0010】

［１－１．支払支援システムの全体構成］
図１は、支払支援システムの全体構成の一例を示す図である。例えば、支払支援システム１は、管理者端末１０、サーバ２０、及びユーザ端末３０を含む。管理者端末１０、サーバ２０、及びユーザ端末３０の各々は、インターネット又はＬＡＮ等のネットワークＮに接続される。

【0011】

管理者端末１０は、支払支援システム１の管理者のコンピュータである。例えば、管理者端末１０は、パーソナルコンピュータ、スマートフォン、又はタブレットである。例えば、管理者端末１０は、制御部１１、記憶部１２、通信部１３、操作部１４、及び表示部１５を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。操作部１４は、キーボード、マウス、又はタッチパネル等の入力デバイスである。表示部１５は、液晶ディスプレイ又は有機ＥＬディスプレイ等のディスプレイである。

【0012】

サーバ２０は、サーバコンピュータである。例えば、サーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

【0013】

ユーザ端末３０は、ユーザのコンピュータである。例えば、ユーザ端末３０は、パーソナルコンピュータ、スマートフォン、又はタブレットである。例えば、ユーザ端末３０は、制御部３１、記憶部３２、通信部３３、操作部３４、及び表示部３５を含む。制御部３１、記憶部３２、通信部３３、操作部３４、及び表示部３５の物理的構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部１４、及び表示部１５と同様であってよい。

【0014】

なお、記憶部１２，２２，３２に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。また、コンピュータ読み取り可能な情報記憶媒体に記憶されたプログラムが、情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）を介して供給されてもよい。

【0015】

また、支払支援システム１は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。例えば、支払支援システム１は、ユーザ端末３０を含まずに、管理者端末１０及びサーバ２０だけを含んでもよい。支払支援システム１は、サーバ２０及びユーザ端末３０を含まずに、管理者端末１０だけを含んでもよい。支払支援システム１は、管理者端末１０、サーバ２０、及びユーザ端末３０を含まずに、他のコンピュータを含んでもよい。

【0016】

［２．支払支援システムの概要］
本実施形態では、ユーザに対し、支払支援サービスが案内される。支払支援サービスは、支払の支援に関するサービスである。支払は、現金を引き渡すこと、又は、電子的な決済手段を利用することである。電子的な決済手段は、任意の種類であってよく、例えば、クレジットカード、デビットカード、バーコード若しくは二次元コード等のコード、電子マネー、ポイント、暗号資産、口座（銀行口座含む）、又はウォレットであってもよい。

【0017】

支援とは、資金を与えること、支払を分散させること、又は支払を後回しにすることである。例えば、支援は、キャッシング、分割払い、ボーナス払い、又は後払いである。本実施形態では、クレジットカードの付帯サービスとしての支払支援サービスを例に挙げるが、支払支援サービスは、クレジットカードとは関係のないサービスであってもよい。例えば、電子商取引サービスにおける後払い、キャッシング会社が提供するキャッシング、又は電子決済を提供する決済事業者が提供する分割払いが支払支援サービスに相当してもよい。

【0018】

案内とは、ユーザに送られる通知である。案内は、任意の手段を利用可能であり、例えば、電子メール、ＳＭＳのメッセージ機能、ＳＮＳのメッセージ機能、メッセージアプリ、ウェブサイトのバナー広告、動画内の広告、アプリケーション内の通知、プッシュ通知、電話、又はその他の通知によって、案内が行われてもよい。案内は、電子的な手段に限られず、物理的な紙によって行われてもよい。例えば、案内は、物理的なダイレクトメールを送付することによって行われてもよい。

【0019】

本実施形態では、クレジットカードを保有するユーザに対し、支払支援サービスが案内される場合を例に挙げる。例えば、管理者は、クレジットカード会社の担当者である。サーバ２０は、クレジットカード会社により管理される。ユーザは、ユーザ端末３０を操作して、電子商取引サービス、旅行予約サービス、決済サービス、金融サービス、又は通信サービスといった種々のサービスでクレジットカードを利用する。ユーザは、オンラインではなく、実店舗又は自動販売機でもクレジットカードを利用可能である。

【0020】

例えば、ユーザは、クレジットカードの利用時に一括払い、分割払い、又はボーナス払いの何れかを選択できる。ユーザは、一括払いで支払をしたとしても、事後的に分割払い又はボーナス払いに変更できる。本実施形態では、ユーザが事後的に分割払いに変更する場合を例に挙げる。以降、事後的な分割払いを、あとから分割払いという。あとから分割払いは、所定の期日までに申し込む必要がある。例えば、この期日は、クレジットカードの利用日から所定日数だけ後の期日、又は、クレジットカードの毎月の締め日である。

【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】

変形例１－２の支払支援システム１は、訓練ユーザ情報と、訓練ユーザの支払の総額から、訓練ユーザによる支払支援サービスの利用に応じた額を引いた余力と、の関係が学習された余力推定モデルＭ１に基づいて、推定ユーザの余力を推定する。これにより、より正確な余力を余力推定モデルＭ１に学習させることができるので、余力推定モデルＭ１の精度が高まる。

【0127】

［変形例１－３］
例えば、推定ユーザの余力は、時期によって異なることがある。このため、余力推定部１０５は、推定ユーザ情報と、推定ユーザの余力が推定される時期と、余力推定モデルＭ１と、に基づいて、推定ユーザの余力を推定してもよい。例えば、余力推定モデルＭ１には、ある訓練ユーザの訓練ユーザ情報及び時期を入力部分とし、この訓練ユーザのこの時期における余力を出力部分とする訓練データが学習されている。即ち、時期も特徴量の１つとして余力推定モデルＭ１に学習されている。

【0128】

例えば、余力推定部１０５は、推定ユーザ情報及び時期を、余力推定モデルＭ１に入力する。余力推定モデルＭ１は、当該入力された推定ユーザ情報及び時期の埋め込み表現を計算し、当該埋め込み表現に応じた余力を出力する。余力推定部１０５は、余力推定モデルＭ１から出力された余力を取得することによって、推定ユーザ情報及び時期に応じた余力を推定する。

【0129】

なお、推定ユーザの余力が推定される時期ごとに、余力推定モデルＭ１が作成されてもよい。この場合、データ記憶部１００は、複数の余力推定モデルＭ１を記憶する。訓練データ作成部１０２は、時期ごとに、当該時期における訓練ユーザの支払総額から、当該時期における訓練ユーザによる支払支援サービスの利用状況に応じた額を引いた値を計算する。訓練データ作成部１０２は、訓練ユーザ情報及び時期と、当該計算された値と、のペアを訓練データとして作成する。学習部１０３は、時期ごとに、当該時期の訓練データを余力推定モデルＭ１に学習させる。

【0130】

変形例１－３の支払支援システム１は、推定ユーザ情報と、推定ユーザの余力が推定される時期と、余力推定モデルＭ１と、に基づいて、推定ユーザの余力を推定する。これにより、時期に応じた余力の推定が可能になるので、余力の推定精度が高まる。例えば、ボーナスの時期には、他の時期に比べて余力が高くなるといった推定が可能になる。

【0131】

［３－２．第２実施形態に関する変形例］
まず、第２実施形態に関する変形例を説明する。

【0132】

［変形例２－１］
例えば、第２実施形態では、説得可能層のユーザが推定ユーザに相当する場合を説明したが、推定ユーザは、支払支援サービスを相対的に利用していないユーザであってもよい。支払支援サービスを相対的に利用していないユーザとは、支払支援サービスを最初に利用した日からの経過時間が閾値未満であること、支払支援サービスの利用回数若しくは利用頻度が閾値未満であること、又は支払支援サービスの利用額が閾値未満であることである。

【0133】

例えば、変形例２－１の分類部１０１は、ユーザデータベースＤＢ１に基づいて、支払支援サービスを相対的に利用していないユーザと、支払支援サービスを相対的に利用するユーザと、に分類する。支払支援サービスを相対的に利用するユーザとは、支払支援サービスを最初に利用した日からの経過時間が閾値以上であること、支払支援サービスの利用回数若しくは利用頻度が閾値以上であること、又は支払支援サービスの利用額が閾値以上であることである。

【0134】

変形例２－１では、第２実施形態で説明した特定の分類は、支払支援サービスを相対的に利用することを示す。案内部１０６は、支払支援サービスを相対的に利用していない推定ユーザの推定ユーザ情報と、支払支援サービスを相対的に利用する訓練ユーザの訓練ユーザ情報が学習された案内推定モデルＭ２と、に基づいて、推定ユーザの余力を推定する。推定ユーザ及び訓練ユーザの抽出方法が第２実施形態とは異なるが、他の点については、第２実施形態と同様である。

【0135】

変形例２－１では、特定の分類は、支払支援サービスを相対的に利用することを示す。推定ユーザは、支払支援サービスを相対的に利用していないユーザである。これにより、支払支援サービスを相対的に利用しており、十分な情報量が蓄積されており正確な余力を把握できるユーザを訓練ユーザとすることができるので、案内推定モデルＭ２の精度が高まる。支払支援サービスを相対的に利用しておらず、十分な情報量が蓄積されておらず正確な余力を把握するのが難しい推定ユーザの余力を推定できる。

【0136】

［変形例２－２］
例えば、第１実施形態及び第２実施形態を組み合わせて、案内推定部１０７は、推定ユーザ情報と、支払に関する余力の推定に関する余力推定モデルＭ１と、に基づいて、推定ユーザの余力を推定してもよい。変形例２－２では、案内推定部１０７が余力推定部１０５と同様の機能を有するものとする。この機能は、第１実施形態で説明した通りである。

【0137】

変形例２－２の案内推定部１０７は、当該推定された余力と、案内推定モデルＭ２と、に基づいて、推定ユーザの推定を実行する。例えば、訓練ユーザの余力と、訓練ユーザにとって最適なタイミングと、の関係が案内推定モデルＭ２に学習されている。最適なタイミングは、訓練ユーザが実際に支払支援サービスの案内に応じて支払支援サービスを利用した場合の当該案内のタイミングである。

【0138】

例えば、案内推定部１０７は、余力推定部１０５により推定された推定ユーザの余力を、案内推定モデルＭ２に入力する。案内推定部１０７は、推定ユーザの推定ユーザ情報も、案内推定モデルＭ２に入力してもよい。案内推定モデルＭ２は、入力された余力（必要に応じて推定ユーザ情報も）の埋め込み表現を計算し、当該埋め込み表現に応じたタイミングを出力する。案内推定部１０７は、案内推定モデルＭ２から出力されたタイミングを取得することによって、推定ユーザにとって最適なタイミングを推定する。

【0139】

変形例２－２の支払支援システム１は、推定ユーザ情報と、支払に関する余力の推定に関する余力推定モデルＭ１と、に基づいて、推定ユーザの余力を推定する。支払支援システム１は、当該推定された余力と、案内推定モデルＭ２と、に基づいて、推定ユーザの推定を実行する。これにより、推定ユーザに対して支払支援サービスを案内する最適なタイミングを推定する精度が高まる。その結果、支払支援サービスの利用を促進できる。

【0140】

［変形例２－３］
例えば、第２実施形態では、推定ユーザのデモグラフィック情報が推定ユーザ情報として利用される場合を説明したが、推定ユーザ情報は、推定ユーザに関する何らかの情報であればよく、第２実施形態の例に限られない。推定ユーザ情報は、推定ユーザに対して期待される利益を示してもよい。ここでの利益とは、支払支援サービスと、それに付帯するサービス（例えば、クレジットカードの決済サービス）と、の少なくとも一方から得られる利益である。

【0141】

変形例２－３では、管理者端末１０は、予め定められた計算方法に基づいて、推定ユーザの利益を計算する。この計算方法は、数式、テーブル、又は機械学習の手法を利用した利益推定モデルの何れであってもよい。変形例２－３では、利益推定モデルを例に挙げる。利益推定モデルには、訓練ユーザの訓練ユーザ情報と、訓練ユーザから得られた利益と、の関係が学習されている。この学習は、学習部１０３により実行されるものとする。

【0142】

管理者端末１０は、推定ユーザの推定ユーザ情報を、学習済みの利益推定モデルに入力する。利益推定モデルは、入力された推定ユーザ情報の埋め込み表現を計算する。利益推定モデルは、当該計算された埋め込み表現に応じた利益を出力する。管理者端末１０は、利益推定モデルから出力された推定ユーザの利益を取得する。

【0143】

変形例２－３の案内推定モデルＭ２には、訓練ユーザの利益と、訓練ユーザにとって最適な案内のタイミングと、の関係が学習されている。この学習は、学習部１０３により実行されるものとする。案内推定部１０７は、推定ユーザの利益と、案内推定モデルＭ２と、に基づいて、推定ユーザの推定を実行する。利益が高いユーザにとって最適な案内のタイミングがある場合、利益と、最適な案内のタイミングと、の間には相関関係がある。

【0144】

例えば、案内推定部１０７は、上記推定された推定ユーザの利益を、案内推定モデルＭ２に入力する。案内推定部１０７は、推定ユーザの推定ユーザ情報も、案内推定モデルＭ２に入力してもよい。案内推定モデルＭ２は、入力された利益（必要に応じて推定ユーザ情報も）の埋め込み表現を計算し、当該埋め込み表現に応じたタイミングを出力する。案内推定部１０７は、案内推定モデルＭ２から出力されたタイミングを取得することによって、推定ユーザにとって最適なタイミングを推定する。

【0145】

変形例２－３では、推定ユーザ情報は、推定ユーザに対して期待される利益を示す。の支払支援システム１は、推定ユーザの利益と、案内推定モデルＭ２と、に基づいて、推定ユーザの推定を実行する。これにより、推定ユーザに対して期待される利益と、最適な案内のタイミングと、の間に相関関係がある場合に、推定ユーザに対して支払支援サービスを案内する最適なタイミングを推定する精度が高まる。その結果、支払支援サービスの利用を促進できる。

【0146】

［変形例２－４］
例えば、推定ユーザ情報は、推定ユーザによる支払額を示してもよい。支払額は、ある一定の期間の支払総額を意味してもよいし、個々の決済の支払額又はその平均値を示してもよい。変形例２－４の案内推定部１０７は、推定ユーザの支払額と、案内推定モデルＭ２と、に基づいて、推定ユーザの推定を実行する。案内推定モデルＭ２には、訓練ユーザの支払額と、訓練ユーザが支払支援サービスの案内に応じて支払支援サービスを利用したタイミングと、の関係が学習されている。この学習は、学習部１０３により実行される。

【0147】

案内推定部１０７は、推定ユーザの支払額と、案内推定モデルＭ２と、に基づいて、推定ユーザの推定を実行する。例えば、案内推定部１０７は、上記推定された推定ユーザの支払額を、案内推定モデルＭ２に入力する。案内推定部１０７は、推定ユーザの推定ユーザ情報も、案内推定モデルＭ２に入力してもよい。案内推定モデルＭ２は、入力された支払額（必要に応じて推定ユーザ情報も）の埋め込み表現を計算し、当該埋め込み表現に応じたタイミングを出力する。案内推定部１０７は、案内推定モデルＭ２から出力されたタイミングを取得することによって、推定ユーザにとって最適なタイミングを推定する。

【0148】

変形例２－４では、推定ユーザ情報は、推定ユーザによる支払額を示す。支払支援システム１は、推定ユーザの支払額と、案内推定モデルＭ２と、に基づいて、推定ユーザの推定を実行する。これにより、推定ユーザによる支払額と、最適な案内のタイミングと、の間に相関関係がある場合に、推定ユーザに対して支払支援サービスを案内する最適なタイミングを推定する精度が高まる。その結果、支払支援サービスの利用を促進できる。

【0149】

［変形例２－５］
例えば、第２実施形態では、案内推定モデルＭ２が、推定ユーザにとって適切なタイミングを推定するモデルである場合を説明したが、案内推定モデルＭ２は、支払支援サービスの案内に関する複数の態様の中から、推定ユーザにとって適切な態様を推定するモデルであってもよい。態様は、案内に含めるメッセージ、画像、案内の手段、又はこれらの組み合わせである。変形例２－５の案内推定モデルＭ２には、訓練ユーザの訓練ユーザ情報と、訓練ユーザが支払支援サービスの案内に応じて支払支援サービスを利用した場合の当該案内の態様と、の関係が学習されている。

【0150】

変形例２－５の訓練データの出力部分は、説得可能層の訓練ユーザに対し、過去に実際に行われた案内における態様を示す。この態様は、ユーザデータベースＤＢ１に格納されたユーザ情報に示されているものとする。例えば、ユーザ情報に示された支払支援サービスの案内状況に示されている。過去に実際に行われた案内は、ＡＢテスト又はバンディットアルゴリズム等のように、複数の態様の中からランダムに選択されてもよい。ユーザ情報には、過去に実際に行われた案内の態様とともに、この案内に対して訓練ユーザによる反応があったか否かが示されている。訓練ユーザによる反応があった態様が、訓練データの出力部分として示される。

【0151】

変形例２－５の案内推定部１０７は、推定ユーザ情報と、案内推定モデルＭ２と、に基づいて、適切な態様を推定する。例えば、案内推定部１０７は、案内推定モデルＭ２に対し、推定ユーザ情報を入力する。案内推定モデルＭ２は、当該入力された推定ユーザ情報の埋め込み表現を計算し、埋め込み表現に応じた態様を出力する。案内推定部１０７は、案内推定モデルＭ２から出力された態様を取得する。

【0152】

案内部１０６は、案内推定部１０７により推定された適切な態様で、推定ユーザに対し、支払支援サービスを案内する。例えば、案内部１０６は、案内推定部１０７により推定されたメッセージを含む案内を、推定ユーザに対して送信する。案内部１０６は、案内推定部１０７により推定された画像を含む案内を、推定ユーザに対して送信する。案内部１０６は、案内推定部１０７により推定された手段で、支払支援サービスを案内する。

【0153】

変形例２－５の支払支援システム１は、推定ユーザ情報と、案内推定モデルＭ２と、に基づいて、適切な態様を推定する。支払支援システム１は、当該推定された適切な態様で、推定ユーザに対し、支払支援サービスを案内する。これにより、支払支援システム１は、案内推定モデルＭ２を利用して適切な態様を推定することによって、より効果的な態様で支払支援サービスを案内できるようになる。

【0154】

［変形例２－６］
例えば、案内推定モデルＭ２は、複数の支払支援サービスの中から、推定ユーザにとって適切な支払支援サービスを推定するモデルであってもよい。変形例２－６では、キャッシングサービスと、あとから分割払いサービスと、の２つの支払支援サービスを例に挙げるが、支払支援サービスは、３つ以上であってもよい。変形例２－６の案内推定モデルＭ２には、訓練ユーザの訓練ユーザ情報と、複数の支払支援サービスのうち、訓練ユーザが支払支援サービスの案内に応じて利用した支払支援サービスと、の関係が学習されている。

【0155】

変形例２－６の訓練データの出力部分は、説得可能層の訓練ユーザに対し、過去に実際に行われた案内における支払支援サービスを示す。この支払支援サービスは、ユーザデータベースＤＢ１に格納されたユーザ情報に示されているものとする。例えば、この支払支援サービスは、ユーザ情報に示された支払支援サービスの案内状況に示されている。過去に実際に行われた案内は、ＡＢテスト又はバンディットアルゴリズム等のように、複数の支払支援サービスの中からランダムに選択されてもよい。ユーザ情報には、過去に実際に案内が行われた支払支援サービスとともに、この案内に対して訓練ユーザによる反応があったか否かが示されている。訓練ユーザによる反応があった支払支援サービスが、訓練データの出力部分として示される。

【0156】

変形例２－６の案内推定部１０７は、推定ユーザ情報と、案内推定モデルＭ２と、に基づいて、適切な支払支援サービスを推定する。例えば、案内推定部１０７は、案内推定モデルＭ２に対し、推定ユーザ情報を入力する。案内推定モデルＭ２は、当該入力された推定ユーザ情報の埋め込み表現を計算し、埋め込み表現に応じた支払支援サービスを識別可能な情報を出力する。案内推定部１０７は、案内推定モデルＭ２から出力された情報を取得する。

【0157】

案内部１０６は、推定ユーザに対し、案内推定部１０７により推定された適切な支払支援サービスを案内する。例えば、案内部１０６は、複数の支払支援サービスのうち、案内推定部１０７により推定された適切な支払支援サービスを、推定ユーザに対して案内する。個々の支払支援サービスの案内の内容を示すデータは、データ記憶部１００に予め記憶されているものとする。

【0158】

変形例２－６の支払支援システム１は、推定ユーザ情報と、案内推定モデルＭ２と、に基づいて、適切な支払支援サービスを推定する。支払支援システム１は、推定ユーザに対し、案内推定部１０７により推定された適切な支払支援サービスを案内する。これにより、支払支援システム１は、案内推定モデルＭ２を利用して適切な支払支援サービスを推定することによって、より適切な支払支援サービスを案内できるようになる。

【0159】

［３－３．その他の変形例］
例えば、上記説明した変形例を組み合わせてもよい。

【0160】

例えば、管理者端末１０で実現されるものとして説明した機能は、支払支援システム１における少なくとも１つのコンピュータにより実現されるようにすればよく、複数のコンピュータで機能が分担されてもよい。この場合、複数のコンピュータの各々が、他のコンピュータに対し、自身の処理結果を送信することによって、機能の分担が実現されるようにすればよい。例えば、管理者端末１０で実現されるものとして説明した機能は、サーバ２０により実現されてもよい。

【0161】

［６．付記］
例えば、本開示に係る支払支援システムは、下記のような構成も可能である。
（１）
支払の支援に関する支払支援サービスの案内に関する推定が行われる推定ユーザに関する推定ユーザ情報を取得する推定ユーザ情報取得部と、
前記推定ユーザ情報と、前記推定に関する案内推定モデルと、に基づいて、前記推定ユーザの前記推定を実行する案内推定部と、
前記推定ユーザの前記推定の実行結果に基づいて、前記推定ユーザに対し、前記支払支援サービスを案内する案内部と、
を含む支払支援システム。
（２）
前記案内推定モデルは、前記支払支援サービスを案内する適切なタイミングを推定するモデルであり、
前記案内推定部は、前記推定ユーザ情報と、前記案内推定モデルと、に基づいて、前記推定ユーザにとっての前記適切なタイミングを推定し、
前記案内部は、前記案内推定部により推定された前記適切なタイミングで、前記推定ユーザに対し、前記支払支援サービスを案内する、
（１）に記載の支払支援システム。
（３）
前記案内推定部は、前記案内推定モデルの訓練のための訓練ユーザに関する訓練ユーザ情報と、前記訓練ユーザにとって適切な前記案内と、の関係が学習された前記案内推定モデルに基づいて、前記推定を実行する、
（１）又は（２）に記載の支払支援システム。
（４）
前記支払支援システムは、前記支払支援サービスにおける複数のユーザの各々に関するユーザ情報に基づいて、前記複数のユーザの各々を分類する分類部を更に含み、
前記訓練ユーザは、前記複数のユーザのうち、特定の分類の前記ユーザである、
（３）に記載の支払支援システム。
（５）
前記分類部は、前記複数のユーザの各々の前記ユーザ情報と、アップリフトモデリングと、に基づいて、前記複数のユーザの各々を分類し、
前記特定の分類は、前記アップリフトモデリングにおける説得可能層である、
（４）に記載の支払支援システム。
（６）
前記推定ユーザも、前記複数のユーザのうち、前記アップリフトモデリングにおける説得可能層の前記ユーザである、
（５）に記載の支払支援システム。
（７）
前記特定の分類は、前記支払支援サービスを相対的に利用することを示し、
前記推定ユーザは、前記支払支援サービスを相対的に利用していないユーザである、
（４）～（６）の何れかに記載の支払支援システム。
（８）
前記案内推定部は、
前記推定ユーザ情報と、前記支払に関する余力の推定に関する余力推定モデルと、に基づいて、前記推定ユーザの前記余力を推定し、
当該推定された余力と、前記案内推定モデルと、に基づいて、前記推定ユーザの前記推定を実行する、
（１）～（７）の何れかに記載の支払支援システム。
（９）
前記推定ユーザ情報は、前記推定ユーザに対して期待される利益を示し、
前記案内推定部は、前記推定ユーザの前記利益と、前記案内推定モデルと、に基づいて、前記推定ユーザの前記推定を実行する、
（１）～（８）の何れかに記載の支払支援システム。
（１０）
前記推定ユーザ情報は、前記推定ユーザによる支払額を示し、
前記案内推定部は、前記推定ユーザの前記支払額と、前記案内推定モデルと、に基づいて、前記推定ユーザの前記推定を実行する、
（１）～（９）の何れかに記載の支払支援システム。
（１１）
前記案内推定モデルは、前記支払支援サービスの案内に関する複数の態様の中から、前記推定ユーザにとって適切な態様を推定するモデルであり、
前記案内推定部は、前記推定ユーザ情報と、前記案内推定モデルと、に基づいて、前記適切な態様を推定し、
前記案内部は、前記案内推定部により推定された前記適切な態様で、前記推定ユーザに対し、前記支払支援サービスを案内する、
（１）～（１０）の何れかに記載の支払支援システム。
（１２）
前記案内推定モデルは、複数の前記支払支援サービスの中から、前記推定ユーザにとって適切な前記支払支援サービスを推定するモデルであり、
前記案内推定部は、前記推定ユーザ情報と、前記案内推定モデルと、に基づいて、前記適切な支払支援サービスを推定し、
前記案内部は、前記推定ユーザに対し、前記案内推定部により推定された前記適切な支払支援サービスを案内する、
（１）～（１１）の何れかに記載の支払支援システム。
（１３）
前記支払支援サービスは、前記推定ユーザのクレジットカードに付帯するサービスである、
（１）～（１２）の何れかに記載の支払支援システム。

【符号の説明】

【0162】

１ 支払支援システム、Ｎ ネットワーク、１０ 管理者端末、１１，２１，３１ 制御部、１２，２２，３２ 記憶部、１３，２３，３３ 通信部、２０ サーバ、３０ ユーザ端末、１４，３４ 操作部、１５，３５ 表示部、Ｍ 電子メール、Ｍ１ 余力推定モデル、Ｍ２ 案内推定モデル、ｔ１ 時点、１００ データ記憶部、１０１ 分類部、１０２ 訓練データ作成部、１０３ 学習部、１０４ 推定ユーザ情報取得部、１０５ 余力推定部、１０６ 案内部、１０７ 案内推定部、２００ データ記憶部、２０１ サービス提供部、３００ データ記憶部、３０１ 表示制御部、３０２ 操作受付部、ＤＢ１ ユーザデータベース、ＤＢ２ 訓練データベース。

【要約】      （修正有）

【課題】支払支援サービスの利用を促進する、支払支援サービスの案内方法及びプログラムを提供する。
【解決手段】支払支援システムにおいて、管理者端末１０は、支払の支援に関する支払支援サービスの案内に関する推定が行われる推定ユーザに関する推定ユーザ情報を取得する推定ユーザ情報取得部１０４と、推定ユーザ情報と、推定に関する案内推定モデルと、に基づいて、推定ユーザの前記推定を実行する案内推定部１０７と推定ユーザの推定の実行結果に基づいて、推定ユーザに対し、支払支援サービスを案内する案内部１０６と、を備える。
【選択図】図８

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】