JP2018137005A - 決済システム、決済方法、および決済プログラム - Google Patents

Abstract

【課題】越境ＥＣにおいて、異なる通貨種別間での決済の際に、為替スプレッドを可能な限り回避して利便性の高い手段を提供することを可能とする。【解決手段】越境ＥＣにおいて、異なる通貨種別間での決済の際に、為替スプレッドを可能な限り回避して利便性の高い手段を提供する決済システムである。代表的な実施の形態によれば、所定の入出金用銀行口座に対する消費者からの第１の通貨種別による入金を検知し、入金に係る金額と等価値の第１の通貨種別の第１の仮想通貨を発行し、第１の仮想通貨を第２の通貨種別の第２の仮想通貨に両替し、入出金銀行口座からマーチャントの銀行口座に対する第２の仮想通貨の金額と等価値の出金を指示する決済ゲートウェイを有する。【選択図】図１

Description

本発明は、電子商取引（ＥＣ：Electronic Commerce）における決済技術に関し、特に、いわゆる「越境ＥＣ」における決済を支援する決済システム、決済方法、および決済プログラムに適用して有効な技術に関するものである。

インターネットなどのＩＴ環境の普及・発展に伴い、電子商取引により商品やサービスを販売する事業者が、販路拡大などのために海外の消費者に対して商品等を提供する、いわゆる「越境ＥＣ」の市場が拡大している。越境ＥＣでは、消費者と店舗（以下では「マーチャント」と記載する場合がある）とが国を越えて取引を行うことから、その決済では、マーチャントが支払を受け付ける通貨と、消費者が支払の際に用いる通貨とが異なる場合が生じる。一般的にはクレジットカードによる決済や、銀行による海外送金などが用いられ、クレジットカード会社や銀行などにより通貨の換算が行われて決済される。

越境ＥＣでの決済に関連する技術として、例えば、特表２０１２−５０１０１３号公報（特許文献１）には、買い手が、現地通貨を用いるオフショア小売商ウェブサイトの商品を購入する際に仲介プラットフォームを用いる技術が記載されている。ここでは、買い手がオフショア小売商ウェブサイトに発注し、当該ウェブサイトは注文要求を仲介プラットフォームに送信する。仲介プラットフォームは購入金額を現地通貨で計算し、金融プラットフォームを介してユーザーにより提供される現地通貨金額を等価な外貨金額に交換し、また、商品の出荷を可能にするために、支払い成功を示す取引メッセージをオフショア小売商ウェブサイトに通知する。

また、例えば、特開２０１２−２５６２００号公報（特許文献２）には、為替変動リスクを回避し、国際決済の手数料を安価にする技術が記載されている。ここでは、輸出者に適用される第１為替レートとこれに仲介者の利益を付加した第２為替レートを入力する。また、輸出した商品の代金を輸出先通貨で表した輸出先通貨代金と輸出先口座とを含む入金データを受信し、入金データに含まれる輸出先口座と輸出先通貨代金とを関連づけて記憶し、輸出先通貨代金を輸出先口座から輸出元口座に振り替え、輸出先通貨代金と第１為替レートとに基づいて第１輸出元通貨代金を求め、輸出先通貨代金と第２為替レートとに基づいて第２輸出元通貨代金を求め、第１輸出元通貨代金と第２輸出元通貨代金との差額を求め、差額を仲介者口座と関連づけて記憶し、第１輸出元通貨代金を受取口座と関連づけて記憶する。

特表２０１２−５０１０１３号公報 特開２０１２−２５６２００号公報

越境ＥＣにおいてクレジットカードや銀行送金のような決済手法が用いられる場合、また、特許文献１に記載されたような決済手法が用いられるような場合、通常は、通貨の換算の際に、クレジットカード会社や銀行、その他の仲介事業者などによりスプレッドが上乗せされた独自の為替レートが用いられる。その結果、市場での為替レートよりも割高となってしまい、利用者の費用負担が重くなって利便性が減殺される結果となる。

また、特許文献２に記載されたような決済手法を用いる場合、同一銀行内に輸出元口座、輸出先口座を作成することから、海外送金として取り扱う必要がない一方で、同一銀行内に口座を作成しなければならないなどの制約があり、やはり利便性、柔軟性が減殺される結果となる。

