特許 7597978 推定装置、推定方法、およびプログラム

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

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

(11)【特許番号】

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

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

(54)【発明の名称】推定装置、推定方法、およびプログラム

(51)【国際特許分類】

   G06Q 30/015 20230101AFI20241203BHJP

【ＦＩ】

G06Q30/015

【請求項の数】 10

(21)【出願番号】P 2024117793

(22)【出願日】2024-07-23

【審査請求日】2024-07-23

【早期審査対象出願】

(73)【特許権者】

【識別番号】519110124

【氏名又は名称】ＰａｙＰａｙ株式会社

(74)【代理人】

【識別番号】100149548

【弁理士】

【氏名又は名称】松沼 泰史

(74)【代理人】

【識別番号】100181124

【弁理士】

【氏名又は名称】沖田 壮男

(74)【代理人】

【識別番号】100194087

【弁理士】

【氏名又は名称】渡辺 伸一

(72)【発明者】

【氏名】樫村 龍成

(72)【発明者】

【氏名】神津 秀人

(72)【発明者】

【氏名】杉山 宣行

(72)【発明者】

【氏名】深瀬 貴之

(72)【発明者】

【氏名】田中 万智

【審査官】上田 智志

(56)【参考文献】

【文献】特許第７３１５８０３（ＪＰ，Ｂ１）

【文献】特開２０２２－１１３６７５（ＪＰ，Ａ）

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

Ｇ０６Ｑ １０／００－９９／００

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

【請求項1】

電子決済サービスの利用者に関する推定用利用者情報を取得する取得部と、
取得した前記推定用利用者情報を、前記電子決済サービスの利用者に関する推定用利用者情報が入力されると、前記利用者が、前記電子決済サービスに関する問い合わせを行う可能性を表す指標値を、前記問い合わせの内容の分類を表すカテゴリについて出力するように学習された学習済みモデルに入力することによって、前記利用者に関する前記指標値を取得する推定部と、を備える、
推定装置。

【請求項2】

前記推定用利用者情報は、前記利用者が利用者端末装置上で閲覧した前記電子決済サービスに関するヘルプ情報の閲覧履歴と、前記電子決済サービスにおける前記利用者のステータス情報と、前記利用者による前記電子決済サービスを用いた電子決済の決済履歴と、前記利用者に関するデモグラフィック情報と、前記決済履歴に基づいて推定された前記利用者の行動年齢と、のうちの少なくとも一つを含む、
請求項１に記載の推定装置。

【請求項3】

前記学習済みモデルは、前記推定用利用者情報が入力されると、前記利用者が、前記電子決済サービスに関する問い合わせを行う可能性を表す指標値を所定カテゴリについて出力するように学習されたものである、
請求項１又は２に記載の推定装置。

【請求項4】

前記学習済みモデルは、前記推定用利用者情報が入力されると、前記利用者が、前記電子決済サービスに関する問い合わせを行う可能性を表す指標値を複数のカテゴリについて出力するように学習されたものである、
請求項１又は２に記載の推定装置。

【請求項5】

電子決済サービスの利用者に関する推定用利用者情報を取得する取得部と、
取得した前記推定用利用者情報を、前記電子決済サービスの利用者に関する推定用利用者情報が入力されると、前記利用者が、前記電子決済サービスに関する問い合わせを行う可能性を表す指標値を出力するように学習された学習済みモデルに入力することによって、前記利用者に関する前記指標値を取得する推定部と、を備え、
前記学習済みモデルは、前記推定用利用者情報に対して、前記利用者が前記電子決済サービスのサポートに対して送信した問い合わせデータのカテゴリを示すアノテーションを対応付けた教師データに基づいて学習されたものである、
推定装置。

【請求項6】

取得した前記指標値に基づいて、前記利用者が利用する利用者端末装置に、前記問い合わせに関連する補助情報を出力させる出力部を更に備える、
請求項１に記載の推定装置。

【請求項7】

前記出力部は、取得した前記指標値が閾値以上の場合にのみ、前記利用者端末装置に、前記問い合わせに関連する補助情報を出力させる、
請求項６に記載の推定装置。

【請求項8】

前記出力部は、前記補助情報として、前記問い合わせに関連する説明情報が記載された前記電子決済サービスのページへのリンクを前記利用者端末装置に出力させる、
請求項６に記載の推定装置。

【請求項9】

コンピュータが、
電子決済サービスの利用者に関する推定用利用者情報を取得し、
取得した前記推定用利用者情報を、前記電子決済サービスの利用者に関する推定用利用者情報が入力されると、前記利用者が、前記電子決済サービスに関する問い合わせを行う可能性を表す指標値を、前記問い合わせの内容の分類を表すカテゴリについて出力するように学習された学習済みモデルに入力することによって、前記利用者に関する前記指標値を取得する、
推定方法。

【請求項10】

コンピュータが、
電子決済サービスの利用者に関する推定用利用者情報を取得し、
取得した前記推定用利用者情報を、前記電子決済サービスの利用者に関する推定用利用者情報が入力されると、前記利用者が、前記電子決済サービスに関する問い合わせを行う可能性を表す指標値を出力するように学習された学習済みモデルに入力することによって、前記利用者に関する前記指標値を取得し、
前記学習済みモデルは、前記推定用利用者情報に対して、前記利用者が前記電子決済サービスのサポートに対して送信した問い合わせデータのカテゴリを示すアノテーションを対応付けた教師データに基づいて学習されたものである、
推定方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、推定装置、推定方法、およびプログラムに関する。

【背景技術】

【0002】

従来、サービスの利用者のうち、明示的に自身の抱える疑問や課題を提示しない利用者であるサイレントカスタマーの存在が知られている。例えば、特許文献１には、明示的に自身の抱える疑問や課題を提示するアクティブカスタマーから提示された課題と、サイレントカスタマーの行動履歴と、を用いて、効率的にサービス向上に資する情報を取得する技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０２２－１１３６７５号公報

【発明の概要】

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

【0004】

特許文献１に記載の技術は、アクティブカスタマーに関するパッシブデータをクラスタリングしてパッシブデータのクラスタを特定し、ユーザ全てのパッシブデータのうち、特定されたクラスタに属するデータの件数を把握することで、サイレントカスタマーを特定するものである。しかしながら、従来技術では、電子決済サービスの利用に関して疑問や課題を抱えるサイレントカスタマーを正確に推定できない場合があった。

【0005】

本発明は、このような事情を考慮してなされたものであり、電子決済サービスの利用に関して疑問や課題を抱えるサイレントカスタマーを正確に推定することができる推定装置、推定方法、およびプログラムを提供することを目的の一つとする。

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

【0006】

