JP2019128932A - 情報処理装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】仮想通貨を活用して、ユーザの経済活動を支援することができる情報処理装置等を提供する。【解決手段】情報処理装置１は、ユーザが所定の支出先に対して支出した金額を示す支出情報を取得する支出情報取得部と、複数のノードに分散して管理される仮想通貨の取引データを参照して、前記ユーザが前記支出先に対応する前記仮想通貨を保有しているか否かを判定する判定部と、前記仮想通貨を保有していると判定した場合、前記支出した金額に応じた数量の前記仮想通貨を前記ユーザに付与する付与部とを備えることを特徴とする。【選択図】図１

Description

本発明は、情報処理装置、情報処理方法及びプログラムに関する。

近年、ブロックチェーンに代表される分散型台帳技術を背景とした仮想通貨への関心が高まっており、仮想通貨を活用した様々なサービス手法が提案されている。例えば特許文献１では、実店舗で商品を購入する場合に、仮想通貨による決済を受け付け、購入された商品をユーザの自宅まで配送するよう配送者に通知する情報処理装置等が開示されている。

特開２０１７−４９９６７号公報

しかしながら、特許文献１に係る発明は仮想通貨により購入された商品をユーザ宛に配送するのみで、購入された商品等に応じたインセンティブを仮想通貨により与えるに至っていない。

一つの側面では、仮想通貨を活用して、ユーザの経済活動を支援することができる情報処理装置等を提供することを目的とする。

一つの側面では、情報処理装置は、ユーザが所定の支出先に対して支出した金額を示す支出情報を取得する支出情報取得部と、複数のノードに分散して管理される仮想通貨の取引データを参照して、前記ユーザが前記支出先に対応する前記仮想通貨を保有しているか否かを判定する判定部と、前記仮想通貨を保有していると判定した場合、前記支出した金額に応じた数量の前記仮想通貨を前記ユーザに付与する付与部とを備えることを特徴とする。

一つの側面では、仮想通貨を活用して、ユーザの経済活動を支援することができる。

仮想通貨取引システムの構成例を示す模式図である。 サーバ及び端末の構成例を示すブロック図である。 ユーザＤＢ及び商品ＤＢのレコードレイアウトの一例を示す説明図である。 実施の形態１の概要を示す説明図である。 トークンバック処理を説明するための説明図である。 端末に表示されるアプリケーション画面の一例を示す説明図である。 トークン算出処理の処理手順の一例を示すフローチャートである。 トークン付与処理の処理手順の一例を示すフローチャートである。 複数の仮想通貨取引システムが構築される様子を概念的に示す説明図である。 実施の形態２の概要を示す説明図である。 端末における画面遷移を説明するための説明図である。 実施の形態２に係るトークン付与処理の一例を示すフローチャートである。

以下、本発明をその実施の形態を示す図面に基づいて詳述する。
（実施の形態１）
図１は、仮想通貨取引システムの構成例を示す模式図である。本実施の形態では、ユーザによる商品等の購買行動を促進するべく、商品等の購入額（支出金額）の一部を原資に、当該ユーザに仮想通貨を付与する仮想通貨取引システムについて説明する。仮想通貨取引システムは、情報処理装置１、１、１…、端末装置２、２、２…、発行サーバ３、及び取引所サーバ４を含む。各装置は、インターネット等のネットワークＮを介して相互に通信接続されている。

情報処理装置１は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバ装置、パーソナルコンピュータ等である。本実施の形態で情報処理装置１はサーバ装置であるものとし、以下では簡潔のためサーバ１と読み替える。各サーバ１は、各々が独自に仮想通貨（トークン）を発行する各種団体のサーバ装置である。トークンの発行主体となる団体は、例えば企業、地方自治体、国、金融機関等が考えられるが、これらに限定されるものではない。本実施の形態では主に、ユーザに商品又はサービス（以下、商品等と言う）を提供する民間企業がトークンの発行主体であるものとして説明する。

サーバ１は、自社が発行したトークンを保有するユーザが自社の商品等を購入した場合、当該商品等の購入額を示す購入情報（支出情報）を収集し、商品等を購入した特典として、購入額に応じたトークンをキャッシュバックとしてユーザに付与するトークンバックサービスを提供する。サーバ１は、各企業が提供する本サービスのオペレータとして機能する。詳しくは後述するように、サーバ１は、商品等の購入額の一部を原資に、トークンの発行元（発行サーバ３）から、又はトークン保有者からトークンを購入するトランザクションを実行して、キャッシュバックとしてユーザに与えるトークンを調達する。サーバ１は、購入額の一部を用いて調達したトークンをユーザに付与する。

端末装置２は、ユーザが所有する情報処理端末であり、例えばスマートフォン、パーソナルコンピュータ、タブレット端末等である。以下では簡潔のため、端末装置２を端末２と読み替える。端末２には、例えば仮想通貨のウォレットとして機能するアプリケーションプログラムがインストールされている。ユーザは当該ウォレットにより仮想通貨を保有する。

なお、ユーザの端末２にウォレットとして機能するアプリケーションプログラムをインストールしてローカル端末で仮想通貨（トークン）を管理する形態だけでなく、仮想通貨の取引所（取引所サーバ４）等がＷｅｂ上で提供するオンライン口座にてユーザが保有する仮想通貨を管理する形態も、本実施の形態の範疇に含まれる。すなわち、仮想通貨の管理を行う装置はローカル端末に限定されず、クラウド上のサーバ装置であってもよい。

発行サーバ３は、トークンを発行する発行元として機能するサーバ装置であり、サーバ１、端末２等から入金を受け付けて、入金額に応じたトークンを送信（送金）する。サーバ１は、発行サーバ３から購入したトークンをユーザに付与する。

なお、図１では発行サーバ３を一つしか図示していないが、上述の如く各企業が自社トークンを発行するため、各企業がサーバ１と同様に自らの発行サーバ３を用意し、各々の発行サーバ３がトークンを発行してもよい。この場合、サーバ１及び発行サーバ３がそれぞれ行う処理（トークンバック及びトークン発行）は、一の装置で実現されてもよい。

あるいは、各企業にトークンバックサービスを実現するためのインフラ環境を与える一種のプラットフォームとして本システムを規定する場合、一の発行サーバ３が、各企業に応じ銘柄（種類）が異なる別々のトークンをまとめて発行するようにしてもよい。

取引所サーバ４は、仮想通貨の取引所として機能するサーバ装置であり、ユーザ同士の仮想通貨の取引を仲介する。取引所サーバ４は、本システムで各企業が発行するトークンを取り扱い、トークンの購入申込と売却申込とをマッチングさせて取引を約定させる。

なお、取引所サーバ４を仮想通貨の販売所、両替所等として機能させてもよいことは勿論である。また、サーバ１は外部の取引所等を介さず、自らが取引所、販売所等として機能してもよい。