そこで本発明の目的は、越境ＥＣにおいて、異なる通貨種別間での決済の際に、為替スプレッドを可能な限り回避して利便性の高い手段を提供することを可能とする決済システムおよび決済方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による決済システムは、異なる通貨圏に属するユーザ間の取引に係る決済を行う決済システムであって、所定の口座に対する第１の通貨種別による入金を検知し、前記入金に係る金額と等価値の仮想通貨を発行し、相対する注文をマッチングさせた上で等価値の第２の通貨種別による出金を指示する決済ゲートウェイを有するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、越境ＥＣにおいて、異なる通貨種別間での決済の際に、為替スプレッドを可能な限り回避して利便性の高い手段を提供することが可能となる。

本発明の一実施の形態である決済システムの構成例について概要を示した図である。 本発明の一実施の形態の越境ＥＣにおける決済の例について概要を示した図である。 本発明の一実施の形態の越境ＥＣにおける決済の具体例について概要を示した図である。 本発明の一実施の形態における決済処理の流れの例について概要を示したフローチャートである。 本発明の一実施の形態における現地通貨での価格決定処理の流れの例について示したシーケンス図である。 本発明の一実施の形態における平均取得レートの計算処理の流れの例について示したフローチャートである。 本発明の一実施の形態における入金監視処理および仮想通貨発行処理の流れの例について示したシーケンス図である。 本発明の一実施の形態における両替注文指示処理および償還指示処理の流れの例について示したシーケンス図である。 本発明の一実施の形態における出金依頼処理および出金処理の流れの例について示したシーケンス図である。 従来の越境ＥＣにおける決済の例について概要を示した図である。 従来の越境ＥＣにおける決済の具体例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

図１０は、従来の越境ＥＣにおける決済の例について概要を示した図である。図の左側には日本の消費者およびマーチャント、右側には米国のマーチャントおよび消費者がそれぞれ示されている。日本国内での消費者とマーチャントとの間、および米国内での消費者とマーチャントとの間の購買取引は、越境ＥＣではなく、当然、決済はそれぞれの国の通貨によって行われる。すなわち、日本の消費者は日本円（図中では「￥」として表示）によって支払い、日本のマーチャントはそのまま日本円によって受け取る。また、米国の消費者は米国ドル（図中では「＄」として表示）によって支払い、米国のマーチャントはそのまま米国ドルによって受け取る。

一方で、日本の消費者が米国のマーチャントのＷｅｂサイトを介して商品等を購入する越境ＥＣの場合、例えば、クレジットカードによって決済を行うと、日本の消費者は日本円によって支払うことになるが、米国のマーチャントに対しては米国ドルによって支払われる。このとき、日本の消費者の支払う金額は、クレジットカード会社等が用いる独自の為替レートによって米国ドルから変換された金額が用いられる。この為替レートには、通常、クレジットカード会社等によってスプレッドが上乗せされており、市場での為替レートと比較して割高となってしまう。米国の消費者が日本のマーチャントから商品等を購入する場合も同様である。

図１１は、従来の越境ＥＣにおける決済の具体例について概要を示した図である。ここでは、図１０の例における日本と米国との間での越境ＥＣにおける具体的な決済状況の例を示している。例えば、上段の図では、日本の消費者「ａさん」、「ｂさん」、「ｃさん」が、それぞれ、米国のマーチャントの「Ｓｈｏｐ Ａ」、「Ｓｈｏｐ Ｂ」、「Ｓｈｏｐ Ｃ」で販売している＄９、＄５、＄２の商品を購入した場合を示している。市場における為替レートが１＄＝￥１００であったとすると、日本円での支払額は、本来、それぞれ￥９００、￥５００、￥２００となるべきところ、図中の例では、￥４のスプレッドが乗せられた為替レート（１＄＝￥１０４）が適用されており、日本の消費者の支払額は、それぞれ、￥９３６、￥５２０、￥２０８となって割高となっている。

同様に、下段の図では、米国の消費者「ｄさん」、「ｅさん」、「ｆさん」が、それぞれ、日本のマーチャントの「店Ｄ」、「店Ｅ」、「店Ｆ」で販売している￥１００、￥５００、￥３００の商品を購入した場合を示している。この場合、米国ドルでの支払額は、本来、それぞれ＄１、＄５、＄３となるべきところ、図中の例では、＄０．０４のスプレッドが乗せられた為替レート（１．０４＄＝￥１００）が適用されており、米国の消費者の支払額は、それぞれ、＄１．０４、＄５．２、＄３．１となって割高となっている。

