知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023083377
(43)【公開日】2023-06-15
(54)【発明の名称】方法、サーバ、プログラム、およびシステム
(51)【国際特許分類】
G06Q 20/36 20120101AFI20230608BHJP
【ＦＩ】
G06Q20/36
【審査請求】未請求
【請求項の数】13
【出願形態】ＯＬ
【公開請求】
(21)【出願番号】P 2023063789
(22)【出願日】2023-04-10
(71)【出願人】
【識別番号】516075204
【氏名又は名称】株式会社Ｋｙａｓｈ
(74)【代理人】
【識別番号】100128886
【弁理士】
【氏名又は名称】横田 裕弘
(72)【発明者】
【氏名】鷹取 真一
(72)【発明者】
【氏名】上田 太暉
(57)【要約】
【課題】ウォレットへの入金方法を増やす。
【解決手段】本発明の方法は、ユーザの資金を用いてウォレットに入金するユーザ入金と、ユーザの資金以外を用いてウォレットに入金するユーザ外入金と、を実行する方法であって、ユーザ外入金は、第１入金と、第１入金とは異なる第２入金との少なくとも一方を用いて実行する。
【選択図】図１
【解決手段】本発明の方法は、ユーザの資金を用いてウォレットに入金するユーザ入金と、ユーザの資金以外を用いてウォレットに入金するユーザ外入金と、を実行する方法であって、ユーザ外入金は、第１入金と、第１入金とは異なる第２入金との少なくとも一方を用いて実行する。
【選択図】図１
【特許請求の範囲】
【請求項1】
ユーザの資金を用いてウォレットに入金するユーザ入金と、
ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、
を実行する方法であって、
前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、
方法。
ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、
を実行する方法であって、
前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、
方法。
【請求項2】
前記第１入金の受付期間は、前記第２入金の前記受付期間よりも長い、
請求項１記載の方法。
請求項１記載の方法。
【請求項3】
前記第１入金は前記ユーザの信用情報に基づき実行され、前記第２入金は前記ユーザへの入金予定に基づき実行される、
請求項１記載の方法。
請求項１記載の方法。
【請求項4】
前記第１入金は前記ウォレットの利用履歴に基づき実行され、前記第２入金は前記ウォレットへの入金予定に基づき実行される、
請求項１記載の方法。
請求項１記載の方法。
【請求項5】
前記ウォレットの残高を表示し、
前記ユーザ外入金による前記残高と、前記ユーザ入金による前記残高とを、区別可能に表示する、
請求項１から４いずれかに記載の方法。
前記ユーザ外入金による前記残高と、前記ユーザ入金による前記残高とを、区別可能に表示する、
請求項１から４いずれかに記載の方法。
【請求項6】
前記ユーザが決済をする際に、前記ユーザ外入金による前記残高より、前記ユーザ入金による残高を優先して決済に利用する、
請求項５記載の方法。
請求項５記載の方法。
【請求項7】
前記ユーザ外入金による残高および前記ユーザ入金による残高を図形によって表示領域に表示し、前記表示領域における前記図形を操作する指示により、前記ユーザ入金による残高により前記ユーザ外入金による残高を返済する、
請求項５記載の方法。
請求項５記載の方法。
【請求項8】
前記前記第２入金が実行された後、前記入金予定に基づく入金が実行される場合、
前記入金予定の額と前記第２入金により入金された額との差額を、前記ウォレットへ入金する、
請求項３に記載の方法。
前記入金予定の額と前記第２入金により入金された額との差額を、前記ウォレットへ入金する、
請求項３に記載の方法。
【請求項9】
前記ウォレットは、現金で出金が可能な残高である第１残高と、現金で出金が不可能な残高である第２残高とを有し、
前記第２入金は、入金予定に基づき前記第２残高として入金され、
前記入金予定の入金が実行されると、前記第２残高から前記第１残高に置換される、
請求項１から４いずれかに記載の方法。
前記第２入金は、入金予定に基づき前記第２残高として入金され、
前記入金予定の入金が実行されると、前記第２残高から前記第１残高に置換される、
請求項１から４いずれかに記載の方法。
【請求項10】
前記第２入金は、自動的に返済され、
前記第１入金は、ユーザからの指示により返済される請求項１から４いずれかに記載の方法。
前記第１入金は、ユーザからの指示により返済される請求項１から４いずれかに記載の方法。
【請求項11】
ユーザの資金を用いてウォレットに入金するユーザ入金と、
ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、
を実行するサーバであって、
前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、
サーバ。
ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、
を実行するサーバであって、
前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、
サーバ。
【請求項12】
コンピュータに、
ユーザの資金を用いてウォレットに入金するユーザ入金と、
ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、
を実行させあるプログラムであって、
前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、
プログラム。
ユーザの資金を用いてウォレットに入金するユーザ入金と、
ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、
を実行させあるプログラムであって、
前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、
プログラム。
【請求項13】
ユーザが操作する端末と、
前記端末とネットワークを介して通信可能なサーバと、
を有するシステムであって、
前記サーバが、
ユーザの資金を用いてウォレットに入金するユーザ入金と、
ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、
を実行し、
前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、
システム。
前記端末とネットワークを介して通信可能なサーバと、
を有するシステムであって、
前記サーバが、
ユーザの資金を用いてウォレットに入金するユーザ入金と、
ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、
を実行し、
前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、
システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、方法、サーバ、プログラム、およびシステムに関する。
【背景技術】
【0002】
特許文献１には、以下のようなサーバ装置が記載されている。このサーバ装置は、通信ネットワークを介して雇用者端末及び利用者端末の夫々と接続される情報処理システムにおいて、労働者から給与相当額の前払いの申請として、定期的に到来する支払い時期の指定を含む申請を受け付け、当該申請に基づいて、支払い時期に応じて定められる支払い日を特定し、当該支払い日の情報を含む事前データを生成して記録し、当該支払い日に、記録されている事前データに基づいて申請に応じた支払い処理を実行する。労働者に給与相当額の前払いとして支払い可能な上限額を労働者の労働時間の実績を含む勤務データに基づいて算出することが開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０２２－１０２７２７号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、現金に代わり、ユーザが所有する資金と関連づけられたウォレットなどの残高を用いて、決済、入出金、送金、投資等の為替行為をすることが近年活発に行われている。このウォレット残高を決済等の為替行為に利用する際の、ユーザの利便性を向上させることが求められていた。
【0005】
そこで、本発明は、ウォレット残高を決済等の為替行為に利用する際の、ユーザの利便性を向上させることを目的とする。
【課題を解決するための手段】
【0006】
かかる目的のもと、本明細書に開示される技術は、ユーザの資金を用いてウォレットに入金するユーザ入金と、ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、を実行する方法であって、前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、方法である。
また、前記第１入金の受付期間は、前記第２入金の前記受付期間よりも長いとよい。
また、前記第１入金は前記ユーザの信用情報に基づき実行され、前記第２入金は前記ユーザへの入金予定に基づき実行されるとよい。
また、前記第１入金は前記ウォレットの利用履歴に基づき実行され、前記第２入金は前記ウォレットへの入金予定に基づき実行されるとよい。
また、前記ウォレットの残高を表示し、前記ユーザ外入金による前記残高と、前記ユーザ入金による前記残高とを、区別可能に表示するとよい。
また、前記ユーザが決済をする際に、前記ユーザ外入金による前記残高より、前記ユーザ入金による残高を優先して決済に利用するとよい。
また、前記ユーザ外入金による残高および前記ユーザ入金による残高を図形によって表示領域に表示し、前記表示領域における前記図形を操作する指示により、前記ユーザ入金による残高により前記ユーザ外入金による残高を返済するとよい。
また、前記前記第２入金が実行された後、前記入金予定に基づく入金が実行される場合、前記入金予定の額と前記第２入金により入金された額との差額を、前記ウォレットへ入金するとよい。
また、前記ウォレットは、現金で出金が可能な残高である第１残高と、現金で出金が不可能な残高である第２残高とを有し、前記第２入金は、入金予定に基づき前記第２残高として入金され、前記入金予定の入金が実行されると、前記第２残高から前記第１残高に置換されるとよい。
また、前記第２入金は、自動的に返済され、前記第１入金は、ユーザからの指示により返済されるとよい。
また、前記第１入金の受付期間は、前記第２入金の前記受付期間よりも長いとよい。
また、前記第１入金は前記ユーザの信用情報に基づき実行され、前記第２入金は前記ユーザへの入金予定に基づき実行されるとよい。
また、前記第１入金は前記ウォレットの利用履歴に基づき実行され、前記第２入金は前記ウォレットへの入金予定に基づき実行されるとよい。
また、前記ウォレットの残高を表示し、前記ユーザ外入金による前記残高と、前記ユーザ入金による前記残高とを、区別可能に表示するとよい。
また、前記ユーザが決済をする際に、前記ユーザ外入金による前記残高より、前記ユーザ入金による残高を優先して決済に利用するとよい。
また、前記ユーザ外入金による残高および前記ユーザ入金による残高を図形によって表示領域に表示し、前記表示領域における前記図形を操作する指示により、前記ユーザ入金による残高により前記ユーザ外入金による残高を返済するとよい。
また、前記前記第２入金が実行された後、前記入金予定に基づく入金が実行される場合、前記入金予定の額と前記第２入金により入金された額との差額を、前記ウォレットへ入金するとよい。
また、前記ウォレットは、現金で出金が可能な残高である第１残高と、現金で出金が不可能な残高である第２残高とを有し、前記第２入金は、入金予定に基づき前記第２残高として入金され、前記入金予定の入金が実行されると、前記第２残高から前記第１残高に置換されるとよい。
また、前記第２入金は、自動的に返済され、前記第１入金は、ユーザからの指示により返済されるとよい。
【0007】
さらに他の観点から捉えると、本明細書に開示される技術は、ユーザの資金を用いてウォレットに入金するユーザ入金と、ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、を実行するサーバであって、前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、サーバである。
【0008】
さらに他の観点から捉えると、本明細書に開示される技術は、コンピュータに、ユーザの資金を用いてウォレットに入金するユーザ入金と、ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、を実行するプログラムであって、前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、プログラムである。
【0009】
さらに他の観点から捉えると、本明細書に開示される技術は、ユーザが操作する端末と、前記端末とネットワークを介して通信可能なサーバと、を有するシステムであって、前記サーバが、ユーザの資金を用いてウォレットに入金するユーザ入金と、ユーザの資金以外を用いて前記ウォレットに入金するユーザ外入金と、を実行し、前記ユーザ外入金は、第１入金と、前記第１入金とは異なる第２入金との少なくとも一方を用いて実行する、システムである。
【発明の効果】
【0010】
本発明によれば、ウォレット残高を決済等の為替行為に利用する際の、ユーザの利便性を向上させることが可能な方法などが提供される。
【図面の簡単な説明】
【0011】
【図1】本実施の形態が適用される決済システムの全体構成例を示した図である。
【図2】決済サーバのハードウェア構成例を示した図である。
【図3】ユーザ端末のハードウェア構成例を示した図である。
【図4】決済サーバの構成例を説明するための図である。
【図5】ウォレットＤＢに記憶されるテーブルを説明するための図である。
【図6】第１入金および第２入金の受付時期を説明するための図である。
【図7】第１入金および第２入金の相違点を説明するための図である。
【図8】他者資金による入金処理を示すフローチャートである。
【図9】入金可能額算出処理を示すフローチャートである。
【図10】決済システムの決済処理を示すフローチャートである。
【図11】決済システムの自動返済処理を示すフローチャートである。
【図12】決済システムの手動入力返済処理を示すフローチャートである。
【図13】決済システムの店舗支払返済処理を示すフローチャートである。
【図14】操作画像を示す図である。
【図15】手動入力返済画像について説明をする図である。
【発明を実施するための形態】
【0012】
以下、添付図面を参照して、本発明の他の実施の形態について説明する。
＜決済システム１＞
図１は、本実施の形態が適用される決済システム１の全体構成例を示した図である。
図１に示すように、決済システム１は、決済サーバ１００と、店舗端末３００と、ユーザ端末５００と、雇用会社サーバ６００と、第１銀行サーバ７００と、第２銀行サーバ９００とを有する。
＜決済システム１＞
図１は、本実施の形態が適用される決済システム１の全体構成例を示した図である。
図１に示すように、決済システム１は、決済サーバ１００と、店舗端末３００と、ユーザ端末５００と、雇用会社サーバ６００と、第１銀行サーバ７００と、第２銀行サーバ９００とを有する。
【0013】
決済サーバ１００は、決済サービス会社ＫＳが管理するコンピュータ装置によって構成される。この決済サーバ１００は、決済システム１におけるサーバとして機能する。本実施の形態の決済サーバ１００は、ユーザ端末５００を操作するユーザＵＲが決済を行うために必要な各種制御を実行する。図示の例における決済サーバ１００は、ユーザＵＲが店舗ＳＨなどにおいて商品の購入やサービスの利用をすることにともなう決済を支援する。また、決済サーバ１００は、ユーザＵＲの雇用主である雇用会社ＥＭからユーザＵＲに支払われる給与に関する情報を利用して、ユーザＵＲの決済を支援する。
【0014】
店舗端末３００は、商品の販売やサービスの提供を行う店舗ＳＨに設けられる。店舗端末３００は、例えばレジスター、スマートフォン、ノート型コンピュータ、デスクトップ型コンピュータ、タブレット型コンピュータなどのコンピュータ装置である。この店舗端末３００は、ユーザＵＲが操作するユーザ端末５００からクレジットカード情報を取得することで、ユーザＵＲからの支払いを受ける。
【0015】
ユーザ端末５００は、商品・サービスの購入・利用をするユーザＵＲによって操作される。ユーザ端末５００は、例えばスマートフォン、ノート型コンピュータ、デスクトップ型コンピュータ、タブレット型コンピュータ、ウェアラブルデバイス、あるいは携帯電話などのコンピュータ装置によって構成される。図示の例のユーザ端末５００は、スマートフォンである。
【0016】
ユーザ端末５００は、決済システム１において決済処理を支援するアプリケーションプログラムがインストールされている。このアプリケーションプログラムは、決済サーバ１００と通信してユーザＵＲの決済可能額情報などを取得し、ユーザＵＲの決済を支援する機能を有する。図示の例におけるアプリケーションプログラムは、決済サーバ１００を介して後述するユーザＵＲのウォレットに出入金をすることが可能である。付言すると、アプリケーションプログラムは、ユーザＵＲが決済や出入金を行う際のインターフェイスとして機能する。なお、以下の説明においては、このアプリケーションプログラムを、「決済アプリ」とする場合がある。
【0017】
雇用会社サーバ６００は、ユーザＵＲの雇用主である雇用会社ＥＭが管理するコンピュータ装置によって構成される。雇用会社ＥＭは、ユーザＵＲに対して給与の支払いを行う。ここで、給与は、雇用会社ＥＭから従業員であるユーザＵＲへ支払われる労働の対価としての金銭である。この給与は、基本給、賞与および各種手当を含む。ここで、各種手当は、例えば時間外手当、扶養手当、通勤手当、住宅手当、役職手当、資格手当を含む。
【0018】
第１銀行サーバ７００は、第１銀行ＢＫ１が管理するコンピュータ装置によって構成される。第１銀行ＢＫ１は、金融機関の一例である。第１銀行ＢＫ１は、雇用会社ＥＭの指示に従い、ユーザＵＲの口座に給与の振り込みを行う。すなわち、第１銀行ＢＫ１は振込元銀行である。
【0019】
第２銀行サーバ９００は、第２銀行ＢＫ２が管理するコンピュータ装置によって構成される。第２銀行ＢＫ２は、金融機関の一例である。第２銀行ＢＫ２は、ユーザＵＲの給与の受け取り（着金）を行う。すなわち、第２銀行ＢＫ２は、振込先銀行である。
【0020】
決済サーバ１００、店舗端末３００、ユーザ端末５００、雇用会社サーバ６００、第１銀行サーバ７００、および第２銀行サーバ９００は、ネットワーク（不図示）を介して互いに接続されている。ネットワークは、装置間のデータ交換に用いられる通信ネットワークである。図示のネットワークは、インターネットにより構成されるが、特に限定されない。ネットワークは、例えばＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）であってもよい。また、ネットワークの通信回線は、有線か無線かを問わず、これらを併用してもよい。また、図１においては、決済サーバ１００、店舗端末３００、ユーザ端末５００、雇用会社サーバ６００、第１銀行サーバ７００、および第２銀行サーバ９００は、それぞれ１つずつ示しているが、これらは複数設けられてもよい。また、ネットワークによる各サーバについては、各サーバ間でデータをやり取りできればよく、各サーバ間にゲートウェイ装置が設けられていてもよい。
【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】
＜操作画像５１０＞
図１４は、操作画像５１０を示す図である。
次に、図１４を参照しながら、決済サーバ１００および決済アプリによってユーザ端末５００に表示される操作画像５１０について説明をする。操作画像５１０は、ユーザ端末５００を操作するユーザＵＲに決済に関する情報を表示し、ユーザＵＲからの指示を受け付ける画像である。
図１４は、操作画像５１０を示す図である。
次に、図１４を参照しながら、決済サーバ１００および決済アプリによってユーザ端末５００に表示される操作画像５１０について説明をする。操作画像５１０は、ユーザ端末５００を操作するユーザＵＲに決済に関する情報を表示し、ユーザＵＲからの指示を受け付ける画像である。
【0131】
図１４（Ａ）に示すように、図示の例における操作画像５１０は、クレジットカードを模した画像であるカード画像５１１と、ユーザＵＲの決済可能額を示す決済可能額画像５１２と、決済システム１を利用することでユーザＵＲが取得したポイントを示すポイント画像５１３と、ユーザＵＲからの入出金の指示を受け付ける入出金指示画像５１５と、決済システム１を利用した履歴である履歴画像５１７とを含む。
【0132】
ここで、図示のカード画像５１１は、ユーザＵＲに割り当てられたクレジットカードのクレジット番号を表示する。このクレジット番号を店舗端末３００が取得するなどすることにより、上記決済処理が開始される。
【0133】
また、決済可能額画像５１２に示されるユーザＵＲの決済可能額は、ユーザＵＲのウォレット決済残高である。ウォレット決済残高は、ユーザＵＲが決済口座に所有するマネーとバリューとの合算である（図５（Ｂ）参照）。
【0134】
ここで、ユーザＵＲが決済可能額画像５１２を選択するなど所定の操作をすることにより、図１４（Ｂ）に示すように、決済可能額の内訳を示す決済可能額内訳画像５１９が表示される。この決済可能額内訳画像５１９は、決済口座（ウォレット）におけるマネーの残高を示すマネー残高画像５２１と、決済口座（ウォレット）におけるバリューの残高を示すバリュー残高画像５２３とを含む。
【0135】
図示のバリュー残高画像５２３は、バリューの内訳を示す。このバリューの内訳は、決済口座（ウォレット）ＴＢ（図５（Ｂ）参照）に示すバリュー内訳に基づき表示される。さらに説明をすると、バリュー残高画像５２３は、自己資金残高、第１入金、第２入金の各々の金額を示す画像を含む。バリュー残高画像５２３を表示することにより、決済口座（ウォレット）の資金のうち、返済が必要な金額などの詳細情報をユーザＵＲが確認することが可能となる。
【0136】
なお、図示のバリュー残高画像５２３とは異なり、自己資金残高と第１入金とを合算して表示し、第２入金の金額が表示される態様であってもよい。すなわち、第２入金の金額と、バリューにおける第２入金以外の金額が表示される態様であってもよい。
【0137】
このように、ユーザＵＲは、自己資金残高と他社資金残高とを容易に区別することができる。また、ユーザＵＲは、他社資金残高のうち、第１入金残高と第２入金残高とを容易に区別することができる。すなわち、ユーザＵＲは異なる特性を持つ残高を容易に把握しつつ、決済に利用することができる。
【0138】
＜手動入力返済画像５５０＞
図１５は、手動入力返済画像５５０について説明をする図である。
上記のように、決済システム１においては、手動入力返済が可能である。そして、上記のように、手動入力返済においては、ユーザＵＲから返済する金額である返済額の指定および返済要求を受け付ける（図１２におけるＳ１１０４およびＳ１１０５参照）。
図１５は、手動入力返済画像５５０について説明をする図である。
上記のように、決済システム１においては、手動入力返済が可能である。そして、上記のように、手動入力返済においては、ユーザＵＲから返済する金額である返済額の指定および返済要求を受け付ける（図１２におけるＳ１１０４およびＳ１１０５参照）。
【0139】
ここで、返済額の指定は、図１５（Ａ）に示す手動入力返済画像５５０をユーザ端末５００に表示することによって行ってもよい。図１５（Ａ）に示す手動入力返済画像５５０は、ユーザＵＲの決済口座（ウォレット）における残高の内訳を示す画像を含む。図示の例においては、手動入力返済画像５５０は、マネーを示すマネー画像５５１と、第１入金を示す第１入金画像５５３を含む。
【0140】
マネー画像５５１および第１入金画像５５３は、棒グラフを構成する。さらに説明をすると、マネー画像５５１および第１入金画像５５３は、各々長方形の画像であり、上下方向に並べて表示される。そして、マネー画像５５１および第１入金画像５５３の上下方向の長さは各残高の大きさを示す。
【0141】
そして、手動入力返済画像５５０をユーザＵＲが操作することで、返済要求が出力される。例えば、ユーザＵＲの操作を受け付けることでマネー画像５５１が移動し（図１５（Ｂ）参照）、第１入金画像５５３に重なる位置に配置される（図１５（Ｃ）および（Ｄ）参照）。
【0142】
このとき、マネー画像５５１が第１入金画像５５３に重なる長さＬ１によって、返済額が変化する。すなわち、長さＬ１が大きくなるほど返済額が大きくなる。このことにより、ユーザＵＲが視覚的に把握しながら返済額の指示を入力することができる。
【0143】
そして、マネー画像５５１の位置が定まると、返済実行をユーザＵＲに確認する確認画像５５５が表示される（図１５（Ｅ）参照）。図示の例においては、確認画像５５５に含まれる「はい」の画像が選択されることでユーザＵＲからの指示を受け付けると、ユーザ端末５００が決済サーバ１００に返済要求を出力する。そして、返済処理が実行されると、返済処理が完了したことを示す完了画像５５７と、返済後のマネーを示すマネー画像５５９とが表示される。
【0144】
ここで、返済処理が完了した後に表示されるマネー画像５５９は、返済処理が完了する前に表示されるマネー画像５５１よりも長さが短い。このマネー画像５５１からマネー画像５５９への長さの変化により、ユーザＵＲは、返済処理によりマネーの残高が減少したことを視覚的に把握することができる。
【0145】
なお、図１５に示すような手動入力返済は第２入金にも適用可能である。具体的には、例えば、給与振込前に、手動入力返済により第２入金の返済を行ってもよい。また、自動返済が実行されない場合において、第２入金を図１５に示すような手動入力返済を受け付け可能としてもよい。
【0146】
また、図１５においては、マネーでバリューを返済することを説明したが、バリューでバリューを返済してもよい。さらに説明をすると、例えば自己資金残高のバリューを示す自己資金画像（不図示）を表示してもよい。そして、自己資金画像を第１入金画像５５３に重ねる位置に移動させるなど、ユーザＵＲが所定の操作をすることによりバリューの返済を実行してもよい。また、第１入金画像５５３と第２入金画像（不図示）とを並べて表示し、第２入金画像（不図示）を第１入金画像５５３に移動させるなどユーザＵＲが所定の操作をすることで、第２入金で第１入金を返済してもよい。一方、第１入金画像５５３を第２入金画像（不図示）に移動させるなどユーザＵＲが所定の操作をしたとしてもこの操作を受け付けず、第２入金を第１入金で返済できない態様としてもよい。
【0147】
＜変形例＞
上記の例においては、受領予定データを用いて、第２入金を実行することを説明した。この第２入金は、日付指定の入金依頼を受けていてその入金依頼の入金前に実行される入金である。上記の受領予定データは、振込実行前に送信される振込内容を示すデータの一例であって、受領予定データ以外の振込データであってもよい。例えば、ユーザＵＲが受け取りを予定している売上金の振込データに基づいて、第２入金を実行してもよい。また、給与振込あるいは賞与振込という摘要の振込データに対して第２入金を可能とし、それ以外の適用の振り込みデータは第２入金を制限する（不可とする）態様でもよい。
上記の例においては、受領予定データを用いて、第２入金を実行することを説明した。この第２入金は、日付指定の入金依頼を受けていてその入金依頼の入金前に実行される入金である。上記の受領予定データは、振込実行前に送信される振込内容を示すデータの一例であって、受領予定データ以外の振込データであってもよい。例えば、ユーザＵＲが受け取りを予定している売上金の振込データに基づいて、第２入金を実行してもよい。また、給与振込あるいは賞与振込という摘要の振込データに対して第２入金を可能とし、それ以外の適用の振り込みデータは第２入金を制限する（不可とする）態様でもよい。
【0148】
また、上記の例においては、個人の信用情報の一例として、給与履歴データを用いて、第１入金を実行することを説明した。ここで、給与履歴データを用いて第１入金を実行し、受領予定データを用いて第２入金を実行することで、２段階の給与前借りが可能となる。なお、給与履歴データは、ウォレット決済残高の履歴の一例であって、給与履歴データ以外の履歴データであってもよい。例えば、決済の履歴、給与以外の入金の履歴など、ウォレットの利用履歴を用いて、第１入金を実行してもよい。さらに説明をすると、例えば直近６か月など所定期間内の月ごとの支払額の平均の１０％を上限として、第１入金を実行してもよい。
【0149】
上記の例においては、第１入金および第２入金を実行した後に、商品の購入などにおける決済を実行することを説明したが、これに限定されない。例えば、商品の購入などにおける決済を実行する処理を開始した後、ウォレット残高が不足する場合に、第１入金および第２入金を実行する態様でもよい。この場合、不足分に相当する金額の入金が完了した場合には決済処理を行い、入金が完了しない場合には、決済処理を行わない。この態様においては、決済口座の残金に関わらず、ユーザＵＲが決済をすることが可能となる。
【0150】
ここで、例えば、商品の購入などにおける決済を行う際に残高が不足した際に、第１入金および第２入金、すなわち前借を案内する画像がユーザ端末５００に表示されてもよい。そして、この画像を介してユーザＵＲから入金要求を受けて、第１入金および第２入金が実行されてもよい。
【0151】
また、商品の購入などにおける決済を行う際に残高が不足した際に、自動的に第１入金または第２入金から少なくとも不足分を入金し、決済を実行してもよい。この態様においては、ユーザＵＲから予め第１入金または第２入金を許可する指示を受け付けてもよい。また、この態様においては、第２入金が可能であれば第２入金を優先して入金する。
【0152】
また、第１入金について、入金時に手数料を徴収している場合は、第１入金は通常のバリューと同じ優先順位で利用してもよい。また、第２入金について、利用分だけの手数料徴収としている場合は、第２入金は利用優先順位が低くなるよう設定してもよい。
【0153】
上記の例においては、第１入金および第２入金はバリューとして入金されることを説明したが、これに限定されない。例えば、第１入金および第２入金はマネーとして入金されてもよい。また、バリューおよびマネーを組み合わせて入金される態様でもよい。例えば、一部をバリューとして入金し、残りをマネーとして入金する態様でもよい。
【0154】
さて、給与振込が実行されると、上記のようにマネーで決済口座（ウォレット）に入金される。そして、このマネーはＡＴＭなどから出金可能である。例えば、出金する際の手数料は１回無料とすることがあるが、この無料とする起算を月初から月末の間で１回とするのではなく、給与の受け取りから所定期間・所定回数について無料としてもよい。なお、第２入金がマネーで決済口座（ウォレット）に入金される態様においては、第２入金の実行を起算としてもよい。この例における決済サーバ１００は、以下のようなサーバとして捉えることができる。すなわち、決済サーバ１００は、ＡＴＭからの出金要求を受け、決済口座（ウォレット）へ給与受け取り残高が反映された日を取得し、出金要求が反映された日から所定期間・所定回数であれば、出金手数料を無料とするサーバである。
【0155】
また、第１入金および第２入金を返済する資金を異ならせてもよい。例えば、第１入金は、ウォレット残高から返済できずに、例えばＡＴＭや店舗ＳＨでの返済のみを可能とする。一方、第２入金は、ＡＴＭや店舗ＳＨでの返済に加えて、ウォレット残高からの返済を可能としてもよい。
【0156】
また、上記の例においては、他者資金入金として第１入金および第２入金が含まれることを説明したが、これに限定されない。例えば、他者資金入金として、第１入金および第２入金以外に、第１入金および第２入金とは異なる条件で実行される第３入金あるいは第４入金以上が含まれてもよい。
【0157】
なお、上記のように、第２入金が、ユーザＵＲの決済ウォレットにマネーとして入金される態様でもよい。なお、この態様においては、上記図５（Ｂ）を参照しながら説明をしたようにバリュー内訳に第２入金を含めて管理しなくてよい。この態様においては、入出金処理部１１０によるバリューに関する処理が簡素化される。また、この態様においては、図１１で説明した自動返済処理の返済処理（Ｓ１００３）が以下のように実行される。すなわち、入出金処理部１１０は、ユーザＵＲの借入残高ＴＢの第２入金借入残高を読み込む。次に、入出金処理部１１０は、振込受領通知からユーザＵＲに対する給与の振込金額を読み込む。そして、入出金処理部１１０は、給与の振込金額と第２入金借入残高との差額を算出する。また、入出金処理部１１０は、この差額をユーザＵＲのマネー残高に反映（入金）させる。
【0158】
また、上記の説明においては第２銀行ＢＫ２（図１参照）を介して給与を受け取る場合について説明したが、第２銀行ＢＫ２を介さず直接、第１銀行ＢＫ１（図１参照）からユーザＵＲの決済ウォレットに入金されてもよい。このユーザＵＲの決済ウォレットに直接入金する態様（直接入金態様）においては、決済サービス会社ＫＳが上記第２銀行ＢＫ２の機能を果たす。さらに説明をすると、上記実施形態における上記第１銀行サーバ７００が出力する振込予告が、直接入金態様においては、上記第１銀行サーバ７００から決済サーバ１００へ出力する受領予告として取り扱われる。また、上記実施形態における第１銀行ＢＫ１によって実行される給与振込が、直接入金態様においては、第１銀行ＢＫ１からユーザＵＲの決済ウォレットの入金、および第１銀行サーバ７００から決済サーバ１００へ出力する受領通知として取り扱われる。
【0159】
上記では種々の実施形態および変形例を説明したが、これらの実施形態や変形例同士を組み合わせて構成してももちろんよい。
また、本開示は上記の実施形態に何ら限定されるものではなく、本開示の要旨を逸脱しない範囲で種々の形態で実施することができる。
また、本開示は上記の実施形態に何ら限定されるものではなく、本開示の要旨を逸脱しない範囲で種々の形態で実施することができる。
【0160】
決済システム１は、システムの一例である。決済サーバ１００は、サーバの一例である。ユーザ端末５００は、端末の一例である。手動入力返済画像５５０は、図形の一例である。
【符号の説明】
【0161】
１…決済システム、１００…決済サーバ、１３０…決済処理部、３００…店舗端末、５００…ユーザ端末、７００…第１銀行サーバ、９００…第２銀行サーバ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】