WO2023008418A1

WO2023008418A1 - 支援通貨管理システムおよび通信端末

Info

Publication number: WO2023008418A1
Application number: PCT/JP2022/028756
Authority: WO
Inventors: 克彦近藤; 昭彦松村
Original assignee: Ｔｅｓｎｏｌｏｇｙ株式会社
Priority date: 2021-07-28
Filing date: 2022-07-26
Publication date: 2023-02-02
Also published as: TW202309804A; US20240161069A1; JPWO2023008418A1

Abstract

ユーザが、店舗から商品を購入するとき、運営会社が発行する支援通貨によりその対価の全部または一部を支払う。支援通貨はデジタル貨幣であり、通信端末に格納される。取引に際しては、通信端末により支援通貨に取引の内容を示す取引情報が追加される。支援通貨を受け取った店舗は、同じく支援通貨を商品購入に使うことができる。このときには、店舗が使用する通信端末は、新たな取引の内容を示す取引情報を支援通貨に追加する。

Description

支援通貨管理システムおよび通信端末

　本発明は、経済取引を活性化するための技術、に関する。

　商品やサービスの対価として「お金」が支払われる。ＡさんがＢさんにお金を支払うと、Ｂさんの購買力が増す。Ｂさんに移転したお金は、新たな商品やサービスの消費につながる。お金は「価値への対価として、相手が受け取ってくれる」という信頼と実績によって信用のネットワークをつくる。信用を基盤としてお金が流通することにより、商品やサービスなどの開発・提案・生産・提供といった経済行為が促進される。

特開２００１－３０６７１６号公報特開２０１９－１９７５１３号公報

　もし、多くの人が自分の購買力を維持するためにお金を溜め込みすぎてしまうと、お金の流動性が低下し、いわゆる「不景気」となる。このような場合、金利を下げたり、国債等を通じて市場にお金を供給することで、お金の流動性を刺激する金融政策を実行するのが一般的である。しかし、市場に供給されたお金が実際にどのくらいの経済効果を発揮しているかを把握するのは容易ではない。

　本発明は、上記背景に基づいて完成された発明であり、その主たる目的は、法定通貨とは異なる支援通貨を通して経済を活性化させるための技術、を提供することにある。

　本発明のある態様における支援通貨管理システムは、第１の経済主体および第２の経済主体の取引にともなって、第１の経済主体から第２の経済主体に支援通貨が移転されるとき、第１の経済主体および第２の経済主体の取引に関する取引情報を取引の対象となった支援通貨に対応づけて記録する取引管理部、を備える。
　取引管理部は、支援通貨が介在する取引が発生するごとに、支援通貨に取引情報を追加する。

　本発明のある態様における通信端末は、一単位ごとに通貨ＩＤにより識別される支援通貨に対して、支援通貨による取引に関する取引情報を対応づけて記録する取引管理部と、取引相手の通信端末に対して、通貨ＩＤおよび取引情報を含む支援通貨を送信する送信部と、を備える。

　本発明によれば、経済取引を活性化させやすくなる。

支援通貨の循環を説明するための模式図である。支援通貨の送金方法を説明するための模式図である。支援通貨管理システムのハードウェア構成図である。通信端末のハードウェア構成図である。通信端末の機能ブロック図である。運営サーバの機能ブロック図である。発行サーバの機能ブロック図である。支援通貨の発行および配布過程を示すシーケンス図である。通信端末における支払画面の画面図である。通信端末における支援通貨選択画面の画面図である。取引情報のデータ構造図である。支援通貨に含まれる取引情報のデータ構造図である。支援通貨の移転状況を示す模式図である。送信対象となる支援通貨の選び方を示す模式図である。支援通貨による取引過程を示すシーケンス図である。累計手数料情報のデータ構造図である。手数料設定情報のデータ構造図である。手数料調整情報のデータ構造図である。通貨流通情報のデータ構造図である。使用条件情報のデータ構造図である。経済効果情報のデータ構造図である。変形例として、商品購入の御礼として支援通貨を配布するときの処理過程を示すシーケンス図である。変形例として、支援通貨の有償購入するときの処理過程を示すシーケンス図である。変形例として、ウェブサイトへのアクセスにともなって支援通貨を流通させる方法の概念図である。変形例における取引履歴情報のデータ構造図である。

［第１実施形態］
　本実施形態においては、発行体Ｘは現金等価物としてのポイントを発行する。
　以下、このポイントのことを「支援通貨」とよぶ。支援通貨は、いわゆる地域通貨として機能する。
　支援通貨は、法定通貨の裏付けがある。たとえば、１ポイントの支援通貨は１円と交換可能である。支援通貨の基本的価値の源泉は、ビットコインのような仮想通貨とは異なり「国家に対する信頼」である。国家に対する信頼は、究極的には、将来税収および国有資産に依拠する。

　発行体Ｘ、引受機関Ｙ、店舗Ａ１～Ａｎ、ユーザ（消費者）Ｂ１～Ｂｍを想定して説明する。
　まず、発行体Ｘは５００万ポイントの支援通貨を発行する。発行体Ｘは外部からの指示、たとえば、発行体Ｘ（運営企業）に対して引受機関Ｙからの発行依頼があったときに支援通貨を発行する。
　引受機関Ｙは５００万ポイントの支援通貨を発行体Ｘから５００万円で購入する。引受機関Ｙとしては、政府機関、地方公共団体（「地方自治体」とも称する）、金融機関などが想定される。ここでは、引受機関Ｙは、地域Ｚ（市町村）の経済を活性化したいと考えている地方公共団体であるとして説明する。

　支援通貨は、電子通貨である。
　支援通貨は、１ポイントごとに通貨ＩＤにより識別される。
　支援通貨は、通貨ＩＤおよび取引情報（後述）がパッケージされたオブジェクト（電子的なコンテンツ）である。

　引受機関Ｙは、地域にある店舗Ａ１～Ａｎに支援通貨を配る。
　引受機関Ｙは支援通貨を無償譲渡してもよいし、有償譲渡してもよい。ここでは、無償譲渡であるとして説明する。
　引受機関Ｙは５００万ポイントのうちの５万ポイント分の支援通貨を店舗Ａ１に無償譲渡したとする。店舗Ａ１にとっては、５万円相当の支援金を引受機関Ｙから提供されたことになる。

　引受機関Ｙから店舗Ａ１に５万ポイントが譲渡されるとき、引受機関Ｙは支援通貨に「提供元（Ｙ）、提供先（Ａ１）、提供日時、提供理由（例：店舗支援）」という取引情報Ｄ１を入力する。
　たとえば、通貨ＩＤ＝１の１ポイント分の支援通貨（以下、「支援通貨（１）」とよぶ）に対して、上記の取引情報Ｄ１が付与される。５万ポイントの通貨ＩＤが「１～５００００」であるとすると、引受機関Ｙは、支援通貨（１）～支援通貨（５００００）のすべてに取引情報Ｄ１を付与する。
　店舗Ａ１は、５万ポイントの支援通貨（オブジェクト）を取引情報Ｄ１とともに受け取る。

　このとき、発行体Ｘは譲渡対象となる支援通貨（５万ポイント）の一部、たとえば、１％相当の手数料を受け取る。上記の例の場合、５万ポイントの支援通貨の１％にあたる５００円を、引受機関Ｙは発行体Ｘに支払う。
　発行体Ｘは、手数料を譲渡者の口座から受け取ってもよいし、譲受者の口座から受け取ってもよい。
　引受機関Ｙがあらかじめ導入している支援通貨制御のためのアプリケーション（以下、「支援ツール」とよぶ）は、５万ポイント分の支援通貨を店舗Ａ１に送信するとき、取引情報Ｄ１を支援通貨（オブジェクト）に追加するとともに、発行体Ｘへの５００円分の決済処理を実行する。
　発行体Ｘは、引受機関Ｙの銀行口座から５００円を手数料として受け取る。

　ユーザＢ１は、店舗Ａ１で食事をしたとする。
　このときユーザＢ１は、店舗Ａ１のアンケートに答えたとする。
　アンケートにより「蕎麦アレルギーです」「蕎麦が美味しかった」「蕎麦が好きです」などユーザＢ１に関するさまざまな情報が店舗Ａ１に提供される。
　店舗Ａ１は、ユーザＢ１に情報提供の御礼として５０ポイント分の支援通貨を譲渡する。

　店舗Ａ１からユーザＢ１に５０ポイント分の支援通貨が譲渡されるとき、店舗Ａ１の支援ツールは支援通貨に「提供元（Ａ１）、提供先（Ｂ１）、提供日時、提供理由（例：アンケート回答）」という取引情報Ｄ２を入力する。この例の場合、店舗Ａ１は、支援通貨（１）～支援通貨（５０）のすべてに取引情報Ｄ２を付与する。
　ユーザＢ１は、スマートフォンなどの情報端末により、５０ポイントの支援通貨を取引情報Ｄ１，Ｄ２とともに受け取る。
　なお、店舗およびユーザが導入する支援ツールは、支援通貨に付与される取引情報Ｄ１，Ｄ２を端末に表示させることはない。

　発行体Ｘは譲渡対象となる支援通貨（５０ポイント）の１％分の手数料を店舗Ａ１から徴収する。
　５０ポイントの１％は０．５円となる。手数料が１円（最低引出額）に満たないときには、発行体Ｘは店舗Ａ１の手数料が１円を超えたときにまとめて徴収する。最低引出額は、任意に設定可能である。
　なお、発行体Ｘは、店舗Ａ１（譲渡者）ではなく、ユーザＢ１（譲受者）から手数料を受け取ってもよい。また、発行体Ｘは、店舗Ａ１とユーザＢ１の双方から手数料を受け取ってもよい。

　ユーザＢ１は、別のユーザＢ２から個人的なサービスを受けたとする。
　たとえば、ユーザＢ２は、ユーザＢ１のために荷物運びをしたとする。
　このとき、ユーザＢ１は、ユーザＢ２に御礼として支援通貨を５００ポイント分譲渡する。この５００ポイントの支援通貨のうち２０ポイント分（支援通貨（１）～支援通貨（２０））は、ユーザＢ１が店舗Ａ１から譲渡された支援通貨に由来するとする。
　ユーザＢ１からユーザＢ２に支援通貨が譲渡されるとき、ユーザＢ１の有する情報端末（支援ツール）は、支援通貨に譲渡にともなう取引情報Ｄ３を付与する。
　支援通貨（１）～支援通貨（２０）には取引情報Ｄ１，Ｄ２，Ｄ３が対応づけられる。

　発行体Ｘは譲渡対象となる支援通貨の一部を手数料としてユーザＢ１から徴収する。

　ユーザＢ２は、店舗Ａ１で食事をしたとする。
　ユーザＢ２は、料金の一部または全部を支援通貨で支払うことができる。
　ここでは、２００円分を２００ポイント分の支援通貨で支払ったとする。
　このとき、ユーザＢ２の情報端末から店舗Ａ１の店舗端末に支援通貨が送信される。
　ユーザＢ２の情報端末にインストールされる支援ツールは、２００ポイント分の支援通貨に新たな取引情報Ｄ４を追加する。
　譲渡された２００ポイントの支援通貨のうち１０ポイント分（支援通貨（１）～支援通貨（１０））は、ユーザＢ１が店舗Ａ１から譲渡された支援通貨であり、かつ、ユーザＢ２がユーザＢ１から譲渡された支援通貨であるとする。
　この場合、支援通貨（１）～支援通貨（１０）には取引情報Ｄ１，Ｄ２，Ｄ３，Ｄ４が対応づけられる。

　発行体Ｘは譲渡対象となる支援通貨の一部を手数料としてユーザＢ２から徴収する。

　以上のように、発行体Ｘが発行した支援通貨は、引受機関Ｙを起点として、店舗Ａ１、ユーザＢ１、ユーザＢ２、店舗Ａ１の順に循環している。
　より具体的には、発行体Ｘが発行した５万ポイントの支援通貨（支援通貨（１）～支援通貨（５００００））のうち、５０００ポイントの支援通貨（支援通貨（１）～支援通貨（５０００））は発行体Ｘから引受機関Ｙに譲渡され、そのうち５００ポイントの支援通貨（支援通貨（１）～支援通貨（５０００））は引受機関Ｙから店舗Ａ１に譲渡されている。
　支援通貨（１）～支援通貨（５０００）の一部である支援通貨（１）～支援通貨（５０）は店舗Ａ１からユーザＢ１に譲渡され、更にその一部である支援通貨（１）～支援通貨（２０）はユーザＢ１からユーザＢ２に譲渡され、更にその一部である支援通貨（１）～支援通貨（１０）はユーザＢ２から店舗Ａ１に譲渡されている。
　以上の流通過程において、４回の取引を経由した１０ポイント分の支援通貨（支援通貨（１）～支援通貨（１０））には、取引情報Ｄ１～Ｄ４が付与される。

　ユーザＢ１は、店舗Ａ１で食事をし、アンケートに回答することで５０ポイントの支援通貨を得ることができる。
　この支援通貨は地域Ｚにある店舗Ａ１～Ａｎにおいて現金と同様に使用できる。このため、ユーザＢ１は情報を店舗Ａ１に与えることで利益を得られる。

