JP2017091245A - 実行装置、実行方法及び実行プログラム - Google Patents

Abstract

【課題】様々な状況に応じて柔軟に電子マネーの不足分の決済を行うこと。【解決手段】本願に係る実行装置は、取得部と、実行部とを有する。取得部は、電子マネーを利用するユーザに関する情報であるユーザ情報を取得する。実行部は、ユーザが利用する電子マネーの決済においてチャージ残高に不足がある場合に、取得部によって取得されたユーザ情報に基づいて、当該ユーザからの操作を受けることなく当該ユーザが利用する電子マネー口座へのチャージを実行する。【選択図】図１

Description

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

近年、電子マネーが盛んに利用されている。電子マネーの決済においては、予めチャージされている金額が決済金額に不足した場合、新たに電子マネーをチャージすることを要するため、手間がかかるという課題がある。

このような電子マネーの決済に関する技術として、決済を行う利用者の端末側に与信情報を保持することで、電子マネー残高が決済金額に満たない場合であっても迅速な決済処理を可能とする電子マネー決済システムが知られている。

特開２００７−２１３３９９号公報

しかしながら、上記の従来技術では、様々な状況に応じて柔軟に電子マネーの不足分の決済を行うことができるとは限らない。具体的には、上記の従来技術では、金融機関における預金状態等に応じた与信情報を利用者の端末が備える必要がある。すなわち、上記の従来技術では、電子マネーを利用する際には、予め与信情報を準備しておき、かつ、与信情報を備えた端末での利用が必須となる。また、そもそも金融機関の与信情報を有していないユーザについては、従来技術を適用させることができない。このように、上記の従来技術では、電子マネーを利用する様々なユーザに対して利便性を享受させることは難しい。

本願は、上記に鑑みてなされたものであって、様々な状況に応じて柔軟に電子マネーの不足分の決済を行うことができる実行装置、実行方法及び実行プログラムを提供することを目的とする。

本願に係る実行装置は、電子マネーを利用するユーザに関する情報であるユーザ情報を取得する取得部と、前記ユーザが利用する電子マネーの決済においてチャージ残高に不足がある場合に、前記取得部によって取得されたユーザ情報に基づいて、当該ユーザからの操作を受けることなく当該ユーザが利用する電子マネー口座へのチャージを実行する実行部と、を備えたことを特徴とする。

実施形態の一態様によれば、様々な状況に応じて柔軟に電子マネーの不足分の決済を行うことができるという効果を奏する。

図１は、実施形態に係る実行処理の一例を示す図である。 図２は、実施形態に係る事業者サーバの構成例を示す図である。 図３は、実施形態に係るユーザ情報記憶部の一例を示す図である。 図４は、実施形態に係る購買行動テーブルの一例を示す図である。 図５は、実施形態に係るアプリ履歴テーブルの一例を示す図である。 図６は、実施形態に係るＳＮＳ情報テーブルの一例を示す図である。 図７は、実施形態に係る電子マネー口座情報記憶部の一例を示す図である。 図８は、実施形態に係る利用履歴情報の一例を示す図である。 図９は、実施形態に係る事業者サーバによる処理手順を示すフローチャートである。 図１０は、事業者サーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

〔１．実行処理の一例〕
まず、図１を用いて、実施形態に係る実行処理の一例について説明する。図１は、実施形態に係る実行処理の一例を示す図である。図１では、実行システム１を例に挙げて、本願に係る実行処理の一形態について説明する。具体的には、図１では、実行システム１に含まれるサーバ装置であって、本願に係る実行装置に対応するサーバ装置である事業者サーバ１００によって、ユーザが利用する電子マネーの決済におけるチャージ処理が行われる一例について説明する。なお、事業者サーバ１００が実行するチャージ処理とは、所定の条件の下、ユーザに代わり、ユーザの電子マネー口座にチャージ額を自動的に発生させることをいう。

図１に示すように、実行システム１には、ユーザ端末１０と、店舗端末３０と、金融機関サーバ４０と、事業者サーバ１００とが含まれる。実行システム１に含まれる各装置は、図示しない通信ネットワーク（例えば、インターネット）を介して、互いに通信可能に接続される。なお、実行システム１に含まれる各装置の台数は、図１に示した例に限られない。例えば、実行システム１には、複数台のユーザ端末１０が含まれてもよい。

ユーザ端末１０は、一般ユーザによって利用される情報処理装置である。具体的には、ユーザ端末１０は、ユーザがウェブページを閲覧したり、ユーザ端末１０にインストールされたアプリケーションを使用したりするために利用される。また、ユーザ端末１０には、電子マネー機能が搭載される。この場合、ユーザ端末１０は、電子マネーのチャージや決済処理を行うことができる。ユーザ端末１０は、例えば、スマートフォンやタブレット端末やＰＤＡ（Personal Digital Assistant）等の移動端末や、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣ等により実現される。図１の例では、ユーザ端末１０は、ユーザＵ０１によって利用されるスマートフォンであり、電子マネー機能を備えるものとする。ユーザ端末１０は、例えば、インストールされた所定のアプリケーションによって、電子マネー機能を実現する。

店舗端末３０は、店舗に備えられる所定の情報処理装置である。店舗端末３０は、電子マネーの決済機能を有する。例えば、店舗端末３０は、ユーザから電子マネーのチャージや、電子マネーを用いた決済を受け付ける。具体的には、店舗端末３０は、店舗で販売している商品をユーザが購入する際に、電子マネーによる決済処理を受け付ける。そして、店舗端末３０は、電子マネーが利用された際には、ネットワークを介して、事業者サーバ１００に電子マネーの利用に関する情報を送信する。

金融機関サーバ４０は、金融機関に備えられるサーバ装置である。金融機関サーバ４０は、所定の取り決めに従い、ユーザが金融機関で開設した口座における入出金の管理を行う。例えば、金融機関サーバ４０は、事業者サーバ１００が後述するチャージ処理を実行した場合に、その額に応じた口座振替を実行する。

事業者サーバ１００は、電子マネーによる決済等を行う事業者によって利用されるサーバ装置である。事業者サーバ１００は、電子マネーに関する入出金を記録する電子マネー口座を管理する。事業者サーバ１００は、ユーザから電子マネーの利用を受け付ける。例えば、事業者サーバ１００は、電子マネーの決済機能を有する店舗端末３０を介して、ネットワーク経由で電子マネーの利用を受け付ける。事業者サーバ１００は、ユーザが電子マネーの入金処理（チャージ）を行った場合には、当該ユーザの電子マネー口座におけるチャージ額を加算する。また、事業者サーバ１００は、ユーザが電子マネーを利用して商品を購入した場合には、決済処理を行い、当該ユーザの電子マネー口座のチャージ額から購入額分を引き落とす。

また、事業者サーバ１００は、ユーザが電子マネーのチャージ額を超えて決済を試みた場合、言い換えれば、電子マネーの決済において不足分がある場合に、所定の条件のもと、不足分のチャージ処理を実行する。これにより、ユーザは、チャージ額が不足する際に決済処理を試みた場合でも、決済不可によるエラー等の警告を受けずに決済処理を済ませることができる。このため、ユーザは、チャージ額を気にせず電子マネーを利用することができたり、不足分のチャージを行う手間が省けたりするなどの利便性を享受することができる。事業者サーバ１００は、上記の処理に用いる情報の記憶部として、ユーザ情報記憶部１２１と、電子マネー口座情報記憶部１２２とを有する。なお、事業者サーバ１００が実行するチャージにより発生するチャージについては、区別のため、仮チャージと表記する場合がある。以下、図１を用いて、実行システム１による仮チャージの実行処理を流れに沿って説明する。

図１の例において、ユーザＵ０１は、電子マネーの決済を行う（ステップＳ１１）。例えば、ユーザＵ０１は、訪問した店舗において商品を購入する際に、電子マネーによる決済を試みる。事業者サーバ１００は、ネットワークを介して、ユーザＵ０１の電子マネーの決済に関する情報を取得する（ステップＳ１２）。なお、ステップＳ１１及びステップＳ１２の処理は、ユーザＵ０１が訪問した店舗に備えられる店舗端末３０を介して行われてもよい。

