JPWO2021095266A5

JPWO2021095266A5 -

Info

Publication number: JPWO2021095266A5
Application number: JP2021555775A
Authority: JP
Filing date: 2019-11-15
Publication date: 2022-04-18
Anticipated expiration: 2039-11-15

Description

本発明は、ブロックチェーンで管理される取引の決済を行う制御方法、制御プログラム、情報処理装置および制御システムに関する。

近年、仮想通貨等の暗号資産の取引が増大しており、非中央集権型で運営の透明性を確保できる分散台帳管理技術として、ブロックチェーンの有用性が期待されている。ブロックチェーン上で管理される資産、例えば、暗号資産は、暗号技術で保護され、現実世界の物品やサービスとも交換できる価値を有し、現金に代わる決済手段として活用されてきている。

また、暗号資産のブロックチェーン間にスマートコントラクトが仲介することで、資産管理用の台帳を管理する暗号資産チェーンと、サービスへの対価として支払う決済トークン管理用の台帳を管理する決済トークンチェーンと、を連携させることができる。

従来、取引の決済に関連する技術として、例えば、ホストで管理する利用者のアカウントから利用者の端末に電子マネーの配分を送信することで、配分された電子マネーの上限額で代金支払いを行う技術がある（例えば、下記特許文献１参照。）。また、スマートコントラクトによるエスクロー決済の取引に連動して勘定系操作を実行し、利用者の口座の預金額と商品価格を比較することで、取引の成否を判定する技術がある（例えば、下記特許文献２参照。）。また、利用者の電子マネーを用いた即時決済の可否をサーバの与信手続きにより判断する技術がある（例えば、下記特許文献３参照。）。

特表２０１４－５３０４３３号公報特開２０１８－１３９０６８号公報国際公開第２００７／０１８１１９号

ブロックチェーンで管理された取引において、暗号資産を他者に譲渡する際の記録、例えば、取引データの正当性チェックを行う際には、ブロックチェーン上の全記録を調べて、二重取引や残高不足が起きていないかのチェックを行っている。従来技術では、スマートコントラクトの機能を用いても、このチェック時には、管理ノードであるサーバへのアクセスが不可欠であり、利用者がブロックチェーンにアクセスできない環境の場合には、チェックが行えず、取引に不便が生じた。例えば、利用者が海外旅行先で取引を決済する際、決済端末が与信の情報を管理するサーバへ接続できない通信環境の場合等には、クレジット決済（後払い）を完了できない状態が生じた。このように、従来のブロックチェーンを用いた決済技術には問題があった。

一つの側面では、本発明は、ブロックチェーンを用いた新しい決済技術を提供することを目的とする。

本発明の一側面によれば、第１の通貨を扱う第１のブロックチェーンと、第２の通貨を扱う第２のブロックチェーンの連携を情報処理装置で制御する制御方法において、前記情報処理装置のコンピュータは、利用者から第２の通貨の発行依頼を受け付けると、前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定するとともに、前記支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信し、前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収する指示を前記第１のブロックチェーンに送信する、処理を実行する制御方法が提案される。

本発明の一態様によれば、異なる通貨による決済手続きの煩雑さを低減できるという効果を奏する。

図１は、実施の形態にかかる取引処理にかかる情報処理装置を含む制御システムの説明図である。図２は、実施の形態にかかる情報処理装置を含むブロックチェーンの構成例を示す図である。図３は、実施の形態にかかる情報処理装置の構成例を示すブロック図である。図４は、実施の形態にかかる情報処理装置のハードウェア構成例を示す図である。図５は、実施の形態にかかる情報処理装置が行う取引の処理例を示すフローチャートである。図６は、実施の形態にかかる情報処理装置が行う取引の他の処理例を示すフローチャートである。図７は、実施の形態にかかる情報処理装置が行う取引の具体例を示す説明図である。

以下に図面を参照して、開示の制御方法、制御プログラム、情報処理装置および制御システムの実施の形態を詳細に説明する。

開示の技術は、異なるブロックチェーン（ＢＣ）である資産管理用の台帳（例えば、暗号資産チェーン）と、サービスへの対価として支払う決済トークン管理用の台帳（決済トークンチェーン）と、を情報処理装置のスマートコントラクトの機能で連携させる。そして、運営者等の決済トークンの発行元は、利用者の取引の信用度をスコア化した信用度スコアに応じて、決済トークンチェーンに設けられた口座（例えば、クレジット口座）に支払許容額の情報を含むトークンを払い出す。

決済トークンチェーン内で利用者の商品購入毎の取引は、トークンが示す支払許容額内でオフライン動作可能、すなわち、決済トークンチェーン内のみで取引処理でき、外部（暗号資産チェーン等）との通信を不要にできる。

そして、情報処理装置のスマートコントラクトは、決済トークンチェーンにおいて、クレジット口座から店舗などの他者の口座への送金を監視し、送金額に相当する暗号資産建てでの代金支払いを決済日等に定期的に請求する。そして、暗号資産での代金支払いが遅延したり、支払いに失敗したりした場合にはペナルティとして利用者の信用度スコアを低く変化させ、次回からクレジット口座へ払い出す決済トークンの量を減らす等の処理を行う。

一般には、暗号資産を使った取引では前払いが必須となっている。これに対し、実施の形態では、一定額の預託金や、支払い能力の信用情報を示すトークンを生成し、ブロックチェーン間でトークンを受け渡すことで、実際の通貨等の前払いを不要にする。また、取引毎のブロックチェーン外部への通信接続が必要な与信手続きを不要として、決済日に一括した後払いを実現する。また、利用者の取引毎に速やかに店舗等への代金支払いを実現する。

（実施の形態）
図１は、実施の形態にかかる取引処理にかかる情報処理装置を含む制御システムの説明図である。制御システム１００は、複数のサーバＡ～Ｃ（１０１～１０３）と、端末１１０を含み構成される。

サーバＡ（１０１、第１のサーバ）は、利用者の暗号資産チェーンＡを管理し、暗号資産（暗号通貨、Ｙコイン、第１の通貨）を管理する。Ｙコインは、銀行などが運営する、法定通貨との交換が可能な暗号資産（いわゆるステーブルコイン）であってもよい。サーバＡ（１０１）は、暗号資産チェーンＡ上の利用者口座、運営者口座等に対するＹコインの送金を制御する。