越境ＥＣでの決済におけるこのような為替スプレッドの影響を可能な限り回避するため、本発明の一実施の形態である決済システムでは、消費者と海外のマーチャントとの間に、消費者からの入金を受け付け、マーチャントに対して入金を行う決済用のゲートウェイを設ける。そして、取引毎に直接為替交換を行って決済するのではなく、ゲートウェイ内でいったん仮想通貨に変換し、仮想通貨による通貨種別間の両替注文を板情報として管理し、相対する注文をマッチングさせる。これにより、スプレッドが乗らない交換レートを用いることができ、消費者は、当該交換レートによって決定された金額を支払えばよく、商品購入時の費用負担を低減させることができる。

図２は、本実施の形態の越境ＥＣにおける決済の例について概要を示した図である。図１０の従来の例と同様のケースにおいて、本実施の形態では、越境ＥＣの場合に、例えば、日本の消費者による米国のマーチャントへの支払いに係る両替（日本円→米国ドル）と、米国の消費者による日本のマーチャントへの支払いに係る両替（米国ドル→日本円）とを、中間のＥＣ決済ゲートウェイ１０において仮想通貨を用いることでマッチングさせる。これにより、日本の消費者による日本円での支払いを、日本のマーチャントへの支払いに充当し、また、米国の消費者による米国ドルでの支払いを、米国のマーチャントへの支払いに充当することができ、外国為替による通貨の実際の両替を行わずに為替スプレッドの影響を排除することが可能となる。

図３は、本実施の形態の越境ＥＣにおける決済の具体例について概要を示した図である。図１１の従来の例と同様のケースにおいて、例えば、上段の図における日本の消費者「ａさん」は、米国のマーチャントの「Ｓｈｏｐ Ａ」から＄９の商品を購入した場合、為替スプレッドが上乗せされない￥９００を支払うことになる。なお、ここでは説明の便宜上、為替スプレッドはゼロとしているが、両替のマッチングの結果次第では実際には少額のスプレッドが乗る場合も生じ得る。この￥９００の支払いは、下段の図における日本のマーチャントの「店Ｄ」、「店Ｅ」、「店Ｆ」での米国の消費者「ｄさん」、「ｅさん」、「ｆさん」に対する販売額の合計が￥１００＋￥５００＋￥３００＝￥９００であることから、ＥＣ決済ゲートウェイ１０においてマッチングの対象とされ、これらのマーチャントへの支払いに充当される。

同様に、下段の図における米国の消費者「ｄさん」、「ｅさん」、「ｆさん」は、それぞれ、日本のマーチャントの「店Ｄ」、「店Ｅ」、「店Ｆ」から￥１００、￥５００、￥３００の商品を購入した場合、為替スプレッドが上乗せされない＄１、＄５、＄３を支払うことになる。これらを合計した＄９の支払いは、上段の図における米国のマーチャントの「Ｓｈｏｐ Ａ」での米国の消費者「ａさん」に対する販売額が＄９であることから、ＥＣ決済ゲートウェイ１０においてマッチングの対象とされ、当該マーチャントへの支払いに充当される。

本実施の形態では、図３の例のように、通貨種別間の両替を伴う決済を１対１でのみマッチングさせるのではなく、販売額と支払額の合計が合致する限り、ｍ対ｎの数でマッチングさせることができるものとする。相対する両替をマッチングさせる際の手法としては、特に限定されないが、株式市場などにおけるいわゆる「板寄せ方式」などを適宜用いることができる。

＜システム構成＞
図１は、本発明の一実施の形態である決済システムの構成例について概要を示した図である。決済システム１は、越境ＥＣ環境と、越境ＥＣでの取引に係る決済処理を行うＥＣ決済ゲートウェイ１０からなる。越境ＥＣ環境は一般的なものであってよく、例えば、インターネット等のネットワーク５０を介して接続された、消費者３０が利用する情報処理端末である消費者端末３１と、消費者３０とは通貨圏が異なるマーチャント４０のＥＣ用Ｗｅｂサイトを実装するＷｅｂサーバ４１を有する。

