JP2020107217A - 情報処理方法、情報処理装置及びプログラム - Google Patents

Abstract

【課題】決済額を用途別に管理することを可能にする情報処理方法を提供すること。【解決手段】ユーザが所有する口座の残高を、第１口座と、１以上の第２口座とに分けて管理する管理部と、決済が行われる際、第１口座及び１以上の第２口座の中から、決済に用いる一の口座の選択を行う選択部と、選択された決済に用いる一の口座の残高が決済の額以上である場合に、決済の額の支払を行い、選択された決済に用いる一の口座の残高から決済の額を減算する決済処理部と、を有する情報処理装置を提供する。【選択図】図３

Description

本発明は情報処理方法、情報処理装置及びプログラムに関する。

現在、プリペイドによる決済手段として、電子マネー、国際ブランドによるプリペイドカード決済、ＱＲコード（登録商標）を利用した決済など、様々な決済手段が提供されている。例えば特許文献１には、バーコード又はＱＲコード（登録商標）を利用してより簡便に商品の費用を決済することを可能とする技術が開示されている。

特開２０１６−５３４４５３号公報

現在提供されているプリペイド決済手段では、チャージされた金額は１つの残高で管理される。プリペイド決済では、支払いを行っている感覚が薄れることから、ついつい使い過ぎてしまうユーザが多い。また、残高が減ると自動的にクレジットカードからチャージが行われるサービスが提供されていることも、更に使い過ぎを助長する要因となる。そのため、ユーザは、使い過ぎを防止するために、例えば何の用途でいくら使ったのかを記録しておくなど、支払い用途を自ら管理する必要があった。

そこで、本発明は、決済額を用途別に管理することを可能にする情報処理方法を提供することを目的とする。

本発明の一態様に係る情報処理装置は、ユーザが所有する口座の残高を、第１口座と、１以上の第２口座とに分けて管理する管理部と、決済が行われる際、第１口座及び１以上の第２口座の中から、決済に用いる一の口座の選択を行う選択部と、選択された決済に用いる一の口座の残高が決済の額以上である場合に、決済の額の支払を行い、選択された決済に用いる一の口座の残高から決済の額を減算する決済処理部と、を有する。

本発明によれば、決済額を用途別に管理することを可能にする情報処理方法を提供することができる。

本実施形態に係る決済システムのシステム構成例を示す図である。 サーバ及び端末のハードウェア構成例を示す図である。 サーバの機能ブロック構成例を示す図である。 口座管理ＤＢの一例を示す図である。 決済履歴ＤＢの一例を示す図である。 取引履歴ＤＢの一例を示す図である。 端末の機能ブロック構成例を示す図である。 決済システムが口座開設、サブ口座作成及びチャージを行う際の処理手順の一例を示すシーケンス図である。 残高の振分けを受け付ける画面の一例を示す図である。 決済システムが決済処理を行う際の処理手順の一例を示すシーケンス図である。 決済システムが決済処理を行う際の処理手順の一例を示すシーケンス図である。 支払い口座を選択する画面の一例を示す図である。

添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

＜システム構成＞
図１は、本実施形態に係る決済システム１のシステム構成例を示す図である。決済システム１は、サーバ１０と端末２０とを含む。図１にはサーバ１０と端末２０がそれぞれ１つずつ図示されているが、複数含まれていてもよい。サーバ１０と端末２０とは、通信ネットワークＮを介して相互に通信することができる。本開示において、サーバ１０と、端末２０とをそれぞれ区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよい。

サーバ１０は、通信ネットワークＮを介してユーザが利用する端末２０に、決済サービスを提供する。決済サービスとは１以上のユーザが金銭または金銭相当物の授受ができるサービスを意味する。限定でなく例として、一次元コード（バーコードなど）、二次元コード（ＱＲコード（登録商標）など）（以下で、一次元コードおよび二次元コードをまとめて「二次元コード等」と総称する。）、近距離無線通信（ＮＦＣ (Near Field Communication)、ＢＬＥ（Bluetooth（登録商標） Low Energy）、Wi-Fi（登録商標）、超音波通信、赤外線通信など）を利用して決済を行うサービスを含む。また、代金の支払いを行うユーザ（支払者）の端末２０が二次元コード等を読み取ることで決済を行うことを「ユーザ読取型コード決済」または「ＭＰＭ（Merchant Presented Mode）」と表現し、支払いを行うユーザの端末２０が二次元コード等を表示し、表示された二次元コード等を、代金を請求する店舗側等のユーザ（販売者、請求者）の端末２０が読み取ることで決済を行うことを「店舗読取型コード決済」または「ＣＰＭ（Consumer Presented Mode）」と表現する。なお、ＭＰＭおよびＣＰＭは、動的であってもよいし、静的であってもよい。