サーバＢ（１０２、第２のサーバ）は、利用者が取引を行う決済トークンチェーンＢを管理し、暗号資産（暗号通貨、Ｄコイン、第２の通貨）を管理する。例えば、サーバＢ（１０２）は、クレジットカード会社などが運営し、店舗でのサービス代金支払いに使える決済トークン（支払い可能なＤコインに相当）を管理する。サーバＢ（１０２）は、決済トークンチェーンＢ上の店舗口座およびクレジット口座等に対するＤコインの送金を制御する。

サーバＣ（１０３）は、実施の形態の情報処理装置に相当し、スマートコントラクトの機能を有し、サーバＡ（１０１）およびサーバＢ（１０２）間に配置される。サーバＣ（１０３）は、サーバＡ（１０１）およびサーバＢ（１０２）との間でネットワーク通信を行い、異なるブロックチェーンである暗号資産チェーンＡと、決済トークンチェーンＢ間での資産の情報のやり取りを仲介する。

サーバＣ（１０３）は、暗号資産チェーンＡのＹコインと決済トークンチェーンＢのＤコインとを互いに所定レートで送金する機能を有する。そして、実施の形態では、サーバＣ（１０３）は、利用者の信用情報と、取引情報をそれぞれ信用情報データベース（ＤＢ）１２１と、取引履歴ＤＢ１２２に保持する。

信用情報ＤＢ１２１は、例えば、利用者が暗号資産チェーンＡ上で保有する暗号資産の評価、例えば、保有するＹコインの評価額や、利用者の過去の取引で算出された所定の信用度スコア等からなる。取引履歴ＤＢ１２２は、利用者が決済トークンチェーンＢ上で決済を行った過去の履歴、例えば、商品購入毎の日時や購入額（Ｙコイン）等を蓄積保持してなる。

端末１１０は、取引を行う利用者が保持し、ネットワークを介してサーバＣ（１０３）に通信接続される。

ここで、制御システム１００を利用する利用者は、Ｙコインの暗号資産チェーンＡと、Ｄコインの決済トークンチェーンＢの両方に口座を持っているものとする。サーバＣ（１０３）は、利用者が決済トークンチェーンＢの店舗で商品購入等の取引を行う以前の時期に、利用者の取引の信用情報（トークン）を生成し、決済トークンチェーンのサーバＢ（１０２）に送信する。

例えば、トークンは、利用者が保有する暗号資産（Ｙコイン）に基づき、利用者が決済トークンチェーンＢで取引できる支払許容額（トークン量）を含む情報である。

情報処理装置であるサーバＣ（１０３）は、下記の処理１．～４．を順次実行する。
１．「決済前の利用者によるＤコインの発行依頼」
２．「決済トークンチェーンＢへのＤコインの送金」
３．「決済トークンチェーンＢ上でのＤコインの取引」
４．「取引集計とＹコインの徴収」

１．の処理について、決済トークンチェーンＢ上で利用者が取引を行う予定である場合、この取引を行う以前の時期において、利用者は、端末１１０を操作して、サーバＣ（１０３）に対し、Ｄコインの発行（払い出し）を依頼しておく（ステップＳ１０１）。例えば、利用者は、海外旅行中に予定する決済総額相当の発行を依頼する。この際、利用者は、異なる通貨であるＤコイン、あるいはＤコイン額に相当するＹコインの発行を依頼でき、サーバＣ（１０３）は、発行依頼がＹコインであれば、Ｙコイン額をレート換算したＤコイン額を算出する。

サーバＣ（１０３）は、利用者の発行依頼により、利用者の取引の信用情報として取引できる支払許容額（トークン）を生成する。そして、サーバＣ（１０３）は、信用情報ＤＢ１２１にアクセスし、利用者が保有する暗号資産チェーンＡ上でのＹコインの所有量に基づき、払い出しの発行限度額をチェックし、発行（払い出し）の可否を判断する。例えば、サーバＣ（１０３）は、利用者が発行依頼したＤコイン（ＹコインをＤコインにレート換算後）の払い出しの要求額が発行限度額以下であれば、この発行（払い出し）依頼を許可し、所定の支払許容額を示すトークンを生成する。

２．の処理では、サーバＣ（１０３）は、払い出しの許可時には、支払許容額に相当するＤコイン（トークン）を暗号資産チェーンＡのサーバＡ（１０１）から決済トークンチェーンＢのサーバＢ（１０２）に送金させる（ステップＳ１０２）。これにより、利用者は、海外旅行中に支払許容額の範囲内でＤコインを用いた商品購入等の取引が行える。

上記１．２．の処理は、利用者が実際の取引を行う以前の時期に行う処理であり、この後、３．の処理で利用者が実際に商品購入を行う。

３．の処理では、利用者は、店舗での商品購入等毎に決済トークンチェーンＢでＤコインの支払取引を行う。このＤコインの支払取引毎の情報は、決済トークンチェーンＢのサーバＢ（１０２）からサーバＣ（１０３）に通知される（ステップＳ１０３）。サーバＣ（１０３）は、利用者のＤコインの支払取引毎の情報（例えば、商品購入日やＤコイン額等）を取引履歴ＤＢ１２２に蓄積する。

３．の処理時点において、決済トークンチェーンＢのサーバＢ（１０２）は、利用者の支払取引毎にサーバＣ（１０３）、さらには暗号資産チェーンＡのサーバＡ（１０１）と通信を行う必要がない。トークンが示す支払許容額（送金済みのＤコイン）を用いて取引毎の処理を逐次実行する。トークンは、支払許容額を示す情報であるため、暗号資産チェーンＡと決済トークンチェーンＢ間では、実際の通貨の送金（資金移動）を不要にすることができる。

４．の処理では、サーバＣ（１０３）は、例えば、毎月に設定した決済日になると、利用者によるＤコインの取引毎の集計を行い、集計したＤコインをレート換算したＹコインでの一括決済を行う。この際、サーバＣ（１０３）は、サーバＡ（１０１）にアクセスし、集計したＹコインを暗号資産チェーンＡの利用者口座から徴収させる（ステップＳ１０４）。また、サーバＣ（１０３）は、利用者によるＤコインでの支払取引が決済トークンチェーンＢに記録されると、Ｄコインに対応する価値を有するＹコインを、暗号資産チェーンＡ上の利用者の口座から徴収する指示を暗号資産チェーンＡのサーバＡ（１０１）に送信してもよい。このように、利用者の実際の資金移動（Ｙコインの徴収）は、暗号資産チェーンＡ内でのみ行うことができる。実施の形態では、便宜上、Ｄコインの送金として説明しているが、実際には支払許容額を示すトークンの送信である。