また、決済に用いる実際の銀行口座として、各マーチャント４０が支払いを受け取る個別の銀行口座４２に加え、ＥＣ決済ゲートウェイ１０が決済処理を行うために保有する通貨種別毎の入出金用銀行口座２０を有する。図１の例では、入出金用銀行口座２０として、日本円、米国ドル、および中国元での入出金をそれぞれ受け付ける銀行口座（入出金用銀行口座２０ａ〜２０ｃ）を有している。これらの口座は、それぞれの通貨圏の国の銀行等に個別に設けられていてもよい。

ＥＣ決済ゲートウェイ１０は、例えば、サーバ機器や、クラウドコンピューティング環境上に構築された仮想サーバなどにより実装されるサーバシステムであり、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で動作するソフトウェアとして実装された、銀行入出金管理部１１、仮想通貨交換エンジン１２、ゲートウェイ（ＧＷ）口座管理部１３、マーチャント口座管理部１４、プライスコンバータ１５、およびマーケットメーカー１６などの各部を有する。また、データベース等により実装されたマーチャント管理マスタ１７などのデータストアを有する。

銀行入出金管理部１１は、各入出金用銀行口座２０に対して、入金の監視や、各マーチャント４０の銀行口座４２への振込・送金等の出金指示を行う機能を有する。具体的には、入出金用銀行口座２０が設けられている銀行のオンラインバンキングやネットバンキング等のインタフェースを介してコマンド等を発行することで処理を行う。

仮想通貨交換エンジン１２は、ネットワーク上で流通・交換が可能な仮想暗号通貨を実現するための処理エンジンとしての機能を有する。外部の仮想通貨交換エンジンや仮想通貨交換サービスに対するインタフェース機能として実装されたものであってもよい。仮想通貨交換エンジン１２としては、公知の技術を適宜用いることができる。本実施の形態では、エンタープライズ向けの通貨交換ネットワークとして、通貨交換に必要な機能群がＯＳＳ（Open Source Software）として提供されており自由に利用可能であるＲｉｐｐｌｅ（登録商標）（https://ripple.com/）を用いるものとして説明する場合がある。

ＧＷ口座管理部１３は、Ｒｉｐｐｌｅなどの仮想通貨交換エンジン１２上に設けられたＥＣ決済ゲートウェイ１０用の仮想通貨（Ｒｉｐｐｌｅでは「ＩＯＵ」に相当）の口座であるＧＷ口座１３ａを管理する機能を有する。ＧＷ口座管理部１３は、ＧＷ口座１３ａに対して所定の通貨種別（図１の例では、日本円（￥）、米国ドル（＄）、中国元（元））の仮想通貨の発行を行う。また、後述するマーチャント口座からＧＷ口座１３ａへの仮想通貨の入金（ＲｉｐｐｌｅではＩＯＵの償還に相当）を検知した場合に、銀行入出金管理部１１に対して、入出金用銀行口座２０から対象のマーチャント４０の銀行口座４２への出金指示を出力する。

マーチャント口座管理部１４は、各マーチャント４０と関連付けられた仮想通貨の口座であるマーチャント口座を管理する機能を有する。図１の例では、日本、米国および中国の各マーチャント４０に対応するマーチャント口座として、日本口座１４ａ、米国口座１４ｂおよび中国口座１４ｃがそれぞれ１つ以上設けられている。

各マーチャントには、受け取りを許可する仮想通貨の通貨種別が設定されている。通常は、対象の国で流通する通貨種別のみが許可されるが、例えば、日本のマーチャント４０が中国元での受け取りを許可する場合など、他の通貨種別を許可するようにしてもよい。なお、このような設定情報は、マーチャント管理マスタ１７などに予め登録される。受け取りを許可する通貨種別以外の種別によって仮想通貨の入金があった場合は、後述するマーケットメーカー１６に対して、受け取りを許可する通貨種別への両替注文を行い、両替された結果の仮想通貨を入金処理する。

プライスコンバータ１５は、後述するマーケットメーカー１６が保有するオーダーブック１６ａの情報に基づいて、マーチャント４０のＷｅｂサーバ４１が提供するＥＣ用のＷｅｂサイトにおいて販売する商品等の価格を、消費者の現地通貨における価格に変換して提示する機能を有する。