本発明の一態様は、電子決済サービスの利用者に関する推定用利用者情報を取得する取得部と、取得した前記推定用利用者情報を、前記電子決済サービスの利用者に関する推定用利用者情報が入力されると、前記利用者が、前記電子決済サービスに関する問い合わせを行う可能性を表す指標値を出力するように学習された学習済みモデルに入力することによって、前記利用者に関する前記指標値を取得する推定部と、を備える推定装置である。

【発明の効果】

【0007】

本発明の一態様によれば、電子決済サービスの利用に関して疑問や課題を抱えるサイレントカスタマーを正確に推定することができる推定装置、推定方法、およびプログラムを提供することができる。

【図面の簡単な説明】

【0008】

【図1】電子決済サービスが実現されるための構成の一例を示す図である。

【図2】電子決済の大まかな流れを例示したシーケンス図（その１）である。

【図3】電子決済の大まかな流れを例示したシーケンス図（その２）である。

【図4】第１実施形態に係る決済サーバ１００の構成図である。

【図5】利用者情報１７２の内容の一例を示す図である。

【図6】加盟店／店舗情報１７６の内容の一例を示す図である。

【図7】決済アプリ２０によって表示されるヘルプ情報の画面遷移の一例を示す図である。

【図8】決済アプリ２０によって表示されるヘルプ情報の画面遷移の一例を示す図である。

【図9】教師データ１７８の内容の一例を示す図である。

【図10】学習済みモデル１８０の構成の一例を示す図である。

【図11】出力部１４６によって出力される通知情報の一例を示す図である。

【図12】出力部１４６によって出力される通知情報の別の例を示す図である。

【図13】出力部１４６によって出力される通知情報のさらに別の例を示す図である。

【図14】推定部１４４による推定結果と対応チャネルとの対応関係の一例を示すテーブルである。

【図15】情報管理部１４０によって実行される処理の流れの一例を示すフローチャートである。

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

【0009】

以下、図面を参照し、本発明の推定装置、推定方法、およびプログラムの実施形態について説明する。以下に登場する「サーバ」、「管理装置」「情報提供装置」などの、利用者にサービスを提供したり内部解析を行ったりするための各種装置は、分散化された装置群によって実現されてよく、それぞれの装置を運用する事業者は異なってもよい。また装置のハードウェアの保有者（クラウドサーバの提供者）と実質的な運用を行う事業者も異なってよい。アプリケーションプログラムと決済サーバは、協働して電子決済サービスを提供する。以下の説明ではアプリケーションプログラムを決済アプリと称する。電子決済サービスは、店舗における商品やサービスの購買に係る決済をサポートするサービスである。店舗とは、例えば、現実空間に存在する物理的な店舗（実店舗）であるが、電子商取引の仮想店舗を含んでもよい。仮想店舗は、電子決済サービスの運営者とは異なる主体によって提供されるものを含んでもよい。その場合、仮想店舗における買い物の決済の際に、電子決済サービスのインターフェース画面に遷移するように制御される。電子決済サービスにおいて、店舗は、例えば加盟店（ブランド）に属するものとして扱われ、店舗において購買行動が行われた際の決済などの処理は、主として利用者と加盟店の間で行われる。これに代えて、決済などの処理が利用者と店舗との間で行われてもよい。

【0010】

［電子決済サービス］
図１は、電子決済サービスが実現されるための構成の一例を示す図である。電子決済サービスは、決済サーバ１００を中心として実現される。決済サーバ１００は、例えば、一以上の利用者端末装置１０、一以上の第１店舗端末装置５０、及び一以上の第２店舗端末装置７０のそれぞれとネットワークＮＷを介して通信する。ネットワークＮＷは、例えば、インターネット、ＬＡＮ（Local Area Network）、無線基地局、プロバイダ装置などを含む。

【0011】

利用者端末装置１０は、例えば、スマートフォンやタブレット端末等の可搬型端末装置である。利用者端末装置１０は、少なくとも、光学読取機能、通信機能、表示機能、入力受付機能、プログラム実行機能を有するコンピュータ装置である。以下の説明では、これらの機能を実現するための構成をそれぞれカメラ、通信装置、タッチパネル、ＣＰＵ（Central Processing Unit）等と称する。利用者端末装置１０では、ＣＰＵ等のプロセッサにより決済アプリ２０が実行されることで、決済サーバ１００と連携して電子決済サービスを利用者に提供するように動作する。決済アプリ２０は、例えば、アプリケーションストアから利用者端末装置１０にインストールされ、カメラ、通信装置、タッチパネルなどを制御する。

【0012】

第１店舗端末装置５０は、例えば、店舗に設置される。第１店舗端末装置５０は、少なくとも、商品価格取得機能、光学読取機能、プログラム実行機能、通信機能を有するコンピュータ装置である。第１店舗端末装置５０は、いわゆるＰＯＳ（Point of Sale）装置を含み、ＰＯＳ装置によって商品価格取得機能や光学読取機能を実現してもよい。店舗コード画像６０は、店舗に置かれ、ＱＲコード（登録商標）等のコード画像が紙やプラスチックの媒体に印刷されたものである。なお、店舗コード画像６０は、店舗に置かれたディスプレイ（スマートフォンなどの端末装置のディスプレイでもよい）によって表示されてもよい。

【0013】

第２店舗端末装置７０は、加盟店の運営者によって使用される。第２店舗端末装置７０は、スマートフォンやタブレット端末、パーソナルコンピュータ等である。第２店舗端末装置７０では、加盟店向けインターフェース７２が動作する。加盟店向けインターフェース７２は、加盟店向けアプリであってもよいし、ブラウザであってもよい。加盟店向けインターフェース７２は、加盟店の運営者によるクーポンの設定等を受け付け、決済サーバ１００に送信する。スマートフォンである第２店舗端末装置７０は、加盟店向けアプリを実行することで、店舗コード画像に相当するコード画像を表示したり、利用者端末装置１０が表示するコード画像を読み取ったりする機能を有する。

【0014】

決済サーバ１００は、利用者端末装置１０または第１店舗端末装置５０から受信した決済情報に基づいて電子決済を実現する。第１店舗端末装置５０は、ＰＯＳ装置と加盟店サーバを含む場合があり、その場合、ＰＯＳ装置から加盟店サーバを介して決済情報が決済サーバ１００に送信される。以下の説明では、これを特に区別せず、第１店舗端末装置５０から決済情報が送信されるものとする。

【0015】

図２および図３は、電子決済の大まかな流れを例示したシーケンス図である。電子決済には、パターン１とパターン２の二つが存在してよい。

【0016】

