JP2024091812A - 提供装置、提供方法及び提供プログラム - Google Patents

Abstract

【課題】決済サービスの連携先として適切なサービスの情報を利用者に提供する。
【解決手段】本願に係る提供装置は、所定の決済手段に関する決済サービスの提供先となる利用者に関する利用者情報を取得する取得部と、取得部により取得された利用者情報に基づいて、決済サービスの連携先である連携サービスに関する連携サービス情報を提供する優先度を連携サービスごとに決定する決定部と、決定部により決定された優先度に基づいて、連携サービス情報を所定の決済手段を提供するプラットフォームを介して利用者に提供する提供部とを有することを特徴とする。
【選択図】図１

Description

本発明は、提供装置、提供方法及び提供プログラムに関する。

従来、インターネットを介して様々な情報を利用者に提供する技術が知られている。このような技術の一例として、インターネット上で、サービス利用者の求めるサービス要求を受信し、そのサービス要求を満足する１つ以上の提案をサービス提供者から受け取り、サービス利用者へ送信する技術が知られている。

特開２０１８－０６０２５３号公報

しかしながら、上述した技術では、決済サービスの連携先として適切なサービスの情報を利用者に提供しているとは言えない場合がある。

例えば、上述した技術では、飲食店、美容院、ネイルサロンなどの店舗のサービスを提案しているに過ぎず、決済サービスの連携先として適切なサービスの情報を利用者に提供しているとは言えない。

本願は、上記に鑑みてなされたものであって、決済サービスの連携先として適切なサービスの情報を利用者に提供することを目的とする。

本願に係る提供装置は、所定の決済手段に関する決済サービスの提供先となる利用者に関する利用者情報を取得する取得部と、前記取得部により取得された利用者情報に基づいて、前記決済サービスの連携先である連携サービスに関する連携サービス情報を提供する優先度を連携サービスごとに決定する決定部と、前記決定部により決定された優先度に基づいて、前記連携サービス情報を前記所定の決済手段を提供するプラットフォームを介して前記利用者に提供する提供部とを有することを特徴とする。

実施形態の一態様によれば、決済サービスの連携先として適切なサービスの情報を利用者に提供できるという効果を奏する。

図１は、実施形態に係る提供処理の一例を示す図である。 図２は、実施形態に係る利用者端末の画面の一例を示す図（１）である。 図３は、実施形態に係る利用者端末の画面の一例を示す図（２）である。 図４は、実施形態に係る決済サーバの構成例を示す図である。 図５は、実施形態に係る口座データベースの一例を示す図である。 図６は、実施形態に係る利用者情報データベースの一例を示す図である。 図７は、実施形態に係る提供処理の手順の一例を示すフローチャートである。 図８は、決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に本願に係る提供装置、提供方法及び提供プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る提供装置、提供方法及び提供プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．実施形態〕
図１を用いて、本実施形態の提供装置等により実現される提供処理について説明する。図１は、実施形態に係る提供処理の一例を示す図である。なお、図１では、本実施形態に係る提供装置の一例である決済サーバ１０によって、実施形態に係る提供処理などが実現されるものとする。

図１に示すように、実施形態に係る提供処理システム１は、決済サーバ１０と、利用者端末１００と、店舗端末２００と、サービスサーバ３００とを含む。決済サーバ１０、利用者端末１００、店舗端末２００及びサービスサーバ３００は、ネットワークＮ（例えば、図４参照）を介して有線または無線により相互に通信可能に接続される。ネットワークＮは、例えば、インターネットなどのＷＡＮ（Wide Area Network）である。なお、図１に示した提供処理システム１には、複数台の決済サーバ１０、複数台の利用者端末１００、複数台の店舗端末２００及び複数台のサービスサーバ３００が含まれていてもよい。

図１に示す決済サーバ１０は、実施形態に係る提供処理を実行する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。例えば、決済サーバ１０は、利用者端末１００を用いる電子決済に関する電子決済サービスを提供する。例えば、決済サーバ１０は、取引対象の提供者（事業者）や取引対象が提供される利用者の口座を管理しており、利用者からの決済要求に従って、口座間において電子マネーの移行等を行うことで、各種決済を実現する。なお、電子マネーとは、例えば、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドル等の国家により提供される貨幣を電子的に取引可能としたものであってもよい。

図１に示す利用者端末１００は、利用者によって利用される情報処理装置である。利用者端末１００は、例えば、スマートフォンや、タブレット型端末、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ、携帯電話機、ＰＤＡ（Personal Digital Assistant）等により実現される。また、利用者端末１００は、決済サーバ１０によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１に示す例では、利用者端末１００がスマートフォンである場合を示す。

なお、利用者端末１００は、所定の情報処理を実現する制御情報を決済サーバ１０から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）等のスクリプト言語やＣＳＳ（Cascading Style Sheets）等のスタイルシート言語、Ｊａｖａ（登録商標）等のプログラミング言語、ＨＴＭＬ（HyperText Markup Language）等のマークアップ言語等により記述される。なお、決済サーバ１０から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。

図１に示す店舗端末２００は、利用者に取引対象を提供する事業者によって利用される情報処理装置である。店舗端末２００は、例えば、ＰＯＳ（Point of Sales）端末や、スマートフォン、タブレット型端末、ノート型ＰＣ、デスクトップＰＣ、携帯電話機、ＰＤＡ等により実現される。また、店舗端末２００は、決済サーバ１０によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。

なお、図１に示す例では、店舗端末２００が店舗に設置されたＰＯＳ端末であり、店舗において提供する商品に関する商品情報を管理するものとする。例えば、店舗端末２００は、商品の価格を、商品に添付されるバーコードが示す情報（商品を識別するための識別情報（商品ＩＤ））に紐づけて管理する。

図１に示すサービスサーバ３００は、利用者にネットワークＮを介してサービスを提供し、提供したサービスにおける利用者の利用履歴を管理する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。なお、サービスサーバ３００が提供するウェブサービスは、例えば、検索サービス、ナビゲーションサービス、ニュース配信サービス、オークションサービス、天気予報サービス、ショッピングサービス、ファイナンスサービス、路線検索サービス、地図提供サービス、旅行サービス、飲食店紹介サービス、施設予約サービス、ＳＮＳ（Social Networking Service）サービス、ウェブブログサービスなどであってもよい。また、サービスサーバ３００は、例えば、利用者端末１００にインストールされた各種アプリケーションに関するコンテンツを配信するウェブサービスを提供してもよい。具体的な例を挙げると、サービスサーバ３００は、ポータルアプリ、ナビゲーションアプリ、ニュースアプリ、オークションサイト、天気予報アプリ、ショッピングアプリ、ファイナンス（株価）アプリ、路線検索アプリ、地図提供アプリ、旅行アプリ、飲食店紹介アプリ、施設予約アプリ、ＳＮＳアプリ、ブログ閲覧アプリ等に関するコンテンツを配信するサービスを提供してもよい。