マーケットメーカー１６は、通貨種別間の両替の組み合わせ毎に保有するオーダーブック１６ａの情報を管理し、両替処理を行う機能を有する。オーダーブック１６ａは、マーチャント口座管理部１４から出される両替注文の情報を注文板情報として保持している。マーケットメーカー１６は、オーダーブック１６ａにおける売り／買いの両替注文に対して、上述の図３に示したようなマッチングを行って両替注文を成立させる。なお、具体的なマッチングの手法については特に限定されず、Ｒｉｐｐｌｅなどの仮想通貨交換エンジン１２が備えるマッチング機能を用いてもよいし、独自にマッチング処理を構築してもよい。マーケットメーカー１６は、また、プライスコンバータ１５等からの指示に応じて、現在の板情報に基づいて両替における平均取得レートを算出して出力する。

マーチャント管理マスタ１７は、本実施の形態の決済システム１を利用して決済を行うマーチャント４０についてのマスタ情報を保持するテーブルである。上述したマーチャント４０が入金を許可する通貨種別の情報や、銀行口座４２の情報などを管理する。

図１の例では、ＥＣ決済ゲートウェイ１０を１つのサーバシステムとして構成しているが、構成は適宜柔軟に変更することが可能であり、例えば、銀行入出金管理部１１やＧＷ口座管理部１３、マーチャント口座管理部１４などを各国に分散して配置して各国用のゲートウェイシステムとして構成し、プライスコンバータ１５やマーケットメーカー１６を１ヶ所に集約して設けるというような構成とすることも可能である。

また、本実施の形態では、ＧＷ口座管理部１３やマーチャント口座管理部１４などについて、口座の情報を管理する機能を有するソフトウェアとして構成しているが、口座の情報とこれにアクセスする機能とを一体とした「口座オブジェクト」として実装することも可能である。同様に、マーケットメーカー１６についても、オーダーブック１６ａの情報とこれにアクセスする機能とを一体とした「オーダーブックオブジェクト」として実装することも可能である。

＜処理の流れ（全体）＞
図４は、本実施の形態における決済処理の流れの例について概要を示したフローチャートである。消費者３０が越境ＥＣによって海外のマーチャント４０から商品等を購入する際の決済処理において、まず、決済に先立ち、マーチャント４０のＥＣ用のＷｅｂサイトは、ＥＣ決済ゲートウェイ１０のプライスコンバータ１５にアクセスして、商品等の販売価格に対する、消費者３０の現地通貨での支払価格を取得して、消費者３０に提示する（Ｓ０１）。このとき、プライスコンバータ１５は、マーケットメーカー１６におけるオーダーブック１６ａの板状況を参照し、マーチャント４０が属する国の通貨単位での販売額を、消費者３０が属する国の通貨単位での支払額に変換して出力する。

支払額が決定して商品等の購入契約が締結されると、その後、ＥＣ決済ゲートウェイ１０の銀行入出金管理部１１は、入出金用銀行口座２０に消費者３０から上記の支払額が入金されたかどうかを監視する（Ｓ０２）。消費者３０が入金する先の入出金用銀行口座２０は、通貨種別に応じてＥＣ決済ゲートウェイ１０が指定する。例えば、図１の例において、日本円での支払いの場合には、日本円での入出金を受け付ける入出金用銀行口座２０ａを指定する。銀行入出金管理部１１は、各入出金用銀行口座２０への入金の有無を定期的に確認する。新たな入金があった場合は、その通貨種別と金額、および支払先のマーチャント４０に係る情報をＧＷ口座管理部１３に通知する。

なお、支払先のマーチャント４０に係る情報は、例えば、消費者３０が入出金用銀行口座２０に振込等により入金する際に入力する振込情報に、マーチャント４０を特定するＩＤ等の情報や、対象の取引の注文番号などを入力させることで把握することができる。例えば、マーチャント４０を特定するＩＤ等の情報が指定された場合は、ＥＣ決済ゲートウェイ１０においてマーチャント管理マスタ１７を参照することでマーチャント４０を特定することができる。また、注文番号が措定された場合は、例えば、マーチャント４０において購買契約が締結された際に、その注文番号とマーチャント４０の情報を予めＷｅｂサーバ４１がネットワーク５０などを介してＥＣ決済ゲートウェイ１０に送信しておくことで、マーチャント４０を特定することができる。

消費者３０からの入金が把握できた場合、その通知を受領したＧＷ口座管理部１３は、当該入金に係る通貨種別および入金額に対応する（すなわち、等価値の）仮想通貨（ＲｉｐｐｌｅではＩＯＵ）を発行し、さらに、発行した仮想通貨を、対象のマーチャント４０と関連付けられたマーチャント口座へ送金する（Ｓ０３）。