サーバ１０は、決済サービス以外に、電子商取引サービス、インスタントメッセンジャーを代表とするＳＮＳ（Social Networking Service）、楽曲・動画・書籍などのコンテンツ提供サービス等を提供するようにしてもよい。

サーバ１０は、１又は複数のサーバから構成されていてもよい。例えば、サーバ１０には、決済サービスを提供するサーバと、電子商取引サービスを提供するサーバとが含まれていてもよい。

端末２０は、ユーザが操作する端末であり、スマートフォン、タブレット端末、携帯電話機、パーソナルコンピュータ（ＰＣ）、ノートＰＣ、携帯情報端末（ＰＤＡ）、家庭用ゲーム機器など、通信機能を備えた端末であればあらゆる端末を用いることができる。

本実施形態でサーバ１０が提供する決済サービスでは、ユーザごとに決済用の口座が用意され、各ユーザは、クレジットカード又は銀行口座から自身の決済用の口座に、電子的なバリューをチャージすることができる。バリューは、電子マネーのように、通貨と１対１で等価交換可能であることを想定しているが、通貨と所定の交換比率で交換可能なポイント、仮想通貨及びマイレージ等であってもよい。

各ユーザの口座は、複数の仮想口座に分割され、例えば、第１口座と１以上の第２口座とに分割される。一例として、口座は、決済用途が定められていない口座であるメイン口座（第１口座）と、支払い用途が定められている１以上のサブ口座（第２口座）とに分割されている。サブ口座は、ユーザの指示により１又は複数作成することが可能であり、支払い用途もユーザが任意に指定することができる。サブ口座の一例として、ランチ用口座（ランチ代を支払う口座）、飲み会用口座（飲み会代を支払う口座）、趣味用口座等が挙げられる。以下の説明では、ユーザがＮ個のサブ口座を作成する場合、Ｎ個のサブ口座を、サブ口座１、サブ口座２、サブ口座３、・・・サブ口座Ｎと表現する。

本実施形態では、オンラインの電子商取引サービスなどで決済が行われる際、メイン口座及び１以上のサブ口座の中から決済に用いる一の口座の選択が行われ、選択された一の口座の残高から決済の額が減算されることで支払いが行われる。決済に用いる一の口座の選択は、サーバ１０が自動的に行うようにしてもよいし、決済の都度ユーザが選択することとしてもよい。

＜ハードウェア構成＞
図２は、サーバ１０及び端末２０のハードウェア構成例を示す図である。サーバ１０及び端末２０は、ＣＰＵ（Central Processing Unit）１１、メモリ、ＨＤＤ（Hard Disk Drive）及び／又はＳＳＤ（Solid State Drive）等の記憶装置１２、有線又は無線通信を行う通信ＩＦ（Interface）１３、入力操作を受け付ける入力デバイス１４、及び情報の出力を行う出力デバイス１５を有する。入力デバイス１４は、例えば、キーボード、タッチパネル、マウス及び／又はマイク等である。出力デバイス１５は、例えば、ディスプレイ及び／又はスピーカ等である。

＜機能ブロック構成＞
図３は、サーバ１０の機能ブロック構成例を示す図である。サーバ１０は、記憶部１０１と、管理部１０２と、選択部１０３と、決済処理部１０４とを含む。管理部１０２と、選択部１０３と、決済処理部１０４とは、サーバ１０のＣＰＵ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体（Non-transitory computer readable medium）であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ−ＲＯＭ等の記憶媒体であってもよい。

記憶部１０１は、電子決済サービス（以下、単に「決済サービス」とも称す。）を利用するために各ユーザが開設した口座に関する各種情報を管理する口座管理ＤＢと、決済サービスを利用して各ユーザが決済を行った際の履歴を管理する決済履歴ＤＢと、各ユーザが電子商取引サービスを利用して商品を取引した履歴を管理する取引履歴ＤＢとを格納する。また、記憶部１０１は、サーバ１０が備える記憶装置１２や、通信ネットワークＮを介してサーバ１０と通信可能な他の情報処理装置を用いて実現することができる。口座管理ＤＢ及び決済履歴ＤＢは決済サービスに関連するデータベースであり、取引履歴ＤＢは、電子商取引サービスに関連するデータベースであることから、口座管理ＤＢを管理するサーバ１０と、取引履歴ＤＢを管理するサーバ１０とは異なるサーバであってもよい。