　ユーザＢ１は、また、ユーザＢ２の親切に対して支援通貨を御礼として使っている。いいかえれば、ユーザＢ１はユーザＢ２に対して支援通貨によりチップを渡している。
　ユーザＢ２が事業者でなく、ユーザＢ１と親しい人間の場合、ユーザＢ１はユーザＢ２に現金貨幣（金銭）で御礼をしづらい。
　一般的に、親しい人間関係において金銭を介在させることは双方が抵抗感を感じやすい。人間の心情として、親しい間柄であればあるほど、その関係にお金を介在させることは適切ではない。
　このため、好意を受けた側は「言葉（ありがとう）」や「贈り物（モノ）」などで感謝の気持ちを表すことが多い。
　本実施形態における支援通貨は現金等価物であるが、ユーザＢ１は「アンケートに答える」というちょっとした行為によって支援通貨をプレゼントされている。このため、ユーザＢ１がユーザＢ２に御礼として支援通貨を渡したときには金銭を手渡すほどの抵抗感が双方に生じることはない。

　ユーザＢ１は、ユーザＢ２に５００ポイントの支援通貨を譲渡するとき、その１％の５円を発行体Ｘに支払う。
　ユーザＢ１は、実質５円の経済負担により、ユーザＢ２に５００円分の価値を提供できる。ユーザＢ１にとってはもともと無料に近い感覚でもらった支援通貨により、気軽に感謝の意を示すことができる。また、ユーザＢ２も、支援通貨はユーザＢ１の労働の成果ではないことを知っているので、支援通貨を気軽に受け取ることができる。

　ユーザＢ２は、日常的な親切行為によって少しずつ支援通貨を得ることができる。
　支援通貨を得ることで店舗Ａ１の食事というサービスを受けることができる。

　店舗Ａ１は、無償でもらった支援通貨を自由に活用できる。
　上記の例においては、店舗Ａ１は、支援通貨をユーザＢ１に提供することで、顧客の消費行動に関する有用な情報を手に入れることができる。また、支援通貨を使用可能とすることで、ユーザＢ２を誘引できる。
　店舗Ａ１は、支援通貨を活用することで事業を効率化・活性化できる。

　引受機関Ｙ（地方自治体）は、５００万円分の予算により、地域Ｚにおいて支援通貨を流通させることができる。引受機関Ｙは、支援通貨を使うことで地域Ｚの店舗Ａ１～Ａｎを活性化できる。地域Ｚが活性化することで引受機関Ｙの税収増加も期待できる。また、地域Ｚの住人は、地域通貨を使用可能な地域Ｚでなるべく消費をしようとするため、この点においても支援通貨は地域経済の活性化に貢献すると考えられる。

　引受機関Ｙは、外国人観光客を地域Ｚに呼び込みたい場合にも、支援通貨を活用できる。引受機関Ｙは、外国人観光客に支援通貨を配布してもよい。支援通貨を配布された外国人は、地域Ｚでの観光に魅力を感じ、地域Ｚにおいて支援通貨だけでなく現金貨幣も使用する可能性がある。

　発行体Ｘは、支援通貨が流通することにより手数料収入を得ることができる。

　発行体Ｘと引受機関Ｙは、支援通貨に付与される取引情報を参照することにより、支援通貨がどのように流通しているか（流通速度、流通経路、取引成立の理由）を知ることができる。これにより、地域経済を活性化するために必要な政策を適切に立案しやすくなる。たとえば、発行体Ｘあるいは引受機関Ｙは、どの店舗に支援通貨を配るのが効果的か、地域Ｚの住民のうちのどの程度まで支援通貨が普及しているかを分析できる。

　支援通貨は、もともと引受機関Ｙから無償譲渡された上で流通が開始する。地域通貨を受け入れ可能な店舗（事業体）あるいはユーザ（消費者）が増えることで支援通貨の流通はいっそう促進される。
　また、小さな親切に対して感謝の気持ちを抵抗感なく示すためのツールになることも、支援通貨の流通促進に寄与する。たとえば、ユーザＢ３が店舗Ａ２のサービスに満足したとき、ユーザＢ３はチップとして支援通貨を店舗Ａ２に提供してもよい。

　支援通貨は減価通貨であってもよい。たとえば、ユーザＢ３がユーザＢ４に５０１ポイントの支援通貨を譲渡したとき、ユーザＢ４は５００ポイントの支援通貨を受け取り、１ポイント分の支援通貨は減価するとしてもよい。
　取引とともに支援通貨が減るので、発行体Ｘは支援通貨をいずれ再発行することになる。このように発行と減価を繰り返すことで支援通貨の流通速度をいっそう向上させることもできる。

　支援通貨は、一定時間ごとに減価してもよい。たとえば、支援通貨は１日ごとに１％ずつ自動的に減価するとしてもよい。この場合、ユーザは支援通貨を貯め込むと損をするため、できるだけ消費行動に使おうする。このような制御方法によっても支援通貨の流通をいっそう促進できる。

　貨幣は、取引を通してその価値を高める。支援通貨も、貨幣（現金）と同じく地域Ｚ内において循環することでその価値を高めていく。貨幣とは別に、あるいは、貨幣に附随して支援通貨が循環することにより、ＧＤＰの実質的な向上にもつながると考えられる。貨幣の流通速度が高まるほどＧＤＰは大きくなるため、実質的なＧＤＰは、貨幣によるＧＤＰに支援通貨のＧＤＰが加算されたものとなる。

　物流においても支援通貨を利用可能である。この場合、物流会社は引受機関Ｙとなって支援通貨を発行体Ｘから買い取る。
　ユーザＢ５（送り手）からユーザＢ６（受け手）に荷物を配送するとする。
　ユーザＢ６（受け手）は、荷物の受取可能日時を設定する。
　物流会社から指定された運送担当者Ｃ１は、指定日時にユーザＢ６（受け手）の家に荷物を運ぶ。
　運送担当者Ｃ１は指定日時に荷物を届ければ物流会社から支援通貨をもらえる。また、ユーザＢ６（受け手）が指定日時において荷物を受け取れば同じく物流会社から支援通貨をもらえる。

　一方、指定日時においてユーザＢ６（受け手）が不在のため荷物の受け渡しができなかったとする。
　この場合にも運送担当者Ｃ１は指定日時にユーザＢ６の家に到着していれば支援通貨をもらえる。一方、不在だったユーザＢ６は支援通貨をもらうことはできない。
　運送担当者Ｃ１は再配達になったとしても、労賃として支援通貨をもらえる。したがって、再配達という労力が発生したとしても支援通貨による補償を受けることができる。
　ユーザＢ６（受け手）は、指定日時に在宅していれば物流会社から支援通貨をもらうことができる。しかし、再配達になってしまったときには支援通貨をもらえない。このような仕組みにより、ユーザＢ６（受け手）は指定日時に確実に荷物を受け取れるように在宅しておこうという気持ちをもたせることができる。

　支援通貨そのものに取引情報を付与してもよいし、支援通貨に「通貨ＩＤ、取引ＩＤ」を付与して取引情報をこれらに対応づけて管理してもよい。
　たとえば、ユーザＢ１からユーザＢ２に支援通貨が譲渡されたとき、ユーザＢ１の通信端末は取引ＩＤを生成する。同一の取引ＩＤが生成されないように、取引ＩＤには時刻などの一時的な情報を含めてもよい。
　通信端末（Ｂ１）は、支援通貨を譲渡するとき、取引ＩＤおよび取引情報を発行体Ｘのサーバに通知する。
　サーバは、取引ＩＤと取引情報を対応づけて登録する。
　通信端末（Ｂ１）は、取引情報をローカルメモリから削除する。すなわち、支援通貨には「通貨ＩＤおよび取引ＩＤ」のみが含まれるとしてもよい。
　発行体は、支援通貨に付与される通貨ＩＤと取引ＩＤを確認することにより、支援通貨の取引情報を取得できる。

　情報の対価として支援通貨を付与してもよい。
　ユーザＢ１がある情報、たとえば、地域Ｚにおけるヴィーガンのための美味しいお店を知りたいとする。
　ユーザＢ１は情報を募集する。これに対して、他のユーザが情報を提供したとする。ユーザＢ１は情報を提供してくれた他のユーザに対して、御礼として支援通貨を支払ってもよい。

　支援通貨の取引は、ウェブブラウザや既知の二次元コードなどを介して行うことができる。

　ユーザ間で行われる取引は、物を譲渡・貸与することであってもよいし、サービスを提供することであってもよい。

　Ａ１．第１のユーザと第２のユーザの間で取引が行われるとき、第１のユーザの第１の通信端末は、支援通貨を第２のユーザの第２の通信端末に転送するとともに取引の種別を支援通貨に対応づけてもよい。

　Ａ２．第１の通信端末は、第２の通信端末に近距離無線通信により支援通貨を直接送信してもよいし、ゲートウェイサーバ等の中継装置を介して送信してもよい。

　Ａ３．取引が行われるとき、支援通貨の一部は、支援通貨の発行体に支払われる。

　以下においては、本実施形態における支援通貨管理システム２００の機能および構成について詳細に説明する。

　図１は、支援通貨の循環を説明するための模式図である。
　まず、地方公共団体（引受機関）、運営会社（発行体）およびユーザ（Ｐ１）、ユーザ（Ｐ２）の４者を想定し、支援通貨が循環する過程について説明する。ここで、「ユーザ」とは支援通貨による取引の担い手となる経済主体であり、個人または店舗（事業者）の双方を意味するものとして説明する。

　本実施形態においては「基本通貨」と「支援通貨」の２種類の通貨がユーザ間において循環する。基本通貨とは、法定通貨のほか、金、銀、暗号通貨など既知・既存の通貨であればよい。支援通貨は、地方公共団体、政府、ＮＰＯ（Non-Profit Organization）、企業などが引受機関となり、運営会社に発行してもらう独自のデジタル通貨である。本実施形態においては、地方公共団体が支援通貨の発行を依頼する主体（発行を依頼する主体）である。支援通貨は地域経済振興のために、基本通貨の流通を促進することを目的として発行される。

　支援通貨の単位を「ポイント（ｐｔ）」とよぶ。１（ｐｔ）の支援通貨は、１（円）の価値に相当する。運営会社は、地方公共団体からの発行依頼に応じて支援通貨を発行し、支援通貨を管理する。運営会社は、地方公共団体からの依頼に基づいて支援通貨を発行する主体（発行を実行する主体）である。

　まず、地方公共団体は、法定通貨（基本通貨Ｌ）を運営会社に支払い（Ｓ１）、その対価として、運営会社は支援通貨Ｓを地方公共団体に発行する（Ｓ２）。このとき、運営会社は少しの手数料を地方公共団体から徴収する。地方公共団体は、引き受けた支援通貨をユーザ（Ｐ１）に譲渡する（Ｓ３）。運営会社はユーザ（Ｐ１）（譲受人）から少し手数料を徴収する。ユーザ（Ｐ１）は基本通貨を地方公共団体に支払うことで支援通貨を買い取ってもよい（Ｓ４）。あるいは、地方公共団体は、支援通貨をユーザ（Ｐ１）に無償譲渡してもよい。以下においては、無償譲渡を想定して説明する。

　ユーザ（Ｐ２）は、商品またはサービスをユーザ（Ｐ１）に提供する。以下においては、特に断らない限り「商品」は「サービス」を含む概念であるとして説明する。ユーザ（Ｐ１）は、商品の対価をユーザ（Ｐ２）に支援通貨によって支払ったとする（Ｓ５）。運営会社はこの取引に際して、譲受人であるユーザ（Ｐ２）から手数料を徴収する。

　ユーザ（Ｐ２）は、運営会社に支援通貨と基本通貨の換金を要求できる。ユーザ（Ｐ２）は運営会社に支援通貨を支払い（Ｓ６）、運営会社はユーザ（Ｐ２）に基本通貨を支払う（Ｓ７）。このときにも、運営会社は基本通貨の一部を手数料としてユーザ（Ｐ２）から徴収する。
　以上のように、地方公共団体、運営会社の２者により発行される支援通貨が多数のユーザの間で循環する。

　図２は、支援通貨の送金方法を説明するための模式図である。
　ユーザは、ユーザＩＤにより識別される。以下、ユーザ（Ｐ１）とは、ユーザＩＤ＝Ｐ１のユーザを意味するものとする。ここでは、ユーザ（Ｐ１）から、ユーザ（Ｐ２）に支援通貨を送金（譲渡）する場合を想定して説明する。

　まず、支援通貨は、１（ｐｔ）（１円相当）ごとに通貨ＩＤによって識別される。ユーザ（Ｐ１）の通信端末１００（以下、「通信端末（Ｐ１）」のように表記する）には、通貨ＩＤ＝Ｃ１の支援通貨（以下、「支援通貨（Ｃ１）」のように表記する）が保存されている。支援通貨の実体は、通貨ＩＤ＝Ｃ１を示すデータと、１以上の取引情報３２０から構成されるデータセットである。図２に示す支援通貨（Ｃ１）には、ｎ個の取引情報３２０（１）～３２０（ｎ）が対応づけられている。取引情報３２０の詳細については後述する。