ここで、事業者サーバ１００は、電子マネーの決済に関する情報として、ユーザＵ０１に関する情報（ユーザ情報）を取得する。例えば、事業者サーバ１００は、ユーザ端末１０を利用して電子マネーの決済が行われた場合、ユーザ情報として、ユーザＵ０１を識別するための識別情報を取得する。また、事業者サーバ１００は、ユーザ端末１０に保持された情報に基づいて、ユーザＵ０１のネットワーク上の行動履歴等をユーザ情報として取得する。なお、事業者サーバ１００は、取得した識別情報に基づいて、予めユーザ情報記憶部１２１に記憶されているユーザＵ０１のユーザ情報を特定することで、ユーザＵ０１のユーザ情報を取得してもよい。そして、事業者サーバ１００は、取得したユーザ情報に基づいて算出される情報である、ユーザＵ０１の信用度を取得する。詳細は後述するが、ユーザ情報にはユーザＵ０１に関する種々の情報が含まれる。事業者サーバ１００は、種々のユーザ情報に基づいて信用度を算出する。なお、事業者サーバ１００は、算出された信用度についても、ユーザＵ０１に関する情報であることから、ユーザ情報の１つとしてユーザ情報記憶部１２１に保持しておくものとする。

そして、事業者サーバ１００は、ユーザＵ０１の信用度が所定の基準を満たしており、かつ、ユーザＵ０１の電子マネーの決済に不足分が生じている場合には、不足分のチャージ処理を実行する（ステップＳ１３）。具体的には、事業者サーバ１００は、不足分の金額に対応する額を自動的にチャージする仮チャージを行うことにより、決済において不足していた額の支払いを可能とするための処理を行う。事業者サーバ１００は、このようにしてステップＳ１１で実行された決済処理が完了した場合には、決済の完了をユーザＵ０１に通知する（ステップＳ１４）。このように、事業者サーバ１００は、電子マネーを利用したユーザＵ０１のユーザ情報に基づいて、不足分のチャージ処理を行う。これにより、ユーザＵ０１は、決済の時点でチャージ額が不足していた場合であっても、支障なく決済処理を完了させることができる。なお、事業者サーバ１００は、必ずしも不足分ちょうどの額をチャージするのではなく、不足分を超える額をチャージするようにしてもよい。また、事業者サーバ１００は、電子マネーの決済や仮チャージに基づいて、ユーザＵ０１に係る電子マネー口座情報記憶部１２２の情報を適宜更新する。

その後、事業者サーバ１００は、所定のタイミングで電子マネーが利用された店舗への入金処理を行う（ステップＳ１５）。例えば、事業者サーバ１００は、毎月定められた特定の日や、店舗へ入金すべき金額がある一定の金額に達した場合に、店舗への入金処理を行う。

また、事業者サーバ１００は、所定のタイミングで、チャージにより発生した仮チャージ額の返済をユーザＵ０１に要求する。例えば、事業者サーバ１００は、ユーザＵ０１が契約している金融機関の口座を介して、仮チャージ額の返済を要求する。言い換えれば、事業者サーバ１００が実行するチャージ（仮チャージ）とは、ネットワーク上のユーザの行動履歴等から算出される信用度に応じて、本来、決済の前にユーザがチャージしておくべき金額をまとめて後払いすることを許容する（事業者サーバ１００がチャージを立て替えておく）ものといえる。

例えば、事業者サーバ１００は、ユーザＵ０１が契約している金融機関の口座に関する情報をユーザ情報として取得しておく。そして、事業者サーバ１００は、金融機関サーバ４０に対して、所定のタイミングでユーザＵ０１に対してチャージを行った金額分の口座振替を要求する（ステップＳ１６）。具体的には、事業者サーバ１００は、毎月定められた特定の日や、ユーザＵ０１に対してチャージした金額がある一定の金額に達した場合に、ユーザＵ０１の金融機関の口座から事業者サーバ１００に対して、チャージした金額に相当する額の口座振替を要求する。金融機関サーバ４０は、要求された口座振替を実行する（ステップＳ１７）。口座振替が実行された場合には、事業者サーバ１００は、口座振替の完了をユーザに通知する（ステップＳ１８）。このような処理により、事業者サーバ１００は、ユーザＵ０１に対する仮チャージ額を一定の金額に抑えることができるため、円滑な運用を行うことができる。

上述してきたように、実施形態に係る事業者サーバ１００は、電子マネーを利用するユーザに関する情報であるユーザ情報を取得する。そして、事業者サーバ１００は、ユーザが利用する電子マネーの決済において残高に不足がある場合に、取得されたユーザ情報に基づいて、ユーザが利用する電子マネー口座にチャージを実行する。

このように、実施形態に係る事業者サーバ１００は、ユーザが利用する電子マネーに関して、決済の時点でチャージ額が不足していた場合であっても、支障なく決済処理を完了させることができる。すなわち、事業者サーバ１００は、決済の時点でチャージ額が不足している場合であっても、新たなチャージ処理をユーザに負わせることなく決済処理を完了させることで、ユーザの利便性を向上させる。また、事業者サーバ１００は、電子マネーを利用するユーザのユーザ情報を取得しておき、電子マネーが使用された場合に、ユーザを特定することで、仮チャージ処理が実行可能か否かを判定する。このため、事業者サーバ１００によれば、与信情報等が保持されたユーザ端末１０以外が使用された場合であっても、電子マネーの使用に際して、ユーザを識別する情報を取得さえすれば、当該ユーザに関する仮チャージ処理を実行することができる。また、事業者サーバ１００は、ユーザ情報に基づいてチャージを行うため、例えば、即時の引き落としに対応する口座（金融機関の口座等）を有しなくとも、決済の時点では、支障なく決済処理を行うことができる。このため、ユーザは、与信情報を要するクレジットカードによる決済手法や、即時の引き落としに対応する口座を要するデビットカードによる決済手法によらず、電子マネーの仮チャージ処理の利便性を享受できる。このように、事業者サーバ１００は、様々な状況に応じて柔軟に電子マネーの不足分の決済を行うことができる。

〔２．事業者サーバの構成〕
次に、図２を用いて、実施形態に係る事業者サーバ１００の構成について説明する。図２は、実施形態に係る事業者サーバ１００の構成例を示す図である。図２に示すように、事業者サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、事業者サーバ１００は、事業者サーバ１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を出力するための出力部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。かかる通信部１１０は、通信ネットワークと有線又は無線で接続され、通信ネットワークを介して、ユーザ端末１０や、店舗端末３０や、金融機関サーバ４０との間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。実施形態に係る記憶部１２０は、ユーザ情報記憶部１２１と、電子マネー口座情報記憶部１２２とを有する。以下、各記憶部について順に説明する。

（ユーザ情報記憶部１２１について）
ユーザ情報記憶部１２１は、電子マネーを利用するユーザに関する情報を記憶する。ここで、図３に、実施形態に係るユーザ情報記憶部１２１の一例を示す。図３に示すように、ユーザ情報記憶部１２１は、「ユーザＩＤ」、「端末ＩＤ」、「電子マネー口座」、「金融機関口座」、「信用度」といった項目を有する。

「ユーザＩＤ」は、ユーザを識別するための識別情報を示す。「端末ＩＤ」は、ユーザが利用する端末装置を識別するための識別情報を示す。なお、実施形態において、ユーザＩＤや端末ＩＤは、説明で用いる参照符号と共通するものとする。例えば、ユーザＩＤが「Ｕ０１」であるユーザは、「ユーザＵ０１」を示す。また、端末ＩＤが「１０」である端末装置は、「ユーザ端末１０」を示す。

「電子マネー口座」は、ユーザが有する電子マネーの口座を示す。「金融機関口座」は、ユーザが有する金融機関の口座を示す。図３では、電子マネー口座や金融機関口座は、「ＸＸＸ」や「ＹＹＹ」等の概念で示しているが、実際には、口座番号などの口座を特定する情報が記憶される。

