特開 2021-166044 支援サーバ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2021-166044(P2021-166044A)

(43)【公開日】2021年10月14日

(54)【発明の名称】支援サーバ

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20210917BHJP

   G06Q 40/06 20120101ALI20210917BHJP

【ＦＩ】

   G06Q50/10

   G06Q40/06

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

【全頁数】17

(21)【出願番号】特願2021-64497(P2021-64497)

(22)【出願日】2021年4月5日

(31)【優先権主張番号】特願2020-67247(P2020-67247)

(32)【優先日】2020年4月3日

(33)【優先権主張国】JP

(71)【出願人】

【識別番号】520118854

【氏名又は名称】白倉 重樹

(71)【出願人】

【識別番号】519318351

【氏名又は名称】山下 和彦

(71)【出願人】

【識別番号】512251275

【氏名又は名称】新城 健一

(74)【代理人】

【識別番号】100110560

【弁理士】

【氏名又は名称】松下 恵三

(74)【代理人】

【識別番号】100182604

【弁理士】

【氏名又は名称】長谷川 二美

(72)【発明者】

【氏名】白倉 重樹

(72)【発明者】

【氏名】山下 和彦

(72)【発明者】

【氏名】新城 健一

【テーマコード（参考）】

5L049

5L055

【Ｆターム（参考）】

5L049CC11

5L055BB55

(57)【要約】      （修正有）

【課題】サービス等利用者が経済的な負担を感じることなく感謝の気持ちと共に金銭的な価値をもってサービス等提供者を支援できる支援サーバを提供する。
【解決手段】支援サーバ２００は、ユーザ３が協力企業２との取引を通じて自ら支援金をねん出し、自己の判断で支援先であるボランティア団体１を選ぶ。ボランティア団体１は、支援金により事業を継続すると共に事業の質を向上できる。協力企業２は、受注機会が増え、且つ、それが継続するようになる。ユーザ３及び協力企業２には、金銭的な負担感がないため純粋にボランティア団体１を支援の形で応援できる。ボランティア団体１は、しがらみのない資金を調達可能になる。
【選択図】図１１

【特許請求の範囲】

【請求項1】

第一取引者からサービス又は商品の提供を受けたユーザ３が任意で当該第一取引者に対する支援額を含む感謝を入力する評価手段と、
前記ユーザ３による第二取引者のサービス又は商品の購入に基づいて第一取引者に対する前記支援額を創出する支援処理手段と、
を備えたことを特徴とする支援サーバ。

【請求項2】

ユーザ３が任意の第一取引者を支援先として選択する支援先選択手段と、
前記ユーザ３による第二取引者のサービス又は商品の購入に基づいて第一取引者に対する前記支援額を創出する支援処理手段と、
を備えたことを特徴とする支援サーバ。

【請求項3】

前記ユーザ３に対して、第二取引者と、当該ユーザ３が希望する支援額を満たすための前記第二取引者のサービス又は商品及びその購入額と、をあらかじめ登録してある当該第二取引者のサービス又は商品に関する情報から算出し、表示する発注先情報表示手段を更に有することを特徴とする請求項１又は２に記載の支援サーバ。

【請求項4】

前記支援処理手段は、前記創出した支援額を前記ユーザ３及び第二取引者には還付されないように処理することを特徴とする請求項１〜３のいずれか一つに記載の支援サーバ。

【請求項5】

更に、前記支援先である第一取引者又は前記ユーザ３の端末から活動報告を取得し当該活動報告を掲載可能に処理する活動報告処理手段を有し、
前記支援処理手段は、前記活動報告の有無に基づいて前記第一取引者に対する前記支援額を創出することを特徴とする請求項１〜４のいずれか一つに記載の支援サーバ。

【請求項6】

更に、前記活動報告処理手段は、前記活動報告があるまで創出した支援額を当該第一取引者のために保管することを特徴とする請求項１〜５のいずれか一つに記載の支援サーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サービス等利用者が経済的な負担を感じることなく感謝の気持ちと共に金銭的な価値をもってサービス等提供者を支援できる支援サーバに関するものである。

【背景技術】

【0002】

現在、様々な無料サービスが提供されているが、社会に役に立つサービスやモノになるほど採算をとるのが困難であり、利用者が必要としているにもかかわらず、事業継続が困難になることが多い。このようなサービスに該当するサービスは、困窮者に食事を提供する労働を伴うサービスから無料のＷｅｂサービスまで様々である。不採算のサービスは国や地方公共団体ないしＮＰＯ団体がその運営を担うことが多く、このためサービスの種類が少なく利用者にとっては不便である。

【0003】

また、利用者が当該サービスに大変満足しているために当該サービスを継続してもらいたいと希望しても、利用者が当該サービスを経済的に支援する仕組みが殆ど存在しておらず、利用者は当該サービスの事業継続を願うことしかできなかった。また、経済的支援となると利用者の個人単位では負担が大きすぎて現実的ではないという問題もある。

【0004】

最近では、大量のフリーの利用者の一部を有償サービスに移行させて採算を得る所謂フリービジネスが数多く存在するが、このようなビジネスモデルは現実の人的労働や材料等を必要とするサービスには不向きである。

【0005】

なお、寄付に関するシステムとしては従来から特許文献１に記載されているような発明等が存在する。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２０１５−２１５８４９号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