以上の処理１．～４．により、トークンの払い出しのみでは決済は発生せず、決済トークンチェーンＢのサーバＢ（１０２）は、利用者の支払取引毎に、Ｄコインの送金額（支払許容額）の範囲内で支払取引を行う。そして、サーバＣ（１０３）は、決算日等に一括して暗号資産チェーンＡのサーバＡ（１０１）に複数の支払取引を集計した取引総額の代金徴収を行わせる。このようにして、スマートコントラクト（サーバＣ）は、暗号資産チェーンＡと決済トークンチェーンＢを仲介し、決済時に暗号資産チェーンＡの利用者口座から自動引き落とさせる。

上記の１．～４．の処理は、主に実施の形態のサーバＣ（１０３）が行う基本的な処理内容を示している。このほか、サーバＣ（１０３）は、上記の４．の処理で代金徴収に失敗した場合に、信用情報ＤＢ１２１の信用度スコアを低く変更（信用の格下げ）する処理を行わせてもよい。この場合、サーバＣ（１０３）は、２．の処理では、発行（払い出し）するＤコインの額を減らすことができる。

このほか、２．の処理では、サーバＣ（１０３）は、Ｄコインの口座残高に応じて発行限度額を変更してもよい。例えば、サーバＣ（１０３）は、利用者からの１．Ｄコインの発行（払い出し）依頼時毎に暗号資産チェーンＡからＤコインの口座残高を取得し、取得した口座残高に応じた所定の発行限度額を設定し、信用情報ＤＢ１２１に更新保持してもよい。

さらには、２．の処理移行の時期、例えば、利用者による決済を行うまでの期間中において、利用者の操作により、１．の処理でＤコインの再度の発行（払い出し）依頼をすることもできる。例えば、海外旅行中においてＤコインの利用額が多くなった場合、払い出しの要求額を追加依頼することもできる。

実施の形態では、上記の３．の処理に示した、利用者が商品購入等を行う際には、決済にかかる「与信」等の処理を不要にできる。この際、決済トークンチェーンＢは、既に２．の処理で支払許容額を示すＤコイン（トークン）が送金済みの状態である。したがって、決済トークンチェーンＢのサーバＢ（１０２）は、決済トークンチェーンＢ内での処理だけで取引でき、取引毎にサーバＣ（１０３）や暗号資産チェーンＡ（１０１）に対し通信接続することなく（オフライン動作可能に）取引を行うことができる。

また、上記の３．の処理では、決済トークンチェーンＢのサーバＢ（１０２）は、利用者の取引毎にサーバＣ（１０３）、さらには暗号資産チェーンＡのサーバＡ（１０１）と通信を行わずとも、送金済みのＤコインにより支払取引毎の処理を逐次実行できる。例えば、利用者が通信環境が悪い地域等の海外旅行先で商品購入を行った際、決済トークンチェーンＢのサーバＢ（１０２）がサーバＣ（１０３）と通信できない状態が生じても、クレジット決済等の支払取引を完了できるようになる。このように、実施の形態によれば、利用者が商品購入する際、与信の情報を管理するサーバへの接続を不要にできる。

図２は、実施の形態にかかる情報処理装置を含むブロックチェーンの構成例を示す図である。異なる２つのブロックチェーンとして上述した暗号資産チェーンＡと、決済トークンチェーンＢを示し、スマートコントラクト（サーバＣ）１０３は、これら暗号資産チェーンＡと、決済トークンチェーンＢに通信接続して相互の取引を仲介する。サーバＣ（１０３）は、信用情報ＤＢ１２１と、取引履歴ＤＢ１２２のＤＢを有する。

暗号資産チェーンＡは、利用者が有する利用者口座２０１と、暗号資産チェーンＡの運営者が有する運営者口座２０２を含み、上記のサーバＡ（１０１）は、これら利用者口座２０１、運営者口座２０２にアクセス可能である。

決済トークンチェーンＢは、商品を販売する店舗口座２１１と、利用者が保有するクレジット口座２１２を含み、上記のサーバＢ（１０２）は、これら店舗口座２１１、クレジット口座２１２にアクセス可能である。

図２を用いて上記１．～４．の各処理に対応し、暗号資産チェーンＡ、決済トークンチェーンＢ、およびスマートコントラクト（サーバＣ）１０３がそれぞれ行う取引の流れを説明する。

はじめに、１．「決済前の利用者によるＤコインの払い出し依頼」で、利用者から払い出しの要求額が入力される。これにより、スマートコントラクト（サーバＣ）１０３は、信用情報ＤＢ１２１に保持された信用情報に基づき、Ｄコインの支払許容額を決定する（ステップＳ２０１）。

この後、２．「決済トークンチェーンＢへのＤコインの送金」の処理として、スマートコントラクト（サーバＣ）１０３は、運営者口座２０２が保有する支払許容額（Ｄコイン）を決済トークンチェーンＢのクレジット口座２１２に払い出す（ステップＳ２０２）。より詳細には、決済トークンチェーンＢ上の利用者の払い出し口座に送金後、払い出し口座からクレジット口座２１２に払い出される。

この後、利用者の取引毎に、決済トークンチェーンＢのサーバＢ（１０２）は、３．「決済トークンチェーンＢ上でのＤコインの取引」にかかる処理を行う。この際、サーバＢ（１０２）は、利用者の商品購入等の取引毎に、クレジット口座２１２の口座残高の範囲内での取引を許可する。

そして、サーバＢ（１０２）は、利用者の取引毎に、クレジット口座２１２から取引額相当のＤコインを店舗口座２１１に送金し（ステップＳ２０３）、クレジット口座２１２の口座残高を次回以降の支払限度額に設定する（ステップＳ２０４）。また、サーバＢ（１０２）は、取引毎の取引情報をスマートコントラクト（サーバＣ）１０３に通知する（ステップＳ２０５）。これにより、スマートコントラクト（サーバＣ）１０３は、取引毎の履歴を取引履歴ＤＢ１２２に蓄積でき、取引履歴ＤＢ１２２の情報は、決済トークンチェーンＢ上での利用者の取引に同期させることができる。

この後、スマートコントラクト（サーバＣ）１０３は、決算日等の所定の時期において、４．「取引集計とＹコインの徴収」の処理を行い、取引集計されたＹコインを暗号資産チェーンＡの利用者口座２０１から運営者口座２０２に支払う（ステップＳ２０６）。決算日は、例えば、利用者が設定した海外旅行終了後の日時や、予めクレジット決済日として設定された日時等である。徴収するＹコインは、Ｄコインのレート換算後の利用者の取引総額である。