図４は、口座管理ＤＢの一例を示す図である。「ユーザＩＤ」は、ユーザを一意に識別するためのＩＤである。「口座番号」は、本実施形態に係る口座の識別子であって、当該口座に、銀行窓口、ＡＴＭ又はオンラインバンキングを利用してチャージする際に指定する番号、銀行名、支店名、口座種別等を示す。「メイン口座残高」は、メイン口座にチャージされているバリューの残高を示す。「サブ口座１残高」は、サブ口座１にチャージされているバリューの残高を示す。「サブ口座１用途」は、サブ口座１の支払い用途を示す。「サブ口座２残高」は、サブ口座２にチャージされているバリューの残高を示す。「サブ口座２用途」は、サブ口座２の支払い用途を示す。口座管理ＤＢには、ユーザが作成したサブ口座の数だけ、「サブ口座残高」及び「サブ口座用途」が繰り返し格納される。

図５は、決済履歴ＤＢの一例を示す図である。「ユーザＩＤ」は、ユーザを一意に識別するためのＩＤである。「口座」は、決済が行われた口座を示す。「日時」は、決済が行われた日付及び時刻を示す。「支払対象」は、ユーザが購入した商品又はサービスの名称又はカテゴリなど、支払いの対象を示す。「決済額」は、支払ったバリューの額を示す。「残高」は、支払いが行われた時点における口座の残高を示す。

図６は、取引履歴ＤＢの一例を示す図である。「ユーザＩＤ」は、ユーザを一意に識別するためのＩＤである。「日時」は、ユーザが出品した商品を他のユーザが購入した日付及び時刻、又は、ユーザが商品を購入した日付及び時刻を示す。「出品／購入」は、ユーザが商品を出品したのか又は商品を購入したのかを示すフラグが格納される。「売上額／支払額」は、ユーザが出品した商品を他のユーザが購入したときの売上額、又は、ユーザが商品を購入したときの支払額が格納される。

管理部１０２は、ユーザが所有する口座の残高を、メイン口座の残高と１以上のサブ口座の残高とに分けて管理する機能を有する。

選択部１０３は、決済が行われる際、メイン口座及び１以上のサブ口座の中から、決済に用いる一の口座の選択を行う機能を有する。選択部１０３は、所定の条件に従って当該一の口座を自動的に選択するようにしてもよいし、ユーザに選択を促すようにしてもよい。

決済処理部１０４は、選択部１０３で選択された決済に用いる一の口座の残高が決済の額以上である場合に、当該一の口座の残高から決済の額を減算することで決済を行う機能を有する。

図７は、端末２０の機能ブロック構成例を示す図である。端末２０は、取得部２０１と、表示部２０２と、受付部２０３と、通知部２０４とを含む。取得部２０１とと、表示部２０２と、受付部２０３と、通知部２０４とは、端末２０のＣＰＵ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。当該プログラムは、サーバ１０が提供する決済サービスを利用するためのアプリケーションであってみもよい。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ−ＲＯＭ等の記憶媒体であってもよい。

取得部２０１は、ユーザが所有する口座を管理するサーバ１０から、ユーザが所有する口座に含まれる、メイン口座の残高と、１以上のサブ口座の残高とを取得する機能を有する。

表示部２０２は、取得部２０１が取得したメイン口座の残高と、１以上のサブ口座の残高とを並べて画面に表示する機能を有する。

受付部２０３は、画面に表示されたメイン口座と１以上のサブ口座の中から、決済に用いる一の口座の選択を受け付ける機能を有する。

通知部２０４は、受付部２０３で受け付けた決済に用いる一の口座を、サーバ１０に通知する機能を有する。

＜処理手順＞
（口座開設処理、サブ口座作成処理、チャージ処理）
図８は、決済システム１が口座開設、サブ口座作成及びチャージを行う際の処理手順の一例を示すシーケンス図である。

まず、端末２０の受付部２０３は、ユーザから口座開設の依頼を受け付ける（Ｓ１００）。続いて、端末２０の通知部２０４は、サーバ１０に口座開設依頼メッセージを送信する。その後、サーバ１０と端末２０との間で、ユーザの個人情報の送信、ユーザＩＤの決定、本人確認書類の画像送信、チャージに利用する銀行口座又はクレジットカード番号の通知などが行われ、口座開設が完了する（Ｓ１０１）。このとき、管理部１０２は、新たに開設したユーザの口座を管理するために、口座管理ＤＢにメイン口座残高が０円であるレコードを作成する。

続いて、端末２０の受付部２０３は、ユーザから、口座にチャージするチャージ額を受け付ける（Ｓ２０２）。端末２０の画面にチャージ額が入力されると（Ｓ１０２）、ユーザＩＤとチャージ額とを含むチャージ依頼メッセージがサーバ１０に通知される（Ｓ１０３）。サーバ１０の管理部１０２は、ユーザの銀行口座又はクレジットカードから指定されたチャージ額を引き落とす処理を行い、引落しが正常に完了すると、口座管理ＤＢのメイン口座残高に指定されたチャージ額を加算する（Ｓ１０４）。