図２に示すパターン１（以下、ユーザスキャンと称する）の場合、決済アプリ２０が起動した状態の利用者端末装置１０が、光学読取機能によって店舗コード画像６０をデコードする（Ｓ１）。店舗コード画像６０には、店舗ＵＲＬ（Uniform Resource Locator）の情報が含まれている。この店舗ＵＲＬは、電子決済サービスのドメインに対して店舗を識別可能な情報が付加されたものであり、決済サーバ１００において加盟店ＩＤや店舗ＩＤ等との対応付けがなされている（後述）。決済アプリ２０は、店舗ＵＲＬとアカウントＩＤを含む第１決済情報を決済サーバ１００に送信する（Ｓ２）。決済サーバ１００は、店舗ＵＲＬに対応する加盟店ＩＤ、店舗ＩＤから、店舗情報（後述）を検索して加盟店名と店舗名の情報を取得し（Ｓ３）、決済アプリ２０に送信する（Ｓ４）。利用者は、加盟店名や店舗名が表示された画面において、決済金額を利用者端末装置１０に入力する（Ｓ５）。そして、利用者端末装置１０は、少なくとも決済金額を含む第２決済情報を生成し、決済サーバ１００に送信する（Ｓ６）。決済サーバ１００は、受信した第２決済情報に基づいて電子決済を行う（Ｓ７）。そして、決済サーバ１００は、決済完了通知（決済完了画面を表示するための情報）を決済アプリ２０に送信し（Ｓ８）、決済アプリ２０は決済完了画面を表示する（Ｓ９）。なお、店舗コード画像６０が店舗に置かれたディスプレイによって表示される場合、店舗コード画像６０には、店舗ＵＲＬだけでなく決済金額の情報が含まれる場合がある。この場合、利用者が決済金額を入力する手順が省略され、第１決済情報に決済金額の情報が含められて決済サーバ１００に送信される。加盟店名や店舗名の情報は、決済完了画面に含めて表示されてよい。

【0017】

図３に示すパターン２（以下、ストアスキャンと称する）の場合、決済アプリ２０の起動時、決済アプリ２０において支払う操作が行われたとき、自動更新のタイミング（例えば１分おき）になったとき、およびその他のタイミングで、決済アプリ２０はワンタイムコードの発行要求を決済サーバ１００に送信する（Ｓ１１）。決済サーバ１００はワンタイムコードを生成し（Ｓ１２）、決済アプリ２０に送信する（Ｓ１３）。決済アプリ２０は、ワンタイムコードに基づいて生成した、ＱＲコードやバーコード等のコード画像を表示する（Ｓ１４）。利用者は利用者端末装置１０の表示面を第１店舗端末装置５０に翳し（提示し）、第１店舗端末装置５０は、光学読取機能によってコード画像をデコードし、ワンタイムコード等を取得する（Ｓ１５）。そして、第１店舗端末装置５０は、ワンタイムコード、決済金額、加盟店ＩＤ、店舗ＩＤ等を含む決済情報を生成し、決済サーバ１００に送信する（Ｓ１６）。決済金額の情報は、予めバーコード読み取りや手入力等によって取得されている。決済サーバ１００は、受信した情報に基づいて、ワンタイムコードに対応する利用者を特定し、電子決済を行う（Ｓ１７）。そして、決済サーバ１００は、決済完了通知を決済アプリ２０に送信し（Ｓ１８）、決済アプリ２０は決済完了画面を表示する（Ｓ１９）。

【0018】

なお、上記のいずれか一方のみのパターンで電子決済が行われてもよい。また、図２で説明した「アカウントＩＤ」は、利用者の識別情報として用いられ得る他の情報（例えば電話番号）であってもよい。また、ストアスキャンにおいてワンタイムコードの発行が省略され、決済アプリ２０は、利用者のアカウントＩＤに基づいて生成したコード画像を表示してもよい。その場合、決済サーバ１００は、ワンタイムコードに対応する利用者を特定するのに代えて、アカウントＩＤに対応する利用者を特定する。

【0019】

［決済サーバ］
図４は、第１実施形態に係る決済サーバ１００の構成図である。決済サーバ１００は、例えば、通信部１１０と、決済コンテンツ提供部１２０と、決済処理部１３０と、情報管理部１４０と、記憶部１７０とを備える。通信部１１０および記憶部１７０以外の構成要素は、例えば、ＣＰＵなどのハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）などのハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ－ＲＯＭなどの着脱可能な記憶媒体（非一過性の記憶媒体）に格納されており、記憶媒体がドライブ装置に装着されることで記憶装置にインストールされてもよい。情報管理部１４０は、さらに、取得部１４２と、推定部１４４と、出力部１４６と、を備えるが、これらの機能の詳細については後述する。決済サーバ１００のうち情報管理部１４０の機能が、「情報処理装置」の一例である。

【0020】

記憶部１７０は、ＨＤＤやフラッシュメモリ、ＲＡＭ（Random Access Memory）などである。記憶部１７０は、決済サーバ１００がネットワークを介してアクセス可能なＮＡＳ（Network Attached Storage）装置であってもよい。記憶部１７０には、利用者情報１７２、決済コンテンツ情報１７４、加盟店／店舗情報１７６、教師データ１７８、学習済みモデル１８０などの情報が格納される。

【0021】

通信部１１０は、ネットワークＮＷに接続するための通信インターフェースである。通信部１１０は、例えばネットワークインターフェースカードである。

【0022】

決済コンテンツ提供部１２０は、例えば、Ｗｅｂサーバの機能を有し、電子決済サービスの各種画面を表示するための情報（コンテンツ）を利用者端末装置１０に提供する。決済コンテンツ提供部１２０は、決済コンテンツ情報１７４から適宜、必要なコンテンツを読み出して利用者端末装置１０に提供する。利用者端末装置１０は、決済アプリ２０によってコンテンツが再生された状態で利用者による各種入力を受け付け、前述した決済情報などを決済サーバ１００に送信する。

【0023】

決済処理部１３０は、利用者端末装置１０または第１店舗端末装置５０により送信された決済情報に基づいて、決済処理を行う。決済処理部１３０は、利用者情報１７２を参照しながら決済処理を行う。

【0024】

図５は、利用者情報１７２の内容の一例を示す図である。利用者情報１７２は、利用者の登録情報の一例である。利用者情報１７２は、例えば、利用者ＵＲＬ、アカウントＩＤ、電話番号、パスワードの他、メールアドレス、利用者ＩＤ、性別、氏名・住所・生年月日、登録日、本人確認の済／未済、チャージ残高、クレジット払い設定、クレジット払い枠、クレジット払い利用額、クレジット払い利用可能額、決済方法設定、銀行口座、クレジットカード番号、チャージ履歴情報、決済履歴情報などの情報が対応付けられたものである。利用者ＵＲＬは、利用者間の送金処理に使用される。電子決済サービスへの新規登録時には、電話番号およびパスワードの登録が必須となる。アカウントＩＤは、決済サーバ１００によって利用者に発行されるものであり、利用者ＩＤは、利用者が任意に設定できる（設定しなくてもよい）ＩＤである。メールアドレス、および氏名・住所・生年月日も同様に、利用者が任意に設定できる（設定しなくてもよい）情報である。登録日とは利用者が電子決済サービスに登録した日（アカウントを作成した日）である。本人確認とは、例えば、利用者が、自身の本人確認書類（例えば、運転免許証などの公的身分証明書）を、決済アプリ２０を用いて決済サーバ１００にアップロードすることによって、本人確認を完了させたか否かを示す情報であり、「済」と「未」のいずれかに設定される。本人確認が「済」となった場合、利用者は、以下で説明するチャージ残高の銀行口座への出金などが可能となる。以下、これらの情報が対応付けられた利用者のインスタンス（電子決済口座）のことをアカウントと称する。