図３は、実施の形態にかかる情報処理装置の構成例を示すブロック図である。主に、情報処理装置であるスマートコントラクト（サーバＣ）１０３の機能を示し、サーバＣ（１０３）に通信接続される暗号資産チェーンＡ（サーバＡ）１０１と、決済トークンチェーンＢ（サーバＢ）１０２の機能を併記してある。

暗号資産チェーンＡのサーバＡ（１０１）と、決済トークンチェーンＢは、それぞれ汎用の分散台帳管理部３１１，３２１を有する。サーバＡ（１０１）の分散台帳管理部３１１は、暗号資産チェーンＡ内の利用者口座２０１、運営者口座２０２を管理するとともに、サーバＣ（１０３）との間の情報をやり取りする。サーバＢ（１０２）の分散台帳管理部３２１は、決済トークンチェーンＢ内の店舗口座２１１、クレジット口座２１２を管理するとともに、サーバＣ（１０３）との間の情報をやり取りする。

スマートコントラクト（サーバＣ）１０３は、上述した信用情報ＤＢ１２１および取引履歴ＤＢ１２２と、受付部３０１、払い出し金額決定部３０２、送金実行部３０３、送金検出部３０４の機能を有する。また、徴収・返金額決定部３０５、引き落とし実行部３０６、の機能を有する。

受付部３０１は、サービスを利用する暗号資産の利用者の端末１１０に通信接続され、利用者の端末１１０の操作により、Ｄコインでの取引を行う以前の時期に上述した取引の払い出しの要求額の利用申し込みを受け付ける。例えば、利用者は、所定の認証データ（例えば、許可コード）を用いて利用申し込みする。この利用申し込みは、暗号資産チェーンＡ上で利用者の暗号資産（Ｙコイン）を保持する利用者口座２０１から、指定した運営者口座２０２への上限付きの資産移転取引の実行の許可要求に相当する。

許可コードは、Ｙコインを利用者口座２０１からクレジット会社の口座（クレジット口座）２１２へ移転することに同意したことを示す認証情報である。この許可コードには、移転の上限である発行限度額と、有効期限が設定されている。サーバＣ（１０３）は、受け付けた許可コードをメモリ等に保持しておき、決済時に再度利用する。

払い出し金額決定部３０２は、受付部３０１が受け付けた許可コードにより、利用者の支払い能力を管理する信用情報ＤＢ１２１に格納されている信用情報と、許可コードに指定されている払い出し額を抽出する。そして、払い出し金額決定部３０２は、信用情報の発行限度額内での払い出しの要求額であれば、決済トークンチェーンＢ上の利用者のクレジット口座２１２に送金する所定の支払許容額（トークンに相当）を決定する。

送金実行部３０３は、払い出し金額決定部３０２が決定した支払許容額（トークン量）を暗号資産チェーンＡの利用者口座２０１から決済トークンチェーンＢの利用者口座（例えば、クレジット口座２１２）に送金させる。

送金検出部３０４は、決済トークンチェーンＢ上で発生する口座（店舗口座２１１，クレジット口座２１２等）間の送金取引の全てをモニターし、検出した送金取引の送金元口座番号（クレジット口座２１２）と、送金額の組を取引履歴ＤＢ１２２に記録する。

徴収・返金額決定部３０５は、取引履歴ＤＢ１２２に記録された決済トークンチェーンＢ上の利用者口座（クレジット口座２１２）が送金元となっている送金履歴を決済日に対応する一定期間毎に取得する。そして、徴収・返金額決定部３０５は、決算日に送金額の合計額に相当する暗号資産を許可コードに含まれる情報を使って暗号資産チェーンＡ上の利用者口座２０１から徴収すべき暗号資産（Ｙコイン）の決算払いの金額を決定する。

また、徴収・返金額決定部３０５は、利用者によるシステム利用を停止したい場合、例えば、利用者が決済トークンチェーンＢに送金したトークンについて、運営者等の指定口座に取引後の残りのトークン量（全残額の資産移転）を行う。この場合、徴収・返金額決定部３０５は、支払許容額から取引での支払額を差し引いた返金手続きを実施し、保管してある許可コードを破棄し、確定した決済金額を利用者口座２０１に返金（清算）する。

引き落とし実行部３０６は、徴収・返金額決定部３０５の決済払いの金額の決定を受けて、利用者口座２０１から決済トークン発行者の指定口座（例えば、運営者口座２０２）へ暗号資産（Ｙコイン）の資産移転を実行する。

図４は、実施の形態にかかる情報処理装置のハードウェア構成例を示す図である。上述した情報処理装置（スマートコントラクト）の機能を有するサーバＣ（１０３）は、例えば、図４に示すハードウェアで構成することができる。

例えば、サーバＣ（１０３）は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）４０１、メモリ４０２、ネットワークインタフェース（ＩＦ）４０３、記録媒体ＩＦ４０４、記録媒体４０５、を含む。４００は各部を接続するバスである。

ＣＰＵ４０１は、サーバＣ（１０３）の全体の処理を司る処理部として機能する演算処理装置である。メモリ４０２は、不揮発性メモリおよび揮発性メモリを含む。不揮発性メモリは、例えば、ＣＰＵ４０１のプログラムを格納するＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）である。揮発性メモリは、例えば、ＣＰＵ４０１のワークエリアとして使用されるＤＲＡＭ（ＤｙｎａｍｉｃＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）、ＳＲＡＭ（ＳｔａｔｉｃＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）等である。

ネットワークＩＦ４０３は、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）、ＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）、インターネットなどのネットワーク４１０に通信接続するインタフェースである。このネットワークＩＦ４０３を介して、サーバＣ（１０３）は、外部のサーバＡ（１０１）、サーバＢ（１０２）、端末１１０に通信接続する。

記録媒体ＩＦ４０４は、ＣＰＵ４０１が処理した情報を記録媒体４０５との間で読み書きするためのインタフェースである。記録媒体４０５は、メモリ４０２を補助する記録装置である。記録媒体４０５は、例えば、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）や、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）フラッシュドライブ等を用いることができる。

メモリ４０２または記録媒体４０５に記録されたプログラムをＣＰＵ４０１が実行することにより、図３に示したサーバＣ（１０３）の各機能を実現する。また、メモリ４０２や記録媒体４０５により、図３に示した信用情報ＤＢ１２１、取引履歴ＤＢ１２２等の情報を記録保持する機能を実現できる。