なお、サービスサーバ３００は、決済サーバ１０が提供する電子決済用のアプリケーション（以下、単に「決済アプリ」と記載する場合がある）内で起動するアプリケーション（ミニアプリ）において利用者にサービスを提供してもよい。

〔１－１．利用者端末１００を用いた決済について〕
ここで、決済サーバ１０が実行する通知処理に先立ち、利用者端末１００を用いた決済（電子決済）の一例について説明する。なお、以下の説明では、店舗Ａに配置された２次元コード（ＱＲコード（登録商標））であって、店舗Ａを識別する店舗識別情報Ｃ１を示す２次元コードを用いて、利用者Ｕ１が利用者端末１００を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意の利用者が任意の利用者端末１００を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報Ｃ１は、ＱＲコードのみならず、バーコードや所定のマーク、番号等であってもよい。

例えば、利用者Ｕ１が店舗Ａにて各種の商品やサービスといった決済対象（取引対象）の利用や購入に伴う決済を行う場合、利用者Ｕ１は、利用者端末１００に予めインストールされた決済アプリを起動する。そして、利用者Ｕ１は、決済アプリを介して、店舗Ａに設置された店舗識別情報Ｃ１を撮影する。このような場合、利用者端末１００は、決済対象の価格を入力するための画面を表示し、利用者Ｕ１或いは店舗Ａの店員から決済金額の入力を受け付ける。そして、利用者端末１００は、利用者Ｕ１を識別する利用者識別情報と、店舗識別情報Ｃ１（若しくは、店舗識別情報Ｃ１が示す情報、すなわち、店舗Ａ（若しくは店舗Ａを管理する事業者Ｍ１）を示す情報（例えば、店舗ＩＤ））と、決済金額とを示す決済情報を決済サーバ１０へと送信する。

このような場合、決済サーバ１０は、利用者識別情報が示す利用者Ｕ１の口座から、店舗識別情報Ｃ１が示す店舗Ａの口座へと、決済金額が示す額の電子マネーを移行させる。そして、決済サーバ１０は、決済が完了した旨の通知を利用者端末１００へと送信する。このような場合、利用者端末１００は、決済が完了した旨の画面や所定の音声を出力することで、電子マネーによる決済が行われた旨を通知する。

なお、利用者端末１００を用いた決済は、上述した処理に限定されるものではない。例えば、利用者端末１００を用いた決済は、店舗Ａに設置された店舗端末２００を用いたものであってもよい。例えば、利用者端末１００は、利用者Ｕ１を識別するための利用者識別情報を画面上に表示させる。このような場合、店舗Ａに設置された店舗端末２００は、利用者端末１００に表示された利用者識別情報を読み取り、利用者識別情報（若しくは、利用者識別情報が示す情報、すなわち、利用者Ｕ１を示す情報（例えば、利用者ＩＤ））と、決済金額と、店舗Ａを識別する情報とを示す決済情報を決済サーバ１０へと送信する。このような場合、決済サーバ１０は、利用者識別情報が示す利用者Ｕ１の口座から、店舗Ａの口座へと、決済金額が示す額の電子マネーを移行させ、店舗Ａの店舗端末２００或いは利用者端末１００に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。

また、利用者端末１００を用いた決済は、実店舗に対するものに限らず、例えば、決済サーバ１０が提供する電子決済サービスと、任意のサービスとのＡＰＩ連携を通じたオンライン決済であってもよい。このような場合、例えば、利用者端末１００は、利用者Ｕ１を識別する利用者識別情報と、サービスの提供者を識別する提供者識別情報と、当該サービスにおける取引対象の価格（決済金額）とを示す決済情報を決済サーバ１０へと送信する。そして、決済サーバ１０は、利用者識別情報が示す利用者Ｕ１の口座から、提供者識別情報が示す提供者の口座へと、決済金額が示す額の電子マネーを移行させ、利用者端末１００に対し決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知する。

また、利用者端末１００を用いた決済は、利用者Ｕ１が予め電子マネーをチャージした口座から店舗Ａの口座へと電子マネーを移行させる処理のみならず、例えば、利用者Ｕ１が予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、決済サーバ１０は、店舗Ａの口座に対して決済金額の電子マネーを移行させるとともに、利用者Ｕ１のクレジットカードの運用会社（カード会社）に対し、決済金額を請求してもよい。

また、利用者端末１００を用いた決済は、例えば、いわゆるデビットカードと同様に、利用者Ｕ１が予め登録した銀行口座からの即時口座振替により行われてもよい。このような場合、例えば、決済サーバ１０は、決済金額を利用者Ｕ１の銀行口座から引き落とすとともに、電子決済における利用者Ｕ１の口座に決済金額分の電子マネーをチャージし、店舗Ａの口座に対して決済金額の電子マネーを移行させる。

〔１－２．実施形態の概要について〕
ここで、従来、インターネットを介して様々な情報を利用者に提供する技術の一例として、インターネット上で、サービス利用者の求めるサービス要求を受信し、そのサービス要求を満足する１つ以上の提案をサービス提供者から受け取り、サービス利用者へ送信する技術が知られている。しかしながら、このような技術では、店舗のサービスを提案しているに過ぎず、決済サービスの連携先として適切なサービスの情報を利用者に提供しているとは言えない。

そこで、決済サーバ１０は、実施形態に係る提供処理を実行する。以下、図１を用いて、決済サーバ１０が実行する提供処理について説明する。なお、以下の説明では、利用者端末１００が利用者Ｕ１により利用される例を示す。また、以下の説明では、利用者端末１００を利用者Ｕ１と同一視し、店舗端末２００を事業者Ｍ１とする場合がある。すなわち、以下では、利用者Ｕ１を利用者端末１００と読み替え、事業者Ｍ１を店舗端末２００と読み替えることもできる。

まず、決済サーバ１０は、上述した決済アプリを用いて利用者Ｕ１が店舗Ａに対して行った決済に関する決済情報を店舗端末２００から取得する（ステップＳ１）。例えば、決済サーバ１０は、店舗Ａの店舗ＩＤや、店舗端末２００がバーコードリーダ等により商品に添付されたバーコードから読み取った商品ＩＤ、利用者端末１００に表示された利用者Ｕ１の利用者ＩＤ、決済金額などを含む決済情報を店舗端末２００から取得する。

