JP7034898B2 - 地域通貨管理システム、地域通貨管理方法、および地域通貨流通基盤 - Google Patents

Description

本発明は、地域通貨管理システム、地域通貨管理方法、および地域通貨流通基盤に関し、特に地方自治体やＮＰＯ（Ｎｏｎ Ｐｒｏｆｉｔ Ｏｒｇａｎｉｚａｔｉｏｎ）が主導する、特定の地域を中心に流通する地域通貨の実現手法に関わる。

昨今では、地球温暖化等に起因する異常気象が常態化し、それに伴う災害による被害額が増大する傾向にある。また、人口が都市部に集中する、いわゆるアーバリゼーションが本傾向に拍車を掛けている。

そうした災害発生の都度、国や自治体を中心に多額の支援金や義捐金が集められる。しかし、被災者に向けた迅速な支援金給付やその使途の追跡が出来ているとは言い難い。また同様に、平時に集められる寄付金や募金も、資金の出し手に対して使途を明確にしているとは言い難い。

このような使途の追跡に関する問題は、国連の関係機関など世界規模の組織が主導する活動に限らず、例えば神社仏閣の修繕費やお祭りに関する寄進といった地域のイベントに関しても同様である。つまり、一度提供した資金に関して、目的外の利用を防ぐことは困難である。

そこで、所定の資金に関して目的外の利用を抑制する、特定用途向けの代替通貨を実現する技術として、カラードコインと呼ばれる概念が提案されている（非特許文献１参照）。
この概念においては、参加者に固有のアドレスを割り当て、その支払先を記録し資金の流れを追跡可能とする。

また他の技術として、特定の地域に循環する取引を促進する電子決済システムが知られている（特許文献１参照）。この技術においては、地域通貨による決済時に、支払人の登録地と受取人の登録地の相対距離を判定し、距離が離れるほど決済手数料率を上げる手法が開示されている。

特開２０１７－０９０９８９号公報

あらゆる資産を表現できるビットコイン２．０プロジェクト「カラードコイン」

ところが、多発かつ大型化する自然災害への対応において、従来技術を用いるだけでは、支援金や義捐金の迅速な給付や使途追跡が困難であった。

具体的には、まず、実際に被害にあった被災者を特定して迅速な給付を行うことが困難である。通常、義捐金等の給付業務では、フリーライダー排除のため罹災証明書の発行と確認が必須である。しかし、災害発生時における自治体では災害対策に忙殺され、罹災証
明書の発行が遅れるケースが多い。

また、給付手段として地域通貨を発行するとした場合、その流通範囲の設計が困難である点も挙げられる。地域通貨の流通範囲を厳しく制限してしまうと、サービスの提供者が限られてしまい、被災者にとって使いにくい通貨となってしまう。また、地域外からの物資や人手（ボランティア）に対してのインセンティブとして機能しにくくなる弊害もある。反面、法定通貨や他の全国的なポイントへの兌換を容易にすると、地域通貨の価値が被災地域から簡単に流出してしまい、被災地域復興の目的を果たしえない。

そこで本発明は上記の課題を鑑みてなされたものであり、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現することを目的とする。

上記課題を解決する本発明の地域通貨管理システムは、イベントの影響範囲に関する情報として、自然災害の影響範囲に関する情報を保持する記憶装置と、ユーザの所在情報を所定装置から取得し、前記所在情報と前記イベントである自然災害の影響範囲に関する情報とに基づき、前記ユーザが前記自然災害の影響下にあるか判定する処理と、前記判定の結果、前記ユーザが前記自然災害の影響下にある場合、当該ユーザに対して所定の地域通貨の発行手続を行う処理と、を実行する演算装置と、を含むことを特徴とする。

また、本発明の地域通貨管理方法は、イベントの影響範囲に関する情報として、自然災害の影響範囲に関する情報を保持する記憶装置を備えた情報処理システムが、ユーザの所在情報を所定装置から取得し、前記所在情報と前記イベントである自然災害の影響範囲に関する情報とに基づき、前記ユーザが前記自然災害の影響下にあるか判定する処理と、前記判定の結果、前記ユーザが前記自然災害の影響下にある場合、当該ユーザに対して所定の地域通貨の発行手続を行う処理と、を実行することを特徴とする。

また、本実施形態の地域通貨流通基盤は、地域通貨の発行と流通を管理する地域通貨流通基盤であって、前記地域通貨の発行、決済の各処理を行うノードと、前記ノードを相互に接続するネットワークと、前記ノードに対して、前記地域通貨の発行または決済に関する処理要求を行う端末とを有し、前記ノードは、前記端末のユーザに関する前記地域通貨の支払い情報を保持し、前記端末からの処理要求を受け付け、前記処理要求に応じて、前記地域通貨の発行または決済の処理について他のノードと合意するものである、ことを特徴とする。

本発明によれば、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現できる。

本実施形態における地域通貨流通基盤によるサービス関係図である。 本実施形態のノードにおけるハードウェア構成例を示す図である。 本実施形態の端末におけるハードウェア構成例を示す図である。 本実施形態におけるブロックチェーンのデータ構造（例）を示す図である。 本実施形態における地域通貨の支払判断ユーザインタフェース（広域災害発生時）の例を示す図である。 本実施形態における地域通貨の支払判断ユーザインタフェース（月次の生活補助給付）の例を示す図である。 本実施形態における決済の例（スマホ間のジェスチャ）を示す図である。 本実施形態における飲食代の決済の流れを示すフロー図である。 本実施形態における決済画面の例を示す図である。 本実施形態におけるオンライン取引における決済の流れを示すフローチャートである。 本実施形態における決済内容を示す明細書のイメージ例を示す図である。 本実施形態における決済時における手数料算出テーブルを示す図である。 本実施形態における異なる地域通貨（Ｘ＜－＞Ｚ）間の両替方法である。 本実施形態における地域通貨間交換時の手数料算出テーブルを示す図である。 本実施形態における端末上の残高確認画面を示す図である。 本実施形態における端末上の支払い画面を示す図である。 本実施形態における消費者名簿およびＷａｌｌｅｔ残高一覧ユーザインタフェースを示す図である。 本実施形態における事業者名簿および受け入れ可能な地域通貨利用区分を示す図である。 本実施形態における通貨配布時の処理フロー（災害発生時の医療ケア給付）である。 本実施形態における地域通貨配布時の処理フロー（生活補助給付）である。

－－－地域通貨流通基盤の構成例－－－

以下、本発明の実施形態について図面を用いて説明する。図１は、本実施形態の地域通貨流通基盤１０２による提供サービスにおける、参加者および構成物の関係を示す概念図である。

図１で例示する地域通貨流通基盤１０２は、ブロックチェーン技術を用いて構築された価値交換のネットワークである。こうした地域通貨流通基盤１０２は、複数のノード１０１ａ～１０１ｃを含んで構成される。

これらノード１０１ａ～１０１ｃのそれぞれは、相互に通信を行って矛盾のない一意なトランザクション情報を生成し、支払いデータチェーン１１１（ブロックチェーン）として保持する。

上述の地域通貨運営者１１２は、地域通貨流通基盤１０２を構成するノード１０１ａ～１０１ｃを保有し、運営する。なお、特に限定しないかぎり、一般的にこれらノード１０１ａ～１０１ｃを区別なく示す場合、ノード１０１と記載する。