図４に示したハードウェア構成は、図１に示したサーバＡ（１０１）や、サーバＢ（１０２）、さらには端末１１０（例えば、スマートフォン等）にも適用でき、実施の形態の制御システムは、汎用のハードウェア構成を用いて実現できる。ここで、端末１１０は、例えば、タッチパネルを有することで、利用者に対する情報の操作入力および表示出力が行える。

図５は、実施の形態にかかる情報処理装置が行う取引の処理例を示すフローチャートである。サーバＣ（１０３）の制御部（ＣＰＵ４０１）がプログラム実行する利用者の取引にかかる処理例を示す。

はじめに、制御部は、取引の決済前の時期に、利用者の端末１１０の操作により許可コードを受信することで、以下の処理を実行開始する。この許可コードは、利用者によるＤコインの発行（払い出し）依頼の要求額を含み、端末１１０から送信される。

制御部は、許可コードを受信すると、信用情報ＤＢ１２１を参照し、利用者の発行限度額をチェックする（ステップＳ５０１）。そして、制御部は、要求額のＤコインを発行可能か判断する（ステップＳ５０２）。

例えば、制御部は、暗号資産チェーンＡ上の利用者口座２０１が保有するＹコインをＤコインにレート換算し、利用者が保有するＤコインの保有量が要求額以下であればＤコインが発行可能であると判断する（ステップＳ５０２：Ｙｅｓ）。そして、ステップＳ５０４の処理に移行する。一方、利用者が保有するＤコインの保有量が要求額を超えていれば、Ｄコインが発行できないと判断し（ステップＳ５０２：Ｎｏ）、ステップＳ５０３の処理に移行する。

ステップＳ５０３では、制御部は、Ｄコインの発行量を発行限度額以下に変更し（ステップＳ５０３）、ステップＳ５０４の処理に移行する。ステップＳ５０４では、制御部は、Ｄコインの決済トークンチェーンＢ上の利用者口座（例えば、クレジット口座２１２）の取引モニターを開始する（ステップＳ５０４）。

つぎに、制御部は、決定した支払許容額のＤコインを決済トークンチェーンＢ上の利用者口座（クレジット口座２１２）に送金させる（ステップＳ５０５）。すなわち、サーバＣ（１０３）の制御部（ＣＰＵ４０１）は、支払許容額を決済トークンチェーンＢに通知する指示を暗号資産チェーンＡに送信し、支払許容額のＤコインを暗号資産チェーンＡから決済トークンチェーンＢ上の利用者口座（クレジット口座２１２）に送金させる。制御部（ＣＰＵ４０１）は、決算前の時期に、以上の事前処理を行っておく。

この後、制御部は、利用者が決済トークンチェーンＢ上で実際に商品購入等の取引に基づき、ステップＳ５０６以下の処理を実行する。まず、制御部は、利用者の取引による決済トークンチェーンＢ上の利用者口座（クレジット口座２１２）から他へ口座（例えば、店舗口座２１１）への送金取引の検出を判断する（ステップＳ５０６）。

ステップＳ５０６において、送金取引を検出すれば（ステップＳ５０６：Ｙｅｓ）、制御部は、検出した取引の内容を取引履歴ＤＢ１２２に記録し（ステップＳ５０７）、ステップＳ５０８の処理に移行する。一方、送金取引を検出しなければ（ステップＳ５０６：Ｎｏ）、ステップＳ５０８の処理に移行する。

ステップＳ５０８では、制御部は、決済日であるかを判断する（ステップＳ５０８）。現在の日にちが決済日に達していなければ（ステップＳ５０８：Ｎｏ）、ステップＳ５０６の処理に戻る。そして、現在の日にちが決済日となれば（ステップＳ５０８：Ｙｅｓ）、制御部はステップＳ５０９の処理に移行する。

ステップＳ５０９では、制御部は、利用者によるＤコインの利用総額からレート換算によりＹコインでの決済額を決定する（ステップＳ５０９）。そして、許可コードを使って利用者口座２０１から決済額のＹコインを運営者口座２０２に送金する（ステップＳ５１０）。

つぎに、制御部は、送金が成功したか判断する（ステップＳ５１１）。送金が成功であれば（ステップＳ５１１：Ｙｅｓ）、以上の処理を終了する。送金が成功していなければ（ステップＳ５１１：Ｎｏ）、制御部は、信用情報ＤＢ１２１を更新し（ステップＳ５１２）、以上の処理を終了する。

ここで、送金が成功しない場合、例えば、送金時に利用者口座２０１のＹコインの保有量が少なくなり、決済額以下となる等の支払い不能な状況に相当する。この場合、制御部は、信用情報ＤＢ１２１に利用者の支払い不能の情報や、支払い不能の額や回数等に基づき算出した所定の信用度スコア等の情報を格納し、利用者の信用情報を相対的に低く変化させる。

図６は、実施の形態にかかる情報処理装置が行う取引の他の処理例を示すフローチャートである。図６に示す処理（ステップＳ６０１～ステップＳ６１２）は、図５に示した処理（ステップＳ５０１～ステップＳ５１２）と同じである。図６に示す処理では、事前処理の開始時に、新たにステップＳ６００の処理を追加した点が異なる。

ステップＳ６００では、制御部は、利用者の端末１１０から許可コードを受信すると、Ｙコインの利用者口座２０１の口座残高を取得し、残高に応じて発行限度額を決定し、信用情報ＤＢ１２１を更新する（ステップＳ６００）。この後、制御部は、ステップＳ６０１以下の処理を実行する。例えば、発行限度額は、利用者口座２０１の残高以下となるように決定する。また、残高別の所定割合（例えば、５０％～８０％）に決定することもできる。

上記ステップＳ６００の処理により、利用者が暗号資産チェーンＡ上で保有するＹコインの残高に応じた発行限度額が決定でき、この発行限度額の範囲内で支払許容額を算出できるようになる。これにより、利用者が保有するＹコインの残高を反映でき、残高が時間経過とともに大きく変動する場合等に対応して適切な発行限度額、および支払許容額を設定できるようになる。

図７は、実施の形態にかかる情報処理装置が行う取引の具体例を示す説明図である。図５の処理例に対応する具体的な処理例を説明する。

