(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-01-17
(45)【発行日】2024-01-25
(54)【発明の名称】法定通貨バリュー、電子マネー、その他ポイント等の各種バリューのチャージ、入金方法及びシステム
(51)【国際特許分類】
G06Q 20/04 20120101AFI20240118BHJP
【FI】
G06Q20/04
(21)【出願番号】P 2019081473
(22)【出願日】2019-04-23
【審査請求日】2022-04-13
(73)【特許権者】
【識別番号】516075204
【氏名又は名称】株式会社Kyash
(74)【代理人】
【識別番号】100128886
【氏名又は名称】横田 裕弘
(72)【発明者】
【氏名】鷹取 真一
(72)【発明者】
【氏名】椎野 孝弘
【審査官】青柳 光代
(56)【参考文献】
【文献】特開2015-038692(JP,A)
【文献】特開2016-071655(JP,A)
【文献】特開2017-037594(JP,A)
【文献】特開2016-118932(JP,A)
【文献】国際公開第2018/126920(WO,A1)
【文献】特表2020-503622(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
(57)【特許請求の範囲】
【請求項1】
決済サーバであって、
第1端末から、購入金額を含む取引の
決済要求を受け付ける受付部と、
利用者
に関連付けられた残高を記憶する残高記憶部と、
前記利用者が予め設定し
たクレジットカードをファンディングソース
として記憶するファンディングソース記憶部と、
前記残高
と前記ファンディングソースに記憶された前記クレジットカードからの資金を用いて決済を行う制御部と、
を備え、
前記制御部は、
前記残高が、前記購入金額に対し不足しない場合、前記残高の資金を用いて前記決済要求を承認し、
前記残高が、前記購入金額に対し不足する場合、
決済サーバを管理する会社とは異なる会社の前記クレジットカードを管理する第2端末に対して、前記クレジットカードからの資金を用いたチャージ要求を行い、
前記第2端末に前記チャージ要求が認められた場合に、
前記クレジットカードの資金を用いて前記決済要求を承認する、
決済サーバ。
【請求項2】
前記ファンディングソース記憶部は、
前記クレジットカードに加えて、前記利用者が予め設定した銀行口座情報、デビットカード情報、仮想通貨口座情報の少なくともいずれか一つをファンディングソースとして記憶し、
前記制御部は、
前記
決済要求
に含まれる前記利用者の情報から、前記決済要求に係る取引の用途を特定し、
前記特定した用途に基づいて、
前記ファンディングソース記憶部に記憶された複数の前記ファンディングソースの中から決済に用いる前記ファンディングソースを選択する、
請求項1記載の
決済サーバ。
【請求項3】
前記ファンディングソース記憶部は、
前記クレジットカードに加えて、前記利用者が予め設定した銀行口座情報、デビットカード情報、仮想通貨口座情報の少なくともいずれか一つをファンディングソースとして記憶し、
前記制御部は、
前記
決済要求
に含まれる前記利用者の情報から、前記
利用者が所属する
会社において
前記決済要求に係る前記購入金額の費用を負担する部門を特定し、
前記特定した部門に基づいて、
前記ファンディングソース記憶部に記憶された複数の前記ファンディングソースの中から決済に用いる前記ファンディングソースを選択する、
請求項1記載の
決済サーバ。
【請求項4】
決済サーバの制御方法であって、
第1端末から、購入金額を含む取引の
決済要求を受け付けるステップと、
利用者
に関連付けられた残高を記憶するステップと、
前記利用者が予め設定した
クレジットカードをファンディングソース
として記憶するステップと、
前記残高
と前記ファンディングソースに記憶された前記クレジットカードからの資金を用いて決済を行うステップと、
を含み、
前記決済を行うステップにおいて、
前記残高が、前記購入金額に対し不足しない場合、前記残高の資金を用いて前記決済要求を承認するステップと、
前記残高が、前記購入金額に対し不足する場合、
決済サーバを管理する会社とは異なる会社の前記クレジットカードを管理する第2端末に対して、前記クレジットカードからの資金を用いたチャージ要求を行うステップと、
前記第2端末に前記チャージ要求が認められた場合に、
前記クレジットカードの資金を用いて前記決済要求を承認するステップと、
を含む、
決済サーバの制御方法。
【請求項5】
コンピュータに、
第1端末から、購入金額を含む取引の
決済要求を受け付けるステップと、
利用者
に関連付けられた残高を記憶するステップと、
前記利用者が予め設定した
クレジットカードをファンディングソース
として記憶するステップと、
前記残高
と前記ファンディングソースに記憶された前記クレジットカードからの資金を用いて決済を行うステップと、
を含み、
前記決済を行うステップにおいて、
前記残高が、前記購入金額に対し不足しない場合、前記残高の資金を用いて前記決済要求を承認するステップと、
前記残高が、前記購入金額に対し不足する場合、
決済サーバを管理する会社とは異なる会社の前記クレジットカードを管理する第2端末に対して、前記クレジットカードからの資金を用いたチャージ要求を行うステップと、
前記第2端末に前記チャージ要求が認められた場合に、
前記クレジットカードの資金を用いて前記決済要求を承認するステップと、
を実行させる、プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、各種バリューのチャージ方法及びシステムに関する。
【背景技術】
【0002】
従来、法定通貨バリュー、電子マネー、その他ポイント等の金銭的価値を有する無形資産(以下、「バリュー」という)による決済が普及しており、一例として、電子マネー決済の一般的な仕組みにおいて、利用者は、所定の方法により、一定の金額相当の電子マネーを事前または即座にチャージし、電子マネー利用者である加盟店に渡すことで、その加盟店が販売する商品またはサービスを購入し、加盟店舗は、電子マネー発行者から売上金相当の電子マネーと引き換えに現金等の支払を受ける。
【0003】
電子マネーのチャージ方法として、現金によるチャージのほか、クレジットカードや銀行口座等の支払能力を担保することが可能な対象と連動したチャージ方法が挙げられる(例えば、特許文献1)。また、複数のチャージ方法(ファンディングソース)を利用者が選択肢の中から選択できる方法も開示されている(例えば、特許文献2)。
【先行技術文献】
【特許文献】
【0004】
【文献】特許6473487号公報
【文献】特開2018-160267号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、電子マネーを始めとするバリューの決済カード又は決済が可能なコード等の決済媒体の提供者が、個人または法人等の利用者に決済媒体を提供する場合において、事前に提供者が提供するチャージ方法に限定され、柔軟性に乏しい。
【0006】
そこで、本発明では、より柔軟なバリューのチャージ方法を提供することを目的とする。
【課題を解決するための手段】
【0007】
バリューによる支払用の決済媒体を提供する媒体提供者により提供される、バリューのチャージ方法であって、利用者がバリューを介して加盟店舗または事業主が提供する商品またはサービスを購入したときに、加盟店舗または事業主端末から当該商品またはサービスの取引のオーソリ要求を受付け、前記利用者のバリューの残高を確認し、前記残高が前記商品またはサービスの購入金額を下回るときに、前記利用者が予め設定したファンディングソースからバリューをチャージする。
【発明の効果】
【0008】
本発明によれば、より柔軟なバリューのチャージ方法を提供することができる。
【図面の簡単な説明】
【0009】
【
図1】本発明の第一実施形態に係るチャージシステムを示すブロック構成図である。
【
図2】
図1のカード会社端末100を示す機能ブロック構成図である。
【
図3】
図1の利用者端末200を示す機能ブロック構成図である。
【
図4】
図1の店舗端末200を示す機能ブロック構成図である。
【
図5】サーバ100に格納される利用者データの一例を示す模式図である。
【
図6】サーバ100に格納される電文データの一例を示す模式図である。
【
図7】本発明の第一実施形態に係る、チャージ方法に係るフローチャートの一例である。
【
図8】本発明の第一実施形態に係る、チャージ方法に係るフローチャートの変形例である。
【
図9】本発明の第二実施形態に係る、チャージ方法に係るフローチャートの一例である。
【
図10】本発明の第三実施形態に係る、チャージ方法に係るフローチャートの一例である。
【
図11】本発明の第四実施形態に係る、チャージ方法に係るフローチャートの一例である。
【発明を実施するための形態】
【0010】
以下、本発明の実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本開示の必須の構成要素であるとは限らない。
【0011】
(実施形態1)
<構成>
図1は、本発明の第一実施形態に係るチャージシステムを示すブロック構成図である。 なお、本実施形態は、法的通貨バリュー、電子マネー及び各種ポイント等一定の金銭的価値を有するバリューに適用され、また、プリペイドカードのようなカード媒体のほか、QRコード等を印字したシート媒体、QRコード等を表示したWebページ等の電子媒体、Webサービスやアプリ等の仮想媒体等の、各種媒体提供者によって提供される決済媒体に対しても適用され得るが、本実施形態においては、説明の便宜のため、電子マネーを利用するためのプリペイドカードを発行する、カード会社の端末である、カード会社端末100と、そのカードを利用する利用者の端末である、利用者端末200と、商品またはサービスと引き換えにカード会社が発行する電子マネーを利用可能な加盟店舗の端末である、店舗端末300と、利用者が電子マネーをチャージする際のチャージ元となるファンディングソースとにより構成されるシステムを例示して説明する。
【0012】
カード会社は、所謂、クレジットカードやプリペイドカードのイシュアーと呼ばれ、利用者に対し、カードを発行し、与信管理を行い、プリペイドカードであれば、利用者の電子マネーの残高を管理し、利用者が商品と引き換えにプリペイドカードを加盟店舗で利用した際に、その取引のオーソリ(承認)を行う。利用者は、個人利用者または法人利用者が考えられ、また、法人の場合は、その法人が二次イシュアー(パートナー)として、さらに他の法人に対してカードを発行し、カードに自社が提供する機能を追加してサービス提供をすることも考えられる。また、利用者が法人であって、カード会社が法人カードとしてカード発行する場合は、利用者は、そのカードを従業員向けに発行し、従業員は、出張、会議及び接待等、業務に付随する用途のためにそのカードを利用することも考えられる。
【0013】
また、カード会社は、所謂、バーチャルカードといわれる、利用者がスマートフォン等の携帯端末にインストールしたアプリケーションを介して表示されるプリペイドカードを発行したり、利用者からの要求に応じて、物理カードといわれる、磁気カードまたはICチップを内蔵したICカードを発行することもできる。一般的に、バーチャルカードは、オンラインショッピング等のオンラインにおける商品の購入等の取引に、物理カードは、実店舗における商品またはサービスの購入等の取引に際して利用される。
【0014】
カード会社端末100と、利用者端末200、店舗端末300及びファンディングソース400とは、ネットワークNWを介して接続される。ネットワークNWは、インターネット、イントラネット、無線LAN(Local Area Network)やWAN(Wide Area Network)等により構成される。
【0015】
カード会社端末100は、例えば、ワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティングによって論理的に実現されてもよい。本実施形態においては、説明の便宜上カード会社端末として1台を例示しているが、これに限定されず、複数台であってもよい。
【0016】
利用者端末200は、例えば、パーソナルコンピュータやタブレット端末等の情報処理装置であるが、スマートフォンや携帯電話、PDA等により構成しても良い。
【0017】
店舗端末300は、カードの加盟店に設置される端末であり、例えば、スーパー、ショッピングセンター、コンビニエンスストア等に設置されるPOS/CCT/CAT等の端末が考えられるが、同様の機能を備えたアプリケーションを内蔵したパーソナルコンピュータ、スマートフォン、タブレット端末等も考えられる。また、店舗に限らず、事業活動を行う事業主に設置される事業主端末にも置き換えられ得る。店舗端末300により、加盟店の店頭において、クレジットカード、プリペイドカードおよびデビットカードの決済等の操作を行うことができる。また、店舗端末300は、ネットワークNWを介して、カード会社端末100や(図示しない)他のクレジットカード発行会社の端末と通信可能に接続される。また、VISA(登録商標)等の国際ブランドのカードシステムを経由して、カード端末100等に接続することも考えられる。
【0018】
本実施形態では、システム1は、カード会社端末100、利用者端末200、店舗端末300及びファンディングソース400を有するものと説明するが、上述のように、二次イシュアー(パートナー)を利用者端末とすることもでき、また、パートナーのカード利用者が他の法人または個人となる例において、そのパートナーを本システムにおけるカード会社(カード会社端末100)に置き換え、そのパートナーが発行するカードの利用者を本システムにおける利用者(利用者端末200)に置き換えることもできる。パートナーがカード会社に置き換えられる場合は、元のカード会社のAPI(Application Programming Interface)を利用することも考えられる。
【0019】
図2は、
図1のカード会社端末100の機能ブロック構成図である。カード会社端末100は、通信部110と、記憶部120と、制御部130とを備える。
【0020】
通信部110は、ネットワークNWを介して利用者端末200及び店舗端末300と通信を行うための通信インタフェースであり、例えばTCP/IP(Transmission Control Protocol/Internet Protocol)等の通信規約により通信が行われる。
【0021】
記憶部120は、各種制御処理や制御部130内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、RAM(Random Access Memory)、ROM(Read Only Memory)等から構成される。また、記憶部120は、カード利用者が加盟店で商品またはサービスを購入した場合の取引のオーソリ(承認)や電子マネーのチャージに必要な各種データを格納する、利用者データ格納部121、加盟店から受信するオーソリ電文に関連するデータを格納する、電文データ格納部122等を有する。さらに、記憶部120は、利用者端末200及び店舗端末300と通信を行ったデータを一時的に記憶することもできる。なお、各種データを格納したデータベース(図示せず)が記憶部120外に構築されていてもよい。
【0022】
制御部130は、記憶部120に記憶されているプログラムを実行することにより、カード会社端末100の全体の動作を制御するものであり、CPU(Central Processing Unit)やGPU(Graphics Processing Unit)等から構成される。制御部130の機能として、利用者端末200または店舗端末300からの指示を受け付ける要求受付部131と、オーソリ要求に対して承認のための処理を行う承認処理部132と、電子マネーのチャージに関連する処理を行う、チャージ処理部133と、を有する。この要求受付部131、承認処理部132、チャージ処理部133は、記憶部120に記憶されているプログラムにより起動されてコンピュータ(電子計算機)であるカード会社端末100により実行される。
【0023】
要求受付部131は、例えば、利用者端末200においてインストールされるアプリケーションを介して表示されるユーザインターフェースにおいて、利用者が、例えば、利用者情報を登録したり、バーチャルまたは物理的なプリペイドカードを発行する等の所定の要求を行ったときに、利用者端末200から通信部110を介して要求を受付ける。また、利用者が、例えば、加盟店でカードを使って商品またはサービスの購入を行い、店舗端末300のリーダによって磁気カードの読み取り操作を行い、オーソリ要求を行うためにオーソリ電文を送信したときに、店舗端末300から通信部110を介して要求を受付ける。
【0024】
承認処理部132は、店舗端末300から、特定の取引についてオーソリ要求を受付けたときに、その取引の承認を行うための所定の処理を行う。
【0025】
チャージ処理133は、利用者端末200からの要求により、または、自動処理によって、利用者の電子マネーのチャージ処理を行う。
【0026】
図3は、
図1の利用者端末200を示す機能ブロック構成図である。利用者端末200は、通信部210と、表示操作部220と、記憶部230と、制御部240とを備える。
【0027】
通信部210は、ネットワークNWを介してカード会社端末100と通信を行うための通信インタフェースであり、例えばTCP/IP等の通信規約により通信が行われる。
【0028】
表示操作部220は、利用者が指示を入力し、制御部240からの入力データに応じてテキスト、画像等を表示するために用いられるユーザインターフェースであり、利用者端末200がパーソナルコンピュータで構成されている場合はディスプレイとキーボードやマウスにより構成され、利用者端末200がタブレット端末で構成されている場合はタッチパネル等から構成される。この表示操作部220は、記憶部230に記憶されているアプリケーションプログラム等の制御プログラムにより起動されてコンピュータ(電子計算機)である利用者端末200により実行される。
【0029】
記憶部230は、各種制御処理や制御部240内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、RAMやROM等から構成される。また、記憶部230は、カード会社端末100との通信内容を一時的に記憶している。
【0030】
制御部240は、記憶部230に記憶されているプログラムを実行することにより、利用者端末200の全体の動作を制御するものであり、CPUやGPU等から構成される。
【0031】
なお、カード会社端末100に利用者端末200に記憶されているアプリケーションプログラム等の制御プログラムの機能を全部または一部備える構成としても良い。
【0032】
図4は、
図1の店舗端末300を示す機能ブロック構成図である。店舗端末300は、通信部310と、表示操作部320と、記憶部330と、リーダ340、制御部350とを備える。
【0033】
通信部310は、ネットワークNWを介してカード会社端末100(国際ブランドのカードシステムを経由する場合は、(図示しない)国際ブランドのカードシステムと)と通信を行うための通信インタフェースであり、例えばTCP/IP等の通信規約により通信が行われる。
【0034】
表示操作部320は、店舗担当者が指示を入力し、制御部350からの入力データに応じてテキスト、画像等を表示するために用いられるユーザインターフェースであり、店舗端末300が、POS/CCT/CAT端末であれば、ディスプレイとボタン、ポインティングデバイス、キーボード等により構成され、パーソナルコンピュータで構成されている場合はディスプレイとキーボードやマウス等により構成され、店舗端末300がタブレット端末で構成されている場合はタッチパネル等から構成される。また、この表示操作部220は、記憶部230に記憶されているアプリケーションプログラム等の制御プログラムにより起動されてコンピュータ(電子計算機)である利用者端末200により実行される。
【0035】
記憶部330は、各種制御処理や制御部350内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、RAMやROM等から構成される。また、記憶部230は、カード会社端末100との通信内容を一時的に記憶している。
【0036】
リーダ340は、リーダ114は、磁気カードリーダ、バーコードリーダ、ICチップリーダ等の装置で構成され、プリペイドカード、クレジットカード、デビットカード等の情報を読み取ることができる。
【0037】
制御部350は、記憶部330に記憶されているプログラムを実行することにより、店舗端末300の全体の動作を制御するものであり、CPUやGPU等から構成される。
【0038】
図5は、サーバ100に格納される利用者データの一例を示す模式図である。
【0039】
図5に示す利用者データ1000は、プリペイドカードを利用する利用者に関連する各種データを格納する。
図5において、説明の便宜上、一利用者(利用者ID「10001」で特定される利用者)の例を示すが、複数の利用者の情報を格納することができる。利用者に関連する各種データとして、例えば、利用者の登録情報(法人の場合は、法人名、代表者名、住所及び連絡先等、個人または従業員の場合は、氏名、生年月日、性別、住所、及び連絡先(電話番号、Eメールアドレス等)、また、従業員の場合は、さらに、社員ID及び所属部門等)、また、カード情報(例えば、カード番号(PAN)、カード会員名、有効期限(EXP)、暗証番号(PIN)、セキュリティコード(CAV/CVC2/CVV2/CID)、及びトラックデータ等)が含まれる。また、与信に関連する情報(例えば、電子マネー残高、利用限度額等)、利用者のファンディングソース情報(クレジットカード情報、デビットカード情報、銀行口座情報、仮想通貨口座情報及びキャリア決済用の情報等))も含まれる。
【0040】
図6は、サーバ100に格納される電文データの一例を示す模式図である。
【0041】
図6に示す電文データ2000は、オーソリ電文に格納される各種データを格納する。オーソリ電文に関連する各種データとして、例えば、加盟店で利用されたカード情報、加盟店ID、利用日時、利用金額等の情報が含まれる。
【0042】
<処理の流れ>
図7を参照しながら、本実施形態のシステム1が実行するチャージ方法の処理の流れについて説明する。
図7は、本発明の第一実施形態に係る、チャージ方法に係るフローチャートの一例である。
【0043】
ここで、まず、一例として、利用者は、プリペイドカードを発行するため、自身の利用者端末200に、アプリケーションをインストールし、アプリケーションを起動し、提供されるユーザインターフェースにおいて登録情報を登録し、カードの発行要求を行う。カードとして、バーチャルカードといわれる、利用者が利用者端末200にインストールしたアプリケーションを介して表示されるプリペイドカード、及び/または、物理カードといわれる、プラスチックに所定のカード情報を印字した、磁気カードまたはICチップを内蔵したICカードを発行することができる。利用者は、事前にアプリケーションを使って、電子マネーにチャージを行うための所望のファンディングソース情報(例えば、クレジットカード情報、デビットカード情報、銀行口座情報、仮想通貨口座情報及びキャリア決済用の情報等)を設定し、事前に所定金額相当の電子マネーをチャージしておくことができる。また、コンビニエンスストア等の店舗に設置されたATMを使った現金によるチャージも可能である。電子マネーのチャージは、電子マネーのチャージ額が所定額(例えば、5万円)未満である場合、所定額単位(例えば、1000円、5000円、10000円単位)でのチャージが選択的に利用可能である。
【0044】
まず、SQ101の処理として、利用者端末200は、加盟店で商品またはサービスを購入するために、プリペイドカードを利用する。この場合、利用者が実店舗で商品またはサービスを購入する場合は、利用者は、リアルなプリペイドカードを店舗の担当者に提示する。利用者が利用者端末200を使って、オンライン店舗等で商品またはサービスを購入する場合は、バーチャルカードに関する情報をオンライン店舗の購入画面に入力する。
【0045】
SQ102の処理として、加盟店の店舗端末300は、商品またはサービスの決済操作を行い、商品またはサービスの取引に対するオーソリ要求をカード会社端末100に送信する。例えば、オンライン店舗の場合、店舗端末300は、利用者端末200から商品またはサービスの購入要求をネットワーク経由で受付け、決済処理を行う。また、実店舗の場合、店舗端末300は、プリペイドカードをPOS/CCT/CAT等の端末に読み取らせて決済処理を行う。決済処理を行うと、店舗端末300は、オーソリ要求として、オーソリ電文及び売上データをカード会社端末100に送信する。オーソリ電文に含まれる情報として、例えば、
図6に示す情報(カード情報、加盟店ID、日時、利用金額)が含まれる。オーソリ電文として、例えば、ISO8583規格に基づいてメッセージとして生成されものを送信するか、または、ISO8583規格で生成されたメッセージを他の所与の形式(例えば、JSON形式)に変換したものを送信することが考えられる。
【0046】
続いて、SQ103の処理として、カード会社端末100の要求受付部131は、オーソリ要求を受信すると、承認処理部132は、利用者の、利用金額に対する電子マネーの残高を確認する。例えば、カード会社端末100は、カード番号を基に利用者IDを検索し、
図5に示す利用者データ1000のうち、対象となる利用者の電子マネーの残高を参照する。
【0047】
続いて、SQ104の処理として、カード会社端末100の承認処理部132は、利用者の電子マネーの残高が、利用金額に対して同額か、上回れば、取引を承認する。(利用者の電子マネーの残高が、利用金額を下回る場合、処理は、SQ106に進む)
【0048】
続いて、SQ105の処理として、カード会社端末100の通信部110は、店舗端末300に対して、取引承認の応答を送信する。
【0049】
上記SQ103において、利用者の電子マネーの残高が利用金額を下回る場合は、SQ106の処理として、カード会社端末100のチャージ処理部133は、
図5に示す利用者データ1000のうち、登録情報を確認し、その利用者のファンディングソースを確認する。例えば、その利用者が個人または法人事業者であれば、その個人または法人が登録するファンディングソース(例えば、クレジットカード、デビットカード、銀行口座、仮想通貨口座及びキャリア決済を含むが、これらに限られない)を特定する。また、その利用者が、二次事業者としてのパートナー企業であれば、その企業が登録するファンディングソースを確認する。また、その利用者が、法人企業において、費用負担部門との紐付けがされている場合は、その部門を特定し、その部門が登録するファンディングソースを確認する。
【0050】
続いて、SQ107において、カード会社端末100のチャージ処理部133は、利用者のファンディングソースに応じて、ファンディングソースから所定額相当の電子マネーをチャージする。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネーをチャージするか、カード会社または利用者が予め設定した金額相当の電子マネーをチャージすることができる。例えば、利用者がパートナー企業であった場合、そのパートナー企業が登録するファンディングソースが銀行口座であった場合、チャージ処理部133は、その銀行口座から、例えば不足額分の現金を電子マネーに変換し、電子マネーを増額する処理を行う。また、例えば、利用者が企業の営業部門に属している場合、チャージ処理部133は、営業部門に設定されているファンディングソースから電子マネーを増額する処理を行う。
【0051】
続いて、SQ108の処理として、カード会社端末100の承認処理部132は、利用者の電子マネーの残高が、利用金額に対して同額か、上回ることを確認し、取引を承認し、SQ109の処理として、カード会社端末100の通信部110は、店舗端末300に対して、取引承認の応答を送信する。
【0052】
以上のように、本実施形態のチャージ方法を通じて、カード会社は、カード利用者が設定したファンディングソースに基づいた、柔軟な電子マネーのチャージ方法を提供することができる。特に、カード会社がパートナー企業等の法人企業に対してカードを発行するときに、パートナー企業を始めとする法人企業は、独自のファンディングソースをチャージ資源として活用したいというニーズがあり、本実施形態のチャージ方法によれば、こうしたニーズに柔軟に対応することができる。
【0053】
(変形例)
図8は、本発明の第一実施形態に係る、チャージ方法に係るフローチャートの変形例である。
【0054】
本変形例は、
図7に示したチャージ方法と基本部分は同じであるが、特に、カード利用者が、法人企業であって、その法人企業がビジネス用途に応じたファンディングソースの設定を行いたいような場合に適用可能な電子マネーのチャージ方法となる。
【0055】
まず、SQ201の処理として、利用者端末200は、加盟店で商品またはサービスを購入するために、プリペイドカードを利用する。この場合、利用者が実店舗で商品またはサービスを購入する場合は、利用者は、リアルなプリペイドカードを店舗の担当者に提示する。利用者が利用者端末200を使って、オンライン店舗等で商品またはサービスを購入する場合は、バーチャルカードに関する情報をオンライン店舗の購入画面に入力する。
【0056】
SQ202の処理として、加盟店の店舗端末300は、商品またはサービスの決済操作を行い、商品またはサービスの取引に対するオーソリ要求をカード会社端末100に送信する。例えば、オンライン店舗の場合、店舗端末300は、利用者端末200から商品またはサービスの購入要求をネットワーク経由で受付け、決済処理を行う。また、実店舗の場合、店舗端末300は、プリペイドカードをPOS/CCT/CAT等の端末に読み取らせて決済処理を行う。決済処理を行うと、店舗端末300は、オーソリ要求として、オーソリ電文及び売上データをカード会社端末100に送信する。オーソリ電文に含まれる情報として、例えば、
図6に示す情報(カード情報、加盟店ID、日時、利用金額)が含まれる。オーソリ電文として、例えば、ISO8583規格に基づいてメッセージとして生成されものを送信するか、または、ISO8583規格で生成されたメッセージを他の所与の形式(例えば、JSON形式)に変換したものを送信することが考えられる。
【0057】
続いて、SQ203の処理として、カード会社端末100の要求受付部131は、オーソリ要求を受信すると、承認処理部132は、利用者の、利用金額に対する電子マネーの残高を確認する。例えば、カード会社端末100は、カード番号を基に利用者IDを検索し、
図5に示す利用者データ1000のうち、対象となる利用者の電子マネーの残高を参照する。
【0058】
続いて、SQ204の処理として、カード会社端末100の承認処理部132は、利用者の電子マネーの残高が、利用金額に対して同額か、上回れば、取引を承認する。(利用者の電子マネーの残高が、利用金額を下回る場合、処理は、SQ206に進む)
【0059】
続いて、SQ205の処理として、カード会社端末100の通信部110は、店舗端末300に対して、取引承認の応答を送信する。
【0060】
上記SQ203において、利用者の電子マネーの残高が利用金額を下回る場合は、SQ206の処理として、カード会社端末100のチャージ処理部133は、
図6に示す電文データ2000の情報からその取引のビジネス用途及びその用途に応じたファンディングソースを確認する。例えば、電文データ2000の加盟店IDからその店舗の属性(例えば、飲食店、ホテル、タクシー等)を確認し、属性が飲食店であれば、交際費としてビジネス用途を決定する。そのうえで、そのビジネス用途に応じたファンディングソース(例えば、クレジットカード、デビットカード、銀行口座、仮想通貨口座及びキャリア決済を含むが、これらに限られない)を特定する。
【0061】
続いて、SQ207において、カード会社端末100のチャージ処理部133は、ビジネス用途のファンディングソースに応じて、ファンディングソースから所定額相当の電子マネーをチャージする。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネーをチャージするか、カード会社または利用者が予め設定した金額相当の電子マネーをチャージすることができる。例えば、上記例において、交際費に対応するファンディングソースが銀行口座であった場合、チャージ処理部133は、その銀行口座から、例えば不足額分の現金を電子マネーに換金し、電子マネーを増額する処理を行う。
【0062】
続いて、SQ208の処理として、カード会社端末100の承認処理部132は、利用者の電子マネーの残高が、利用金額に対して同額か、上回ることを確認し、取引を承認し、SQ109の処理として、カード会社端末100の通信部110は、店舗端末300に対して、取引承認の応答を送信する。
【0063】
以上のように、本変形例を通じて、カード会社は、利用者のビジネス用途に応じて設定したファンディングソースに基づき、柔軟な電子マネーのチャージ方法を提供することができる。なお、本変形例は、法人企業に限らず、個人事業主や個人のカード利用者に対しても適用することができる。
【0064】
<実施形態2>
図9は、本発明の第二実施形態に係る、チャージ方法に係るフローチャートの一例である。本実施形態は、カード利用者となる個人または法人が、複数のファンディングソースを設定したいような場合に適用可能な電子マネー等のバリューのチャージ方法である。なお、本実施形態において、基本的なシステム構成は
図1に示した第一実施形態の構成と同じであり、また、カード会社端末100における基本的な処理は、
図7に示した第一実施形態に係る処理と同じであるので、ファンディングソースからの電子マネーのチャージ処理以外の処理については説明を省略する。
【0065】
まず、SQ301の処理として、利用者の商品またはサービスの購入に係る利用金額に対する電子マネーの残高が不足している場合、カード会社端末100のチャージ処理部133は、第1のファンディングソース(例えば、銀行口座)に対してチャージ要求を行う。この場合、利用者は、事前に複数のファンディングソースをチャージ用のソースとして登録することができ、優先的にチャージを実施するためのファンディングソースを設定することができる。
【0066】
SQ302の処理として、第1のファンディングソース(例えば、銀行口座)を管理する端末は、カード会社端末100からの要求を受付け、利用者の口座残高を確認する。本処理は、カード会社端末100が、第1のファンディングソースから利用者の残高情報を取得することで、残高確認を行うことも可能である。また、カード会社端末100が、(不足額や設定された金額等)予め金額を決めて第1のファンディングソースにその金額相当分の電子マネーのチャージ要求を行う場合は、本ステップを省略することもできる。
【0067】
続いて、SQ303の処理として、カード会社端末100のチャージ処理部133は、第1のファンディングソースから電子マネーのチャージを行う。第1のファンディングソースが銀行口座である場合には、所定金額の現金を電子マネーに変換し、チャージを行う。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネーをチャージするか、カード会社または利用者が予め設定した金額相当の電子マネーをチャージすることができる。チャージ後の電子マネーの残高が、店舗端末から照会を受けた利用金額と同額か上回ったときに、カード会社端末100はチャージ処理を終了する。
【0068】
ここで、第1のファンディングソースから電子マネーをチャージしてもなお利用金額に対する電子マネーの残高が不足している場合、SQ304の処理として、カード会社端末100のチャージ処理部133は、第2のファンディングソース(例えば、クレジットカード)に対してチャージ要求を行う。この場合、利用者は、複数のファンディングソースに対していずれのソースにチャージを要求するかの順番を設定することができる。
【0069】
続いて、SQ305の処理として、第2のファンディングソース(例えば、クレジットカード)を管理する端末は、カード会社端末100からの要求を受付け、利用者の口座残高を確認する。本処理は、カード会社端末100が、第2のファンディングソースから利用者の残高情報を取得することで、残高確認を行うことも可能である。ここで、例えば、クレジットカード会社に対してチャージを要求する場合は、クレジットカード会社端末は、残高確認として、利用者の利用可能額等を確認する。また、カード会社端末100が、(不足額や設定された金額等)予め金額を決めて第2のファンディングソースにその金額相当分の電子マネーのチャージ要求を行う場合は、本ステップを省略することもできる。
【0070】
続いて、SQ306の処理として、カード会社端末100のチャージ処理部133は、第2のファンディングソースから電子マネーのチャージを行う。第2のファンディングソースがクレジットカードである場合には、カード会社端末100のチャージ処理部133は、所定金額相当の電子マネーのチャージを行い、金額情報をクレジットカード会社端末に送信を行う。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネーをチャージするか、カード会社または利用者が予め設定した金額相当の電子マネーをチャージすることができる。チャージ後の電子マネーの残高が、店舗端末から照会を受けた利用金額と同額か上回ったときに、カード会社端末100はチャージ処理を終了する。なお利用金額に対する電子マネーの残高が不足している場合、さらに別のファンディングソースが設定されている場合には、カード会社端末100は、そのファンディングソースにチャージ要求を行うか、または、取引の非承認の通知を店舗端末に対して送信する。
【0071】
以上のように、本実施形態を通じて、カード会社は、利用者に対し、さらに柔軟に電子マネーのチャージ方法を提供することができる。
【0072】
<実施形態3>
図10は、本発明の第三実施形態に係る、チャージ方法に係るフローチャートの一例である。本実施形態は、カード利用者となる個人または法人が、複数のファンディングソースを設定したいような場合に適用可能な電子マネー等のバリューのチャージ方法の他の例である。なお、本実施形態において、基本的なシステム構成は
図1に示した第一実施形態の構成と同じであり、また、カード会社端末100における基本的な処理は、
図7に示した第一実施形態に係る処理と同じであるので、ファンディングソースからの電子マネーのチャージ処理以外の処理については説明を省略する。
【0073】
まず、SQ401の処理として、利用者の商品またはサービスの購入に係る利用金額に対する電子マネーの残高が不足している場合、カード会社端末100のチャージ処理部133は、予め設定されている複数のファンディングソースについて、相対的に優先度の高い第1のファンディングソース(例えば、銀行口座)と、優先度の低い第2のファンディングソース(例えば、他の銀行口座)を設定しておき、また、これらのファンディングソースの残高を確認する。そして、第1のファンディングソースからチャージする金額と、第2のファンディングソースからチャージする金額を、一定割合またはその他の基準に基づいて決め、かつ、両ファンディングソースからのチャージ額の合計が不足金額と同じか、または、上回る金額となるように決めておくことができる。
【0074】
続いて、SQ402の処理として、カード会社端末100のチャージ処理部133は、第1のファンディングソース(例えば、銀行口座)に対してチャージ要求を行う。
【0075】
続いて、SQ403の処理として、カード会社端末100のチャージ処理部133は、第1のファンディングソースから電子マネーのチャージを行う。第1のファンディングソースが銀行口座である場合には、所定金額の現金を電子マネーに変換し、チャージを行う。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネー(例えば、1000円相当)のうち、一定割合(例えば、600円相当)についてチャージすることができる。
【0076】
続いて、SQ404の処理として、カード会社端末100のチャージ処理部133は、第2のファンディングソース(例えば、他の銀行口座)に対してチャージ要求を行う。
【0077】
続いて、SQ405の処理として、カード会社端末100のチャージ処理部133は、第2のファンディングソースから電子マネーのチャージを行う。第2のファンディングソースが銀行口座である場合には、所定金額の現金を電子マネーに変換し、チャージを行う。ここで、チャージ額としては、利用金額に対する不足額相当の電子マネー(例えば、1000円相当)のうち、一定割合(例えば、400円相当)についてチャージすることができる。これにより、第1のファンディングソースからのチャージ金額と第2のファンディングソースからのチャージ金額とを合算すると、不足額と同じになり、カード会社端末100は、その取引を承認することができる。
【0078】
以上のように、本実施形態を通じて、カード会社は、複数のファンディングソースの連携を通じて、利用者に対し、さらに柔軟に電子マネーのチャージ方法を提供することができる。
【0079】
<実施形態4>
図11は、本発明の第三実施形態に係る、チャージ方法に係るフローチャートの一例である。本実施形態は、カード利用者となる個人または法人が、複数のファンディングソースを設定したいような場合に適用可能な電子マネー等のバリューのチャージ方法のさらに他の例である。なお、本実施形態において、基本的なシステム構成は
図1に示した第一実施形態の構成と同じであり、また、カード会社端末100における基本的な処理は、
図7に示した第一実施形態に係る処理と同じであるので、ファンディングソースからの電子マネーのチャージ処理以外の処理については説明を省略する。
【0080】
まず、SQ501の処理として、利用者の商品またはサービスの購入に係る利用金額に対する電子マネーの残高が不足している場合、カード会社端末100のチャージ処理部133は、予め設定されている複数のファンディングソースのうち、まず先にアクセスする第1のファンディングソース(例えば、ソーシャルネットワークシステム)に対して、その利用者の信用スコアを問い合わせる・
【0081】
続いて、SQ402の処理として、第1のファンディングソース(例えば、ソーシャルネットワークシステム)は、その利用者の属性情報やソーシャルネットワーク上での行動履歴を参照し、信用スコアを算出する。例えば、ソーシャルネットワークシステムは、その利用者のプロフィール情報を確認し、その利用者の信用スコアを所定の基準に基づいて算出する。例えば、ソーシャルネットワークシステムは、その利用者のプロフィール情報(例えば、勤務先、年齢、友だちの人数等)及び/または利用者のアクション(例えば、投稿に対して「いいね」を受け付けた数、投稿に対してコメントを受け付けた数等)に基づき、信用スコアを算出する。スコアの配分は種々考えられ、例えば、プロフィールの入力内容が多いほどスコアを高く設定したり、所定のアクション毎にスコアを割り当て、アクション数に応じてスコアを積算することもできる。
【0082】
続いて、SQ403の処理として、ソーシャルネットワークシステムは、算出した信用スコアをカード会社端末100に送信する。ソーシャルネットワークシステムは、カード会社端末100に算出した信用スコア(例えば、90点)を送信する。
【0083】
続いて、SQ405の処理として、カード会社端末100のチャージ処理部133は、第2のファンディングソース(例えば、クレジットカード)に対して、その利用者の信用スコアを送信する。オーソリ要求に際して、チャージ処理部133は、その利用者が購入した商品またはサービスの金額等与信に必要な情報をオーソリ電文等の形式で送信することができる。
【0084】
続いて、SQ406の処理として、第2のファンディングソース(例えば、クレジットカード会社端末)は、受信した利用者の信用スコアを参照し、及び/または他の与信情報を確認する。与信情報として、例えば、その利用者のクレジットカードの利用限度額、利用履歴等を含む。
【0085】
続いて、第2のファンディングソースは、与信確認の結果に基づき、信用供与をカード会社端末100に対して行う。第2のファンディングソースがクレジットカードである場合には、利用者の信用スコア(例えば、90点)、及び/またはその他の与信情報に基づいて、例えば、500円のTシャツであれば購入を許可する旨の通知を、カード会社端末100に対して行う。
【0086】
以上のように、本実施形態を通じて、カード会社は、複数のファンディングソースの連携を通じて、信用供与を行うことで、さらに柔軟に電子マネーのチャージ方法を提供することができる。
【0087】
なお、上記第一乃至第四の実施形態の適用は、電子マネーを利用するためのプリペイドカードに対するチャージ方法に限られず、法的通貨バリューや各種ポイント等を含む、一定の金銭的価値を有するバリューに適用され、また、QRコード等を印字したシート媒体、QRコード等を表示したWebページ等の電子媒体、Webサービスやアプリ等の仮想媒体等の、媒体提供者により提供される決済媒体に対しても適用することができる。
【0088】
また、上記第一乃至第四の実施形態の適用は、金銭的価値を有するバリューに対するチャージ方法に限られず、他の利用者が保有するバリューからの送金による入金方法にも適用することができる。
【0089】
以上、開示に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換および変更を行なって実施することが出来る。これらの実施形態および変形例ならびに省略、置換および変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。
【符号の説明】
【0090】
1 チャージシステム 100 カード会社端末、110 通信部、120 記憶部、130 制御部、200 利用者端末、300 店舗端末、NW ネットワーク