ノード１０１は物理的なコンピュータで構成されてもよいし、仮想的な計算機インスタンス、もしくはクラウド事業者に運営を委託された仮想サーバでも構わない。

ノード１０１を運営することにより地域通貨運営者１１２は地域通貨流通基盤１０２の支障ない運営を支えると共に、地域通貨流通基盤１０２上の送金もしくは決済トランザクションの直接的な生成および監視を行うことが出来る。

ここで、ノード１０１は、地域通貨利用者１１０の要求を、その端末１０４（図中では端末１０４ａ、１０４ｂ）を介して受け付け、上述の支払いデータチェーン１１１の生成およびその承認を行う。これにより、地域通貨を介した資金の決済や送金、換金のデータ的な処理を実現するものである。

支払いデータチェーン１１１は、複数のブロック＃１～＃Ｍ（１１１ａ～１１１ｃ）か
ら構成される。また、各ブロックは相互に連結され、Ｃｈｅｃｋｓｕｍフィールド内に１つ前のブロックのハッシュ値を保持する。

このハッシュ値は、対象ブロックの内容から生成された要約情報（ダイジェスト）である。ハッシュ値を計算する関数には、多項式や楕円関数が用いられ、元になるブロックの内容からハッシュ値の算出および検算は容易であるが、逆方向の演算（ハッシュ値からのブロック内容の推定）は困難な性質を有する。

そのため、悪意のある部外者が特定のブロックおよびその内部の支払い情報を改ざんした場合、他の正当な参加者からはハッシュ値を検証するだけでその改ざんを容易に検出できる。

また、各ブロックには支払い情報１～Ｎ（１２１ａ～１２１ｃ）が保持され、地域通貨利用者１１０の間に関して生じた支払い情報を保持している。なお、ブロック１１１ａ～１１１ｃが有する情報については、図３を用いて後述するものとする。
こうしたブロックチェーンネットワークでもある地域通貨流通基盤１０２は、地域通貨利用者１１０および地域通貨運用者１１２を結び付けている。

このうち地域通貨利用者１１０は、ユーザ“Ａ”～“Ｃ”など一般の消費者に加えて、事業者“Ｓ”、病院“Ｔ”、および薬局“Ｕ”など、特定の地域に所在する事業者群から構成される。

一方、地域通貨運営者１１２は、１つ以上の自治体“Ｘ”～“Ｚ”が含まれる。本実施形態においてこうした自治体は、それぞれの地域の地域通貨の発行主体となる。

なお、ある自治体は、管轄する特定の地域に対して１つの地域通貨を発行してもよいし、複数の地域通貨を発行し並立させてもよい。また、複数の自治体間で相互に流通可能な１つの地域通貨を共同で発行・運営してもよい。
本実施形態での例としては、自治体“Ｘ”が地域通貨Ｘを、自治体“Ｚ”が地域通貨Ｚをそれぞれ発行し管理するものとして以後の説明を行う。

また、上述の地域通貨運営者１１２は、他にも１つ以上の金融機関“Ｇ”～“Ｉ”が含まれているとしてもよい。これらの金融機関“Ｇ”～“Ｉ”は、上述の自治体からの業務委託を請負い、地域通貨の発行や口座（Ｗａｌｌｅｔ）の管理、決済業務を代行する。

なお、上述の例では自治体を地域通貨発行体、業務遂行者を金融機関に想定したが、他のＮＰＯやＮＧＯ（Ｎｏｎ Ｇｏｖｅｒｍｅｎｔ Ｏｒｇａｎｉｚａｔｉｏｎ）などの組織体、事業会社などがそれぞれの業務を行うことも十分に考えられる。したがって、それらのバリエーションも本発明の想定の範囲内である。

また、地域通貨利用者１１０の間で行われる価値交換の例示として、ユーザ“Ａ”とサービサ“Ｓ１”との間のインタラクションを示す。ユーザ“Ａ”は地域通貨支払い１０８をサービサ“Ｓ１”に対して行い、サービサ“Ｓ１”はサービス提供１０９を行う。
ユーザ“Ａ”は端末１０４ａを、また、サービサ“Ｓ１”は端末１０４ｂを、それぞれ用いて地域通貨流通基盤１０２に接続する。

地域通貨支払いの実行に際し、ユーザ“Ａ”やサービサ“Ｓ１”は、必ずしも地域通貨流通基盤１０２を意識せずともよい。端末１０４ａ～１０４ｂは、インターネットなどの適宜な通信手段１０３を用いて必要なデータを発信、受信する。

端末１０４ａ～１０４ｂから発信される通信データの例としては、支払い相手を特定するＩＤや支払い金額、支払い手段となる地域通貨の種別、支払い対象のサービスの種類に加えて、端末の現在地および過去にさかのぼっての滞在地情報を発信しうる。

この現在地および滞在地情報は、地域通貨運営者１１１２の側での地域通貨による支払や給付（発行）の適格性の判断や、距離情報１０７の算出、およびそれらに基づいた決済手数料の算出と徴収に用いられる。
－－－ハードウェア構成－－－

また、本実施形態におけるノード１０１のハードウェア構成は、図２Ａに示す如くとなる。ノード１０１は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０１３、記憶装置１０１に保持されるプログラム１０１２をメモリ１０１３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０１４、ユーザからのキー入力や音声入力を受け付ける入力装置１０１５、処理データの表示を行うディスプレイ等の出力装置１０１６、地域通貨流通基盤１０２と接続し他ノードとの通信処理を担う通信装置１０１７、を備える。

なお、記憶装置１０１１内には、本実施形態のノード１０１として必要な機能を実装する為のプログラム１０１２に加えて、上述の支払いデータチェーン１１１（ブロックチェーン）が少なくとも記憶されている。勿論、ブロックチェーンネットワークにおけるノードが一般的に備えるステートＤＢなど他の構成を適宜に備えるものとする。

また、本実施形態における端末１０４のハードウェア構成は、図２Ｂに示す如くとなる。この場合、端末１０４は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０４１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０４３、記憶装置１０４１に保持されるプログラム１０４２をメモリ１０４３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４４、ユーザからのキー入力や音声入力を受け付ける入力装置１０４５、処理データの表示を行うディスプレイ等の出力装置１０４６、地域通貨流通基盤１０２と接続し上述のノード１０１との通信処理を担う通信装置１０４７、およびＧＰＳユニット１０４８を備える。

なお、記憶装置１０４１内には、本実施形態の端末１０４として必要な機能を実装する為のプログラム１０４２に加えて、例えば、移動履歴１０４９が少なくとも記憶されている。この移動履歴１０４９は、当該端末（を携行するユーザ）における、所定時刻ごとの位置情報が格納されたテーブルである。

また、上述のＧＰＳユニット１０４８は、一般的なＧＰＳユニットであって、ＧＰＳ衛星からの電波を受信して端末１０４の現在位置および時刻を測定し、この測定結果を出力可能なものとなる。よって、このＧＰＳユニット１０４８による測定結果が、端末１０４により上述の行動履歴１０４９に格納されることとなる。
－－－ブロックチェーンの例－－－
図３に本実施形態におけるブロックチェーンすなわち上述の支払いデータチェーン１１１のデータ構造例を示す。
この支払いデータチェーン１１１では、説明の簡明化のため、チェーンを構成するブロックのうちブロック１１１ａ～１１１ｃのみ例示している。

