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

Abstract

【課題】利用者の潜在的なニーズに沿った決済の提案を行う。【解決手段】本願に係る提案装置は、利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報（例えば、決済の目的を示す目的情報や、決済が行われた日時）を取得する取得部と、取得部により取得された決済情報に基づいて、利用者が支払先に決済を行う周期を特定する特定部と、特定部により特定された周期に応じて、所定の決済手段を提供するプラットフォームを介して支払先への決済を利用者に提案する提案部とを有することを特徴とする。【選択図】図１

Description

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

従来、利用者の決済支援するための各種のサービスを提供する技術が知られている。このような技術の一例として、予め顧客が指定した規則に従って送金額を定めることが可能な自動送金サービスに関する技術が提案されている。

特開２００２－３６６７６５号公報

しかしながら、上記の従来技術では、利用者の潜在的なニーズに沿った決済の提案を行うことができるとは限らない。

例えば、上記の従来技術では、予め顧客が指定した規則に従って所定の送金先口座に送金を行っているに過ぎず、顧客が送金の依頼をしていない場合は自動送金を行うことができないため、利用者の潜在的なニーズに沿った決済の提案を行うことができるとは限らない。

本願は、上記に鑑みてなされたものであって、利用者の潜在的なニーズに沿った決済の提案を行うことができる提案装置、提案方法及び提案プログラムを提供することを目的とする。

本願に係る提案装置は、利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報を取得する取得部と、前記取得部により取得された決済情報に基づいて、前記利用者が前記支払先に決済を行う周期を特定する特定部と、前記特定部により特定された周期に応じて、前記所定の決済手段を提供するプラットフォームを介して前記支払先への決済を前記利用者に提案する提案部とを有することを特徴とする。

実施形態の一態様によれば、利用者の潜在的なニーズに沿った決済の提案を行うことができるという効果を奏する。

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

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

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

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

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

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

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

〔１－１．端末装置１００を用いた決済について〕
ここで、決済サーバ１０が実行する提案処理に先立ち、端末装置１００を用いた決済（電子決済）の一例について説明する。なお、以下の説明では、決済サーバ１０から配信されるアプリケーションであって、端末装置１００を用いる電子決済用のアプリケーション（以下、単に「決済アプリ」と記載する場合がある）が端末装置１００にインストールされているものとする。また、以下の説明では、店舗に配置された２次元コード（ＱＲコード（登録商標））であって、店舗を識別する店舗識別情報を示す２次元コードを用いて、利用者Ｕ１が端末装置１００を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意の利用者が任意の端末装置１００を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報は、ＱＲコードのみならず、バーコードや所定のマーク、番号等であってもよい。

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

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

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

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

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

なお、端末装置１００を用いた送金は、上述した処理に限定されるものではない。例えば、端末装置１００を用いた送金は、送金先の利用者の電話番号や、送金先の利用者を示す情報（例えば、利用者ＩＤ）を端末装置１００に入力することにより行われてもよい。具体的な例を挙げると、端末装置１００は、送金先の利用者の電話番号或いは利用者ＩＤと、送金金額との入力を利用者Ｕ１から受け付け、入力された電話番号或いは利用者ＩＤと、送金金額と、利用者Ｕ１を識別する利用者識別情報とを決済サーバ１０へと送信する。そして、決済サーバ１０は、利用者Ｕ１の口座から、送信された電話番号或いは利用者ＩＤに紐づけられた利用者の口座へと、送金金額が示す額の電子マネーを移行させる。

ここで、送金先の利用者の電話番号や利用者ＩＤは、当該利用者に関する情報と紐付けて決済アプリに予め登録されていてもよい。この場合、端末装置１００は、決済アプリに登録された利用者（送金先）の指定と、当該利用者への送金金額の入力とを利用者Ｕ１から受け付け、指定された利用者に紐付けられた電話番号或いは利用者ＩＤと、送金金額と、利用者Ｕ１を識別する利用者識別情報とを決済サーバ１０へと送信する。

また、例えば、端末装置１００を用いた送金は、送金金額を受け取るためのリンク情報を送金先の利用者に提供することにより行われてもよい。具体的な例を挙げると、端末装置１００は、利用者Ｕ１から送金金額の入力を受け付けて送金金額を受け取るためのリンク情報を生成し、リンク情報を含む電子メールを送信したり、リンク情報を含む投稿情報をＳＮＳ（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）等の集積回路により実現される。実施形態に係る制御部４０は、図２に示すように、取得部４１と、特定部４２と、提案部４３と、処理部４４とを有し、以下に説明する情報処理の機能や作用を実現または実行する。