【0025】

チャージ残高は、利用者が予めアカウントに送金することで設定された電子マネーの残高を示す情報である。送金の手段としては、指定業者（銀行）のＡＴＭ（Automatic Teller Machine）からの送金、登録された銀行口座からの送金などがある。クレジット払い設定は、クレジット払いによる電子決済を可能とするための設定が済んでいるか否かを示す情報であり、「済」と「未」のいずれかに設定される。クレジット払い枠は月ごとに利用可能なクレジット払いの限度額であり、クレジット払い利用額は、当月に既に利用されたクレジット払いの金額であり、クレジット払い利用可能額は、クレジット払い枠からクレジット払い利用額を差し引いて求められる、当月に利用可能なクレジット払いの金額である。図ではクレジット払い枠を一つだけ示しているが、実際には更に日ごとの上限額などが存在し、それらの低い方がクレジット払い枠に設定されてよい。クレジット払いの更なる詳細については後述する。決済方法設定は、その時点において利用者がチャージ残高による電子決済を行うのか、クレジット払いによる決済を行うのかを示す設定情報である。銀行口座とクレジットカード番号のそれぞれは、電子決済サービスに入金可能な銀行口座またはクレジットカード番号の情報（口座番号、カード番号）である。チャージ履歴情報は、利用者が予め電子決済サービスに送金してチャージ残高を増加させた履歴である。決済履歴情報は、利用者が行った決済の内訳（日時、購買行動が行われた店舗の店舗ＩＤ、決済金額、決済方法など）を、決済ごとに示す情報である。なお、図５では、記載を省略しているが、利用者情報１７２は、利用者が電子決済の実行によって獲得したポイントに関する情報を更に記憶してもよい。ポイントは、利用者が行った電子決済の決済金額に応じて付与されるものであり、付与されたポイントは、例えば、次回の電子決済の決済金額の割引に使用することができる。

【0026】

図６は、加盟店／店舗情報１７６の内容の一例を示す図である。加盟店／店舗情報１７６は、例えば、店舗ＵＲＬに対して加盟店ＩＤと店舗ＩＤが対応付けられた第１テーブル１７６Ａと、加盟店ＩＤに対して加盟店名と売上金（前述）が対応付けられた第２テーブル１７６Ｂと、店舗ＩＤに対して店舗名が対応付けられた第３テーブル１７６Ｃとを含む。加盟店／店舗情報１７６には、これらの情報の他、加盟店または店舗のカテゴリ、店舗の所在地、決済パターン等の情報が含まれてもよい。

【0027】

情報管理部１４０は、利用者端末装置１０や第２店舗端末装置７０から取得した情報に基づいて、利用者情報１７２および加盟店／店舗情報１７６を管理する。情報管理部１４０は、利用者情報１７２および加盟店／店舗情報１７６について新規レコードの追加、編集、削除などを行う。

【0028】

［電子決済］
決済処理部１３０は、利用者端末装置１０または第１店舗端末装置５０から決済情報が取得されると、利用者情報１７２を参照して当該利用者の「決済方法設定」を取得する。決済処理部１３０は、「決済方法設定」が「チャージ残高」に設定されている利用者に関して、以下のように電子決済を行う。決済処理部１３０は、例えば、利用者ＩＤに対応付けて管理しているチャージ残高を減少させ、加盟店の売上金の項目値を増加させることで、電子決済を行う。加盟店の売上金の項目値は、例えば、それ自体が電子マネーとして使用されるものでは無く、加盟店と電子決済サービスとの取り決めに応じたサイクルで、売上金の項目値に対応する金額が銀行口座に送金される。

【0029】

決済処理部１３０は、「設定情報」が「クレジット払い」に設定されている利用者に関して、以下のように電子決済を行う。クレジット払いとは、電子決済サービスの運営者とは別主体であるクレジットカード会社との連携による支払い方法であり、電子決済サービスの運営者が与信者となって、クレジット払い枠の範囲内でチャージ残高に依存しない電子決済を許容するものである。なおクレジット払いサービスを受けるために、電子決済サービスの運営者が提供するクレジットカードの取得が要求されてよい。クレジット払いで利用された金額は、一か月分まとめて翌月の支払日に、例えば銀行口座からの引き落としによって決済される。この場合、決済処理部１３０は、クレジット払い利用額に決済金額を加算し、クレジット払い利用可能額から同額を差し引くことで暫定決済を行い、締め日になると上記のように当月分の決済を翌月の支払い日に引き落とすための処理を行う、或いはクレジットカード会社の運営者に当該処理を依頼する。なお暫定決済の時点で決済金額がクレジット払い利用可能額を超える場合は、エラー通知が決済アプリ２０に返信される。

【0030】

［ヘルプ情報］
このように、電子決済サービスに登録した利用者は、決済アプリ２０を用いて、加盟店の店舗において電子決済を行うことができる。しかしながら、上述した通り、利用者が決済アプリ２０を用いて電子決済を行うためには、アカウントの作成、利用者情報の登録、本人確認の実施、銀行口座またはクレジットカード番号の登録など、複数の操作をこなす必要があり、利用者の中には、その内容に疑問を抱いたり、操作の実行に失敗したりすることもある。そのため、電子決済サービスは、決済アプリ２０上で、利用者が参照可能なヘルプ情報を提供する。

【0031】

図７は、決済アプリ２０によって表示されるヘルプ情報の画面遷移の一例を示す図である。図７の左部に示す画面は、例えば、利用者が決済アプリ２０のトップ画面上で、ヘルプ情報を示す項目を選択することによって表示されるものである。ヘルプ情報は、例えば、検索キーワードの入力に応じて、チャットボットに当該検索キーワードに応じた回答を出力させるための表示領域Ａ１と、利用者の疑問内容を分類するカテゴリに応じた説明内容を出力するための表示領域Ａ２と、電子決済サービスのサポートに問い合わせるための表示領域Ａ３とを含む。ここで、チャットボットは、大規模言語モデル(ＬＬＭ)を搭載し、自然言語によって利用者と会話を行うように学習されたＡＩ型のチャットボットであってもよいし、利用者が入力した検索キーワードに類似する回答を選択肢として出力する非ＡＩ型のチャットボットであってもよい。

【0032】