このブロック１１１ａのＣｈｅｃｋＳｕｍ情報１２０ａは、前段のブロックの内容から
生成されたハッシュ値である。本実施形態の場合、ブロック１１１ａは、支払いデータチェーン１１１を構成する最初のブロックであるため、そのＣｈｅｃｋＳｕｍ情報１２０ａの内容は未定義、もしくはオールゼロを示すものとなる。

一方、後段のブロックである１１１ｂ、１１１ｃにおけるＣｈｅｃｋＳｕｍ情報１２０ｂ、１２０ｃには、それぞれ１つ前のブロックの内容から生成されたハッシュ値を保持する。

また、支払情報１２１ａには、上述の地域通貨利用者１１０のうちの特定の２者の間で実施された支払いに関する情報が保持される。本実施形態では、ブロック１１１ａの支払情報１２１ａには、支払者２０１ａ、受取者２０２ａ、金額２０３ａ、決済手段２０４ａ、利用区分２０５ａ、摘要２０６ａの各情報が含まれる。図３の例では、支払者情報２０１ａには“ユーザＣ”が、受取者情報２０２ａにはサービサ“Ｓ２”がそれぞれ格納されている。

もちろん、これら以外の情報が支払い情報１２１ａに含まれていても構わない。そうした情報の例としては、支払いトランザクションのＩＤや支払日時、他のシステムへのリンク情報などが考えられる。

なお、こうした支払情報１２１ａにおける支払者２０１ａ、受取者２０２ａの各情報の保持形態としては、ユーザのＩＤ情報（１０進数ｏｒ１６進数）が一般的である。ただし、他の形態、例えばｕｎｉｃｏｄｅによる文字列情報やＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）などを採用するとしもよい。
上述の支払者２０１ａおよび受取者２０２ａの各情報により、本支払情報１２１ａが“ユーザＣ”からサービサ“Ｓ２”への支払いであることが特定される。

また、金額２０３ａには“１００００”という数値情報が、決済手段２０４ａには“地域通貨Ｘ”という決済手段の種類が設定されており、“１００００”円が“地域通貨Ｘ”で支払われることを示している。

また、利用区分２０５ａには“生活補助Ｑ”の値が、また、摘要２０６ａには“商品代”の値が設定されており、上述の“地域通貨Ｘ”で支払われる“１００００”円は、“生活補助Ｑ”の区分に該当する“商品代”の決済金額であることを示している。

上述の利用区分２０５ａは、支払者の所有する地域通貨の口座の１部を指定している。なお、上述の“地域通貨Ｘ”は用途の区分別に利用可能なサービスがあらかじめ規定されており、その規定の詳細については図７Ｄを用いて後述する。
また、上述の摘要２０６ａは支払いの事由を保持する項目であり、関係者が支払いの理由を確認するために用いられる情報となる。

なお、支払情報１２１ｂの場合も、フィールドの項目は支払情報１２１ａと同様であり、支払者２０１ｂは“ユーザＡ”、受取者２０２ｂは“サービサＳ１”、金額２０３ｂは“２０００”、決済手段２０４ｂは“地域通貨Ｘ”、利用区分２０５ｂは“災害見舞金Ｐ”、摘要２０６ｂは“飲食代”、などと値が設定されている。
－－－地域通貨の発行契機等について－－－

図４Ａには、一例として広域災害発生時における地域通貨の発行判断に用いられるＵＩ４０１（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）の例を示す。つまり、地域通貨運営者１１２である自治体の職員（地域通貨発行担当）が閲覧するＵＩである。

図４Ａの例では、広域災害として地震を想定している。また、このＵＩ４０１では、時刻指定タブ４０５にて指定された所定時刻において、地域通貨の発行候補者である「ユーザＡ」が居た場所を地震遭遇地点４０４として図示している。この例では、地震の震源地４０７が、該当自治体のマップ４０３内に存在、すなわち該当自治体を震源地とする地震が発生した状況を想定している。

なお、上述の「ユーザＡ」は、このＵＩ４０１の生成より以前の或る時点で、その端末１０４ａを操作し、地域通貨の発行リクエストを自治体のノード１０１に送信している状況を想定できる。

また、「ユーザＡ」の端末１０４ａは、そのＧＰＳユニット１０４８で得ている移動履歴１０４９を保持している。この移動履歴１０４９は、各時刻における位置情報が蓄積されたものである。

例えば、上述の移動履歴１０４９によれば、「ユーザＡ」は、地震が発生した時刻（本例の場合、２０１８年２月１日１２時を想定）において、震源地４０７から半径５ｋｍ圏４０６ａの内に居たとする。

その場合、当該自治体のノード１０１は、地震の震源４０７およびや半径５ｋｍ圏４０６ａの表示を含むＵＩ４０１において、「ユーザＡ」の所在地を示すオブジェクト４０４１を、半径５ｋｍ圏４０６ａの該当位置に配置し表示させる。また、このオブジェクト４０４１から所定長の引出線を描画し、上述の地震遭遇地点４０４のアイコンおよびテキストをＵＩ４０１内に配置する。
なお、半径５ｋｍ圏４０６ａは、地域通貨の発行条件である。一方、半径１０ｋｍ圏４０６ｂは、地域通貨の発行条件ではない。

よって、この半径５ｋｍ圏４０６ａの領域に地震発生時刻から所定時間の時間範囲でユーザが所在した場合、当該ユーザは地域通貨発行対象者とする規定に対応する。但し、もちろんこれは発行条件の一例である。

この場合、ノード１０１は、「ユーザＡ」の端末１０４ａの移動履歴１０４９から地震発生時刻の位置情報履歴４０２を取得し、これに基づいてオブジェクト４０４１をＵＩ４０１上に配置することとなる。なお、震源地４０７から半径５ｋｍ圏４０６ａの内に居たと判断される。
そこで、上述の自治体の職員はこのＵＩ４０１を閲覧・確認することで、発行候補者の「ユーザＡ」が地域通貨の発行対象か否か容易に判断できることとなる。

また図４Ｂには、月次の生活補助を目的とした地域通貨発行（給付）の際に、対象の「ユーザＡ」が適格か否か判断するため、上述の自治体の職員が閲覧するＵＩ４１１の例を示す。基本的な構成は、上述のＵＩ４０１と同様である。

ここでは、生活補助を目的とした地域通貨発行の条件として、例えば、「ユーザＡ」の所得水準が所定基準以下であり、かつ登録住所が該当自治体内にあるといった一般的な事項以外に、生活の基盤が該当自治体内にある条件も合わせて想定している。

そこで本条件を確認するため、上述の自治体職員は、ユーザ本人の申告に基づき、特定の日・時刻にユーザ本人が所在した場所について、ノード１０１を操作し特定する。

この場合、ノード１０１は、上述の職員から所定インターフェイス４１５で指定された特定の日・時刻をキーに、「ユーザＡ」の端末１０４ａの移動履歴１０４９から位置情報
履歴４１２を取得し、これに基づいてオブジェクト４１４１をＵＩ４１１上に配置することとなる。

また、このオブジェクト４１４１から所定長の引出線を描画し、上述の「ユーザＡ」の所在場所（住所）４１４のアイコンおよびテキストをＵＩ４１１内に配置する。