（取得部４１について）
取得部４１は、利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報を取得する。例えば、図１の例において、取得部４１は、決済アプリを用いた決済（送金）に関する決済情報を取得し、利用者情報データベース３２に格納する。

また、取得部４１は、支払先に対する決済の目的を示す目的情報を含む決済情報を取得してもよい。例えば、図１の例において、取得部４１は、送金先の利用者が送金金額を受け取るための操作を行う際に当該利用者が利用する端末装置１００に表示されるコンテンツであって、利用者Ｕ１が送金に関する操作を行う際に選択した送金の目的を視覚的に示すコンテンツや、送金の際に送金先の利用者に送るメッセージとして利用者Ｕ１が入力した情報などを示す目的情報を含む決済情報を取得する。また、取得部４１は、利用者Ｕ１と送金先の利用者との関係性に基づく目的情報を含む決済情報を取得する。また、取得部４１は、送金先の事業者のカテゴリに応じて設定される目的情報などを示す決済情報を取得する。

また、取得部４１は、支払先に対する決済が行われた日時を示す決済情報を取得してもよい。例えば、図１の例において、取得部４１は、送金金額や、送金先の利用者を識別する利用者識別情報（利用者ＩＤ）、送金を行った日時などを示す決済情報を取得する。

（特定部４２について）
特定部４２は、取得部４１により取得された決済情報に基づいて、利用者が支払先に決済を行う周期を特定する。例えば、図１の例において、特定部４２は、利用者情報データベース３２を参照し、決済情報に基づいて、利用者Ｕ１が支払先に決済を行う周期を特定する。

また、特定部４２は、支払先が属するカテゴリに基づいて周期を特定してもよい。例えば、図１の例において、特定部４２は、事業者Ｍ１のカテゴリ「ガス会社」に基づき、利用者Ｕ１が事業者Ｍ１に対して送金を行う周期を「毎月１回」と特定する

また、特定部４２は、目的情報に基づいて周期を特定してもよい。例えば、図１の例において、特定部４２は、決済情報Ｄ＃２が示す目的情報「月謝」に基づき、利用者Ｕ１が利用者Ｕ３に対して送金を行う周期を「毎月１回」と特定する。また、特定部４２は、決済情報Ｄ＃３が示す目的情報「ガス料金」に基づき、利用者Ｕ１が事業者Ｍ１に対して送金を行う周期を「毎月１回」と特定する。

また、特定部４２は、決済情報が示す日時に基づいて周期を特定してもよい。例えば、図１の例において、特定部４２は、決済情報が示す日時に基づいて、利用者Ｕ１が支払先の各利用者や事業者に対して送金を行う周期を特定する。

（提案部４３について）
提案部４３は、特定部４２により特定された周期に応じて、所定の決済手段を提供するプラットフォームを介して支払先への決済を利用者に提案する。例えば、図１の例において、提案部４３は、特定された周期に応じたタイミングで支払先への決済の提案を行う。

また、提案部４３は、支払先への決済の提案に関するコンテンツであって、支払先への決済を指示するためのコンテンツを利用者が利用する利用者端末に表示させてもよい。例えば、図１の例において、提案部４３は、支払先への決済の提案に関するコンテンツであって、支払先への決済を指示するためのコンテンツである提案コンテンツを端末装置１００に送信し、表示させる。

また、提案部４３は、所定の決済手段における利用者の口座の残高が所定の閾値以下である場合は、当該口座に対する入金と、支払先への決済とを指示するためのコンテンツを利用者端末に表示させてもよい。例えば、図１の例において、入力欄に入力された送金金額が、電子決済サービスにおける利用者Ｕ１の口座の残高よりも高い場合、提案部４３は、口座への所定の金額の入金処理、並びに、入金完了後に支払先への決済処理を指示するためのコンテンツを端末装置１００に表示させる。

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

また、処理部４４は、利用者が保有する口座から、送金金額の送金先である利用者が保有する口座に送金金額を移行させる処理を実行してもよい。例えば、図１の例において、処理部４４は、利用者Ｕ１の口座から、送金先の利用者の口座へと、送金金額が示す額の電子マネーを移行させる処理を実行する。

また、処理部４４は、コンテンツに対する操作に応じて、支払先への決済処理を実行してもよい。例えば、図１の例において、処理部４４は、提案コンテンツに対する操作に応じて送信される決済要求に基づき、利用者Ｕ１の口座から支払先の利用者や事業者の口座へと電子マネーの送金を行う。