マーチャント口座管理部１４は、各マーチャント口座への入金を監視しており、対象のマーチャント口座に仮想通貨の入金があったことを検知した場合に、その通貨種別が、当該マーチャント４０が受け取りを許可する通貨種別と一致しない場合、マーケットメーカー１６に対して、入金された仮想通貨の通貨種別を当該マーチャント４０が受け取りを許可する通貨種別へ交換する両替注文を出す（Ｓ０４）。例えば、￥１，０００を＄１０に交換するために「売り：￥１，０００／買い：＄１０」の両替注文を出す。なお、各マーチャント４０が受け取りを許可する通貨種別の情報は、上述したように、マーチャント管理マスタ１７などに予め登録されている。

一方で、マーチャント口座に入金された仮想通貨の通貨種別が、当該マーチャント４０が受け取りを許可する通貨種別と一致する場合、もしくは、上記の両替注文が約定して受け取りを許可する通貨種別の仮想通貨がマーチャント口座に入金された場合、マーチャント口座管理部１４は、対象のマーチャント口座に入金された仮想通貨を全額ＧＷ口座１３ａに送金（ＲｉｐｐｌｅではＩＯＵの償還）する（Ｓ０５）。

ＧＷ口座管理部１３は、ＧＷ口座１３ａへの仮想通貨の入金を監視しており、マーチャント口座からの仮想通貨の入金を検知した場合に、その通貨種別および入金額に対応する（すなわち、等価値の）現実通貨での金額、および入金元のマーチャント口座に対応するマーチャント４０の銀行口座４２の情報を銀行入出金管理部１１へ送信して出金の依頼を行う（Ｓ０６）。対象のマーチャント４０の銀行口座４２の情報は、上述したように、マーチャント管理マスタ１７などに予め登録されている。

銀行入出金管理部１１は、ＧＷ口座管理部１３から受け取った通貨種別と金額、および銀行口座４２の情報に基づいて、対象の通貨種別を取り扱う入出金用銀行口座２０（図１の例では米国ドルでの入出金を受け付ける入出金用銀行口座２０ｂ）から、対象のマーチャント４０の銀行口座４２に対して振込や送金などの実際の出金処理を行う（Ｓ０７）。以上の一連の処理により越境ＥＣでの決済が完了する。

＜処理の流れ（現地通貨での価格決定）＞
図５は、図４のステップＳ０１の現地通貨での価格決定処理の流れの例について示したシーケンス図である。現地通貨での支払価格の取得要求を受けたＥＣ決済ゲートウェイ１０のプライスコンバータ１５は、まず、マーケットメーカー１６に対して、注文板情報に基づく平均取得レートの計算指示を行う。指示を受けたマーケットメーカー１６では、まず、仮想通貨交換エンジン１２に対してコマンド等を発行し、対象の通貨種別間の両替注文の板情報、すなわちオーダーブック１６ａの情報を取得する。そして、オーダーブック１６ａの情報に基づいて、後述する手法などにより平均取得レートを計算し、プライスコンバータ１５に応答する。プライスコンバータ１５では、平均取得レートと商品等の販売額とに基づいて、消費者３０の現地通貨での支払額を計算する。

図６は、図５の例における平均取得レートの計算処理の流れの例について示したフローチャートである。まず、両替注文の一覧について処理を繰り返すループ処理を開始する（Ｓ１１）。ループ処理では、まず、対象の両替注文に基づいて両替済の金額を更新するための準備処理として、対象の両替注文に係る交換後の価格（以下では「α」と記載する）を計算し、これまでの両替済金額の合計（以下では「Ａ」と記載する）に「α」を加算した両替済金額「Ａ＋α」を計算する。なお、両替注文の情報は、例えば、「１＄＝￥１００のレートで、￥５，０００分交換する」というように、交換レートと交換対象金額の情報を含むものとする。

次に、両替済金額「Ａ＋α」が、販売国の通貨での販売額以上となっているか否かを判定する（Ｓ１３）。「Ａ＋α」が販売額に満たない場合は、これまでの両替済金額を更新する（Ｓ１４）。すなわち、「Ａ＋α」を新たな「Ａ」として、次の両替注文の処理に移る（Ｓ１５、Ｓ１１）。