続いて、ユーザが端末２０の画面でサブ口座の支払い用途を指定すると（Ｓ１０５）、端末２０の通知部２０４は、指定されたサブ口座の支払い用途を含むサブ口座作成指示メッセージをサーバ１０に送信する（Ｓ１０６）。サーバ１０は、口座管理ＤＢに、指定された支払い用途のサブ口座を追加する（Ｓ１０７）。なお、ステップＳ１０５の処理手順において、端末２０の画面には、指定可能なサブ口座の支払い用途が選択肢として表示され、ユーザは、当該選択肢の中から各サブ口座の支払い用途を選択するようにしてもよい。

続いて、端末２０の受付部２０３は、ユーザから、メイン口座の残高の全部又は一部をサブ口座の残高に振り分ける指示を受け付ける（Ｓ１０８）。ユーザから、残高の振分けを受け付ける画面の一例を図９に示す。図９に示す画面には、メイン口座の残高のうち、サブ口座に振り分けるチャージ額を入力する入力欄Ｍ１０と、各サブ口座に配分するチャージ額を入力する入力欄（Ｍ１１、Ｍ１２）とが設けられている。ユーザは、メイン口座からサブ口座に振り分けるバリューの額を入力欄Ｍ１０に入力し、各サブ口座に振り分けるバリューの額を入力欄Ｍ１１及びＭ１２に入力する。なお、入力欄Ｍ１１及びＭ１２の合計額と入力欄Ｍ１０に入力されるバリュー額は同一である必要がある。なお、図９において、各サブ口座に振り分けるバリューの額を、割合で指定可能としてもよい。例えば、メイン口座からサブ口座に振り分けるバリュー額の３０％をサブ口座１に配分し、残りの７０％をサブ口座２に配分するといった指定を可能としてもよい。図８に戻り説明を続ける。

ユーザが振分実行ボタンＢ１を押下すると、端末２０の通知部２０４は、サーバ１０に、メイン口座から各サブ口座に振り分けるバリューの額を含む振分け依頼メッセージを送信する（Ｓ１０９）。サーバ１０は、振分け依頼メッセージに従って、メイン口座から各サブ口座にバリューの振分けを行う（Ｓ１１０）。

（チャージ額の自動振分け処理）
サーバ１０の管理部１０２は、チャージ処理（Ｓ１０２〜Ｓ１０４）と振分け処理（Ｓ１０８〜Ｓ１１０）とを同時に実行可能としてもよい。具体的には、サブ口座が複数存在する場合、管理部１０２は、チャージが行われる際、チャージされたバリューの額をメイン口座に加算するのではなく、所定の配分に従って各サブ口座に直接加算するようにしてもよい。

ここで、所定の配分は、予めユーザが指定した配分であってもよいし、管理部１０２が所定のロジックに従って算出した配分であってもよい。このとき、管理部１０２は、所定のロジックに従って算出した配分を一旦ユーザに提示し、ユーザから同意が得られた場合に当該所定の配分に従ってサブ口座への配分を開始するようにしてもよい。若しくは、ユーザに提示することなく、算出した所定の配分に従ってサブ口座への配分を行うようにしてもよい。

所定のロジックについて、例えば、管理部１０２は、決済履歴ＤＢを検索することで、所定の期間（例えば過去半年などでもよいし、ユーザが口座を開設してから現在までの期間であってもよい）においてユーザが支払った金額の合計額をサブ口座ごとに算出し、算出したサブ口座ごとの合計額に基づいて、所定の配分を決定するようにしてもよい。例えば、所定の期間におけるサブ口座１の合計利用額が５万円であり、サブ口座２の合計利用額が１０万円である場合、管理部１０２は、サブ口座１とサブ口座２における所定の配分は、１対２であると算出する。この場合、３万円のチャージが行われると、管理部１０２は、１万円をサブ口座１に加算し、２万円をサブ口座２に加算する。

（サブ口座用途のレコメンド処理）
サーバ１０の管理部１０２は、決済履歴ＤＢを過去所定の期間検索することで、ユーザが支払った商品又はサービスのカテゴリを抽出し、抽出した商品又はサービスのカテゴリを、各サブ口座における支払い用途としてユーザに提案するようにしてもよい。