また、処理部４４は、コンテンツに対する操作に応じて、口座に所定の金額を入金し、当該入金完了後に支払先への決済処理を実行してもよい。例えば、図１の例において、処理部４４は、口座への所定の金額の入金処理、並びに、入金完了後に支払先への決済処理を指示するためのコンテンツに対する操作に応じて、利用者Ｕ１の口座に所定の金額を入金し、当該入金完了後に支払先への決済処理を実行する。

また、処理部４４は、決済情報が示す決済金額に基づいて、支払先への決済処理を実行してもよい。例えば、図１を例にして説明すると、利用者Ｕ１が毎回一定の金額を送金している支払先への送金を利用者Ｕ１に提案される場合、処理部４４は、当該金額が入力済みの提案コンテンツを介した決済要求に基づいて、支払先への当該金額の決済処理を実行する。

また、処理部４４は、コンテンツに対して利用者が入力した金額に基づいて、支払先への決済処理を実行してもよい。例えば、図１の例において、処理部４４は、提案コンテンツに入力された送金金額に基づく決済処理を実行する。

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

図６に示すように、決済サーバ１０は、利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報を取得する（ステップＳ１０１）。続いて、決済サーバ１０は、決済情報に基づいて、利用者が支払先に決済を行う周期を特定する（ステップＳ１０２）。続いて、決済サーバ１０は、決済を提案するタイミングであるか否かを判定する（ステップＳ１０３）。決済を提案するタイミングではないと判定した場合（ステップＳ１０３；Ｎｏ）、決済サーバ１０は、決済を提案するタイミングとなるまで待機する。

一方、決済を提案するタイミングであると判定した場合（ステップＳ１０３；Ｙｅｓ）、決済サーバ１０は、支払先への決済の提案に関するコンテンツを利用者端末に表示させる（ステップＳ１０４）。続いて、決済サーバ１０は、端末装置１００から決済要求が送信されたか否かを判定する（ステップＳ１０５）。決済要求が送信されない場合（ステップＳ１０５；Ｎｏ）、決済サーバ１０は処理を終了する。

一方、決済要求が送信された場合（ステップＳ１０５；Ｙｅｓ）、決済サーバ１０は、支払先への決済処理を実行し（ステップＳ１０６）、処理を終了する。

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

〔４－１．決済について〕
本願における「決済」は、各種商品や役務の提供等に対する対価として利用者が行うものに限定されるものではなく、例えば、個人間の送金といった単純な資金移動、すなわち、商品や役務の提供に対する対価ではない資金のやりとり（送金）を含む概念とする。すなわち、本願における「利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報を取得する取得部と、前記取得部により取得された決済情報に基づいて、前記利用者が前記支払先に決済を行う周期を特定する特定部と、前記特定部により特定された周期に応じて、前記所定の決済手段を提供するプラットフォームを介して前記支払先への決済を前記利用者に提案する提案部とを有することを特徴とする提案装置」とは、何かしらの対価として行われる決済のみならず、対価ではない単純な資金移動に関する送金の処理をも含む概念であることとする。

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

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

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

〔５．効果〕
上述してきたように、実施形態に係る決済サーバ１０は、取得部４１と、特定部４２と、提案部４３と、処理部４４とを有する。取得部４１は、利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報を取得する。特定部４２は、取得部４１により取得された決済情報に基づいて、利用者が支払先に決済を行う周期を特定する。提案部４３は、特定部４２により特定された周期に応じて、所定の決済手段を提供するプラットフォームを介して支払先への決済を利用者に提案する。また、提案部４３は、支払先への決済の提案に関するコンテンツであって、支払先への決済を指示するためのコンテンツを利用者が利用する利用者端末に表示させる。処理部４４は、コンテンツに対する操作に応じて、支払先への決済処理を実行する。

これにより、実施形態に係る決済サーバ１０は、利用者が自動送金に関する設定を行わなくとも、支払先への送金に関して適切なタイミングで送金の提案を行い、送金を行うことができるため、利用者の潜在的なニーズに沿った決済の提案を行うことができる。

また、実施形態に係る決済サーバ１０において、例えば、特定部４２は、支払先が属するカテゴリに基づいて周期を特定する。また、取得部４１は、支払先に対する決済の目的を示す目的情報を含む決済情報を取得する。そして、特定部４２は、目的情報に基づいて周期を特定する。また、取得部４１は、支払先に対する決済が行われた日時を示す決済情報を取得する。そして、特定部４２は、決済情報が示す日時に基づいて周期を特定する。