本発明は、上記のような問題を解決するために創作されたものである。

【課題を解決するための手段】

【0008】

本発明の支援サーバは、第一取引者からサービス又は商品の提供を受けたユーザが任意で当該第一取引者に対する支援額を含む感謝を入力する評価手段と、前記ユーザによる第二取引者のサービス又は商品の購入に基づいて第一取引者に対する前記支援額を創出する支援処理手段と、
を備えたことを特徴とする。

【0009】

本発明の支援サーバは、ユーザが任意の第一取引者を支援先として選択する支援先選択手段と、
前記ユーザによる第二取引者のサービス又は商品の購入に基づいて第一取引者に対する前記支援額を創出する支援処理手段とを備えたことを特徴とする。

【0010】

更に、上記発明において、前記ユーザに対して、第二取引者と、当該ユーザが希望する支援額を満たすための前記第二取引者のサービス又は商品及びその購入額と、をあらかじめ登録してある当該第二取引者のサービス又は商品に関する情報から算出し、表示する発注先情報表示手段を有することを特徴とする。

【0011】

更に、上記発明において、前記支援処理手段は、前記創出した支援額を前記ユーザ及び第二取引者には還付されないように処理することを特徴とする。

【0012】

更に、上記発明において、前記支援先である第一取引者又は前記ユーザ３の端末から活動報告を取得し当該活動報告を掲載可能に処理する活動報告処理手段を有し、前記支援処理手段は、前記活動報告の有無に基づいて前記第一取引者に対する前記支援額を創出することを特徴とする。

【0013】

更に、上記発明において、前記活動報告処理手段は、前記活動報告があるまで創出した支援額を当該第一取引者のために保管することを特徴とする。

【0014】

なお、上記各手段としてコンピュータを動作させるプログラムについても本発明に含まれる。

【図面の簡単な説明】

【0015】

【図1】支援システムを示すハードウエア構成図である。

【図2】支援サーバを示す機能ブロック図である。

【図3】支援サーバの動作を示す相関説明図である。

【図4】支援サーバの支援金ねん出の仕組みを示す説明図である。

【図5】支援サーバの典型的な動作を示すフローチャートである。

【図6】第一取引者の評価画面の一例である。

【図7】支援額の入力画面の一例である。

【図8】発注先のリストの画面の一例である。

【図9】支援サーバの別の動作を示すフローチャートである。

【図10】第一取引者及び支援額の入力画面の一例である。

【図11】この発明の実施の形態２に係る支援システムを示すハードウエア構成図である。

【図12】図１１に示した支援サーバを示す機能ブロック図である。

【図13】支援サーバの動作を示す相関説明図である。

【図14】活動報告の表示画面の例を示す説明図である。

【図15】支援サーバの支援金ねん出の仕組みを示す説明図である。

【図16】支援サーバの典型的な動作を示すフローチャートである。

【図17】支援サーバの別の動作を示すフローチャートである。

【発明を実施するための形態】

【0016】

（実施の形態１）
図１は、支援システムを示すハードウエア構成図である。この支援システムは、支援サービスを提供する支援サーバ１００と、ユーザの端末３と、第一取引者の端末１と、第二取引者の端末２とがインターネット５０を介して接続されて構成される。支援サーバ１００は、複数台のコンピュータで構成されても良いし、クラウドサービスのような支援サービス提供者の所有するものでなくても良い。各端末は、パーソナルコンピュータの他、スマートフォン等でも良い。以下、ユーザの端末３を単に「ユーザ」ということもあり、第一取引者又は第二取引者の端末１，２を単に「第一取引者」又は「第二取引者」ということもある。

【0017】

図２は、支援サーバを示す機能ブロック図である。各機能は、ハードウエアと所定のソフトウェアにより構築される。この支援サーバ１００は、ユーザが第一取引者に感謝の意（「ありがとう」等）により評価を行う評価部１０１と、ユーザが第一取引者を支援するために利用する第二取引者に関する情報を表示する発注先情報表示部１０２と、第二取引者とユーザとの取引により第一取引者に支援処理を行う支援処理部１０３と、第一取引者及び第二取引者並びにユーザ等を登録する登録部１０４と、第二取引者からの入金を管理する入金管理部１０５とから構成される。

【0018】

前記発注先情報表示部１０２は、入力された支援額を満たすために必要な購入額を登録された商品、サービスごとに計算する計算部１０６を有する。前記支援処理部１０３は、ユーザが第一取引者を支援したい額を入力する支援額入力部１０７、ユーザが保有する支援可能な額（保有額）を記憶する保有額記憶部１０８、第二取引者との取引情報を取得する取引情報取得部１０９、この取引情報取得部１０９の情報から保有額を集計する保有額集計部１１０、第二取引者２に発注うを行う発注部１１１を有する。

【0019】

図３は、支援サーバの動作を示す相関説明図である。第一取引者１は、ユーザ３にサービスを提供する事業者である。サービスは、無料でも有料でも良いが、以下は無料サービスを前提に説明するものとする。当該サービスの種類は問わない。例えば、Ｗｅｂサービスでも良いし、人的労働や原価を必要とするサービスでも良い。更に、第一取引者１が提供するサービスは第三者１ａに委託される場合を含む。更に、第一取引者１は、モノを提供する事業者であっても良い。例えば、無料で物品や食料等を配布する事業者でも良い。