　通貨ＩＤは、数字であってもよいし、数字および文字の組み合わせであってもよい。たとえば、通貨ＩＤは、支援通貨の種類（後述）を示す文字情報、支援通貨の発行日時を示す数字情報、通し番号などが含まれてもよい。いずれの形式であっても、通貨ＩＤは、１（ｐｔ）、いいかえれば、１単位の支援通貨を一意に識別可能な情報であればよい。

　譲渡側の通信端末１００（Ｐ１）と、譲受側の通信端末１００（Ｐ２）には、ＤＩエンジンとよばれる支援ツールがあらかじめ搭載されている。本実施形態におけるＤＩエンジンは通信機能を有するＩＣ（Integrated Circuit）チップおよび軽量のソフトウェアにより構成される。

　通信端末１００（Ｐ１）の支援ツールは、支援通貨（Ｃ１）にユーザ（Ｐ２）との取引内容を示す取引情報３２０（ｎ＋１）を追加した上で、通信端末１００（Ｐ２）に支援通貨（Ｃ１）を送信する。支援通貨（Ｃ１）の送信後、通信端末１００（Ｐ１）の支援ツールは通信端末１００（Ｐ１）のローカルストレージから支援通貨（Ｃ１）を削除する。これにより、ユーザ（Ｐ１）は、１（ｐｔ）の支援通貨（Ｃ１）を失う。

　一方、譲受側の通信端末１００（Ｐ２）の支援ツールは、支援通貨（Ｃ１）を受信したとき、支援通貨（Ｃ１）を通信端末１００（Ｐ２）のローカルストレージに記録する。こにより、ユーザ（Ｐ２）は、１（ｐｔ）の支援通貨（Ｃ１）を取得する。

　以上のように、ユーザ間で支援通貨が移転されるとき、譲渡側からは支援通貨（デジタルデータ）が削除され、譲受側においては支援通貨が記録される。また、取引が発生するごとに、支援通貨には取引情報３２０が追加される。

　より詳細には、通信端末１００（Ｐ１）の支援ツールは、支援通貨を暗号化してローカルストレージに保存している。通信端末１００（Ｐ１）は、支援通貨を暗号化した状態で送信する。通信端末１００（Ｐ２）における支援ツールは、受信した支援通貨を復号することで支援通貨の真正性を認証した上で、再び暗号化して通信端末（Ｐ２）のローカルストレージに保存する。支援通貨の暗号化および復号は、支援ツールにより自動的に実行される。ユーザは、支援通貨の暗号化および復号に関わることはできない。

　ユーザ（Ｐ１）からユーザ（Ｐ２）に支援通貨が支払われる場合としては、ユーザ（Ｐ１）がユーザ（Ｐ２）から商品を購入した場合のほか、ユーザ（Ｐ２）の親切に対するお礼、ユーザ（Ｐ２）への贈与なども考えられる。取引が行われるごとに、支援通貨には取引情報３２０が追加される。

　図３は、支援通貨管理システム２００のハードウェア構成図である。
　支援通貨管理システム２００においては、地方公共団体が管理する発行サーバ１１０（発行システム）、運営会社が管理する運営サーバ１２０（運営システム）、決済システム１０４および複数の通信端末１００が、インターネット１０２を介して相互に接続される。

　地方自治体（発行サーバ１１０）は、運営会社（運営サーバ１２０）に対して支援通貨の発行を依頼する。発行依頼には、支援通貨の使用条件（後述）と発行量が含まれる。運営サーバ１２０は、依頼にしたがって支援通貨を発行する。地方自治体は、発行された支援通貨を一部または特定の通信端末１００に配布する。決済システム１０４は、金融機関が運営するシステムである。

　通信端末１００としては、スマートフォン、ラップトップＰＣ、ＰＯＳ（Point Of Sales）端末などが想定される。個人または事業体は、通信端末１００により支援通貨を互いに送受する。

　図４は、通信端末１００のハードウェア構成図である。
　通信端末１００は、コンピュータプログラムを格納する不揮発性メモリとしてのストレージ３１２、プログラムおよびデータを展開する揮発性のメモリ３０４、レジスタ、演算器、命令デコーダ等を内蔵し、メモリ３０４からプログラムを読み出して実行するプロセッサ３００（ＣＰＵ：Central Processing Unit）等を含む。プロセッサ３００は、比較的高速な第１バス３０２と接続される。第１バス３０２には、メモリ３０４のほかＮＩＣ（Network Interface Card）が接続される。第１バス３０２には、このほか、ＧＰＵ（Graphics Processing Unit）等の他のデバイスが接続されてもよい。

　第１バス３０２は、ブリッジ３０８を介して比較的低速な第２バス３１０と接続される。第２バス３１０には、ストレージ３１２のほか、モニタあるいはスピーカなどの出力デバイス３１６が接続される。また、第２バス３１０には、マウスやキーボードなどの入力デバイス３１４、プリンタなどの周辺機器３１８が接続されてもよい。
　なお、発行サーバ１１０および運営サーバ１２０のハードウェア構成についても、基本的には同様である。

　図５は、通信端末１００の機能ブロック図である。
　通信端末１００の各構成要素は、ＣＰＵおよび各種コプロセッサ（co-processor）などの演算器、メモリやストレージといった記憶装置、それらを連結する有線または無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。
　通信端末１００本体および通信端末１００に搭載されるＤＩエンジン（支援ツール）により、図５に示す各機能が実現される。
　以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。発行サーバ１１０、運営サーバ１２０についても同様である。

　通信端末１００は、ユーザインタフェース処理部１３０、通信部１３２、データ処理部１３４およびデータ格納部１３６を含む。
　ユーザインタフェース処理部１３０は、入力デバイスを介してユーザからの操作を受け付けるほか、画像表示や音声出力など、ユーザインタフェースに関する処理を担当する。通信部１３２は、他の通信端末１００等との通信処理を担当する。データ格納部１３６は各種データを格納する。データ処理部１３４は、ユーザインタフェース処理部１３０からの入力、通信部１３２の受信データおよびデータ格納部１３６に格納されているデータに基づいて各種処理を実行する。データ処理部１３４は、通信部１３２、ユーザインタフェース処理部１３０およびデータ格納部１３６のインタフェースとしても機能する。

　ユーザインタフェース処理部１３０は、入力部１３８および出力部１４０を含む。
　入力部１３８は、ユーザからの各種入力を受け付ける。出力部１４０は、ユーザに対して各種情報を出力する。

　通信部１３２は、送信部１４２と受信部１４４を含む。
　送信部１４２は、外部装置に各種データを送信する。受信部１４４は、外部装置から各種データを受信する。

　データ処理部１３４は、取引管理部１４６を含む。取引管理部１４６は、他の通信端末１００に支援通貨を送信するとき、支援通貨に取引情報３２０を追加する。取引管理部１４６は、支援通貨の暗号化および復号も実行する。

　データ格納部１３６は、通貨格納部１４８を含む。通貨格納部１４８は、支援通貨に対応するデジタルデータを管理する。支援通貨は暗号化された状態で通貨格納部１４８に保存される。

　図６は、運営サーバ１２０の機能ブロック図である。
　運営サーバ１２０は運営会社が管理するサーバである。運営サーバ１２０は、通信部１５０、データ処理部１５２およびデータ格納部１５４を含む。通信部１５０は、通信端末１００等の外部装置との通信処理を担当する。データ格納部１５４は各種情報を格納する。データ処理部１５２は、通信部１５０により取得されたデータおよびデータ格納部１５４に格納されているデータに基づいて各種処理を実行する。データ処理部１５２は、通信部１５０およびデータ格納部１５４のインタフェースとしても機能する。

　通信部１５０は、送信部１５６と受信部１５８を含む。
　送信部１５６は、外部装置に各種データを送信する。受信部１５８は、外部装置から各種データを受信する。

　データ処理部１５２は、通貨交換部１８０、手数料徴収部１６０、決済管理部１６２、集計部１６４、ユーザ管理部１０６および発行部１６６を含む。
　ユーザ管理部１０６は、支援ツールを搭載済みの通信端末１００からユーザ登録要求が受信されたとき、ユーザにユーザＩＤを付与する。また、ユーザ登録に際しては、ユーザの住所、性別、職業、銀行口座番号などの属性情報をユーザＩＤと対応づけてユーザ情報として登録する。運営サーバ１２０は、ユーザ情報を発行サーバ１１０と共用する。

　手数料徴収部１６０は、支援通貨による取引が発生したとき、支援通貨を受け取った側のユーザの銀行口座から手数料を徴収する。別例として、手数料徴収部１６０は、支援通貨を受け取った側ではなく、支払った側のユーザの銀行口座から手数料を徴収するとしてもよい。決済管理部１６２は、地方自治体から基本通貨を受け入れ、支援通貨を発行するための決済を実行する。決済管理部１６２は地方自治体の銀行口座から支援通貨の代金（基本通貨）を引き落として預り金（以下、「運営預託通貨」とよぶ）として管理する。集計部１６４は、支援通貨の取引情報３２０を集計し、経済効果を分析する。発行部１６６は、支援通貨を発行する。また、発行部１６６は、支援通貨の発行に際して、支援通貨の使用条件（後述）をデータ格納部１５４に登録する。通貨交換部１８０は、基本通貨と支援通貨を交換する。

　図７は、発行サーバ１１０の機能ブロック図である。
　発行サーバ１１０は地方自治体が管理するサーバである。発行サーバ１１０は、通信部１７０、データ処理部１７２およびデータ格納部１７４を含む。通信部１７０は、通信端末１００等の外部装置との通信処理を担当する。データ格納部１７４は各種情報を格納する。データ処理部１７２は、通信部１７０により取得されたデータおよびデータ格納部１７４に格納されているデータに基づいて各種処理を実行する。データ処理部１７２は、通信部１７０およびデータ格納部１７４のインタフェースとしても機能する。

　通信部１７０は、送信部１７６と受信部１７８を含む。
　送信部１７６は、外部装置に各種データを送信する。受信部１７８は、外部装置から各種データを受信する。

　データ処理部１７２は、特典付与部１８２と配布部１０８を含む。
　特典付与部１８２は、取引について所定の特典条件が成立したとき、取引者に対して特典を付与する。配布部１０８は、支援通貨を通信端末１００に配布する。

　図８は、支援通貨の発行および配布過程を示すシーケンス図である。
　まず、地方自治体の発行サーバ１１０から運営会社の運営サーバ１２０に支援通貨の発行要求を送信する（Ｓ１０）。発行要求には発行量および使用条件が含まれる。このとき、地方自治体は、発行額に見合う基本通貨（法定通貨）を運営会社に支払う。たとえば、１００億（ｐｔ）の支援通貨を発行するときには、地方自治体は１００億（円）を運営会社に支払う。

　運営サーバ１２０の発行部１６６は、指定された量の支援通貨を発行する（Ｓ１２）。このとき発行部１６６は、支援通貨に通貨ＩＤを設定する。上述したように、通貨ＩＤは１（ｐｔ）単位の通貨を識別可能な情報であればよい。決済管理部１６２は、地方自治体の銀行口座を対象として基本通貨による決済を決済システム１０４に指示する（Ｓ１４）。この決済処理により、基本通貨が地方自治体から運営会社に振込まれる。運営会社は、地方自治体から受け取った資金（基本通貨）を運営預託通貨として管理する。一方、地方自治体は、運営会社から受け取った支援通貨を「発行預託通貨」として管理する。手数料徴収部１６０は、支援通貨の発行にともなう手数料を徴収する（Ｓ１６）。手数料徴収部１６０は、手数料を振込額に上乗せする方式により、手数料を振込額といっしょに徴収してもよい。

　発行サーバ１１０の配布部１０８は、発行預託通貨（支援通貨）を複数の通信端末１００に無償配布する。たとえば、発行サーバ１１０は、１００億（ｐｔ）の発行預託通貨を保有しているときには、住民１人あたり１０００（ｐｔ）ずつ支援通貨を配布してもよい。これにより、ユーザは地方自治体から１０００（ｐｔ）の支援通貨をもらう。
　なお、発行サーバ１１０を通すことなく、運営サーバ１２０から通信端末１００に支援通貨を直接送信することで、支援通貨を発行してもよい。すなわち、発行サーバ１１０が支援通貨の発行量および配布先を運営サーバ１２０に通知し、運営サーバ１２０は通知にしたがって支援通貨を通信端末１００に送信するとしてもよい。

　支援通貨の配布対象は、地方自治体の政策担当者が任意に設定すればよい。たとえば、政策担当者は、新たに発行される支援通貨の配布先を、地域Ｚにある店舗に限定してもよい。ユーザ（店舗）は、支援通貨管理システム２００に会員登録するときに、店舗の規模・業態・場所などの属性情報を運営サーバ１２０にユーザ情報として登録しておく。発行サーバ１１０の配布部１０８は、運営サーバ１２０と共用するユーザ情報を参照し、配布対象となるユーザのアドレスを対象として、支援通貨を送信する。