この図７では、利用者は、暗号資産チェーンＡ上に利用者口座２０１ａを有し、決済トークンチェーンＢ上に払い出し口座２０１ｂを有する。サーバＣ（１０３）は、これら利用者口座２０１ａ，払い出し口座２０１ｂの口座残高をモニター可能であるとする。

そして、暗号資産（Ｙコイン）を保有する利用者が、海外旅行先で店舗での支払いにＤコイン（例えば、米ドル相当）を使用するものとする。Ｙは円、Ｄは米ドルを意味する符号であり、決済時の通貨レートは１１０円／ドルであるとする。また、利用者の端末１１０、例えばスマートフォンには、予めウォレットのアプリケーションがインストールされており、署名用の秘密鍵を有する。そして、利用者の操作により、端末１１０の画面には所定のバーコード、例えばＱＲコード（登録商標）等が表示され、指定したＤコインの要求額をＱＲコードで転送できる。

はじめに、利用者は、海外旅行先での商品購入に備えた事前準備として、端末１１０を操作し、許可コードを添えて所定単位のＤコインの発行をスマートコントラクトのサーバＣ（１０３）に送信し、Ｄコインの利用申し込みを行う（ステップＳ７０１）。例えば、利用者は、海外旅行中の支払い用に５００ドル分のＤコインを払い出す要求額で依頼したとする。

これにより、サーバＣ（１０３）は、利用者口座２０１ａの口座残高が５００ドル相当以上（例えば、Ｙコインが５５０００円）を有していれば、要求額の全額を支払許容額に設定する。この場合、サーバＣ（１０３）は、設定した支払許容額５００ドル分のＤコインを利用者の払い出し口座２０１ｂからクレジット口座２１２に移転する（ステップＳ７０２）。ここで、利用者口座２０１ａの口座残高（Ｙコイン）が５万円の場合、サーバＣ（１０３）は、Ｙコインの５万円相当（Ｄコイン換算で４５５ドル相当）を発行限度額とし、この発行限度額を上限とした支払許容額を設定して、Ｄコインを移転させる。

この後、利用者が海外旅行先で複数回の商品購入により、合計３００ドル分のＤコインを使用したとする（ステップＳ７０３）。利用者の口座（払い出し口座２０１ｂ）は取引モニターの対象となっており、Ｄコインは決済トークンチェーンＢの分散台帳管理部３２１で管理されているため、取引の履歴をサーバＣ（１０３）が収集可能である。ここで、利用者が海外旅行中の支払い時、Ｄコインの払い出し口座２０１ｂから別の口座（クレジット口座２１２）へＤコインが移転されるたびに、送金取引が発生する。また、商品購入毎にクレジット口座２１２から店舗口座２１１へ送金取引が発生する。この際、サーバＣ（１０３）は、取引モニターを行っている送金検出部３０４が取引内容を取引履歴ＤＢ１２２に記録する。

ここで、利用者は旅行後の決済日までに、Ｙコインでの利用者口座２０１ａのＹコインの残高が３００ドル分（３００ドル×１１０円／ドル＝３３０００円）以上となるよう、残高をプールしておく（ステップＳ７０４）。

そして、サーバＣ（１０３）は、決算日に取引履歴ＤＢ１２２を参照し、Ｄコインで利用者が使ったＤコインの金額（３００ドル）を集計する。そして、相当額の３３０００円分のＹコインを利用者口座２０１ａから運営者が徴収する運営者口座２０２へ許可コードを用いて代金の徴収を行う（ステップＳ７０５）。

この決算時、利用者の利用者口座２０１ａの残高が足りず、徴収が失敗した場合には、その失敗の回数等に基づいて利用者の信用度スコアを低く変化させ、信用情報ＤＢ１２１に記録する（ステップＳ７０６）。例えば、決算後の徴収が３回失敗することで信用度スコアを半減させ、払い出す支払許容額を半分にし、６回失敗で利用者のシステム利用を禁止する、等の処理を行うことができる。

上述した実施の形態では、支払許容額を示すトークンの送信は、１回の許可コードに対応して１回のみ実施されることとした。これに限らず、例えば、サーバＣ（１０３）の制御部は、発行限度額の範囲で自動的にトークンを補充することもできる。これにより、利用者毎の発行限度額の範囲で複数回、支払許容額を示すトークン量を増やすことができ、利用者は許可コードを用いた手続きを省くことができる。また、利用者による複数回の取引によって支払額が支払許容額に近づいた場合、発行限度額の範囲内であれば、利用者の指定により支払許容額（トークン量）を追加チャージの形で増やすこともできる。

このほか、利用者によるシステム利用を停止したい場合、例えば、利用者が決済トークンチェーンＢ上の払い出し口座２０１ｂから運営者等の指定口座に残りのトークン量（全残額の資産移転）を行うこととしてもよい。この場合、サーバＣ（１０３）の制御部（例えば、徴収・返金額決定部３０５）は、支払許容額から支払額を差し引いた返金手続きを実施し、保管した許可コードを破棄する。これにより、トークンを指定口座へ送金するだけで、決済金額が確定して精算手続きを行える。

以上説明した実施の形態によれば、第１の通貨であるＹコインを扱う暗号資産チェーンＡと、第２の通貨であるＤコインを扱う決済トークンチェーンＢをサーバＣ（１０３）で連携させる。サーバＣ（１０３）は、スマートコントラクトの機能を有し、利用者からＤコインの発行依頼を受け付けると、利用者の信用情報（１２１）に基づき、Ｄコインの支払許容額を決定する。そして、支払許容額を決済トークンチェーンＢに通知する指示を暗号資産チェーンＡに送信する。また、サーバＣ（１０３）は、利用者によるＤコインでの支払取引が決済トークンチェーンに記録されると、Ｄコインに対応する価値を有するＹコインを、暗号資産チェーン上の利用者の口座から徴収する指示を暗号資産チェーンに送信する。これにより、利用者がサービス利用する事前時期に、利用者の信用情報に基づき支払許容額を暗号資産チェーンＡから決済トークンチェーンＢに送信しておくことで、利用者は、支払取引毎に支払許容額の範囲内で決済トークンチェーンＢ上の店舗への代金支払いが行えるようになる。

