JP7497833B2 - 法定通貨バリュー、電子マネー、その他ポイント等の各種バリューのチャージ、入金方法及びシステム - Google Patents

Description

本発明は、各種バリューのチャージ方法及びシステムに関する。

従来、法定通貨バリュー、電子マネー、その他ポイント等の金銭的価値を有する無形資産（以下、「バリュー」という）による決済が普及しており、一例として、電子マネー決済の一般的な仕組みにおいて、利用者は、所定の方法により、一定の金額相当の電子マネーを事前または即座にチャージし、電子マネー利用者である加盟店に渡すことで、その加盟店が販売する商品またはサービスを購入し、加盟店舗は、電子マネー発行者から売上金相当の電子マネーと引き換えに現金等の支払を受ける。

電子マネーのチャージ方法として、現金によるチャージのほか、クレジットカードや銀行口座等の支払能力を担保することが可能な対象と連動したチャージ方法が挙げられる（例えば、特許文献１）。また、複数のチャージ方法（ファンディングソース）を利用者が選択肢の中から選択できる方法も開示されている（例えば、特許文献２）。

特許６４７３４８７号公報 特開２０１８-１６０２６７号公報

しかしながら、電子マネーを始めとするバリューの決済カード又は決済が可能なコード等の決済媒体の提供者が、個人または法人等の利用者に決済媒体を提供する場合において、事前に提供者が提供するチャージ方法に限定され、柔軟性に乏しい。

そこで、本発明では、より柔軟なバリューのチャージ方法を提供することを目的とする。

バリューによる支払用の決済媒体を提供する媒体提供者により提供される、バリューのチャージ方法であって、利用者がバリューを介して加盟店舗または事業主が提供する商品またはサービスを購入したときに、加盟店舗または事業主端末から当該商品またはサービスの取引のオーソリ要求を受付け、前記利用者のバリューの残高を確認し、前記残高が前記商品またはサービスの購入金額を下回るときに、前記利用者が予め設定したファンディングソースからバリューをチャージする。

本発明によれば、より柔軟なバリューのチャージ方法を提供することができる。

本発明の第一実施形態に係るチャージシステムを示すブロック構成図である。 図１のカード会社端末１００を示す機能ブロック構成図である。 図１の利用者端末２００を示す機能ブロック構成図である。 図１の店舗端末２００を示す機能ブロック構成図である。 サーバ１００に格納される利用者データの一例を示す模式図である。 サーバ１００に格納される電文データの一例を示す模式図である。 本発明の第一実施形態に係る、チャージ方法に係るフローチャートの一例である。 本発明の第一実施形態に係る、チャージ方法に係るフローチャートの変形例である。 本発明の第二実施形態に係る、チャージ方法に係るフローチャートの一例である。 本発明の第三実施形態に係る、チャージ方法に係るフローチャートの一例である。 本発明の第四実施形態に係る、チャージ方法に係るフローチャートの一例である。

以下、本発明の実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本開示の必須の構成要素であるとは限らない。

（実施形態１）
＜構成＞
図１は、本発明の第一実施形態に係るチャージシステムを示すブロック構成図である。
なお、本実施形態は、法的通貨バリュー、電子マネー及び各種ポイント等一定の金銭的価値を有するバリューに適用され、また、プリペイドカードのようなカード媒体のほか、ＱＲコード等を印字したシート媒体、ＱＲコード等を表示したＷｅｂページ等の電子媒体、Ｗｅｂサービスやアプリ等の仮想媒体等の、各種媒体提供者によって提供される決済媒体に対しても適用され得るが、本実施形態においては、説明の便宜のため、電子マネーを利用するためのプリペイドカードを発行する、カード会社の端末である、カード会社端末１００と、そのカードを利用する利用者の端末である、利用者端末２００と、商品またはサービスと引き換えにカード会社が発行する電子マネーを利用可能な加盟店舗の端末である、店舗端末３００と、利用者が電子マネーをチャージする際のチャージ元となるファンディングソースとにより構成されるシステムを例示して説明する。

カード会社は、所謂、クレジットカードやプリペイドカードのイシュアーと呼ばれ、利用者に対し、カードを発行し、与信管理を行い、プリペイドカードであれば、利用者の電子マネーの残高を管理し、利用者が商品と引き換えにプリペイドカードを加盟店舗で利用した際に、その取引のオーソリ（承認）を行う。利用者は、個人利用者または法人利用者が考えられ、また、法人の場合は、その法人が二次イシュアー（パートナー）として、さらに他の法人に対してカードを発行し、カードに自社が提供する機能を追加してサービス提供をすることも考えられる。また、利用者が法人であって、カード会社が法人カードとしてカード発行する場合は、利用者は、そのカードを従業員向けに発行し、従業員は、出張、会議及び接待等、業務に付随する用途のためにそのカードを利用することも考えられる。