一方で、ステップＳ１３において「Ａ＋α」が販売額以上となっている場合は、両替済金額の「Ａ＋α」が販売額と同額になるよう平均取得レートを調整する（Ｓ１６）。例えば、「α」を追加する前の「Ａ」の額が販売額に満たない場合は、以下の式により平均取得レートを計算する。

平均取得レート＝平均取得レート＋
対象の両替注文における交換レート×（販売額−Ａ）／Ａ
その後、ループ処理を終了し、ステップＳ１６で算出した平均取得レートを返却して（Ｓ１７）、処理を終了する。以上の一連の処理により、オーダーブック１６ａにおける両替注文の板情報に基づいて、対象の通貨種別間での仮想通貨における交換レートの平均を取得することができる。

＜処理の流れ（入金監視、仮想通貨発行）＞
図７は、図４のステップＳ０２の入金監視処理およびステップＳ０３の仮想通貨発行処理の流れの例について示したシーケンス図である。まず、消費者３０が、ＥＣ決済ゲートウェイ１０が指定する入出金用銀行口座２０に対して実際の入金を行う。銀行入出金管理部１１は、定期的に当該口座に対する入金の有無を確認することにより、入金を検知し、必要に応じて消費者３０に対して入金を確認した旨の通知を行う。例えば、消費者３０に対して電子メールを送付する等により入金確認の通知を行うことができる。

入金を検知した銀行入出金管理部１１は、ＧＷ口座管理部１３に対して、入金された通貨種別と金額に対応する（すなわち、等価値の）仮想通貨（ＲｉｐｐｌｅではＩＯＵ）の発行指示を行う。発行指示を受けたＧＷ口座管理部１３は、仮想通貨発行および送金のためのコマンド等からなるトランザクションを作成して、これを仮想通貨交換エンジン１２に対して実行する。これにより、仮想通貨交換エンジン１２によって仮想通貨が発行されるとともに、発行された仮想通貨が対象のマーチャント４０に関連付けられたマーチャント口座に対して送金される。

＜処理の流れ（両替注文指示、償還指示）＞
図８は、図４のステップＳ０４の両替注文指示処理およびステップＳ０５の償還指示処理の流れの例について示したシーケンス図である。まず、マーチャント口座管理部１４は、各マーチャント４０に関連付けられたマーチャント口座に対して仮想通貨の入金トランザクションが存在しないかを、仮想通貨交換エンジン１２に対して定期的に確認する。仮想通貨交換エンジン１２からのレスポンスによって入金があったことを検知すると、次に通貨種別の判定を行う。具体的には、仮想通貨交換エンジン１２からのレスポンスの内容から入金に係る通貨種別の情報を取得する。また、マーチャント管理マスタ１７を参照して、対象のマーチャント口座（もしくはこれに関連付けられたマーチャント４０）が受け取りを許可している通貨種別の情報を取得する。そして、これらの通貨種別が一致するか否かを判定する。

通貨種別が一致しない場合は、受け取りを許可する通貨種別へ交換するための両替指示の処理を行う。具体的には、まず、マーチャント口座管理部１４は、仮想通貨を両替するためのコマンド等からなるトランザクションを作成して、このトランザクションメッセージを含む両替指示をマーケットメーカー１６に対して送信する。マーケットメーカー１６は、受け取ったトランザクションメッセージを仮想通貨交換エンジン１２に対して送信することにより、仮想通貨交換エンジン１２が両替用のトランザクションを実行して通貨種別間での仮想通貨の両替を行う。

一方、入金された通貨種別と、対象のマーチャント４０が受け取りを許可する通貨種別とが一致する場合は、入金された仮想通貨をＧＷ口座１３ａへ送金するための償還指示の処理を行う。具体的には、まず、マーチャント口座管理部１４は、仮想通貨をＧＷ口座１３ａへ送金するためのコマンド等からなるトランザクションを作成して、これを仮想通貨交換エンジン１２に対して実行する。これにより、仮想通貨交換エンジン１２によって対象のマーチャント口座内の仮想通貨がＧＷ口座１３ａに送金される。その後、ＧＷ口座管理部１３は、銀行入出金管理部１１に対して対象のマーチャント４０の銀行口座４２への出金依頼を行うが、この処理の詳細については後述する。