続いて、サービスサーバ３００は、利用者Ｕ１に提供した各種のサービスにおいて、利用者Ｕ１が入力した検索クエリを示す検索履歴を収集する（ステップＳ２）。続いて、決済サーバ１０は、サービスサーバ３００が収集した利用者Ｕ１の検索履歴を取得する（ステップＳ３）。

続いて、決済サーバ１０は、決済アプリにおける利用者Ｕ１に関する情報を利用者端末１００から取得する（ステップＳ４）。例えば、決済サーバ１０は、決済アプリにおける本人確認のための情報（個人情報等）や、決済アプリにおける利用者Ｕ１の口座に電子マネーの入金（チャージ）を行う銀行の口座（言い換えると、電子決済サービスに連携済みである銀行の口座。以下、「チャージ用口座」と記載する場合がある）に関する情報などを取得する。また、決済サーバ１０は、上述した決済アプリを用いて利用者Ｕ１が各店舗に対して行った決済に関する決済情報や、決済を行った際の利用者Ｕ１の位置情報（例えば、利用者端末１００が有するＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）により測位された位置情報）を取得する。

続いて、決済サーバ１０は、利用者端末１００や、店舗端末２００、サービスサーバ３００などから取得した利用者Ｕ１に関する利用者情報に基づいて、電子決済サービスの連携先である連携サービスに関する連携サービス情報を利用者Ｕ１に提供する優先度を決定する（ステップＳ５）。なお、図１の例において、決済サーバ１０が、連携サービス情報として、電子決済サービスに連携する新たな銀行に関する情報を提供するものとする。この場合、利用者Ｕ１が電子決済サービスに連携済みである銀行以外の銀行であって、利用者Ｕ１が口座を開設していると推定される銀行に関する連携サービス情報の優先度を決定する。例えば、決済サーバ１０は、利用者の決済情報や、検索履歴、個人情報、位置情報などを含む利用者情報に基づいて、利用者が口座を保有すると推定される銀行に関する連携サービス情報ほど、優先度を高く設定する。具体的な例を挙げると、決済サーバ１０は、利用者Ｕ１の決済アプリを用いた消費行動の拠点となるエリア（例えば、利用者Ｕ１が居住するエリアや、利用者Ｕ１の通勤先のエリアなど）に所在する銀行に関する連携サービス情報の優先度を、他のエリアに所在する銀行に関する連携サービス情報よりも高く設定する。また、決済サーバ１０は、連携サービス情報に対応する銀行に関する検索クエリが利用者Ｕ１の検索履歴に多く含まれるほど、当該連携サービス情報の優先度を高く設定する。また、決済サーバ１０は、利用者Ｕ１が居住するエリアの地方銀行に関する連携サービス情報の優先度を、他の銀行に関する連携サービス情報よりも高く設定する。

続いて、決済サーバ１０は、連携サービス情報を利用者端末１００に提供する（ステップＳ６）。ここで、図１の例において、決済サーバ１０が、チャージ用口座の追加に関する要求を利用者端末１００から受け付けたものとする。この場合、決済サーバ１０は、利用者Ｕ１が電子決済サービスに連携済みである銀以外の銀行に関する連携サービス情報を、優先度に基づく表示態様で表示するコンテンツを利用者端末１００に提供する。

続いて、利用者端末１００は、決済サーバ１０から提供された連携サービス情報に基づいて、決済アプリを介して連携サービスを選択するための画面を表示する（ステップＳ７）。続いて、利用者Ｕ１は、利用者端末１００に表示される連携サービスのうち、希望する連携サービスを選択する（ステップＳ８）。例えば、利用者Ｕ１は、自身が口座を保有する銀行を選択し、当該口座をチャージ用口座として登録するための情報（例えば、支店名や、口座番号など）を利用者端末１００に入力する。

ここで、図２を用いて、上述した実施形態において利用者端末１００が表示する画面の例を説明する。図２は、実施形態に係る利用者端末の画面の一例を示す図（１）である。

図２に示すように、利用者端末１００は、チャージ用口座を追加するための画面ＳＣ１を表示する。例えば、利用者端末１００は、銀行名等の検索クエリを入力するための領域ＡＲ１と、連携先の銀行を選択するための領域であって、各連携サービス情報に対応する各銀行を優先度に応じて表示する領域である領域ＡＲ２と、各連携サービス情報（バナー広告等）を優先度に応じて表示する領域ＡＲ３とを含む画面ＳＣ１を表示する。具体的な例を挙げると、利用者端末１００は、連携サービス情報のうち、優先度の上位９件に含まれる連携サービス情報に対応する銀行を領域ＡＲ２に表示する。

ここで、領域ＡＲ１が選択された場合、言い換えると、利用者Ｕ１が連携先として希望する銀行が領域ＡＲ２に表示されておらず、他の銀行の表示を利用者Ｕ１が希望した場合、利用者端末１００は、画面ＳＣ１を画面ＳＣ２に遷移させる。例えば、利用者端末１００は、領域ＡＲ１と、連携先の銀行を選択するための領域であって、領域ＡＲ２に表示したものの次に優先度が高い連携サービス情報に対応する銀行を表示する領域である領域ＡＲ４とを含む画面ＳＣ２を表示する。なお、利用者Ｕ１が領域ＡＲ１に検索クエリを入力した場合、当該検索クエリに対応する銀行のサジェストを、対応する連携サービス情報の優先度が高い順に表示してもよい。

なお、利用者端末１００により表示される連携サービス情報は図２の態様に限定されず、決済アプリにより表示される任意の画面に連携サービス情報が表示されてもよい。ここで、図３を用いて、利用者端末１００が表示する連携サービス情報の態様の一例を説明する。図３は、実施形態に係る利用者端末の画面の一例を示す図（２）である。

図３に示すように、利用者端末１００は、決済アプリを起動した際、ホーム画面として画面ＳＣ３を表示する。例えば、利用者端末１００は、決済アプリ内で起動するミニアプリ等を表示する領域ＡＲ５と、連携サービス情報（バナー広告）を表示する領域ＡＲ６とを含む画面ＳＣ３を表示する。具体的な例を挙げると、利用者端末１００は、連携サービス情報を、優先度が高い順に領域ＡＲ６に表示する。