「信用度」は、事業者サーバ１００がチャージを行う際に参照する、ユーザの信用度を示す。実施形態では、信用度は、５段階の数値で表され、５が最も信用度が高く、１が最も信用度が低いものとする。なお、事業者サーバ１００は、後述する各データテーブルに記憶される情報に基づいて、ユーザの信用度を算出する。そして、事業者サーバ１００は、算出された数値をユーザＩＤと対応付けてユーザ情報記憶部１２１に記憶する。

すなわち、図３では、ユーザ情報の一例として、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１が、端末ＩＤ「１０」で識別されるユーザ端末１０を利用しており、電子マネー口座「ＸＸＸ」と、金融機関口座「ＹＹＹ」を有しており、信用度は「４」である例を示している。

なお、図３では、ユーザＵ０１が端末装置や電子マネー口座や金融機関口座を一つずつ有する例を示したが、ユーザＵ０１は、端末装置や電子マネー口座や金融機関口座を複数有していてもよい。

また、ユーザ情報記憶部１２１は、ユーザの信用度を算出するために用いる情報として、ユーザの行動履歴等を記憶した各データテーブルを有する。図２に示すように、ユーザ情報記憶部１２１は、実施形態において、購買行動テーブル１２１１と、アプリ履歴テーブル１２１２と、ＳＮＳ（Social Networking Service）情報テーブル１２１３とを有する。

（購買行動テーブル１２１１について）
購買行動テーブル１２１１は、ネットワークを介して取得される、ユーザの購買行動に関する情報を記憶する。ここで、図４に、実施形態に係る購買行動テーブル１２１１の一例を示す。図４に示すように、購買行動テーブル１２１１は、「ユーザＩＤ」、「購買行動評価」、「オークション評価」、「購買行動情報」といった項目を有する。

「ユーザＩＤ」は、図３で示した同一の項目に対応する。「購買行動評価」は、ユーザのネットワークを介した購買行動に関する評価値を示す。実施形態では、購買行動評価は、５段階の数値で表され、５が最も評価が高く、１が最も評価が低いものとする。購買行動評価は、購買行動に関するユーザの信用度を示す。購買行動評価は、例えば、ユーザが所定期間内（例えば１カ月間）にユーザが商品を購入した金額の総額や、購買行動の頻度や、購買行動が適切であったか（支払いの遅延等が発生しなかったか）等に基づき算出される。なお、購買行動評価は、各店舗がユーザを評価した評価値を集計し、集計された評価値から求められる数値（平均値等）等であってもよい。

「オークション評価」は、ユーザが所定のオークションサイトを利用している場合に、ユーザのオークションサイトにおける行動の評価値を示す。実施形態では、オークション評価は、５段階の数値で表され、５が最も評価が高く、１が最も評価が低いものとする。オークション評価は、オークションに関するユーザの信用度を示す。例えば、オークション評価は、迅速な連絡のやり取りや支払いの遅延等のない適切な取引が行われたか、オークションに商品を出品する頻度、商品を落札する頻度等に基づき算出される。なお、オークション評価は、オークションに参加する他のユーザが評価対象となるユーザを評価した評価値を集計し、集計された評価値から求められる数値（平均値等）等であってもよい。

「購買行動情報」は、ユーザの購買行動に関する行動履歴（行動ログ）を示す。購買行動情報は、「行動日時」、「行動種別」、「金額」といった小項目を有する。

「行動日時」は、ユーザが購買行動等を行った日時を示す。「行動種別」は、ユーザの購買行動の種別を示す。例えば、行動種別の項目には、商品購入や、オークションの出品、入札、落札等の行動が記憶される。「金額」は、購買行動に関する金額を示す。

すなわち、図４では、購買行動情報の一例として、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１の購買行動評価は「４」であり、オークション評価は「４．５」であり、購買行動情報の履歴の一つとして、「２０１５年１１月１日 １０時００分」に「商品購入」し、その金額は「１５０００円」であるという履歴があることを示している。

なお、購買行動テーブル１２１１には、図４に示した例以外にも、ユーザの購買行動に関する情報として、例えば、ユーザが訪問したオークションサイトやショッピングサイトを特定する情報や、金額の授受のない無料のダウンロードコンテンツのダウンロード履歴等が記憶されてもよい。また、購買行動テーブル１２１１に記憶される購買行動は、電子マネーが利用された購買行動であってもよいし、それ以外の決済手法（クレジットカード等）が利用された購買行動であってもよい。

（アプリ履歴テーブル１２１２について）
アプリ履歴テーブル１２１２は、ユーザが使用する端末装置で実行されるアプリに関する履歴が記憶される。ここで、図５に、実施形態に係るアプリ履歴テーブル１２１２の一例を示す。図５に示すように、アプリ履歴テーブル１２１２は、「ユーザＩＤ」、「アプリ行動評価」、「アプリ使用情報」といった項目を有する。

「ユーザＩＤ」は、図３で示した同一の項目に対応する。「アプリ行動評価」は、ユーザがアプリを使用する行動に関する評価値を示す。実施形態では、アプリ行動評価は、５段階の数値で表され、５が最も評価が高く、１が最も評価が低いものとする。アプリ行動評価は、アプリ使用の履歴に基づき、ユーザの購買力や資金力を評価した値である。アプリ行動評価は、例えば、使用に際してある一定の資金力を要すると想定されるアプリの使用頻度等に基づき算出される。使用に際してある一定の資金力を要すると想定されるアプリは、例えば、タクシー配車アプリや、レストラン予約アプリ等である。なお、アプリ行動評価は、ユーザが使用するアプリを提供する提供者（アプリ提供事業者等）がユーザを評価した評価値を集計し、集計された評価値から求められる数値（平均値等）等であってもよい。

「アプリ使用情報」は、ユーザのアプリの使用に関する履歴（ログ）を示す。アプリ使用情報は、「行動日時」、「アプリ」といった小項目を有する。

「行動日時」は、ユーザがアプリを使用した日時を示す。「アプリ」は、ユーザが使用したアプリを特定する情報を示す。

すなわち、図５では、アプリ使用情報の一例として、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１のアプリ行動評価は「３」であり、アプリ使用の履歴の１つとして、「２０１５年１１月７日 １０時００分」に「タクシー配車アプリ」の使用があったことを示している。

（ＳＮＳ情報テーブル１２１３について）
ＳＮＳ情報テーブル１２１３は、ユーザが利用するＳＮＳに関する情報を記憶する。ここで、図６に、実施形態に係るＳＮＳ情報テーブル１２１３の一例を示す。図６に示すように、ＳＮＳ情報テーブル１２１３は、「ユーザＩＤ」、「ＳＮＳ評価」、「ＳＮＳ使用情報」といった項目を有する。

「ユーザＩＤ」は、図３で示した同一の項目に対応する。「ＳＮＳ評価」は、ユーザが使用するＳＮＳに関する評価値を示す。実施形態では、ＳＮＳ評価は、５段階の数値で表され、５が最も評価が高く、１が最も評価が低いものとする。ＳＮＳ評価は、ＳＮＳの利用の履歴に基づき、ユーザの社会的信用度等を評価した値である。ＳＮＳ評価は、例えば、ユーザが利用するＳＮＳにおいて他のユーザと関係を有している数（実施形態では「つながり数」と表記する）や、関係を有する他のユーザの評価値等に基づき算出される。

「ＳＮＳ使用情報」は、ユーザが利用するＳＮＳの使用状況に関する情報を示す。ＳＮＳ使用情報は、「ＳＮＳ名称」、「つながり数」、「つながり先評価」といった小項目を有する。