これにより、実施形態に係る決済サーバ１０は、各種の情報に基づいて利用者が支払先に決済を行う周期を特定することができるため、周期を特定する際の精度を向上させることができる。

また、実施形態に係る決済サーバ１０において、例えば、提案部４３は、所定の決済手段における利用者の口座の残高が所定の閾値以下である場合は、当該口座に対する入金と、支払先への決済とを指示するためのコンテンツを利用者端末に表示させる。そして、処理部４４は、コンテンツに対する操作に応じて、口座に所定の金額を入金し、当該入金完了後に支払先への決済処理を実行する。また、処理部４４は、決済情報が示す決済金額に基づいて、支払先への決済処理を実行する。そして、処理部４４は、コンテンツに対して利用者が入力した金額に基づいて、支払先への決済処理を実行する。

これにより、実施形態に係る決済サーバ１０は、電子結佐―サービスにおける利用者の状況に応じて柔軟に決済処理を実行できるため、利便性を向上させることができる。

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

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

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

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

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

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

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

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

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

１０ 決済サーバ
２０ 通信部
３０ 記憶部
３１ 口座データベース
３２ 利用者情報データベース
４０ 制御部
４１ 取得部
４２ 特定部
４３ 提案部
４４ 処理部
１００ 端末装置

Claims (10)

1. 利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報を取得する取得部と、
   前記取得部により取得された決済情報に基づいて、前記利用者が前記支払先に決済を行う周期を特定する特定部と、
   前記特定部により特定された周期に応じて、前記所定の決済手段を提供するプラットフォームを介して前記支払先への決済を前記利用者に提案する提案部と
   を有することを特徴とする提案装置。
2. 前記特定部は、
   前記支払先が属するカテゴリに基づいて前記周期を特定する
   ことを特徴とする請求項１に記載の提案装置。
3. 前記取得部は、
   前記支払先に対する決済の目的を示す目的情報を含む前記決済情報を取得し、
   前記特定部は、
   前記目的情報に基づいて前記周期を特定する
   ことを特徴とする請求項１または２に記載の提案装置。
4. 前記取得部は、
   前記支払先に対する決済が行われた日時を示す前記決済情報を取得し、
   前記特定部は、
   前記決済情報が示す日時に基づいて前記周期を特定する
   ことを特徴とする請求項１から３のうちいずれか１つに記載の提案装置。
5. 前記提案部は、
   前記支払先への決済の提案に関するコンテンツであって、前記支払先への決済を指示するためのコンテンツを前記利用者が利用する利用者端末に表示させ、
   前記コンテンツに対する操作に応じて、前記支払先への決済処理を実行する処理部
   をさらに有することを特徴とする請求項１から４のうちいずれか１つに記載の提案装置。
6. 前記提案部は、
   前記所定の決済手段における前記利用者の口座の残高が所定の閾値以下である場合は、当該口座に対する入金と、前記支払先への決済とを指示するための前記コンテンツを前記利用者端末に表示させ、
   前記処理部は、
   前記コンテンツに対する操作に応じて、前記口座に所定の金額を入金し、当該入金完了後に前記支払先への決済処理を実行する
   ことを特徴とする請求項５に記載の提案装置。
7. 前記処理部は、
   前記決済情報が示す決済金額に基づいて、前記支払先への決済処理を実行する
   ことを特徴とする請求項５または６に記載の提案装置。
8. 前記処理部は、
   前記コンテンツに対して前記利用者が入力した金額に基づいて、前記支払先への決済処理を実行する
   ことを特徴とする請求項５または６に記載の提案装置。
9. コンピュータが実行する提案方法であって、
   利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報を取得する取得工程と、
   前記取得工程により取得された決済情報に基づいて、前記利用者が前記支払先に決済を行う周期を特定する特定工程と、
   前記特定工程により特定された周期に応じて、前記所定の決済手段を提供するプラットフォームを介して前記支払先への決済を前記利用者に提案する提案工程と
   を含むことを特徴とする提案方法。
10. 利用者が所定の決済手段を用いて支払先に対して行った決済に関する決済情報を取得する取得手順と、
    前記取得手順により取得された決済情報に基づいて、前記利用者が前記支払先に決済を行う周期を特定する特定手順と、
    前記特定手順により特定された周期に応じて、前記所定の決済手段を提供するプラットフォームを介して前記支払先への決済を前記利用者に提案する提案手順と
    をコンピュータに実行させることを特徴とする提案プログラム。

Images