図１に戻り説明を続ける。続いて、決済サーバ１０は、連携サービスを示す情報を利用者端末１００から受け付ける（ステップＳ９）。例えば、決済サーバ１０は、利用者が選択した銀行を示す情報や、チャージ用口座として登録するための情報などを利用者端末１００から受け付ける。

続いて、決済サーバ１０は、電子決済サービスと、連携サービスとを連携させる処理を実行する（ステップＳ１０）。例えば、決済サーバ１０は、利用者Ｕ１の利用者ＩＤと、ステップＳ９において受け付けた情報が示す口座とを紐付ける。

以上のように、実施形態に係る決済サーバ１０は、電子決済サービスの提供先である利用者自身の情報に基づいて、連携サービス情報を提供することができる。これにより、実施形態に係る決済サーバ１０は、地方に居住している利用者のような、地方銀行の口座を開設する傾向が強い利用者に対しては、一般的には利用者が多いメガバンクの情報がノイズとなるため、このようなノイズを抑制して情報を提供することができる。すなわち、実施形態に係る決済サーバ１０は、決済サービスの連携先として適切なサービスの情報を利用者に提供できるという効果を奏する。

また、実施形態に係る決済サーバ１０は、最初に表示された銀行以外の銀行の検索を開始するための操作を利用者が行った場合には、その次に優先度の高い銀行に関する情報を表示する。これにより、実施形態に係る決済サーバ１０は、利用者がなるべく検索クエリの入力等の煩雑な操作を行わなくとも、利用者に対し適切な情報を提供することができるため、利便性を向上させることができる。

〔２．決済サーバの構成〕
次に、図４を用いて、決済サーバ１０の構成について説明する。図４は、実施形態に係る決済サーバの構成例を示す図である。図４に示すように、決済サーバ１０は、通信部２０と、記憶部３０と、制御部４０とを有する。

（通信部２０について）
通信部２０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部２０は、ネットワークＮと有線または無線で接続され、利用者端末１００、店舗端末２００、サービスサーバ等との間で情報の送受信を行う。

（記憶部３０について）
記憶部３０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図４に示すように、記憶部３０は、口座データベース３１と、利用者情報データベース３２とを有する。

（口座データベース３１について）
口座データベース３１は、利用者や店舗（事業者）などが電子決済サービスにおいて所有する口座に関する各種の情報を記憶する。ここで、図５を用いて、口座データベース３１が記憶する情報の一例を説明する。図５は、実施形態に係る口座データベースの一例を示す図である。図５の例において、口座データベース３１は、「口座ＩＤ」、「所有者情報」、「口座残高」といった項目を有する。

「口座ＩＤ」は、口座を識別するための識別情報を示す。「所有者情報」は、口座を所有する所有者に関する情報を示し、例えば、所有者を識別するための識別情報が格納される。「口座残高」は、口座の残高を示す。

すなわち、図５では、口座ＩＤ「ＡＩＤ＃１」によって識別される口座の保有者の情報が「利用者＃１」であり、口座残高が「７，８００円」である例を示す。

（利用者情報データベース３２について）
利用者情報データベース３２は、決済サーバ１０が提供する電子決済サービスの利用者に関する各種の情報を記憶する。ここで、図６を用いて、利用者情報データベース３２が記憶する情報の一例を説明する。図６は、実施形態に係る利用者情報データベースの一例を示す図である。図６の例において、利用者情報データベース３２は、「利用者ＩＤ」、「連携済サービス」、「個人情報」、「属性情報」、「検索履歴」、「決済履歴」といった項目を有する。

「利用者ＩＤ」は、利用者を識別するための識別情報を示す。「連携済サービス」は、電子決済サービスに連携済のサービスに関する情報を示す。「個人情報」は、決済アプリにおける本人確認のために利用者が登録した情報（例えば、住所）を示す。「属性情報」は、利用者の属性情報（デモグラフィック属性やサイコグラフィック属性）を示す。「検索履歴」は、利用者が各種サービスにおいて入力した検索クエリの履歴を示す。「決済履歴」は、電子決済サービスを利用して行った決済の履歴（決済情報）を示し、例えば、「決済ＩＤ」、「支払先」、「取引対象」、「決済金額」といった項目を有する。

「決済ＩＤ」は、決済を識別するための識別情報を示す。「支払先」は、支払先の情報（店舗ＩＤ等）を示す。「取引対象」は、決済の対象である取引対象を示す。「決済金額」は、支払先への決済金額を示す。「位置情報」は、決済を行った際の利用者の位置を示し、例えば、利用者端末１００により測位された位置や、支払先の店舗の所在地などといった情報が格納される。

すなわち、図６では、利用者ＩＤ「ＵＩＤ＃１」によって識別される利用者が、電子決済サービスに連携済みのサービスが「連携済サービス＃１」、個人情報が「個人情報＃１」属性情報が「属性情報＃１」、検索履歴が「検索履歴＃１」であり、決済ＩＤ「ＰＩＤ＃１」により識別される決済の支払先が「支払先＃１」、取引対象が「取引対象＃１」、決済金額が「２，０００円」、位置情報が「位置情報＃１」である例を示す。

（制御部４０について）
制御部４０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、決済サーバ１０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部４０は、コントローラであり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。実施形態に係る制御部４０は、図４に示すように、取得部４１と、決済処理部４２と、学習部４３と、決定部４４と、提供部４５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。

（取得部４１について）
取得部４１は、所定の決済手段に関する決済サービスの提供先となる利用者に関する利用者情報を取得する。例えば、図１の例において、取得部４１は、利用者端末１００や、店舗端末２００、サービスサーバ３００などから利用者Ｕ１に関する利用者情報を取得し、利用者情報データベース３２に格納する。具体的な例を挙げると、取得部４１は、店舗Ａの店舗ＩＤや、店舗端末２００がバーコードリーダ等により商品に添付されたバーコードから読み取った商品ＩＤ、利用者端末１００に表示された利用者Ｕ１の利用者ＩＤ、決済金額などを含む決済情報を店舗端末２００から取得する。また、取得部４１は、利用者Ｕ１に提供した各種のサービスにおいて、利用者Ｕ１が入力した検索クエリを示す検索履歴をサービスサーバ３００から取得する。また、取得部４１は、決済アプリにおける本人確認のための情報や、決済アプリにチャージ用口座に関する情報などを利用者端末１００から取得する。また、取得部４１は、決済アプリを用いて利用者Ｕ１が各店舗に対して行った決済に関する決済情報や、決済を行った際の利用者Ｕ１の位置情報を取得する。