図４Ｂの例では、該当日時「２０１８年２月２６日、１２時」において該当自治体（のマップ４１３）の内に「ユーザＡ」は所在したと判断される。つまり、上述の自治体の職員はこのＵＩ４１１を閲覧・確認することで、発行候補者の「ユーザＡ」が生活補助を目的とした地域通貨の発行対象か否か容易に判断できることとなる。
なお、上述の生活補助を目的とした地域通貨発行に際し、ユーザ本人の生活実態がその自治体の範囲内にあることを、さらに確実に確認することが望ましい。

そうした生活実態の確認方法としては、ノード１０１が、居住地におけるライフライン（水道・電気・ガス）の使用データを当該ユーザ居宅のスマートメーターから取得し、使用有無に基づき確認するものが想定できる。

また、上述の端末１０４ａのＧＰＳユニット１０４８を活用した位置情報等の取得・確認手法を例示しているが、これに他の方法（例：上述のスマートメーターからのデータ取得とその判定）を併用させることも有用と考えられる。
－－－地域通貨による決済イメージ－－－

続いて、図５Ａにスマートフォンを使った２者間での決済の例を示す。図５Ａの例では、支払者１０５ａである「ユーザＡ」と支払先１０６ａである「サービサＳ１」とが、お互いに向き合って端末１０４ａおよび端末１０４ｂを操作する。

こうした決済実行時の操作としていくつかのオプションが考えられるが、本例では、必要な情報を端末画面上で入力した上で、端末を前後に振るジェスチャ（４０２ａ、４０２ｂ）を行うことを想定している。

端末４０２ａおよび端末４０２ｂは、相互に無線もしくは接触にて相互に通信を行うと共に、地域通貨流通基盤１０２を構成するノード１０１ａ～１０１ｃに対して決済実行時点の現在位置を送信する。これにより、地域通貨流通基盤１０２のノード１０１は、端末間距離４０１を計算できる。

なお、本例では支払いにおける端末間距離４０１を地域通貨流通基盤１０２側（ノード１０１）で計算することを想定しているが、端末１０４ａと端末１０４ｂとの間で直接計測処理を行うとしてもよい。また端末１０４ａ、１０４ｂとしてはＧＰＳユニット１０４８を有するスマートフォンを想定できるが、ＰＯＳ端末や他の機器で代替してもよい。
－－－フロー例１－－－

続いて図５Ｂに、「ユーザＡ」と「サービサＳ１」との間で生じる、飲食代の決済処理に関するフローチャートを示す。当該フローチャートに関して以下で説明する各種動作は、地域通貨流通基盤１０２のノード１０１や、地域通貨利用者１１０の端末１０４ａ、１０４ｂ、など対応する実行主体が、そのメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

この場合、まず最初に「ユーザＡ」が、「サービサＳ１」との間で、提供する商品やサービスの内容とその支払い条件について合意しているものとする。本例では、「ユーザＡ
」が「サービサＳ１」が提供している特定の飲食メニュー、例えば「定食」を、地域通貨「２０００コイン」で食すると決定したとする。

そこで「ユーザＡ」は、自身の端末１０４ａを操作し、例えば、画面５００（図５Ｃ参照）にて上述の支払いの内容を指定する。例えば、「ユーザＡ」は「定食」の利用に際し、地域通貨を使って金額「２０００コイン」を、支払先＝「サービサＳ１」に対して支払うとの内容を画面５００で入力する。
端末１０４ａは、こうした「ユーザＡ」による入力を受け付ける（５０１）。
また、この「ユーザＡ」は、上述の画面５００で「決済ボタン」を押下するか、或いは、上述のジェスチャを行うなどして、決済指示を行う。

この場合の端末１０４ａは、上述の決済指示を感知し、予め定めた所定の決済処理を実行する（５０２）。本ステップでの「ユーザＡ」は、「サービサＳ１」の端末１０４ｂとの間で特定の操作として、図５Ａに前述したジェスチャを行う。

上述の決済指示により、当該決済指示が端末１０４ａから通信手段１０３を通じて地域通貨流通基盤１０２およびそれを構成するノード１０１ａ～１０１ｃに伝達される。

地域通貨流通基盤１０２はブロックチェーンネットワークであるから、ノード１０１ａ～１０１ｃらは、上述の決済指示の受信に伴い所定のトランザクションを生成し、ノード間での合意形成を経て支払いデータチェーン１１１に格納することとなる。

このトランザクションは、決済指示に応じて、例えば、金融機関ないし自治体のノードが実行する地域通貨の移動すなわち決済処理の実行に伴い発行するトランザクションである。

すなわち、「ユーザＡ」の地域通貨ウォレットから、該当金額分の地域通貨を、「サービサＳ１」の地域通貨ウォレットに移動させる、といった処理の結果を含むトランザクションが発行されることとなる。

このトランザクションは、ノード１０１の支払いデータチェーン１１１のブロックを構成する。また、当該トランザクションが含む所定情報（例：決済処理の内容）は、ステート情報としてノード１０１が保持するものとする。

このように対面、もしくは特定の距離より短い間で実行される決済の場合、地域通貨流通基盤１０２のノード１０１は、特段の決済手数料を徴収しない。これにより、地域通貨の流通を容易なものとする。なお、決済手数料の算出ルールについては図６Ｃを用いて後述する。

次に図６Ａを用いて、対面ではないオンライン取引（ＥＣ：Ｅｌｅｃｔｒｉｃ Ｃｏｍｍｅｒｃｅ）における処理の流れをタイムチャートで示す。図６Ａに示すタイムチャートは、上から下に向かって時間が流れるものとし、ユーザＣの端末１０４ｃ、サービサＳ２の端末１０６ｂ、金融機関Ｘのノード１０１ａ、および地域通貨流通基盤１０２、の間のインタラクションを水平方向の矢印で示す。

この場合、ユーザＣの端末１０４ｃは、サービサＳ２の端末１０６ｂに対して商品の購入申込み処理を行う（６０１）。一方、サービサＳ２の端末１０６ｂは、該当商品の金額および決済に用いることが出来る通貨種類を応答する（６０２）。こうした６０１、６０２における処理自体は、既存のＥＣサイトで通常行われている処理と同様である（以下同様）。
次にユーザＣの端末１０４ｃは、地域通貨を用いての支払いをサービサＳ２の端末１０６ｂに申し込む（６０３）。
一方、サービサＳ２の端末１０６ｂは、金融機関Ｘのノード１０１ａに対して、上述のユーザＣの口座が利用可能か否かを問い合わせする（６０４）。

この場合、金融機関Ｘのノード１０１ａは、地域通貨流通基盤１０２に対して問い合わせを行い（６０４１）、例えば、対応する地域通貨Ｘの口座（Ｗａｌｌｅｔ）が利用可能である旨をサービサＳ２の端末１０６ｂに応答する（６０５）。

続いて、サービサＳ２の端末１０６ｂは、ユーザＣの端末１０４ｃに対し、地域通貨Ｘによる支払の受け入れ（ＡＣＫ）を応答すると共に、ユーザＣの位置情報を要求する（６０６）。
これを受けたユーザＣの端末１０４ｃは、自身の位置情報をＧＰＳユニット１０４８から得て、これをサービサＳ２の端末１０６ｂに通知する（６０７）。

また、サービサＳ２の端末１０６ｂは、サービサＳ２自身の位置情報をそのＧＰＳユニット１０４８から得て、これを上述のユーザＣの位置情報と共に、金融機関Ｘのノード１０１ａに通知する（６０８）。