　あるいは、地域Ｚの訪問者を対象として支援通貨を発行してもよい。ユーザ（Ｐ３）は、地域Ｚ以外を居住地とするユーザであるとする。ユーザ（Ｐ３）が地域Ｚに来たとき、通信端末１００（Ｐ３）は、位置情報とユーザＩＤを発行サーバ１１０に送信する。発行サーバ１１０の配布部１０８は、ユーザＩＤおよび位置情報に基づいて、ユーザ（Ｐ３）が他の地域から地域Ｚを訪問したユーザであることを検出し、通信端末１００（Ｐ３）に訪問の御礼として支援通貨を送信する。このような制御方法によれば、他地域から地域Ｚへの訪問意欲を喚起できる。また、訪問者が受け取った支援通貨は、地域Ｚにおける消費活動を促す。

　複数の地方自治体は独自の支援通貨を発行できる。また、１つの地方自治体が複数種類の支援通貨を発行することもできる。支援通貨の種別は、種別ＩＤにより識別される。以下においては、主として、小田原市で発行される支援通貨（種別ＩＤ＝Ｋ１）を想定して説明する。また、小田原市で発行される支援通貨を「支援通貨（Ｋ１＜小田原＞）」あるいは発行対象地域を省略した「支援通貨（Ｋ１）」のように表記する。小田原市は、日光市と姉妹都市である。支援通貨（Ｋ１＜小田原＞）は、小田原市だけでなく日光市でも使うことができるように使用条件が設定される。同様にして、日光市で発行される支援通貨（種別ＩＤ＝Ｋ４）（上述の通り、「支援通貨（Ｋ４＜日光＞）」または「支援通貨（Ｋ４）」と表記する）、日光市だけでなく小田原市でも使うことができる。

　図９は、ユーザ（Ｐ１）が所有する通信端末１００（Ｐ１）における支払画面１９８の画面図である。
　ここでは、ユーザ（Ｐ１）が、「Ａ－Ｓｈｏｐ」という店舗（ユーザ（Ｐ４））で「くつ下Ｂ」を購入する場合を想定して説明する。店舗（Ｐ４）に設置された通信端末１００（Ｐ４）は、ＰＯＳ端末であるとする。商品精算時において、通信端末１００（Ｐ４）は商品名、金額等の取引内容を示す情報を通信端末１００（Ｐ１）に送信する。通信端末１００（Ｐ１）の出力部１４０は、支払画面１９８を表示させる。ユーザ（Ｐ１）は支払画面１９８により、購入対象商品を確認する。

　ユーザ（Ｐ１）は、商品対価を基本通貨と支援通貨のいずれかで支払う。基本通貨と支援通貨の両方で対価を支払ってもよい。通貨選択領域１９０には、基本通貨ボタン１９２および支援通貨ボタン１９４が表示される。ユーザ（Ｐ１）は、基本通貨で支払うときには基本通貨ボタン１９２をタッチし、支払金額を入力する。支援通貨で支払うときには支援通貨ボタン１９４をタッチし、支払金額（ポイント数）を入力する。たとえば、「くつ下Ｂ」が１，４００（円）であるとき、基本通貨で１，０００（円）を支払い、残りの４００（円）を支援通貨で支払ってもよい。基本通貨による支払い方法はクレジットカードあるいは電子マネーによる支払い方法と同様である。支援通貨ボタン１９４をタッチしたときには次の図１０に示す支援通貨選択画面２０２が表示される（後述）。

　上述したように、通信端末１００（Ｐ４）は、取引内容を示す情報を通信端末１００（Ｐ１）に送信する。ユーザ（Ｐ１）が取引内容ボタン１９６をタッチすると、出力部１４０は取引内容を表示させる。ユーザ（Ｐ１）は取引内容の表示画面（不図示）において取引内容を確認し、必要に応じて修正できる。このとき、ユーザ（Ｐ１）は、取引理由を入力できる。取引理由としては、「商品購入」「プレゼント」「親切に対する御礼」「借入金の返済」「貸付け」などが考えられる。

　商品対価の支払い方法について基本通貨および支援通貨の配分を決定したあと、ユーザ（Ｐ１）は支払ボタン２０４をタッチする。支援通貨による支払いがあるときには、支援通貨には取引情報３２０が追加され、通信端末１００（Ｐ３）に送信される。基本通貨による支払いがあるときには、基本通貨による決済も実行される。

　図１０は、通信端末１００における支援通貨選択画面２０２の画面図である。
　支払画面１９８の支援通貨ボタン１９４がタッチされたとき（図９参照）、通信端末１００（Ｐ１）の出力部１４０は、支援通貨選択画面２０２を表示させる。支援通貨選択画面２０２には、ユーザ（Ｐ１）が保有する支援通貨とその保有量を示す選択ボタン２０６が表示される。図１０によれば、ユーザ（Ｐ１）は、渋谷で発行された支援通貨（Ｋ２＜渋谷＞）を５２０（ｐｔ）、大阪で発行された支援通貨（Ｋ５＜大阪＞）を１１，０００（ｐｔ）、小田原で発行された支援通貨（Ｋ１＜小田原＞）を１８，４５３（ｐｔ）、日光で発行された支援通貨（Ｋ４＜日光＞）を１３０（ｐｔ）保有している。

　ユーザ（Ｐ４）は、小田原市に存在する店舗であり、支援通貨（Ｋ１＜小田原＞）と、小田原市と提携する日光市による支援通貨（Ｋ４＜日光＞）を使用可能であるとする。通信端末１００（Ｐ４）は取引に際して、受け入れ可能な支援通貨の種別を通信端末１００（Ｐ１）に通知する。通信端末１００（Ｐ１）の出力部１４０は、使用できない支援通貨（Ｋ２＜渋谷＞）と支援通貨（Ｋ５＜大阪＞）に対応する選択ボタン２０６をグレーアウト表示させ、選択不可に設定する。

　ユーザ（Ｐ１）は、小田原市の店舗（Ｐ４）において、支援通貨（Ｋ１＜小田原＞）および支援通貨（Ｋ４＜日光＞）を使用可能である。ユーザ（Ｐ１）は、支援通貨（Ｋ１）を選択したとき、その使用量（ポイント数）を決める。支援通貨（Ｋ４＜日光＞）を選択したときも同様である。支援通貨（Ｋ４＜日光＞）を小田原市で使用すると、ユーザ（Ｐ１）には特典が付与される。支援通貨（Ｋ４＜日光＞）には、あらかじめ、「小田原市で使用されたとき」に特典を付与するという特典条件が設定されている。出力部１４０は、特典を得られる支援通貨の選択ボタン２０６にはチャンスマーク２０８を追加表示させる。

　発行サーバ１１０は、各支援通貨についての特典条件が登録されている。したがって、ユーザ（Ｐ１）が支援通貨（Ｋ４＜日光＞）を使用したときには、特典付与部１８２はユーザ（Ｐ１）に特典を付与する。特典は任意であるが、たとえば、日光で使用可能な食事券（デジタルデータ）、支援通貨（Ｋ４＜日光＞）などであってもよい。

　図１１は、取引情報３２０のデータ構造図である。
　送信側の通信端末１００における取引管理部１４６は、取引実行時に取引ＩＤを生成し、取引情報３２０に取引ＩＤを付与する。取引ＩＤは、時刻、ユーザＩＤの固有情報を含むハッシュ値として生成される。取引管理部１４６は、取引発生時の時刻、取引発生地点、取引対象者のユーザＩＤなど、取引を一意に識別可能な情報を取引情報３２０に含めればよい。そして、これらの取引を識別可能な情報を「取引ＩＤ」とみなしてもよい。取引情報３２０には、送信者（譲渡者）のユーザＩＤ、受信者（譲受者）のユーザＩＤ、取引対象となった商品名（商品コード）、商品価格、支援通貨および基本通貨の使用量、取引日時、取引理由など、取引の詳細を示すさまざまな情報が含まれる。

　たとえば、ユーザ（Ｐ１）がユーザ（Ｐ５）に「洋服（Ｂ２）」の対価として２，０００（円）を支払うとする。ユーザ（Ｐ１）は２，０００（円）のうち、１，５００（円）を基本通貨で支払い、残りの５００（円）に相当する５００（ｐｔ）を支援通貨（Ｋ１＜小田原＞）で支払ったとする。この取引についての取引ＩＤは「Ｔ１」であるとする。この場合、通信端末１００（Ｐ１）の取引管理部１４６は、５００（ｐｔ）分の支援通貨（Ｋ１＜小田原＞）、いいかえれば５００個の支援通貨（Ｋ１＜小田原＞）それぞれに対して、取引情報３２０（Ｔ１）を追加する。通信端末１００（Ｐ１）は、取引情報３２０（Ｔ１）を追加された５００（ｐｔ）分の支援通貨（Ｋ１＜小田原＞）を通信端末１００（Ｐ５）に送信する。

　取引情報３２０には、貢献度データ２１０も含まれる。取引（Ｔ１）においては、５００（ｐｔ）の支援通貨により、２，０００（円）分の経済取引が成立している。この場合、取引管理部１４６は、支援通貨の流通貢献度を「４（＝２，０００÷５００）」として算出する。流通貢献度とは、取引価格／支援通貨を示し、支援通貨がどのくらい基本通貨を動かしたかを示す。取引（Ｔ１）の場合、ユーザ（Ｐ１）は、５００（ｐｔ）の支援通貨（Ｋ１＜小田原＞）を使用する権利を有していたために、２，０００（円）の洋服（Ｂ２）の購入を決断したと考えられる。

　取引（Ｔ１）で使われた支援通貨（Ｋ１＜小田原＞）のうち、通貨ＩＤ＝Ｃ１の支援通貨は、支援通貨（Ｋ１＜小田原＞：Ｃ１）あるいは、支援通貨（Ｋ１：Ｃ１）と表現される。ここで、支援通貨（Ｋ１：Ｃ１）が、更に次の取引（Ｔ２）でも使用されたとする。取引（Ｔ２）においては、ユーザ（Ｐ５）からユーザ（Ｐ８）には「アンケートへの回答の御礼」として１５０（ｐｔ）の支援通貨（Ｋ１）が支払われている。取引（Ｔ２）においては、基本通貨の支払いは付随していないため、流通貢献度は「０」である。通信端末１００（Ｐ５）の取引管理部１４６は、支援通貨（Ｋ１：Ｃ１）に取引情報３２０（Ｔ２）を追加する。

　支援通貨（Ｋ１：Ｃ１）は、更に、次の取引（Ｔ３）でも使用されたとする。取引（Ｔ３）においては、ユーザ（Ｐ８）からユーザ（Ｐ４）に対してランチの代金として１，５００（円）が支払われている。このうち、支援通貨（Ｋ１）による支払いは５００（ｐｔ）なので流通貢献度は「３（＝１，５００÷５００）」となる。通信端末１００（Ｐ８）の取引管理部１４６は、支援通貨（Ｋ１：Ｃ１）に取引情報３２０（Ｔ３）を追加する。

　以上のように、支援通貨には、取引に使用されるごとに、取引情報３２０が追加される。このため、支援通貨の取引情報３２０を参照することで、１つ１つの支援通貨についての取引履歴を知ることができる。

　支援通貨は、給料、アルバイト料などの労賃として支払われてもよい。あるいは、ユーザが店舗に会員登録をしたときや、来店したとき、商品をＳＮＳ（Social Networking Service）で紹介したときの御礼として支払われてもよい。

　図１２は、支援通貨に含まれる取引情報３２０のデータ構造図である。
　上述したように、複数の支援通貨は、種別ＩＤにより識別される。支援通貨（Ｋ１＜小田原＞）のグループには、複数単位の支援通貨（Ｋ１＜小田原＞）が含まれる。支援通貨（Ｋ１）は１（ｐｔ）が１単位であり、通貨ＩＤにより識別される。

　通貨ＩＤ＝Ｃ１の支援通貨（Ｋ１：Ｃ１）は、さまざまなユーザ間の取引によって通信端末１００の間を移転する。取引が発生するごとに、送信側の通信端末１００により取引情報３２０が追加される。他の支援通貨についても、同様である。このように、１単位（ｐｔ）の支援通貨には、１以上の取引情報３２０が含まれる。図１２は、支援通貨（Ｋ１＜小田原＞：Ｃ１）から支援通貨（Ｋ１＜小田原＞：Ｃｎ）のデータ構造を示している。支援通貨（Ｋ１＜小田原＞）以外の支援通貨についても同様である。

　図１３は、支援通貨の移転状況を示す模式図である。
　ここでは、説明を簡略化するため、ユーザ間の取引における支援通貨の移転の様子を模式的に示すが、実際の取引においては多数のユーザの間にて支援通貨は複雑に移転していく。図１３においては、ユーザ（Ｐ１）が保有する支援通貨の一部がユーザ（Ｐ５）に移転され（取引（Ｔ１））、ユーザ（Ｐ５）が保有する支援通貨の一部がユーザ（Ｐ８）に移転され（取引（Ｔ２））、ユーザ（Ｐ８）が保有する支援通貨の一部がユーザ（Ｐ４）に移転される場合を想定して説明する（取引（Ｔ３））。