（決済処理部４２について）
決済処理部４２は、決済情報に従い、決済処理を実行する。例えば、利用者識別情報と、店舗識別情報と、決済金額とを示す決済情報が利用者端末１００から送信された場合、決済処理部４２は、利用者識別情報が示す利用者の口座から、店舗識別情報が示す店舗の口座へと、決済金額が示す額の電子マネーを移行させる。また、利用者識別情報と、決済金額と、店舗識別情報とを示す決済情報が店舗端末２００から送信された場合、決済処理部４２は、利用者識別情報が示す利用者の口座から、店舗識別情報が示す店舗の口座へと、決済金額が示す額の電子マネーを移行させる。

（学習部４３について）
学習部４３は、連携サービスに関する連携サービス情報と、当該連携サービスを決済サービスに連携済の利用者に関する利用者情報との関連性に基づいて、各連携サービスの優先度を推定するようにモデルを学習させる。例えば、学習部４３は、連携サービスが提供するサービスの内容や、連携サービスが分類されるグループ（カテゴリ）などを含む連携サービス情報と、当該連携サービスを電子決済サービスに連携済の利用者の位置情報や、検索履歴、決済履歴（取引対象等）、属性、推定されるライフステージなどを含む利用者情報との関連性に基づいて、利用者情報が入力された場合に各連携サービスの優先度を推定（出力）するようにモデルを学習させる。

具体的な例を挙げると、学習部４３は、モデルに入力される利用者情報との一致度が所定の閾値以上である利用者のうち、連携済である利用者が多い連携サービスほど優先度を高く推定するようにモデルの学習を行う。言い換えると、学習部４３は、利用者情報が入力されると、その利用者情報と対応する利用者のうち連携済みの利用者が多い連携サービス程高い値のスコア（優先度を示すスコア）を出力するように、バックプロパゲーション等の技術を用いて、モデルの学習を行うこととなる。

より具体的な例を挙げると、連携サービスとして、グループ「投資サービス」に属する連携サービスの優先度を推定する場合、学習部４３は、モデルに入力される利用者情報が示す利用者の使用言語や、金融リテラシーのレベル、投資歴との一致度が所定の閾値以上である利用者のうち、連携済である利用者が多い連携サービスほど優先度を高く推定するようにモデルの学習を行う。ここで、学習部４３は、さらに、特定の連携サービスの優先度が高く推定されるほど、当該連携サービスが提供するサービスの内容（例えば、金融商品、金利、手数料、取扱通貨等）との一致度が所定の閾値以上である他の連携サービスの優先度を高く推定するようにモデルの学習を行ってもよい。また、学習部４３は、さらに、モデルに入力される利用者情報が示す利用者に対応する利用者のうち、グループ「投資サービス」に属する連携サービスと連携済である利用者が多いほど、グループ「投資サービス」に属する連携サービスの優先度を高く推定するようにモデルの学習を行ってもよい。

なお、連携サービス＃１に関する連携サービス情報と、連携サービス＃１を電子決済サービスに連携済の利用者群＃１に関する利用者情報＃１との関連性に基づきモデルの学習を行う場合、学習部４３は、モデルに入力される利用者情報が、利用者情報＃１との一致度が高いほど、連携サービス＃１の優先度を高く推定するようにモデルの学習を行ってもよい。ここで、学習部４３は、さらに、連携サービス＃１の優先度が高いほど、連携サービス＃１が提供するサービスの内容との一致度が所定の閾値以上である連携サービスの優先度を高く推定するようにモデルの学習を行ってもよい。また、学習部４３は、さらに、連携サービス＃１の優先度が高いほど、連携サービス＃１が分類されるグループに属する連携サービスの優先度を高く推定するようにモデルの学習を行ってもよい。

また、学習部４３は、連携サービスの組み合わせと、当該組み合わせに含まれる連携サービスの各々を決済サービスに連携済の利用者に関する利用者情報とをさらにモデルに学習させてもよい。例えば、学習部４３は、電子決済サービスに連携済の連携サービスの組み合わせであって、互いに異なるグループに属する連携サービスの組み合わせの一致度が所定の閾値以上である利用者群＃１の利用者情報と、連携サービスの組み合わせとの関係性をモデルに学習させる。具体的な例を挙げると、利用者Ｕ１の利用者情報がモデルに入力される場合、学習部４３は、利用者Ｕ１の利用者情報と、利用者群＃１の利用者情報との一致度が高いほど、利用者群＃１が連携済の連携サービスのうち、利用者Ｕ１が連携させていない連携サービスの優先度を高く推定するように学習させる。

なお、モデルの学習には、任意の公知技術が適用可能であり、取得される情報に応じて適宜選択された学習手法が用いられてもよい。例えば、モデルの学習には、機械学習に関する種々の従来技術（例えば、ＳＶＭ（Support Vector Machine）等の教師あり学習の機械学習に関する技術）を用いて行われてもよい。また、モデルの学習には、深層学習（ディープラーニング）の技術が用いられてもよい。例えば、モデルの学習には、ＲＮＮ（Recurrent Neural Network）やＣＮＮ（Convolutional Neural Network）等の種々のディープラーニングの技術が用いられてもよい。

（決定部４４について）
決定部４４は、取得部４１により取得された利用者情報に基づいて、決済サービスの連携先である連携サービスに関する連携サービス情報を提供する優先度を連携サービスごとに決定する。例えば、決定部４４は、利用者情報データベース３２を参照し、電子決済サービスにおける利用者の口座に入金を行うための金融機関に関する連携サービス情報や、電子決済サービスを用いて利用料金の支払いが可能なサービスに関する連携サービス情報などの優先度を決定する。具体的な例を挙げると、図１の例において、決定部４４は、利用者Ｕ１が電子決済サービスに連携済みである銀行以外の銀行であって、利用者Ｕ１が口座を開設していると推定される銀行に関する連携サービス情報の優先度を決定する。

また、決定部４４は、利用者の位置情報に基づいて、優先度を決定してもよい。例えば、図１の例において、決定部４４は、また、決定部４４は、利用者Ｕ１が居住するエリアの地方銀行に関する連携サービス情報の優先度を、他の銀行に関する連携サービス情報よりも高く設定する。

また、決定部４４は、利用者の検索履歴に基づいて、優先度を決定してもよい。例えば、図１の例において、決定部４４は、連携サービス情報に対応する銀行に関する検索クエリが利用者Ｕ１の検索履歴に多く含まれるほど、当該連携サービス情報の優先度を高く設定する。