この場合、金融機関Ｘのノード１０１ａは、後述するテーブル（図６Ｃに記載）を参照して決済手数料を算出し（６０９）、これをサービサＳ２の端末１０６ｂに通知する（６１０）。

一方、サービサＳ２の端末１０６ｂは、ユーザＣが所望する商品の代金に加え、決済手数料（６０９で算出されたもの）、および所定の送料（ＥＣサイトで一般的に規定され、運用されているものと同様）などを加えた、支払いの内訳および総金額の情報を、ユーザＣの端末１０４ｃに通知する（６１１）。

他方、ユーザＣの端末１０４ｃは、上述の支払いの内訳および総金額の情報を閲覧し納得したユーザからの指示を受けて、代金の支払依頼を金融機関Ｘのノード１０１ａに対して行う（６１２）。

この依頼を受けた金融機関Ｘのノード１０１ａは、支払依頼に応じて、該当地域通貨の移動すなわち決済処理を実行する（６１３）。すなわち、「ユーザＣ」の地域通貨ウォレットから、該当金額分の地域通貨を、「サービサＳ２」の地域通貨ウォレットに移動させる、といった処理になる。

また、ノード１０１ａは、地域通貨流通基盤１０２に対して、上述の決済処理の情報に関するトランザクションを発行し、所定の合意形成を経て支払いデータチェーン１１１への登録処理を行う（６１４）。

このトランザクションは、ノード１０１の支払いデータチェーン１１１のブロックを構成する。また、当該トランザクションが含む所定情報（例：決済処理の内容）は、ステート情報として各ノード１０１が保持するものとする。

また、金融機関Ｘのノード１０１ａは、６１３，６１４での処理結果、すなわち支払結果を、ユーザＣの端末１０４ｃおよびサービサＳ２の端末１０６ｂに対して通知する（６１５）。

この場合、サービサＳ２は、上述の通知を端末１０６ｂで閲覧し、支払を確認すること
となる。端末１０６ｂは、サービサＳ２による確認結果の応答（例：該当画面でのＯＫボタンのクリックなど）を受け、例えば、商品配送部門のシステムに対し、ユーザＣに対する該当商品の配送指示を行うこととなる（６１６）。こうしてサービサＳ２からユーザＣに向け、商品が送付される。
図６Ｂに、上述のサービサＳ２の端末１０６ｂからユーザＣの端末１０４ｃに対して通知される決済内容である納品書兼明細書６２０を例示する。

この納品書兼明細書６２０が示す決済内容は、上述の商品の配送指示（６１６）に伴い、サービサＳ２の端末１０６ｂからユーザＣの端末１０４ｃに対して通知されるもの（電子情報）を想定するが、実際の商品に同梱される紙の明細書であってもよい。

ここで例示する納品書兼明細書６２０では、総計６２１の欄に記載のとおり、支払いの総額は「１００００コイン」であって、これが地域通貨Ｘによって支払われることが示されている。

さらに支払内訳６２２では、支払対象の商品名称が「陶器ティーセット」であり単価が「８０００コイン」、送料が「１０００コイン」、さらに支払いに掛かる手数料チャージが「１０００コイン」であることが示されている。
本例では、ユーザＣとサービサＳ２との間の決済時距離が１００ｋｍであり、１ｋｍあたり１０コインが決済手数料としてチャージされていることが分かる。

ここで図６Ｃに、上述の決済手数料の算出テーブル６３０を示す。本例において、決済手数料の算出は、地域通貨流通基盤１０２中のノード１０１ａ～１０１ｃが、本テーブル６３０を参照して行う。従って、ノード１０１ａ～１０１ｃは、それぞれ本テーブル６３０を保持しているか、他装置にアクセスして参照可能なものとする。
図６Ｃにおける手数料算出テーブル６３０は、ユーザとサービサとの間の決済時距離６３１に応じて、手数料単価６３２が規定された構造となっている。

上述の図６ｂにおける支払内訳６２２の例では、決済時のユーザとサービサとの間の決済時距離が「１００ｋｍ」であったため、手数料単価としては「１０コイン／ｋｍ」が適用されることとなる。よって、１００ｋｍ×１０コインの算定にて合計１０００コインが決済手数料として請求されていたことが分かる。
－－－フロー例２－－－

本実施例における地域通貨流通基盤１０２は、複数種類の地域通貨の流通を可能にするものである。そこで図６Ｄを用いて、異なる地域通貨間の両替方法に係る処理を説明する。
この例では、ユーザＤが保持する地域通貨Ｘを、異なる地域通貨Ｚに両替する際の処理フローについて示すものとする。

本説明では便宜上、地域通貨Ｘと地域通貨Ｚは互いに同じ単位名称「コイン」を用いるものとし、地域通貨Ｘの１コインは、地域通貨Ｚの１コインと等しい価値を有するものとする。なお、これら地域通貨それぞれが市場や相対取引を通じて交換される変動相場制を採用していてもほぼ同じ処理手順で両替が実施できる。
また、ユーザＤは、自身が保有する地域通貨Ｘ「１０００コイン」を、地域通貨Ｚに両替することを企図しているものとする。
この場合、ユーザＤの端末１０４ａは、ユーザＤが保有する地域通貨Ｘ「１０００コイン」を、地域通貨Ｚに両替するとのユーザ指示を受け付ける（６３５）。

次に、ユーザＤの端末１０４ａは、金融機関Ｘのノード１０１ａに対して、地域通貨Ｘ
＝１０００コイン分の両替を依頼する（６３６）。このようにユーザＤの端末１０４ａが金融機関Ｘのノード１０１ａに対して依頼する理由は、金融機関Ｘ（１１２ｃ）が自治体Ｘ（１１２ａ）から地域通貨Ｘの運用を委託されており、ユーザＤの口座（Ｗａｌｌｅｔ）を管理していることを想定する。

一方、上述の両替依頼を受けた金融機関Ｘのノード１０１ａは、図６Ｅに示す手数料算出テーブル６４０に従い手数料を算出する（６３６）。本ケースでは地域通貨Ｘから地域通貨Ｚへの交換であるため、手数料算出テーブル６４０に示すとおり２％の手数料単価が設定され、１０００×０．０２＝２０コインが手数料として算出されることとなる。
ここで図６Ｅを用いて、地域通貨間の交換時の手数料算出テーブル６４０について説明する。

この手数料算出テーブル６４０においては、交換元コイン６４１と交換先コイン６４２のペアに対して、手数料単価６４３が一意に規定されている。本テーブル６４０は、地域通貨流通基盤１０２に参加する全ての関係者、すなわちユーザおよび自治体、金融機関の間で共有される。

図６ＤにおけるユーザＤの両替要求のケースでは、行６４４が参照され、手数料単価が２％に設定されることになる。逆に地域通貨Ｚから地域通貨Ｘへの両替の場合は行６４５が参照され、手数料単価は１％となる。

この他、地域通貨Ｘと法定通貨Ｙとの関係も定義されており、地域通貨Ｘから法定通貨Ｙへの両替の際は行６４６が参照され手数料単価が５％に設定される。また、逆方向の場合は行６４７が参照され手数料単価は０％、すなわち手数料は徴収されない。

すなわち、正貨である法定通貨Ｙから地域通貨Ｘへの流入を推奨しており、自治体Ｘ（１１２ａ）としてはユーザたる住民に対して積極的に地域通貨Ｘを購入してもらい自治体Ｘの地域経済の活性化を企図している。