　まず、取引（Ｔ１）において、ユーザ（Ｐ１）が保有する支援通貨の一部がユーザ（Ｐ５）に移転される。ここでは、支援通貨（Ｃ１）、支援通貨（Ｃ２）、支援通貨（Ｃ３）が送信されたとする。このとき、通信端末１００（Ｐ１）の取引管理部１４６は、これらの３単位の支援通貨それぞれに取引情報３２０（Ｔ１）を付与する。

　次に、取引（Ｔ２）において、ユーザ（Ｐ５）が保有する支援通貨の一部がユーザ（Ｐ８）に移転される。支援通貨（Ｃ１）と支援通貨（Ｃ３）が送信され、ユーザ（Ｐ８）がもともと保有していた支援通貨（Ｃ４）も送信対象になったとする。一方、ユーザ（Ｐ８）が取引（Ｔ１）で手に入れた支援通貨（Ｃ２）は移転していない。

　取引（Ｔ２）が終わった時点で、支援通貨（Ｃ１）と支援通貨（Ｃ３）には取引情報３２０（Ｔ１）と取引情報３２０（Ｔ２）が追加されている。支援通貨（Ｃ２）にとって最新の取引情報３２０は取引情報３２０（Ｔ１）であり、支援通貨（Ｃ４）には取引情報３２０（Ｔ２）が追加される。

　取引（Ｔ３）において、ユーザ（Ｐ８）が保有する支援通貨の一部がユーザ（Ｐ４）に移転される。支援通貨（Ｃ１）と支援通貨（Ｃ５）が移転され、支援通貨（Ｃ４）は移転されていない。通信端末１００（Ｐ８）は、支援通貨（Ｃ１）と支援通貨（Ｃ５）に取引情報３２０（Ｔ３）を追加する。

　取引（Ｔ３）が終わった時点で、支援通貨（Ｃ１）には取引情報３２０（Ｔ１）～３２０（Ｔ３）が追加されている。支援通貨（Ｃ２）には取引情報３２０（Ｔ１）が追加され、支援通貨（Ｃ３）には取引情報３２０（Ｔ１）、取引情報３２０（Ｔ２）が追加されている。支援通貨（Ｃ４）には取引情報３２０（Ｔ２）が追加され、支援通貨（Ｃ５）には取引情報３２０（Ｔ３）が追加されている。

　実際には、送信対象となる支援通貨はＦＩＦＯ（First in First out）方式で選ばれるため、図１３に示したような支援通貨の選び方がなされることはない。ユーザが保有する多数の支援通貨の中から送信対象となる支援通貨の選び方については、次の図１４に関連して説明する。

　図１４は、送信対象となる支援通貨の選び方を示す模式図である。
　ここでは、ユーザ（Ｐ８）がユーザ（Ｐ６）に支援通貨（Ｋ１＜小田原＞）を支払う取引（Ｔ５）、ユーザ（Ｐ６）がユーザ（Ｐ１）に支援通貨（Ｋ１）を支払う取引（Ｔ６）を対象として説明する。

　ユーザ（Ｐ８）は、ユーザ（Ｐ４）、ユーザ（Ｐ７）、ユーザ（Ｐ６）、などからもらった複数の支援通貨（Ｋ１）を保有している。図１４の上方が最近取得した支援通貨（Ｋ１）を示し、下方ほど古くに取得した支援通貨（Ｋ１）を示す。取引（Ｔ５）において、ユーザ（Ｐ８）が所定量の支援通貨（Ｋ１）をユーザ（Ｐ６）に支払うときには、通信端末１００（Ｐ８）の取引管理部１４６は、取得日時が古い方の支援通貨（Ｋ１）から所定量の支援通貨（Ｋ１）を選んで通信端末１００（Ｐ６）に送信する。すなわち、取引管理部１４６は、いわゆるＦＩＦＯ方式にて支援通貨（Ｋ１）を管理する。

　取引（Ｔ５）のあと、通信端末１００（Ｐ６）はユーザ（Ｐ８）から受け取った支援通貨（Ｋ１）を保有通貨として通貨格納部１４８に格納する。取引（Ｔ６）に際しては、通信端末１００（Ｐ６）の取引管理部１４６も、取得日時の古い方の支援通貨（Ｋ１）から送信対象を選ぶ。

　ＦＩＦＯ方式にて送信対象となる支援通貨（Ｋ１）を選ぶことにより、一部の支援通貨（Ｋ１）が特定ユーザの通貨格納部１４８に長期滞留しにくくなる。一部の支援通貨（Ｋ１）だけが取引対象となると、一部の支援通貨（Ｋ１）だけに大量の取引情報３２０が付与されてしまう。ＦＩＦＯ方式を採用することにより、多数の支援通貨（Ｋ１）に含まれる取引情報３２０の量、いいかえれば、各支援通貨（Ｋ１）のデータサイズを平準化しやすくなる。

　図１５は、支援通貨による取引過程を示すシーケンス図である。
　ここでは、取引（Ｔ１）において、ユーザ（Ｐ１）がユーザ（Ｐ５）に支援通貨を支払う場合を想定して説明する。まず、ユーザ（Ｐ１）は、支払画面１９８においてユーザ（Ｐ５）への支援通貨の送信（支払い）を指示する（Ｓ２０）。通信端末１００（Ｐ１）の取引管理部１４６は、送信対象となる支援通貨に取引情報３２０（Ｔ１）を追加する（Ｓ２２）。

　通信端末１００（Ｐ１）の送信部１４２は、支援通貨を通信端末１００（Ｐ５）に送信し、通信端末１００（Ｐ５）の受信部１４４は支援通貨を受信する（Ｓ２４）。上述したように、支援通貨は暗号化されて送信される。通信端末１００（Ｐ５）の取引管理部１４６は支援通貨を復号できれば、正規の支援通貨であると判定する。通信端末１００に搭載される支援ツールは、秘密の共通鍵を有している。この共通鍵により復号と暗号化が実行される。

　受信側の通信端末１００（Ｐ５）の出力部１４０は、支援通貨の真正性が確認できれば、入金通知を表示する（Ｓ２６）。なお、上述したように、支援通貨の送信と並行して、基本通貨の送金が実行されてもよい。

　通信端末１００（Ｐ１）の取引管理部１４６は、送信部１４２を介して、取引結果を示す取引情報３２０を運営サーバ１２０にも送信する（Ｓ２８）。同様にして、通信端末１００（Ｐ５）も、取引結果を示す取引情報３２０を運営サーバ１２０に送信する（Ｓ３０）。運営サーバ１２０の手数料徴収部１６０は、２つの取引情報３２０を照合し、支援通貨を受け取った側のユーザ（Ｐ５）について累計手数料情報２２０を更新する（Ｓ３２）。累計手数料情報２２０は、ユーザごとの未払いの手数料の累計額を記録したものである（後述）。

　なお、運営サーバ１２０において取引情報３２０の照合ができたとき、運営サーバ１２０の送信部１５６は、通信端末１００（Ｐ１）および通信端末１００（Ｐ５）の双方または一方に取引承認通知を送信してもよい。支援通貨を受け取った側である通信端末１００（Ｐ５）の取引管理部１４６は、取引承認通知が受信されたとき、Ｓ２４において受信した支援通貨の取引情報３２０に取引承認の旨を追加で記録してもよい。

　なお、運営サーバ１２０による取引承認は実行しないとしてもよい。この場合、通信端末１００（Ｐ１）または通信端末１００（Ｐ５）の一方のみが取引情報３２０を運営サーバ１２０に通知するとしてもよい。

　手数料は、取引で支払った支援通貨の所定割合として決められる。たとえば、手数料率が１（％）であって、取引で使用した支援通貨が１，０００（ｐｔ）であれば、運営サーバ１２０は取引額の１（％）に相当する１０（円）を手数料として徴収する。本実施形態においては、支援通貨を支払われた側から手数料を徴収するが、支払った側から徴収するとしてもよい。手数料は、取引が発生するごとに徴収されてもよいが、本実施形態においては１ヶ月に１回、月末にまとめて徴収されるものとする。

　図１６は、累計手数料情報２２０のデータ構造図である。
　累計手数料情報２２０は、運営サーバ１２０のデータ格納部１５４に格納される。累計手数料情報２２０は、ユーザごとの未決済の手数料累計額を示す。ユーザ間の取引が発生するごとに、手数料徴収部１６０は支援通貨の一部に相当する金額を手数料として累計手数料情報２２０に記録する。たとえば、ユーザ（Ｐ１）からユーザ（Ｐ５）に支援通貨が支払われたときには、手数料徴収部１６０はユーザ（Ｐ５）の手数料累計額に新たな取引にともなう手数料を加算する。

　手数料徴収部１６０は、決済システム１０４に指示して、月末に各ユーザの銀行口座から未払い分の手数料を引き落とす。手数料徴収部１６０は決済後、累計手数料情報２２０を更新する。累計手数料情報２２０には未収の手数料のみが記載される。

　たとえば、ユーザ（Ｐ１）の手数料累計額は５２０（円）なので、手数料徴収部１６０はユーザ（Ｐ１）の銀行口座から基本通貨（法定通貨）にて５２０（円）を月末に引き落とす。引き落としの完了後、累計手数料情報２２０におけるユーザ（Ｐ１）の手数料累計額、すなわち、未払い分は０（円）となる。
　手数料徴収部１６０は、累計手数料情報２２０を決済システム１０４と共有し、銀行残高が手数料累計額未満とならないようにインターネット１０２に指示してもよい。

　図１７は、手数料設定情報２３０のデータ構造図である。
　手数料設定情報２３０は、運営サーバ１２０のデータ格納部１５４に格納される。手数料設定情報２３０は、支援通貨（Ｋ１＜小田原＞）について、ユーザごとの取引累計額および手数料率を示す。運営サーバ１２０の集計部１６４は、取引が発生するごとに、支援通貨（Ｋ１）を使った側のユーザについて、取引累計額を更新する。図１７の手数料設定情報２３０によれば、ユーザ（Ｐ１）は、合計５，０１８（ｐｔ）の支援通貨（Ｋ１）を使用している。取引累計額は、あらかじめ指定された期間において送金された支援通貨の総額（ｐｔ）を示す。

　手数料徴収部１６０は、取引累計額に応じて手数料率を設定する。基本の手数料率は１．０（％）である。取引累計額が１０万（ｐｔ）を超えると、手数料徴収部１６０は手数料率を０．８（％）に低下させる。ユーザ（Ｐ２）の取引累計額は１２１，１８４（ｐｔ）なので、手数料徴収部１６０はユーザ（Ｐ２）の手数料率を０．８（％）に設定している。すなわち、ユーザ（Ｐ２）が他のユーザから支援通貨を受け取った場合には、ユーザ（Ｐ２）は受け取った支援通貨の０．８（％）に相当する基本通貨を運営会社に手数料として支払う。

　支援通貨を積極的に使うほど、支援通貨をもらったときの手数料を安くすることで、支援通貨の使用意欲を高めることができる。また、支援通貨が使われるときには基本通貨も同時に動くことが多いため、支援通貨の流通を活性化することで、基本通貨の流通を活性化させることができる。

　取引累計額が通信端末１００万（ｐｔ）を超えると、手数料徴収部１６０は手数料率を０．３（％）に変更する。取引累計額が１，０００万（ｐｔ）を超えると、手数料徴収部１６０は手数料率を０．１（％）に変更する。

　手数料徴収部１６０は、手数料率とユーザの属性情報に基づいて設定してもよい。たとえば、個人か事業者か、大企業か中小企業かに応じて手数料率を変更してもよい。手数料徴収部１６０は、性別、年齢、居住地、世帯年収等に応じて手数料率を設定してもよい。

　図１８は、手数料調整情報２４０のデータ構造図である。
　手数料調整情報２４０は、運営サーバ１２０のデータ格納部１５４に格納される。手数料調整情報２４０は、取引理由に応じた手数料の調整率を示す。手数料徴収部１６０は、特定の取引を促進するため、取引理由に応じて手数料を変化させる。通常の商品購入のときには、調整率は「×１．０」である。ユーザ（Ｐ１）の手数料率は１．０（％）なので（図１７参照）、ユーザ（Ｐ１）から他のユーザが通常の商品を購入したとき、ユーザ（Ｐ１）が支払うべき手数料について適用される手数料率は１．０（％）（＝１×１）である。

　多数の商品のうち、地方自治体は「エコ商品（環境配慮商品）」を指定してもよい。エコ商品の調整率は「×０．５」である。ユーザ（Ｐ１）から他のユーザがエコ商品を購入したとき、ユーザ（Ｐ１）に適用される手数料率は０．５（％）（＝１×０．５）となる。このような調整をすることで、ユーザ（Ｐ１）がエコ商品を販売する動機を強めることができる。