また、決済トークンチェーンＢを管理するサーバＢ（１０２）は、利用者の支払許容額を示すトークンの受信後は、決済トークンチェーンＢ外と通信しないオフライン状態で決済トークンチェーンＢ内のみで、利用者の支払取引を処理できる。サーバＢ（１０２）は、取引毎に、支払許容額の範囲内でＤコインを利用者の口座から店舗等の支払先の口座に移動させる。そして、サーバＣ（１０３）は、利用者の支払取引毎の情報を含む取引履歴に基づき、所定の決済日に、利用者のＹコインでの支払取引を集計し、暗号資産チェーンＡを管理するサーバＡ（１０１）に対し、Ｙコインでの徴収を行わせる。これにより、利用者が商品購入等の取引を行う都度、決済トークンチェーンＢのサーバＢ（１０２）は、外部のサーバＡ（１０１）、サーバＣ（１０３）等と通信接続する必要がなく、取引を実行できる。例えば、通信環境が悪い地域等の海外旅行先で利用者が商品購入を行った際、決済トークンチェーンＢのサーバＢ（１０２）がサーバＣ（１０３）と通信できない状態が生じても、クレジット決済等の取引を完了できる。この際、従来のような、利用者が商品購入する毎の与信の情報を管理するサーバへの接続は不要である。

また、サーバＣ（１０３）は、利用者からＤコインの払い出し依頼を受け付けると、利用者の信用情報（１２１）を参照し、利用者のＹコインの口座残高に基づき、支払許容額を決定してもよい。これにより、利用者は自身が保持する暗号資産であるＹコインの残高に基づく支払許容額の範囲内での商品購入等の取引を行うことができ、安全に決済できるようになる。

また、サーバＣ（１０３）は、利用者からＤコインの払い出し依頼を受け付けると、利用者の信用情報（１２１）を参照し、利用者のＹコインの口座残高の範囲内でＹコインの通貨の発行限度額を決定し、この発行限度額の範囲内で所定の支払許容額を決定する。これにより、Ｄコインの払い出し額が発行限度額の範囲内であれば、取引の都度、利用者からＤコインの払い出し依頼を受信する必要がなく、支払許容額を自動決定でき、支払許容額を示すトークンを暗号資産チェーンＡから決済トークンチェーンＢに送信させる制御が行えるようになる。例えば、利用者毎の発行限度額の範囲で複数回、支払許容額を示すトークン量を自動的に増やすことができ、この都度、利用者による許可コードを用いた手続きを省くことができる。

また、信用情報（１２１）は、利用者の信用度を示す信用度スコアを含み、サーバＣ（１０３）は、徴収毎の徴収状態に基づき、信用度スコアを変化させてもよい。例えば、徴収が失敗する毎に、利用者の信用度スコアを低下させ、以降の支払許容額を次第に制限することができる。これにより、利用者の未払い発生毎にペナルティとして、システムで使用できる支払許容額（トークン量）を次第に低くでき、信用度スコアに基づいて発行した支払許容額を上限とすることで未払いリスクを低減できるようになる。

以上のことから、実施の形態によれば、ブロックチェーンを用いた新しい決済技術を提供することができる。また、異なる通貨による決済手続きの煩雑さを低減できるようになる。そして、異なるブロックチェーンがそれぞれ管理する資産を連携することができ、一方の決済トークンチェーンＢでの取引を他方の暗号資産チェーンＡに反映させることができ、既存の複数のブロックチェーン間での資産移動を簡単に行うことができるようになる。

なお、本発明の実施の形態で説明した制御方法は、予め用意されたプログラムをサーバ等のプロセッサに実行させることにより実現することができる。本制御方法は、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ（ＣｏｍｐａｃｔＤｉｓｃ－ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）、ＤＶＤ（ＤｉｇｉｔａｌＶｅｒｓａｔｉｌｅＤｉｓｋ）、フラッシュメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本制御方法は、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）第１の通貨を扱う第１のブロックチェーンと、第２の通貨を扱う第２のブロックチェーンの連携を情報処理装置で制御する制御方法において、
前記情報処理装置のコンピュータは、
利用者から第２の通貨の発行依頼を受け付けると、前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定するとともに、前記支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信し、
前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収する指示を前記第１のブロックチェーンに送信する、
処理を実行することを特徴とする制御方法。

（付記２）前記第２のブロックチェーンを管理するコンピュータは、
前記利用者の前記支払許容額の受信後は、前記第２のブロックチェーン外と通信しないオフライン状態で前記第２のブロックチェーン内のみで、前記利用者が支払取引を行う毎に、前記支払許容額の範囲内で前記第２の通貨を前記利用者の口座から支払先の口座に移動させ、
前記情報処理装置のコンピュータは、
前記利用者の支払取引毎の情報を含む取引履歴に基づき、前記利用者による前記第１の通貨での支払取引を集計し、
前記第１のブロックチェーンを管理するコンピュータに対し、集計した前記支払取引に基づく前記徴収を決済日に行う指示を送信する、
ことを特徴とする付記１に記載の制御方法。

（付記３）前記情報処理装置のコンピュータは、
前記利用者から第２の通貨の発行依頼を受け付けると、前記利用者の信用情報を参照し、前記利用者の前記第１の通貨の口座残高に基づき、前記支払許容額を決定する、
ことを特徴とする付記１に記載の制御方法。

（付記４）前記情報処理装置のコンピュータは、
前記利用者から前記第２の通貨の発行依頼を受け付けると、前記利用者の信用情報に基づき、前記利用者の前記第１の通貨の口座残高の範囲内で前記第２の通貨の発行限度額を決定し、当該発行限度額の範囲内で前記支払許容額を決定し、
前記第２の通貨の前記支払許容額が前記発行限度額の範囲内であれば、前記利用者から前記第２の通貨の発行依頼を受信することなく、前記支払許容額を自動的に決定し、前記支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信する、
ことを特徴とする付記１に記載の制御方法。

（付記５）前記情報処理装置のコンピュータは、
前記信用情報は、前記利用者の信用度を示す信用度スコアを含み、前記徴収毎の徴収状態に基づき、前記信用度スコアを変化させる、
ことを特徴とする付記１～４のいずれか一つに記載の制御方法。

（付記６）第１の通貨を扱う第１のブロックチェーンと、第２の通貨を扱う第２のブロックチェーンの連携を情報処理装置で制御する制御プログラムにおいて、
前記情報処理装置のコンピュータに、
利用者から第２の通貨の発行依頼を受け付けると、前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定させるとともに、前記支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信させ、
前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収する指示を前記第１のブロックチェーンに送信させる、
処理を実行させることを特徴とする制御プログラム。