ここで図６Ｄのフローの説明に戻る。続いて、金融機関Ｘのノード１０１ａは、手数料を加えた地域通貨Ｘ＝１０２０コインを、ユーザＤの口座（Ｗａｌｌｅｔ）から減算し、地域通貨Ｚ＝１０００コインを加算する要求（のトランザクション）を、地域通貨流通基盤１０２に送出する（６３７）。

ここで送出された要求は他の全てのノード、もしくは一部のノードで受信・観測される。本ケースでは、両替元の地域通貨Ｘの管理機関である金融機関Ｘ（１１２ｃ）および両替先の地域通貨Ｚを管理している金融機関Ｚ（１１２ｄ）の両者から受信・観測される。

ここでは、両替要求を認識した関係者である、金融機関Ｘ（１１２ｃ）および金融機関Ｚ（１１２ｄ）の両者が本両替要求を承認する（６３８）。なお、両替要求が承認されないケースとしては、両替元の口座に十分な資金がない場合（例：ユーザＤの有する地域通貨Ｘ残高が１０２０に満たない）、もしくは両替先の地域通貨Ｚの取引がユーザＤに許可されていない場合（例：ユーザＤが地域通貨Ｚの口座を持っていない）などが考えられる。
最後に、金融機関Ｘのノード１０１ａは、ユーザＤの端末１０４ａに対して両替完了結果を通知し（６３９）、処理を終了する。

なお、説明は省略したが、上述のステップ６３５～６３９の全て又は一部に伴い、実行主体の端末やノードがトランザクションを発行し、他の端末やノードとの合意形成を経て、当該トランザクションを支払いデータチェーン１１１に格納する。

ここで、図７Ａを用いて、ユーザが使用する端末上の地域通貨残高の確認画面例を示す。残高確認画面７００は、例えばユーザＣが用いる端末１０４ｃに表示される画面である。

この残高確認画面７００において、ユーザ欄７０１では確認主体であるユーザＣを示している。このユーザＣは１つ以上のコインを格納したＷａｌｌｅｔを保持しており、セレクタ７０２によって地域通貨Ｘを、かつセレクタ７０３によって利用区分が生活補助Ｑである部分の残高参照を指示している。
また、金額ウィンドウ７０４に、「２００,０００」が表示されており、参照対象の地
域通貨残高が「２００,０００」コインであることを示している。

また図７Ｂに、ユーザＣが支払いを行うときの端末上の残高確認画面７１０を例示する。この残高確認画面７１０は、ユーザＣの端末（典型的にはスマートフォン）に表示される画面である。

また、この残高確認画面７１０において、ユーザＣは、セレクタ７１１により支払先＝サービサＳ２を指定し、入力フォーム７１２にて金額＝１００００を指定している。

さらにセレクタ７１３によって地域通貨Ｘを、セレクタ７１４によって生活補助ＱのサブＷａｌｌｅｔから支払うことを指示している。また、入力フォーム７１５に摘要として文字列「商品代」を指定している。
この残高確認画面７１０を閲覧したユーザＣは、支払内容に問題がないことを確認し、ボタン７１６を押して支払指示を送信する。
また図７Ｃに、自治体Ｘ（１１２ａ）の職員が参照する消費者名簿およびＷａｌｌｅｔ残高一覧を表すＵＩ７２０を例示する。

本ＵＩ７２０では、一行に１ユーザの情報が表示される形式を取る。例えば、行７２１にはユーザＡ（１１０ａ）の情報が表示されており、各欄にはＩＤ番号（＃）、名前、住所、および利用区分（２０５）別のウォレット残高が格納されている。

行７２１によると、名前＝ユーザＡ、住所＝Ｘ市△△町、地域通貨Ｘのウォレット残高のうち、利用区分＝災害見舞金Ｐに属するＷａｌｌｅｔ残高が１００００００、生活補助Ｑに属するＷａｌｌｅｔ残高が２０００００であることを示している。本ＵＩ７２０により、自治体Ｘ（１１２ａ）の職員は利用者の各種情報を参照できる。

また図７Ｄに、自治体Ｘ（１１２ａ）に登録されている事業者名簿および各事業者が受け入れ可能な地域通貨の利用区分を表すＵＩ７３０を例示する。自治体Ｘ（１１２ａ）の職員は本ＵＩ７３０を用いて地域通貨Ｘを受け入れている事業者の一覧および各事業者の情報を取得できる。

本ＵＩ７３０では、１行に１事業者の情報が表示される形式を取る。例えば、行７３１の例では、ＩＤ＝１の事業者名称が「事業者１」であり、その登録地がＸ市△△町であり、その事業内容が「住宅リフォーム、修繕」であることを示している。

この事業者１は、地域通貨Ｘの利用区分のうち、災害見舞金Ｐは受け入れ可能であるが、生活補助Ｑは受け入れられないことを示している。そのため、地域通貨Ｘを支払う消費者は、主に広域災害で住宅や建物を損傷した消費者がその修繕やリフォームのために事業者１に対して支払をすることになるであろう。

一方、行７３２に示す事業者＝「病院２」の場合は、利用区分として災害見舞金Ｐおよび生活補助Ｑのいずれも受け入れ可能であることを示している。すなわち災害によって生じた怪我に対しての災害見舞金Ｐを用いての支払い、もしくは慢性的な持病に対する生活補助Ｑを用いた支払いのいずれも受け入れ可能であることを示している。
このように、事業者とそのサービスメニューごとに地域通貨の用途をコントロールすることによって、意図しない地域通貨の使われ方を抑止することが出来る。
－－－フロー例３－－－

続いて図８にて、災害発生時における医療ケア目的での地域通貨Ｘの発行の処理フローを示す。図４Ａにて述べた広域災害の発生ケースにおいて、ユーザＡ（１０５ａ）が地震に遭遇し何らかの傷害を受けたとする。

また、このユーザＡは、取り急ぎ病院２で受診し、手当ておよび薬の処方を受ける。そして診療が終わったユーザＡは、診療費用の支払時に、自身の端末１０４ａ（典型的にはスマートフォン）から給付金申請ＵＩを呼び出す。この給付金申請ＵＩについては特に図示しないが、一般的な給付金申請事項の入力インターフェイスを備えた画面を想定する。
一方、上述のユーザＡの端末１０４ａは、給付金申請ＵＩを介して、ユーザＡによる診療費に関する給付金申請内容の入力を受け付ける（８００）。

また、端末１０４ａは、上述の給付金申請内容と、ＧＰＳユニット１０４８の移動履歴１０４９の情報を、通信手段１０３および地域通貨流通基盤１０２を介して、自治体Ｘのノード１０１ｂに送出する（８０１）。

上述の端末１０４ａから給付申請内容および移動履歴１０４９の情報を受け取った自治体Ｘのノード１０１ｂは、申請者であるユーザＡが災害見舞金の給付適格であるか否かを判断する（８０２）。

具体的には、ユーザＡの移動履歴１０４９の情報の示す所在位置が、地震発生およびその前後の影響範囲に含まれるか、すなわち重複しているか判断することになる。この判断の基準は、既に例示したように、地震発生前後の時間帯にユーザＡが震源地から半径５ｋｍ以内にいたこと、などを想定する。