【0020】

第二取引者２は、定期購買に係る事業を行う事業者である。定期購買としたのは日用品等の常に必要となる商品やサービスから支援の財源を得るのがユーザ３にとってハードルが低いためである。定期購買は、トイレットペーパー、洗剤等の家庭で用いる日用品や、電力、ガス、水道等の公共インフラ系サービス、新聞、携帯電話、インターネットプロバイダー等の多くの家庭で契約がなされているサービス、スポーツクラブ、塾、習い事等の長期にわたり利用するサービス等が典型的に該当する。

【0021】

また、第二取引者２は、高額商品やサービスを取り扱う事業者であっても良い。例えば自動車、音響機器、海外旅行、結婚式、葬式等に関する事業を行う事業者である。

【0022】

ユーザ３は、第一取引者１及び第二取引者２の両方を利用する者である。個人でも法人でも良い。ユーザ３が利用する順は、第一取引者１が先でも第二取引者２が先でも良い。ユーザ３が利用する第一取引者１及び第二取引者２は複数でも良い。

【0023】

登録部１０４には、少なくとも、第一取引者１、第二取引者２及びユーザ３に関する基本情報（会社名や住所等）、第一取引者１、第二取引者２が取り扱う商品及びサービスの内容及び対価等に関する情報が登録される。

【0024】

支援サーバ１００の動作概要を説明する。第一取引者１、第二取引者２及びユーザ３は、登録部１０４に登録することで、支援サーバ１００の提供する支援サービスを利用可能となる。ユーザ３は、登録した事業者（第一取引者１）から所定のサービスを受けた結果、大変満足し、このサービスを提供した第一取引者１に満足、感謝、好意を表すものとする（以下、これらを「感謝」という。）。このとき、ユーザ３は、感謝の印として金銭またはポイント（以下、「支援金」という）を提供することを希望するものとする。支援サーバ１００は、定期購買等の事業を行う事業者（第二取引者２）との取引から支援金をねん出してこれを第一取引者１に送る。ユーザ３が第二取引者２との取引と無関係に自己の資金で支援金を送るのものではない。なお、サーバ上でやり取りされる支援金は、現金ではなくコンピュータ上で通信される換金可能な情報である。

【0025】

この支援サーバ１００によれば、ユーザ３は、心理的にも金銭的にも負担がないため第一取引者１への感謝を素直に表すことができる。第一取引者１は、当該支援金により事業を継続できる。特に無料サービス又は採算性の悪いサービスは事業継続が困難になることが多いところ、支援金が入るようになれば事業に継続性が生まれると共にその反射的効果としてユーザ３も継続的に当該サービスを受けられるようになる。第二取引者２は、本支援サービスの趣旨に賛同することでユーザ３から新規の発注が得られる可能性が高くなる。また、第一取引者１に支援金を送ることで第一取引者１のサービスが継続され或いはより充実したものとなり、ユーザ３の評価を高め、その結果、ユーザ３からの第二取引者２への発注がさらに増大する。このように、この支援サーバ１００は、当該支援サーバ１００を利用するすべての者に利益をもたらすものとなる。

【0026】

また、ユーザ３は、第一取引者１から受けたサービスや商品に満足しなかった場合等は、感謝の意思を表示する必要はない。この場合、第一取引者１は支援金を得ることはできない。支援するか否かの決定はあくまでユーザ３の任意であり強制ではない。この場合、第二取引者２との取引によりねん出される支援金は第一取引者１と関連付けて保持され、ユーザ３や第二取引者２に還付されることはない。即ち、この支援金は第一取引者１を支援する用途以外には原則使用できない。例外的に、保管期限を過ぎる等の一定条件を満たした支援金は、支援サーバ１００が予め登録している団体や個人に寄付される。または、支援サーバ１００が所定の手順に従って選定した第一取引者１に送ることができる。このように、ユーザ３及び第二取引者２は、自己のために支援金を使用できないことから、経済的な利害によらず純粋に第一取引者１に感謝を表すことができる。また、ユーザ３及び第二取引者２は、第一取引者１に支援金を送った場合でも余計な出費をした気持ちになることがない。このようなことから、本支援サーバ１００によれば、利害のない純粋な財源をユーザ３自身が生み出して、これを役立てることができる。

【0027】

また、上記では、ユーザ３が第一取引者１から所定のサービスの提供を受けて感謝した結果として支援を行うものとしたが、ユーザ３が第一取引者１からのサービスを受けていなくても当該第一取引者１を支援したいと希望することがある。このような場合でも、第二取引者２との取引から支援金をねん出してこれを第一取引者１に送ることができる。なお、本願ではユーザ３その他の者との取引がなくとも取引予定者として「第一取引者１」と称する。

【0028】

この支援手順は、第一取引者１のサービスが事業として開始されていない場合に特に有効である。例えば、事業化することで当該事業が社会のためになり大きく発展するものとユーザ３が判断した場合、その事業を行う第一取引者１に資金を提供できる。第一取引者１から見ると、良いサービス事業を計画または準備することで、この支援サーバ１００を通じて資金を調達できる。この資金は融資でも投資でもない資金であるため、第一取引者１は制約が少ない形で事業を行うことができる。