また、カード会社は、所謂、バーチャルカードといわれる、利用者がスマートフォン等の携帯端末にインストールしたアプリケーションを介して表示されるプリペイドカードを発行したり、利用者からの要求に応じて、物理カードといわれる、磁気カードまたはＩＣチップを内蔵したＩＣカードを発行することもできる。一般的に、バーチャルカードは、オンラインショッピング等のオンラインにおける商品の購入等の取引に、物理カードは、実店舗における商品またはサービスの購入等の取引に際して利用される。

カード会社端末１００と、利用者端末２００、店舗端末３００及びファンディングソース４００とは、ネットワークＮＷを介して接続される。ネットワークＮＷは、インターネット、イントラネット、無線ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等により構成される。

カード会社端末１００は、例えば、ワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティングによって論理的に実現されてもよい。本実施形態においては、説明の便宜上カード会社端末として１台を例示しているが、これに限定されず、複数台であってもよい。

利用者端末２００は、例えば、パーソナルコンピュータやタブレット端末等の情報処理装置であるが、スマートフォンや携帯電話、ＰＤＡ等により構成しても良い。

店舗端末３００は、カードの加盟店に設置される端末であり、例えば、スーパー、ショッピングセンター、コンビニエンスストア等に設置されるＰＯＳ／ＣＣＴ／ＣＡＴ等の端末が考えられるが、同様の機能を備えたアプリケーションを内蔵したパーソナルコンピュータ、スマートフォン、タブレット端末等も考えられる。また、店舗に限らず、事業活動を行う事業主に設置される事業主端末にも置き換えられ得る。店舗端末３００により、加盟店の店頭において、クレジットカード、プリペイドカードおよびデビットカードの決済等の操作を行うことができる。また、店舗端末３００は、ネットワークＮＷを介して、カード会社端末１００や（図示しない）他のクレジットカード発行会社の端末と通信可能に接続される。また、ＶＩＳＡ（登録商標）等の国際ブランドのカードシステムを経由して、カード端末１００等に接続することも考えられる。

本実施形態では、システム１は、カード会社端末１００、利用者端末２００、店舗端末３００及びファンディングソース４００を有するものと説明するが、上述のように、二次イシュアー（パートナー）を利用者端末とすることもでき、また、パートナーのカード利用者が他の法人または個人となる例において、そのパートナーを本システムにおけるカード会社（カード会社端末１００）に置き換え、そのパートナーが発行するカードの利用者を本システムにおける利用者（利用者端末２００）に置き換えることもできる。パートナーがカード会社に置き換えられる場合は、元のカード会社のＡＰＩ（Application Programming Interface）を利用することも考えられる。

図２は、図１のカード会社端末１００の機能ブロック構成図である。カード会社端末１００は、通信部１１０と、記憶部１２０と、制御部１３０とを備える。

通信部１１０は、ネットワークＮＷを介して利用者端末２００及び店舗端末３００と通信を行うための通信インタフェースであり、例えばＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）等の通信規約により通信が行われる。

記憶部１２０は、各種制御処理や制御部１３０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等から構成される。また、記憶部１２０は、カード利用者が加盟店で商品またはサービスを購入した場合の取引のオーソリ（承認）や電子マネーのチャージに必要な各種データを格納する、利用者データ格納部１２１、加盟店から受信するオーソリ電文に関連するデータを格納する、電文データ格納部１２２等を有する。さらに、記憶部１２０は、利用者端末２００及び店舗端末３００と通信を行ったデータを一時的に記憶することもできる。なお、各種データを格納したデータベース（図示せず）が記憶部１２０外に構築されていてもよい。

制御部１３０は、記憶部１２０に記憶されているプログラムを実行することにより、カード会社端末１００の全体の動作を制御するものであり、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）等から構成される。制御部１３０の機能として、利用者端末２００または店舗端末３００からの指示を受け付ける要求受付部１３１と、オーソリ要求に対して承認のための処理を行う承認処理部１３２と、電子マネーのチャージに関連する処理を行う、チャージ処理部１３３と、を有する。この要求受付部１３１、承認処理部１３２、チャージ処理部１３３は、記憶部１２０に記憶されているプログラムにより起動されてコンピュータ（電子計算機）であるカード会社端末１００により実行される。

要求受付部１３１は、例えば、利用者端末２００においてインストールされるアプリケーションを介して表示されるユーザインターフェースにおいて、利用者が、例えば、利用者情報を登録したり、バーチャルまたは物理的なプリペイドカードを発行する等の所定の要求を行ったときに、利用者端末２００から通信部１１０を介して要求を受付ける。また、利用者が、例えば、加盟店でカードを使って商品またはサービスの購入を行い、店舗端末３００のリーダによって磁気カードの読み取り操作を行い、オーソリ要求を行うためにオーソリ電文を送信したときに、店舗端末３００から通信部１１０を介して要求を受付ける。