「ＳＮＳ名称」は、ユーザが利用しているＳＮＳの名称を示す。「つながり数」は、ＳＮＳにおいて他のユーザと関係を有している数を示す。例えば、つながり数は、ＳＮＳ上におけるフォローユーザ数などが該当する。「つながり先評価」は、ＳＮＳでつながりを有する他のユーザの評価を示す。例えば、つながり先評価は、「ＳＮＳ評価」と同様、５段階の数値で示され、ユーザがつながっている他のユーザにおける評価の平均値等により算出される。つながり先評価が高いということは、ユーザがつながっている他のユーザのＳＮＳ評価が高いということであり、言い換えれば、当該ユーザが、社会的信用度の高い他のユーザと多くつながっていることを示している。

すなわち、図６では、ユーザのＳＮＳ使用情報の一例として、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１のＳＮＳ評価は「４」であり、ＳＮＳの使用状況の１つとして、ＳＮＳ名称「ＡＡＡ」であるＳＮＳサイトにおける他のユーザとのつながり数は「７０」であり、つながり先評価は「３．３」であることを示している。

なお、ＳＮＳ情報テーブル１２１３では、例えば、ユーザとつながる他のユーザの社会的地位や収入等の情報が記憶されてもよい。また、事業者サーバ１００は、ユーザとつながる他のユーザの社会的地位や収入等の情報に基づいて、つながり先評価の値を算出してもよい。事業者サーバ１００は、このように他のユーザの社会的地位や収入等の情報が加味されたつながり先評価を、ユーザ自身のＳＮＳ評価の算出に用いることにより、当該ユーザの社会的信用度を精度よく算出することができる。

（電子マネー口座情報記憶部１２２について）
電子マネー口座情報記憶部１２２は、ユーザの電子マネーの口座情報を記憶する。ここで、図７に、実施形態に係る電子マネー口座情報記憶部１２２の一例を示す。図７に示すように、電子マネー口座情報記憶部１２２は、「ユーザＩＤ」、「電子マネー口座」、「利用履歴情報」、「仮チャージ情報」といった項目を有する。

「ユーザＩＤ」及び「電子マネー口座」は、図３で示した同一の項目に対応する。「利用履歴情報」は、電子マネーの利用履歴を記憶する。図７では、利用履歴情報は「Ｇ０１」等の概念で表記しているが、実際には、電子マネーが利用された日時や、行動種別等がログとして記憶される。利用履歴情報の詳細については、後述する。

「仮チャージ情報」は、電子マネーの決済において不足分が生じた際に事業者サーバ１００が実行するチャージに関する情報を示す。仮チャージ情報は、「金融機関口座」、「仮チャージ限度額」、「口座振替日」といった小項目を有する。

「金融機関口座」は、ユーザが契約している金融機関の口座を特定する情報を示す。「仮チャージ限度額」は、事業者サーバ１００が実行するチャージの所定期間（例えば１カ月間）における限度額を示す。「口座振替日」は、事業者サーバ１００によるチャージが実行された場合に、仮チャージ額に相当する金額を金融機関口座から口座振替を実行する設定日を示す。

すなわち、図７では、電子マネー口座に関する情報の一例として、ユーザＩＤ「Ｕ０１」で識別されるユーザＵ０１の電子マネー口座は「ＸＸＸ」であり、利用履歴情報は「Ｇ０１」であり、チャージが実行された場合に、仮チャージ額を振り替える金融機関口座は「ＹＹＹ」であり、仮チャージ限度額は「１００００円」であり、口座振替日は「毎月２５日」であることを示している。

なお、図７において、仮チャージ限度額や口座振替日については、事業者サーバ１００側で自動的に設定されてもよいし、ユーザからの要望に応じて設定されてもよい。

続いて、図８を用いて、電子マネー口座の利用履歴に関する情報について説明する。図８は、実施形態に係る利用履歴情報Ｇ０１の一例を示す図である。図８に示すように、利用履歴情報Ｇ０１は、ユーザＵ０１の電子マネーに関する利用履歴（ログ）を記憶する。利用履歴情報Ｇ０１は、「利用履歴」として、「利用日時」、「利用態様」、「金額」、「チャージ残高」、「仮チャージ額合計」といった小項目を有する。

「利用日時」は、電子マネーが利用された日時を示す。「利用態様」は、チャージや購入など、電子マネーの利用の態様を示す。「金額」は、利用の際に取引された金額を示す。なお、金額の項目において、「△」の記号はマイナスの値を示す。「チャージ残高」は、電子マネー口座にチャージされている残高を示す。「仮チャージ額合計」は、事業者サーバ１００によりチャージが実行された額の合計を示す。

すなわち、図８に示す例では、ユーザＵ０１の電子マネー口座の利用履歴情報Ｇ０１として、以下のような履歴が記憶されている。まず、ユーザＵ０１が「２０１５年１０月７日 １０時００分」に「５０００円」を「チャージ」したことで、チャージ残高は「５０００円」となる。そして、「２０１５年１０月１０日 ８時００分」に「３０００円」の商品を「購入」したことで、チャージ残高は「２０００円」となる。また、「２０１５年１０月１５日 １５時００分」に「３０００円」の商品を「購入」したことで、チャージ残高は「△１０００円」となる。

この場合、事業者サーバ１００は、チャージを実行する。事業者サーバ１００が実行したチャージは、利用履歴では、仮チャージとして記憶される。すなわち、利用履歴には、「２０１５年１０月１５日 １５時００分」に「１０００円」の「仮チャージ」が行われ、チャージ残高は「０円」になるとともに、仮チャージ額合計に「１０００円」が記憶される。そして、「２０１５年１０月２５日 ０時００分」に「１０００円」分の「口座振替（月次）」が行われ、ユーザＵ０１の仮チャージ額が「０円」にリセットされる。なお、図７で示したように、ユーザＵ０１の口座振替日は「毎月２５日」となっていることから、原則として、毎月２５日に仮チャージ額に相当する金額が金融機関口座「ＹＹＹ」から振り替えられることとなる。

続いて、ユーザＵ０１が「２０１５年１１月２０日 ８時００分」に「４０００円」を「チャージ」し、チャージ残高は「４０００円」であるが、この時点での仮チャージ額合計は「５０００円」であるものとする。そして、「２０１５年１１月２２日 １３時００分」に「１００００円」の商品を「購入」したことで、チャージ残高は「△６０００円」となる。この場合、事業者サーバ１００は、チャージを実行する。すなわち、利用履歴には、「２０１５年１１月２２日 １３時００分」に「６０００円」の「仮チャージ」が行われ、チャージ残高は「０円」になるとともに、仮チャージ額合計に「１１０００円」が記憶される。

ここで、事業者サーバ１００は、仮チャージ合計額が仮チャージ限度額である「１００００円」を超えたことを判定する。そして、事業者サーバ１００は、仮チャージ限度額を超えた場合には、設定された口座振替日の前であっても、口座振替を実行する。例えば、事業者サーバ１００は、仮チャージ限度額に相当する額の口座振替を要求する。そして、「２０１５年１１月２２日 １３時０５分」に「１００００円」分の「口座振替（限度額）」が行われ、ユーザＵ０１の電子マネー口座の仮チャージ額合計から「１００００円」が差し引かれる。これにより、仮チャージ額合計は、「１０００円」となる。

（制御部１３０について）
制御部１３０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、事業者サーバ１００内部の記憶装置に記憶されている各種プログラム（実行プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

実施形態に係る制御部１３０は、図２に示すように、取得部１３１と、算出部１３２と、決済部１３３と、チャージ実行部１３４と、通知部１３５を有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図２に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図２に示した接続関係に限られず、他の接続関係であってもよい。

（取得部１３１について）
取得部１３１は、ユーザによって利用される電子マネーに関する情報を取得する。例えば、取得部１３１は、電子マネーが利用される際に、電子マネー口座を特定する識別情報を取得する。また、取得部１３１は、電子マネーが利用された際の利用情報について取得する。すなわち、取得部１３１は、電子マネーが利用された態様（チャージや使用等）や金額に関する情報を取得する。