図２は、サーバ１及び端末２の構成例を示すブロック図である。サーバ１は、制御部１１、主記憶部１２、通信部１３、及び補助記憶部１４を備える。
制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有し、補助記憶部１４に記憶されたプログラムＰ１を読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の一時記憶領域であり、制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。通信部１３は、通信に関する処理を行うための処理回路等を含み、端末２等と情報の送受信を行う。

補助記憶部１４は大容量メモリ、ハードディスク等であり、制御部１１が処理を実行するために必要なプログラムＰ１、その他のデータを記憶している。また、補助記憶部１４は、ユーザＤＢ１４１及び商品ＤＢ１４２を記憶している。ユーザＤＢ１４１は、各ユーザの情報を格納するデータベースである。商品ＤＢ１４２は、ユーザに提供する商品等の情報を記憶するデータベースである。

なお、補助記憶部１４はサーバ１に接続された外部記憶装置であってもよい。また、サーバ１は複数のコンピュータからなるマルチコンピュータであってもよく、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。

また、本実施の形態においてサーバ１は上記の構成に限られず、例えば可搬型記憶媒体に記憶された情報を読み取る読取部等を含んでもよい。

端末２は、制御部２１、主記憶部２２、通信部２３、表示部２４、入力部２５、撮像部２６、補助記憶部２７を備える。
制御部２１は、一又は複数のＣＰＵ、ＭＰＵ等の演算処理装置を有し、補助記憶部２７に記憶されたプログラムＰ２を読み出して実行することにより、端末２に係る種々の情報処理、制御処理等を行う。主記憶部２２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）等の一時記憶領域であり、制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。通信部２３は、通信を行うためのアンテナ、処理回路等を含み、サーバ１等と情報の送受信を行う。表示部２４は、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ等の表示装置であり、制御部２１から与えられた画像を表示する。入力部２５は、例えばタッチパネル、メカニカルキー等の操作部品であり、ユーザからの操作入力を受け付ける。撮像部２６は、ＣＭＯＳ（Complementary Metal Oxide Semiconductor）カメラ等の撮像機構であり、ユーザによる操作入力に従って画像の撮像を行う。

補助記憶部２７は、ＲＯＭ（Read Only Memory）等の不揮発性メモリであり、制御部２１が処理を実行するために必要なプログラムＰ２、その他のデータを記憶している。また、補助記憶部２７は、ユーザが保有するトークンのデータを管理するためのウォレット２７１を記憶している。ウォレット２７１は、仮想通貨ウォレットに係るウォレットアドレス、暗号鍵等の情報を含む。

図３は、ユーザＤＢ１４１及び商品ＤＢ１４２のレコードレイアウトの一例を示す説明図である。
ユーザＤＢ１４１は、ユーザＩＤ列、ユーザ名列、ウォレットアドレス列、購入履歴列、ＳＮＳ（Social Networking Service）列を含む。ユーザＩＤ列は、各ユーザを識別するためのＩＤを記憶している。ユーザ名列は、ユーザＩＤと対応付けて、ユーザの氏名を記憶している。ウォレットアドレス列は、ユーザＩＤと対応付けて、ユーザが所有するウォレット２７１のウォレットアドレスを記憶している。購入履歴列は、ユーザＩＤと対応付けて、ユーザが加盟店で商品又はサービスを購入した購入履歴を記憶している。購入履歴は、図３に示すように、購入額に応じてユーザにキャッシュバックした額（トークンにより返還した額）を示すキャッシュバック履歴を含む。ＳＮＳ列は、ユーザＩＤと対応付けて、ユーザが所持するＳＮＳアカウントに関する情報を記憶している。

商品ＤＢ１４２は、商品ＩＤ列、商品列、ＳＮＳ画像列、リンク列を含む。商品ＩＤ列は、ユーザに提供する各商品を識別するためのＩＤを記憶している。商品列は、商品ＩＤと対応付けて、各商品に関する情報を記憶している。ＳＮＳ画像列は、商品ＩＤと対応付けて、各商品に関連するＳＮＳ投稿用の画像データを記憶している。リンク列は、商品に関連するＷｅｂページへ遷移するためのリンクアドレスを記憶している。当該リンクアドレスは、例えば商品の提供者である企業のホームページへ遷移するためのアドレスである。

図４は、実施の形態１の概要を示す説明図である。図５は、トークンバック処理を説明するための説明図である。図４では、ユーザが商品を購入した場合にキャッシュバック相当のトークンを付与する様子を図示している。図５では、トークンバックの具体例を概念的に図示している。

まず図４に基づき、本実施の形態の概要について説明する。既に述べたように、本システムでは発行サーバ３が発行する独自通貨（トークン）を取り扱う。例えば発行サーバ３は、ＩＣＯ（Initial Coin Offering）を実施し、自らが生成したトークンの全部又は一部を販売する。例えば発行サーバ３は、当該トークンの販売価格、数量等の情報を取引所サーバ４に出力（上場）し、一般のユーザに販売する。

なお、ＩＣＯを実施する場合、発行サーバ３はトークンの発行総量の上限を定めた上で、当該発行総量の一部に相当するトークンを市場に供給する。例えばトークンの発行総量が１万枚である場合、発行サーバ３は、ＩＣＯの段階では発行総量の１割に相当する１０００枚のトークンを供給する。後述するようにサーバ１からトークンの新規購買要求を受け付けた場合、発行サーバ３は、発行総量の上限（１万枚）を満たす範囲で新規にトークンを発行し、サーバ１宛に送金（販売）する。

発行サーバ３は、端末２からトークンの購買要求を受け付け、ユーザにトークンを販売する。例えば取引所サーバ４がトークンの売買を仲介し、発行サーバ３は端末２とトランザクションを行ってユーザのウォレットアドレス宛にトークンを送信（送金）する。これにより、ユーザはトークンを保有する保有者となる。

なお、端末２は取引所を介さず、発行サーバ３に直接アクセスしてトークンを取得するようにしても良い。また、例えば発行サーバ３は所定数量のトークンを予めサーバ１に送金しておき、サーバ１が端末２との間でトランザクションを行って、トークンを販売するようにしても良い。

トークンを保有するユーザは、トークンの発行主体である企業が提供する商品等を購入した場合、購入額に応じたトークンの譲渡、つまりトークンによるキャッシュバック（トークンバック）を受けることができる。

例えば図４下に示すように、まずユーザは、発行企業が提供する商品等を所定の店舗で購入する。商品等の購入は上述のトークンを利用したものであってもよいが、当該トークン以外の決済手段（例えば法定通貨）に依るものとすると好適である。なお、ユーザが購入する商品等は、発行企業が直接提供する商品等ではなく、発行企業と提携する所定の加盟店で提供される商品等であってもよい。また、商品等の購入場所は実店舗である必要はなく、後述する実施の形態２のように、インターネット上で商品を販売するＥＣサイト等であってもよい。