【0029】

図４は、支援サーバの支援金ねん出の仕組みを示す説明図である。ユーザ３が第二取引者２との間でサービスや商品の購入をした場合、この購入代金は支援サーバ１００の入金管理部１０５に対してユーザ３から支払い処理がなされると共にその一部が支援金として保持される。購入代金から支援金を差し引いた金額が支援サーバ１００の入金管理部１０５から第二取引者２に支払われる。支援金は、購入代金に一定の割合を乗じた額でも良いし、固定額としても良い。

【0030】

ユーザ３が第一取引者１に対して支払いを指示した場合、支援処理部１０３は指定された額の支援金を第一取引者１に支払う。支援金が一定期間支払いの指示がされない状態にあると、支援処理部１０３は、例えば次のような処理ができる。１）支援サーバ１００が予め指定している第三者（公共性の高い組織等）に寄付を行う。２）ユーザ３からの感謝の数が多い第一取引者１に対して支援金を支払う。３）支援サーバ１００の運営者に支払いを行う。

【0031】

図５は、支援サーバの典型的な動作を示すフローチャートである。ユーザ３は、第一取引者１から所望のサービスを受けて満足した場合、ユーザ３は、支援システムにログインし、評価部１０１において第一取引者１のサービスに対して感謝を表す（ステップＳ１）。感謝するか否かは、ユーザ３の任意である。感謝しない場合は、このまま終了する。図６は、評価部により第一取引者１への感謝を入力する画面の一例である。ユーザ３は、支援サーバ１００にログインして当該画面上から感謝の有無、支援の有無をクリックして選択する。

【0032】

感謝は、経済的支援を伴う必要はない。換言すれば「ありがとう」「いいね」の文字情報だけでも良い。支援しない場合は、このまま終了する。ユーザ３が、その第一取引者１を支援したいと考えた場合、支援額入力部１０７に支援額を入力する（ステップＳ２）。図７は、支援額入力部１０７により表示した支援額の入力画面の一例である。ユーザ３は、画面上で前記第一取引者１を支援する支援額を入力する。このとき、保有額記憶部１０８により、当該ユーザ３が支援可能な額（保有額）も併せて画面に表示される。

【0033】

支援処理部１０３は、入力した支援額が当該ユーザ３が支援サーバ上で保有する保有額以下である場合（ステップＳ３）、支援額の支払い処理を実行する（ステップＳ４）。なお、保有額集計部１１０は、支援が可能な額を第二取引者２との取引情報に基づいて集計し、保有額記憶部１０８に記憶している。一方、支援処理部１０３は、入力した支援額が当該ユーザ３が支援サーバ上で保有する保有額を超えている場合（ステップＳ３）、第二取引者２に対して新たな取引を発注する必要があるため、発注先情報表示部１０２により発注先のリストがユーザ３に対して表示される（ステップＳ５）。

【0034】

前記発注先のリストは、登録されている第二取引者２の取り扱う商品及びサービスごとに、計算部１０６が必要な支援額に対して必要な購入額を計算する。例えば、第一取引者１に１０００円の支援を行う場合において、保有額が５００円しかないためもう５００円不足する場合には、当該５００円を支援するには第二取引者２の特定の商品を１年間の合計で１００００円分購入する必要があることを計算する。計算結果として当該特定商品と必要購入額が表示される。図８は、発注先情報表示部１０２が表示する発注先のリストの画面の一例である。このように、希望する支援額の支援を行うのに必要な当該特定商品と必要購入額がリストで表示される。

【0035】

ユーザ３は、発注部１１１により、多数表示された商品及びサービスの中から任意の商品及びサービスを選択し（ステップＳ６）、当該選択した商品を発注する（ステップＳ７）。保有額集計部１１０は、この発注情報に基づいてねん出した支援額を保有額として集計し、保有額記憶部１０８に記憶する。続いて、支援処理部１０３は、前記購入により保有額が支援額を超えているか判断する（ステップＳ８）。超えていない場合は、追加で商品又はサービスを選択するステップに戻る（ステップＳ５）。購入により保有額が支援額を超えた場合、支援処理部１０３は、支援額の支払い処理を実行する（ステップＳ９）。

【0036】

上記で支払い処理がなされた場合、第一取引者１は支援金を受領する（ステップＳ１０）。受領方法は口座振り込みやポイント付与等の予め定めた任意の手段で行う。

【0037】

図９は、支援サーバの別の動作を示すフローチャートである。上記図５に示した処理手順と略同じであるが、ユーザ３が第一取引者１のサービス提供を受けることなく、当該第一取引者１に対して支援を行う点が異なる。以下、異なる手順について説明し、同様の処理手順については説明を省略する。

【0038】

ユーザ３は、支援サーバ１００の支援先選択部２０１により支援金による支援先を選択する（ステップＳ９１）。ユーザ３は、特定の第一取引者１と取引がない状態でも当該第一取引者１を支援できる。ユーザ３の指示により、支援先選択部２０１は特定の第一取引者１を選択する。選択にあたり、例えば、第一取引者１を入力すると共に支援額を入力する画面を支援処理部１０３がユーザ３の端末に表示する。図１０に画面の入力例を示す。この画面上でユーザ３は所望の第一取引者１を入力すると共に当該第一取引者１に対する支援額を入力する。