　カーボンクレジットの調整率は「×（－０．２）」である。ユーザ（Ｐ１）がカーボンクレジットの生産者であるとする。この場合、ユーザ（Ｐ１）から他のユーザがカーボンクレジットを購入したとき、ユーザ（Ｐ１）には手数料率として－０．２（％）（＝１×（－０．２）が適用される。すなわち、カーボンクレジットを販売するときには、運営会社はユーザ（Ｐ１）に基本通貨を支払う。

　図１９は、通貨流通情報２５０のデータ構造図である。
　通貨流通情報２５０は、運営サーバ１２０のデータ格納部１５４に格納される。通貨流通情報２５０は、支援通貨（Ｋ１＜小田原＞）の流通回数（取引回数）および合計の流通貢献度を示す。ユーザの交換要求（図１参照）により、運営会社は支援通貨を財市場（Goods Market）から回収する。集計部１６４は、回収された支援通貨の取引情報３２０を確認し、流通回数および流通貢献度を計算する。

　図１９の通貨流通情報２５０は、支援通貨（Ｋ１＜小田原＞）についてのデータを集計したものである。支援通貨（Ｋ１：Ｃ１）が運営会社により発行されてから、運営会社に回収されるまでに１５回の取引を経由している。いいかえれば、支援通貨（Ｋ１：Ｃ１）には１５個の取引情報３２０が付与されている。一方、支援通貨（Ｋ１：Ｃ３）の流通回数は９８回である。したがって、支援通貨（Ｋ１：Ｃ１）よりも支援通貨（Ｋ１：Ｃ３）の方が多くの取引に使用されていることがわかる。

　集計部１６４は、支援通貨１単位ごとに、流通貢献度の合計値を計算する。具体的には、集計部１６４は、支援通貨（Ｋ１：Ｃ１）に付属する複数の取引情報３２０に貢献度データ２１０として含まれる流通貢献度を合計し、その合計値を通貨流通情報２５０に記録する。支援通貨（Ｋ１：Ｃ１）の流通貢献度の合計値は「８１」である。支援通貨（Ｋ１：Ｃ１）は１（ｐｔ）分の流通により８１（円）分の基本通貨を流通させていることを意味する。いいかえれば、流通貢献度の合計値「８１」は、支援通貨（Ｋ１：Ｃ１）による経済効果の大きさを示す。

　図２０は、使用条件情報２６０のデータ構造図である。
　使用条件情報２６０は、運営サーバ１２０のデータ格納部１５４に格納される。使用条件情報２６０は、支援通貨の使用条件を示す。地方自治体は、支援通貨の発行に際して、運営会社に対して使用条件を設定する。

　支援通貨（Ｋ１）は、小田原市で使用可能に設定される。具体的には、小田原市に住民登録されているユーザ、本店または支店が小田原市に設定されている店舗において、支援通貨（Ｋ１＜小田原＞）は使用可能である。支援通貨（Ｋ１）の受け手が小田原市のユーザであることを条件として、支援通貨（Ｋ１）による取引が可能となる。小田原市は、姉妹都市である日光市と提携している。このため、支援通貨（Ｋ１＜小田原＞）は小田原市だけでなく日光市でも使用可能である。

　支援通貨（Ｋ１＜小田原＞）の使用可能な期間は「２０２２年１月１日」から「２０２２年１２月３１日」までの１年間である。したがって、２０２３年になると支援通貨（Ｋ１）は使用不可となる。２０２３年になっても支援通貨（Ｋ１）を保有していたユーザは、運営サーバ１２０に対して支援通貨と基本通貨の交換を要求する。運営サーバ１２０の通貨交換部１８０は、ユーザから支援通貨を受け取り、ユーザに基本通貨を支払う。あるいは、通貨交換部１８０は使用期間の終了後、市場に流通している支援通貨（Ｋ１）を無効化してもよい。無効化された支援通貨（Ｋ１）は、運営サーバ１２０において交換不可となる。

　日光市の支援通貨（Ｋ４＜日光＞）も小田原市で使用可能である。上述したように、支援通貨（Ｋ４＜日光＞）を小田原市で使用したとき、特典付与部１８２はユーザに特典を付与する。あるいは、支援通貨（Ｋ１＜小田原＞）を日光市で使用したときにも、特典付与部１８２はユーザに特典を付与する。

　地方自治体は、使用条件を任意に設定可能である。たとえば、支援通貨を使用可能な店舗、支援通貨により取引可能な商品、支援通貨を使用可能な曜日、など、使用方法を制約する使用条件が考えられる。このほか、支援通貨を使用した取引に際して流通貢献度が４倍以上となることを使用条件としてもよいし、雨の日だけ使用可能とするなど天候を使用条件として設定してもよい。あるいは、雨の日に使用すると特典を付与するなどの特典条件が設定されてもよい。

　図２１は、経済効果情報２７０のデータ構造図である。
　経済効果情報２７０は、運営サーバ１２０のデータ格納部１５４に格納される。経済効果情報２７０は、各種の支援通貨の経済効果を示す。支援通貨の使用期間が終了したあと、集計部１６４は通貨流通情報２５０を参照して、支援通貨の経済効果を計算する。

　支援通貨（Ｋ１＜小田原＞）は、５兆（ｐｔ）が発行されている。支援通貨（Ｋ１＜小田原＞）の流通回数は最低値が１（回）であり、最大値は７２０（回）、平均値は２６０（回）である。支援通貨（Ｋ１＜小田原＞）の流通貢献度の平均値が７１（回）であれば、支援通貨（Ｋ１）にともなう基本通貨の流通量は３５５兆（円）（＝５兆×７１）と算出できる。なお、平均値ではなく、中央値あるいは最頻値を流通回数分布の代表値として採用してもよい。

　使用条件情報２６０および経済効果情報２７０を参照することにより、支援通貨の使用条件と経済効果の関係を考察可能となる。たとえば、支援通貨（Ｋ１＜小田原＞）の経済効果が高いという結果が得られたときには、他の地域においても支援通貨（Ｋ１）の使用条件にて独自に支援通貨を発行することで同様の経済効果を期待できる。いいかえれば、小田原市の地方自治体の経験を、他地域でも活かすことができる。

＜総括＞
　以上、実施形態に基づいて支援通貨管理システム２００を説明した。
　ユーザは、地方自治体から無償で支援通貨をもらい、支援通貨を通常の基本通貨と同様に使用できる。支援通貨の原資は地方自治体が負担するため、ユーザは経済的な負担をすることなく支援通貨を手軽に使うことができる。そして、支援通貨にともなって基本通貨が動くことで、経済活動が活性化される。

　支援通貨にさまざまな使用条件あるいは特典条件をつけることで、支援通貨に個性や独自性をもたせることができる。たとえば、ある地域Ｚでの経済活性化を目的とする場合には、支援通貨の通用範囲を地域Ｚに限定してもよい。また、支援通貨に使用期間を設定し、期限後に支援通貨を無効化するとすれば、支援通貨を使えるうちに使おうという意識にユーザを導くことができるため、支援通貨の流通回数を促進しやすくなる。

　地域Ｚを訪問したユーザに支援通貨を配布することで、地域Ｚへの訪問意欲を喚起しやすくなる。地域Ｚへの訪問者は、支援通貨とともに基本通貨を地域Ｚで使うことが想定されるため、地域Ｚに外部からお金（基本通貨）を呼び込むことができる。

　支援通貨を、購買意欲が旺盛な若い世代あるいは子育て世代に限って無償配布するとしてもよいし、教育目的だけに使用可能な支援通貨を発行してもよい。このように、地方自治体は、政策目的に合わせて、支援通貨の配布先と使用条件について独自の工夫をこらすことができる。

　地方自治体は、運営会社に基本通貨（お金）を払い、支援通貨を発行してもらう。このため、支援通貨の原資は地方自治体が負担することになる。その一方、支援通貨を通して経済が活性化すれば、地方自治体は法人税あるいは消費税による税収増を期待できる。

　ユーザが通信端末１００に保有する支援通貨は、ＦＩＦＯ方式にて管理される。このため、一部の支援通貨だけが取引対象とならないように制御できる。

　支援通貨は、基本通貨と同様に流通するが、支援通貨には使用条件が設定される。使用条件により使用目的・使用方法を制限するほど、支援通貨は「通貨のようで通貨とはいえないもの」になる。このため、誰かに受けた親切や恩の対価として、正規の通貨である基本通貨を謝礼として支払うよりも、支援通貨を支払う方が、譲渡者と譲受者の双方において心理的抵抗感を抑制しやすくなる。特に、支援通貨はもともと無償配布されたものであるため、ユーザは支援通貨を親切の対価として気軽に支払いやすい。

　支援通貨には、取引が発生するごとに、取引情報３２０が追加される。支援通貨に付加された取引情報３２０を確認することで、支援通貨が、どのくらい使われたか、何に使われたか、どのくらいの経済効果を発揮したかを詳細に分析できる。

　たとえば、ある地方自治体が発行した支援通貨が経済効果を発揮したことがわかれば、同様の政策を他の地方自治体でも導入しやすくなる。また、ある地方自治体で発行した支援通貨の経済効果が低かったときでも、失敗の経験として共有することで、他の地方自治体が同じ失敗をするのを防ぐことができる。ある地方自治体で発行した支援通貨が経済効果を発揮したときには、国が同様の使用条件にて支援通貨を発行してもよい。支援通貨管理システム２００によれば、支援通貨による経済効果を計測できるため、合理的な経済政策を立案しやすくなる。

　運営会社は、取引が発生するごとに手数料を徴収する。この手数料が運営会社の運営資金となる。支援通貨を使えば使うほど手数料率を下げることで、支援通貨の使用意欲をいっそう喚起しやすくなる。手数料率が下がったとしても、支援通貨による取引の回数が増えれば運営会社は収益機会を充分に確保できる。

　手数料率を、取引を行うユーザの属性情報あるいは取引理由に応じて変化させることで、取引をある程度コントロールできる。たとえば、ＦＣＶ（Fuel Cell Vehicle）関連製品の購入時における手数料率を下げることで、ＦＣＶの普及を促進してもよい。

　さまざまな支援通貨を集める楽しみをユーザに提供できる。ユーザは日本全国、あるいは、世界各国の独自貨幣としての支援通貨を集めることで、支援通貨をコレクションしてもよい。支援通貨には、独自デザインの画像が設定されてもよい。支援通貨選択画面２０２において、デザインの異なる多様な支援通貨を並べて表示させることで、コレクションの楽しみを増すことができる。あるいは、支援通貨のコレクションを一覧表示する専用アプリケーション・ソフトウェアを提供してもよい。コレクション需要を喚起することにより、支援通貨の価値を高めることができる。

　なお、本発明は上記実施形態や変形例に限定されるものではなく、要旨を逸脱しない範囲で構成要素を変形して具体化することができる。上記実施形態や変形例に開示されている複数の構成要素を適宜組み合わせることにより種々の発明を形成してもよい。また、上記実施形態や変形例に示される全構成要素からいくつかの構成要素を削除してもよい。

　複数の通信端末１００、発行サーバ１１０および運営サーバ１２０を含むことにより支援通貨管理システム２００が構成されるとして説明したが、通信端末１００の機能の一部は発行サーバ１１０または運営サーバ１２０により実現されてもよいし、発行サーバ１１０または運営サーバ１２０の機能の一部が通信端末１００に割り当てられてもよい。また、通信端末１００、発行サーバ１１０あるいは運営サーバ１２０以外の第３の装置が、通信端末１００、発行サーバ１１０あるいは運営サーバ１２０の機能の一部を担ってもよい。通信端末１００、発行サーバ１１０および運営サーバ１２０の各機能の集合体は大局的には１つの「情報処理装置」として把握することも可能である。１つまたは複数のハードウェアに対して、本発明を実現するために必要な複数の機能をどのように配分するかは、各ハードウェアの処理能力や支援通貨管理システム２００に求められる仕様等に鑑みて決定されればよい。

＜変形例＞
　本実施形態においては、通信端末１００に対して、通信機能を有するＤＩエンジン（支援ツール）を搭載するとして説明した。ＤＩエンジンは、ＩＣチップとアプリケーション・ソフトウェアにより実現されてもよいし、アプリケーション・ソフトウェアのみにより実現されてもよいし、ＩＣチップなどの専用の電子回路のみにより実現されてもよい。

　図２２は、変形例として、商品購入の御礼として支援通貨を配布するときの処理過程を示すシーケンス図である。
　ユーザが、ある店舗で商品を購入したとき、その御礼として購入者に支援通貨を付与してもよい。図２２に示す変形例においては、地方自治体が運営会社に基本通貨を支払うことで支援通貨を発行してもらう。運営会社は基本通貨を管理し、地方自治体は支援通貨を管理するものとする。

　まず、個人であるユーザ（Ｐ１１）は、店舗であるユーザ（Ｐ１０）から商品を購入したとする。ユーザ（Ｐ１０）は、地方自治体から指定された「特定店舗」であるとする。特定店舗の選び方は任意であるが、たとえば、地方自治体が支援したい地元の小規模商店などが考えられる。ユーザ（Ｐ１１）は、基本通貨（現金）により、商品代金をユーザ（Ｐ１０：特定店舗）に支払う（Ｓ４０）。ユーザ（Ｐ１０）は、基本通貨による商品購入があった旨を地方自治体（発行サーバ１１０）に報告する（Ｓ４２）。具体的には、通信端末１００（Ｐ１０）の取引管理部１４６は、購入者のユーザＩＤ＝Ｐ１１と販売者のユーザＩＤ＝Ｐ１０、商品の購入代金を発行サーバ１１０に通知する。

