知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024106915
(43)【公開日】2024-08-08
(54)【発明の名称】方法、サーバ、プログラムおよびシステム
(51)【国際特許分類】
G06Q 20/22 20120101AFI20240801BHJP
G06Q 40/04 20120101ALN20240801BHJP
【ＦＩ】
G06Q20/22
G06Q40/04
【審査請求】未請求
【請求項の数】15
【出願形態】ＯＬ
(21)【出願番号】P 2023011417
(22)【出願日】2023-01-27
(71)【出願人】
【識別番号】516075204
【氏名又は名称】株式会社Ｋｙａｓｈ
(74)【代理人】
【識別番号】100128886
【弁理士】
【氏名又は名称】横田 裕弘
(72)【発明者】
【氏名】鷹取 真一
(72)【発明者】
【氏名】桜井 かほる
(72)【発明者】
【氏名】谷村 壮
(72)【発明者】
【氏名】山田 幾茂
【テーマコード（参考）】
5L020
5L040
5L055
【Ｆターム（参考）】
5L020AA51
5L040BB52
5L055AA51
5L055BB52
(57)【要約】
【課題】証券口座の資産をユーザが利用することが容易となる方法などを提供する。
【解決手段】本発明の方法は、商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能なユーザの証券口座とを関連づけ、ウォレットを介して、証券口座に保有されるユーザの資金で商品・サービスの決済を行う。
【選択図】図１
【解決手段】本発明の方法は、商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能なユーザの証券口座とを関連づけ、ウォレットを介して、証券口座に保有されるユーザの資金で商品・サービスの決済を行う。
【選択図】図１
【特許請求の範囲】
【請求項1】
商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、
前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、
方法。
前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、
方法。
【請求項2】
前記証券口座の前記ユーザの資金によって前記商品・サービスの決済が可能な場合に、前記ウォレットを介して前記商品・サービスの決済を実行する、
請求項１記載の方法。
請求項１記載の方法。
【請求項3】
前記商品・サービスの決済は、前記商品・サービスを決済する要求を受け付けた後であって、前記証券口座から前記資金を払い出す前に実行される、請求項２記載の方法。
【請求項4】
前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、
前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額と、
を前記ユーザが操作する端末に表示する、請求項１記載の方法。
前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額と、
を前記ユーザが操作する端末に表示する、請求項１記載の方法。
【請求項5】
前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額との合計を前記ユーザが操作する端末に表示する、請求項１記載の方法。
【請求項6】
前記商品・サービスの決済は、前記証券口座に保有される前記有価証券の売却後であって、前記有価証券の売却金額が前記証券口座の預かり残高に反映される前であっても、前記売却金額を用いて実行される、請求項１記載の方法。
【請求項7】
前記商品・サービスの決済は、前記商品・サービスを決済する要求を受け付け前記証券口座に保有される有価証券を売却して前記資金を払い出す、請求項１記載の方法。
【請求項8】
前記第１決済可能額が前記商品・サービスの決済に不足する場合であって、かつ前記第２決済可能額が前記不足する額以上である場合に、前記ウォレットを介して前記商品・サービスの決済を実行する、請求項４または５記載の方法。
【請求項9】
前記第１決済可能額および前記第２決済可能額を前記端末に並べて表示し、
前記前記第２決済可能額から第１決済可能額に資金を移動させる指示を受け付けると、前記証券口座に保有される前記有価証券を売却し、前記有価証券の売却金額に相当する額を前記第１決済可能額に加える、請求項４または５記載の方法。
前記前記第２決済可能額から第１決済可能額に資金を移動させる指示を受け付けると、前記証券口座に保有される前記有価証券を売却し、前記有価証券の売却金額に相当する額を前記第１決済可能額に加える、請求項４または５記載の方法。
【請求項10】
前記ウォレットに関連付けられた前記ユーザの銀行口座に入金があると前記銀行口座から前記証券口座へ資金を移動させる、請求項１記載の方法。
【請求項11】
前記ウォレットおよび前記証券口座を関連づけることにともない、前記ウォレットから前記証券口座に資金を移動させる、請求項１記載の方法。
【請求項12】
商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、
前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額との合計を前記ユーザが操作する端末に表示し、
前記証券口座の前記ユーザの資金によって前記商品・サービスの決済が可能な場合に、前記商品・サービスを決済する要求を受け付けた後であって前記証券口座から前記資金を払い出す前に、前記決済を実行する、
方法。
前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額との合計を前記ユーザが操作する端末に表示し、
前記証券口座の前記ユーザの資金によって前記商品・サービスの決済が可能な場合に、前記商品・サービスを決済する要求を受け付けた後であって前記証券口座から前記資金を払い出す前に、前記決済を実行する、
方法。
【請求項13】
商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、
前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、
サーバ。
前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、
サーバ。
【請求項14】
コンピュータに、
商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけるステップと、
前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行うステップと、
を実行させる、プログラム。
商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけるステップと、
前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行うステップと、
を実行させる、プログラム。
【請求項15】
ユーザが操作する端末と、
前記端末とネットワークを介して通信可能なサーバと、
を有するシステムであって、
前記サーバが、
商品・サービスの決済が可能な前記ユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、
前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、
システム。
前記端末とネットワークを介して通信可能なサーバと、
を有するシステムであって、
前記サーバが、
商品・サービスの決済が可能な前記ユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、
前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、
システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、方法、サーバ、プログラムおよびシステムに関する。
【背景技術】
【0002】
特許文献１には、以下のようなコンピュータが記載されている。このコンピュータは、取引口座の残高が、取引額特に買い注文の額に満たない場合には、証券会社側コンピュータは、その不足分について、顧客によって予め指定された銀行の預金口座の資金を用いて取引口座の残高が不足する場合であっても、有価証券の取引が可能となる。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２００２－０６３５２２号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、ユーザが証券口座に株式や投資信託などの資産を保有していても、ユーザが例えば店舗で商品を購入する際などに証券口座の資産を利用することは困難であった。
【0005】
そこで、本発明は、証券口座の資産をユーザが利用することが容易となる方法などを提供することを目的とする。
【課題を解決するための手段】
【0006】
かかる目的のもと、本明細書に開示される技術は、商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、方法である。
また、前記証券口座の前記ユーザの資金によって前記商品・サービスの決済が可能な場合に、前記ウォレットを介して前記商品・サービスの決済を実行するとよい。
また、前記商品・サービスの決済は、前記商品・サービスを決済する要求を受け付けた後であって、前記証券口座から前記資金を払い出す前に実行されるとよい。
また、前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額と、を前記ユーザが操作する端末に表示するとよい。
また、前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額との合計を前記ユーザが操作する端末に表示するとよい。
また、前記商品・サービスの決済は、前記証券口座に保有される前記有価証券の売却後であって、前記有価証券の売却金額が前記証券口座の預かり残高に反映される前であっても、前記売却金額を用いて実行されるとよい。
また、前記商品・サービスの決済は、前記商品・サービスを決済する要求を受け付け前記証券口座に保有される有価証券を売却して前記資金を払い出すとよい。
また、前記第１決済可能額が前記商品・サービスの決済に不足する場合であって、かつ前記第２決済可能額が前記不足する額以上である場合に、前記ウォレットを介して前記商品・サービスの決済を実行するとよい。
また、前記第１決済可能額および前記第２決済可能額を前記端末に並べて表示し、前記前記第２決済可能額から第１決済可能額に資金を移動させる指示を受け付けると、前記証券口座に保有される前記有価証券を売却し、前記有価証券の売却金額に相当する額を前記第１決済可能額に加えるとよい。
また、前記ウォレットに関連付けられた前記ユーザの銀行口座に入金があると前記銀行口座から前記証券口座へ資金を移動させるとよい。
また、前記ウォレットおよび前記証券口座を関連づけることにともない、前記ウォレットから前記証券口座に資金を移動させるとよい。
また、前記証券口座の前記ユーザの資金によって前記商品・サービスの決済が可能な場合に、前記ウォレットを介して前記商品・サービスの決済を実行するとよい。
また、前記商品・サービスの決済は、前記商品・サービスを決済する要求を受け付けた後であって、前記証券口座から前記資金を払い出す前に実行されるとよい。
また、前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額と、を前記ユーザが操作する端末に表示するとよい。
また、前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額との合計を前記ユーザが操作する端末に表示するとよい。
また、前記商品・サービスの決済は、前記証券口座に保有される前記有価証券の売却後であって、前記有価証券の売却金額が前記証券口座の預かり残高に反映される前であっても、前記売却金額を用いて実行されるとよい。
また、前記商品・サービスの決済は、前記商品・サービスを決済する要求を受け付け前記証券口座に保有される有価証券を売却して前記資金を払い出すとよい。
また、前記第１決済可能額が前記商品・サービスの決済に不足する場合であって、かつ前記第２決済可能額が前記不足する額以上である場合に、前記ウォレットを介して前記商品・サービスの決済を実行するとよい。
また、前記第１決済可能額および前記第２決済可能額を前記端末に並べて表示し、前記前記第２決済可能額から第１決済可能額に資金を移動させる指示を受け付けると、前記証券口座に保有される前記有価証券を売却し、前記有価証券の売却金額に相当する額を前記第１決済可能額に加えるとよい。
また、前記ウォレットに関連付けられた前記ユーザの銀行口座に入金があると前記銀行口座から前記証券口座へ資金を移動させるとよい。
また、前記ウォレットおよび前記証券口座を関連づけることにともない、前記ウォレットから前記証券口座に資金を移動させるとよい。
【0007】
さらに他の観点から捉えると、本明細書に開示される技術は、商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、前記ウォレットに関連付けられ、決済可能な額を示す第１決済可能額と、前記証券口座に関連づけられ、前記ウォレットを介して決済可能な額を示す第２決済可能額との合計を前記ユーザが操作する端末に表示し、前記証券口座の前記ユーザの資金によって前記商品・サービスの決済が可能な場合に、前記商品・サービスを決済する要求を受け付けた後であって前記証券口座から前記資金を払い出す前に、前記決済を実行する、方法である。
【0008】
さらに他の観点から捉えると、本明細書に開示される技術は、商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、サーバである。
【0009】
さらに他の観点から捉えると、本明細書に開示される技術は、コンピュータに、商品・サービスの決済が可能なユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけるステップと、前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行うステップと、を実行させる、プログラムである。
【0010】
さらに他の観点から捉えると、本明細書に開示される技術は、ユーザが操作する端末と、前記端末とネットワークを介して通信可能なサーバと、を有するシステムであって、前記サーバが、商品・サービスの決済が可能な前記ユーザのウォレットと、有価証券の決済が可能な前記ユーザの証券口座とを関連づけ、前記ウォレットを介して、前記証券口座に保有される前記ユーザの資金で前記商品・サービスの決済を行う、システムである。
【発明の効果】
【0011】
本発明によれば、証券口座の資産をユーザが利用することが容易となる方法などが提供される。
【図面の簡単な説明】
【0012】
【図1】本実施の形態が適用される決済システムの全体構成例を示した図である。
【図2】決済サーバの構成例を説明するための図である。
【図3】ウォレットＤＢに記憶されるテーブルを説明するための図である。
【図4】決済サーバのハードウェア構成例を示した図である。
【図5】ユーザ端末のハードウェア構成例を示した図である。
【図6】決済システムの決済処理を示すフローチャートである。
【図7】決済システムの有価証券の購入処理を示すフローチャートである。
【図8】決済システムの出金処理を示すフローチャートである。
【図9】決済システムの第１入金処理を示すフローチャートである。
【図10】決済システムの第２入金処理を示すフローチャートである。
【図11-1】決済操作画像を示す図である。
【図11-2】決済操作画像を示す図である。
【図12】決済操作画像を示す図である。
【図13】有価証券の売買について説明をする図である。
【発明を実施するための形態】
【0013】
以下、添付図面を参照して、本発明の他の実施の形態について説明する。
＜決済システム１＞
図１は、本実施の形態が適用される決済システム１の全体構成例を示した図である。
図１に示すように、決済システム１は、決済サーバ１００と、店舗端末３００と、ユーザ端末５００と、証券サーバ９００とを有する。
＜決済システム１＞
図１は、本実施の形態が適用される決済システム１の全体構成例を示した図である。
図１に示すように、決済システム１は、決済サーバ１００と、店舗端末３００と、ユーザ端末５００と、証券サーバ９００とを有する。
【0014】
決済サーバ１００は、決済サービス会社ＫＳが管理するコンピュータ装置によって構成される。この決済サーバ１００は、決済システム１におけるサーバとして機能する。本実施の形態の決済サーバ１００は、ユーザ端末５００を操作するユーザＵＲが決済を行うために必要な各種制御を実行する。図示の例における決済サーバ１００は、ユーザＵＲが店舗などにおいて商品の購入やサービスの利用をすることにともなう決済を支援する。
【0015】
店舗端末３００は、商品の販売やサービスの提供を行う店舗ＳＨに設けられる。店舗端末３００は、例えばレジスター、スマートフォン、ノート型コンピュータ、デスクトップ型コンピュータ、タブレット型コンピュータなどのコンピュータ装置である。この店舗端末３００は、ユーザＵＲが操作するユーザ端末５００からクレジットカード情報を読み取ることで、ユーザＵＲからの支払いを受ける。
【0016】
ユーザ端末５００は、商品・サービスの購入・利用をするユーザＵＲによって操作される。ユーザ端末５００は、例えばスマートフォン、ノート型コンピュータ、デスクトップ型コンピュータ、タブレット型コンピュータ、ウェアラブルデバイス、あるいは携帯電話などのコンピュータ装置によって構成される。図示の例のユーザ端末５００は、スマートフォンである。
【0017】
ユーザ端末５００は、決済システム１において決済処理を支援するアプリケーションプログラムがインストールされている。このアプリケーションプログラムは、決済サーバ１００と通信してユーザＵＲの決済可能額情報などを取得し、ユーザＵＲの決済を支援する機能を有する。図示の例におけるアプリケーションプログラムは、決済サーバ１００を介して証券口座の開設や、証券口座において有価証券の売買をすることが可能である。付言すると、アプリケーションプログラムは、有価証券の売買において、ユーザＵＲが決済を行う際のインターフェイスとして機能する。なお、以下の説明においては、このアプリケーションプログラムを、「決済アプリ」とする場合がある。
【0018】
証券サーバ９００は、証券会社ＳＣが管理するコンピュータ装置によって構成される。この証券サーバ９００は、決済システム１におけるクライアントとして機能する。証券会社ＳＣは、金融商品取引業者の一例である。この金融商品取引業者は、例えば投資信託会社などであってもよい。ここで、証券会社ＳＣは、有価証券の売買の取次ぎや引受けなどを行う。有価証券は、証券市場での売買の対象として金融商品取引法に列挙されている証券である。有価証券は、例えば株券、投資信託の受益証券、国債、地方債、社債などである。ここで、投資信託（投信）は、ＭＲＦ（Ｍｏｎｅｙ Ｒｅｓｅｒｖｅ Ｆｕｎｄ）およびＭＭＦ（Ｍｏｎｅｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｄ）を含む。
【0019】
決済サーバ１００、店舗端末３００、ユーザ端末５００、および証券サーバ９００は、ネットワーク（不図示）を介して互いに接続されている。ネットワークは、装置間のデータ交換に用いられる通信ネットワークである。図示のネットワークは、インターネットにより構成されるが、特に限定されない。ネットワークは、例えばＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）であってもよい。また、ネットワークの通信回線は、有線か無線かを問わず、これらを併用してもよい。また、図１においては、決済サーバ１００、店舗端末３００、ユーザ端末５００、および証券サーバ９００は、それぞれ１つずつ示しているが、これらは複数設けられてもよい。
【0020】
また、図示の例における証券会社ＳＣは、決済サービス会社ＫＳとは別の企業である。付言すると、決済サーバ１００および証券サーバ９００は、それぞれ別の管理者によって管理されている。
【0021】
本実施形態の決済サーバ１００は、決済を行う。また、決済サーバ１００は、決済に用いられるクレジットカードの発行と管理・運用を行う。例えば、決済サーバ１００は、クレジットカードの識別番号であるクレジット番号を発番しユーザＵＲごとに割り当てる。
【0022】
また、決済サーバ１００は、例えば、ユーザＵＲのユーザ端末５００にインストールされた決済アプリでクレジットカードを用いた決済機能を提供する。図示の例におけるクレジットカードは、ユーザＵＲが操作しユーザ端末５００にインストールした決済アプリを介してクレジット番号を表示する所謂、バーチャルカードである。なお、ここでのクレジットカードとは、ユーザＵＲの信用によって後払いを可能とする情報を提供する媒体である。例えば、クレジットカードは、プラスチックに所定のカード情報を印字した、磁気カードまたはＩＣチップを備えたＩＣカードで構成されるリアルカード（物理カード）であってもよい。また、ここではクレジットカードとして説明をするが、クレジットカードの機能が提供されるものであれば、カードの形状であることやカードの画像をユーザ端末５００に表示することは必要でない。例えば、近距離無線通信(ＮＦＣ)の機能を備えた端末（例えば、スマートフォン、指輪型端末、腕時計型端末）を介して提供されるクレジットカードの機能を模した（エミュレート）決済サービスでもよい。
【0023】
ここで、ユーザＵＲの支払い原資は、ユーザＵＲの決済口座の資金が用いられる。この決済口座は、決済サーバ１００上に仮想的に生成された財布であるウォレットとして捉えることができる。そして、このウォレットに保有された資金を用いて、決済サーバ１００は決済を行う。
【0024】
さらに説明をすると、本実施の形態における決済サーバ１００は、対象とするユーザＵＲのウォレットと、クレジットカードのクレジット番号とを関連づける。そして、決済サーバ１００は、店舗などにおいてユーザＵＲが所望の取引対象（商品やサービス）を購入・利用した際に、決済（電子決済）を行う。ここで、決済サーバ１００は、決済時に、クレジット番号に関連付けられたウォレットの決済残高であるウォレット決済残高を、対象の商品・サービスの決済金額の支払いに充てる。すなわち、対象の商品・サービスの決済金額の分だけ、ウォレット決済残高のウォレット決済残高を差し引く。付言すると、決済サーバ１００が発行するクレジットカードは、予めウォレットに入金されているウォレット決済残高を用いてクレジットカードの決済を行うことから、プリペイド型クレジットカードとして捉えることができる。
【0025】
次に、図１を参照しながら、決済システム１における証券口座の資金を利用した決済処理の概略を説明する。
まず、店舗端末３００が、ユーザＵＲのクレジット番号をリアルカード（物理カード）から読み取るなどしてクレジット番号を所得する（Ｓ１）。店舗端末３００は、ユーザＵＲからネットワークを介してクレジット番号を所得してもよい。そして、店舗端末３００は、決済サーバ１００に対して決済要求を出力する（Ｓ２）。決済要求を受けた決済サーバ１００は、決済処理を行った後、店舗端末３００に対して決済完了通知を出力する（Ｓ３）。このことにより、ユーザＵＲと店舗ＳＨとの間における決済が完了する。また、決済サーバ１００は、ユーザ端末５００に対して支払完了通知を出力する（Ｓ４）。このことにより、ユーザＵＲは、決済が完了したことを把握することが可能となる。
まず、店舗端末３００が、ユーザＵＲのクレジット番号をリアルカード（物理カード）から読み取るなどしてクレジット番号を所得する（Ｓ１）。店舗端末３００は、ユーザＵＲからネットワークを介してクレジット番号を所得してもよい。そして、店舗端末３００は、決済サーバ１００に対して決済要求を出力する（Ｓ２）。決済要求を受けた決済サーバ１００は、決済処理を行った後、店舗端末３００に対して決済完了通知を出力する（Ｓ３）。このことにより、ユーザＵＲと店舗ＳＨとの間における決済が完了する。また、決済サーバ１００は、ユーザ端末５００に対して支払完了通知を出力する（Ｓ４）。このことにより、ユーザＵＲは、決済が完了したことを把握することが可能となる。
【0026】
ここで、店舗端末３００から決済サーバ１００に対して出力される決済要求（Ｓ２）は、ユーザＵＲのクレジット番号と決済で要求される金額である決済要求額とを含む。そして、店舗端末３００から決済要求を受けた決済サーバ１００は、クレジット番号に関連付けられたユーザＵＲおよびユーザＵＲのウォレットを特定し、特定したウォレットのウォレット決済残高を取得する。そして、決済要求額とウォレット決済残高を比較し、ウォレット決済残高が決済要求額以上、すなわちウォレット決済残高で支払い可能な場合、決済サーバ１００は決済処理を行う（Ｓ１１）。
【0027】
一方、ウォレット決済残高が決済要求額未満、すなわちウォレット決済残高で支払い不可能である場合、決済サーバ１００は、ユーザＵＲに関連づけられた証券口座情報を取得する。決済サーバ１００は、ユーザＵＲの証券口座の資金を用いてウォレット決済残高の不足分を決済できるか判断する。決済サーバ１００は、ユーザＵＲの証券口座の資金を用いてウォレット決済残高の不足分を決済が可能な場合は、決済処理を行う（Ｓ１１）。決済サーバ１００は、ユーザＵＲの証券口座の資金を用いてウォレット決済残高の不足分を決済が不可能な場合は、決済処理を行わない。
【0028】
決済サーバ１００は、ユーザＵＲの証券口座の資金を用いて決済を行う場合、続いて、ユーザＵＲの証券口座の資金の払い出しを実行する。具体的に説明をすると、まず決済サーバ１００は、証券サーバ９００に対して払出要求を出力する（Ｓ２１）。この払出要求は、ユーザＵＲのウォレットの識別情報（銀行口座情報、後述）と、決済における不足額とを含む。そして、払出要求を受けた証券サーバ９００は、ユーザＵＲの証券口座の資金から銀行口座に不足額に相当する額の払出処理を実行し、決済サーバ１００に対して払出完了通知を出力する（Ｓ２２）。このように、ユーザＵＲのウォレット決済残高が不足している場合において、ユーザＵＲの証券口座の資金によって不足分を補充する（補う）ことで、ユーザＵＲによる決済の利便性が向上する。つまり、証券口座の資金をユーザＵＲが操作し、決済サーバ１００内の自身のウォレットに払い出すことなく、ウォレットを介して証券口座の資金を用いた決済を行うことが可能となる。なお、ここでの払い出しとは、証券口座や銀行口座などユーザＵＲの口座から資金を移動させることをいう。
【0029】
さて、一般的に、証券口座の資金は、銀行口座の普通預金に保有された資金と比較して、出金（払い出し）しにくい。例えば、証券口座の資金は、銀行口座の普通預金と比較して、出金処理に要する時間が長い。また、例えば、証券口座の資金は直接引き出すことができず、銀行口座に一旦払い出した後にＡＴＭ（現金自動預入支払機）を用いて引き出す必要がある。さらに説明をすると、有価証券を売却する場合、売却要求を受け付けてから売却額に相当する資金を出金できるようになるまで、所定期間（例えば、２営業日）が必要となる。具体的には、有価証券を売却した売却額は、有価証券の購入に使用できる買付余力にはすぐに反映される一方、証券口座から銀行口座などに資金を払い出すことが可能な預かり金としては、所定期間後に反映される。
【0030】
また、証券口座を管理する証券サーバ９００においては、システムメンテナンスなどを目的として、リクエスト受付停止時間帯（例えば、毎週日曜日の１９時～２０時）が存在することがある。リクエスト受付停止時間帯は、ダウンタイムとも呼ばれ、一時的に入出金不可とするバッチ処理を行う期間である。そして、このリクエスト受付停止時間帯においては、証券サーバ９００は入出金処理を受け付けることができない。したがって、リクエスト受付停止時間帯は、ユーザＵＲが証券口座の資金を利用して決済を望む場合であっても、入出金、すなわち決済ができない状態となる。ここで、例えばリクエスト受付停止時間帯の終了を待って証券口座から資金の払い出しを行い、その後決済を実行する態様も考えられる。しかしながら、ダウンタイム中は決済完了までの時間が長くなり、決済の利便性が著しく損なわれる。
【0031】
本実施の形態においては、決済サーバ１００が、証券口座から決済口座への資金の払い出しを完了するより前に決済を行う。このように決済口座への資金振替（払い出し）より前に決済を行うことで、一時的に、ユーザＵＲの決済口座がマイナス（決済サービス会社ＫＳからの貸し付け状態）となる。そして、決済サーバ１００は、決済が完了した後に、決済口座の貸付状態を解消、すなわち清算する処理を実行する。このことにより、証券サーバ９００の状態に関わらず、速やかに決済を実行することが可能となる。また、証券口座からの資金の払い出しを決済の後にすることから、株売却後に売却額に相当する金額をすぐに決済に利用することが可能となる。つまり、払い出しができない買付余力の状態の資金でも決済に利用できる。このことにより、証券口座のように資金が出金しにくい資金を利用しながら、利便性が高い決済を提供することができる。
【0032】
＜決済サーバ１００＞
図２は、決済サーバ１００の構成例を説明するための図である。
図３は、ウォレットＤＢに記憶されるテーブルを説明するための図である。
次に、図２および図３を参照しながら決済サーバ１００の構成例について説明をする。
図２は、決済サーバ１００の構成例を説明するための図である。
図３は、ウォレットＤＢに記憶されるテーブルを説明するための図である。
次に、図２および図３を参照しながら決済サーバ１００の構成例について説明をする。
【0033】
図２に示すように、決済サーバ１００は、ユーザＵＲの決済口座における入出金を行う入出金処理部１１０と、決済を行う決済処理部１３０と、証券口座の管理を行う証券管理部１５０と、ユーザ端末５００など他の装置との通信を行う通信部１７０と、ユーザＵＲの決済に関する情報を記憶するウォレットＤＢ２１０とを有する。
【0034】
ここで、ウォレットＤＢ２１０は、図３に示すように、ユーザＴＢ（テーブル）と、決済口座（ウォレット）ＴＢと、証券口座ＴＢとを記憶する。
図３（Ａ）に示すユーザＴＢは、ユーザＵＲに関する情報であるユーザ情報を格納する。このユーザＴＢは、決済処理部１３０によって所定の時期に更新される。図示の例におけるユーザＴＢは、ユーザＵＲの識別番号であるユーザＩＤ、クレジット番号、銀行口座情報（支店コード、口座番号）、証券口座情報（支店コード、口座番号）、および本人確認情報を記憶する。なお、ユーザ情報は、ユーザＵＲの氏名や生年月日などの登録情報、利用限度額などの与信情報、を含むことができる。
図３（Ａ）に示すユーザＴＢは、ユーザＵＲに関する情報であるユーザ情報を格納する。このユーザＴＢは、決済処理部１３０によって所定の時期に更新される。図示の例におけるユーザＴＢは、ユーザＵＲの識別番号であるユーザＩＤ、クレジット番号、銀行口座情報（支店コード、口座番号）、証券口座情報（支店コード、口座番号）、および本人確認情報を記憶する。なお、ユーザ情報は、ユーザＵＲの氏名や生年月日などの登録情報、利用限度額などの与信情報、を含むことができる。
【0035】
ここで、クレジット番号は、ユーザＵＲに割り当てられたクレジットカードの識別番号である。このクレジット番号は、ユーザ登録することで、決済サービス会社ＫＳによってユーザＵＲごとに割り当てられる。ユーザＵＲはクレジット番号の入力やクレジット番号情報を有するリアルカード（物理カード）を用いることで、後述するウォレット決済残高を用いて商品・サービスを決済することができる。
【0036】
銀行口座は、ユーザＵＲに割り当てられた銀行口座である。この銀行口座は、ユーザ登録することで、決済サービス会社ＫＳによってユーザＵＲごとに割り当てられる。さらに説明すると、銀行口座の実際の所有者（名義）は決済サービス会社ＫＳである。そして、決済サービス会社ＫＳの名義でありながら、ユーザＵＲごとに別の口座番号が割り当てられている。この銀行口座に入金があった場合に、当該銀行口座に関連づけられたユーザＵＲが抽出され、抽出されたユーザＵＲの後述する決済口座（ウォレット）ＴＢのマネーあるいはバリューの残高に入金された額が反映される。
【0037】
証券口座は、ユーザＵＲに関連付けられた証券口座である。この証券口座は、ユーザＵＲ自身が所有する証券口座を登録すること、あるいは決済サーバ１００を介して証券口座の開設することにより、ユーザＵＲに関連付けられる。
【0038】
本人確認情報は、ユーザＵＲの本人確認が完了しているか否かの情報である。ここでの本人確認は、決済サービス会社ＫＳがユーザＵＲが本人であることを確認する処理である。この本人確認は、例えばユーザＵＲが、運転免許証やマインバーカードなどの本人確認資料の画像を決済サーバ１００に送信し、決済サービス会社ＫＳがその画像を確認することで実行される。
【0039】
図３（Ｂ）に示す決済口座（ウォレット）ＴＢは、ユーザＵＲの決済口座に関する情報である決済口座情報を格納する。この決済口座（ウォレット）ＴＢは、決済処理部１３０によって所定の時期に更新される。図示の例における決済口座（ウォレット）ＴＢに格納される決済口座情報は、ユーザＩＤ、マネー、バリュー、ウォレット決済残高、ポイントの情報を含む。
【0040】
マネーは、決済に利用可能な資金である。マネーは、決済口座で保有されるチャージ残高である。マネーは、ＡＴＭなどを介して出金することが可能である。また、マネーは、株などの有価証券を購入することが可能である。また、マネーは、資金移動業に該当する資金である。なお、図３（Ａ）のユーザＴＢにおいて「本人確認」が「済」の場合、すなわち本人確認が完了している場合、ユーザＵＲの銀行口座に入金された額は、マネーに加算される。
【0041】
バリューは、決済に利用可能な資金である。バリューは、他の金融機関に送金することが可能である。また、バリューは、ＡＴＭなどを介して出金することはできない。さらに、バリューは、株などの有価証券を購入することができない。また、バリューは、前払い式支払い手段に該当する資金である。なお、図３（Ａ）のユーザＴＢにおいて「本人確認」が「未」の場合、すなわち本人確認が完了していない場合、ユーザＵＲの銀行口座に入金された額は、バリューに加算される。また、「本人確認」が「済」の場合、すなわち本人確認が完了している場合であっても、他のユーザからバリューが送金されてきた場合は、ユーザＵＲのバリューに加算される。
【0042】
ウォレット決済残高は、決済口座（ウォレット）において決済可能な資金の残高である。ウォレット決済残高は、マネーおよびバリューの合算値である。さらに説明をすると、図３（Ｂ）に示すように、マネー（Ａ）およびバリュー（Ｂ）の合計が、決済口座（ウォレット）におけるウォレット決済残高（Ｃ＝Ａ＋Ｂ）となる。
【0043】
ポイントは、例えば決済額の１％など、決済額に応じてユーザＵＲに付与される利用特典である。ポイントは、バリューに交換して利用することができる。すなわち、ポイントは、バリューを介して決済に利用可能である。なお、このポイントは、ＡＴＭなどを介して出金することや有価証券を購入することができない。
【0044】
図３（Ｃ）に示す証券口座ＴＢは、ユーザＵＲの証券口座に関する情報である証券口座情報を格納する。この証券口座ＴＢは、証券管理部１５０によって所定の時期に更新される。図示の例における証券口座ＴＢに格納される証券口座情報は、ユーザＩＤ、総資産、買付余力、預り金、株式（銘柄、評価額）、投信（銘柄、評価額）を含む。
【0045】
総資産は、ユーザＵＲが証券口座で所有する資産の総額である。なお、図示の例における総資産（Ａ）は、買付余力（Ｂ）、株式の評価額（Ｅ）、および投信の評価額（Ｆ）の総額である（Ａ＝Ｂ＋Ｅ＋Ｆ）。
【0046】
預かり金は、ユーザＵＲが証券口座で所有する資金であって、決済口座を介さずに直接証券口座からＡＴＭ（現金自動預入支払機）などを介して出金することが可能な額である。さらに説明をすると、預かり金は、証券口座から決済口座を介さずに直接証券口座から出金可能な残高である。本実施例においては、証券口座に保有する有価証券を売却する場合、売却額に相当する額は、所定期間の経過後に預かり金に反映される。これは、売却した有価証券の受渡は所定期間の経過後に行われ、受渡後に預かり金に反映されるためである。なお、本実施例においては証券口座の預かり金は、自動的に全てＭＲＦを買い付けるものとして説明するが、これに限られない。預かり金の一部のみＭＲＦの買い付けを行ってもよいし、預かり金を用いてＭＲＦを買い付けない構成としてもよい。なお、ＭＲＦを買付けた場合であっても、ＭＲＦの評価額は預かり金に反映されるものとして説明する。
【0047】
買付余力は、ユーザＵＲが証券口座において有価証券の買付注文をすることができる額である。買付余力は、預かり金の額と有価証券の売却額との合計である。有価証券の売却額は前述の通り有価証券の受渡後に入金されるが、買付余力にはすでに確定した有価証券の売却額を受渡前であっても反映する。買付余力は、有価証券の売却後、所定期間は預かり金よりも大きな額となる。
【0048】
証券決済残高は、証券口座において決済口座を介して決済に利用できる資金の額である。言い替えると、証券口座の資金を利用して決済することができる上限額である。ここで、証券決済残高は、ユーザＵＲからの指定を受け付け設定されてもよい。図示の例におけるユーザＵＲ１の証券決済残高は、買付余力に連動する。すなわち、証券決済残高は買付余力と等しい（Ｄ＝Ｂ）。例えば、ユーザＵＲから上限金額の指定を受けて、上限金額以下で買付余力に連動するよう証券決済残高が設定されてもよい。図示の例におけるユーザＵＲ２の証券決済残高は、ユーザによって設定された上限金額（１００，０００円）以下で買付余力に連動する。また、証券決済残高は、決済サービス会社ＫＳによって予め設定されてもよい。図示の例におけるユーザＵＲ３の証券決済残高は、サービス会社ＫＳによって設定された上限金額（５，０００円）以下で買付余力に連動する。なお、証券決済残高は、ユーザＵＲから売却することを許容する株式や証券の銘柄の指示を受けて、指定された銘柄の評価額と買付余力の合算に相当する額に設定されてもよい。
【0049】
図３（Ｃ）における株式は、ユーザＵＲが証券口座で所有する株式である。ここでの株式の情報は、ユーザＵＲが証券口座に保有する株式の銘柄およびその評価額を含む。
図３（Ｃ）における投信は、ユーザＵＲが証券口座で所有する投資信託である。ここでの投信の情報は、ユーザＵＲが証券口座に保有する投信の銘柄およびその評価額を含む。
図３（Ｃ）における投信は、ユーザＵＲが証券口座で所有する投資信託である。ここでの投信の情報は、ユーザＵＲが証券口座に保有する投信の銘柄およびその評価額を含む。
【0050】
図示の例においては、証券管理部１５０が所定のタイミング毎に証券口座に保有される資産を確認し、証券口座の資産に変動があると、証券管理部１５０が証券口座ＴＢを更新する。すなわち、証券口座ＴＢは、証券口座と同期している。なお、証券口座において残高に変動があることにともない証券サーバ９００から通知を受けることで、証券口座ＴＢが更新される態様でもよい。付言すると、証券口座の資金は決済口座側でなく、証券口座側にあり資金変動はデータ上で処理される。そして、実際の資金の移動は、所定のタイミング（例えば１日に１度）において所謂バッチ処理をすることで実行される。
【0051】
＜決済サーバ１００のハードウェア構成＞
図４は、決済サーバ１００のハードウェア構成例を示した図である。
図４に示すように、決済サーバ１００は、ＣＰＵ１０１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３と、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０４と、通信Ｉ／Ｆ１０５とを備える。
図４は、決済サーバ１００のハードウェア構成例を示した図である。
図４に示すように、決済サーバ１００は、ＣＰＵ１０１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３と、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０４と、通信Ｉ／Ｆ１０５とを備える。
【0052】
ＣＰＵ１０１は、ＲＯＭ１０３などに記憶された各種プログラムをＲＡＭ１０２にロードして実行することにより、決済サーバ１００の上記各機能を実現する。
ＲＡＭ１０２は、ＣＰＵ１０１の作業用メモリなどとして用いられるメモリである。
ＲＯＭ１０３は、ＣＰＵ１０１が実行する各種プログラムなどを記憶するメモリである。
ＨＤＤ１０４は、ユーザ情報などを記憶する例えば磁気ディスク装置である。
通信Ｉ／Ｆ１０５は、ネットワークを介して他の装置との間で各種情報の送受信を行う。
ＲＡＭ１０２は、ＣＰＵ１０１の作業用メモリなどとして用いられるメモリである。
ＲＯＭ１０３は、ＣＰＵ１０１が実行する各種プログラムなどを記憶するメモリである。
ＨＤＤ１０４は、ユーザ情報などを記憶する例えば磁気ディスク装置である。
通信Ｉ／Ｆ１０５は、ネットワークを介して他の装置との間で各種情報の送受信を行う。
【0053】
ここで、ＣＰＵ１０１によって実行されるプログラムは、半導体メモリなどのコンピュータが読取可能な記録媒体に記憶した状態で、決済サーバ１００へ提供し得る。また、ＣＰＵ１０１によって実行されるプログラムは、決済サーバ１００を介してユーザ端末５００などへダウンロードしてもよい。例えば、決済サーバ１００の上記各機能を実現するプログラムを、アプリケーションソフトウェアとしてユーザ端末５００などへダウンロードしてもよい。また、証券サーバ９００も決済サーバ１００と同様のハードウェア構成を有する。
【0054】
＜ユーザ端末５００のハードウェア構成＞
図５は、ユーザ端末５００のハードウェア構成例を示した図である。
図５に示すように、ユーザ端末５００は、ＣＰＵ５０１と、ＲＡＭ５０２と、ＲＯＭ５０３と、記憶部５０４と、操作パネル５０５と、スピーカ５０６と、マイク５０７と、カメラ５０８と、ＧＰＳセンサ５０９と、通信インターフェイスＩ／Ｆ５１１とを備える。
図５は、ユーザ端末５００のハードウェア構成例を示した図である。
図５に示すように、ユーザ端末５００は、ＣＰＵ５０１と、ＲＡＭ５０２と、ＲＯＭ５０３と、記憶部５０４と、操作パネル５０５と、スピーカ５０６と、マイク５０７と、カメラ５０８と、ＧＰＳセンサ５０９と、通信インターフェイスＩ／Ｆ５１１とを備える。
【0055】
ＣＰＵ５０１は、ＲＯＭ５０３などに記憶された各種プログラムをＲＡＭ５０２にロードして実行することにより、ユーザ端末５００の上記各機能を実現する。
ＲＡＭ５０２は、ＣＰＵ５０１の作業用メモリなどとして用いられるメモリである。
ＲＯＭ５０３は、ＣＰＵ５０１が実行する各種プログラムなどを記憶するメモリである。
記憶部５０４は、各種アプリケーションソフトウェアのプログラム、および当該プログラムによって使用される各種データなどを記憶する例えばフラッシュメモリである。
操作パネル５０５は、各種情報の表示やユーザＵＲからの操作入力の受付を行う例えばタッチパネルである。
ＲＡＭ５０２は、ＣＰＵ５０１の作業用メモリなどとして用いられるメモリである。
ＲＯＭ５０３は、ＣＰＵ５０１が実行する各種プログラムなどを記憶するメモリである。
記憶部５０４は、各種アプリケーションソフトウェアのプログラム、および当該プログラムによって使用される各種データなどを記憶する例えばフラッシュメモリである。
操作パネル５０５は、各種情報の表示やユーザＵＲからの操作入力の受付を行う例えばタッチパネルである。
【0056】
スピーカ５０６は、通話先から受信された受話音声を含む種々の音声を出力する。
マイク５０７は、ユーザの発話音声を含む種々の音声を取得する。
カメラ５０８は、レンズと、ＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｍｅｔａｌ-Ｏｘｉｄｅ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）などの撮像素子（画像センサ）とを含み、被写体を撮影する。
マイク５０７は、ユーザの発話音声を含む種々の音声を取得する。
カメラ５０８は、レンズと、ＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｍｅｔａｌ-Ｏｘｉｄｅ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）などの撮像素子（画像センサ）とを含み、被写体を撮影する。
【0057】
ＧＰＳセンサ５０９は、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）信号を取得し、ユーザ端末５００の位置情報を取得する。
通信Ｉ／Ｆ３１２は、ネットワークなどを介して他の通信機器との間でデータを送受信する。
通信Ｉ／Ｆ３１２は、ネットワークなどを介して他の通信機器との間でデータを送受信する。
【0058】
ここで、ＣＰＵ５０１によって実行されるプログラムは、半導体メモリなどのコンピュータが読取可能な記録媒体に記憶した状態で、ユーザ端末５００へ提供し得る。また、ＣＰＵ５０１によって実行されるプログラムは、ネットワークを介してユーザ端末５００へダウンロードしてもよい。例えば、ユーザ端末５００の上記各機能を実現するプログラムを、アプリケーションソフトウェアとしてユーザ端末５００へダウンロードしてもよい。そして、ユーザＵＲは、ユーザ端末５００にダウンロードしたアプリケーションソフトウェアをインストールして、上記サービスを利用する。
【0059】
＜証券口座開設処理＞
証券口座は、ユーザ端末５００の決済アプリを用いて決済サーバ１００を介して、開設することができる。この証券口座の開設は、例えばユーザＵＲの本人確認が完了していること（図３（Ａ）のユーザＴＢ参照）を条件として実行してもよい。このことにより証券口座を開設する際に必要となる本人確認の処理負担が軽減される。また、決済アプリと証券口座の本人確認を同一のタイミングで実施してもよい。このことにより、ユーザは一度の本人確認手続きにより、決済アプリおよび証券口座の本人確認を行うことができる。また、決済アプリにより口座開設されることにともない、開設された証券口座と決済口座とを自動的に連携してもよい。このことにより、ユーザＵＲによる証券口座と決済口座とを関連づける手続きが簡略化される。なお、ここでの連携とは、一の情報から他の情報を検索可能にすることである。
証券口座は、ユーザ端末５００の決済アプリを用いて決済サーバ１００を介して、開設することができる。この証券口座の開設は、例えばユーザＵＲの本人確認が完了していること（図３（Ａ）のユーザＴＢ参照）を条件として実行してもよい。このことにより証券口座を開設する際に必要となる本人確認の処理負担が軽減される。また、決済アプリと証券口座の本人確認を同一のタイミングで実施してもよい。このことにより、ユーザは一度の本人確認手続きにより、決済アプリおよび証券口座の本人確認を行うことができる。また、決済アプリにより口座開設されることにともない、開設された証券口座と決済口座とを自動的に連携してもよい。このことにより、ユーザＵＲによる証券口座と決済口座とを関連づける手続きが簡略化される。なお、ここでの連携とは、一の情報から他の情報を検索可能にすることである。
【0060】
＜証券口座との連携＞
証券口座と決済口座とが連携されると、決済サーバ１００は、ユーザＴＢの証券口座情報に連携した証券口座の情報を保存する。証券管理部１５０は、所定のタイミング毎に連携した証券口座にアクセスし、証券口座の資金状況を確認する。証券管理部１５０は、証券口座の資産に変動があると、証券管理部１５０が証券口座ＴＢを更新する。なお、証券口座において残高に変動があることにともない証券サーバ９００から通知を受けることで、証券口座ＴＢが更新してもよい。このように、証券口座ＴＢは、証券口座の資金状況と同期している。
証券口座と決済口座とが連携されると、決済サーバ１００は、ユーザＴＢの証券口座情報に連携した証券口座の情報を保存する。証券管理部１５０は、所定のタイミング毎に連携した証券口座にアクセスし、証券口座の資金状況を確認する。証券管理部１５０は、証券口座の資産に変動があると、証券管理部１５０が証券口座ＴＢを更新する。なお、証券口座において残高に変動があることにともない証券サーバ９００から通知を受けることで、証券口座ＴＢが更新してもよい。このように、証券口座ＴＢは、証券口座の資金状況と同期している。
【0061】
証券口座と決済口座とが連携されると、決済口座で保有されるマネー（資金移動業に該当する資金）は、証券口座に自動的に払い出されてもよい。このとき、決済口座で保有されるバリュー（前払い式支払い手段に該当する資金）は、証券口座に自動的に払い出されない。このことにより、マネーは証券口座で保有し、バリューは決済口座で保有する態様となり、管理が簡素化される。
【0062】
＜決済処理＞
図６は、決済システム１の決済処理を示すフローチャートである。
次に、図６を参照しながら、決済システム１の決済処理について説明をする。ここで、決済処理は、例えば店舗端末３００が、クレジットカード情報を取得することにより開始される。また、図６に示す例においては、決済口座（ウォレット）のウォレット決済残高は、支払金額よりも少ない（不足する）場合について説明する。
図６は、決済システム１の決済処理を示すフローチャートである。
次に、図６を参照しながら、決済システム１の決済処理について説明をする。ここで、決済処理は、例えば店舗端末３００が、クレジットカード情報を取得することにより開始される。また、図６に示す例においては、決済口座（ウォレット）のウォレット決済残高は、支払金額よりも少ない（不足する）場合について説明する。
【0063】
まず、店舗端末３００が、決済サーバ１００に対して決済要求を出力する（Ｓ５０１）。決済要求を受け付けた決済サーバ１００の決済処理部１３０は、決済処理を実行する。具体的には、決済処理部１３０は、ユーザＴＢからクレジット番号に関連付けられたユーザＵＲおよびユーザＵＲのウォレットを特定し、決済口座（ウォレット）ＴＢからユーザＵＲのウォレット決済残高を取得する（Ｓ５０２）。本説明においては、この決済口座（ウォレット）ＴＢから取得したウォレット決済残高は決済要求額に対して不足しているため、決済処理部１３０は、証券口座ＴＢからユーザＵＲの証券決済残高を取得する（Ｓ５０３）。決済処理部１３０は、証券決済残高と、ウォレット決済残高の決済要求額に対する不足額とを比較する（Ｓ５０４）。決済処理部１３０は、証券決済残高が不足額以上である場合は決済処理を継続し、証券決済残高が不足額未満である場合は決済処理を中止し、店舗端末３００に決済不可を通知する。
【0064】
そして、決済処理部１３０は、決済口座（ウォレット）ＴＢのウォレット決済可能残高を減じる（この例においてはゼロとする）とともに、不足分を決済口座（ウォレット）ＴＢの負債として記憶する（Ｓ５０５）。すなわち、決済サーバ１００は、決済口座（ウォレット）ＴＢの不足分を一時的に後払い決済（Ｂｕｙ Ｎｏｗ Ｐａｙ Ｌａｔｅｒ、ＢＮＰＬ）状態とする。このことにより、証券口座からの資金の払い出しを待つことなく、ユーザＵＲおよび店舗ＳＨの間における決済処理を完了させることができる。そして、決済処理部１３０は、店舗端末３００に対して決済完了通知を出力する（Ｓ５０６）。このことにより、店舗ＳＨ側が決済完了を把握することができ、ユーザＵＲからの店舗ＳＨへの支払いが終了する。
【0065】
次に、決済サーバ１００の決済処理部１３０は、証券サーバ９００に払出要求を出力する（Ｓ５０７）。いわば、決済処理部１３０は、証券サーバ９００に対して債務通知を出力する。払出要求を受信した証券サーバ９００は、証券口座の資金を確保する（Ｓ５０８）。例えば、証券口座の資金の確保は、証券決済残高に預かり金が反映されており、かつ預かり金でＭＲＦを購入している場合、ＭＲＦの売却を行う。また、証券決済残高に売却可能な証券の銘柄の評価額が反映されている場合は、当該証券の売却を行う。
【0066】
次に、証券サーバ９００は、決済サーバ１００へ資金を払い出す払出処理を実行する（Ｓ５０９）。具体的には、売却処理（Ｓ５０８参照）で売却された有価証券の売却額から、払出要求の要求額を決済サーバ１００側に支払う処理を実行する。そして、証券サーバ９００は、決済サーバ１００に対して払出完了通知を出力する（Ｓ５１０）。払出完了通知を受けた決済サーバ１００の決済処理部１３０は、負債の解消処理を実行する（Ｓ５１１）。すなわち、決済口座（ウォレット）ＴＢの不足分（負債）について証券口座の資金を用いて精算を行う。なお、証券サーバ９００から、決済サーバ１００への資金の払い出しは、売却処理（Ｓ５０８参照）において、即時出金不可能な証券（株式等）の売却が行われた場合は、所定期間の経過後である証券引渡後に行われる。
【0067】
なお、図６に示す例とは異なり、決済口座（ウォレット）のウォレット決済残高が、ユーザＵＲが要求する支払いの支払金額以上である場合は、上記証券口座からの資金の払出処理が行われない。すなわち、決済サーバ１００が、決済処理を実行した後（Ｓ５０２参照）、決済完了通知を出力する（Ｓ５０３参照）ことで、決済処理が終了する。
【0068】
上記のように、決済システム１は、ユーザＵＲが店舗ＳＨにおいて商品・サービスの購入・利用をする際に、ユーザＵＲは決済サーバ１００を介して、自身が所有する証券口座の資金を利用しながら決済を行うことできる。このことにより、ユーザＵＲにとって利便性の高い決済サービスが提供される。また、決済システム１は、証券口座から決済口座への資金の払い出しを完了するより前に決済を行うことにより、速やかに決済を実行することが可能となる。また、証券口座における有価証券の売却後であっても、有価証券の受渡を待つことなく、すぐに売却額に相当する額が決済に利用可能なため、ユーザＵＲにとって利便性の高い決済サービスが提供される。
【0069】
さて、上記の例においては、ＭＲＦまたは有価証券を売却することで払出処理を実行することを説明した。すなわち、上記の例においては保有資産の売却により払出処理の資金を確保することを説明したが、これに限定されない。例えば、証券口座の預り金によって払出処理を実行してもよい。この場合、上記の説明とは異なり、ＭＲＦの売却処理（Ｓ５０８）を実行せず、証券口座の預り金から、払出要求の要求額を決済サーバ１００側に支払う処理を実行する。
【0070】
上記の例では、ウォレット決済残高を証券決済残高に優先して決済に利用する例について説明したが、これに限られない。例えば、証券決済残高をウォレット決済残高に優先して決済に利用してもよい。この場合、証券決済残高が決済要求額に対して不足している場合に、ウォレット決済残高を用いて決済を行ってもよい。また、決済要求額に対して、ウォレット決済残高と証券決済残高とを所定の割合で決済に利用してもよい。
【0071】
＜購入処理＞
図７は、決済システム１の有価証券の購入処理を示すフローチャートである。
次に、図７を参照しながら、決済システム１の有価証券の購入処理について説明をする。購入処理によって、ユーザＵＲはユーザ端末５００の決済アプリを用いて、決済サーバ１００を介して有価証券を購入することが可能となる。なお、図７に示す例においては、証券口座の買付余力は、ユーザＵＲが購入指示をする有価証券の金額よりも少ない（不足する）場合について説明する。そして、図７に示す例においては、この不足分について決済口座（ウォレット）から証券口座への払出処理が実行される。すなわち、決済口座（ウォレット）の資金におけるマネーを利用して、有価証券の購入が実行される。ここで、上述のように決済口座（ウォレット）の資金におけるバリューは有価証券を購入することができない。そこで、決済口座（ウォレット）のウォレット決済残高の一部であるマネーを利用して、有価証券の購入が実行される。
図７は、決済システム１の有価証券の購入処理を示すフローチャートである。
次に、図７を参照しながら、決済システム１の有価証券の購入処理について説明をする。購入処理によって、ユーザＵＲはユーザ端末５００の決済アプリを用いて、決済サーバ１００を介して有価証券を購入することが可能となる。なお、図７に示す例においては、証券口座の買付余力は、ユーザＵＲが購入指示をする有価証券の金額よりも少ない（不足する）場合について説明する。そして、図７に示す例においては、この不足分について決済口座（ウォレット）から証券口座への払出処理が実行される。すなわち、決済口座（ウォレット）の資金におけるマネーを利用して、有価証券の購入が実行される。ここで、上述のように決済口座（ウォレット）の資金におけるバリューは有価証券を購入することができない。そこで、決済口座（ウォレット）のウォレット決済残高の一部であるマネーを利用して、有価証券の購入が実行される。
【0072】
また、図７に示す例においては、ユーザＵＲが操作するユーザ端末５００には、ユーザＵＲからの指示に応じて、証券操作画像５３０（後述する図１１―２（Ｄ）参照）が表示されているものとする。そして、証券操作画像５３０の売買指示画像５５１が操作されることにより、決済サーバ１００はユーザＵＲから有価証券の購入指示を受け付ける。
【0073】
まず、ユーザＵＲが操作するユーザ端末５００が、決済サーバ１００に対して有価証券の購入要求を出力する（Ｓ６０１）。この購入要求には、ユーザＩＤに関連する情報、購入する有価証券の銘柄および数量の情報が含まれる。そして、有価証券の購入要求を受け付けた決済サーバ１００の証券管理部１５０は、証券サーバ９００に対して有価証券の購入指示を出力する（Ｓ６０２）。この購入指示には、上記購入要求で受け付けたユーザＩＤに関連する情報、購入する有価証券の銘柄および数量の情報が含まれる。そして、証券サーバ９００は、証券口座ＴＢにおけるユーザＵＲの証券口座における買付余力を読み込む（Ｓ６０３）。本実施例においては、証券口座の買付余力は購入指示を受け付けた有価証券の評価額に対して不足しているため、証券サーバ９００は、決済サーバ１００に不足分についての払出要求を出力する（Ｓ６０４）。そして、決済サーバ１００の決済処理部１３０は、払出処理を実行する（Ｓ６０５）。具体的には、決済処理部１３０は、決済口座（ウォレット）のマネー残高から払出要求の要求額を減じるとともに、要求額を証券口座に振り込む処理を実行する。そして、決済処理部１３０は、証券サーバ９００に対して払出完了通知を出力する（Ｓ６０６）。払出完了通知を受けた証券サーバ９００は、購入処理を実行する（Ｓ６０７）。すなわち、ユーザＵＲから指示を受けた有価証券の購入手続きを完了させる。
【0074】
次に、証券サーバ９００は、決済サーバ１００に対して購入完了通知を出力する（Ｓ６０８）。購入完了通知を受けた決済サーバ１００の通信部１７０は、ユーザ端末５００に対して購入が完了したことを示す画像の表示を指示する（Ｓ６０９）。この指示を受けたユーザ端末５００は、購入完了を示す画像を示す（Ｓ６１０）。このことにより、ユーザＵＲが購入完了を把握することができる。
【0075】
なお、図７に示す例とは異なり、証券口座の買付余力が、ユーザＵＲが購入指示をする有価証券の金額以上である場合は、払出処理が行われない。すなわち、証券サーバ９００は、残高読込を実行した後（Ｓ６０３参照）、払出要求（Ｓ６０４参照）を実行することなく、購入処理（Ｓ６０７参照）を実行して、購入処理が終了する。
【0076】
ここで、ユーザ端末５００の決済アプリは、証券口座の買付余力および決済口座（ウォレット）のマネー残高は取得可能である。したがって、上記の説明とは異なり、ユーザ端末５００の決済アプリにおいてユーザＵＲから受け付けた有価証券の評価額が、買付余力およびマネー残高の合算を超える場合は、有価証券の購入注文を受け付けない（注文を制限する）という態様でもよい。
【0077】
このように、ユーザＵＲはユーザ端末５００の決済アプリを介して証券口座の有価証券を取引することが可能となる。よって、ユーザＵＲは１つのアプリを用いて決済の管理と証券取引とを行うことができる。また、ウォレット決済残高を用いて、証券取引を行うことが可能となる。よって、口座間での煩雑な資金移動を行うことなく、シームレスに複数の口座を連携させて利用することができる。
【0078】
＜出金処理＞
図８は、決済システム１の出金処理を示すフローチャートである。
次に、図８を参照しながら、決済システム１の出金処理について説明をする。ここで、出金処理は、ユーザＵＲが操作するＡＴＭ８００から出金要求を受け付けることにより開始される。この出金処理により、ユーザＵＲは現金を引き出すことが可能となる。ここで、図８に示す例においては、決済口座の現金を引き出し可能な資金であるマネーの残高は、ユーザＵＲが要求する出金要求の出金金額よりも少ない（不足する）ものとする
図８は、決済システム１の出金処理を示すフローチャートである。
次に、図８を参照しながら、決済システム１の出金処理について説明をする。ここで、出金処理は、ユーザＵＲが操作するＡＴＭ８００から出金要求を受け付けることにより開始される。この出金処理により、ユーザＵＲは現金を引き出すことが可能となる。ここで、図８に示す例においては、決済口座の現金を引き出し可能な資金であるマネーの残高は、ユーザＵＲが要求する出金要求の出金金額よりも少ない（不足する）ものとする
【0079】
まず、ユーザＵＲが操作するＡＴＭ８００が決済サーバ１００に対して出金要求を出力する（Ｓ７０１）。出金要求には、ユーザＩＤに関連する情報、出金要求額が含まれる。そして、出金要求を受け付けた決済サーバ１００の入出金処理部１１０は、出金処理を実行する（Ｓ７０２）。具体的には、入出金処理部１１０は、ＡＴＭ８００から受信したユーザＩＤに基づいて決済口座（ウォレット）ＴＢからユーザＵＲを特定する。入出金処理部１１０は特定したユーザＵＲの決済口座（ウォレット）ＴＢからマネー残高を取得する。この決済口座（ウォレット）ＴＢから取得したマネー残高は出金要求額に対して不足しているため、入出金処理部１１０は、証券口座ＴＢからユーザＵＲの証券決済残高を取得する。そして、入出金処理部１１０は、決済口座（ウォレット）ＴＢのマネー残高を減じる（この例においてはゼロとする）とともに、不足分を決済口座（ウォレット）ＴＢの負債として記憶する。
【0080】
次に、決済サーバ１００の通信部１７０は、ＡＴＭ８００に対して出金許可通知を出力する（Ｓ７０３）。そして、出金許可通知を受信したＡＴＭ８００は、ユーザＵＲに対して現金を払い出す払出処理を実行する（Ｓ７０４）。このことにより、ユーザＵＲによるＡＴＭ８００からの現金の引出しが完了する。
【0081】
次に、決済サーバ１００の決済処理部１３０は、証券サーバ９００に払出要求を出力する（Ｓ７０５）。払出要求を受信した証券サーバ９００は、例えば証券口座のＭＲＦ（有価証券）の売却処理を実行し、資金を確保する（Ｓ７０６）。そして、証券サーバ９００は、払出処理を実行する（Ｓ７０７）。具体的には、売却処理（Ｓ７０６参照）で売却された有価証券の売却額から、払出要求の要求額を決済サーバ１００側に支払う処理を実行する。そして、証券サーバ９００は、決済サーバ１００に対して払出完了通知を出力する（Ｓ７０８）。払出完了通知を受けた決済サーバ１００の決済処理部１３０は、解消処理を実行する（Ｓ７０９）。すなわち、決済口座（ウォレット）ＴＢの不足分についての後払い決済を完了させる。
【0082】
なお、図８に示す例とは異なり、決済口座（ウォレット）の現金を引き出し可能な資金であるマネーの残高が、ユーザＵＲが要求する出金要求の出金金額以上である場合は、証券口座からの払出処理が行われない。すなわち、決済サーバ１００が出金処理を実行した後（Ｓ７０２参照）、出金完了通知を出力する（Ｓ７０３参照）ことで、出金処理が終了する。
【0083】
このように、ユーザＵＲは、証券口座の資金を決済口座を介して容易に出金することが可能となる。ユーザＵＲは、証券口座の証券決済残高の資金を容易に出金することが可能となる。証券決済残高は、前述したように有価証券の売却後であって、証券の受渡前に売却額に相当する額を反映させることができる。ユーザは決済口座を介することで、証券の受渡前であっても売却額に相当する額を出金することが可能となる。また、ユーザは決済口座を介することで、証券サーバ９００のダウンタイムであっても証券口座の資金を出金することが可能となる。
【0084】
＜入金処理＞
（入金処理概略）
図９は、決済システム１の第１入金処理を示すフローチャートである。
図１０は、決済システム１の第２入金処理を示すフローチャートである。
次に、図９および図１０を参照しながら、ユーザＵＲからＡＴＭ８００などを介して決済口座に入金する指示を受け付けた場合の決済システム１における入金処理について説明をする。また、決済システム１の入金処理は、決済口座が証券口座と連携されているか否かで処理が異なる。さらに説明をすると、ユーザＴＢにおいて対象とするユーザＵＲの証券口座が記憶されているかを入出金処理部１１０が判断し、証券口座が記憶されているか否かに応じて、入金先を証券口座とする処理と、入金先を決済口座とする処理とが切り替えられる。以下、決済口座が証券口座と連携されており入金先が証券口座となる第１入金処理と、決済口座が証券口座と連携されておらず入金先が決済口座となる場合の第２入金処理とを説明する。なお、第１入金処理および第２入金処理は、いずれもＡＴＭ８００がユーザＵＲからユーザＵＲの銀行口座への現金の入金を受け付けることにより開始される。なお、以下の説明においては、ＡＴＭ８００は銀行サーバ７００によって制御されるものとする。
（入金処理概略）
図９は、決済システム１の第１入金処理を示すフローチャートである。
図１０は、決済システム１の第２入金処理を示すフローチャートである。
次に、図９および図１０を参照しながら、ユーザＵＲからＡＴＭ８００などを介して決済口座に入金する指示を受け付けた場合の決済システム１における入金処理について説明をする。また、決済システム１の入金処理は、決済口座が証券口座と連携されているか否かで処理が異なる。さらに説明をすると、ユーザＴＢにおいて対象とするユーザＵＲの証券口座が記憶されているかを入出金処理部１１０が判断し、証券口座が記憶されているか否かに応じて、入金先を証券口座とする処理と、入金先を決済口座とする処理とが切り替えられる。以下、決済口座が証券口座と連携されており入金先が証券口座となる第１入金処理と、決済口座が証券口座と連携されておらず入金先が決済口座となる場合の第２入金処理とを説明する。なお、第１入金処理および第２入金処理は、いずれもＡＴＭ８００がユーザＵＲからユーザＵＲの銀行口座への現金の入金を受け付けることにより開始される。なお、以下の説明においては、ＡＴＭ８００は銀行サーバ７００によって制御されるものとする。
【0085】
（第１入金処理）
まず、銀行サーバ７００が、ユーザＵＲの入金を受け付ける着金処理を実行する（Ｓ８０１）。具体的には、銀行サーバ７００は、決済サーバ１００に対して入金通知をする。この入金通知には入金先としてＡＴＭ８００が受け付けた銀行口座の口座番号と入金額が含まれる。そして、決済サーバ１００は、ユーザＴＢ（図３（Ａ））を参照し、入金通知に含まれる銀行口座の番号からユーザＵＲを特定する。次に、決済サーバ１００は、特定したユーザＵＲに証券口座が連携されているか否かを確認する。この例においては、銀行口座と連携された証券口座が存在する場合について説明する。次に、決済サーバ１００は、銀行サーバ７００に対し、入金先をユーザＵＲの証券口座とする払出指示を出力する（Ｓ８０２）。この払出指示には、入金先となる証券口座の口座番号が含まれる。すなわち、決済サーバ１００は、銀行口座に入金された資金を証券口座に送金する指示を出力する。
まず、銀行サーバ７００が、ユーザＵＲの入金を受け付ける着金処理を実行する（Ｓ８０１）。具体的には、銀行サーバ７００は、決済サーバ１００に対して入金通知をする。この入金通知には入金先としてＡＴＭ８００が受け付けた銀行口座の口座番号と入金額が含まれる。そして、決済サーバ１００は、ユーザＴＢ（図３（Ａ））を参照し、入金通知に含まれる銀行口座の番号からユーザＵＲを特定する。次に、決済サーバ１００は、特定したユーザＵＲに証券口座が連携されているか否かを確認する。この例においては、銀行口座と連携された証券口座が存在する場合について説明する。次に、決済サーバ１００は、銀行サーバ７００に対し、入金先をユーザＵＲの証券口座とする払出指示を出力する（Ｓ８０２）。この払出指示には、入金先となる証券口座の口座番号が含まれる。すなわち、決済サーバ１００は、銀行口座に入金された資金を証券口座に送金する指示を出力する。
【0086】
そして、銀行サーバ７００は、入金された金額を指定された証券口座に払い出す払出処理を実行する（Ｓ８０３）。そして、証券サーバ９００は、証券口座の残高を増やす残高更新処理を行う（Ｓ８０４）。
【0087】
次に、証券サーバ９００は、決済サーバ１００に対して証券口座の資金に変動があった旨を通知する更新完了通知を出力する（Ｓ８０４）。更新完了通知を受けた決済サーバ１００の入出金処理部１１０は、証券口座ＴＢの証券決済残高を更新する残高更新処理を実行する（Ｓ８０５）。以上の処理により、ユーザＵＲから銀行口座に入金された資金は、証券口座に入金される。付言すると、第１入金処理においては、決済口座（ウォレット）ＴＢ（図３（Ｂ）参照）は更新されずに、証券口座ＴＢ（図３（Ｃ）参照）が更新される。
【0088】
（第２入金処理）
まず、銀行サーバ７００が、ユーザＵＲの入金を受け付ける着金処理を実行する（Ｓ９０１）。具体的には、銀行サーバ７００は、決済サーバ１００に対して入金通知をする。そして、決済サーバ１００は、ユーザＴＢ（図３（Ａ））を参照し、入金通知に含まれる銀行口座の番号からユーザＵＲを特定する。次に、決済サーバ１００は、特定したユーザＵＲに証券口座が連携されているか否かを確認する。この例においては、銀行口座と連携された証券口座が存在しない場合について説明する。
まず、銀行サーバ７００が、ユーザＵＲの入金を受け付ける着金処理を実行する（Ｓ９０１）。具体的には、銀行サーバ７００は、決済サーバ１００に対して入金通知をする。そして、決済サーバ１００は、ユーザＴＢ（図３（Ａ））を参照し、入金通知に含まれる銀行口座の番号からユーザＵＲを特定する。次に、決済サーバ１００は、特定したユーザＵＲに証券口座が連携されているか否かを確認する。この例においては、銀行口座と連携された証券口座が存在しない場合について説明する。
【0089】
次に、決済サーバ１００の入出金処理部１１０は、決済口座（ウォレット）ＴＢのウォレット決済残高を更新する残高更新処理を実行する（Ｓ９０２）。具体的には、決済サーバ１００は入金通知に含まれる入金額を、銀行口座番号から特定したユーザＵＲの決済口座（ウォレット）ＴＢ（図３（Ｂ）参照）に反映させる。付言すると、第２入金処理においては、証券口座ＴＢ（図３（Ｃ）参照）は更新されずに、決済口座（ウォレット）ＴＢが更新される。
【0090】
（入金処理の変形例など）
上記のように、第１入金処理において、ＡＴＭ８００がユーザＵＲから受け付けた入金金額は、証券口座に入金される。すなわち、ユーザＵＲが決済口座へのチャージを行おうとすると、決済口座は経由せず、自動で証券口座に入金される。このことにより、金利が高いなどユーザＵＲにとって有利な有価証券として資金が保有される。なお、ＡＴＭ８００で受け付けた資金を証券口座に直ちに移動させることは必要なく、証券口座の買付余力に反映できればよい。この場合、決済サービス会社ＫＳは、所定のタイミングで銀行口座から資金を証券会社ＳＣに送金する。上記の通り、ユーザＵＲに関連づけられている銀行口座は決済サービス会社ＫＳの口座である。決済サービス会社ＫＳは、複数のユーザＵＲに関連づけられた銀行口座の資金をまとめて証券会社ＳＣに送金してもよい。
上記のように、第１入金処理において、ＡＴＭ８００がユーザＵＲから受け付けた入金金額は、証券口座に入金される。すなわち、ユーザＵＲが決済口座へのチャージを行おうとすると、決済口座は経由せず、自動で証券口座に入金される。このことにより、金利が高いなどユーザＵＲにとって有利な有価証券として資金が保有される。なお、ＡＴＭ８００で受け付けた資金を証券口座に直ちに移動させることは必要なく、証券口座の買付余力に反映できればよい。この場合、決済サービス会社ＫＳは、所定のタイミングで銀行口座から資金を証券会社ＳＣに送金する。上記の通り、ユーザＵＲに関連づけられている銀行口座は決済サービス会社ＫＳの口座である。決済サービス会社ＫＳは、複数のユーザＵＲに関連づけられた銀行口座の資金をまとめて証券会社ＳＣに送金してもよい。
【0091】
また、ここではＡＴＭ８００を介して入金指示を受け付けることを説明したが、これに限定されない。例えば、銀行からの振り込み指示、コンビニエンスストアなどの店舗ＳＨからのチャージ指示にともなう入金の指示を受け付ける場合も、上記のように決済口座に反映されることなく証券口座に入金される態様でもよい。さらに説明をすると、他のユーザからの送金も証券口座に入金される態様でもよい。
【0092】
また、他のユーザから入金される資金の金額に応じて、決済口座への入金を許可するか否かを切り替えてもよい。例えば、入金される資金の金額が１００万円を超える場合と、１００万円以下の場合とに応じて、入金先を切り替えてもよい。具体的には、１００万円を超える資金移動の場合は証券口座に入金し、１００万円以下の資金移動の場合は決済口座に入金する態様でもよい。
【0093】
また、入金後のウォレット決済残高に応じて、入金先を変更してもよい。例えば、入金後のウォレット決済残高が１００万円を超える場合は、証券口座に入金し、１００万円以下の場合は決済口座に入金する態様でもよい。入金後のウォレット決済残高が１００万円を超える場合は、ウォレット決済残高が１００万円以下となる部分を決済口座に入金し、それ以外を証券口座に入金する態様でもよい。上記の例は１００万円を閾値として説明したが、これに限られない。例えば、決済口座残高の上限はユーザが設定した額としてもよい。
【0094】
入金先は、入金毎にユーザＵＲが都度指示する構成でもよい。例えば、銀行口座に入金がされた場合、決済アプリ上に入金通知を行う。決済アプリは、入金先と入金額を決済口座と証券口座とに振り分ける操作を受け付け可能に構成されてもよい。
【0095】
また、他のユーザから入金される資金の振込名目に応じて、入金を許可するか否かを切り替えてもよい。例えば、入金される資金の振込名目が給与・賞与の場合は、決済口座が証券口座と連携されていることを条件に、入金を許可する態様でもよい。この態様においては、証券口座に入金がされる。すなわち決済口座には給与・賞与が入金されることを許容しない態様でもよい。
【0096】
このように、ユーザＵＲは、決済サービス会社ＫＳにより割り当てられた銀行口座を用いて、決済口座と証券口座とに入金を行うことが可能となる。よって、異なる口座間での資金の移動が容易となる。また、決済サービス会社ＫＳにより割り当てられた銀行口座を用いるため、周知の銀行振込みを用いて入金が可能となり、決済口座のユーザＩＤを指定して入金を行う等の煩雑な入金操作を行う必要がない。
【0097】
＜決済操作画像５１０＞
図１１―１および図１１―２は、決済操作画像５１０を示す図である。
次に、図１１―１および図１１―２を参照しながら、決済サーバ１００および決済アプリによってユーザ端末５００に表示される決済操作画像５１０について説明をする。決済操作画像５１０は、ユーザ端末５００を操作するユーザＵＲに決済に関する情報を表示し、ユーザＵＲからの指示を受け付ける画像である。
図１１―１および図１１―２は、決済操作画像５１０を示す図である。
次に、図１１―１および図１１―２を参照しながら、決済サーバ１００および決済アプリによってユーザ端末５００に表示される決済操作画像５１０について説明をする。決済操作画像５１０は、ユーザ端末５００を操作するユーザＵＲに決済に関する情報を表示し、ユーザＵＲからの指示を受け付ける画像である。
【0098】
図１１―１（Ａ）に示すように、図示の例における決済操作画像５１０は、クレジットカードを模した画像であるカード画像５１１と、ユーザＵＲの決済可能額を示す決済可能額画像５１２と、決済システム１を利用することでユーザＵＲが取得したポイントを示すポイント画像５１３と、ユーザＵＲからの入出金の指示を受け付ける入出金指示画像５１５と、決済システム１を利用した履歴である履歴画像５１７とを含む。
【0099】
ここで、図示のカード画像５１１は、ユーザＵＲに割り当てられたクレジットカードのクレジット番号を表示する。このクレジット番号を店舗端末３００が取得するなどすることにより、上記決済処理が開始される。
【0100】
また、決済可能額画像５１２に示されるユーザＵＲの決済可能額は、ユーザＵＲのウォレット決済残高と、証券決済残高と、の合計である。ウォレット決済残高は、ユーザＵＲが決済口座に所有するマネーとバリューとの合算である（図３（Ｂ）参照）。証券決済残高は、ユーザＵＲが証券口座に所有する決済に利用できる資金の額である
【0101】
ここで、ユーザＵＲが決済可能額画像５１２を選択するなど所定の操作をすることにより、図１１―２（Ｂ）に示すように決済可能額の内訳を示す決済可能額内訳画像５１９が表示される。この決済可能額内訳画像５１９は、決済口座（ウォレット）における決済可能額を示すウォレット決済画像５２１と、証券口座における決済可能額を示す証券決済画像５２３とを含む。なお、図示のウォレット決済画像５２１は、決済口座（ウォレット）におけるマネーおよびバリューの内訳を表示する。
【0102】
また、決済操作画像５１０を左右方向にスワイプするなどユーザＵＲが所定の操作をすることにより、図１１―２（Ｃ）に示すように、出金可能資金の額（出金可能額）を示す出金可能額画像５２５と、出金可能額の内訳を示す出金可能額内訳画像５２７とが表示される。この出金可能額内訳画像５２７は、決済口座（ウォレット）における出金可能額であるマネーの額を示すマネー画像５２８と、証券口座における決済口座を介して出金可能な額である証券決済残高を示す証券出金画像５２９とを含む。
【0103】
また、決済操作画像５１０を左右方向にスワイプするなどユーザＵＲが所定の操作をすることにより、図１１―２（Ｄ）に示すように、証券口座に関する情報を表示させる画像である証券操作画像５３０が表示される。この証券操作画像５３０は、ユーザＵＲが保有する証券の評価額の推移を示す評価額グラフ５３３を有する。また、証券操作画像５３０は、ユーザＵＲが証券口座に保有する株式の銘柄およびその評価額を示す株式表示画像５４１と、ユーザＵＲが証券口座に保有する投資信託の銘柄およびその評価額を示す投信表示画像５４３と、ユーザＵＲが証券口座に保有する預り金を示す預かり金画像５４５とを有する。また、図示の証券操作画像５３０は、ユーザＵＲからの有価証券の売買の指示を受け付ける売買指示画像５５１を有する。
【0104】
このように、証券決済残高を含む決済可能額を決済アプリに表示することで、ユーザＵＲは、特別に意識することなく、証券口座の資金を用いて、ウォレットを介した決済を行うことができる。すなわち、チャージ残高が不足したために証券口座の資金から払い出すというよりも、上記決済可能額を保有するウォレットから決済されているというユーザエクスペリエンスが提供される。また、証券決済残高を含む出金可能額を決済アプリに表示することで、ユーザＵＲは、特別に意識することなく、証券口座の資金を用いて、ウォレットを介した出金を行うことができる。すなわち、チャージ残高が不足したために証券口座の資金から出金するというよりも、上記出金可能額を保有するウォレットから出金されているというユーザエクスペリエンスが提供される。
【0105】
＜変形例＞
上記の例においては、商品・サービスの決済において、決済口座の資金が不足する場合に、証券口座の資金を用いることを説明したが、これに限定されない。例えば、決済口座の資金の金額にかかわらず、証券口座の資金を用いる態様であってもよい。すなわち、証券口座の資金を優先的に用いる態様でもよい。この態様においては、決済口座の残金に関わらず、ユーザＵＲは決済をすることが可能となる。付言すると、決済口座の資金は常にゼロであってもよい。
上記の例においては、商品・サービスの決済において、決済口座の資金が不足する場合に、証券口座の資金を用いることを説明したが、これに限定されない。例えば、決済口座の資金の金額にかかわらず、証券口座の資金を用いる態様であってもよい。すなわち、証券口座の資金を優先的に用いる態様でもよい。この態様においては、決済口座の残金に関わらず、ユーザＵＲは決済をすることが可能となる。付言すると、決済口座の資金は常にゼロであってもよい。
【0106】
また、決済口座の資金が不足する場合で、不足分を証券口座の資金によっても補えない場合は、決済を受け付けない態様であってもよい。例えば、決済サーバが決済処理を実行する際に（図６のＳ５０２参照）、証券口座ＴＢからユーザＵＲの証券決済残高を取得し、決済口座の不足分を補えない場合は、決済を中止する処理を行ってもよい。
【0107】
また、商品・サービスの決済または有価証券の購入に替えて（あるいは加えて）、ユーザＵＲが他のユーザなどに送金する場合に、証券口座の資金を用いる態様でもよい。例えば、送金において決済口座の資金が不足する場合に、証券口座の資金を用いてもよい。
【0108】
また、上記の説明においては、決済サーバ１００がクレジットカードを介して決済を行うことを説明したが、これに限定されない。例えば、非接触ＩＣを用いた決済や、ＱＲコード（登録商標）などの２次元バーコードを用いた決済など、他の態様の決済において、上記のように決済口座の資金が不足する場合に、証券口座の資金を用いてもよい。
【0109】
また、上記の説明の決済処理においては、払出要求（図６のＳ５０４参照）を実行するよりも前に決済処理（Ｓ５０２参照）を実行することを説明した。ここで、証券サーバ９００の稼働状態に応じて、払出要求よりも前に決済処理を実行する態様と、払出要求よりも後に決済処理を実行する態様とを切り替えてもよい。例えば、決済処理を行うタイミングが証券サーバ９００のダウンタイムである場合に、払出要求よりも前に決済処理を実行する態様とし、それ以外のタイミングである場合に、払出要求よりも後に決済処理を実行する態様としてもよい。また、決済処理を行うタイミングが証券サーバ９００の処理負担が高い（例えば、証券サーバ９００の処理を待つ時間が所定時間よりも長い）場合に、払出要求よりも前に決済処理を実行する態様としてもよい。
【0110】
また、上記の例においては、証券口座に入金された資金はＭＲＦとし、証券口座の資金で決済などをする際にＭＲＦの売却をすることを説明した。ここで、ＭＲＦは、単元株ごとに売却することが必要である株式などと異なり、１円単位で売却することが可能である。したがって、証券口座の資金で上記決済などを実行する際に、株式などよりもＭＲＦを優先することにより、決済に必要な額を過不足なく補うことができる。ここで、証券口座で保有される資金の一部または全部を売却する対象としては、ＭＲＦに限定されない。例えば、証券口座に入金された預り金を証券口座の資金で決済に利用する態様でもよい。この預り金を決済に利用する場合には、上記の例とは異なり有価証券の売買が不要となる。
【0111】
また、証券口座に保有される資金の種別に応じて、決済に利用する際の優先順位を設定してもよい。例えば、預り金、ＭＲＦ、ＭＲＦ以外の他の投資信託、株式の順など、証券口座で保有することでユーザＵＲが受ける利益あるいはリターンが小さい種別から優先して、決済に利用する態様でもよい。あるいは、証券口座に保有される資金のうち、含み益があるものから優先して、決済に利用する態様でもよい。
【0112】
また、ＭＲＦが不足した場合に、他の有価証券を売却することの指示をユーザＵＲから受け付ける態様であってもよい。例えば、ＭＲＦが不足した場合に、他の有価証券を売却することの指示を受け付ける受付画像をユーザ端末５００に表示し、ユーザＵＲから売却指示を受け付けた場合に他の有価証券を売却してもよい。なお、受付画像においては、不足額を補うために必要な有価証券の銘柄や数量の組み合わせを含んでもよい。ここで、有価証券の銘柄や数量の組み合わせを複数表示し、ユーザＵＲによっていずれかを選択可能としてもよい。また、有価証券の銘柄や数量の組み合わせを、有価証券の含み益の大きさに応じて表示してもよい。例えば、有価証券の含み益が大きいものを優先して各組合せを並べて表示してもよい。
【0113】
また、各有価証券を決済に用いることを許容するか否かの指示を、証券口座との連携を設定するタイミングなどにおいて、ユーザＵＲから予め取得する態様でもよい。また、例えば預り金、ＭＲＦ、ＭＲＦ以外の他の投資信託、株式など有価証券のいずれを優先して売却するかをユーザＵＲから受け付けてもよい。
【0114】
また、株式や投資信託の種別や個別銘柄ごとに、売却して決済に用いることの可否を受け付けてもよい。さらに説明をすると、売却して決済に用いることを許可する銘柄と、決済に用いることを許可しない（禁止する）銘柄との設定指示をユーザＵＲから受け付けてもよい。ここで、決済に用いることを許可しない銘柄（ロック銘柄）は、決済可能額に反映させない（合算しない）。このことにより、ユーザＵＲが自身で決済に用いることを許可している資産の総額を把握することが容易となる。また、決済に用いることを許可する銘柄（フリー銘柄）は、評価額（時価）を超えない額（例えば、時価の７０％）で決済可能額に反映させてもよい。このことにより、有価証券の評価額が変動した場合に、決済可能額が不足することが抑制される。なお、フリー銘柄を売却した最終的に有価証券の値下がりにより必要な額を確保できなかった場合、ユーザＵＲに通知し不足分を充当させてもよい。
【0115】
また、証券口座のＭＲＦの評価額を、証券口座における預かり金、すなわち決済可能となる残高とし、他の有価証券の評価額を、売却することで決済可能となる残高とする態様、すなわち２種の残高を表示する態様でもよい。
【0116】
なお、証券口座においては、ＭＲＦを売却すると、売却（約定）当日に売却額が買付余力に反映されるとともに、即日出金可能、すなわち売却当日に売却額が預り金に反映される。一方、株式など他の有価証券を売却すると、売却当日に売却額が買付余力に反映されるが、売却日から３日後などの受け渡し日にはじめて出金可能となる。そこで、上記のように決済処理を行った後で払出処理を行うことで、預かり金反映前の残高も、決済可能額に含めて表示し、決済に用いることができる。付言すると、払出処理が完了するまでは、決済サービス会社ＫＳが、一時的に株式売却金額を担保に貸し付ける状態となる。いわば決済サービス会社ＫＳによる自動貸付状態となる。
【0117】
（ウォレット切り替え）
図１２は、決済操作画像６１０、６５０を示す図である。
上記の説明においては、ユーザＵＲが保有する決済口座（ウォレット）が１つである例を説明したが、これに限定されない。例えば、図１２に示すように、ユーザＵＲが決済口座を複数保有する態様であってもよい。そして、各ウォレットで、証券口座と連携するか否かを設定可能としてもよい。
図１２は、決済操作画像６１０、６５０を示す図である。
上記の説明においては、ユーザＵＲが保有する決済口座（ウォレット）が１つである例を説明したが、これに限定されない。例えば、図１２に示すように、ユーザＵＲが決済口座を複数保有する態様であってもよい。そして、各ウォレットで、証券口座と連携するか否かを設定可能としてもよい。
【0118】
図１２に示す例においては、ユーザＵＲが、図１２（Ａ）の決済操作画像６１０で示される決済口座と、図１２（Ｂ）の決済操作画像６５０で示される決済口座とを保有する。また、決済操作画像６１０が示すウォレット１は証券口座と連携し、決済操作画像６５０が示すウォレット２は証券口座と連携しない。そして、決済操作画像６１０および決済操作画像６５０は、ユーザＵＲの操作に応じて互いに切り替えられる。
【0119】
ここで、証券口座と連携する決済口座を示す決済操作画像６１０は、残高画像６１１と、内訳画像６１３と、履歴画像６１５とを含む。また、証券口座と連携しない決済口座を示す決済操作画像６５０は、残高画像６５１と、内訳画像６５３と、履歴画像６５５とを含む。証券口座と連携する履歴画像６１５においては、ユーザＵＲの利用履歴として、入金、出金、決済の表示に加え、有価証券の売買による残高変動（例えば売却にともなう買付余力の増加分や利益分）も含む。また、残高画像６１１は「総残高」として決済口座および証券口座の資産の合算が表示される。一方、証券口座と連携しない履歴画像６１５においては、入金、出金、決済の表示は含むものの、有価証券の売買に関する情報は含まない。また、残高画像６５１は「残高」として決済口座の資産のみが表示される。
【0120】
なお、ユーザＵＲが証券口座と連携するかの選択により、ユーザＵＲが決済システム１の機能として、資金移動を行う決済口座あるいは有価証券の売買を行う証券口座のいずれを主として利用するかが切り替わる。このことにより、ユーザＵＲの要望に沿った形で決済システム１の機能が提供される。
【0121】
また、ここではウォレット１およびウォレット２が、証券口座と連携するか否かを設定することについて説明したが、決済口座（ウォレット）の設定はこれに限定されない。例えば、証券口座と連携するか否かに加えて（あるいは替えて）、対象とするウォレットを他のユーザと共有するか否かを切り替えてもよい。なお、他のユーザとウォレットを共有することで、他のユーザと共有する資産の管理が容易となる。
【0122】
ここで、上記決済処理にともないユーザＵＲに付与されるポイントは、決済を行ったウォレットに付与される。上記の例においては、証券口座と連携するウォレット１において、証券口座を利用した決済を行った場合、ウォレット２ではなく、決済を行ったウォレット１にポイントが付与される。このことにより、他のユーザにポイントが使用されるなど、ユーザＵＲの意図しないポイントの増減が回避される。
【0123】
【0124】
ここで、図１３に示す決済操作画５７０をユーザ端末５００に表示することによって、有価証券の売買を行ってもよい。図１３（Ａ）に示す決済操作画５７０は、ユーザＵＲの決済可能額を示すカード画像５７１と、決済可能額の内訳を示す決済可能額内訳画像５７５とを有する。すなわち、決算口座の情報と証券口座の情報とが並列表示される。ここで、決済可能額内訳画像５７５は、証券口座の内訳を示す画像として、株式の銘柄および評価額を示す株式画像５８１と、投信の銘柄および評価額を示す投信画像５８３と、預り金の金額を示す預り金画像５８５とを有する。
【0125】
そして、証券口座に保有される有価証券の銘柄を示す画像を操作することで、その銘柄の有価証券の売買が実行される。例えば、ユーザＵＲの操作を受け付けることで株式画像５８１が選択される。そして、図１３（Ｂ）に示すように、ユーザＵＲの操作を受け、株式画像５８１がカード画像５７１に重なる位置に移動される。
【0126】
そして、図１３（Ｃ）に示すように、株式画像５８１がカード画像５７１に重なる位置に移動することにともない、対象とする有価証券を売買する意思を確認する売買確認５９１が表示される。そして、ユーザＵＲから売却する指示を受け付ける（図示の例においては「ＹＥＳ」が選択される）ことにより、図１３（Ｄ）に示すように、株式画像５８１が売却される。このとき、売却額に応じて、カード画像５７１の決済可能額が増額され、株式画像５８１の評価額が減額される。また、図示の例においては、売却後の資金は証券口座に保有される。
【0127】
なお、詳細な説明は省略するが、決済操作画５７０によって有価証券の購入することも可能である。さらに説明をすると、カード画像５７１に対してユーザＵＲが所定の操作をすることで、有価証券が購入される。例えば、カード画像５７１を購入したい有価証券の画像（例えば、投信画像５８３）に重なる位置に移動させることで、その有価証券を購入することが可能である。このことにより、ユーザＵＲによる有価証券の購入が簡易となる。なお、この有価証券の購入には、バリューを用いてもよい。また、有価証券の購入には、チャージ残高（マネー）よりもバリューを優先して利用してもよい。
【0128】
上記では種々の実施形態および変形例を説明したが、これらの実施形態や変形例同士を組み合わせて構成してももちろんよい。
また、本開示は上記の実施形態に何ら限定されるものではなく、本開示の要旨を逸脱しない範囲で種々の形態で実施することができる。
また、本開示は上記の実施形態に何ら限定されるものではなく、本開示の要旨を逸脱しない範囲で種々の形態で実施することができる。
【0129】
決済システム１は、システムの一例である。決済サーバ１００は、サーバの一例である。ウォレット決済画像５２３が示す決済可能額は、第１決済可能額の一例である。証券決済画像５２５が示す決済可能額は、第２決済可能額の一例である。
【符号の説明】
【0130】
１…決済システム、１００…決済サーバ、１３０…決済処理部、１５０…証券管理部、３００…店舗端末、５００…ユーザ端末、７００…銀行サーバ、９００…証券サーバ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11-1】
【図11-2】
【図12】
【図13】