【0039】

続いて、支援処理部１０３は、保有額記憶部１０８に記憶している保有額を参照して支払いが可能か否かを判断し（ステップＳ３）、可能であれば当該第一取引者１に支援金を支払う（ステップＳ４）。不足している場合は、上記ステップＳ５以降の処理に従い、最終的に支払い処理を行う。

【0040】

以上、この支援サーバ１００によれば、ユーザ３が第二取引者２との取引を通じて自ら支援金をねん出し、自己の判断で支援先である第一取引者１を選び、第一取引者１は支援金により事業を継続すると共に事業の質を向上できる。また、第二取引者２は受注機会が増え且つそれが継続するようになる。ユーザ３及び第二取引者２には金銭的な負担感がないため純粋に第一取引者１を支援の形で応援できる。第一取引者１はしがらみのない資金を調達可能になる。そして、ユーザ３が第一取引者１又は第二取引者２になることもあれば、第一取引者１がユーザ３又は第二取引者２になることもあれば、第二取引者２がユーザ３又は第一取引者１になることもある。支援サーバ１００を利用する者すべてに利益をもたらすことができ、好循環を形成できる。

【0041】

（実施の形態２）
次に具体的なステークホルダを設定してこの発明の他の実施の形態を説明する。図１１は、この発明の実施の形態２に係る支援システムを示すハードウエア構成図である。この支援システムは、支援サービスを提供する支援サーバ２００と、ユーザの端末３と、ボランティア団体の端末１と、協力企業の端末２と、一般者の端末４とがインターネット５０を介して接続されて構成される。支援サーバ２００は、複数台のコンピュータで構成されても良いし、クラウドサービスのような支援サービス提供者（以下「管理者」という）の所有するものでなくても良い。各端末は、パーソナルコンピュータの他、スマートフォン等でも良い。以下、ボランティア団体の端末１を単に「ボランティア団体１」又といい、一般者の端末４を「一般者４」ということもある。

【0042】

図１２は、図１１に示した支援サーバを示す機能ブロック図である。各機能は、ハードウエアと所定のソフトウェアにより構築される。この支援サーバ２００は、ユーザ３がボランティア団体１に感謝の意により評価を行う評価部１０１と、ユーザ３がボランティア団体１を支援するために利用する協力企業２に関する情報を表示する発注先情報表示部１０２と、協力企業２とユーザとの取引によりボランティア団体１に支援処理を行う支援処理部１０３と、ボランティア団体１及び協力企業２並びにユーザ３等を登録する登録部１０４と、協力企業２からの入金を管理する入金管理部１０５と、ボランティア団体１の活動報告に関する情報を処理する活動報告処理部３０１と、から構成される。

【0043】

前記発注先情報表示部１０２は、入力された支援額を満たすために必要な購入額を登録された商品、サービスごとに計算する計算部１０６を有する。前記支援処理部１０３は、ユーザ３がボランティア団体１を支援したい額を入力する支援額入力部１０７、ユーザ３が保有する支援可能な額（保有額）を記憶する保有額記憶部１０８、協力企業２との取引情報を取得する取引情報取得部１０９、この取引情報取得部１０９の情報から保有額を集計する保有額集計部１１０、協力企業２２に発注を行う発注部１１１を有する。

【0044】

図１３は、支援サーバの動作を示す相関説明図である。ボランティア団体１は、ユーザ３にサービスを提供する事業者又は個人である。ボランティア団体１が提供するサービスは第三者１ａに委託される場合を含む。更に、ボランティア団体１は、モノを提供する事業者であっても良い。例えば、無料で物品や食料等を配布する事業者又は個人でも良い。

【0045】

協力企業２は、定期購買に係る事業を行う事業者である。定期購買としたのは日用品等の常に必要となる商品やサービスから支援の財源を得るのがユーザ３にとってハードルが低いためである。定期購買は、トイレットペーパー、洗剤等の家庭で用いる日用品や、電力、ガス、水道等の公共インフラ系サービス、新聞、携帯電話、インターネットプロバイダー等の多くの家庭で契約がなされているサービス、スポーツクラブ、塾、習い事等の長期にわたり利用するサービス等が典型的に該当する。

【0046】

また、協力企業２は、高額商品やサービスを取り扱う事業者であっても良い。例えば自動車、音響機器、海外旅行、結婚式、葬式等に関する事業を行う事業者である。ユーザ３は、少なくとも協力企業２を利用する者である。ボランティア団体１を利用する者であっても良い。また、個人でも法人でも良い。ユーザ３が利用する順は、ボランティア団体１が先でも協力企業２が先でも良い。ユーザ３が利用するボランティア団体１及び協力企業２は複数でも良い。

【0047】

一般者４は、ボランティア団体１、協力企業２及びユーザ３として登録される可能性がある者である。管理者５０は、支援サーバ２００を管理する者である。

【0048】

登録部１０４には、少なくとも、ボランティア団体１、協力企業２及びユーザ３に関する基本情報（会社名や住所等）、ボランティア団体１、協力企業２が取り扱う商品及びサービスの内容及び対価等に関する情報が登録される。

【0049】