＜処理の流れ（出金依頼、出金処理）＞
図９は、図４のステップＳ０６の出金依頼処理およびステップＳ０７の出金処理の流れの例について示したシーケンス図である。まず、ＧＷ口座管理部１３は、ＧＷ口座１３ａに対して仮想通貨の入金トランザクションが存在しないかを、仮想通貨交換エンジン１２に対して定期的に確認する。仮想通貨交換エンジン１２からのレスポンスによって入金があったことを検知すると、次に、出金依頼の内容を作成する。具体的には、仮想通貨交換エンジン１２からのレスポンスの内容から入金に係る通貨種別と金額の情報、および入金元のマーチャント口座の情報を取得する。そして、マーチャント管理マスタ１７を参照し、マーチャント口座に関連付けられたマーチャント４０および銀行口座４２の情報を取得し、仮想通貨の通貨種別と入金額に対応する（すなわち、等価値の）現実通貨での金額の情報、および銀行口座４２の情報を出金依頼の内容として作成する。

その後、出金依頼の内容を銀行入出金管理部１１へ送信して出金依頼を行う。銀行入出金管理部１１は、受け取った出金依頼の内容に基づいて、対象の通貨種別を取り扱う入出金用銀行口座２０から対象の銀行口座４２への実際の送金を、銀行等が提供する振込サービスや送金サービスに対して指示する。銀行等が提供する振込サービス等は、指示された内容に従って、入出金用銀行口座２０から対象のマーチャント４０の銀行口座４２に対して実際の送金を行う。以上の一連の処理により越境ＥＣでの決済処理を行うことができる。

以上に説明したように、本発明の一実施の形態である決済システム１によれば、消費者３０と海外のマーチャント４０との間にＥＣ決済ゲートウェイ１０を設け、取引毎に直接為替交換を行って決済するのではなく、ＥＣ決済ゲートウェイ１０内でいったん仮想通貨に変換し、仮想通貨による通貨種別間の両替注文をオーダーブック１６ａにおける板情報として管理し、相対する注文をマッチングさせる。これにより、仮想通貨交換ネットワークにおける市場の為替レートを用いることができ、消費者は、当該為替レートによって決定された金額を支払えばよく、スプレッドの影響を回避して、商品購入時の費用負担を低減させることができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、越境ＥＣにおける決済を支援する決済システムおよび決済方法に利用可能である。

１…決済システム、
１０…ＥＣ決済ゲートウェイ、１１…銀行入出金管理部、１２…仮想通貨交換エンジン、１３…ＧＷ口座管理部、１３ａ…ＧＷ口座、１４…マーチャント口座管理部、１４ａ…日本口座、１４ｂ…米国口座、１４ｃ…中国口座、１５…プライスコンバータ、１６…マーケットメーカー、１６ａ…オーダーブック、１７…マーチャント管理マスタ、
２０、２０ａ〜２０ｃ…入出金用銀行口座、
３０…消費者、３１…消費者端末、
４０…マーチャント、４１…Ｗｅｂサーバ、４２…銀行口座、
５０…ネットワーク

Claims (3)

1. 異なる通貨圏に属するユーザ間の取引に係る決済を行う決済システムであって、
   所定の口座に対する第１の通貨種別による入金を検知し、前記入金に係る金額と等価値の仮想通貨を発行し、相対する注文をマッチングさせた上で等価値の第２の通貨種別による出金を指示する決済ゲートウェイを有する、決済システム。
2. 異なる通貨圏に属するユーザ間の取引に係る決済を行う決済システムにおける決済方法であって、
   前記決済システムが、所定の口座に対する第１の通貨種別による入金を検知する第１のステップと、
   前記決済システムが、前記入金に係る金額と等価値の仮想通貨を発行する第２のステップと、
   前記決済システムが、相対する注文をマッチングさせた上で等価値の第２の通貨種別による出金を指示する第３のステップと、
   を有する、決済方法。
3. 異なる通貨圏に属するユーザ間の取引に係る決済を行う決済システムとして機能するよう、コンピュータに処理を実行させる決済プログラムであって、
   所定の口座に対する第１の通貨種別による入金を検知する第１の処理と、
   前記入金に係る金額と等価値の仮想通貨を発行する第２の処理と、
   相対する注文をマッチングさせた上で等価値の第２の通貨種別による出金を指示する第３の処理と、
   を前記コンピュータに実行させる、決済プログラム。

Images