より具体的には、図７の左部において、表示領域Ａ２は、利用者の疑問内容を分類するカテゴリの一例として、支払い方法に関する利用者の疑問内容を表す支払いカテゴリＣ１と、チャージ方法に関する利用者の疑問内容を表すチャージカテゴリＣ２と、アカウント設定に関する利用者の疑問内容を表すアカウントカテゴリＣ３とを含む。表示領域Ａ２は、さらに、クリックに応じて、これらカテゴリの詳細情報を表示するためのアコーディオンボタンＢ１～Ｂ３を含む。表示領域Ａ３は、例えば、電子決済サービスのカスタマーサービスに直接問い合わせるための問い合わせフォームに遷移するリンクＬ１を含む。表示領域Ａ３は、さらに、電子決済サービスのカスタマーサービスの電話番号を含んでいてもよいし、リンクＬ１は、クリックに応じて、問い合わせフォームではなく、利用者端末装置１０にインストールされたメーラーを立ち上げるものであってもよい。

【0033】

例えば、利用者が、支払いカテゴリＣ１に対応するボタンＢ１をクリックした場合、図７の右部に示す通り、決済アプリ２０は、支払いカテゴリＣ１に含まれ、支払い方法に関する利用者の疑問内容をさらに詳細に分類する子カテゴリＣ１＿１～Ｃ１＿３を表示領域Ａ４に表示させる。図７では、一例として、支払いカテゴリＣ１の子カテゴリとして、チャージ残高での支払い方法に関する利用者の疑問内容を表す子カテゴリＣ１＿１と、クレジット払いでの支払い方法に関する利用者の疑問内容を表す子カテゴリＣ１＿２と、ポイントでの支払い方法に関する利用者の疑問内容を表す子カテゴリＣ１＿３とを表している。

【0034】

利用者が、これら子カテゴリＣ１＿１～Ｃ１＿３の領域のいずれかをクリックすると、決済アプリ２０は、例えば、クリックされた子カテゴリＣ１＿１～Ｃ１＿３に対応する説明内容を記載したページ（すなわち、ヘルプ情報を記載したページ）に遷移させる。

【0035】

図８は、決済アプリ２０によって表示されるヘルプ情報の画面遷移の一例を示す図である。図８の左部に示す画面は、図７の右部に示す画面に対応する。例えば、図８の左部に示す画面において、利用者が子カテゴリＣ１＿１の領域をクリックすると、決済アプリ２０は、チャージ残高での支払い方法に関する説明を記載したページに遷移させる。その結果、図８の右部に示す画面において、利用者は、電子決済サービスにおいて、チャージ残高で支払いを行う方法を理解することができる。

【0036】

［学習済みモデルの生成］
このように、利用者は、チャットボット機能、カテゴリ別のヘルプ情報閲覧機能、サポートへの問い合わせ機能を活用して、電子決済サービスに関する疑問や課題を解決することができる。しかしながら、利用者は、自身の疑問や課題を解決するために、これら機能を能動的に選択および活用することが求められるため、電子決済サービスの利用者の中には、何らかの疑問や課題を抱きつつ、十分にこれら機能を活用できない場合があった。その結果、このような、電子決済サービスの利用に関して疑問や課題を抱えるサイレントカスタマーに対するサービスの利便性が低下する場合があった。

【0037】

このような事情を背景にして、本実施形態では、利用者の推定用利用者情報が入力されると、当該利用者が、電子決済サービスに関する問い合わせを行う可能性を表す指標値を出力するように学習された学習済みモデル１８０を生成し、生成した学習済みモデル１８０を用いて、利用者のうちのサイレントカスタマーを推定する。その後、推定したサイレントカスタマーに対して、例えば、ポップアップ通知により、ヘルプ情報や現在のステータス情報を通知する。これにより、サイレントカスタマーに対するサービスの利便性を向上させることができる。この場合の通知は、ポップアップ通知に限定されず、利用者端末装置１０に搭載されたＳＭＳ（short message service）機能を利用した通知であってもよいし、決済アプリ２０上で出力されるプッシュ通知であってもよい。以下、図９および図１０を参照して、学習済みモデル１８０を生成するための用いる教師データ１７８の内容、および学習済みモデル１８０の構成について、詳細に説明する。

【0038】

図９は、教師データ１７８の内容の一例を示す図である。教師データ１７８は、例えば、教師データＩＤに対して、入力を構成するヘルプ閲覧履歴、ステータス情報、決済履歴、デモグラフィック情報と、出力を構成する問い合わせカテゴリとが対応付けられたものである。教師データ１７８の各レコードは、例えば、利用者が、問い合わせフォームやメールなどを介して、実際にサポートに問い合わせを行ったデータ（例えば、問い合わせフォームデータやメールデータ）から収集され、問い合わせを行った利用者に関する推定用利用者情報に対して、問い合わせのカテゴリを示すアノテーションが対応付けられたものである。

【0039】

ヘルプ閲覧履歴は、問い合わせを行った利用者が、問い合わせ前に、決済アプリ２０上で、電子決済サービスに関するヘルプ情報を閲覧した履歴を表す情報である。ヘルプ閲覧履歴は、例えば、利用者が、図７および図８に示した画面上で、どのような行動を取ったか（例えば、どのような順序でどのページを閲覧し、或いは、どのような検索キーワードで検索を行ったか）を含むものである。図９では、説明の簡潔性のため、ヘルプ閲覧履歴は、利用者の行動内容のみが示されているが、追加的に、例えば、利用者がヘルプ情報を閲覧した日時情報および各ページにおける滞在時間などの情報を含んでもよい。

【0040】

ステータス情報は、問い合わせを行った利用者の、問い合わせ時点における電子決済サービスでのステータスを表す情報である。ステータス情報は、例えば、本人確認が「済」であるか「未」であるか、利用者が決済アプリ２０に登録してからの登録期間（ダウンロードしてから期間や、本人確認を行ってからの期間であってもよい）、エラーの発生有無およびその詳細を含むものである。決済履歴は、利用者情報１７２に記録された決済履歴の一部又は全てを含むものである。

【0041】

デモグラフィック情報は、利用者の年齢や性別などの属性を表す情報である。デモグラフィック情報は、利用者の利用者情報１７２から収集および記録されてもよい。図９では、説明の簡潔性のため、デモグラフィック情報は、利用者の年齢および性別を含んでいるが、代替的に／追加的に、利用者の生年月日、住所、職業、年収などの情報を含んでもよい。行動年齢は、利用者の実年齢とは異なり、利用者の決済アプリ２０を用いた行動に基づいて算出された年齢である。行動年齢の算出方法として、例えば、利用者の決済履歴に基づいて、当該利用者が、特定のカテゴリや店舗（例えば、アミューズメントなどのカテゴリや、コンビニエンスストア、ゲームセンターなどの店舗）で頻繁に決済している場合、利用者の行動年齢は低く算出されてもよい。また、別の例として、電子決済サービスにおいて、利用者全体の決済履歴を年齢層別に分類して特徴量（例えば、決済単価、決済時間帯、カテゴリ、地域など）を算出し、ある利用者について、最も特徴量が類似する年齢層を行動年齢として算出してもよい。