また、決定部４４は、利用者が所定の決済手段を用いて行った決済の履歴に基づいて、優先度を決定してもよい。例えば、図１の例において、決定部４４は、利用者Ｕ１の決済アプリを用いた消費行動の拠点となるエリアに所在する銀行に関する連携サービス情報の優先度を、他のエリアに所在する銀行に関する連携サービス情報よりも高く設定する。

なお、決定部４４は、利用者が所定の決済手段を用いて行った決済の決済金額に基づいて、優先度を決定してもよい。例えば、決定部４４は、決済金額に対応する価格帯の金融商品を提供するサービスや、決済金額に対応する価格帯の保険商品を提供するサービスに関する連携サービス情報の優先度を、他の連携サービス情報よりも高く設定する。

また、決定部４４は、利用者が所定の決済手段を用いて決済を行った取引対象に基づいて、優先度を決定してもよい。例えば、利用者が自転車を購入した場合、決定部４４は、自転車保険に関するサービスを提供する保険サービスに関する連携サービス情報の優先度を、自転車保険に関するサービスを提供しない保険サービスに関するものよりも高く設定する。また、例えば、利用者がベビー用品を購入した場合、決定部４４は、利用者に子供が生まれたと推定し、学資保険や医療保険に関するサービスを提供する保険サービスに関する連携サービス情報の優先度を、学資保険や医療保険に関するサービスを提供しない保険サービスに関するものよりも高く設定する。

また、決定部４４は、利用者の属性に基づいて、優先度を決定してもよい。例えば、決定部４４は、利用者が決済アプリに登録した個人情報や、決済アプリを用いて購入した取引対象、利用者の検索履歴に基づいて推定される属性に基づいて、連携サービス情報の優先度を決定する。具体的な例を挙げると、利用者の属性が「子供がいる」と推定される場合、学資保険や医療保険に関するサービスを提供する保険サービスに関する連携サービス情報の優先度を、学資保険や医療保険に関するサービスを提供しない保険サービスに関するものよりも高く設定する。

なお、決定部４４は、利用者と対応する属性を有する他の利用者が決済サービスに連携済のサービスに関する連携サービス情報の優先度を、他の連携サービス情報よりも高く設定してもよい。

ここで、各サービスが分類されるグループ（カテゴリ）のそれぞれから、利用者に対して適切なサービスに関する情報を提供したいといった要望が考えられる。したがって、決定部４４は、連携サービス情報が分類されたグループごとに、グループ内の各連携サービス情報を提供する優先度を決定してもよい。例えば、決定部４４は、「金融機関」、「保険サービス」、「不動産サービス」、・・・などといったグループごとに、グループ内の各連携サービス情報を提供する優先度を決定する。

なお、決定部４４は、連携サービス情報を提供する優先度を、利用者が得られる利益に基づいて決定してもよい。例えば、グループ「金融機関」や、「保険サービス」などに分類される連携サービス情報の優先度を決定する場合、決定部４４は、金利に基づいて優先度を決定してもよい。

また、決定部４４は、学習部４３により学習されたモデルを用いて優先度を決定してもよい。例えば、決定部４４は、学習部４３により学習されたモデルに利用者情報を入力し、出力された連携サービスごとの優先度を、対応する連携サービス情報を提供する優先度とする。

（提供部４５について）
提供部４５は、決定部４４により決定された優先度に基づいて、連携サービス情報を所定の決済手段を提供するプラットフォームを介して利用者に提供する。例えば、図１の例において、提供部４５は、決済アプリを介して連携サービスを選択するためのコンテンツを利用者端末１００に提供する。

また、提供部４５は、優先度に基づく表示態様で連携サービス情報を提供してもよい。例えば、図１の例において、提供部４５は、利用者Ｕ１が電子決済サービスに連携済みである銀以外の銀行に関する連携サービス情報を、優先度に基づく表示態様で表示するコンテンツを利用者端末１００に提供する。

また、提供部４５は、連携サービス情報のうち、優先度が第１の閾値以上である連携サービス情報を示す第１コンテンツを提供し、当該第１コンテンツに対する所定の操作を利用者から受け付けた場合は、連携サービス情報のうち、優先度が第１の閾値未満であり、且つ、優先度が第２の閾値以上である連携サービス情報を示す第２コンテンツを提供してもよい。例えば、図２に示すように、提供部４５は、連携サービス情報のうち、優先度の上位９件に含まれる連携サービス情報に対応する銀行を示すコンテンツ（画面ＳＣ１）と、利用者Ｕ１の操作に応じて利用者端末１００に表示されるコンテンツであって、上位９件の次に優先度が高い連携サービス情報に対応する銀行を示すコンテンツ（画面ＳＣ２）とを提供する。

また、提供部４５は、第１コンテンツが示す連携サービス情報以外の連携サービス情報の検索に関する操作を利用者から受け付けた場合は、第２コンテンツを提供してもよい。例えば、図２に示すように、提供部４５は、銀行名等の検索クエリを入力するための領域ＡＲ１を利用者が選択した場合に利用者端末１００に表示されるコンテンツ（画面ＳＣ２）を提供する。

また、提供部４５は、決済サービスにおける利用者の口座への入金を行う金融機関に関する連携サービス情報を提供してもよい。例えば、図１の例において、提供部４５は、チャージ用口座に関する連携サービス情報を提供する。

また、提供部４５は、グループ内での優先度に基づいて、グループごとに連携サービス情報を抽出し、抽出した連携サービス情報を提供してもよい。例えば、提供部４５は、「金融機関」、「保険サービス」、「不動産サービス」、・・・などといったグループ内での各連携サービス情報の優先度に基づいて、「金融機関」、「保険サービス」、「不動産サービス」、・・・の各々から連携サービス情報を抽出し、抽出した連携サービス情報を利用者に提供する。

また、提供部４５は、グループのうち、所定の関連性を有するグループごとに連携サービス情報を抽出し、抽出した連携サービス情報を提供してもよい。例えば、提供部４５は、利用者情報に基づく利用者のコンテキストと関連性を有するグループごとに連携サービス情報を抽出し、抽出した連携サービス情報を提供する。具体的な例を挙げると、利用者情報に基づいて、利用者が持ち家の購入を検討していると推定される場合、提供部４５は、決済アプリ内で起動するアプリケーション（ミニアプリ）において利用者の属性に対応する物件を提案するとともに、当該物件の購入を仲介する不動産サービスの中から、グループ「不動産サービス」における優先度に基づいて抽出した不動産サービスに関する連携サービス情報を提供する。さらに、提供部４５は、上記の物件に関する保険（火災保険等）に関するサービスを提供する保険サービスの中から、グループ「保険サービス」における優先度に基づいて抽出した保険サービスに関する連携サービス情報を提供する。さらに、提供部４５は、上記の物件に関する住宅ローンに関するサービスを提供する金融機関の中から、グループ「金融機関」における優先度に基づいて抽出した金融機関に関する連携サービス情報を提供する。