具体的には、サーバ１０の管理者等は、商品又はサービスのカテゴリとして、予め、「食費」、「日用品」、「衣類」、「交際費」、「娯楽」、「交通費」、「医療費」、「教育費」といったカテゴリの選択肢をサーバ１０に設定しておく。続いて、管理部１０２は、決済履歴ＤＢのうち所定の期間（例えば過去半年など）に含まれるレコードの「支払対象」を参照し、各レコードが、上記設定したカテゴリのうちどのカテゴリに該当するのかを判定する。例えば図５の例では、支払対象が「洗剤」、「食器洗いスポンジ」及び「雑巾」であるレコードは「日用品」に該当すると判定できる。また、支払対象が「子供靴下」、「子供肌着」、「大人Ｔシャツ」及び「大人ズボン」であるレコードは「衣類」に該当すると判定できる。また、支払対象が「映画館」であるレコードは「娯楽」に該当すると判定できる。続いて、管理部１０２は、各サブ口座における支払用途として、「日用品」、「衣類」、「娯楽」の３つのカテゴリをユーザに提案する。これにより、提案を受けたユーザは、現在設定されているサブ口座の支払い用途を、より適切な支払い用途に変更することが可能になる。

なお、「支払対象」がどのカテゴリに該当するのかについては、例えばカテゴリごとに、そのカテゴリに含まれる商品名やサービス名を対応づけた辞書データベースを用意しておき、管理部１０２は、当該辞書データベースを検索することで、「支払対象」がどのカテゴリに該当するのかを判定するようにしてもよい。若しくは、文字列を入力することで、入力された文字列に最も近いと推定されるカテゴリを出力する学習済みモデルを用意しておき、管理部１０２は、当該学習済みモデルを利用することで、「支払対象」がどのカテゴリに該当するのかを判定するようにしてもよい。

以上説明したサブ口座用途のレコメンド処理について、管理部１０２は、決済履歴ＤＢに代えて、外部の電子商取引サイト等から取得した、ユーザが購入した商品やサービスの履歴を利用することとしてもよい。決済履歴ＤＢや外部の電子商取引サイトから取得した履歴等を、まとめて「決済情報」と称してもよい。

（決済処理）
図１０は、決済システム１が決済処理を行う際の処理手順の一例を示すシーケンス図である。図１０を用いて、端末２０を利用するユーザが、ユーザ読取型コード決済を利用して決済を行う際の処理手順を説明する。

まず、ユーザは、端末２０の画面を操作することで、決済サービスを利用するためのアプリケーションを起動させる（Ｓ２００）。端末２０の通知部２０４は、サーバ１０に、残高を要求するメッセージを送信する（Ｓ２０１）。当該メッセージには、端末２０を利用するユーザのユーザＩＤが含まれる。サーバ１０の管理部１０２は、口座管理ＤＢから、当該ユーザＩＤを有するユーザのメイン口座の残高、各サブ口座の残高を検索する（Ｓ２０２）。検索が完了すると、管理部１０２は、端末２０に、メイン口座の残高、各サブ口座の残高を含む残高通知メッセージを送信する（Ｓ２０３）。端末２０の表示部２０２は、メイン口座の残高、各サブ口座の残高を画面に表示する。

続いて、ユーザは、店舗のＰＯＳ端末等に表示される二次元コード等を読み取り、決済額を端末２０の画面に入力する（Ｓ２０４、Ｓ２０５）。また、ユーザは、端末２０の画面にて、支払いを行う口座（メイン口座、サブ口座１、サブ口座２・・・）を選択する（Ｓ２０６）。なお、ユーザが、端末２０の画面にて、支払いを行うサブ口座を選択しなかった場合、メイン口座が自動的に選択されることとしてもよい。続いて、端末２０の通知部２０４は、ユーザＩＤ、読み取った二次元コード等の情報、支払い額及び支払い口座を含む決済要求メッセージをサーバ１０に送信する（Ｓ２０７）。

サーバ１０の決済処理部１０４は、指定された支払い口座の残高が支払い額以上であることを確認する。支払い額以上である場合、決済処理部１０４は、指定された支払い口座の残高から支払い額を減算することで決済処理を行う（Ｓ２０８）。もし、指定された支払い口座の残高が支払い額未満（つまり残高不足）である場合、決済処理部１０４は、決済処理を行わずに処理を終了する。なお、指定された支払い口座の残高が支払い額未満である場合において、ユーザが、事後決済サービスを利用しており、かつ、支払い額が、事後決済サービスを利用可能な金額の範囲内である場合、決済処理部１０４は、事後決済サービスを使用して決済を行うこととしてもよい。なお、事後決済サービスとは、クレジットカードのように支払い時期を遅らせることができるサービスを意味する。残高不足の場合に事後決済サービスを使用するか否かを、ユーザが予め設定可能としてもよい。

決済処理部１０４は、決済完了したか、決済処理ができなかったか、事後決済サービスを利用したかのいずれかを示す決済結果通知を端末２０に送信する（Ｓ２０９）。端末２０の画面には、決済完了したか、決済処理ができなかったか、事後決済サービスを利用したかのいずれかが表示される（Ｓ２１０）。