【0042】

問い合わせカテゴリは、問い合わせを行った利用者の問い合わせ内容を、例えば、図７および図８を介して説明したカテゴリに対応付けたアノテーションを表す情報である。問い合わせカテゴリは、基本的には、電子決済サービスの運営者が、利用者の問い合わせ内容を確認した際に手動で対応付けるものである。図９の例では、利用者の問い合わせ内容が、カテゴリＣ１～Ｃ３のいずれかに対応付けられているが、本発明はそのような構成に限定されず、利用者の問い合わせ内容は、小カテゴリ（例えば、カテゴリＣ１の場合、小カテゴリＣ１＿１～Ｃ１＿３）に対応付けられてもよい。

【0043】

図１０は、学習済みモデル１８０の構成の一例を示す図である。図１０に示す通り、学習済みモデル１８０は、図９を介して説明した教師データ１７８に基づいて、ヘルプ閲覧履歴、ステータス情報、決済履歴、デモグラフィック情報を含む推定用利用者情報を入力として、正解データである問い合わせカテゴリを出力するように（より正確には、正解データである問い合わせカテゴリを表す指標値が最も高くなるように）、ディープニューラルネットワーク（ＤＮＮ：deep neural network）などの機械学習モデルを学習することによって、生成されるものである。図１０では、一例として、学習済みモデル１８０が、サイレントカスタマーの推定対象となる利用者の推定用利用者情報の入力に応じて、当該利用者が各カテゴリに関する疑問を抱いている確率値を出力するように学習されている。確率値は、特許請求の範囲における「電子決済サービスに関する問い合わせを行う可能性を表す指標値」の一例である。

【0044】

別の態様として、学習済みモデル１８０は、各カテゴリに対応する確率値ではなく、複数のカテゴリのうちの正解カテゴリを示す値（例えば、１）を出力するように学習されたものであってもよい。また、別の態様として、学習済みモデル１８０は、単一のカテゴリについて、利用者が当該カテゴリに関する疑問を抱いている確率値を出力するように学習されてもよい。その場合、教師データ１７８の正解データは、当該単一のカテゴリについて、利用者が問い合わせを行ったという行為そのものを示すフラグとなる。この場合、学習済みモデル１８０は複数用意され、複数の学習済みモデル１８０から出力された確率値のうち、最大値を出力した学習済みモデル１８０に対応するカテゴリが選択されることとなる。

【0045】

学習済みモデル１８０が生成されると、取得部１４２は、サイレントカスタマーであるか否かを推定する対象となる利用者に関する推定用利用者情報を取得し、推定部１４４は、取得した推定用利用者情報を学習済みモデル１８０に入力することによって、当該利用者に関する指標値を取得する。推定部１４４は、例えば、取得した指標値が閾値以上である場合、当該利用者はサイレントカスタマーであると推定することができる。推定部１４４は、利用者が決済アプリ２０を利用中の任意のタイミングで推定用利用者情報を取得し、学習済みモデル１８０に入力してもよい。例えば、推定部１４４は、利用者が決済アプリ２０を起動したタイミングや、決済アプリ２０上で所定イベントを実行したタイミング（例えば、アカウント登録時、本人確認の成功／失敗時、チャージの成功／失敗時、電子決済の成功／失敗時、ヘルプ情報閲覧時、利用者情報１７２の変更時など）で推定用利用者情報を取得し、学習済みモデル１８０に入力してもよい。また、例えば、推定部１４４は、利用者の推定用利用者情報を定期的に取得し、取得した推定用利用者情報の内容が変更されたタイミングで、当該推定用利用者情報を学習済みモデル１８０に入力してもよい。これにより、以下で説明する出力部１４６は、利用者にとって必要なタイミングで通知情報を利用者端末装置１０に出力することができる。

【0046】

［通知情報の出力］
ある利用者がサイレントカスタマーであると推定された場合、出力部１４６は、例えば、利用者端末装置１０に、当該利用者が潜在的に抱いていると思われる疑問や課題に関連するポップアップ通知を出力させる。後述する通り、この時出力されるポップアップ通知は、確率値が最も高い「問い合わせカテゴリ」に応じた内容を含む。これにより、サイレントカスタマーであると推定された利用者は、チャットボット機能、カテゴリ別のヘルプ情報閲覧機能、サポートへの問い合わせ機能などを能動的に活用する必要なく、自身が抱く疑問や課題を解決することができる。ポップアップ通知は、特許請求の範囲における「補助情報」の一例である。

【0047】

図１１は、出力部１４６によって出力される通知情報の一例を示す図である。図１１の左部は、図１０に示す状況において、学習済みモデル１８０がチャージカテゴリＣ２について最大の確率値（すなわち、０．６）を出力したことに応じて、出力部１４６が利用者端末装置１０にポップアップ通知Ｐ１を出力した例を表している。このとき、出力部１４６は、学習済みモデル１８０によって出力された最大の確率値が閾値（例えば、０．５）以上の場合にのみ、利用者端末装置１０にポップアップ通知Ｐ１を出力してもよい。図１１の左部では、一例として、ポップアップ通知Ｐ１は、利用者が電子決済サービスのチャージに関して疑問や課題を有しているか否かを問い合わせるとともに、チャージに関するヘルプ情報に遷移するためのリンクＬ２を表示させている。

【0048】

利用者が利用者端末装置１０上でリンクＬ２をクリックすると、決済アプリ２０は、利用者端末装置１０の表示画面をヘルプ情報に遷移させる。このとき、決済アプリ２０は、チャージカテゴリＣ２について最も大きな確率値が出力されているため、図１１の右部に示す通り、予め、チャージカテゴリＣ２が選択された状態（すなわち、アコーディオンボタンＢ２が押下された状態）でヘルプ情報を表示させてもよい。その結果、電子決済サービスのチャージに関して疑問や課題を有していると推定される利用者は、自身の操作によってヘルプ情報にアクセスしたり、アコーディオンボタンＢ２を押下する必要なく、電子決済サービスのチャージに関するヘルプ情報を迅速に確認することができる。

【0049】

なお、図１１では、一例として、ポップアップ通知Ｐ１が、ヘルプ情報へのリンクＬ２を表示している場合を示しているが、本発明はそのような構成に限定されず、ポップアップ通知Ｐ１は、ヘルプ情報そのものの内容を含んでいてもよい。例えば、学習済みモデル１８０が、小カテゴリの確率値を出力するように構成されている場合には、当該小カテゴリに対応するヘルプ情報の内容をポップアップ通知Ｐ１は含んでもよい。これにより、利用者は、ヘルプ情報をさらに迅速に確認することができる。さらに、ポップアップ通知Ｐ１は、ヘルプ情報へのリンクやヘルプ情報そのものの内容に加えて、利用者のステータス情報（例えば、本人確認「済」／「未」など）を含んでもよい。これにより、利用者は、自身の課題を解決する手がかりを得ることができる。