承認処理部１３２は、店舗端末３００から、特定の取引についてオーソリ要求を受付けたときに、その取引の承認を行うための所定の処理を行う。

チャージ処理１３３は、利用者端末２００からの要求により、または、自動処理によって、利用者の電子マネーのチャージ処理を行う。

図３は、図１の利用者端末２００を示す機能ブロック構成図である。利用者端末２００は、通信部２１０と、表示操作部２２０と、記憶部２３０と、制御部２４０とを備える。

通信部２１０は、ネットワークＮＷを介してカード会社端末１００と通信を行うための通信インタフェースであり、例えばＴＣＰ／ＩＰ等の通信規約により通信が行われる。

表示操作部２２０は、利用者が指示を入力し、制御部２４０からの入力データに応じてテキスト、画像等を表示するために用いられるユーザインターフェースであり、利用者端末２００がパーソナルコンピュータで構成されている場合はディスプレイとキーボードやマウスにより構成され、利用者端末２００がタブレット端末で構成されている場合はタッチパネル等から構成される。この表示操作部２２０は、記憶部２３０に記憶されているアプリケーションプログラム等の制御プログラムにより起動されてコンピュータ（電子計算機）である利用者端末２００により実行される。

記憶部２３０は、各種制御処理や制御部２４０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭやＲＯＭ等から構成される。また、記憶部２３０は、カード会社端末１００との通信内容を一時的に記憶している。

制御部２４０は、記憶部２３０に記憶されているプログラムを実行することにより、利用者端末２００の全体の動作を制御するものであり、ＣＰＵやＧＰＵ等から構成される。

なお、カード会社端末１００に利用者端末２００に記憶されているアプリケーションプログラム等の制御プログラムの機能を全部または一部備える構成としても良い。

図４は、図１の店舗端末３００を示す機能ブロック構成図である。店舗端末３００は、通信部３１０と、表示操作部３２０と、記憶部３３０と、リーダ３４０、制御部３５０とを備える。

通信部３１０は、ネットワークＮＷを介してカード会社端末１００（国際ブランドのカードシステムを経由する場合は、（図示しない）国際ブランドのカードシステムと）と通信を行うための通信インタフェースであり、例えばＴＣＰ／ＩＰ等の通信規約により通信が行われる。

表示操作部３２０は、店舗担当者が指示を入力し、制御部３５０からの入力データに応じてテキスト、画像等を表示するために用いられるユーザインターフェースであり、店舗端末３００が、ＰＯＳ／ＣＣＴ／ＣＡＴ端末であれば、ディスプレイとボタン、ポインティングデバイス、キーボード等により構成され、パーソナルコンピュータで構成されている場合はディスプレイとキーボードやマウス等により構成され、店舗端末３００がタブレット端末で構成されている場合はタッチパネル等から構成される。また、この表示操作部２２０は、記憶部２３０に記憶されているアプリケーションプログラム等の制御プログラムにより起動されてコンピュータ（電子計算機）である利用者端末２００により実行される。

記憶部３３０は、各種制御処理や制御部３５０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭやＲＯＭ等から構成される。また、記憶部２３０は、カード会社端末１００との通信内容を一時的に記憶している。

リーダ３４０は、リーダ１１４は、磁気カードリーダ、バーコードリーダ、ＩＣチップリーダ等の装置で構成され、プリペイドカード、クレジットカード、デビットカード等の情報を読み取ることができる。

制御部３５０は、記憶部３３０に記憶されているプログラムを実行することにより、店舗端末３００の全体の動作を制御するものであり、ＣＰＵやＧＰＵ等から構成される。

図５は、サーバ１００に格納される利用者データの一例を示す模式図である。

図５に示す利用者データ１０００は、プリペイドカードを利用する利用者に関連する各種データを格納する。図５において、説明の便宜上、一利用者（利用者ＩＤ「１０００１」で特定される利用者）の例を示すが、複数の利用者の情報を格納することができる。利用者に関連する各種データとして、例えば、利用者の登録情報（法人の場合は、法人名、代表者名、住所及び連絡先等、個人または従業員の場合は、氏名、生年月日、性別、住所、及び連絡先（電話番号、Ｅメールアドレス等）、また、従業員の場合は、さらに、社員ＩＤ及び所属部門等）、また、カード情報（例えば、カード番号（ＰＡＮ）、カード会員名、有効期限（ＥＸＰ）、暗証番号（ＰＩＮ）、セキュリティコード（ＣＡＶ／ＣＶＣ２／ＣＶＶ２／ＣＩＤ）、及びトラックデータ等）が含まれる。また、与信に関連する情報（例えば、電子マネー残高、利用限度額等）、利用者のファンディングソース情報（クレジットカード情報、デビットカード情報、銀行口座情報、仮想通貨口座情報及びキャリア決済用の情報等））も含まれる。

図６は、サーバ１００に格納される電文データの一例を示す模式図である。