ユーザによって商品等が購入された場合、サーバ１は、購入された商品、購入額等に関する購入情報（支出情報）を取得する。購入情報は、商品等を購入したユーザを識別可能なユーザＩＤと、購入した商品等の購入額と、購入した商品を特定可能な商品ＩＤとを含む。

例えばサーバ１は、端末２から購入情報を取得する。例えば商品等を購入した場合、商品等を購入したことをサーバ１に証明するため、ユーザは端末２を操作し、領収書、レシート等の紙媒体を撮像してサーバ１に送信する。サーバ１は撮像画像に対する文字認識を行い、購入情報を取得する。

また、例えばサーバ１は、店舗での商品の購入状況を管理するＰＯＳ（Point of Sales）システムと同期して、購入情報を取得するようにしてもよい。このように、サーバ１は購入情報を取得可能であればよく、購入情報の取得経路は特に問わない。

サーバ１は、取得した購入情報をユーザＤＢ１４１に記憶し、購入履歴を蓄積する。

なお、図３では簡潔のため、ユーザが購入した商品や購入額等の簡単な情報のみが購入履歴として蓄積されるものとして説明したが、これらの情報に加えて、例えば商品の返品やキャンセル等の情報を履歴として蓄積してもよい。

サーバ１は、ユーザが購入した商品等の購入額から、ユーザに付与するキャッシュバック相当のトークン量を算出する。例えばサーバ１は、商品等の購入額以外に、ユーザが保有するトークンの保有情報に基づいてトークン量を算出する。

保有情報は、ユーザによるトークンの保有状況を示す情報であり、例えばトークンを売却せずに継続して保有している保有期間、ウォレット２７１に保有しているトークンの保有量などである。本実施の形態でサーバ１は、トークンの保有期間及び保有量に応じて、ユーザに譲渡するトークン量を定める。サーバ１は、トークンのトランザクションデータを複数のノードに分散して管理する分散型台帳（例えばブロックチェーン）を参照して、ユーザが保有するトークンの保有期間及び保有量を読み出す。サーバ１は、読み出した保有期間及び保有量に応じて、ユーザに譲渡するトークン量を定める。

図５に基づき、保有情報に応じたトークンバック処理について説明する。図５では、同一の商品を購入した二名のユーザに対し、トークンの保有状況に応じて異なる数量のトークンが譲渡される様子を図示している。図５に示す例では、「ユーザＡ」は、「２．０００」の数量のトークンを「５年」の間保有している。また、「ユーザＢ」は、ユーザＡよりも少ない「１．０００」の数量のトークンを、ユーザＡよりも短い「１年」の間保有している。

まずサーバ１は、各ユーザのトークンの保有情報に基づき、ユーザが所定数以上のトークンを保有しているか否かを判定する。当該所定数は、例えば１枚（１．０００）である。ユーザが１枚以上のトークンを保有していない場合、サーバ１は購入情報を取得しても当該ユーザをトークンバックの対象とはせず、トークンを付与しない。一方、ユーザが１枚以上のトークンを保有している場合、サーバ１はトークンを付与する。つまりサーバ１は、トークンバックの有資格者をトークンの最低保有量に基づいて定め、最低保有量以上のトークンを有するユーザに対し、トークンを付与する。図５に示す例では、ユーザＡ、Ｂ共に１枚以上（１．０００以上）保有しているため、両者共にトークンバックの対象となる。一方で、サーバ１は、トークンの保有量が１枚未満のユーザに対してはトークンを付与しない。トークンバックを受けるために必要な最低保有量を定めることで、当該トークンを一種の会員権として機能させる。

なお、上記のトークンの保有量を判定する判定時点は、例えばユーザが商品等を購入した購入時点としてもよく、購入情報がサーバ１へ送信された送信時点としてもよい。このように、ユーザがトークンバックの有資格者であるか否かを判定する判定時点は特に限定されない。

ユーザが１枚以上のトークンを保有している場合、サーバ１は、ユーザにキャッシュバックする金額（以下、「キャッシュバック額」と呼ぶ）を、商品等の購入情報に基づいて算出する。図５の例の場合、例えばサーバ１は、５０万円の商品を購入したユーザＡに対し、購入額の１％に相当する５０００円をキャッシュバック額として計算する。なお、購入額のうちどの程度の割合をキャッシュバック額とするかは任意の設計事項であり、例えばユーザが購入する商品等に応じて別々にキャッシュバック割合を定めてよい。また、例えばサーバ１は、ユーザが購入した商品等の違いに関わらず、一定額のトークンをユーザに付与するようにしてもよい。

一方で、サーバ１は、ユーザＡと同一の商品を購入したユーザＢに対して、購入額の０．１％に相当する５００円をキャッシュバック額として計算する。ユーザＢのトークンの保有量はユーザＡの半分であり、保有期間は５分の１であるため、サーバ１はユーザＢへのキャッシュバック額をユーザＡの１０分の１とする。このように、サーバ１は購入額に対して保有期間及び保有量に応じた係数を乗算し、各ユーザに対するキャッシュバック額を算出する。

なお、上記の算出方法は一例であって、キャッシュバック額の算出方法はこれに限定されない。例えばキャッシュバック額算出の基準とする保有情報の一つとして、ユーザによる過去のトークン売却の有無を加えてもよい。また、キャッシュバック額算出の基準とする購入情報の一つとして、ユーザによる商品購入の頻度を加えてもよい。また、キャッシュバック額算出の基準とする情報は、商品等の購入情報、及びトークンの保有情報に限定されず、例えば後述するＳＮＳへの投稿の有無など、他の情報であってもよい。

サーバ１は、上記で算出したキャッシュバック額から、一部の金額を抽出（減算）する。例えばサーバ１は、本システム運営のための手数料として一部の金額を抽出し、発行主体の収入とする。これにより、本システムを安定して運営することができる。

なお、サーバ１はキャッシュバック額の一部を手数料以外の名目で抽出してもよい。例えばトークン発行主体が提供するサービスとして不動産賃貸を想定した場合、サーバ１は、キャッシュバック額の一部を賃貸料の名目で抽出し、ユーザが月々に支払う賃貸料に充てて良い。これにより、ユーザにとっては賃貸料が自動的に減額された形になり、利便性が向上する。このように、サーバ１は、ユーザが購入した商品又はサービスに関連する用途に用いるため、キャッシュバック額の一部を抽出してもよい。

サーバ１は、手数料減算後のキャッシュバック額に相当する数量のトークンを取得し、ユーザに譲渡する。例えば図５に示すように、サーバ１はユーザＡに対し、４５００円に相当する「０．０４５」のトークンを譲渡する。また、サーバ１はユーザＢに対し、「０．００４５」のトークンを譲渡する。