〔３．提案処理のフロー〕
次に、図７を用いて、実施形態に係る決済サーバ１０の提供処理の手順について説明する。図７は、実施形態に係る提供処理の手順の一例を示すフローチャートである。

図７に示すように、決済サーバ１０は、所定の決済手段に関する決済サービスの提供先となる利用者に関する利用者情報を取得する（ステップＳ１０１）。続いて、利用者情報に基づいて、決済サービスの連携先である連携サービスに関する連携サービス情報を提供する優先度を連携サービスごとに決定する（ステップＳ１０２）。続いて、決済サーバ１０は、優先度に基づいて、連携サービス情報を所定の決済手段を提供するプラットフォームを介して利用者に提供し（ステップＳ１０３）、処理を終了する。

〔４．変形例〕
上述の実施形態は一例を示したものであり、種々の変更及び応用が可能である。

〔４－１．金融機関について〕
上述の実施形態において、提供部４５が、決済アプリにおける利用者Ｕ１の口座に電子マネーの入金を行う銀行に関する連携サービス情報を提供する例を示したが、電子マネーの入金に用いる金融機関はこのような例に限定されない。例えば、提供部４５は、クレジットカードや、証券会社におけるＭＲＦ（Ｍｏｎｅｙ Ｒｅｓｅｒｖｅ Ｆｕｎｄ）、貸金業者などに関する連携サービス情報を、電子マネーの入金元として選択可能に提供してもよい。

〔４－２．連携サービス情報について〕
上述の実施形態において、提供部４５が、銀行に関する連携サービス情報を、優先度に基づく表示態様で表示するコンテンツを利用者に提供する例を示したが、提供部４５の機能はこのような例に限定されない。例えば、提供部４５は、任意の種別の連携サービス情報の組み合わせを、決定された優先度に基づいて並び替えて表示するコンテンツを利用者に提供してもよい。言い換えると、提供部４５は、異なる種別の連携サービスに関する連携サービス情報間で決定された優先度に基づいて、連携サービス情報を利用者に提供してもよい。

また、上述の実施形態において、提供部４５が、連携サービスを提供する銀行（企業）を選択可能に表示するコンテンツ（図２に示す画面ＳＣ１、ＳＣ２等）を提供する例を示したが、提供部４５の機能はこのような例に限定されない。例えば、提供部４５は、連携サービスを提供する企業が提供する取引対象であって、連携サービスと関連性を有する取引対象（例えば、種別が異なる保険商品や、金融商品）を利用者が選択可能に表示するコンテンツを提供してもよい。

〔４－３．処理態様について〕
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、逆に、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文章中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上記してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔５．効果〕
上述してきたように、実施形態に係る決済サーバ１０は、取得部４１と、決済処理部４２と、決定部４４と、提供部４５とを有する。取得部４１は、所定の決済手段に関する決済サービスの提供先となる利用者に関する利用者情報を取得する。決済処理部４２は、決済情報に従い、決済処理を実行する。学習部４３は、連携サービスに関する連携サービス情報と、当該連携サービスを決済サービスに連携済の利用者に関する利用者情報との関連性に基づいて、各連携サービスの優先度を推定するようにモデルを学習させる。決定部４４は、取得部４１により取得された利用者情報に基づいて、決済サービスの連携先である連携サービスに関する連携サービス情報を提供する優先度を連携サービスごとに決定する。また、また、決定部４４は、学習部４３により学習されたモデルを用いて優先度を決定する。提供部４５は、決定部４４により決定された優先度に基づいて、連携サービス情報を所定の決済手段を提供するプラットフォームを介して利用者に提供する。また、提供部４５は、優先度に基づく表示態様で連携サービス情報を提供する。また、提供部４５は、決済サービスにおける利用者の口座への入金を行う金融機関に関する連携サービス情報を提供する。

これにより、実施形態に係る決済サーバ１０は、利用者にとってノイズとなる情報を抑制して情報を提供することができるため、決済サービスの連携先として適切なサービスの情報を利用者に提供できる。

また、実施形態に係る決済サーバ１０において、例えば、決定部４４は、利用者の位置情報に基づいて、優先度を決定する。また、決定部４４は、利用者の検索履歴に基づいて、優先度を決定する。また、決定部４４は、利用者が所定の決済手段を用いて行った決済の履歴に基づいて、優先度を決定する。また、決定部４４は、利用者が所定の決済手段を用いて決済を行った取引対象に基づいて、優先度を決定する。また、決定部４４は、利用者の属性に基づいて、優先度を決定する。

これにより、実施形態に係る決済サーバ１０は、各種の情報に基づいて優先度を決定し、連携サービス情報を提供することができるため、決済サービスの連携先として提供する情報の精度を向上させることができる。

また、実施形態に係る決済サーバ１０において、例えば、決定部４４は、連携サービス情報が分類されたグループごとに、グループ内の各連携サービス情報を提供する優先度を決定する。提供部４５は、グループ内での優先度に基づいて、グループごとに連携サービス情報を抽出し、抽出した連携サービス情報を提供する。また、提供部４５は、グループのうち、所定の関連性を有するグループごとに連携サービス情報を抽出し、抽出した連携サービス情報を提供する。

これにより、実施形態に係る決済サーバ１０は、関連性を有する複数の連携サービス情報を提供することができるため、利便性を向上させることができる。

また、実施形態に係る決済サーバ１０において、例えば、提供部４５は、連携サービス情報のうち、優先度が第１の閾値以上である連携サービス情報を示す第１コンテンツを提供し、当該第１コンテンツに対する所定の操作を利用者から受け付けた場合は、連携サービス情報のうち、優先度が第１の閾値未満であり、且つ、優先度が第２の閾値以上である連携サービス情報を示す第２コンテンツを提供する。また、提供部４５は、第１コンテンツが示す連携サービス情報以外の連携サービス情報の検索に関する操作を利用者から受け付けた場合は、第２コンテンツを提供する。

これにより、実施形態に係る決済サーバ１０は、利用者がなるべく検索クエリの入力等の煩雑な操作を行わなくとも、利用者に対し適切な情報を提供することができるため、利便性を向上させることができる。