図６に示す電文データ２０００は、オーソリ電文に格納される各種データを格納する。オーソリ電文に関連する各種データとして、例えば、加盟店で利用されたカード情報、加盟店ＩＤ、利用日時、利用金額等の情報が含まれる。

＜処理の流れ＞
図７を参照しながら、本実施形態のシステム１が実行するチャージ方法の処理の流れについて説明する。図７は、本発明の第一実施形態に係る、チャージ方法に係るフローチャートの一例である。

ここで、まず、一例として、利用者は、プリペイドカードを発行するため、自身の利用者端末２００に、アプリケーションをインストールし、アプリケーションを起動し、提供されるユーザインターフェースにおいて登録情報を登録し、カードの発行要求を行う。カードとして、バーチャルカードといわれる、利用者が利用者端末２００にインストールしたアプリケーションを介して表示されるプリペイドカード、及び／または、物理カードといわれる、プラスチックに所定のカード情報を印字した、磁気カードまたはＩＣチップを内蔵したＩＣカードを発行することができる。利用者は、事前にアプリケーションを使って、電子マネーにチャージを行うための所望のファンディングソース情報（例えば、クレジットカード情報、デビットカード情報、銀行口座情報、仮想通貨口座情報及びキャリア決済用の情報等）を設定し、事前に所定金額相当の電子マネーをチャージしておくことができる。また、コンビニエンスストア等の店舗に設置されたＡＴＭを使った現金によるチャージも可能である。電子マネーのチャージは、電子マネーのチャージ額が所定額（例えば、５万円）未満である場合、所定額単位（例えば、１０００円、５０００円、１００００円単位）でのチャージが選択的に利用可能である。

まず、ＳＱ１０１の処理として、利用者端末２００は、加盟店で商品またはサービスを購入するために、プリペイドカードを利用する。この場合、利用者が実店舗で商品またはサービスを購入する場合は、利用者は、リアルなプリペイドカードを店舗の担当者に提示する。利用者が利用者端末２００を使って、オンライン店舗等で商品またはサービスを購入する場合は、バーチャルカードに関する情報をオンライン店舗の購入画面に入力する。

ＳＱ１０２の処理として、加盟店の店舗端末３００は、商品またはサービスの決済操作を行い、商品またはサービスの取引に対するオーソリ要求をカード会社端末１００に送信する。例えば、オンライン店舗の場合、店舗端末３００は、利用者端末２００から商品またはサービスの購入要求をネットワーク経由で受付け、決済処理を行う。また、実店舗の場合、店舗端末３００は、プリペイドカードをＰＯＳ／ＣＣＴ／ＣＡＴ等の端末に読み取らせて決済処理を行う。決済処理を行うと、店舗端末３００は、オーソリ要求として、オーソリ電文及び売上データをカード会社端末１００に送信する。オーソリ電文に含まれる情報として、例えば、図６に示す情報（カード情報、加盟店ＩＤ、日時、利用金額）が含まれる。オーソリ電文として、例えば、ＩＳＯ８５８３規格に基づいてメッセージとして生成されものを送信するか、または、ＩＳＯ８５８３規格で生成されたメッセージを他の所与の形式（例えば、ＪＳＯＮ形式）に変換したものを送信することが考えられる。

続いて、ＳＱ１０３の処理として、カード会社端末１００の要求受付部１３１は、オーソリ要求を受信すると、承認処理部１３２は、利用者の、利用金額に対する電子マネーの残高を確認する。例えば、カード会社端末１００は、カード番号を基に利用者ＩＤを検索し、図５に示す利用者データ１０００のうち、対象となる利用者の電子マネーの残高を参照する。

続いて、ＳＱ１０４の処理として、カード会社端末１００の承認処理部１３２は、利用者の電子マネーの残高が、利用金額に対して同額か、上回れば、取引を承認する。（利用者の電子マネーの残高が、利用金額を下回る場合、処理は、ＳＱ１０６に進む）

続いて、ＳＱ１０５の処理として、カード会社端末１００の通信部１１０は、店舗端末３００に対して、取引承認の応答を送信する。

上記ＳＱ１０３において、利用者の電子マネーの残高が利用金額を下回る場合は、ＳＱ１０６の処理として、カード会社端末１００のチャージ処理部１３３は、図５に示す利用者データ１０００のうち、登録情報を確認し、その利用者のファンディングソースを確認する。例えば、その利用者が個人または法人事業者であれば、その個人または法人が登録するファンディングソース（例えば、クレジットカード、デビットカード、銀行口座、仮想通貨口座及びキャリア決済を含むが、これらに限られない）を特定する。また、その利用者が、二次事業者としてのパートナー企業であれば、その企業が登録するファンディングソースを確認する。また、その利用者が、法人企業において、費用負担部門との紐付けがされている場合は、その部門を特定し、その部門が登録するファンディングソースを確認する。