また、取得部１３１は、電子マネーを利用するユーザに関する情報であるユーザ情報を取得する。具体的には、取得部１３１は、ユーザ情報として、ユーザを識別する識別情報やユーザの属性情報、ユーザのネットワーク上の行動履歴等を取得する。例えば、取得部１３１は、外部の情報処理装置（例えば、ユーザがアクセスするウェブサーバ等）を介してユーザのネットワーク上の行動履歴を取得する。また、取得部１３１は、電子マネーがユーザ端末１０を介して利用される際には、ユーザ端末１０を介して、ユーザ端末１０内に蓄積されたユーザのネットワーク上の行動履歴を取得してもよい。

取得部１３１は、ユーザのネットワーク上の行動履歴として、例えば、ユーザのネットワーク上の購買行動に関する履歴を取得する。具体的には、取得部１３１は、ネットワーク上の購買行動として、購買行動における購買額、又は、購買行動の頻度等を取得する。取得部１３１は、例えば、ショッピングサイトやオークションサイトを運営するウェブサーバ等のサービス提供サーバ等から、ユーザの購買行動に関する情報を取得する。

また、取得部１３１は、ユーザが利用するユーザ端末１０で実行されるアプリケーションに関する履歴を取得してもよい。取得部１３１は、電子マネーの機能を有するユーザ端末１０を介して、ユーザ端末１０で実行されたアプリケーションの利用履歴を取得してもよいし、アプリケーションを提供するアプリ提供サーバからアプリケーションの利用履歴を取得してもよい。

また、取得部１３１は、ユーザが利用する社会的ネットワーク構築のためのサービス内における当該ユーザの知名度、評判、人脈の少なくともいずれか一つに関する情報を取得してもよい。社会的ネットワーク構築のためのサービスとは、例えば、ＳＮＳサービス等である。また、ユーザの知名度、評判、人脈等は、ＳＮＳ評価、他のユーザからつながりを申請された数、他のユーザとつながっている数、他のユーザのＳＮＳ評価等により判定される。

取得部１３１は、取得した情報をユーザ情報記憶部１２１や電子マネー口座情報記憶部１２２に格納する。

（算出部１３２について）
算出部１３２は、取得部１３１によって取得されたユーザ情報に基づいて、ユーザの信用度を算出する。例えば、算出部１３２は、ユーザのネットワーク上の行動履歴に基づいてユーザの信用度を算出する。ユーザの信用度は、事業者サーバ１００によるチャージ実行の判定に用いられる。

例えば、算出部１３２は、ユーザの購買行動に関して、図４に示したような購買行動評価やオークション評価を算出する。さらに、算出部１３２は、購買行動評価やオークション評価の値に基づいて、ユーザの信用度を算出する。例えば、算出部１３２は、購買実績の多いユーザや購買量の多いユーザ、購買に関して適切な対応を行うユーザに対して、信用度を高く算出する。言い換えれば、算出部１３２は、資金力を有し、また、社会的信用性の高いユーザの信用度を高く算出する。算出部１３２が購買行動（行動頻度や売買額）等を評価する算出手法に関しては、例えば、事業者サーバ１００の管理者によって適宜、設計変更可能である。

また、算出部１３２は、ユーザのアプリの使用に関して、図５に示したようなアプリ評価を算出する。さらに、算出部１３２は、アプリ行動評価の値に基づいて、ユーザの信用度を算出する。すなわち、算出部１３２は、ある一定の資金力を要すると想定されるアプリの使用頻度等に基づいてユーザを評価し、かかる評価をユーザの信用度として算出する。言い換えれば、算出部１３２は、ユーザのアプリの使用履歴に基づいてユーザの資金力を推定し、資金力を有していると推定されるユーザの信用度を高く算出する。

また、算出部１３２は、ユーザのＳＮＳの使用に関して、図６に示したようなＳＮＳ評価を算出する。そして、算出部１３２は、ＳＮＳ評価の値に基づいて、ユーザの信用度を算出する。すなわち、算出部１３２は、ネットワーク上においてつながり数の多いユーザや、評価の高い他のユーザと多くつながっているユーザを評価し、かかる評価をユーザの信用度として算出する。言い換えれば、算出部１３２は、社会的信用性が高いと推定されるユーザや、高い社会的地位を有していると推定されるユーザの信用度を高く算出する。

なお、算出部１３２は、上述してきたような購買行動評価やオークション評価などの個々の評価値を総合して算出した値をユーザの信用度としてもよい。すなわち、算出部１３２は、取得部１３１によって取得された様々なユーザ情報に基づいて、総合的なユーザの信用度を算出する。これにより、算出部１３２は、ユーザの資金力や社会的信用性が精度よく反映された信用度をユーザに付与することができる。

（決済部１３３について）
決済部１３３は、電子マネーに関する決済処理を実行する。具体的には、決済部１３３は、取得部１３１によって取得された電子マネーの利用に関する情報に基づいて、利用された電子マネー口座を特定する。そして、決済部１３３は、電子マネーの利用の態様に沿って、決済処理を実行する。

例えば、決済部１３３は、ユーザからチャージ処理が行われた場合には、当該ユーザのチャージ残高にチャージされた金額を加える処理を実行する。また、決済部１３３は、ユーザが電子マネーを利用して商品を購入する場合には、チャージ残高から購入分の額を差し引く処理を実行する。決済部１３３は、決済処理を行った場合、処理の履歴を電子マネー口座情報記憶部１２２に格納する。

（チャージ実行部１３４について）
チャージ実行部１３４は、ユーザが利用する電子マネーの決済において残高に不足がある場合に、取得部１３１によって取得されたユーザ情報に基づいて、ユーザからの操作を受けることなくユーザが利用する電子マネーのチャージを実行する。具体的には、チャージ実行部１３４は、算出部１３２によって算出されたユーザの信用度に基づいて、当該ユーザが利用する電子マネー口座へのチャージの実行が可能か否かを判定する。実行部１３４は、チャージの実行が可能と判定した場合、すなわち、当該ユーザが所定の信用度を有している場合、チャージを実行する。例えば、実行部１３４は、ユーザの信用度に応じた額の範囲内で、当該ユーザが利用する電子マネーの不足分以上を立て替えるためのチャージ（仮チャージ）を実行する。

チャージ実行部１３４は、ユーザの信用度に応じてユーザを格付けし、格付けに応じた仮チャージ限度額を定めるようにしてもよい。例えば、チャージ実行部１３４は、信用度が「５」であるユーザを最も高い格付けとし、仮チャージ限度額を「５００００円」と設定する。また、例えば、チャージ実行部１３４は、信用度が「１」であるユーザを最も低い格付けとし、仮チャージ限度額を「０円」、すなわち仮チャージを認めないユーザに設定する。

チャージ実行部１３４は、所定のタイミングで、事業者サーバ１００がチャージしたことで立て替えられた分の金額を店舗に支払うようにしてもよい。なお、チャージ実行部１３４は、立て替えた金額分と通常の電子マネーによる利用分の金額とを同時に店舗に入金するようにしてもよいし、別々のタイミングで入金してもよい。

また、チャージ実行部１３４は、実行されたチャージ額の合計が所定の金額に達した場合、あるいは、所定の期間ごとに予め設定されたタイミングで、チャージした額の返済をユーザに要求する。

この場合、チャージ実行部１３４は、ユーザに返済を要求するのではなく、金融機関サーバ４０と連携し、チャージを実行したユーザに関して口座振替を要求してもよい。すなわち、チャージ実行部１３４は、取得部１３１によって取得されたユーザ情報に基づいて、ユーザの金融機関口座を特定する。そして、チャージ実行部１３４は、仮チャージ額の合計がユーザに設定されている仮チャージ限度額を超えた場合には、金融機関サーバ４０に対して、仮チャージ額を補填するための口座振替を要求する。なお、チャージ実行部１３４は、仮チャージ限度額を超えない場合であっても、所定のタイミング（例えば、毎月１回の定められた日）で仮チャージ額を補填するための口座振替を要求してもよい。

（通知部１３５について）
通知部１３５は、各種情報を通知する。例えば、通知部１３５は、電子マネーの決済が行われた場合に、その旨をユーザに通知する。また、通知部１３５は、チャージ実行部１３４が口座振替を金融機関サーバ４０に要求する場合、その旨を金融機関サーバ４０に通知する。また、通知部１３５は、口座振替が実行された場合、その旨をユーザに通知する。