図１０に示す処理手順では、ユーザが支払い口座を選択するようにしたが、サーバ１０が自動的に選択するようにしてもよい。この場合の処理手順の例を図１１に示す。なお、図１０と同一の処理手順については、図１０と同一の符号を付して説明は省略する。

端末２０の通知部２０４は、ユーザＩＤ、読み取った二次元コード等の情報及び支払い額を含む決済要求メッセージをサーバ１０に送信する（Ｓ３００）。続いて、サーバ１０の選択部１０３は、メイン口座及び１以上複数のサブ口座の中から、支払対象に関する情報（購入した商品又はサービスの名称、種別又はカテゴリなど）又は支払い先に関する情報（支払い先店舗の業種など）に基づいて、決済に用いる口座を１つ選択する（Ｓ３０１）。例えば選択部１０３は、支払対象に関する情報又は支払い先に関する情報と、各サブ口座の支払い用途とを比較し、支払対象に関する情報又は支払い先に関する情報と最も類似度が高い用途のサブ口座を、決済に用いる口座として選択するようにしてもよい。類似度の判定は、例えば、２つの文字列を入力することで、入力された２つの文字列の意味の類似度や関連度を出力する学習済みモデルを用意しておき、選択部１０３は、当該学習済みモデルを利用することで、支払対象に関する情報又は支払い先に関する情報と、各サブ口座の用途との類似度を判定するようにしてもよい。

また、ユーザが実際の店舗（オフラインの店舗）で支払いを行う場合、支払い先に関する情報を、端末２０の現在位置を示す位置情報に基づいて取得するようにしてもよい。例えば、店舗の位置と業種とを対応づけた業種データベースを用意しておき、選択部１０３は、当該業種データベースから、端末２０の現在位置を示す位置情報に対応する、ユーザが支払いを行う店舗の業種を取得するようにしてもよい。

なお、選択部１０３は、例えば、上述の類似度が所定の閾値以下である場合や、業種データベースにおいて端末２０の現在位置から所定の範囲内には店舗が存在しない場合など、決済に用いるサブ口座を特定できない場合、決済に用いる口座としてメイン口座を選択するようにしてもよい。

図１２は、支払い口座を選択する画面の一例を示す図である。図１２のＡに示すように、端末２０の画面には、口座全体におけるチャージ額の残高（￥３０，０００）、メイン口座の残高（￥１０，０００）、サブ口座１の残高（￥５，０００）、サブ口座２の残高（￥１５，０００）が表示されている。ユーザは、これらの口座の中から、支払いを行う口座を選択する。図１２のＡでは、ユーザはサブ口座１を選択しようとしている。

また、サブ口座の残高を画面に表示する際、残高が所定の閾値以下になったことを表示するようにしてもよい。当該表示は、例えば、サブ口座の残高を表示するアイコンを所定の色で表示することであってもよい。図１２のＢの例は、サブ口座２の残高が所定の閾値（例えば５００円など）を下回っていることを示している。

＜変形例＞
以上説明した決済処理は、店舗読取型コード決済にも提供することができる。店舗読取型コード決済の場合、図１０のステップＳ２０４及びステップＳ２０５の処理手順は省略され、その代わりに、端末２０に表示された二次元コード等を店舗のＰＯＳ端末等で読み取ることで決済が行われる。

サーバ１０の管理部１０２は、ユーザが利用する所定の電子商取引サービスにおけるユーザの売り上げを、メイン口座又はサブ口座にチャージするようにしてもよい。例えば図６には、電子商取引サービスにてユーザが商品を他のユーザに売却したことでユーザが得た売上額が記載されているが、この売上額を、メイン口座又はサブ口座にチャージするようにしてもよい。このとき、管理部１０２は、売却した商品の名称、種別又はカテゴリなどに基づいて、売上額をチャージする口座を１つ選択するようにしてもよい。例えば管理部１０２は、売却した商品の名称、種別又はカテゴリと、各サブ口座の支払い用途とを比較し、売却した商品の名称、種別又はカテゴリと最も類似度が高い用途のサブ口座を、売上額をチャージする口座として選択するようにしてもよい。類似度の判定は、例えば、２つの文字列を入力することで、入力された２つの文字列の意味の類似度や関連度を出力する学習済みモデルを用意しておき、選択部１０３は、当該学習済みモデルを利用することで、売却した商品の名称、種別又はカテゴリと、各サブ口座の用途との類似度を判定するようにしてもよい。

端末２０の表示部２０２は、メイン口座及びサブ口座の決済履歴を画面に表示するようにしてもよい。また、ユーザと所定の関係を有する他のユーザの決済履歴を表示可能としてもよい。