続いて、ＳＱ１０７において、カード会社端末１００のチャージ処理部１３３は、利用者のファンディングソースに応じて、ファンディングソースから所定額相当の電子マネーをチャージする。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネーをチャージするか、カード会社または利用者が予め設定した金額相当の電子マネーをチャージすることができる。例えば、利用者がパートナー企業であった場合、そのパートナー企業が登録するファンディングソースが銀行口座であった場合、チャージ処理部１３３は、その銀行口座から、例えば不足額分の現金を電子マネーに変換し、電子マネーを増額する処理を行う。また、例えば、利用者が企業の営業部門に属している場合、チャージ処理部１３３は、営業部門に設定されているファンディングソースから電子マネーを増額する処理を行う。

続いて、ＳＱ１０８の処理として、カード会社端末１００の承認処理部１３２は、利用者の電子マネーの残高が、利用金額に対して同額か、上回ることを確認し、取引を承認し、ＳＱ１０９の処理として、カード会社端末１００の通信部１１０は、店舗端末３００に対して、取引承認の応答を送信する。

以上のように、本実施形態のチャージ方法を通じて、カード会社は、カード利用者が設定したファンディングソースに基づいた、柔軟な電子マネーのチャージ方法を提供することができる。特に、カード会社がパートナー企業等の法人企業に対してカードを発行するときに、パートナー企業を始めとする法人企業は、独自のファンディングソースをチャージ資源として活用したいというニーズがあり、本実施形態のチャージ方法によれば、こうしたニーズに柔軟に対応することができる。

（変形例）
図８は、本発明の第一実施形態に係る、チャージ方法に係るフローチャートの変形例である。

本変形例は、図７に示したチャージ方法と基本部分は同じであるが、特に、カード利用者が、法人企業であって、その法人企業がビジネス用途に応じたファンディングソースの設定を行いたいような場合に適用可能な電子マネーのチャージ方法となる。

まず、ＳＱ２０１の処理として、利用者端末２００は、加盟店で商品またはサービスを購入するために、プリペイドカードを利用する。この場合、利用者が実店舗で商品またはサービスを購入する場合は、利用者は、リアルなプリペイドカードを店舗の担当者に提示する。利用者が利用者端末２００を使って、オンライン店舗等で商品またはサービスを購入する場合は、バーチャルカードに関する情報をオンライン店舗の購入画面に入力する。

ＳＱ２０２の処理として、加盟店の店舗端末３００は、商品またはサービスの決済操作を行い、商品またはサービスの取引に対するオーソリ要求をカード会社端末１００に送信する。例えば、オンライン店舗の場合、店舗端末３００は、利用者端末２００から商品またはサービスの購入要求をネットワーク経由で受付け、決済処理を行う。また、実店舗の場合、店舗端末３００は、プリペイドカードをＰＯＳ／ＣＣＴ／ＣＡＴ等の端末に読み取らせて決済処理を行う。決済処理を行うと、店舗端末３００は、オーソリ要求として、オーソリ電文及び売上データをカード会社端末１００に送信する。オーソリ電文に含まれる情報として、例えば、図６に示す情報（カード情報、加盟店ＩＤ、日時、利用金額）が含まれる。オーソリ電文として、例えば、ＩＳＯ８５８３規格に基づいてメッセージとして生成されものを送信するか、または、ＩＳＯ８５８３規格で生成されたメッセージを他の所与の形式（例えば、ＪＳＯＮ形式）に変換したものを送信することが考えられる。

続いて、ＳＱ２０３の処理として、カード会社端末１００の要求受付部１３１は、オーソリ要求を受信すると、承認処理部１３２は、利用者の、利用金額に対する電子マネーの残高を確認する。例えば、カード会社端末１００は、カード番号を基に利用者ＩＤを検索し、図５に示す利用者データ１０００のうち、対象となる利用者の電子マネーの残高を参照する。

続いて、ＳＱ２０４の処理として、カード会社端末１００の承認処理部１３２は、利用者の電子マネーの残高が、利用金額に対して同額か、上回れば、取引を承認する。（利用者の電子マネーの残高が、利用金額を下回る場合、処理は、ＳＱ２０６に進む）

続いて、ＳＱ２０５の処理として、カード会社端末１００の通信部１１０は、店舗端末３００に対して、取引承認の応答を送信する。

上記ＳＱ２０３において、利用者の電子マネーの残高が利用金額を下回る場合は、ＳＱ２０６の処理として、カード会社端末１００のチャージ処理部１３３は、図６に示す電文データ２０００の情報からその取引のビジネス用途及びその用途に応じたファンディングソースを確認する。例えば、電文データ２０００の加盟店ＩＤからその店舗の属性（例えば、飲食店、ホテル、タクシー等）を確認し、属性が飲食店であれば、交際費としてビジネス用途を決定する。そのうえで、そのビジネス用途に応じたファンディングソース（例えば、クレジットカード、デビットカード、銀行口座、仮想通貨口座及びキャリア決済を含むが、これらに限られない）を特定する。