【0050】

上述した通り、推定部１４４は、利用者が決済アプリ２０を利用中の任意のタイミングや所定イベントが発生したタイミングで推定用利用者情報を取得し、学習済みモデル１８０に入力してもよく、出力部１４６は、これらタイミングでポップアップ通知Ｐ１を利用者端末装置１０に出力する。その場合、例えば、出力部１４６は、当該所定イベントが問題の発生に対応する場合（本人確認の失敗、チャージの失敗、電子決済の失敗など）には、ポップアップ通知Ｐ１に、当該問題を示す状況通知（「チャージできない状況です」など）と、ヘルプ情報へのリンクやヘルプ情報そのものの内容と、を含めてもよい。このとき、出力部１４６は、状況に応じて（例えば、直近期間の利用者の決済回数が閾値未満になった場合など）、ポップアップ通知Ｐ１に、問い合わせフォームに遷移するリンクＬ１や、電子決済サービスのカスタマーサービスの電話番号を含めてもよい。また、例えば、出力部１４６は、当該所定イベントが規定イベントの発生に対応する場合（アカウント登録や本人確認の完了など）には、ポップアップ通知Ｐ１に、当該規定イベントを示す状況通知（「アカウント登録が完了しました。決済方法を登録しましょう」など）と、ヘルプ情報へのリンクやヘルプ情報そのものの内容と、を含めてもよい。この場合、出力部１４６は、ヘルプ情報に代えて、規定イベントの次のイベントに対応するチュートリアル情報を、プッシュ通知やＳＭＳによって決済アプリ２０に出力してもよい。より一般的に、出力部１４６は、所定イベントの分類に応じて、決済アプリ２０に出力する通知情報の態様を変更してもよい。このように、出力部１４６は、利用者が具体的な問題（本人確認の失敗、チャージの失敗、電子決済の失敗など）に直面したタイミングでのサポート（proactive support）のみならず、決済アプリ２０上で規定イベント（アカウント登録や本人確認の完了など）が発生したタイミングでの利用者への支援（proactive onboarding）を提供することが可能となり、サイレントカスタマーをより広範な状況や場面において補助することができる。

【0051】

図１２は、出力部１４６によって出力される通知情報の別の例を示す図である。図１２の左部は、図１０に示す状況と同様、学習済みモデル１８０が、支払いカテゴリＣ１について０．３、チャージカテゴリＣ１について０．６、アカウントカテゴリＣ３について０．１の確率値を出力した場合を表している。図１２の右部に示す通り、このとき、出力部１４６は、最大の確率値に対応するカテゴリのみならず、例えば、学習済みモデル１８０が出力した確率値の大きさの順に、ポップアップ通知Ｐ１に、ヘルプ情報へのリンクやヘルプ情報そのものを含ませて表示させてもよい。これにより、基本的には、利用者が疑問や課題を抱いている可能性がより高いヘルプ情報を優先的に提示しつつ、学習済みモデル１８０が誤って最大の確率値を出力した場合であっても、利用者を補助することができる。

【0052】

図１３は、出力部１４６によって出力される通知情報の別の例を示す図である。図１１では、一例として、学習済みモデル１８０によって出力された確率値が閾値（例えば、０．５）以上の場合に、出力部１４６がヘルプ情報へのリンクＬ２を利用者端末装置１０に表示させている場合を表している。一方、図１３に示す通り、出力部１４６は、学習済みモデル１８０によって出力された確率値が、上記閾値よりも大きい第２閾値（例えば、０．８）以上の場合、ヘルプ情報に代えて／加えて、電子決済サービスのカスタマーサービスに直接問い合わせるための問い合わせフォームに遷移するリンクＬ１をポップアップ通知Ｐ１に表示させてもよい（すなわち、ポップアップ通知Ｐ１の情報を充実させてもよい）。すなわち、出力部１４６は、学習済みモデル１８０によって出力された確率値の大きさに応じて、ポップアップ通知Ｐ１に含める情報を段階的に変更してもよい。

【0053】

別の態様として、出力部１４６は、利用者のヘルプ閲覧履歴、ステータス情報、決済履歴、デモグラフィック情報、又は行動年齢に関する条件と組み合わせて、ポップアップ通知Ｐ１に含める情報を変更してもよい。例えば、上記の閾値に関する判定に加えて、出力部１４６は、利用者の行動年齢（又はデモグラフィック情報の年齢）が低い場合には、チャットボット機能を利用するように利用者を誘導する（例えば、チャットボット機能へのリンクを表示させる）一方、利用者の行動年齢が高い場合には、問い合わせフォームに遷移するリンクＬ１をポップアップ通知Ｐ１に表示させてもよい。また、例えば、出力部１４６は、利用者のヘルプ閲覧履歴を参照して、当該利用者がヘルプ情報を閲覧した履歴が存在する場合、これは、利用者が既にヘルプ情報を確認済みであることが推定されるため、出力部１４６は、ポップアップ通知Ｐ１にヘルプ情報へのリンクＬ２を含めることなく、チャットボット機能又は問い合わせフォームに利用者を誘導してもよい。また、例えば、利用者の決済頻度が低いか、又は電子決済サービスへの登録期間が短い場合、出力部１４６は、チャットボット機能又はヘルプ情報へのリンクＬ２に代えて／加えて、問い合わせフォームに遷移するリンクＬ１をポップアップ通知Ｐ１に表示させてもよい。

【0054】

さらに、出力部１４６は、学習済みモデル１８０によって出力された確率値が上記第２閾値以上の場合や、利用者の行動年齢（又はデモグラフィック情報の年齢）が高い場合や、緊急度が高い場合には、問い合わせフォームに遷移するリンクＬ１に代えて／合わせて、電子決済サービスのカスタマーサービスの電話番号をポップアップ通知Ｐ１に表示させてもよい。ここで、「緊急度が高い場合」とは、例えば、決済アプリ２０上で所定の問題（本人確認の失敗、チャージの失敗、電子決済の失敗など）が発生した場合を意味する。

【0055】

さらに、出力部１４６は、推定部１４４によって推定されたサイレントカスタマーの問い合わせカテゴリや小カテゴリに応じて、解決の可能性がより高い対応チャネルを選択し、選択した対応チャネルに誘導するためのポップアップ通知Ｐ１を利用者端末装置１０に出力してもよい。

【0056】