所定の関係とは、サーバ１０が、２以上のユーザ間の所定の関係を記憶していることを意味する。限定でなく例として、所定の関係は、相互に関係構築を承認した関係、少なくとも一方が関係構築を申し入れた関係、ユーザ情報に基づき構築された関係、ユーザ行動に基づき構築された関係、所定の条件が満たされたことにより関係構築がなされた状態を含んでもよい。なお、ユーザ情報に基づき構築された関係とは、１以上の同一または類似するユーザ情報を有するユーザ同士を関係づけた関係を含んでもよいし、ユーザ行動に基づき構築された関係とは、１以上の同一または類似するユーザ行動を有するユーザ同士を関係づけた関係を含んでもよい。

また、ユーザと所定の関係にあるユーザは、限定ではなく例として、ユーザと所定の関係にある全てのユーザでもよいし、予め定められた所定の人数のユーザであってもよいし、親密度が所定の度合い以上のユーザであってもよい。

ここで、親密度とは、所定の期間内（１か月間や２か月間などの予め固定された期間でもよいし、所定の関係を構築してから現在までの期間でもよい）においてユーザとの間で送受信したメッセージの送受信量が多い順に親密度が高くなるように決定される度合いであってもよい。また、所定の期間内においてユーザ間で行われた取引（商品の売買や、資産の送受信・両替等などを含む）の回数が多い順に親密度が高くなるように決定される度合いでもよい。

また、親密度とは、所定の関係が構築されてから現在までの期間の長さが長いほど親密度が高くなるように決定される度合いであってもよい。所定の関係を構築してから現在までの期間の長さは、絶対値であってもよいし、ユーザと所定の関係にある１以上のユーザの中での相対値であってもよい。

また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、他のユーザがユーザの位置から所定の範囲内にいる時間の長さが長いほど、親密度が高くなるように決定される度合いであってもよい。また、親密度とは、ユーザと所定の関係にある複数のユーザについて、所定の関係が構築されてから現在までの期間と、各ユーザの位置情報とに基づいて推定される関係性（例えば家族関係にあると推定される等が高いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、ユーザと共通のユーザの数（共通の友達の人数）が多いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザとコミュニケーションをとっているユーザと所定の関係を構築しているユーザのうち、ユーザ自身と所定の関係にあるユーザの数が多いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザ自身の属性と、ユーザと所定の関係にある複数のユーザの各々の属性との間における類似度が高いほど親密度が高くなるように決定される度合いであってもよい。ユーザの属性とは、限定ではなく例として、興味又は関心であってもよい。

サーバ１０の管理部１０２は、ユーザ間でチャージ額の送金を行う場合に、送金元ユーザが指定したサブ口座からの送金を可能としてもよい。このとき、送金先のユーザのサブ口座に、送金元ユーザのサブ口座の用途と同一の用途のサブ口座が存在する場合、管理部１０２は、送金先のユーザのサブ口座のうち、送金元のサブ口座の用途と同一のサブ口座にチャージ額を送金するようにしてもよい。

サーバ１０の管理部１０２は、決済完了後に、支払元のサブ口座を変更する（任意のサブ口座に付け替えを行う）ことを許容してもよい。

サーバ１０の管理部１０２は、口座全体の残高を管理するようにしてもよい。口座全体の残高は、メイン口座の残高及び各サブ口座の残高を合計した値と同一である。例えば、口座管理ＤＢに、口座全体の残高を示す値を格納するようにしておき、管理部１０２は、チャージや支払処理が行われる度に、口座全体の残高も変更するようにしてもよい。

＜まとめ＞
以上説明した実施形態によれば、ユーザが開設した口座において、チャージ額を、メイン口座及び用途別のサブ口座に分けて管理するようにした。これにより、決済利用額を用途別に管理することを可能にした。また、サブ口座を追加できるようにしたことで、ユーザは１つの口座を開設するだけで、チャージ額を用途別に管理することが可能になった。また、サブ口座ごとの残高を、サブ口座の支払い目的と一緒に表示するようにしたことで、ユーザは、どの目的であといくら使えるのかを容易に把握することができ、無駄遣いを抑制することを可能とした。また、これにより、なめらかな社会の創造に貢献することを可能とした。

以上説明した実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、材料、条件、形状及びサイズ等は、例示したものに限定されるわけではなく適宜変更することができる。また、異なる実施形態で示した構成同士を部分的に置換し又は組み合わせることが可能である。

１…決済システム、１０…サーバ、１１…ＣＰＵ、１２…記憶装置、１３…通信ＩＦ、１４…入力デバイス、１５…出力デバイス、２０…端末、１０１…記憶部、１０２…管理部、１０３…選択部、１０４…決済処理部、２０１…取得部、２０２…表示部、２０３…受付部、２０４…通知部

Claims (13)