続いて、ＳＱ２０７において、カード会社端末１００のチャージ処理部１３３は、ビジネス用途のファンディングソースに応じて、ファンディングソースから所定額相当の電子マネーをチャージする。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネーをチャージするか、カード会社または利用者が予め設定した金額相当の電子マネーをチャージすることができる。例えば、上記例において、交際費に対応するファンディングソースが銀行口座であった場合、チャージ処理部１３３は、その銀行口座から、例えば不足額分の現金を電子マネーに換金し、電子マネーを増額する処理を行う。

続いて、ＳＱ２０８の処理として、カード会社端末１００の承認処理部１３２は、利用者の電子マネーの残高が、利用金額に対して同額か、上回ることを確認し、取引を承認し、ＳＱ１０９の処理として、カード会社端末１００の通信部１１０は、店舗端末３００に対して、取引承認の応答を送信する。

以上のように、本変形例を通じて、カード会社は、利用者のビジネス用途に応じて設定したファンディングソースに基づき、柔軟な電子マネーのチャージ方法を提供することができる。なお、本変形例は、法人企業に限らず、個人事業主や個人のカード利用者に対しても適用することができる。

＜実施形態２＞
図９は、本発明の第二実施形態に係る、チャージ方法に係るフローチャートの一例である。本実施形態は、カード利用者となる個人または法人が、複数のファンディングソースを設定したいような場合に適用可能な電子マネー等のバリューのチャージ方法である。なお、本実施形態において、基本的なシステム構成は図１に示した第一実施形態の構成と同じであり、また、カード会社端末１００における基本的な処理は、図７に示した第一実施形態に係る処理と同じであるので、ファンディングソースからの電子マネーのチャージ処理以外の処理については説明を省略する。

まず、ＳＱ３０１の処理として、利用者の商品またはサービスの購入に係る利用金額に対する電子マネーの残高が不足している場合、カード会社端末１００のチャージ処理部１３３は、第１のファンディングソース（例えば、銀行口座）に対してチャージ要求を行う。この場合、利用者は、事前に複数のファンディングソースをチャージ用のソースとして登録することができ、優先的にチャージを実施するためのファンディングソースを設定することができる。

ＳＱ３０２の処理として、第１のファンディングソース（例えば、銀行口座）を管理する端末は、カード会社端末１００からの要求を受付け、利用者の口座残高を確認する。本処理は、カード会社端末１００が、第１のファンディングソースから利用者の残高情報を取得することで、残高確認を行うことも可能である。また、カード会社端末１００が、（不足額や設定された金額等）予め金額を決めて第１のファンディングソースにその金額相当分の電子マネーのチャージ要求を行う場合は、本ステップを省略することもできる。

続いて、ＳＱ３０３の処理として、カード会社端末１００のチャージ処理部１３３は、第１のファンディングソースから電子マネーのチャージを行う。第１のファンディングソースが銀行口座である場合には、所定金額の現金を電子マネーに変換し、チャージを行う。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネーをチャージするか、カード会社または利用者が予め設定した金額相当の電子マネーをチャージすることができる。チャージ後の電子マネーの残高が、店舗端末から照会を受けた利用金額と同額か上回ったときに、カード会社端末１００はチャージ処理を終了する。

ここで、第１のファンディングソースから電子マネーをチャージしてもなお利用金額に対する電子マネーの残高が不足している場合、ＳＱ３０４の処理として、カード会社端末１００のチャージ処理部１３３は、第２のファンディングソース（例えば、クレジットカード）に対してチャージ要求を行う。この場合、利用者は、複数のファンディングソースに対していずれのソースにチャージを要求するかの順番を設定することができる。

続いて、ＳＱ３０５の処理として、第２のファンディングソース（例えば、クレジットカード）を管理する端末は、カード会社端末１００からの要求を受付け、利用者の口座残高を確認する。本処理は、カード会社端末１００が、第２のファンディングソースから利用者の残高情報を取得することで、残高確認を行うことも可能である。ここで、例えば、クレジットカード会社に対してチャージを要求する場合は、クレジットカード会社端末は、残高確認として、利用者の利用可能額等を確認する。また、カード会社端末１００が、（不足額や設定された金額等）予め金額を決めて第２のファンディングソースにその金額相当分の電子マネーのチャージ要求を行う場合は、本ステップを省略することもできる。

続いて、ＳＱ３０６の処理として、カード会社端末１００のチャージ処理部１３３は、第２のファンディングソースから電子マネーのチャージを行う。第２のファンディングソースがクレジットカードである場合には、カード会社端末１００のチャージ処理部１３３は、所定金額相当の電子マネーのチャージを行い、金額情報をクレジットカード会社端末に送信を行う。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネーをチャージするか、カード会社または利用者が予め設定した金額相当の電子マネーをチャージすることができる。チャージ後の電子マネーの残高が、店舗端末から照会を受けた利用金額と同額か上回ったときに、カード会社端末１００はチャージ処理を終了する。なお利用金額に対する電子マネーの残高が不足している場合、さらに別のファンディングソースが設定されている場合には、カード会社端末１００は、そのファンディングソースにチャージ要求を行うか、または、取引の非承認の通知を店舗端末に対して送信する。