支援サーバ２００の動作概要を説明する。ボランティア団体１、協力企業２及びユーザ３は、登録部１０４に登録することで、支援サーバ２００の提供する支援サービスを利用可能となる。一般者４は、登録しなくても所定の範囲のみを利用ないし閲覧可能である。ユーザ３は、登録した事業者（ボランティア団体１）から所定のサービスを受けた結果、大変満足し、このサービスを提供したボランティア団体１に感謝を表すものとする。このとき、ユーザ３は、感謝の印として支援金を提供することを希望するものとする。支援サーバ２００は、定期購買等の事業を行う事業者（協力企業２）との取引から支援金をねん出してこれをボランティア団体１に送る。ユーザ３が協力企業２との取引と無関係に自己の資金で支援金を送るのものではない。なお、サーバ上でやり取りされる支援金は、現金ではなくコンピュータ上で通信される換金可能な情報である。

【0050】

ボランティア団体１は、送られた支援金を受け取るためには活動報告を行う必要がある。活動報告は、ボランティア団体１の活動を写真や文章で表したものである。活動報告の内容は管理者５０が確認したうえで掲載するものとする。活動報告を必要とするのは実体のないボランティア団体１に支援金が渡るのを防止するためである。

【0051】

ボランティア団体１の活動報告は、ボランティア団体の端末１から活動報告処理部３０１に送信され投稿される。活動報告処理部３０１は、投稿された活動報告について掲載前に承認要求を管理者５０の確認可能な支援サーバ２００の画面等に表示させる。管理者５０は、承認要求に応じて投稿された活動報告を閲覧する。閲覧したうえで活動報告の内容が適正であると判断した場合、画面上の承認ボタン（図示省略）を押して承認する。これにより、活動報告処理部３０１は、活動報告が協力企業２及びユーザ３に閲覧可能な状態とする。

【0052】

また、活動報告は、一般者の端末４からも閲覧可能である。一般者４に公開することで当該活動に賛同した者がユーザ３、協力企業２又はボランティア団体１として登録される可能性が生じる。

【0053】

図１４は、活動報告の表示画面の例を示す説明図である。活動報告３５０は、活動内容を撮影した画像３５１、動画３５１と文章３５２により構成される。活動報告３５０が継続的に行われている場合、支援金を継続的に受領できる。活動報告処理部３０１は、一定期間のうち所定回数の活動報告がなされた場合に支援金を支払う条件を設定できる。活動実績があるボランティア団体１に支援金を支払うようにするためである。

【0054】

また、ユーザ３が感謝の意を表示した場合にはユーザ３がサービスを受けた蓋然性が高いことから活動実績が推測されるが、その場合でも前記活動報告３５０を支援金の受領の条件とすることができる。

【0055】

活動報告３５０は、ユーザ３側からも提供できる。ユーザ３は、ユーザの端末３からの活動報告を支援サーバ２００に投稿する。活動報告処理部３０１は、投稿された活動報告３５０について掲載前に承認要求を管理者５０との画面等のインターフェースに表示させる。管理者５０は、承認要求に応じて投稿された活動報告３５０を閲覧する。閲覧したうえで活動報告３５０の内容が適正であると判断した場合、画面上の承認ボタン（図示省略）を押して承認する。これにより、活動報告３５０がボランティア団体１、協力企業２及びユーザ３に閲覧可能な状態とされる。

【0056】

ユーザ３からの活動報告３５０の掲載を可能としたのは、ユーザ３の目線でボランティア団体１が行うサービスを説明することができるためである。ユーザ３からの投稿を承認なしに掲載するとボランティア団体１への誹謗中傷等の悪意のある内容が掲載される可能性があることから、管理者５０が不適切な内容については掲載しないようにするため、管理者５０の承認が必要となる。

【0057】

この支援サーバ２００によれば、ユーザ３は、心理的にも金銭的にも負担がないためボランティア団体１への感謝を素直に表すことができる。ボランティア団体１は、当該支援金により事業を継続できる。特に無料サービス又は採算性の悪いサービスは事業継続が困難になることが多いところ、支援金が入るようになれば事業に継続性が生まれると共にその反射的効果としてユーザ３も継続的に当該サービスを受けられるようになる。協力企業２は、本支援サービスの趣旨に賛同することでユーザ３から新規の発注が得られる可能性が高くなる。また、ボランティア団体１に支援金を送ることでボランティア団体１のサービスが継続され或いはより充実したものとなり、ユーザ３の評価を高め、その結果、ユーザ３からの協力企業２への発注がさらに増大する。このように、この支援サーバ２００は、当該支援サーバ２００を利用するすべての者に利益をもたらすものとなる。

【0058】

ユーザ３は、ボランティア団体１から受けたサービスや商品に満足しなかった場合等は、感謝の意思を表示する必要はない。この場合、ボランティア団体１は支援金を得ることはできない。支援するか否かの決定はあくまでユーザ３の任意であり強制ではない。この場合、協力企業２との取引によりねん出される支援金はボランティア団体１と関連付けて保持され、ユーザ３や協力企業２に還付されることはない。即ち、この支援金はボランティア団体１（すでにサービス等を受けたボランティア団体１及び将来的にユーザ３がサービスを受けるであろうボランティア団体１を含む）を支援する用途以外には原則使用できない。例外的に、保管期限を過ぎる等の一定条件を満たした支援金は、支援サーバ２００が予め登録している団体や個人に寄付される。