図１４は、推定部１４４による推定結果と対応チャネルとの対応関係の一例を示すテーブルである。図１４に示すテーブルは、一例として、問い合わせカテゴリとチャネルとの対応関係を表しているが、小カテゴリ（すなわち、個別の課題）とチャネルとの対応関係を表してもよい。電子決済サービスの運営者は、事前に各問い合わせカテゴリ又は小カテゴリに対して、利用者がどのチャネルを用いて問題を解決した頻度が高いかを事前に計測し、その対応関係を記録することによって、図１４に示すテーブルを事前に定義しておけばよい。この場合、問題を解決したチャネルは、例えば、各利用者が決済アプリ２０内での検索行動を終了したタイミングで最後に利用していたチャネルとして特定することができる。出力部１４６は、サイレントカスタマーについて、推定部１４４によってある問い合わせカテゴリが推定された場合、図１４のテーブルを参照して対応チャネルを選択し、選択した対応チャネルに誘導するためのポップアップ通知Ｐ１を利用者端末装置１０に出力する。

【0057】

テーブルに定義される対応関係の別の例として、出力部１４６は、推定部１４４による推定結果が、チャットボットによって解決可能な課題（例えば、チャージの上限金額に関する疑問）を示す場合、対応チャネルとしてチャットボットを選択してもよい。より詳細には、問い合わせ内容によってチャットボットで解決完結できる率が異なるため、ボットでのセルフ解決率が高い課題、例えば、単に「チャージ上限のみを知りたい」という問いであれば、ボットに誘導をする。また、例えば、出力部１４６は、推定部１４４による推定結果が、説明的な案内が不要な課題（例えば、ポイント支払い設定）を示す場合、出力部１４６は、対応チャネルとして、チャットボットやヘルプ情報ではなく、決済アプリ２０の設定画面（例えば、ポイント支払い設定画面）を選択してもよい。より詳細には、「ポイントを支払いに使いたいが、どこから設定すればいいのか分からない」という問いに対しては、ポイントの利用設定画面にディープリンクで飛ばすためのリンクを画面にポップアップで表示する。このような問いは、特にボットなどでの説明的な案内が不要で、設定画面に直接誘導すればいいからである。また、例えば、出力部１４６は、推定部１４４による推定結果が、説明的な案内が必要な課題（例えば、本人確認の写真撮影エラー）を示す場合、対応チャネルとして、ヘルプ情報を選択してもよい。案内を十分に読んでもらいたい、或いは、図での説明のほうが分かりやすい場合は、ヘルプやガイドに誘導する。「eKYCの写真撮影でエラーになっているが、どうすればいいのか」の問いには、「eKYCできない」のヘルプページで証明書類の撮影方法のヒントを図で示しているため、ヘルプへのリンクをSMSで送るといった案内が有効であるからである。また、例えば、出力部１４６は、推定部１４４による推定結果が、トラブルシューティングや窓口での手続きが必要な課題（例えば、意図しないチャージの取り消し）を示す場合、対応チャネルとして、問い合わせフォームや電子決済サービスのカスタマーサービスの電話番号を選択してもよい。窓口での特別対応の検討が必要であるため、問い合わせ窓口に誘導することが有効だからである。このように、推定部１４４による推定結果に応じて、適切な対応チャネルを事前に定義し、振り分けを行うことによって、サイレントカスタマーの満足度を向上させることができる。

【0058】

［処理の流れ］
次に、図１５を参照して、情報管理部１４０によって実行される処理の流れについて説明する。図１５は、情報管理部１４０によって実行される処理の流れの一例を示すフローチャートである。図１５に示すフローチャートの処理は、例えば、ある利用者が、決済アプリ２０を起動したタイミングや、決済アプリ２０を利用中の任意のタイミングで実行されるものである。

【0059】

まず、取得部１４２は、電子決済サービスに関する問い合わせを行う可能性を推定する利用者の推定用利用者情報を取得する（ステップＳ１００）。次に、推定部１４４は、取得した推定用利用者情報を、学習済みモデル１８０に入力する（ステップＳ１０２）。

【0060】

次に、出力部１４６は、学習済みモデル１８０から出力されたあるカテゴリの確率値が閾値以上であるか否かを判定する（ステップＳ１０４）。学習済みモデル１８０から出力されたあるカテゴリの確率値が閾値以上であると判定された場合、出力部１４６は、当該カテゴリに関するポップアップ通知を利用者端末装置１０に出力する（ステップＳ１０６）。一方、学習済みモデル１８０から出力された確率値がどのカテゴリについても閾値未満であると判定された場合、情報管理部１４０は処理を終了する。これにより、本フローチャートの処理が終了する。

【0061】

なお、本実施形態では、説明の便宜上、決済サーバ１００（特に、取得部１４２、推定部１４４、出力部１４６）の機能と、決済アプリ２０の機能とを区別しているが、本発明はそのような構成に限定されず、決済サーバ１００の機能の一部は、決済アプリ２０に搭載されていてもよい。例えば、決済アプリ２０は、利用者に関する推定用利用者情報を取得して、決済アプリ２０の内部又は外部にある学習済みモデル１８０に入力することによって、確率値を取得してもよい。逆に、決済アプリ２０の機能の一部は、決済サーバ１００に搭載されていてもよい。例えば、利用者端末装置１０上に表示されたリンクがクリックされたことによる画面遷移およびヘルプ情報の表示は、出力部１４６が、利用者端末装置１０を制御することによって実現してもよい。

【0062】

さらに、本実施形態では、出力部１４６は、利用者端末装置１０の決済アプリ２０上にポップアップ通知を出力している。しかし、本発明はそのような構成に限定されず、出力部１４６は、ポップアップ通知ではなく、単に、決済アプリ２０の表示画面（例えば、トップ画面やアカウント設定画面）の一部に、上述したポップアップ通知の内容を出力してもよい。

【0063】

以上説明した実施形態によれば、電子決済サービスの利用者に関する推定用利用者情報を取得し、取得した推定用利用者情報を、電子決済サービスの利用者に関する推定用利用者情報が入力されると、利用者が、電子決済サービスに関する問い合わせを行う可能性を表す指標値を出力するように学習された学習済みモデルに入力することによって、利用者に関する指標値を取得する。これにより、電子決済サービスの利用に関して疑問や課題を抱えるサイレントカスタマーを正確に推定することができる。

【0064】

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

【符号の説明】

【0065】

１０ 利用者端末装置
２０ 決済アプリ
１００ 決済サーバ
１１０ 通信部
１２０ 決済コンテンツ提供部
１３０ 決済処理部
１４０ 情報管理部
１４２ 取得部
１４４ 推定部
１４６ 出力部

【要約】

【課題】電子決済サービスの利用に関して疑問や課題を抱えるサイレントカスタマーを正確に推定すること。
【解決手段】電子決済サービスの利用者に関する推定用利用者情報を取得する取得部と、取得した前記推定用利用者情報を、前記電子決済サービスの利用者に関する推定用利用者情報が入力されると、前記利用者が、前記電子決済サービスに関する問い合わせを行う可能性を表す指標値を出力するように学習された学習済みモデルに入力することによって、前記利用者に関する前記指標値を取得する推定部と、を備える、推定装置。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】