この判断の結果、重複ありとなった場合（８０２：あり）、すなわち地震発生前後の時間帯にユーザＡが震源地から半径５ｋｍ以内にいたことが判明した場合、自治体Ｘのノード１０１ｂは、所定職員からの指示を受けて、ユーザＡの口座（Ｗａｌｌｅｔ）に災害見舞金を地域通貨にて給付する処理を実行する（８０３）。

一方、ユーザＡの端末１０４ａは、自治体から給付された災害見舞金である地域通貨を、病院２の所定システムに対するＷａｌｌｅｔ経由での支払処理を行う（８０４）。このように迅速な災害見舞金の給付が可能になる。
－－－フロー例４－－－

続いて図９にて、毎月発生する生活補助給付を題材に地域通貨発行時の処理フローを示す。この場合、自治体Ｘの職員が、ノード１０１ｂにおける生活給付処理を起動したとする。

ノード１０１ｂは、生活補助給付処理を起動し（９００）、月内の特定日時におけるユーザＡの所在確認処理を実行する（９０１）。上述の特定日時は、自治体側で指定するケースと、申告者（ユーザ）からの指定日時であるケースを想定できる。

また、ノード１０１ｂは、上述のユーザＡの所在位置を、当該ユーザＡの端末１０４ａにおける移動履歴１０４９の情報から取得し、これが自治体Ｘの範囲内であった場合（９０１：範囲内）、ユーザＡの口座（Ｗａｌｌｅｔ）に対する生活補助給付の処理を実行し（９０２）、処理を終了する。これにより、ユーザＡの生活実態に即し、かつ職員への負担が少ない、生活補助給付業務が可能になる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、例えば、迅速な災害義捐金の給付や義捐金の使途の可視化および目的外使用の限定と、災害地域外への通貨価値の流出の緩やかな防止と、を両立させ、被災地域の復興に資する地域通貨流通基盤の実現がなされる。
すなわち、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現できることとなる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の地域通貨管理システムにおいて、前記記憶装置は、前記影響範囲に関する情報として、当該イベントの影響領域および当該影響の及んでいる影響時刻の各情報を保持し、前記演算装置は、前記ユーザの所在情報として、当該ユーザの所在位置および該当位置に所在した所在時刻の各情報を取得し、前記ユーザの前記所在位置および前記所在時刻の各情報と、前記イベントの前記影響領域および前記影響時刻の各情報とに基づき、前記所在時刻における前記所在位置が、前記影響時刻における前記イベントの影響領域に含まれるか判定することで、前記ユーザが前記イベントの影響下にあるか判定するものである、としてもよい。

これによれば、災害やイベントに遭遇したユーザを的確に特定し、当該ユーザに対して効率的に地域通貨の発行を行うことが可能となる。ひいては、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現できることとなる。

また、本実施形態の地域通貨管理システムにおいて、前記記憶装置は、前記影響範囲に関する情報として、自然災害の影響範囲に関する情報を保持し、前記演算装置は、前記ユーザの所在情報と前記自然災害の影響範囲に関する情報とに基づき、前記ユーザが前記自然災害の影響下にあるか判定する処理と、前記判定の結果、前記ユーザが前記自然災害の影響下にある場合、当該ユーザに対して所定の地域通貨の発行手続を行うものである、としてもよい。

これによれば、自然災害に遭遇したユーザを的確に特定し、当該ユーザに対して効率的に地域通貨の発行を行うことが可能となる。ひいては、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現できることとなる。

また、本実施形態の地域通貨管理システムにおいて、前記記憶装置は、前記影響範囲に関する情報として、人為的な催しの影響範囲に関する情報を保持し、前記演算装置は、前記ユーザの所在情報と前記催しの影響範囲に関する情報とに基づき、前記ユーザが前記催しの影響下にあるか判定する処理と、前記判定の結果、前記ユーザが前記催しの影響下にある場合、当該ユーザに対して所定の地域通貨の発行手続を行うものである、としてもよい。

これによれば、地域イベント等に参加したユーザを的確に特定し、当該ユーザに対して効率的に地域通貨の発行を行うことが可能となる。ひいては、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現できることとなる。

また、本実施形態の地域通貨管理システムにおいて、前記演算装置は、前記ユーザにおける、前記地域通貨を他地域通貨または法定通貨に交換する所定処理に際し、前記地域通貨の発行管理機関と前記他地域通貨の発行管理機関との間に関して定めた交換手数料ルールに基づき、前記ユーザにおける前記交換に伴う交換手数料を特定する処理をさらに実行する、としてもよい。

これによれば、地域振興の観点で地域通貨を得たユーザが、これを他の地域通貨等に交換する機会を緩やかに制限しつつも、これを排除しない運用形態を実現する。ひいては、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現できることとなる。

また、本実施形態の地域通貨管理システムにおいて、前記演算装置は、前記ユーザにおける、前記地域通貨を決済手段とした所定のサービサからの商品またはサービスの購入処理に際し、前記ユーザおよび前記サービサの所在情報に基づき、前記ユーザと前記サービサとの間の距離を算定する処理と、前記距離に応じて前記ユーザおよび前記サービサの両方または片方に課す決済手数料を算定する処理をさらに実行する、としてもよい。

これによれば、地域振興の観点で地域通貨を得たユーザが、これを他地域での決済に使用する機会を緩やかに制限しつつも、これを排除しない運用形態を実現する。ひいては、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現できることとなる。

また、本実施形態の地域通貨管理システムにおいて、前記演算装置は、前記ユーザに発行した前記地域通貨に関して、予め定めたルールに基づく使途の指定を行う処理をさらに実行し、前記購入処理に際し、購入対象の商品またはサービスが前記使途に合致するか判定し、前記判定の結果に応じて、前記購入処理における決済手段たる前記地域通貨の使用可否を決定するものである、としてもよい。

これによれば、地域振興の観点で地域通貨を得たユーザが、これを地域振興やユーザ自立支援といった本来的な意味で好適な目的で使用する機会を促進する運用形態を実現する。ひいては、迅速で使途管理可能な資金の提供を通じ、地域振興に資する地域通貨流通基盤を実現できることとなる。

また、本実施形態の地域通貨管理方法において、前記情報処理システムが、前記記憶装置において、前記影響範囲に関する情報として、当該イベントの影響領域および当該影響の及んでいる影響時刻の各情報を保持し、前記ユーザの所在情報として、当該ユーザの所在位置および該当位置に所在した所在時刻の各情報を取得し、前記ユーザの前記所在位置および前記所在時刻の各情報と、前記イベントの前記影響領域および前記影響時刻の各情報とに基づき、前記所在時刻における前記所在位置が、前記影響時刻における前記イベントの影響領域に含まれるか判定することで、前記ユーザが前記イベントの影響下にあるか判定する、としてもよい。

また、本実施形態の地域通貨管理方法において、前記情報処理システムが、前記記憶装置において、前記影響範囲に関する情報として、自然災害の影響範囲に関する情報を保持し、前記ユーザの所在情報と前記自然災害の影響範囲に関する情報とに基づき、前記ユーザが前記自然災害の影響下にあるか判定する処理と、前記判定の結果、前記ユーザが前記自然災害の影響下にある場合、当該ユーザに対して所定の地域通貨の発行手続を行う、としてもよい。