　発行サーバ１１０の配布部１０８または特典付与部１８２は、販売者のユーザＩＤが特定店舗のユーザＩＤであるかを確認した上で、購入代金の一部、たとえば、０．５（％）に相当する支援通貨をユーザ（Ｐ１１：購入者）に送信する（Ｓ４４）。このとき、運営会社は支援通貨の一部について手数料を徴収してもよい。

　このような制御方法によれば、特定店舗で商品を購入したユーザは支援通貨をもらうことができるので、特定店舗での購買行動を促すことができる。地方自治体は、支援通貨を通して、特定店舗を支援できる。また、特定店舗で買い物をしたユーザに支援通貨を配布することで、支援通貨を地域に少しずつ流通させることができる。

　特定店舗に限らず、特定商品を対象として、支援通貨を配布してもよい。たとえば、ＥＶ（Electric Vehicle）などの特定商品が購入されたとき、発行サーバ１１０は購入者に支援通貨を配布してもよい。あるいは、粗大ごみのリサイクル料が支払われたとき、発行サーバ１１０は支払者に支援通貨を配布することで、リサイクルを促進することも考えられる。

　図２３は、変形例として、支援通貨の有償購入するときの処理過程を示すシーケンス図である。
　本実施形態においては、地方自治体が運営会社から支援通貨を有償発行してもらった上で、支援通貨をユーザに無償配布する場合を想定して説明した。変形例として、ユーザは地方自治体から支援通貨を基本通貨により購入してもよい。図２３に示す変形例においても、地方自治体が運営会社に基本通貨を支払うことで支援通貨を発行してもらう。運営会社は基本通貨を管理し、地方自治体は支援通貨を管理するものとする。また、ユーザ（Ｐ１２）からユーザ（Ｐ１５）に対して支援通貨が支払われる場合を想定し、運営サーバ１２０だけでなく発行サーバ１１０も通貨交換部（不図示）を備えるとする。

　まず、地方自治体（発行サーバ１１０）は、運営会社（運営サーバ１２０）に対して支援通貨の発行を依頼する（Ｓ５０）。運営サーバ１２０は、支援通貨に見合った基本通貨（現金）を地方自治体から預かった上で、支援通貨を発行する（Ｓ５２）。地方自治体は、支援通貨を発行預託通貨として保有しておく。

　ここで、ユーザ（Ｐ１２）は、支援通貨を購入したいとする。ユーザ（Ｐ１２）は発行サーバ１１０に対して支援通貨の購入を要求する。このとき、ユーザ（Ｐ１２）は発行サーバ１１０に基本通貨（現金）を支払う（Ｓ５４）。発行サーバ１１０の通貨交換部は、支援通貨を通信端末１００（Ｐ１２）に送信する（Ｓ５６）。基本通貨と支援通貨は等価交換されてもよいし、ユーザ（Ｐ１２）に有利な換金率にて交換してもよい。たとえば、ユーザは８万（円）を支払うことで１０万（ｐｔ）の支援通貨を購入できてもよい。発行サーバ１１０の通貨交換部は、決済システム１０４に指示して、ユーザ（Ｐ１２）の銀行口座から支援通貨の対価を基本通貨として引き落とす。

　次に、ユーザ（Ｐ１２）とユーザ（Ｐ１５）の間に取引が発生し、ユーザ（Ｐ１２）からユーザ（Ｐ１５）に支援通貨が支払われる（Ｓ５８）。ユーザ（Ｐ１２）は受け取った支援通貨と基本通貨との交換を運営サーバ１２０に要求できる。通信端末１００（Ｐ１２）は、支援通貨を含む交換要求を運営サーバ１２０に送信する（Ｓ１２０）。運営サーバ１２０の通貨交換部１８０は、支援通貨を基本通貨と交換する。このとき、１（ｐｔ）の支援通貨は、１（円）の基本通貨と交換される。通貨交換部１８０は、通信端末１００（Ｐ１５）に対して基本通貨を提供する（Ｓ６２）。基本通貨は電子マネーとして支払われてもよいし、決済システム１０４を介してユーザ（Ｐ１５）の銀行口座に振り込まれてもよい。

　図２４は、変形例として、ウェブサイトへのアクセスにともなって支援通貨を流通させる方法の概念図である。
　ユーザは、通信端末１００から課金サーバ２８０を通してウェブサイト２８２ａ、２８２ｂ等にアクセスする。課金サーバ２８０は、アクセス発生時において、アクセス情報を運営サーバ１２０に通知する。アクセス情報には、アクセスをしたユーザのユーザＩＤ、ウェブサイト２８２ａの運営者のユーザＩＤ、ウェブサイト２８２ａのＵＲＩ（Uniform Resource Identifier）などが含まれる。運営サーバ１２０においては、ウェブサイト２８２ａへアクセスしたユーザに対して、ウェブサイト２８２ａのサイト運営者が支援通貨を支払うという支払条件が設定されている。

　サイト運営者（ウェブサイト２８２ａ）は、ウェブサイト２８２ａへの訪問者に支援通貨を支払うことで、ウェブサイト２８２ａへのアクセス数を伸ばすことができる。１回目のアクセスに限って支援通貨を支払う、あるいは、所定期間内のアクセスに限って支援通貨を支払うなどの支払条件が設定されてもよい。

　課金サーバ２８０は、ウェブサイト２８２ａへのアクセスが発生したとき、アクセス情報を運営サーバ１２０に送信する。運営サーバ１２０の決済管理部１６２は、ウェブサイト２８２ａの支払条件を参照し、決済管理部１６２はサイト運営者の通信端末１００にユーザのアドレスを通知し、支援通貨を訪問したユーザの通信端末１００に送信するように指示する。

　一方、ユーザがウェブサイト２８２ｂにアクセスしたときには、ユーザがウェブサイト２８２ｂのサイト運営者に支援通貨を支払う。たとえば、ウェブサイト２８２ｂは、有償の動画コンテンツを提供し、ユーザは視聴対価としてサイト運営者に支援通貨を支払う。課金サーバ２８０は、ウェブサイト２８２ｂへのアクセスが発生したとき、アクセスをしたユーザのユーザＩＤと、ウェブサイト運営者のユーザＩＤなどを運営サーバ１２０に通知する。運営サーバ１２０には、ウェブサイト２８２ｂの支払条件を参照し、ユーザからサイト運営者に支援通貨を送信させる。

　このほか、インターネット広告の広告主が、広告を見てくれたユーザに対して支援通貨を支払ってもよい。あるいは、ユーザはあらかじめ支援通貨をサイト運営者に送信し、サイト運営者は支援通貨の受信を確認した上で、このユーザにウェブページを送信してもよい。運営サーバ１２０は、ウェブページの視聴にともなって支援通貨の支払いが発生したとき、手数料を徴収する。

　図２５は、変形例における取引履歴情報２９０のデータ構造図である。
　本実施形態においては、支援通貨に取引情報３２０が付属し、支援通貨とともに取引情報３２０も通信端末１００間で送受信されるとして説明した。変形例として、運営サーバ１２０において取引情報３２０を管理するとしてもよい。取引履歴情報２９０は、運営サーバ１２０のデータ格納部１５４に格納される。図２５の取引履歴情報２９０は、支援通貨（Ｋ１＜小田原＞）についての取引結果を示す。

　通信端末１００（Ｐ１）が取引（Ｔ１）において支援通貨（Ｋ１：Ｃ１５）、支援通貨（Ｋ１：Ｃ１６）を通信端末１００（Ｐ２）に送信したとき、通信端末１００（Ｐ１）は取引ＩＤ＝Ｔ１と通貨ＩＤ、取引情報３２０を運営サーバ１２０に送信する。また、通信端末１００（Ｐ２）も同様の情報を運営サーバ１２０に送信する。運営サーバ１２０の取引登録部（不図示）は、取引履歴情報２９０を更新し、支援通貨（Ｋ１：Ｃ１５）と支援通貨（Ｋ１：Ｃ１６）について取引ＩＤ＝Ｔ１を記録する。また、取引登録部は、取引ＩＤとともに取引情報３２０をデータ格納部１５４に記録する。この変形例においては、通信端末１００（Ｐ１）から通信端末１００（Ｐ２）には、支援通貨のデータのみが送信され、取引情報３２０は送信対象とはならない。

　通信端末１００（Ｐ２）が取引（Ｔ２）において支援通貨（Ｋ１：Ｃ１５）を通信端末１００（Ｐ３）に送信したとき、通信端末１００（Ｐ２）と通信端末１００（Ｐ３）は、取引ＩＤ＝Ｔ２と通貨ＩＤ＝Ｃ１５および取引情報３２０を運営サーバ１２０に送信する。運営サーバ１２０の取引登録部は、支援通貨（Ｋ１：Ｃ１５）について取引ＩＤ＝Ｔ２を記録するとともに、取引情報３２０（Ｔ２）をデータ格納部１５４に記録する。

　このような制御方法によれば、取引が発生するごとに運営サーバ１２０が取引結果を取引履歴情報２９０に記録するため、運営サーバ１２０は取引履歴情報２９０を参照することで支援通貨の流通状況をリアルタイムにて把握できる。

　地方公共団体から地域内の店舗に平等に支援通貨を無償配布したとしても、店舗の売上に応じて各店舗における支援通貨の保有量に偏りが生じることも考えられる。たとえば、店舗Ｑ１が１万（ｐｔ）の支援通貨を保有し、店舗Ｑ２は１５万（ｐｔ）の支援通貨を保有しているとする。このとき、店舗Ｑ１は店舗Ｑ２から支援通貨を購入できてもよい。具体的には、店舗Ｑ１は運営サーバ１２０に対して、１（ｐｔ）の支援通貨を１．２（円）で５万（ｐｔ）だけ買い取りたい旨を示す購入要求を運営サーバ１２０に送信する。通貨交換部１８０は、店舗Ｑ２に対して店舗Ｑ１の希望を伝える。店舗Ｑ２が同意したときには、通貨交換部１８０は店舗Ｑ２から５万（ｐｔ）の支援通貨を買い取り、店舗Ｑ１に買い取った支援通貨を販売する。このような制御方法によれば、店舗間での支援通貨の偏りを適宜調整可能となる。

　基本通貨と支援通貨の交換率は固定であってもよいし、変動制であってもよい。支援通貨のニーズが高まれば、支援通貨の価値が高まる。逆に、使用条件による制約性ゆえに支援通貨よりも基本通貨が選好される場合には、支援通貨の価値は相対的に低下すると考えられる。運営サーバ１２０の通貨交換部１８０は、支援通貨の流通回数、流通貢献度を変数とする所定の計算式に基づいて、支援通貨の交換率を変動させてもよい。

　運営サーバ１２０は、支援通貨から基本通貨への交換を要求する第１の交換要求と、基本通貨から支援通貨への交換を要求する第２の交換要求を受信し、２つの交換要求をマッチングさせることで、支援通貨と基本通貨を交換してもよい。このとき、運営サーバ１２０の通貨交換部１８０は交換率を提示し、第１の交換要求と第２の交換要求のどちらが強いかに応じて交換率を変動させてもよい。また、発行部１６６が地方自治体からの要求に応じて支援通貨を追加発行するときには、そのときの交換率に応じて支援通貨の発行額を決めてもよい。

　本実施形態における支援通貨は、特定地域のみで通用する地域通貨であるとして説明した。支援通貨は、日本政府が発行主体となる日本全国で通用する通貨であってもよい。あるいは、支援通貨は、複数の国で使用可能な通貨であってもよい。

　支援通貨の取引にともなう手数料は、基本通貨で支払われてもよいし、支援通貨で支払われてもよい。たとえば、ユーザ（Ｐ１）からユーザ（Ｐ２）に５００（ｐｔ）の支援通貨が支払われるとき、運営サーバ１２０はユーザ（Ｐ２）から５（ｐｔ）の支援通貨を徴収してもよい。より具体的には、ユーザ（Ｐ１）からユーザ（Ｐ２）に支援通貨が送信されたとき、通信端末１００（Ｐ２）の取引管理部１４６は、その１（％）にあたる５（ｐｔ）の支援通貨を運営サーバ１２０に送信するように送信部１４２に指示する。このような制御方法によれば、運営会社は支援通貨を発行したあと、手数料として少しずつ支援通貨を財市場から回収できる。

　支援通貨を多く使うユーザは、経済活動に大きく貢献しているといえる。また、支援通貨の使用にともなって基本通貨も多く使うユーザは、消費税を多く支払うことになる。そこで、このようなユーザに対しては、地方自治体は住民税を減額するなど税金面での優遇措置を提供してもよい。