〔３．処理手順〕
次に、図９を用いて、実施形態に係る事業者サーバ１００による処理の手順について説明する。図９は、実施形態に係る事業者サーバ１００による処理手順を示すフローチャートである。

図９に示すように、事業者サーバ１００に係る取得部１３１は、電子マネーによる決済を受け付けたか否かを判定する（ステップＳ１０１）。取得部１３１は、電子マネーによる決済を受け付けていない場合には（ステップＳ１０１；Ｎｏ）、受け付けるまで待機する。

一方、取得部１３１は、電子マネーによる決済を受け付けた場合には（ステップＳ１０１；Ｙｅｓ）、電子マネーの利用に関する情報を取得し、電子マネーを利用するユーザを特定する（ステップＳ１０２）。

そして、決済部１３３は、電子マネーを利用するユーザの電子マネー口座に関して、決済しようとする金額がチャージ額を超えたか否かを判定する（ステップＳ１０３）。決済部１３３は、決済しようとする金額がチャージ額を超えない場合には（ステップＳ１０３；Ｎｏ）、チャージ額で決済処理を実行する（ステップＳ１０５）。

一方、決済しようとする金額がチャージ額を超える場合には（ステップＳ１０３；Ｙｅｓ）、チャージ実行部１３４は、仮チャージによる決済を実行する（ステップＳ１０４）。すなわち、チャージ実行部１３４は、不足分の額をチャージすることにより、現状のチャージ額を超える決済金額であっても、エラーを発生させることなく決済を完了させる。

そして、チャージ実行部１３４は、チャージの実行により発生する仮チャージ額の合計が仮チャージ限度額を超えたか否かを判定する（ステップＳ１０６）。仮チャージ額の合計が仮チャージ限度額を超える場合には（ステップＳ１０６；Ｙｅｓ）、チャージ実行部１３４は、金融機関サーバ４０に対して口座振替を要求する（ステップＳ１０７）。

仮チャージ額の合計が仮チャージ限度額を超えない場合（ステップＳ１０６；Ｎｏ）、ユーザが予めチャージしていた現状のチャージ額の範囲内で決済が完了した場合（ステップＳ１０５）、金融機関サーバ４０によって口座振替が実行された場合（ステップＳ１０７）、いずれの場合であっても、チャージ実行部１３４は、電子マネーの口座情報を更新する（ステップＳ１０８）。

〔４．変形例〕
上述した実施形態に係る事業者サーバ１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、上記の事業者サーバ１００の他の実施形態について説明する。

〔４−１．電子マネーの利用〕
上記実施形態においては、ユーザＵ０１がユーザ端末１０を介して電子マネーを利用する例を示した。しかし、電子マネーを利用するユーザは、必ずしも端末装置を介して電子マネーを利用しなくてもよい。例えば、ユーザは、電子マネー機能を有するＩＣ（Integrated Circuit）カードを使用してもよい。

この場合、事業者サーバ１００は、ＩＣカードが使用された場合に、ＩＣカードから取得される識別情報に基づいて、ユーザを特定する。そして、事業者サーバ１００は、ユーザ情報記憶部１２１に記憶されている電子マネー口座情報と、ユーザＩＤと、ユーザの信用度とを対応付ける。そして、事業者サーバ１００は、電子マネーの決済において不足分が生じた場合には、対応付けたユーザの信用度に応じて、チャージを実行する。

この場合、事業者サーバ１００は、例えば、電子マネーの口座の登録時に、ＩＣカードから取得される識別情報と、ユーザが日常的に使用する端末装置とを対応付けた情報を記憶しておく。そして、事業者サーバ１００は、ユーザが日常的に使用する端末装置から取得されるユーザの行動履歴に基づいて、信用度を算出し、算出した信用度を保持する。そして、事業者サーバ１００は、電子マネーがＩＣカードを介して使用された時点で、ＩＣカードの識別情報によってユーザを特定するとともに、特定されたユーザに対応する信用度を取得する。そして、事業者サーバ１００は、取得した信用度に基づいてチャージを実行する。

このように、事業者サーバ１００は、端末装置を介さずとも、電子マネーを利用するユーザを特定し、ユーザの信用度を取得することができる。これにより、事業者サーバ１００は、様々な状況に応じて柔軟に電子マネーの不足分の決済を行うことができる。

なお、事業者サーバ１００は、端末装置等を介さずに電子マネーが利用され、さらに、特定されたユーザに関するネットワーク上の行動履歴に基づく信用度が取得されない場合であっても、チャージを行ってもよい。例えば、事業者サーバ１００は、電子マネーが利用された場合に、当該ユーザに係る電子マネーの利用履歴を取得することができる。そして、事業者サーバ１００は、例えば、これまでに仮チャージ額の口座振替の延滞等がないことや、ある一定以上の金額を継続して使用していること等を判定し、チャージを実行するようにしてもよい。

〔４−２．ユーザ情報〕
上記実施形態では、事業者サーバ１００が取得するユーザ情報について説明した。ここで、事業者サーバ１００は、上記実施形態で例示したユーザ情報以外の情報についても取得し、取得した情報に基づいてチャージを実行してもよい。

例えば、事業者サーバ１００は、ユーザ端末１０が送信するメールや、ウェブサイトやＳＮＳサービス等に投稿するメッセージを取得してもよい。そして、事業者サーバ１００は、取得したメール等を形態素解析する。そして、事業者サーバ１００は、ユーザが送信するメール等に登場する単語の出現割合等に基づいて、ユーザの信用度を算出する。

例えば、事業者サーバ１００は、「キャッシング」等、負債関係で用いられる単語を頻繁に発するユーザに対しては、信用度を低く算出することができる。一方、事業者サーバ１００は、「投資」等、資金の調達に用いられる単語を頻繁に発するユーザに対しては、信用度を高く算出することができる。また、事業者サーバ１００は、信用度の算出対象となるユーザのみならず、ＳＮＳでつながる他のユーザ等が発するメッセージ等を解析してもよい。そして、事業者サーバ１００は、信用度の算出対象となるユーザとつながりのある他のユーザのメッセージに「キャッシング」等の単語が頻繁に登場するのであれば、信用度の算出対象となるユーザについても、社会的信用性が低いと推定し、信用度を低く算出するようにしてもよい。

また、事業者サーバ１００は、メール等のテキスト情報のみならず、ユーザやつながりのある他のユーザから発信される画像情報等を取得してもよい。そして、事業者サーバ１００は、画像情報を解析し、画像に示される場所や同時に写っているユーザ等の情報に基づいて、ユーザの信用度を算出する。例えば、事業者サーバ１００は、画像情報に基づいて、画像に示された場所が富裕層の集まる傾向にある場所であると解析する。この場合、事業者サーバ１００は、当該ユーザの社会的信用性が高いと推定し、信用度を高く算出するようにしてもよい。

また、事業者サーバ１００は、検索サイトや、検索サービスアプリ等にユーザから投稿される検索クエリを取得してもよい。そして、事業者サーバ１００は、上記と同様、ユーザから投稿される単語の傾向を解析する。そして、事業者サーバ１００は、検索クエリとして投稿された単語の傾向に基づいて、ユーザの信用度を算出してもよい。

〔４−３．アプリ情報〕
上記実施形態では、事業者サーバ１００は、ユーザ端末１０において使用されるアプリに関する情報を取得する例を示した。ここで、事業者サーバ１００は、上記実施形態で例示したアプリ情報以外の情報についても取得し、取得した情報に基づいてチャージを実行してもよい。