1. ユーザが所有する口座の残高を、第１口座と、１以上の第２口座とに分けて管理する管理部と、
   決済が行われる際、前記第１口座及び前記１以上の第２口座の中から、前記決済に用いる一の口座の選択を行う選択部と、
   選択された前記決済に用いる一の口座の残高が前記決済の額以上である場合に、選択された前記決済に用いる一の口座の残高から前記決済の額を減算する決済処理部と、
   を有する情報処理装置。
2. 前記第１口座は、支払い用途が定められていない口座であり、
   前記第２口座は、支払い用途が定められている口座である、
   請求項１に記載の情報処理装置。
3. 前記管理部は、複数の第２口座を管理し、
   前記管理部は、前記ユーザによりチャージが行われる際、チャージされる金額を所定の配分に従って前記複数の第２口座の残高に加算する、
   請求項１又は２に記載の情報処理装置。
4. 前記管理部は、複数の第２口座を管理し、
   前記管理部は、前記ユーザが前記第２口座から過去に支払った金額の合計額を前記第２口座ごとに算出し、算出した前記第２口座ごとの合計額に基づいて、前記所定の配分を決定する、
   請求項３に記載の情報処理装置。
5. 前記チャージされる金額は、前記ユーザが利用する電子商取引サービスにおいて前記ユーザが売り上げた金額を含む、
   請求項３又は４に記載の情報処理装置。
6. 前記管理部は、複数の第２口座を管理し、
   前記管理部は、前記ユーザの決済情報から前記ユーザが支払った商品又はサービスのカテゴリを抽出し、抽出した商品又はサービスのカテゴリを、前記複数の第２口座における支払い用途として前記ユーザに提案する、
   請求項１〜５のいずれか一項に記載の情報処理装置。
7. 前記選択部は、前記第１口座及び前記１以上の第２口座の中から、前記ユーザが指定した口座を、前記決済に用いる一の口座として選択する、
   請求項１〜６のいずれか一項に記載の情報処理装置。
8. 前記選択部は、前記第１口座及び前記１以上の第２口座の中から、前記決済の対象に関する情報又は支払い先に関する情報に基づいて、前記決済に用いる一の口座を選択する、
   請求項１〜７のいずれか一項に記載の情報処理装置。
9. 情報処理装置が行う情報処理方法であって、
   ユーザが所有する口座の残高を、第１口座と、１以上の第２口座とに分けて管理するステップと、
   決済が行われる際、前記第１口座及び前記１以上の第２口座の中から、前記決済に用いる一の口座の選択を行うステップと、
   選択された前記決済に用いる一の口座の残高が前記決済の額以上である場合に、選択された前記決済に用いる一の口座の残高から前記決済の額を減算するステップと、
   を含む情報処理方法。
10. 情報処理装置に、
    ユーザが所有する口座の残高を、第１口座と、１以上の第２口座とに分けて管理するステップと、
    決済が行われる際、前記第１口座及び前記１以上の第２口座の中から、前記決済に用いる一の口座の選択を行うステップと、
    選択された前記決済に用いる一の口座の残高が前記決済の額以上である場合に、選択された前記決済に用いる一の口座の残高から前記決済の額を減算するステップと、
    を実行させるためのプログラム。
11. ユーザが所有する口座を管理する他の情報処理装置から、ユーザが所有する口座に含まれる、第１口座の残高と、１以上の第２口座の残高とを取得する取得部と、
    前記第１口座の残高と、前記１以上の第２口座の残高とを画面に表示する表示部と、
    前記画面に表示された前記第１口座と前記１以上の第２口座の中から、決済に用いる一の口座の選択を受け付ける受付部と、
    受け付けた前記決済に用いる一の口座を、前記他の情報処理装置に通知する通知部と、
    を有する情報処理装置。
12. 情報処理装置が行う情報処理方法であって、
    ユーザが所有する口座を管理する他の情報処理装置から、ユーザが所有する口座に含まれる、第１口座の残高と、１以上の第２口座の残高とを取得するステップと、
    前記第１口座の残高と、前記１以上の第２口座の残高とを画面に表示するステップと、
    前記画面に表示された前記第１口座と前記１以上の第２口座の中から、決済に用いる一の口座の選択を受け付けるステップと、
    受け付けた前記決済に用いる一の口座を、前記他の情報処理装置に通知するステップと、
    を含む情報処理方法。
13. 情報処理装置に、
    ユーザが所有する口座を管理する他の情報処理装置から、ユーザが所有する口座に含まれる、第１口座の残高と、１以上の第２口座の残高とを取得するステップと、
    前記第１口座の残高と、前記１以上の第２口座の残高とを画面に表示するステップと、
    前記画面に表示された前記第１口座と前記１以上の第２口座の中から、決済に用いる一の口座の選択を受け付けるステップと、
    受け付けた前記決済に用いる一の口座を、前記他の情報処理装置に通知するステップと、
    を実行させるためのプログラム。