なお、例えばサーバ１は、社会貢献活動の一環として、キャッシュバック額の一部を所定の寄贈先（寄付先）に送金するようにしてもよい。例えばサーバ１は、キャッシュバック額から差し引いた所定額を、自然保護団体、動物保護団体、児童支援施設等に対して送金する。具体的な図示及び説明は省略するが、例えばサーバ１は、ユーザによる商品等の購入履歴に応じて、キャッシュバック額を寄贈する一又は複数の寄贈先と、各寄贈先に寄贈する金額の配分を決定し、各寄贈先に送金を行う。

購入履歴（支出履歴）から寄贈先及び配分を定める方法は特に限定されないが、例えばサーバ１は、購入商品の属性（例えば男性向け商品であるか、女性向け商品であるか等）と各寄贈先の属性（例えば環境保護団体であるか、教育関連団体であるか等）とを紐付けておき、ルールベースで寄贈先及び配分を決定してよい。また、例えばサーバ１は、各ユーザから手動で寄贈先及び配分の設定入力を受け付け、ある程度サンプルを蓄積した後、購入履歴に基づいてユーザ同士のマッチングを行い、購入履歴が類似するユーザと同じ寄贈先及び配分にするよう決定してよい。

このように、キャッシュバック額の一部を手数料ではなく寄贈することで、本システムを単なる購買促進策としてだけでなく、社会貢献策として実現することができる。特に上記では、ユーザの購入履歴（支出履歴）から寄贈先及び配分を決定することで、寄贈者であるユーザに応じて自動的にアロケーションを行い、適切な寄贈を行うことができる。

なお、寄贈先への送金は法定通貨建てで行ってもよいが、トークン建てで行うと好適である。これにより、法定通貨で送金を行う場合よりも送金手数料を抑制し、寄贈額を増やすことができる。

上述の如く、サーバ１は、トークンの保有期間が長く、保有量が多いユーザほど多くのトークンを譲渡する。これにより、ユーザにはトークンを売却せずに保有しておくインセンティブが生まれ、後述するトークンの価値上昇の一助とすることができる。

図４に戻って説明を続ける。例えばサーバ１は、所定期間毎に各店舗から商品等の購入額に応じた送金を受け、購入額の一部を原資として、以下のようにキャッシュバック用のトークンを調達する。具体的には、サーバ１はトークンの発行サーバ３、あるいはトークンを保有する保有者からキャッシュバック用のトークンを取得（購入）し、ユーザに付与する。

まずサーバ１は、発行サーバ３に対し、トークンの購買要求を送信する。当該購買要求は、例えばトークンの購入数量、購入価格等の情報を含む。

サーバ１から購買要求を受け付けた場合、発行サーバ３は、トークンの保存（在庫）があるか否かを判定する。トークンの保存があると判定した場合、発行サーバ３は、保存してあるトークンから、サーバ１が要求した数量のトークンをサーバ１宛に送信するトランザクションを実行する。サーバ１はトークン取得の対価として、ユーザによる商品等の購入額の一部を発行サーバ３へ送金する。

トークンの保存がないと判定した場合、発行サーバ３は、トークンの発行総量の上限を超えない範囲で新規にトークンを発行し、サーバ１にトークンを送信する。例えば発行総量が１万枚で、発行サーバ３にてトークンの保存がない場合、発行サーバ３は発行数量を１０％増やし、新たに１０００枚のトークンを発行（生成）する。発行サーバ３は、新規に発行したトークンからサーバ１へのトークン送信を行う。

また、サーバ１は、発行サーバ３からトークンを調達するだけでなく、トークンを保有する一般の保有者からトークンを調達してもよい。例えばサーバ１は、トークンの発行総量が上限に達した場合など、発行サーバ３からトークンを取得できない場合、トークンの希望購入価格、希望購入数量等の情報、すなわち購買要求を取引所サーバ４に出力する。取引所サーバ４は、トークンの売却価格等がマッチする保有者を検索して、トークンの売買を約定させる。サーバ１は、売買が約定した保有者からトークンの送金を受けるトランザクションを実行し、ユーザに付与するトークンを取得する。このように、サーバ１は購入額の一部を元手にトークンを調達可能であればよく、トークンを発行元から取得しても、他のトークン保有者から取得してもよい。

上記の処理によって、サーバ１は発行サーバ３の在庫から、又はトークン保有者から新たにトークンを調達するため、市場に流通するトークンの流通量を減少させ、トークンの価格を上昇させる作用が働く。なお、上記では過度なトークンの価格高騰を避けるため、発行済みトークンの保存がなくなった場合に新規トークンを発行しているが、発行総量を超えない限度で新規発行が行われるため、全体的に見るとトークンの価格上昇作用が働く。

これにより、ユーザが保有するトークンの価値が上昇する。従って、ユーザはショッピングを行うことで単にトークンを得ることができるだけでなく、商品等を購入するほど自らが保有するトークンの価値上昇を期待することができる。これによりユーザの購買意欲が刺激され、商品等の売上向上を期待することができる。

上記ではユーザに商品等を提供する企業がトークンの発行主体である場合について説明を行ったが、既に述べたように、トークンの発行主体は地方自治体、国、金融機関等、種々の団体が考え得る。それに伴い、上記の実施形態は種々の変更が考え得る。

例えば地方自治体、国等の行政機関が発行主体である場合、サーバ１は、地域独自、国独自のトークンを所定数以上保有するユーザに対し、トークンバックを実施する。サーバ１は、地域内、国内の加盟店でユーザが商品等を購入した際の購入情報を収集し、購入額に応じてキャッシュバック相当のトークンを付与する。また、サーバ１はキャッシュバック額の一部を抽出し、税収とすることもできる。これにより、行政機関は自らの経済圏に加入するユーザに対してインセンティブを付与することができると共に、新たな収入源を得ることができる。

なお、上記では商品等の購入行為、いわゆる消費支出を契機にトークンバックを行っているが、トークンバックの契機とする支払い行為は消費支出に限定されず、税金、社会保険料等の支払いのように、いわゆる非消費支出であってもよい。すなわち、サーバ１はユーザが所定の支出先に対して支出した金額に応じた数量のトークンを付与可能であればよく、支出内容は商品等の購入行為に限定されない。

金融機関がトークンの発行主体である場合、例えばサーバ１は、金融機関を利用して決済等を行うユーザに対し、利用額に応じた数量のトークンを付与する。この場合にサーバ１は、キャッシュバック額の一部を利用手数料として抽出し、残額に相当するトークンをユーザに付与する。これにより、ユーザによる金融機関の利用を後押しすることができると共に、金融機関にとって新たな収入源を得ることができる。