例えば、事業者サーバ１００は、ユーザ端末１０で使用されるアプリを介して、ユーザ端末１０の位置情報を取得する。そして、事業者サーバ１００は、取得した位置情報に基づいて、ユーザの信用度を算出してもよい。例えば、事業者サーバ１００は、位置情報を取得することにより、ユーザ端末１０を利用するユーザの生活圏を推定することができる。そして、事業者サーバ１００は、ユーザの生活圏における地価や、予め事業者サーバ１００の管理者等により設定された土地のランク等に基づいて、ユーザの信用度を算出する。具体的には、事業者サーバ１００は、ランクの高い土地を生活圏とするユーザに関しては、社会的信用性が高いものとして、信用度を高く算出する。

また、事業者サーバ１００は、上記のような位置情報と、タクシー配車アプリ等の使用履歴等を組み合わせて、ユーザの信用度を算出してもよい。例えば、事業者サーバ１００は、ユーザの昼間の生活圏として推定される位置において、頻繁にユーザがタクシー配車アプリを使用しているという情報を取得したものとする。この場合、事業者サーバ１００は、ユーザが定職についており、かつ、頻繁にタクシーを利用するような人物であることから、比較的資金力が高いユーザであると推定し、信用度を高く算出する。

また、事業者サーバ１００は、アプリを介して取得されるユーザの行動に基づいて、ユーザを評価してもよい。例えば、ユーザ端末１０で実行されるアプリの中には、個人間での商売などを実現するアプリが存在する。この場合、事業者サーバ１００は、アプリを介して他のユーザに向けて商品を提供しているユーザ等に関して、社会的信用性が高いと推定し、信用度を高く算出してもよい。すなわち、事業者サーバ１００は、ユーザがネットワーク上で提供するサービスに関する情報を取得し、取得された情報に基づいて、ユーザの信用度を算出してもよい。

このように、事業者サーバ１００は、ユーザ端末１０が利用するアプリを介して、種々の情報を取得する。また、事業者サーバ１００は、取得した情報を様々に組み合わせて、ユーザの信用度を算出することができる。これにより、事業者サーバ１００は、ユーザの信用度を適切に算出することができるため、信頼あるユーザに対しては多くの仮チャージ額を認めるといった、柔軟な対応をすることができる。

〔４−４．実行システムの各装置〕
実行システム１に含まれる各装置は、様々な変形例により実現されてもよい。例えば、店舗端末３０は、１台の端末装置ではなく、複数の端末装置により実現されてもよい。例えば、店舗端末３０は、電子マネー機能を利用するユーザ端末１０やＩＣカードを読み取るリーダーと、読み取った情報を事業者サーバ１００に送信するサーバとによって実現されてもよい。また、店舗端末３０が備えられる店舗は、実世界の店舗に限られず、オンライン上の店舗であってもよい。すなわち、実施形態に係る実行システム１による処理は、実店舗における決済のほか、オンラインショッピング等の決済に利用されてもよい。

〔４−５．ユーザによる選択〕
上記実施形態では、事業者サーバ１００が、ユーザの信用度に基づいてチャージを実行するか否かを判定する例を示した。しかし、事業者サーバ１００は、事業者サーバ１００によるチャージ処理を許可するか否かについて、予めユーザから設定を受け付けておいてもよい。また、事業者サーバ１００は、仮チャージの限度額についても、ユーザの信用度に応じた限度額を設定するのみならず、希望する限度額の設定をユーザから受け付けてもよい。このように、事業者サーバ１００は、ユーザからチャージ限度額の設定等を受け付けることにより、未払いの状態で電子マネーを使い過ぎることを懸念するユーザの不安を取り除くことができる。

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

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

例えば、図２に示したユーザ情報記憶部１２１や、電子マネー口座情報記憶部１２２は、事業者サーバ１００が保持せずに、外部のストレージサーバ等に保持されてもよい。この場合、事業者サーバ１００は、ストレージサーバにアクセスすることで、ユーザ情報や電子マネー口座情報等を取得する。

また、例えば、上述してきた事業者サーバ１００は、電子マネーの利用に関する情報を取得したり、ユーザ端末１０からユーザ情報を受け付けたりといった、外部装置とのやりとりを中心に実行するフロントエンドサーバ側と、信用度の算出処理やチャージ処理を実行するバックエンドサーバ側とに分散されてもよい。

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

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

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

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

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

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

〔７．効果〕
上述してきたように、実施形態に係る事業者サーバ１００は、取得部１３１と、チャージ実行部１３４（実行部の一例）とを有する。取得部１３１は、電子マネーを利用するユーザに関する情報であるユーザ情報を取得する。チャージ実行部１３４は、ユーザが利用する電子マネーの決済においてチャージ残高に不足がある場合に、取得部１３１によって取得されたユーザ情報に基づいて、当該ユーザからの操作を受けることなく当該ユーザが利用する電子マネー口座へのチャージを実行する。

このように、実施形態に係る事業者サーバ１００は、ユーザ情報に基づいてチャージを行うことにより、決済の時点でチャージ額が不足している場合であっても、新たなチャージ処理をユーザに負わせることなく決済処理を完了させる。すなわち、事業者サーバ１００によれば、ユーザに特段の手間を負わせることなく、また、特定の端末装置の利用等に縛られることなく、様々な状況に応じて柔軟に電子マネーの不足分の決済を行うことができる。

また、事業者サーバ１００は、取得部１３１によって取得されたユーザ情報に基づいて、ユーザの信用度を算出する算出部１３２をさらに有する。また、チャージ実行部１３４は、算出部１３２によって算出されたユーザの信用度に基づいて、当該ユーザが利用する電子マネー口座へのチャージの実行が可能か否かを判定する。また、チャージ実行部１３４は、算出部１３２によって算出されたユーザの信用度に応じた額の範囲内で、当該ユーザが利用する電子マネーのチャージを実行する。

このように、実施形態に係る事業者サーバ１００は、ユーザ情報に基づいて信用度を算出する。そして、事業者サーバ１００は、信用度に基づいてチャージを実行するか否かを判定したり、信用度に応じた額のチャージを実行したりする。このため、事業者サーバ１００は、チャージを行う対象となるユーザや、チャージを行う額を適切に判定することができる。

また、取得部１３１は、ユーザ情報として、ユーザのネットワーク上の行動履歴を取得する。算出部１３２は、取得部１３１によって取得されたユーザのネットワーク上の行動履歴に基づいて、当該ユーザの信用度を算出する。

このように、実施形態に係る事業者サーバ１００は、ユーザの日常の行動に基づいて、ユーザの信用度を算出する。このため、事業者サーバ１００は、端末に与信情報を備えさせたり、金融機関との特段の契約をさせたりといった手間をユーザに掛けさせることなく、事業者サーバ１００によるチャージ処理の利便性を享受させることができる。

また、取得部１３１は、ユーザのネットワーク上の購買行動に関する履歴を取得する。算出部１３２は、取得部１３１によって取得された購買行動における購買額、又は、購買行動の頻度に基づいて、ユーザの信用度を算出する。

このように、実施形態に係る事業者サーバ１００は、例えばショッピングサイトを運営するウェブサーバ等から取得可能な、ユーザの購買行動に基づいて信用度を算出する。例えば、事業者サーバ１００は、頻繁に購買行動のログが取得されるユーザに関して資金力が高いと推定し、多額の仮チャージ額を許容するといった判定を行うことができる。このため、事業者サーバ１００によれば、ユーザの金融機関における与信情報等を取得していないユーザに対しても、適切なチャージを実行することができる。

また、取得部１３１は、ユーザが利用するユーザ端末１０で実行されるアプリケーションに関する履歴を取得する。算出部１３２は、取得部１３１によって取得されたアプリケーションに関する履歴に基づいて、ユーザの信用度を算出する。

このように、実施形態に係る事業者サーバ１００は、ユーザのアプリ使用の履歴等に基づいて信用度を算出してもよい。すなわち、事業者サーバ１００は、アプリの使用履歴を解析することにより、特定のアプリの使用頻度が高いユーザを資金力が高いと推定し、多額の仮チャージ額を許容するといった判定を行うことができる。このため、事業者サーバ１００は、様々なユーザに対して、適切なチャージを実行することができる。