【0059】

又は、支援サーバ２００が所定の手順に従って選定し且つ支援サーバ２００に登録したボランティア団体１に送ることができる。例えば、支援金が恒常的に不足している分野に属するボランティア団体１のうち管理者５０が選定し且つ登録部１０４に登録した任意のボランティア団体１に送られる。このように、ユーザ３及び協力企業２は、自己のために支援金を使用できないことから、経済的な利害によらず純粋にボランティア団体１に感謝を表すことができる。また、ユーザ３及び協力企業２は、ボランティア団体１に支援金を送った場合でも余計な出費をした気持ちになることがない。このようなことから、本支援サーバ２００によれば、利害のない純粋な財源をユーザ３自身が生み出して、これを役立てることができる。

【0060】

また、上記では、ユーザ３がボランティア団体１から所定のサービスの提供を受けて感謝した結果として支援を行うものとしたが、ユーザ３がボランティア団体１からのサービスを受けていない場合やこれから活動が開始される場合にも当該ボランティア団体１を支援したいと希望することがある。このような場合でも、協力企業２との取引から支援金をねん出してこれをボランティア団体１に送ることができる。

【0061】

この支援手順は、ボランティア団体１のサービスが事業として開始されていない場合に特に有効である。例えば、事業化することで当該事業が社会のためになり大きく発展するものとユーザ３が判断した場合、その事業を行うボランティア団体１に資金を提供できる。ボランティア団体１から見ると、良いサービス事業を計画または準備することで、この支援サーバ２００を通じて資金を調達できる。この資金は融資でも投資でもない資金であるため、ボランティア団体１は制約が少ない形で事業を行うことができる。この場合、活動報告は不要とし、事業計画等が掲載される。更に、支援金は一括で支払われず、一時的に支援サーバ２００の管理者５０が保管する。合理的な初期費用が最初に支払われ、その後、当該ボランティア団体１の活動報告がなされるたびに保管してある支援金から分割されて支払われるものとする。これにより、事業計画のみで支援金を受領して実際には活動しない事業者を排除できる。

【0062】

図１５は、支援サーバの支援金ねん出の仕組みを示す説明図である。ユーザ３が協力企業２との間でサービスや商品の購入をした場合、この購入代金は支援サーバ２００の入金管理部１０５に対してユーザ３から支払い処理がなされると共にその一部が支援金として保持される。購入代金から支援金を差し引いた金額が支援サーバ２００の入金管理部１０５から協力企業２に支払われる。支援金は、購入代金に一定の割合を乗じた額でも良いし、固定額としても良い。

【0063】

ユーザ３がボランティア団体１に対して支払いを指示した場合、支援処理部１０３は指定された額の支援金をボランティア団体１に支払う。この際、ボランティア団体１に活動実態があるか否かを確認する。具体的には上記活動報告３５０に基づいて行うものとする。支援金が一定期間支払いの指示がされない状態にあると、支援処理部１０３は、例えば次のような処理ができる。１）支援サーバ２００が予め指定している第三者（公共性の高い組織等）又は特定の分野に属するボランティア団体１に寄付を行う。２）ユーザ３からの感謝の数が多いボランティア団体１に対して支援金を支払う。３）支援サーバ２００の運営者に支払いを行う。

【0064】

一般者４は、自己の端末４からこれらの支援状況を支援サーバ２００に対して表示要求をすることで閲覧できる。一般者４は、ユーザ３、協力企業２、ボランティア団体１として登録する可能性があることから、必要十分な情報が閲覧できるようにする。

【0065】

図１６は、支援サーバの典型的な動作を示すフローチャートである。ユーザ３は、ボランティア団体１から所望のサービスを受けて満足した場合、支援サーバ２００にログインし、評価部１０１においてボランティア団体１のサービスに対して感謝を表す（ステップＳ１）。感謝するか否かは、ユーザ３の任意である。感謝しない場合は、このまま終了する。

【0066】

感謝は、経済的支援を伴う必要はない。換言すれば「ありがとう」「いいね」の文字情報だけでも良い。支援しない場合は、このまま終了する。ユーザ３が、そのボランティア団体１を支援したいと考えた場合、支援額入力部１０７に支援額を入力する（ステップＳ２）。

【0067】

支援処理部１０３は、入力した支援額が、当該ユーザ３が支援サーバ上で保有する保有額以下である場合（ステップＳ３）、活動報告処理部３０１により当該ボランティア団体１の活動実績を確認する（ステップＳ２０１）。具体的には、複数の活動報告３５０が一定期間（例えば三か月間）に行われているか否かを確認する。そして、活動実績が認められる場合（投稿された活動報告の数をカウントする等）、支援額の支払い処理を実行する（ステップＳ４）。

【0068】

なお、保有額集計部１１０は、支援が可能な額を協力企業２との取引情報に基づいて集計し、保有額記憶部１０８に記憶している。一方、支援処理部１０３は、入力した支援額が当該ユーザ３が支援サーバ上で保有する保有額を超えている場合（ステップＳ３）、協力企業２に対して新たな取引を発注する必要があるため、発注先情報表示部１０２により発注先のリストがユーザ３に対して表示される（ステップＳ５）。

【0069】