（付記７）第１の通貨を扱う第１のブロックチェーンと、第２の通貨を扱う第２のブロックチェーンの連携を制御する情報処理装置において、
利用者から第２の通貨の発行依頼を受け付ける受付部と、
前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定し、当該支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信する送金実行部と、
前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収させる指示を前記第１のブロックチェーンに送信する引き落とし実行部と、
を備えたことを特徴とする情報処理装置。

（付記８）第１の通貨を扱う第１のブロックチェーン内での資産移動を管理する第１のサーバと、
第２の通貨を扱う第２のブロックチェーン内での資産移動を管理する第２のサーバと、
前記第１のブロックチェーンと、前記第２のブロックチェーンの連携を制御する情報処理装置と、
前記第１のブロックチェーンおよび前記第２のブロックチェーンにそれぞれ資産を有する利用者が操作する端末と、
を含む制御システムにおいて、
前記情報処理装置は、
前記利用者の前記端末から前記第２の通貨の発行依頼を受け付ける受付部と、
前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定し、当該支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信する送金実行部と、
前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収させる指示を前記第１のブロックチェーンに送信する引き落とし実行部と、
を備えたことを特徴とする制御システム。

（付記９）前記第２のサーバは、
前記利用者の前記支払許容額の受信後は、前記第２のブロックチェーン外と通信しないオフライン状態で前記第２のブロックチェーン内のみで、前記利用者が支払取引を行う毎に、前記支払許容額の範囲内で前記第２の通貨を前記利用者の口座から支払先の口座に移動させる処理を行う制御部を有する、
ことを特徴とする付記８に記載の制御システム。

１００制御システム
１０１サーバＡ（暗号資産チェーンＡ）
１０２サーバＢ（決済トークンチェーンＢ）
１０３サーバＣ（スマートコントラクト）
１１０端末
１２１信用情報データベース
１２２取引履歴データベース
２０１，２０１ａ利用者口座
２０１ｂ払い出し口座
２０２運営者口座
２１１店舗口座
２１２クレジット口座
３０１受付部
３０２払い出し金額決定部
３０３送金実行部
３０４送金検出部
３０５徴収・返金額決定部
３０６引き落とし実行部
３１１，３２１分散台帳管理部
４０１ＣＰＵ
４０２メモリ
４０３ネットワークインタフェース
４０５記録媒体
４１０ネットワーク

Claims

第１の通貨を扱う第１のブロックチェーンと、第２の通貨を扱う第２のブロックチェーンの連携を情報処理装置で制御する制御方法において、
前記情報処理装置のコンピュータは、
利用者から第２の通貨の発行依頼を受け付けると、前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定するとともに、前記支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信し、
前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収する指示を前記第１のブロックチェーンに送信する、
処理を実行することを特徴とする制御方法。
前記第２のブロックチェーンを管理するコンピュータは、
前記利用者の前記支払許容額の受信後は、前記第２のブロックチェーン外と通信しないオフライン状態で前記第２のブロックチェーン内のみで、前記利用者が支払取引を行う毎に、前記支払許容額の範囲内で前記第２の通貨を前記利用者の口座から支払先の口座に移動させ、
前記情報処理装置のコンピュータは、
前記利用者の支払取引毎の情報を含む取引履歴に基づき、前記利用者による前記第１の通貨での支払取引を集計し、
前記第１のブロックチェーンを管理するコンピュータに対し、集計した前記支払取引に基づく前記徴収を決済日に行う指示を送信する、
ことを特徴とする請求項１に記載の制御方法。
前記情報処理装置のコンピュータは、
前記利用者から第２の通貨の発行依頼を受け付けると、前記利用者の信用情報を参照し、前記利用者の前記第１の通貨の口座残高に基づき、前記支払許容額を決定する、
ことを特徴とする請求項１に記載の制御方法。
前記情報処理装置のコンピュータは、
前記利用者から前記第２の通貨の発行依頼を受け付けると、前記利用者の信用情報に基づき、前記利用者の前記第１の通貨の口座残高の範囲内で前記第２の通貨の発行限度額を決定し、当該発行限度額の範囲内で前記支払許容額を決定し、
前記第２の通貨の前記支払許容額が前記発行限度額の範囲内であれば、前記利用者から前記第２の通貨の発行依頼を受信することなく、前記支払許容額を自動的に決定し、前記支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信する、
ことを特徴とする請求項１に記載の制御方法。
前記情報処理装置のコンピュータは、
前記信用情報は、前記利用者の信用度を示す信用度スコアを含み、前記徴収毎の徴収状態に基づき、前記信用度スコアを変化させる、
ことを特徴とする請求項１～４のいずれか一つに記載の制御方法。
第１の通貨を扱う第１のブロックチェーンと、第２の通貨を扱う第２のブロックチェーンの連携を情報処理装置で制御する制御プログラムにおいて、
前記情報処理装置のコンピュータに、
利用者から第２の通貨の発行依頼を受け付けると、前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定させるとともに、前記支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信させ、
前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収する指示を前記第１のブロックチェーンに送信させる、
処理を実行させることを特徴とする制御プログラム。
第１の通貨を扱う第１のブロックチェーンと、第２の通貨を扱う第２のブロックチェーンの連携を制御する情報処理装置において、
利用者から第２の通貨の発行依頼を受け付ける受付部と、
前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定し、当該支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信する送金実行部と、
前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収させる指示を前記第１のブロックチェーンに送信する引き落とし実行部と、
を備えたことを特徴とする情報処理装置。
第１の通貨を扱う第１のブロックチェーン内での資産移動を管理する第１のサーバと、
第２の通貨を扱う第２のブロックチェーン内での資産移動を管理する第２のサーバと、
前記第１のブロックチェーンと、前記第２のブロックチェーンの連携を制御する情報処理装置と、
前記第１のブロックチェーンおよび前記第２のブロックチェーンにそれぞれ資産を有する利用者が操作する端末と、
を含む制御システムにおいて、
前記情報処理装置は、
前記利用者の前記端末から前記第２の通貨の発行依頼を受け付ける受付部と、
前記利用者の信用情報に基づき、前記第２の通貨の支払許容額を決定し、当該支払許容額を前記第２のブロックチェーンに通知する指示を前記第１のブロックチェーンに送信する送金実行部と、
前記利用者による前記第２の通貨での支払取引が前記第２のブロックチェーンに記録されると、前記第２の通貨に対応する価値を有する前記第１の通貨を、前記第１のブロックチェーン上の前記利用者の口座から徴収させる指示を前記第１のブロックチェーンに送信する引き落とし実行部と、
を備えたことを特徴とする制御システム。