以上のように、本実施形態を通じて、カード会社は、利用者に対し、さらに柔軟に電子マネーのチャージ方法を提供することができる。

＜実施形態３＞
図１０は、本発明の第三実施形態に係る、チャージ方法に係るフローチャートの一例である。本実施形態は、カード利用者となる個人または法人が、複数のファンディングソースを設定したいような場合に適用可能な電子マネー等のバリューのチャージ方法の他の例である。なお、本実施形態において、基本的なシステム構成は図１に示した第一実施形態の構成と同じであり、また、カード会社端末１００における基本的な処理は、図７に示した第一実施形態に係る処理と同じであるので、ファンディングソースからの電子マネーのチャージ処理以外の処理については説明を省略する。

まず、ＳＱ４０１の処理として、利用者の商品またはサービスの購入に係る利用金額に対する電子マネーの残高が不足している場合、カード会社端末１００のチャージ処理部１３３は、予め設定されている複数のファンディングソースについて、相対的に優先度の高い第１のファンディングソース（例えば、銀行口座）と、優先度の低い第２のファンディングソース（例えば、他の銀行口座）を設定しておき、また、これらのファンディングソースの残高を確認する。そして、第１のファンディングソースからチャージする金額と、第２のファンディングソースからチャージする金額を、一定割合またはその他の基準に基づいて決め、かつ、両ファンディングソースからのチャージ額の合計が不足金額と同じか、または、上回る金額となるように決めておくことができる。

続いて、ＳＱ４０２の処理として、カード会社端末１００のチャージ処理部１３３は、第１のファンディングソース（例えば、銀行口座）に対してチャージ要求を行う。

続いて、ＳＱ４０３の処理として、カード会社端末１００のチャージ処理部１３３は、第１のファンディングソースから電子マネーのチャージを行う。第１のファンディングソースが銀行口座である場合には、所定金額の現金を電子マネーに変換し、チャージを行う。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネー（例えば、１０００円相当）のうち、一定割合（例えば、６００円相当）についてチャージすることができる。

続いて、ＳＱ４０４の処理として、カード会社端末１００のチャージ処理部１３３は、第２のファンディングソース（例えば、他の銀行口座）に対してチャージ要求を行う。

続いて、ＳＱ４０５の処理として、カード会社端末１００のチャージ処理部１３３は、第２のファンディングソースから電子マネーのチャージを行う。第２のファンディングソースが銀行口座である場合には、所定金額の現金を電子マネーに変換し、チャージを行う。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネー（例えば、１０００円相当）のうち、一定割合（例えば、４００円相当）についてチャージすることができる。これにより、第１のファンディングソースからのチャージ金額と第２のファンディングソースからのチャージ金額とを合算すると、不足額と同じになり、カード会社端末１００は、その取引を承認することができる。

以上のように、本実施形態を通じて、カード会社は、複数のファンディングソースの連携を通じて、利用者に対し、さらに柔軟に電子マネーのチャージ方法を提供することができる。

＜実施形態４＞
図１１は、本発明の第三実施形態に係る、チャージ方法に係るフローチャートの一例である。本実施形態は、カード利用者となる個人または法人が、複数のファンディングソースを設定したいような場合に適用可能な電子マネー等のバリューのチャージ方法のさらに他の例である。なお、本実施形態において、基本的なシステム構成は図１に示した第一実施形態の構成と同じであり、また、カード会社端末１００における基本的な処理は、図７に示した第一実施形態に係る処理と同じであるので、ファンディングソースからの電子マネーのチャージ処理以外の処理については説明を省略する。

まず、ＳＱ５０１の処理として、利用者の商品またはサービスの購入に係る利用金額に対する電子マネーの残高が不足している場合、カード会社端末１００のチャージ処理部１３３は、予め設定されている複数のファンディングソースのうち、まず先にアクセスする第１のファンディングソース（例えば、ソーシャルネットワークシステム）に対して、その利用者の信用スコアを問い合わせる・

続いて、ＳＱ４０２の処理として、第１のファンディングソース（例えば、ソーシャルネットワークシステム）は、その利用者の属性情報やソーシャルネットワーク上での行動履歴を参照し、信用スコアを算出する。例えば、ソーシャルネットワークシステムは、その利用者のプロフィール情報を確認し、その利用者の信用スコアを所定の基準に基づいて算出する。例えば、ソーシャルネットワークシステムは、その利用者のプロフィール情報（例えば、勤務先、年齢、友だちの人数等）及び／または利用者のアクション（例えば、投稿に対して「いいね」を受け付けた数、投稿に対してコメントを受け付けた数等）に基づき、信用スコアを算出する。スコアの配分は種々考えられ、例えば、プロフィールの入力内容が多いほどスコアを高く設定したり、所定のアクション毎にスコアを割り当て、アクション数に応じてスコアを積算することもできる。