前記発注先のリストは、登録されている協力企業２の取り扱う商品及びサービスごとに、計算部１０６が必要な支援額に対して必要な購入額を計算する。例えば、ボランティア団体１に１０００円の支援を行う場合において、保有額が５００円しかないためもう５００円不足する場合には、当該５００円を支援するには協力企業２の特定の商品を１年間の合計で１００００円分購入する必要があることを計算する。計算結果として当該特定商品と必要購入額が表示される。図８は、発注先情報表示部１０２が表示する発注先のリストの画面の一例である。このように、希望する支援額の支援を行うのに必要な当該特定商品と必要購入額がリストで表示される。

【0070】

ユーザ３は、発注部１１１により、多数表示された商品及びサービスの中から任意の商品及びサービスを選択し（ステップＳ６）、当該選択した商品を発注する（ステップＳ７）。保有額集計部１１０は、この発注情報に基づいてねん出した支援額を保有額として集計し、保有額記憶部１０８に記憶する。続いて、支援処理部１０３は、前記購入により保有額が支援額を超えているか判断する（ステップＳ８）。超えていない場合は、追加で商品又はサービスを選択するステップに戻る（ステップＳ５）。購入により保有額が支援額を超えた場合、支援処理部１０３は、活動報告３５０の確認処置（ステップＳ２０１）および支援額の支払い処理を実行する（ステップＳ９）。

【0071】

上記で支払い処理がなされた場合、ボランティア団体１は支援金を受領する（ステップＳ１０）。受領方法は口座振り込みやポイント付与等の予め定めた任意の手段で行う。

【0072】

図１７は、支援サーバの別の動作を示すフローチャートである。上記図１６に示した処理手順と略同じであるが、ボランティア団体１が設立前等の場合で未だサービス提供を行っていないときにも、当該ボランティア団体１に対して支援を行う点が異なる。以下、異なる手順について説明し、同様の処理手順については説明を省略する。

【0073】

ユーザ３は、ボランティア団体１の事業計画等を閲覧する（ステップＳ２５０）。そして、ユーザ３は、支援サーバ２００の支援先選択部２０１により支援金による支援先を選択する（ステップＳ２５１）。ユーザの端末３からの指示により、支援先選択部２０１は特定のボランティア団体１を選択する。選択にあたり、例えば、ボランティア団体１を入力すると共に支援額を入力する画面を支援処理部１０３がユーザの端末３に表示させる。

【0074】

続いて、支援処理部１０３は、保有額記憶部１０８に記憶している保有額を参照して支払いが可能か否かを判断する（ステップＳ３）。活動報告処理部３０１は、ボランティア団体１の事業計画が管理者５０により承認されているか否かを確認する（ステップＳ２５２）。ボランティア団体１は、予め事業計画や活動予定が表示されたＵＲＬを支援サーバ２００に送信し、管理者５０による承認を得ておく。支援処理部１０３に支援可能を示す場合は当該ボランティア団体１に支援金を支払う（ステップＳ４）。不足している場合は、上記ステップＳ５以降の処理に従い、最終的に支払い処理を行う。

【0075】

この場合、支払処理がなされた支援金はいったん支援サーバ２００により保管される（ステップＳ２５３）。支援サーバ２００は、支払先が指定されている当該ボランティア団体１以外に当該支援金を送ることはできない。支援処理部１０３は、分野ごとに合理的と考えられる範囲の初期費用について当該ボランティア団体１に最初の支払いを行う（ステップＳ２５４）。例えば、法人設立の費用や備品の購入費用であって平均的な額の範囲で支援額を自動的に計算するものとする。

【0076】

次に、活動報告処理部３０１は、当該ボランティア団体１から活動報告３５０が投稿された場合（ステップＳ２５５）、保管された支援金から順次支払いを行う（ステップＳ２５６）。例えば、活動報告が一定期間の間に複数回行われ、各活動報告が管理者５０により承認された場合、保管した支援金の一部または全部を支払うものとする。結局活動が行われなかった場合、支払を中止する（ステップＳ２５７）。これにより、活動することなく事業計画のみで支援金が支払われるのを防止する。

【0077】

保管された支援金は、当該ボランティア団体１が活動しない場合、支援処理部１０３により例えば次のような処理ができる。１）支援サーバ２００が予め指定している第三者（公共性の高い組織等）又は特定の分野に属するボランティア団体１に寄付を行う。２）ユーザ３からの感謝の数が多いボランティア団体１に対して支援金を支払う。３）支援サーバ２００の運営者に支払いを行う。

【0078】

以上、この支援サーバ２００によれば、実施の形態１と同様の作用効果を奏する他、活動実績のあるボランティア団体１に支援金を支払うことになるので、支援金を有効に使用できる。また、一般者４が閲覧可能となることから、ユーザ３、協力企業２又はボランティア団体１として登録される可能性が得られる。

【0079】

なお、上記実施の形態において支払う通貨は仮想通貨であってもよい。この場合、ブロックチェーン技術により仮想通貨の取引が運用され、上記支援サーバやユーザ３の端末はブロックチェーン技術でいう各ノードを構成するものとなる。

【符号の説明】

【0080】

１００ 支援サーバ
１０１ 評価部
１０２ 発注先情報表示部
１０３ 支援処理部
１０４ 登録部
１０５ 入金管理部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】