図６は、端末２に表示されるアプリケーション画面の一例を示す説明図である。図６Ａでは、ユーザがキャッシュバックとして受け取るトークンの数量を確認可能な表示画面（以下、トークンバック画面と呼ぶ）の一例を図示している。図６Ｂでは、トークンバック画面への操作入力に応じてＳＮＳ上に投稿される投稿記事（投稿情報）を表示するＳＮＳ画面の一例を図示している。図６Ａ、Ｂに基づき、端末２における画面表示について説明する。

図６Ａに示すように、トークンバック画面は、ユーザによって購入された商品等に関し、トークンバックの履歴を一覧で表示する。具体的には、トークンバック画面は、トークンバックの要因となった商品等の購入履歴と、購入額に応じて付与されたトークンの数量とを示す明細６１、６１、６１…を表示する。

また、トークンバック画面は、ＳＮＳ画像６２を表示する。ＳＮＳ画像６２は、ＳＮＳへのアップロード用にサーバ１が予め用意している投稿素材であり、例えばユーザが購入済みの商品等の画像である。図６に示すように、トークンバック画面には、購入商品をＳＮＳにアップロードするためのＳＮＳ画像６２が表示される。トークンバック画面を介してユーザに明細６１の通知を行う場合、サーバ１は併せて、商品等のＳＮＳ画像６２を商品ＤＢ１４２から検索し、トークンバック画面に出力する。

端末２は、表示されているＳＮＳ画像６２への操作入力を受け付けることで、ＳＮＳ画像６２を用いてＳＮＳへの投稿を行うか否かの選択入力を受け付ける。ＳＮＳ画像６２への操作入力を受け付けた場合、例えば端末２は不図示のポップアップ画面を表示し、ＳＮＳアップロード用のコメント等の入力を受け付ける。端末２は、コメント等の入力内容をサーバ１に通知する。そして端末２は、ＳＮＳ画像６２を用いた投稿記事（投稿情報）を生成し、アップロードするよう要求する。

端末２からアップロードの要求を受け付けた場合、サーバ１は、図６Ｂに示す投稿記事を生成してＳＮＳ上に出力（アップロード）する。ＳＮＳに投稿される投稿記事は、例えばユーザのアカウント名、コメント、ＳＮＳ画像６２等のほか、リンク６３を含む。リンク６３は、ユーザが購入した商品等に関連するＷｅｂページへ遷移するためのハイパーリンクであり、例えば商品等を提供する企業ホームページへのリンクである。サーバ１は端末２での入力内容に基づき、リンク６３を含む投稿記事を生成してユーザのＳＮＳアカウントにアップロードする。これにより、商品等の情報がＳＮＳ上に拡散され、本システムに係るサービスへの他のユーザの参加を促すことができる。

なお、上述の如く、サーバ１はキャッシュバック額の一部を所定の寄贈先に寄贈することも可能である。それに伴い、サーバ１は商品等だけではなく、寄贈先に関する情報を投稿素材としてＳＮＳへの投稿を行ってもよい。例えばサーバ１は、図６Ａに示すトークンバック画面で、ユーザが購入した商品等のＳＮＳ画像６２のほかに、寄贈先に関するＳＮＳ画像６２（例えば寄贈先が児童支援施設である場合、児童の写真）を表示しておく。寄贈先のＳＮＳ画像６２への操作入力を受け付けた場合、サーバ１は、当該寄贈先のＳＮＳ画像６２を投稿素材として投稿情報を生成し、ＳＮＳ上に出力する。これにより、本システムで実現できる社会貢献活動をＳＮＳ上に拡散し、他のユーザに広く認知させることができる。

図７は、トークン算出処理の処理手順の一例を示すフローチャートである。図７に基づき、ユーザに付与するトークン量を算出する処理の処理内容について説明する。
サーバ１の制御部１１は、ユーザが所定の支出先に対して支出した金額を示す支出情報を取得する（ステップＳ１１）。上述の如く、例えば支出情報は、ユーザが購入した商品等に関する購入情報である。なお、支出情報は商品等の購入のような消費支出に限定されず、非消費支出であってもよい。支出先は、トークンの発行主体である企業、地域自治体、国、金融機関等の団体、あるいは発行主体と提携する加盟店のような関連団体である。支出情報は、例えばユーザを識別するためのユーザＩＤ、支出金額、支出対象（商品等）等の情報を含む。

支出情報を取得した場合、制御部１１は、複数のノードに分散して管理されている分散型台帳（例えばブロックチェーン）のトランザクションデータを参照して、支出先に対応するトークンに関し、ユーザが保有するトークンの保有状況を示す保有情報を取得する（ステップＳ１２）。例えばステップＳ１１で取得した支出情報が、ある企業が提供する商品等に対する支出を表す場合、ステップＳ１２でトランザクションを参照するトークンは、当該企業が発行するトークンである。このように、制御部１１は、支出先（発行主体）に対応するトークンの保有情報を取得する。保有情報は、トークンの保有期間、保有量等の情報を含む。

制御部１１は、取得した保有情報に基づき、ユーザが所定数以上のトークンを保有しているか否かを判定する（ステップＳ１３）。所定数以上のトークンを保有していないと判定した場合（Ｓ１３：ＮＯ）、制御部１１は一連の処理を終了する。

所定数以上のトークンを保有していると判定した場合（Ｓ１３：ＹＥＳ）、制御部１１は、ステップＳ１２で取得した支出情報と、ステップＳ１２で取得した保有情報とに基づき、ユーザに付与するキャッシュバック相当のトークン量を算出する（ステップＳ１４）。例えば制御部１１は、商品等の購入額の一部から手数料名目で所定額を減算し、減算後の金額をキャッシュバック額として算出する。制御部１１は、ユーザによるトークンの保有期間及び保有量に基づき、保有期間が長く、保有量が多いほどキャッシュバック額が多くなるように変更する。制御部１１は、算出したキャッシュバック額に相当するトークン量の数量を算出する。なお、制御部１１は、算出したキャッシュバック額をユーザＤＢ１４１に記憶する。制御部１１は、ステップＳ１４で算出したトークン量を端末２に通知する（ステップＳ１５）。

サーバ１から通知を取得した場合、端末２の制御部２１は、サーバ１から付与されるトークンの数量を表示部２４に表示する（ステップＳ１６）。例えば制御部２１は、図６で図示したように、ユーザに付与されるトークンの数量と、当ＳＮＳアップロード用の画像の候補であるＳＮＳ画像６２とを表示する。ＳＮＳ画像６２は、ユーザが購入した商品等に関連する画像である。