続いて、ＳＱ４０３の処理として、ソーシャルネットワークシステムは、算出した信用スコアをカード会社端末１００に送信する。ソーシャルネットワークシステムは、カード会社端末１００に算出した信用スコア（例えば、９０点）を送信する。

続いて、ＳＱ４０５の処理として、カード会社端末１００のチャージ処理部１３３は、第２のファンディングソース（例えば、クレジットカード）に対して、その利用者の信用スコアを送信する。オーソリ要求に際して、チャージ処理部１３３は、その利用者が購入した商品またはサービスの金額等与信に必要な情報をオーソリ電文等の形式で送信することができる。

続いて、ＳＱ４０６の処理として、第２のファンディングソース（例えば、クレジットカード会社端末）は、受信した利用者の信用スコアを参照し、及び／または他の与信情報を確認する。与信情報として、例えば、その利用者のクレジットカードの利用限度額、利用履歴等を含む。

続いて、第２のファンディングソースは、与信確認の結果に基づき、信用供与をカード会社端末１００に対して行う。第２のファンディングソースがクレジットカードである場合には、利用者の信用スコア（例えば、９０点）、及び／またはその他の与信情報に基づいて、例えば、５００円のＴシャツであれば購入を許可する旨の通知を、カード会社端末１００に対して行う。

以上のように、本実施形態を通じて、カード会社は、複数のファンディングソースの連携を通じて、信用供与を行うことで、さらに柔軟に電子マネーのチャージ方法を提供することができる。

なお、上記第一乃至第四の実施形態の適用は、電子マネーを利用するためのプリペイドカードに対するチャージ方法に限られず、法的通貨バリューや各種ポイント等を含む、一定の金銭的価値を有するバリューに適用され、また、ＱＲコード等を印字したシート媒体、ＱＲコード等を表示したＷｅｂページ等の電子媒体、Ｗｅｂサービスやアプリ等の仮想媒体等の、媒体提供者により提供される決済媒体に対しても適用することができる。

また、上記第一乃至第四の実施形態の適用は、金銭的価値を有するバリューに対するチャージ方法に限られず、他の利用者が保有するバリューからの送金による入金方法にも適用することができる。

以上、開示に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換および変更を行なって実施することが出来る。これらの実施形態および変形例ならびに省略、置換および変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。

１ チャージシステム １００ カード会社端末、１１０ 通信部、１２０ 記憶部、１３０ 制御部、２００ 利用者端末、３００ 店舗端末、ＮＷ ネットワーク

Claims (3)

1. サーバであって、
   金額を含む取引の支払要求を受け付ける受付部と、
   利用者に関連付けられた残高を記憶する残高記憶部と、
   前記利用者に予め関連づけられたチャージ資源を記憶する資源記憶部と、
   前記支払要求に基づいて、前記取引を承認する制御部と、を備え、
   前記制御部は、
   前記残高が前記金額に対し不足しない場合は、前記支払要求を承認し、
   前記残高が前記金額に対し不足する場合は、前記チャージ資源を管理する端末に対して、前記チャージ資源を用いたチャージ要求を行い、
   前記端末に前記チャージ要求が認められた場合に、前記取引を承認する、サーバ。
2. サーバの制御方法であって、
   金額を含む取引の支払要求を受け付けるステップと、
   利用者に関連付けられた残高を記憶するステップと、
   前記利用者に予め関連づけられたチャージ資源を記憶するステップと、
   前記支払要求に基づいて、前記取引を承認するステップと、を含み、
   前記取引を承認するステップにおいて、
   前記残高が前記金額に対し不足しない場合は、前記支払要求を承認するステップと、
   前記残高が前記金額に対し不足する場合は、前記チャージ資源を管理する端末に対して、前記チャージ資源を用いたチャージ要求を行うステップと、
   前記端末に前記チャージ要求が認められた場合に、前記取引を承認するステップと、を含む、サーバの制御方法。
3. コンピュータに、
   金額を含む取引の支払要求を受け付けるステップと、
   利用者に関連付けられた残高を記憶するステップと、
   前記利用者に予め関連づけられたチャージ資源を記憶するステップと、
   前記支払要求に基づいて、前記取引を承認するステップと、を実行させ、
   前記取引を承認するステップにおいて、
   前記残高が前記金額に対し不足しない場合は、前記支払要求を承認するステップと、
   前記残高が前記金額に対し不足する場合は、前記チャージ資源を管理する端末に対して、前記チャージ資源を用いたチャージ要求を行うステップと、
   前記端末に前記チャージ要求が認められた場合に、前記取引を承認するステップと、を実行させる、プログラム。