取得部１３１は、ユーザが利用する社会的ネットワーク構築のためのサービス内における当該ユーザの知名度、評判、人脈の少なくともいずれか一つに関する情報を取得する。算出部１３２は、取得部１３１によって取得された社会的ネットワーク構築のためのサービス内におけるユーザの知名度、評判、人脈の少なくともいずれか一つに関する情報に基づいて、当該ユーザの信用度を算出する。

このように、実施形態に係る事業者サーバ１００は、ＳＮＳ等のユーザの社会的ネットワーク構築のためのサービスにおける情報に基づいて、ユーザの信用度を算出してもよい。すなわち、事業者サーバ１００は、ＳＮＳ等で多くの人脈を築いているユーザや、周囲からの評価の高いユーザに関して、資金力や社会的信用が高いものとして、多額の仮チャージ額を許容するといった判定を行うことができる。このため、事業者サーバ１００は、様々なユーザに対して、適切なチャージを実行することができる。

また、取得部１３１は、ユーザがネットワーク上で提供するサービスに関する情報を取得する。算出部１３２は、取得部１３１によって取得された、ユーザがネットワーク上で提供するサービスに関する情報に基づいて、ユーザの信用度を算出する。

このように、実施形態に係る事業者サーバ１００は、ユーザ自身が何らかのサービスを提供するユーザであるか否かの情報を取得し、取得した情報に基づいてユーザの信用度を算出してもよい。例えば、事業者サーバ１００は、ユーザ自身がサービスを提供している場合、当該サービスの売上や、資本力を参照することができる場合がある。事業者サーバ１００は、取得した情報に基づいてユーザの信用度を算出することで、金融機関等の与信情報に依らず、仮チャージ額の限度や、チャージが実行可能か否かを判定することができる。このように、事業者サーバ１００は、様々なユーザに応じたチャージを実行することができる。

また、チャージ実行部１３４は、実行されたチャージにおいて発生した金額の合計が所定の金額に達した場合に、チャージした金額の返済をユーザに要求する。

このように、事業者サーバ１００は、チャージにおいて一定の限度額を設け、限度額に達したユーザに対して返済を要求する。例えば、事業者サーバ１００は、ユーザの信用度に応じて限度額を設ける。これにより、事業者サーバ１００は、チャージを実行した場合でも、返済の滞りを発生させず、円滑な運用を行うことができる。また、事業者サーバ１００は、一定額までの仮チャージを認めることにより、例えば、仮チャージの度に返済の要求を発生させたり、仮チャージの度に手数料が発生したりするような手間をユーザに負わせずに済ませることができる。このため、事業者サーバ１００は、円滑な運用とともに、ユーザに利便性を享受させることができる。

また、チャージ実行部１３４は、所定の期間ごとに、実行されたチャージにおいて発生した金額の返済をユーザに要求する。

このように、事業者サーバ１００は、チャージにおいて所定のタイミングで返済の要求を行うようにしてもよい。これにより、ユーザは、事業者サーバ１００がチャージを行った場合でも、ある決まった日に仮チャージ額を支払えばよいため、少額決済が頻繁に発生した場合等であっても、煩わしい手間を掛けずに済む。また、ユーザは、即時引き落としができない金融機関に口座がある場合であっても、毎月の定められた日に引き落とし等の返済を行うといったような、柔軟な対応をとることができる。このように、事業者サーバ１００によれば、様々な状況に応じて柔軟に仮チャージ額の決済（返済の要求）を行うことができる。

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

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

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

１ 実行システム
１０ ユーザ端末
３０ 店舗端末
４０ 金融機関サーバ
１００ 事業者サーバ
１１０ 通信部
１２０ 記憶部
１２１ ユーザ情報記憶部
１２２ 電子マネー口座情報記憶部
１３０ 制御部
１３１ 取得部
１３２ 算出部
１３３ 決済部
１３４ チャージ実行部
１３５ 通知部

Claims (12)

1. 電子マネーを利用するユーザに関する情報であるユーザ情報を取得する取得部と、
   前記ユーザが利用する電子マネーの決済においてチャージ残高に不足がある場合に、前記取得部によって取得されたユーザ情報に基づいて、当該ユーザからの操作を受けることなく当該ユーザが利用する電子マネー口座へのチャージを実行する実行部と、
   を備えたことを特徴とする実行装置。
2. 前記取得部によって取得されたユーザ情報に基づいて、前記ユーザの信用度を算出する算出部、
   をさらに備え、
   前記実行部は、
   前記算出部によって算出されたユーザの信用度に基づいて、当該ユーザが利用する電子マネー口座へのチャージの実行が可能か否かを判定する、
   ことを特徴とする請求項１に記載の実行装置。
3. 前記実行部は、
   前記算出部によって算出されたユーザの信用度に応じた額の範囲内で、当該ユーザが利用する電子マネー口座へのチャージを実行する、
   ことを特徴とする請求項２に記載の実行装置。
4. 前記取得部は、
   前記ユーザ情報として、前記ユーザのネットワーク上の行動履歴を取得し、
   前記算出部は、
   前記取得部によって取得されたユーザのネットワーク上の行動履歴に基づいて、当該ユーザの信用度を算出する、
   ことを特徴とする請求項２又は３に記載の実行装置。
5. 前記取得部は、
   前記ユーザのネットワーク上の購買行動に関する履歴を取得し、
   前記算出部は、
   前記取得部によって取得された購買行動における購買額、又は、購買行動の頻度に基づいて、前記ユーザの信用度を算出する、
   ことを特徴とする請求項２〜４のいずれか一つに記載の実行装置。
6. 前記取得部は、
   前記ユーザが利用する端末装置で実行されるアプリケーションに関する履歴を取得し、
   前記算出部は、
   前記取得部によって取得されたアプリケーションに関する履歴に基づいて、前記ユーザの信用度を算出する、
   ことを特徴とする請求項２〜５のいずれか一つに記載の実行装置。
7. 前記取得部は、
   前記ユーザが利用する社会的ネットワーク構築のためのサービス内における当該ユーザの知名度、評判、人脈の少なくともいずれか一つに関する情報を取得し、
   前記算出部は、
   前記取得部によって取得された社会的ネットワーク構築のためのサービス内における前記ユーザの知名度、評判、人脈の少なくともいずれか一つに関する情報に基づいて、前記ユーザの信用度を算出する、
   ことを特徴とする請求項２〜６のいずれか一つに記載の実行装置。
8. 前記取得部は、
   前記ユーザがネットワーク上で提供するサービスに関する情報を取得し、
   前記算出部は、
   前記取得部によって取得された、前記ユーザがネットワーク上で提供するサービスに関する情報に基づいて、前記ユーザの信用度を算出する、
   ことを特徴とする請求項２〜７のいずれか一つに記載の実行装置。
9. 前記実行部は、
   実行されたチャージにおいて発生した金額の合計が所定の金額に達した場合に、チャージした金額の返済を前記ユーザに要求する、
   ことを特徴とする請求項１〜８のいずれか一つに記載の実行装置。
10. 前記実行部は、
    所定の期間ごとに、実行されたチャージにおいて発生した金額の返済を前記ユーザに要求する、
    ことを特徴とする請求項１〜９のいずれか一つに記載の実行装置。
11. コンピュータが実行する実行方法であって、
    電子マネーを利用するユーザに関する情報であるユーザ情報を取得する取得工程と、
    前記ユーザが利用する電子マネーの決済においてチャージ残高に不足がある場合に、前記取得工程によって取得されたユーザ情報に基づいて、当該ユーザからの操作を受けることなく当該ユーザが利用する電子マネー口座へのチャージを実行する実行工程と、
    を含んだことを特徴とする実行方法。
12. 電子マネーを利用するユーザに関する情報であるユーザ情報を取得する取得手順と、
    前記ユーザが利用する電子マネーの決済においてチャージ残高に不足がある場合に、前記取得手順によって取得されたユーザ情報に基づいて、当該ユーザからの操作を受けることなく当該ユーザが利用する電子マネー口座へのチャージを実行する実行手順と、
    をコンピュータに実行させることを特徴とする実行プログラム。

Images