また、実施形態に係る決済サーバ１０において、例えば、学習部４３は、連携サービスの組み合わせと、当該組み合わせに含まれる連携サービスの各々を決済サービスに連携済の利用者に関する利用者情報とをさらにモデルに学習させる。

これにより、実施形態に係る決済サーバ１０は、利用者のコンテキストと関連度が高い順に優先度を決定し、連携サービス情報を提供できるため、訴求効果の高い情報を利用者に提供することができる。

〔６．ハードウェア構成〕
また、上述してきた各実施形態に係る決済サーバ１０は、例えば、図８に示すような構成のコンピュータ１０００によって実現される。以下、決済サーバ１０を例に挙げて説明する。図８は、決済サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＯＭ１２００、ＲＡＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１２００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１２００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（実施形態のネットワークＮに対応する）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、また、通信網５００を介してＣＰＵ１１００が生成したデータを他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１３００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１３００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が決済サーバ１０として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１３００上にロードされたプログラムを実行することにより、制御部４０の機能を実現する。また、ＨＤＤ１４００には、決済サーバ１０の記憶装置内の各データが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から所定の通信網を介してこれらのプログラムを取得してもよい。

〔７．その他〕
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述した決済サーバ１０は、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、構成は柔軟に変更できる。

また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１０ 決済サーバ
２０ 通信部
３０ 記憶部
３１ 口座データベース
３２ 利用者情報データベース
４０ 制御部
４１ 取得部
４２ 決済処理部
４３ 学習部
４４ 決定部
４５ 提供部
１００ 利用者端末
２００ 店舗端末
３００ サービスサーバ

Claims (16)

1. 所定の決済手段に関する決済サービスの提供先となる利用者に関する利用者情報を取得する取得部と、
   前記取得部により取得された利用者情報に基づいて、前記決済サービスの連携先である連携サービスに関する連携サービス情報を提供する優先度を連携サービスごとに決定する決定部と、
   前記決定部により決定された優先度に基づいて、前記連携サービス情報を前記所定の決済手段を提供するプラットフォームを介して前記利用者に提供する提供部と
   を有することを特徴とする提供装置。
2. 前記提供部は、
   前記優先度に基づく表示態様で前記連携サービス情報を提供する
   ことを特徴とする請求項１に記載の提供装置。
3. 前記決定部は、
   前記利用者の位置情報に基づいて、前記優先度を決定する
   ことを特徴とする請求項１または２に記載の提供装置。
4. 前記決定部は、
   前記利用者の検索履歴に基づいて、前記優先度を決定する
   ことを特徴とする請求項１から３のうちいずれか１つに記載の提供装置。
5. 前記決定部は、
   前記利用者が前記所定の決済手段を用いて行った決済の履歴に基づいて、前記優先度を決定する
   ことを特徴とする請求項１から４のうちいずれか１つに記載の提供装置。
6. 前記決定部は、
   前記利用者が前記所定の決済手段を用いて決済を行った取引対象に基づいて、前記優先度を決定する
   ことを特徴とする請求項１から５のうちいずれか１つに記載の提供装置。
7. 前記決定部は、
   前記利用者の属性に基づいて、前記優先度を決定する
   ことを特徴とする請求項１から６のうちいずれか１つに記載の提供装置。
8. 前記提供部は、
   前記連携サービス情報のうち、前記優先度が第１の閾値以上である連携サービス情報を示す第１コンテンツを提供し、当該第１コンテンツに対する所定の操作を前記利用者から受け付けた場合は、前記連携サービス情報のうち、前記優先度が第１の閾値未満であり、且つ、前記優先度が第２の閾値以上である連携サービス情報を示す第２コンテンツを提供する
   ことを特徴とする請求項１から７のうちいずれか１つに記載の提供装置。
9. 前記提供部は、
   前記第１コンテンツが示す連携サービス情報以外の連携サービス情報の検索に関する操作を前記利用者から受け付けた場合は、前記第２コンテンツを提供する
   ことを特徴とする請求項８に記載の提供装置。
10. 前記提供部は、
    前記決済サービスにおける前記利用者の口座への入金を行う金融機関に関する前記連携サービス情報を提供する
    ことを特徴とする請求項１から９のうちいずれか１つに記載の提供装置。
11. 前記決定部は、
    連携サービス情報が分類されたグループごとに、グループ内の各連携サービス情報を提供する前記優先度を決定し、
    前記提供部は、
    前記グループ内での前記優先度に基づいて、前記グループごとに連携サービス情報を抽出し、抽出した連携サービス情報を提供する
    ことを特徴とする請求項１から１０のうちいずれか１つに記載の提供装置。
12. 前記提供部は、
    前記グループのうち、所定の関連性を有するグループごとに連携サービス情報を抽出し、抽出した連携サービス情報を提供する
    ことを特徴とする請求項１１に記載の提供装置。
13. 連携サービスに関する連携サービス情報と、当該連携サービスを前記決済サービスに連携済の利用者に関する利用者情報との関連性に基づいて、各連携サービスの優先度を推定するようにモデルを学習させる学習部
    をさらに有し、
    前記決定部は、
    前記学習部により学習されたモデルを用いて前記優先度を決定する
    ことを特徴とする請求項１から１２のうちいずれか１つに記載の提供装置。
14. 前記学習部は、
    連携サービスの組み合わせと、当該組み合わせに含まれる連携サービスの各々を前記決済サービスに連携済の利用者に関する利用者情報とをさらに前記モデルに学習させる
    ことを特徴とする請求項１３に記載の提供装置。
15. コンピュータが実行する提供方法であって、
    所定の決済手段に関する決済サービスの提供先となる利用者に関する利用者情報を取得する取得工程と、
    前記取得工程により取得された利用者情報に基づいて、前記決済サービスの連携先である連携サービスに関する連携サービス情報を提供する優先度を連携サービスごとに決定する決定工程と、
    前記決定工程により決定された優先度に基づいて、前記連携サービス情報を前記所定の決済手段を提供するプラットフォームを介して前記利用者に提供する提供工程と
    を含むことを特徴とする提供方法。
16. 所定の決済手段に関する決済サービスの提供先となる利用者に関する利用者情報を取得する取得手順と、
    前記取得手順により取得された利用者情報に基づいて、前記決済サービスの連携先である連携サービスに関する連携サービス情報を提供する優先度を連携サービスごとに決定する決定手順と、
    前記決定手順により決定された優先度に基づいて、前記連携サービス情報を前記所定の決済手段を提供するプラットフォームを介して前記利用者に提供する提供手順と
    をコンピュータに実行させることを特徴とする提供プログラム。

Images