制御部２１は、ステップＳ１６で表示したＳＮＳ画像６２に対する操作入力を受け付けたか否かに応じて、ＳＮＳへの投稿を行うか否かを判定する（ステップＳ１７）。ＳＮＳへの投稿を行わないと判定した場合（Ｓ１７：ＮＯ）、制御部２１は一連の処理を終了する。ＳＮＳへの投稿を行うと判定した場合（Ｓ１７：ＹＥＳ）、制御部２１は、ＳＮＳ画像６２と共に投稿するコメント等の入力を受け付ける（ステップＳ１８）。制御部２１は、ＳＮＳに投稿する記事（投稿情報）を生成してアップロードするようサーバ１に要求する（ステップＳ１９）。端末２からアップロード要求を受け付けた場合、サーバ１の制御部１１は、ＳＮＳ画像６２と、ステップＳ１８で入力されたコメント等との投稿素材を用いてＳＮＳアップロード用の記事を生成し、ＳＮＳ上にアップロードする（ステップＳ２０）。当該記事は、ステップＳ１９で選択された画像、ステップＳ２０で入力されたコメント等のほか、ユーザが購入した商品等に関連するＷｅｂページへ遷移するためのリンク６３を含む。制御部１１は、一連の処理を終了する。

図８は、トークン付与処理の処理手順の一例を示すフローチャートである。図８に基づき、キャッシュバック用のトークンを取得してユーザに付与する処理について説明する。なお、説明の簡潔のため、サーバ１は店舗側から送金を受け、キャッシュバックの原資を取得済みであるものとして説明する。
サーバ１の制御部１１は、例えばバッチ処理により以下の処理をスタートする。制御部１１はユーザＤＢ１４１を参照して、各ユーザに付与するトークンのキャッシュバック額を読み出す（ステップＳ３１）。制御部１１は、トークンの発行元（発行サーバ３）に対し、キャッシュバック額に相当する数量のトークンを購入する購買要求を行う（ステップＳ３２）。そして制御部１１は、ユーザによる商品等の購入額の一部を発行サーバ３等に送金し、キャッシュバック用のトークンを取得するトランザクションを実行する（ステップＳ３３）。すなわち制御部１１は、商品等の購入額の一部を原資にトークンを購入する。

例えば発行サーバ３は、ステップＳ３２で購買要求を受け付けた場合、要求分のトークンの保存（在庫）があるか否かを判定する。要求分のトークンがあると判定した場合、発行サーバ３は、保存してあるトークンから要求分のトークンをサーバ１へ送金するトランザクションを実行する。要求分のトークンがないと判定した場合、発行サーバ３は、発行総量の上限を超えない範囲で新規トークンを発行し、新規に発行したトークンから、サーバ１が要求した数量のトークンを送金するトランザクションを実行する。

トークンの発行総量が上限に達している場合、例えばサーバ１は、取引所サーバ４を介して一般のトークン保有者に対し購買要求を行う。サーバ１は、取引所サーバ４を介してトークン保有者との間でトークンの売買に係る取引を約定させ、トランザクションを実行してキャッシュバック用のトークンを取得する。

トークンの発行元である発行サーバ３、又は他のトークン保有者からトークンを取得した場合、制御部１１は、キャッシュバック相当のトークンをユーザに付与する（ステップＳ３４）。具体的には、制御部１１はユーザのウォレットアドレス宛にキャッシュバック相当のトークンを送金するトランザクションを実行する。制御部１１は、一連の処理を終了する。

なお、上記でサーバ１は、ステップＳ３３で発行サーバ３等からトークンを取得するトランザクションを行い、その後にステップＳ３４でユーザ宛にトークンを送金するトランザクションを行っているが、ステップＳ３３、Ｓ３４のトランザクションを一にまとめ、発行サーバ３等から直接ユーザ宛にトークンを送金するようにしてもよい。つまりサーバ１は、ユーザにトークンが付与されるようオペレーティング可能であればよく、自らトークンの取得、送信を行わずともよい。

また、上記ではＳＮＳ投稿用の素材としてＳＮＳ画像６２を一例に挙げたが、投稿素材は画像（静止画及び動画）に限定されず、例えばテキスト、音声データ等であってもよい。

また、上記では別段説明しなかったが、サーバ１は、ユーザによって商品等が購入されてから一定期間後にトークンを端末２に送信（付与）するようにしてもよく、商品等の購入直後にトークンを送信してもよい。すなわち、サーバ１は、店舗側からの送金を待ってキャッシュバック用のトークンを調達し、トークンの調達完了後、ユーザに付与するようにしてもよい。この場合、例えばサーバ１は、ユーザによるショッピング直後は予定されているトークンバック量をトークンバック画面に表示させておき、トークンの調達完了後に改めてトークンを送信するようにすればよい。また、サーバ１は商品等の購入直後にリアルタイムでトークンを送信し、その後に店舗側から送金を受けてトークンを調達（補填）するようにしてもよい。このように、ユーザに対するトークン付与、店舗側からの送金、及び発行サーバ３からのトークン取得の順番は任意の設計事項であり、各処理は前後することがあり得る。

また、店舗における商品等の購入決済は現金決済だけでなく、例えばクレジットカードによる決済、掛取引による決済などのように、商品等の購入時点と決済時点とが異なっていてもよいことは勿論である。

また、上記では特定の装置（発行サーバ３）がトークンの発行を行っているが、例えばビットコイン（登録商標）のように、トークンのマイニングの合意形成時に予め定められた発行上限の範囲でトークンを新規に発行するようにしても良い。

また、上記では主にユーザが商品等を購入するケースについて説明したが、ユーザが所有物を売却する場合にトークンを付与するようにしてもよい。具体的には、例えば不動産のように、実物資産の売却時にトークンを付与するようにしてもよい。このようなケースで、トークンバックの原資とする金銭としては、資産の売買を仲介する仲介者の手数料が考えられる。例えばサーバ１は、仲介者が発行するトークンを保有するユーザが所有物を売却する場合、仲介者に支払う仲介手数料を示す支出情報を取得する。そしてサーバ１は、手数料の一部に相当する数量のトークンをユーザに付与する。上記に依れば、本実施の形態を単なる消費活動ではなく、資産（所有物）の売買にまで適用することができ、ユーザの経済活動をより広く支援することができる。

以上より、本実施の形態１によれば、サーバ１はトークン（仮想通貨）を保有するユーザに対し、支出金額に応じて、キャッシュバック相当のトークンを付与する。これにより、単純な仮想通貨による決済システムとは異なり、仮想通貨を活用して、ユーザによる経済活動を支援することができる。また、支出金額の一部を原資にキャッシュバックが賄われるため、持続可能な経済活動のサイクルを構築することができる。

また、本実施の形態１によれば、サーバ１はユーザによる支出金額の一部を原資として、キャッシュバック相当のトークンを、発行元から、又は市場から調達する。これにより、トークンの流通量を減少させ、トークンの価値上昇を促すことができる。

また、本実施の形態１によれば、トークンを所定数以上保有するユーザにのみ、キャッシュバック相当のトークンを付与する。トークンバックを受けるために必要な最低保有量を定めることで、当該トークンを一種の会員権として機能させ、持続可能な経済活動のサイクルをより適切に構築することができる。