また、本実施形態の地域通貨管理方法において、前記情報処理システムが、前記記憶装置において、前記影響範囲に関する情報として、人為的な催しの影響範囲に関する情報を保持し、前記ユーザの所在情報と前記催しの影響範囲に関する情報とに基づき、前記ユーザが前記催しの影響下にあるか判定し、前記判定の結果、前記ユーザが前記催しの影響下にある場合、当該ユーザに対して所定の地域通貨の発行手続を行う、としてもよい。

また、本実施形態の地域通貨管理方法において、前記情報処理システムが、前記ユーザにおける、前記地域通貨を他地域通貨または法定通貨に交換する所定処理に際し、前記地域通貨の発行管理機関と前記他地域通貨の発行管理機関との間に関して定めた交換手数料ルールに基づき、前記ユーザにおける前記交換に伴う交換手数料を特定する処理をさらに実行する、としてもよい。

また、本実施形態の地域通貨管理方法において、前記情報処理システムが、前記ユーザにおける、前記地域通貨を決済手段とした所定のサービサからの商品またはサービスの購入処理に際し、前記ユーザおよび前記サービサの所在情報に基づき、前記ユーザと前記サービサとの間の距離を算定する処理と、前記距離に応じて前記ユーザおよび前記サービサの両方または片方に課す決済手数料を算定する処理をさらに実行する、としてもよい。

また、本実施形態の地域通貨管理方法において、前記情報処理システムが、前記ユーザに発行した前記地域通貨に関して、予め定めたルールに基づく使途の指定を行う処理をさらに実行し、前記購入処理に際し、購入対象の商品またはサービスが前記使途に合致するか判定し、前記判定の結果に応じて、前記購入処理における決済手段たる前記地域通貨の使用可否を決定する、としてもよい。

１０２ 地域通貨流通基盤
１０１、１０１ａ～１０１ｃ ノード
１１１ 支払いデータチェーン（ブロックチェーン）
１０４、１０４ａ～１０４ｂ 端末
１０１１ 記憶装置
１０１２ プログラム
１０１３ メモリ
１０１４ 演算装置
１０１５ 入力装置
１０１６ 出力装置
１０１７ 通信装置
１０４１ 記憶装置
１０４２ プログラム
１０４３ メモリ
１０４４ 演算装置
１０４５ 入力装置
１０４６ 出力装置
１０４７ 通信装置
１０４８ ＧＰＳユニット
１０４９ 移動履歴

Claims (10)

1. イベントの影響範囲に関する情報として、自然災害の影響範囲に関する情報を保持する記憶装置と、
   ユーザの所在情報を所定装置から取得し、前記所在情報と前記イベントである自然災害の影響範囲に関する情報とに基づき、前記ユーザが前記自然災害の影響下にあるか判定する処理と、前記判定の結果、前記ユーザが前記自然災害の影響下にある場合、当該ユーザに対して所定の地域通貨の発行手続を行う処理と、を実行する演算装置と、
   を含む地域通貨管理システム。
2. 前記記憶装置は、
   前記影響範囲に関する情報として、当該イベントの影響領域および当該影響の及んでいる影響時刻の各情報を保持し、
   前記演算装置は、
   前記ユーザの所在情報として、当該ユーザの所在位置および該当位置に所在した所在時刻の各情報を取得し、前記ユーザの前記所在位置および前記所在時刻の各情報と、前記イベントの前記影響領域および前記影響時刻の各情報とに基づき、前記所在時刻における前記所在位置が、前記影響時刻における前記イベントの影響領域に含まれるか判定することで、前記ユーザが前記イベントの影響下にあるか判定するものである、
   ことを特徴とする請求項１に記載の地域通貨管理システム。
3. 前記演算装置は、
   前記ユーザにおける、前記地域通貨を他地域通貨または法定通貨に交換する所定処理に際し、前記地域通貨の発行管理機関と前記他地域通貨の発行管理機関との間に関して定めた交換手数料ルールに基づき、前記ユーザにおける前記交換に伴う交換手数料を特定する処理をさらに実行する、
   ことを特徴とする請求項１に記載の地域通貨管理システム。
4. 前記演算装置は、
   前記ユーザにおける、前記地域通貨を決済手段とした所定のサービサからの商品またはサービスの購入処理に際し、前記ユーザおよび前記サービサの所在情報に基づき、前記ユーザと前記サービサとの間の距離を算定する処理と、前記距離に応じて前記ユーザおよび前記サービサの両方または片方に課す決済手数料を算定する処理をさらに実行する、
   ことを特徴とする請求項１に記載の地域通貨管理システム。
5. 前記演算装置は、
   前記ユーザに発行した前記地域通貨に関して、予め定めたルールに基づく使途の指定を行う処理をさらに実行し、
   前記購入処理に際し、購入対象の商品またはサービスが前記使途に合致するか判定し、前記判定の結果に応じて、前記購入処理における決済手段たる前記地域通貨の使用可否を決定するものである、
   ことを特徴とする請求項４に記載の地域通貨管理システム。
6. イベントの影響範囲に関する情報として、自然災害の影響範囲に関する情報を保持する記憶装置を備えた情報処理システムが、
   ユーザの所在情報を所定装置から取得し、前記所在情報と前記イベントである自然災害の影響範囲に関する情報とに基づき、前記ユーザが前記自然災害の影響下にあるか判定する処理と、前記判定の結果、前記ユーザが前記自然災害の影響下にある場合、当該ユーザに対して所定の地域通貨の発行手続を行う処理と、
   を実行する地域通貨管理方法。
7. 前記情報処理システムが、
   前記記憶装置において、前記影響範囲に関する情報として、当該イベントの影響領域および当該影響の及んでいる影響時刻の各情報を保持し、
   前記ユーザの所在情報として、当該ユーザの所在位置および該当位置に所在した所在時刻の各情報を取得し、前記ユーザの前記所在位置および前記所在時刻の各情報と、前記イベントの前記影響領域および前記影響時刻の各情報とに基づき、前記所在時刻における前記所在位置が、前記影響時刻における前記イベントの影響領域に含まれるか判定することで、前記ユーザが前記イベントの影響下にあるか判定する、
   ことを特徴とする請求項６に記載の地域通貨管理方法。
8. 前記情報処理システムが、
   前記ユーザにおける、前記地域通貨を他地域通貨または法定通貨に交換する所定処理に際し、前記地域通貨の発行管理機関と前記他地域通貨の発行管理機関との間に関して定めた交換手数料ルールに基づき、前記ユーザにおける前記交換に伴う交換手数料を特定する処理をさらに実行する、
   ことを特徴とする請求項６に記載の地域通貨管理方法。
9. 前記情報処理システムが、
   前記ユーザにおける、前記地域通貨を決済手段とした所定のサービサからの商品またはサービスの購入処理に際し、前記ユーザおよび前記サービサの所在情報に基づき、前記ユーザと前記サービサとの間の距離を算定する処理と、前記距離に応じて前記ユーザおよび前記サービサの両方または片方に課す決済手数料を算定する処理をさらに実行する、
   ことを特徴とする請求項６に記載の地域通貨管理方法。
10. 前記情報処理システムが、
    前記ユーザに発行した前記地域通貨に関して、予め定めたルールに基づく使途の指定を行う処理をさらに実行し、
    前記購入処理に際し、購入対象の商品またはサービスが前記使途に合致するか判定し、前記判定の結果に応じて、前記購入処理における決済手段たる前記地域通貨の使用可否を決定する、
    ことを特徴とする請求項９に記載の地域通貨管理方法。

Images