　本実施形態においては、手数料徴収部１６０は、支援通貨を受け取った側のユーザから手数料を徴収するとして説明した。手数料徴収部１６０は、支援通貨を支払う側から手数料を徴収してもよいし、譲渡側と譲受側の双方のユーザから手数料を徴収してもよい。

　支援通貨には、たとえば、１００（ｐｔ）あたり１（ｐｔ）の割合で、特定支援通貨が含まれてもよい。ユーザは、特定支援通貨を発行サーバ１１０に送信すると、発行サーバ１１０の特典付与部１８２は特典をユーザに付与するとしてもよい。このような制御方法によれば、支援通貨を受け取るときに特定支援通貨が含まれていることを期待する楽しみを提供できる。また、ユーザは、他のユーザへの御礼のときに特定支援通貨を提供することで感謝の気持ちを表してもよい。

　本実施形態においては、第１の地域（日光市）を使用可能領域とする支援通貨が、第２の領域（小田原市）で使用されたとき、特典条件が成立し、支援通貨を使用したユーザに特典が付与されるとして説明した。変形例として、支援通貨を使用したユーザだけでなく、使用されたユーザにも特典が付与されてもよい。あるいは、支援通貨（Ｋ４＜日光＞）が小田原市で使用されたときには、支援通貨（Ｋ４）を受け取ったユーザに対して特典が付与されてもよい。

　地方自治体は、ボランティア活動をする団体に支援通貨を無償配布してもよい。この団体は、公園清掃などのボランティア活動への参加者に対して、支援通貨を配布してもよい。このように、親切や社会貢献活動など、本来、お金の対象とならなかった価値に対して、支援通貨により報いやすくなる。

　手数料徴収部１６０は、支援通貨の取引が発生したときではなく、定期的に手数料を徴収するとしてもよい。たとえば、手数料徴収部１６０は、ユーザが保有する支援通貨の０．１（％）を１週間に１回の頻度にて手数料として徴収してもよい。このような制御方法によれば、支援通貨は時間経過とともに減っていくため、ユーザは支援通貨を積極的に使うように誘導できる。

　所定期間において、支援通貨を所定量以上使用したユーザに対して、発行部１６６または特典付与部１８２は支援通貨を無償配布してもよい。このような制御方法によっても、支援通貨の使用を促すことができる。一般的には、自動車や飛行機で移動するよりも電車で移動する方が、環境負荷が低いといわれる。発行部１６６は、電車移動をしたユーザに対して支援通貨を無償配布することで、環境配慮行動を促してもよい。このように、手数料率の調整、あるいは、特定行動に対する支援通貨の配布により、政策目的に沿った行動を多くのユーザに促すことが可能となる。

　地方自治体（発行サーバ１１０）ではなく、運営会社（運営サーバ１２０）が支援通貨を通信端末１００に直接配布してもよい。一例として、発行サーバ１１０が１００億（ｐｔ）の支援通貨を、５０，０００人のユーザに対して、２００，０００（ｐｔ）ずつ配布するように運営サーバ１２０に発行依頼を出したとする。このとき、発行サーバ１１０の送信部１７６は、配布対象者の通信端末１００のアドレスを運営サーバ１２０に通知する。運営サーバ１２０の発行部１６６は、指定された５０，０００人のユーザの通信端末１００それぞれに対して、２００，０００（ｐｔ）の支援通貨を発行してもよい。

　通信端末１００のアドレスとは、メールアドレスなどの既知のアドレスでもよいし、通信端末１００に搭載される支援ツール（ＤＩエンジン）が独自に有するアドレスであってもよい。

　通信端末１００のデータ処理部１３４は、提案部（不図示）および売上管理部（不図示）を備えてもよい。たとえば、通信端末１００がＰＯＳ端末であるとする。ユーザ（Ｐ２０）（店舗）は、第１の検証期間としての２０２２年１１月２３日において、商品Ｍを購入してくれたユーザに対して、支援通貨を購入特典として提供したとする。売上管理部は、購入特典として支援通貨を支払ったときの、「購入日：商品名：売上額」を対応づけて記録しておく。ここでいう「売上額」とは店舗の「２０２２年１１月２３日」における１日の総売上高を意味する。

　売上管理部は、更に、購入日「２０２２年１１月２３日」についての関連情報（期間属性情報）をウェブサイトから検索する。たとえば、この購入日について「最低気温が５度以下」「降雪あり」「晩秋」「祝日」「火曜日」などの関連情報が検索できたとする。また、商品Ｍにも「保温商品」「食品」「菓子」などの関連情報（商品属性情報）があらかじめ対応づけられている。購入日（第１の検証期間）において売上額が大きかった場合、たとえば、平均売上額よりも２０（％）以上の売上額であった場合には、商品Ｍに支援通貨による購入特典を提供することが原因かもしれない。

　売上管理部は、購入特典を提供した日において、売上額が閾値以上、たとえば、平均売上額の２０（％）以上である日を「検証日」として登録する。検証日においては、たとえば、「最低気温が５度以下であるとき、保温商品に購入特典をつけたことが、売上増加につながった」「降雪のある日において、食品に購入特典をつけたことが、売上増加につながった」「祝日において、保温商品に購入特典をつけたことが、売上増加につながった」などの仮説を設定できる。

　提案部は、検証日における購入日についての関連情報と、商品についての関連情報の組み合わせが成立する日があれば、ユーザ（Ｐ２０）に対して購入特典の設定を提案する。たとえば、第２の検証期間としての２０２２年１２月２１日に降雪があったとき、提案部は「お菓子に購入特典をつけると売上が上がるかもしれません」「保温商品に購入特典をつけると売上が上がるかもしれません」といった情報を、出力部１４０を介して表示させる。

　以上のような制御方法によれば、ユーザ（Ｐ２０）は、自分のお店の売上を上げるためにたまたま見つけた有効な購入特典の付与方法を別の日においても再現しやすくなる。このため、支援通貨管理システム２００に参加することで、ユーザ（Ｐ２０）は通信端末１００により経営支援サービスを受けることができる。

　以上、実施形態および変形例の記載から下記の発明が把握される。
Ａ１．発行システムから、運営システムに対して基本通貨を送信するステップと、
　前記運営システムが、前記発行システムから受信した基本通貨を運営預託通貨として保存するステップと、
　前記運営システムが、前記運営預託通貨に対応する支援通貨を前記発行システムに送信するステップと、
　前記発行システムが、前記運営システムから受信した支援通貨を発行預託通貨として保存するステップと、
　第１の経済主体の通信端末が、前記発行システムに対して基本通貨を送信するステップと、
　前記発行システムが、前記第１の経済主体の通信端末から受信した基本通貨に対応する支援通貨を前記発行預託通貨から減算し、前記減算された支援通貨を前記第１の経済主体に移転するステップと、
　前記第１の経済主体および第２の経済主体の取引にともなって、前記第１の経済主体から前記第２の経済主体に支援通貨を移転するステップと、
　前記第２の経済主体の通信端末が、前記運営システムに対して前記第１の経済主体から移転された支援通貨を送信するステップと、
　前記運営システムが、前記第２の経済主体の通信端末から受信した支援通貨に対応する基本通貨を前記運営預託通貨から減算し、前記減算された基本通貨を前記第２の経済主体に移転するステップと、を実行する支援通貨管理方法。

Claims

　第１の経済主体および第２の経済主体の取引にともなって、前記第１の経済主体から前記第２の経済主体に支援通貨が移転されるとき、前記第１の経済主体および前記第２の経済主体の取引に関する取引情報を前記取引の対象となった支援通貨に対応づけて記録する取引管理部、を備え、
　前記取引管理部は、支援通貨が介在する取引が発生するごとに、支援通貨に取引情報を追加する、支援通貨管理システム。
　支援通貨は、一単位ごとに通貨ＩＤにより識別され、
　前記取引管理部は、複数の支援通貨が第１の取引に利用されたときには、前記複数の支援通貨を示す通貨ＩＤそれぞれに対して前記第１の取引に関する第１の取引情報を追加し、
　前記第１の取引に利用された複数の支援通貨の一部の支援通貨が、前記第１の取引のあとに第２の取引に利用されたときには、前記一部の支援通貨の通貨ＩＤに対して、前記第１の取引情報に加えて前記第２の取引に関する第２の取引情報を更に追加する、請求項１に記載の支援通貨管理システム。
　支援通貨の取引情報を集計する集計部、を更に備え、
　前記集計部は、支援通貨ごとの取引回数を計算する、請求項２に記載の支援通貨管理システム。
　前記第１の経済主体と前記第２の経済主体の取引にともなって、前記第１の経済主体から前記第２の経済主体に支援通貨が移転されるとき、前記第１の経済主体および前記第２の経済主体の双方または一方から、手数料を徴収する手数料徴収部、を更に備える請求項１に記載の支援通貨管理システム。
　前記手数料徴収部は、取引対象となった支援通貨の取引状況に応じて、手数料を変化させる、請求項４に記載の支援通貨管理システム。
　前記取引管理部は、支援通貨の取引情報に取引が発生した理由を登録し、
　前記手数料徴収部は、取引が発生した理由に応じて、手数料を変化させる、請求項５に記載の支援通貨管理システム。
　前記取引管理部は、前記第１の経済主体と前記第２の経済主体の取引にともなって、前記第１の経済主体から前記第２の経済主体に支援通貨とともに基本通貨が移転されるとき、支援通貨の取引情報に対して、基本通貨と支援通貨の使用割合を示す流通貢献度を登録する、請求項１に記載の支援通貨管理システム。
　支援通貨の取引情報を集計する集計部、を更に備え、
　前記集計部は、支援通貨ごとの流通貢献度を計算することにより、支援通貨による経済効果を算出する、請求項７に記載の支援通貨管理システム。
　支援通貨を発行する発行部、を更に備え、
　前記発行部は、発行対象となる支援通貨に対して使用条件を対応づけて登録し、
　前記取引管理部は、前記第１の経済主体および前記第２の経済主体の取引が支援通貨の使用条件に適合することを条件として、前記第１の経済主体から前記第２の経済主体への支援通貨の移転を許可する、請求項１に記載の支援通貨管理システム。
　使用条件として第１の地域を使用可能地域として設定された支援通貨が、前記第１の地域にあらかじめ対応づけられる第２の地域において使用されたとき、前記第１の経済主体および前記第２の経済主体の双方または一方に特典を付与する特典付与部、を更に備える請求項９に記載の支援通貨管理システム。
　支援通貨の取引情報を集計する集計部、を更に備え、
　前記集計部は、経済主体ごとの支援通貨の使用量を計算する、請求項２に記載の支援通貨管理システム。
　前記第１の経済主体と前記第２の経済主体の取引にともなって、前記第１の経済主体から前記第２の経済主体に支援通貨が移転されるとき、前記第１の経済主体および前記第２の経済主体の双方または一方から、手数料を徴収する手数料徴収部、を更に備え、
　前記手数料徴収部は、前記第１の経済主体および前記第２の経済主体の双方または一方の支援通貨の使用量に応じて、手数料を変化させる請求項１１に記載の支援通貨管理システム。
　第３の経済主体から基本通貨による支援通貨の購入要求を受け付けたとき、前記第３の経済主体に有利な交換率にて支援通貨を発行する通貨交換部、を更に備える請求項１に記載の支援通貨管理システム。
　第４の経済主体および第５の経済主体の取引にともなって、前記第４の経済主体から前記第５の経済主体に基本通貨が移転されるとき、前記第４の経済主体に対して支援通貨を付与する特典付与部、を更に備える請求項１に記載の支援通貨管理システム。
　店舗における所定の検証期間の売上高を管理する売上管理部と、
　商品の購入時における支援通貨の支給を、前記商品を販売する経済主体に対して提案する提案部と、を更に備え、
　売上管理部は、第１の検証期間に対応づけられる期間属性情報と、前記第１の検証期間において支援通貨の支給対象となった商品に対応づけられる商品属性情報と、前記第１の検証期間における売上高を対応づけて記録し、
　前記提案部は、前記第１の検証期間における売上高が所定の閾値以上であるときには、前記第１の検証期間に対応づけられる期間属性情報を有する将来の第２の検証期間において、前記商品属性情報を有する商品に対して支援通貨の支給を提案する、請求項１に記載の支援通貨管理システム。
　一単位ごとに通貨ＩＤにより識別される支援通貨に対して、支援通貨による取引に関する取引情報を対応づけて記録する取引管理部と、
　取引相手の通信端末に対して、通貨ＩＤおよび取引情報を含む支援通貨を送信する送信部と、を備える通信端末。
　他の通信端末から受信した支援通貨を受信順に基づいて保存する通貨格納部、を更に備え、
　前記送信部は、取引相手の通信端末に対して、受信日時の古い支援通貨から優先的に送信する請求項１６に記載の通信端末。
　支援通貨を保存する通貨格納部と、
　ユーザから、取引にともなう支払額に対する基本通貨および支援通貨の割合の指定を受け付ける入力部と、を更に備え、
　前記送信部は、取引相手の通信端末に対して、指定された割合にて基本通貨および支援通貨を送信する、請求項１６に記載の通信端末。