また、本実施の形態１によれば、トークンの保有期間、保有量など、ユーザによるトークンの保有状況に応じて付与するトークンの数量を決定する。これにより、ユーザにはトークンを売却せずに保有するインセンティブが生まれ、トークンの価値上昇を期待することができる。

また、本実施の形態１によれば、サーバ１はユーザに付与するトークンの一部を抽出し、発行主体の収入、支出用途に応じた代理決済、寄贈等、種々の目的で利用することができる。

また、本実施の形態１によれば、サーバ１はＳＮＳ投稿用の素材をユーザに提示し、ユーザの選択を受けて投稿記事（投稿情報）を生成し、自動的にアップロードする。これにより、ユーザが購入した商品等を他のユーザに周知して本サービスへの参加を促すことができる。

（変形例１）
各サーバ１が上述の処理を行うことにより、企業等の各発行主体は、各々がユーザに対するトークンバックを実施する。これにより、商品等の購入を支援する複数のシステムが構築される。図９は、複数の仮想通貨取引システムが構築される様子を概念的に示す説明図である。図９に示すように、企業Ａが発行するトークンＡを保有するユーザは、企業Ａの商品等を購入した場合、購入額に応じた数量のトークンＡの付与を受ける。同様に、企業Ｂ、Ｃが発行するトークンＢ、Ｃを保有するユーザは、企業Ｂ、Ｃの商品等を購入した場合、トークンＢ、Ｃの付与を受ける。

本実施の形態ではさらに、各サーバ１が提携して、各システムを利用するユーザに対し、システムを跨ぐトークンバックを行ってよい。具体的には、第１の発行主体が発行する第１のトークンを所定数以上保有するユーザが、第２の発行主体が提供する商品等を購入した場合、サーバ１は、当該第２の発行主体が発行する第２のトークンをユーザに付与する。

図９左下に、当該処理を概念的に図示してある。図９左下に示すユーザは、トークンＢを保有しているが、トークンＡは保有していないものとする。このように、トークンＡ、Ｂのいずれかのみを保有するユーザに対しても、企業Ａ、Ｂそれぞれのサーバ１は提携してトークンバックを実施する。例えば図９左下のユーザが企業Ａの商品等を購入した場合、サーバ１はトークンＢ（第１の仮想通貨）のトランザクションデータを参照して、企業Ａと提携する企業ＢのトークンＢを当該ユーザが所定数以上保有しているか否かを判定する。ユーザがトークンＢを所定数以上保有する場合、サーバ１は当該ユーザに対し、トークンＢと異なるトークンＡ（第２の仮想通貨）を付与する。なお、当該処理は企業Ａ、Ｂのいずれのサーバ１が実行してもよい。

また、上記とは反対に、トークンＡ（第１の仮想通貨）を保有するユーザが企業Ａの商品等を購入した場合、サーバ１は、企業Ａと提携する企業ＢのトークンＢをユーザに付与するようにしてもよい。これにより、企業Ｂの商品等の購入を促すことができる。

上記のように、複数の発行主体それぞれが発行するトークンのうち、いずれかを保有することを条件にして、ユーザが保有するトークンとは別のトークンを付与するようにしてもよい。これにより、ユーザは各トークンによるトークンバックを受けたい場合に各トークンを別々に購入しておく必要がなくなり、ユーザの利便性を向上させることができる。

ユーザが保有するトークンとは別のトークンを付与する点以外は実施の形態１と同様であるため、変形例１ではフローチャート等の詳細な図示及び説明は省略する。

（実施の形態２）
本実施の形態では、ＥＣサイト等における商品購入時にトークンを付与する形態について述べる。なお、実施の形態１と重複する内容については同一の符号を付して説明を省略する。
図１０は、実施の形態２の概要を示す説明図である。図１０では、ユーザがＥＣサイトを利用して商品を購入し、購入額に応じたトークンを得る様子を概念的に図示している。ＥＣサイトは、インターネット上の仮想店舗であり、Ｗｅｂ上で商品を販売するＷｅｂサイトである。ユーザは、ＥＣサイトを介して商品を購入し、配送を受けることができる。

本実施の形態でサーバ１はＥＣサイトと提携しており、ＥＣサイトを管理するＥＣサーバ５から商品の購入情報を取得し、ＥＣサイトを利用したユーザに対してトークンを付与する。例えばサーバ１は、ＥＣサイトの運営会社から手数料名目で購入額の一部を取得し、当該手数料を原資としてトークンを購入し、ユーザに付与する。

図１１は、端末２における画面遷移を説明するための説明図である。図１１に基づき、ＥＣサイトからトークンバック画面（図６参照）へ遷移する画面遷移の工程について説明する。
端末２はまず、ＥＣサーバ５にアクセスし、ＥＣサイトに係るブラウザ画面を表示する。当該画面は、ＥＣサイトに出品されている商品に関する商品情報を表示する。端末２は、ユーザによる操作入力を受け付け、ユーザが購入を希望する商品の指定入力を受け付ける。端末２は、指定された商品の購入をＥＣサーバ５に要求する。

購入要求を受け付けた場合、ＥＣサーバ５は、所定の決済処理を実行し、商品の購入を確定させる。ＥＣサーバ５は、購入が確定した商品の購入情報をサーバ１に送信する。また、ＥＣサーバ５は、決済が終了した旨を示す終了画面（不図示）を端末２に表示させ、ショッピングが完了した旨をユーザに通知する。

ここでＥＣサーバ５は、終了画面において、提携するサーバ１提供のアプリケーションプログラム（プログラムＰ２）を起動するためのリンクを表示する。例えば図１１に示すように、ＥＣサーバ５は、「シェアしますか」というハイパーリンク付きのテキストを終了画面に表示する。当該テキストが操作された場合、端末２はアプリケーションプログラムを起動する。例えば端末２は、図６で例示したトークンバック画面を表示し、ＳＮＳ画像６２をユーザに提示する。ユーザはＳＮＳ画像６２への操作入力を行うことで、実施の形態１と同じく、ＳＮＳへの自動投稿を行うことができる。

上述の如く、本システムは、ＥＣサイトを介した所謂ネットショッピングにおいても実現することができる。特に本実施の形態では、ＥＣサイトでの商品の購入完了後、終了画面にアプリケーションプログラムへのリンクを表示しておき、当該リンクへの操作をトリガとしてＳＮＳ画像６２の表示画面へと遷移する。これにより、ユーザはＥＣサイトでのショッピングからスムーズにＳＮＳへの投稿を行うことができる。

図１２は、実施の形態２に係るトークン付与処理の一例を示すフローチャートである。図１２に基づき、実施の形態２に係るトークン付与処理の処理内容について説明する。
端末２の制御部２１は、ＥＣサーバ５にアクセスし、商品情報の出力をＥＣサーバ５に要求する（ステップＳ２０１）。商品情報の出力要求を受け付けた場合、ＥＣサーバ５は、商品情報を端末２に出力する（ステップＳ２０２）。

端末２の制御部２１は、ＥＣサーバ５から出力された商品情報をブラウザ上で表示する（ステップＳ２０３）。制御部２１は、ユーザから商品の購入要求に係る操作入力を受け付け、ＥＣサーバ５に送信する（ステップＳ２０４）。

購入要求を受信した場合、ＥＣサーバ５は、要求された商品の購入決済を行う決済処理を実行する（ステップＳ２０５）。例えばＥＣサーバ５は、予め登録されているユーザのクレジットカード番号などを元に、クレジット会社等を経由してユーザの銀行口座から引き落としを行う。

ＥＣサーバ５は、ユーザが購入した商品に関する購入情報（支出情報）をサーバ１へ送信する（ステップＳ２０６）。サーバ１の制御部１１は、ＥＣサーバ５から購入情報を取得し（ステップＳ１１）、処理をステップＳ１２に移行する。

ＥＣサーバ５は、決済処理が終了した旨を端末２に通知する（ステップＳ２０７）。端末２の制御部２１は、ＥＣサーバ５からの通知に基づき、決済が終了した旨を示す終了画面を表示する（ステップＳ２０８）。終了画面は、購入した商品、購入額等のほか、サーバ１提供のアプリケーションプログラム（Ｐ２）を起動し、ＳＮＳ画像６２の表示画面へ遷移するためのリンクを含む。制御部２１は、ユーザによる操作入力に基づき、アプリケーションプログラムを起動してＳＮＳへの投稿を行うか否かを判定する（ステップＳ２０９）。投稿を行わないと判定した場合（Ｓ２０９：ＮＯ）、制御部２１は一連の処理を終了する。投稿を行うと判定した場合（Ｓ２０９：ＹＥＳ）、制御部２１はアプリケーションプログラムを起動し、ＳＮＳ画像６２を含むトークンバック画面を表示する（ステップＳ２１０）。制御部２１は、処理をステップＳ１６に移行する。

なお、上記ではＥＣサイト（Ｗｅｂサイト）で商品を購入する形態について説明したが、専用のＧＵＩアプリケーションを端末２にインストールし、当該アプリケーションのＧＵＩ画面上でＥＣサービスを受ける形態も本実施の形態の範疇に含まれる。つまりサーバ１は、ユーザがＥＣサービスを利用して商品を購入する場合にトークンの付与を行うことができればよく、ＥＣサービスの形態はＷｅｂサイトに限定されない。

以上より、本実施の形態２によれば、ＥＣサイトを介して商品を購入するケースにも、本システムを応用することができる。

今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ サーバ（情報処理装置）
１１ 制御部
１２ 主記憶部
１３ 通信部
１４ 補助記憶部
Ｐ１ プログラム
１４１ ユーザＤＢ
１４２ 商品ＤＢ
２ 端末（端末装置）
２１ 制御部
２２ 主記憶部
２３ 通信部
２４ 表示部
２５ 入力部
２６ 撮像部
２７ 補助記憶部
Ｐ２ プログラム
２７１ ウォレット

Claims (10)

1. ユーザが所定の支出先に対して支出した金額を示す支出情報を取得する支出情報取得部と、
   複数のノードに分散して管理される仮想通貨の取引データを参照して、前記ユーザが前記支出先に対応する前記仮想通貨を保有しているか否かを判定する判定部と、
   前記仮想通貨を保有していると判定した場合、前記支出した金額に応じた数量の前記仮想通貨を前記ユーザに付与する付与部と
   を備えることを特徴とする情報処理装置。
2. 前記支出した金額に応じた数量の前記仮想通貨の購買要求を出力する出力部と、
   前記購買要求に基づき前記仮想通貨を取得する通貨取得部と
   を備え、
   前記付与部は、取得した前記仮想通貨を前記ユーザに付与する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記判定部は、前記ユーザが所定数以上の前記仮想通貨を保有しているか否かを判定し、
   所定数以上の前記仮想通貨を保有していると判定した場合、前記付与部は前記仮想通貨を付与する
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記付与部は、前記ユーザによる前記仮想通貨の保有状況に応じて、該ユーザに付与する前記仮想通貨の数量を変更する
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記付与部は、
   前記支出した金額の一部から所定額を差し引いた金額を算出し、
   該金額に相当する数量の前記仮想通貨を付与する
   ことを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
6. ネットワーク上に投稿する投稿情報を生成するための投稿素材を、支出対象である商品又はサービスに対応付けて記憶する素材記憶部と、
   前記支出情報を取得した場合、該支出情報が示す前記支出対象に対応付けられた前記投稿素材を前記ユーザ宛に出力する素材出力部と、
   前記投稿素材を用いた投稿を行うか否かの選択入力を受け付ける選択部と、
   投稿を行う旨の選択入力を受け付けた場合、前記投稿素材を用いて前記投稿情報を生成し、ネットワーク上に出力する投稿出力部と
   を備えることを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記支出情報を取得した場合、前記判定部は、第１の前記仮想通貨を前記ユーザが保有しているか否かを判定し、
   前記第１の仮想通貨を保有していると判定した場合、前記付与部は、前記第１の仮想通貨と異なる第２の前記仮想通貨を前記ユーザに付与する
   ことを特徴とする請求項１〜６のいずれか１項に記載の情報処理装置。
8. ユーザが所定の支出先に対して支出した金額を示す支出情報を取得し、
   複数のノードに分散して管理される仮想通貨の取引データを参照して、前記ユーザが前記支出先に対応する前記仮想通貨を保有しているか否かを判定し、
   前記仮想通貨を保有していると判定した場合、前記支出した金額に応じた数量の前記仮想通貨を前記ユーザに付与する
   処理をコンピュータに実行させる情報処理方法。
9. ユーザが所定の支出先に対する支出を行った場合において、前記ユーザが前記支出先に対応する仮想通貨を保有している場合、支出した金額に応じた数量の前記仮想通貨を前記支出先から取得し、
   取得した前記仮想通貨の数量を表示部に表示する
   処理をコンピュータに実行させることを特徴とするプログラム。
10. ネットワーク上に投稿する投稿情報を生成するための、前記支出先に対して支出した支出対象に関連した投稿素材を前記支出先から取得して表示し、
    前記投稿素材を用いた投稿を行うか否かの選択入力を受け付け、
    投稿を行う旨が選択された場合、前記投稿素材を用いて前記投稿情報を生成し、ネットワーク上に出力するよう、前記支出先に要求する
    ことを特徴とする請求項９に記載のプログラム。

Images