図面 (/)

技術 情報処理装置

出願人 株式会社Relic
発明者 北嶋貴朗大庭亮大丸徹也
出願日 2016年2月2日 (3年5ヶ月経過) 出願番号 2016-018284
公開日 2017年8月10日 (1年11ヶ月経過) 公開番号 2017-138732
状態 特許登録済
技術分野 特定用途計算機
主要キーワード 利用リクエスト 支援金 次流通 非会員ユーザ チケットコード 譲渡情報 残り日数 チケットデータベース
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年8月10日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

クラウドファンディングの普及を促進する。

解決手段

クラウドファンディングの会員であるユーザを識別するユーザ識別情報と、クラウドファンディングのプロジェクトを識別するプロジェクト識別情報とを記憶する記憶装置アクセス可能情報処理装置は、第1ユーザの指示に応じて、第1ユーザを識別する第1ユーザ識別情報と、プロジェクト識別情報とに、プロジェクトへの支援金額を示す情報を関連付けて記憶する手段と、第1ユーザ識別情報に、プロジェクトへの支援に対する報酬を受け取る権利を識別するチケット識別情報を関連付けて記憶する手段と、第1ユーザからの指示に応じて、第1ユーザ識別情報とチケット識別情報との関連付けを解除し、かつ、第1ユーザによって指定された第2ユーザを識別する第2ユーザ識別情報にチケット識別情報を関連付けて記憶する手段と、を備える。

概要

背景

近年、ウェブ上でショッピングを行うことができるイーコマースとは別に、クラウドファンディングと呼ばれるサービスが普及してきている。
クラウドファンディングとは、インターネットを介して、プロジェクト(例えば、新商品を開発するプロジェクト)に対して支援者援助した資金を、プロジェクトを作成したプロジェクト作成者に提供する仕組みのことである。

特に、購入型のクラウドファンディングでは、プロジェクト作成者が支援者に対して、プロジェクトへの支援に対する報酬(例えば、開発された新商品)を送る(例えば、非特許文献1を参照)。購入型のクラウドファンディングは、一定の金額支払ったことに対する報酬を受け取ることができるという点において、イーコマースと類似している。

概要

クラウドファンディングの普及を促進する。クラウドファンディングの会員であるユーザを識別するユーザ識別情報と、クラウドファンディングのプロジェクトを識別するプロジェクト識別情報とを記憶する記憶装置アクセス可能情報処理装置は、第1ユーザの指示に応じて、第1ユーザを識別する第1ユーザ識別情報と、プロジェクト識別情報とに、プロジェクトへの支援の金額を示す情報を関連付けて記憶する手段と、第1ユーザ識別情報に、プロジェクトへの支援に対する報酬を受け取る権利を識別するチケット識別情報を関連付けて記憶する手段と、第1ユーザからの指示に応じて、第1ユーザ識別情報とチケット識別情報との関連付けを解除し、かつ、第1ユーザによって指定された第2ユーザを識別する第2ユーザ識別情報にチケット識別情報を関連付けて記憶する手段と、を備える。

目的

クラウドファンディングとは、インターネットを介して、プロジェクト(例えば、新商品を開発するプロジェクト)に対して支援者が援助した資金を、プロジェクトを作成したプロジェクト作成者に提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

クラウドファンディング会員であるユーザを識別するユーザ識別情報と、前記クラウドファンディングのプロジェクトを識別するプロジェクト識別情報とを記憶する記憶装置アクセス可能情報処理装置であって、第1ユーザの指示に応じて、前記第1ユーザを識別する第1ユーザ識別情報と、前記プロジェクト識別情報とに、前記プロジェクトへの支援金額を示す情報を関連付けて記憶する第1関連付け手段と、前記第1ユーザ識別情報に、前記プロジェクトへの支援に対する報酬を受け取る権利を識別するチケット識別情報を関連付けて記憶する第2関連付け手段と、前記第1ユーザからの指示に応じて、前記第1ユーザ識別情報と前記チケット識別情報との関連付けを解除し、かつ、前記第1ユーザによって指定された第2ユーザを識別する第2ユーザ識別情報に前記チケット識別情報を関連付ける第3関連付け手段と、を備える、情報処理装置。

請求項2

前記第3関連付け手段は、前記第2ユーザの指示に応じて、前記第2ユーザ識別情報と前記チケット識別情報との関連付けを解除し、かつ、前記第2ユーザによって指定された第3ユーザを識別する第3ユーザ識別情報に前記チケット識別情報を関連付けて記憶する、請求項1に記載の情報処理装置。

請求項3

前記第3関連付け手段による処理が実行される度に、前記チケット識別情報に、前記指示を与えたユーザを識別するユーザ識別情報と、前記指示を与えたユーザによって指定されたユーザを識別するユーザ識別情報との組合せを関連付けて記憶する第4関連付け手段をさらに備える、請求項1又は2に記載の情報処理装置。

請求項4

前記チケット識別情報に関連付けられたユーザ識別情報によって識別されるユーザであるチケットオーナの指示に応じて、前記チケットオーナ以外のユーザが前記報酬を受け取る権利を譲り受けるために必要な譲渡情報印刷された紙チケット発行する発行手段をさらに備える、請求項1〜3の何れかに記載の情報処理装置。

請求項5

前記チケットオーナ以外のユーザによって、前記発行手段によって発行された紙チケットに印刷された譲渡情報が入力された場合、前記チケットオーナを識別するユーザ識別情報と前記チケット識別情報との関連付けを解除し、かつ、前記譲渡情報を入力したユーザを識別するユーザ識別情報に前記チケット識別情報を関連付けて記憶する第5関連付け手段をさらに備える、請求項4に記載の情報処理装置。

請求項6

前記第5関連付け手段が前記チケットオーナを識別するユーザ識別情報と前記チケット識別情報との対応付けを解除してから、前記第5関連付け手段が前記譲渡情報を入力したユーザを識別するユーザ識別情報に前記チケット識別情報を関連付けて記憶するまでの間、前記チケットを利用できない状態にする手段をさらに備える、請求項4又は5に記載の情報処理装置。

技術分野

0001

本発明は、クラウドファンディングに用いられる情報処理装置に関する。

背景技術

0002

近年、ウェブ上でショッピングを行うことができるイーコマースとは別に、クラウドファンディングと呼ばれるサービスが普及してきている。
クラウドファンディングとは、インターネットを介して、プロジェクト(例えば、新商品を開発するプロジェクト)に対して支援者援助した資金を、プロジェクトを作成したプロジェクト作成者に提供する仕組みのことである。

0003

特に、購入型のクラウドファンディングでは、プロジェクト作成者が支援者に対して、プロジェクトへの支援に対する報酬(例えば、開発された新商品)を送る(例えば、非特許文献1を参照)。購入型のクラウドファンディングは、一定の金額支払ったことに対する報酬を受け取ることができるという点において、イーコマースと類似している。

先行技術

0004

「Kickstarter」,[online],Kickstarter, Inc.,[平成24年4月18日検索],インターネット<URL: http://www.kickstarter.com/>

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

0005

しかし、従来のクラウドファンディングでは、資金を援助した後も、プロジェクトが終了し、かつ、報酬が完成するまでは報酬を受け取ることができない。
また、従来のクラウドファンディングでは、資金を援助してから報酬を受け取るまでの間に、支援したプロジェクトへの関心が薄れたとしても、支援をキャンセルすることはできない。
また、従来のクラウドファンディングでは、オールオアナッシング方式の場合、援助された資金の総額所定金額に達し、かつ、支援期間が満了した後は、支援を受け付けることはできない。したがって、多数のユーザが関心を持っているプロジェクトであっても、支援者の数に制限がある。

0006

これらの理由により、クラウドファンディングは、ユーザにとって、サービスを利用することの心理的障壁が高い。この心理的障壁によって、クラウドファンディングの普及が妨げられている。

0007

本発明の目的は、クラウドファンディングの普及を促進することができる情報処理装置を提供することである。

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

0008

本発明の一態様は、
クラウドファンディングの会員であるユーザを識別するユーザ識別情報と、前記クラウドファンディングのプロジェクトを識別するプロジェクト識別情報とを記憶する記憶装置アクセス可能な情報処理装置であって、
第1ユーザの指示に応じて、前記第1ユーザを識別する第1ユーザ識別情報と、前記プロジェクト識別情報とに、前記プロジェクトへの支援の金額を示す情報を関連付けて記憶する手段と、
前記第1ユーザ識別情報に、前記プロジェクトへの支援に対する報酬を受け取る権利を識別するチケット識別情報を関連付けて記憶する手段と、
前記第1ユーザからの指示に応じて、前記第1ユーザ識別情報と前記チケット識別情報との関連付けを解除し、かつ、前記第1ユーザによって指定された第2ユーザを識別する第2ユーザ識別情報に前記チケット識別情報を関連付けて記憶する手段と、
を備える、情報処理装置である。

発明の効果

0009

クラウドファンディングの普及を促進することができる。

図面の簡単な説明

0010

第1実施形態の情報処理システムシステム構成図。
第1実施形態のクライアント端末の構成を示す図。
第1実施形態のサーバの構成を示す図。
第1実施形態の会員データベースデータ構造を示す図。
第1実施形態のプロジェクトデータベースのデータ構造の一例を示す図。
第1実施形態のリワードデータベースのデータ構造の一例を示す図。
第1実施形態の支援履歴データベースのデータ構造の一例を示す図。
第1実施形態のチケットデータベースのデータ構造の一例を示す図。
第1実施形態のチケットステータス遷移を示す概略図。
第1実施形態の譲渡履歴データベースのデータ構造の一例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の情報処理において表示される画面の例を示す図。
第1実施形態の会員登録の処理のシーケンス図。
第1実施形態のプロジェクト作成の処理のシーケンス図。
第1実施形態の支援の処理のシーケンス図。
第1実施形態のチケット利用の処理のシーケンス図。
第1実施形態のチケット譲渡の処理の第1例のシーケンス図。
第1実施形態のチケット譲渡の処理の第2例のシーケンス図。
第1実施形態のプロジェクト編集の処理のシーケンス図。
第1実施形態の返金の処理のシーケンス図。

実施例

0011

(1)第1実施形態
(1−1)情報処理システムの構成(図1
第1実施形態の情報処理システムの構成について説明する。図1は、第1実施形態の情報処理システムのシステム構成図である。

0012

図1に示すように、情報処理システム1は、クライアント端末10(10−1〜10−n)と、サーバ30とを備える。
クライアント端末10と、サーバ30とは、通信網NW(例えば、インターネット)を介して、通信(例えば、https通信)を行うことができる。

0013

クライアント端末10は、ユーザが使用する情報処理装置の一例である。クライアント端末10は、例えば、スマートフォンタブレット端末パーソナルコンピュータ等である。
サーバ30は、クライアント端末10から送信されたリクエストに基づいて、所定の処理を実行する情報処理装置の一例である。サーバ30は、例えば、ウェブサーバである。

0014

(1−2)クライアント端末の構成(図2
第1実施形態のクライアント端末の構成について説明する。図2は、第1実施形態のクライアント端末の構成を示す図である。

0015

図2に示すように、クライアント端末10は、CPU(Central Processing Unit)11と、記憶装置11と、入力部13と、表示部14と、通信インタフェース15とを備える。

0016

記憶装置11は、情報処理に必要なプログラム及びデータを記憶するように構成される。記憶装置11は、例えば、ROM(Read Only Memory)、RAM(Random Access Memory)、及び、ストレージ(例えば、フラッシュメモリ又はハードディスク)の組合せである。
情報処理に必要なプログラムは、例えば、OS(Operating System)のプログラム、情報処理を実行するアプリケーション(例えば、ブラウザ)のプログラム等である。
情報処理に必要なデータは、例えば、情報処理を実行することによって得られるデータ(つまり、情報処理の実行結果)である。

0017

CPU12は、記憶装置11に記憶されたプログラムを起動することによって、アプリケーションの機能を実現するように構成される。

0018

入力部13は、ユーザの指示を受け付けるように構成される。入力部13は、例えば、キーボードポインティングデバイスタッチパネル等である。

0019

表示部14は、ユーザに情報を提示するように構成される。表示部14は、例えば、液晶ディスプレイである。

0020

通信インタフェース15は、クライアント端末10と通信網NWとの間の通信を制御するように構成される。

0021

(1−3)サーバの構成(図3
第1実施形態のサーバの構成について説明する。図3は、第1実施形態のサーバの構成を示す図である。

0022

図3に示すように、サーバ30は、記憶装置31と、CPU32と、入力部33と、表示部34と、通信インタフェース35とを備える。

0023

記憶装置31は、情報処理に必要なプログラム、データ、及び、データベースを記憶する記憶装置である。記憶装置31は、例えば、ROM、RAM、及び、ストレージ(例えば、フラッシュメモリ又はハードディスク)の組合せである。
情報処理に必要なプログラムは、例えば、OS(Operating System)のプログラム、サーバ30の機能を実現するアプリケーションのプログラム等である。
情報処理に必要なデータは、例えば、要件情報(後述する)である。

0024

CPU32は、記憶装置31に記憶されたプログラムを起動することによって、サーバ30の機能を実現するように構成される。

0025

入力部33及び表示部34は、それぞれ、図2の入力部13及び表示部14と同様である。

0026

通信インタフェース35は、サーバ30と通信網NWとの間の通信を制御するように構成される。

0027

(1−4)データベースのデータ構造(図4図7
第1実施形態のデータベースのデータ構造について説明する。

0028

(1−4−1)会員データベース(図4
第1実施形態の会員データベースのデータ構造について説明する。図4は、第1実施形態の会員データベースのデータ構造を示す図である。

0029

会員データベースの各レコードには、会員に関する情報(以下「会員情報」という)が格納される。

0030

図4に示すように、会員データベースは、「会員ID」フィールドと、「メールアドレス」フィールドと、「パスワード」フィールドと、「氏名」フィールドと、「画像」フィールドと、「住所」フィールドと、「支払情報」フィールドとを含む。

0031

「会員ID」フィールドには、会員IDが格納される。会員IDは、会員として登録されたユーザ毎に固有の情報である。つまり、会員IDは、会員を識別する情報である。会員IDは、会員データベースの各レコードの主キーである。会員IDは、サーバ30が決定する情報である。

0032

「メールアドレス」フィールドには、会員のメールアドレスを示すテキストデータが格納される。
「パスワード」フィールドには、会員のパスワードを示すテキストデータが格納される。
「メールアドレス」フィールド及び「パスワード」フィールドの情報は、会員のログイン認証のために参照される。「メールアドレス」フィールド及び「パスワード」フィールドの情報は、会員が任意に決定する情報である。

0033

「氏名」フィールドには、会員の氏名を示すテキストデータが格納される。
「画像」フィールドには、会員の画像を示す画像データが格納される。
「住所」フィールドには、会員の住所を示すテキストデータが格納される。
「支払情報」フィールドには、会員の支払に関する情報(例えば、クレジットカード番号)を示す値が格納される。
「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドの情報は、会員が任意に決定する情報である。

0034

(1−4−2)プロジェクトデータベース(図5
第1実施形態のプロジェクトデータベースのデータ構造について説明する。図5は、第1実施形態のプロジェクトデータベースのデータ構造の一例を示す図である。

0035

プロジェクトデータベースの各レコードには、プロジェクトに関する情報(以下「プロジェクト情報」という)が格納される。
「プロジェクト」とは、クラウドファンディングにおいて、会員からの支援の対象を意味する。

0036

図5に示すように、プロジェクトデータベースは、「プロジェクトID」フィールドと、「プロジェクトオーナID」フィールドと、「パスワード」フィールドと、「メールアドレス」フィールドと、「氏名」フィールドと、「プロフィール」フィールドと、「プロジェクト名」フィールドと、「目標金額」フィールドと、「概要」フィールドと、「画像」フィールドと、「開始日」フィールドと、「終了日」フィールドと、「タイプ」フィールドとを含む。

0037

「プロジェクトID」フィールドには、プロジェクトIDが格納される。プロジェクトIDは、プロジェクト毎に固有の情報である。つまり、プロジェクトIDは、プロジェクトを識別する情報である。プロジェクトIDは、プロジェクトデータベースの各レコードの主キーである。プロジェクトIDは、サーバ30が決定する情報である。

0038

「プロジェクトオーナID」フィールドには、プロジェクトオーナIDが格納される。プロジェクトオーナIDは、プロジェクトオーナIDは、プロジェクトオーナを識別する情報である。
「パスワード」フィールドには、プロジェクトオーナとしてログインするためのパスワードが格納される。
「プロジェクトオーナID」フィールド及び「パスワード」フィールドは、サーバ30が決定する情報である。
「プロジェクトオーナ」とは、プロジェクトの作成者として登録されたユーザを意味する。プロジェクトオーナは、プロジェクトを管理する権限を有する。

0039

「メールアドレス」フィールドには、プロジェクトオーナのメールアドレスを示すテキストデータが格納される。「メールアドレス」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。

0040

「氏名」フィールドには、プロジェクトオーナの氏名を示すテキストデータが格納される。
「プロフィール」フィールドには、プロジェクトオーナのプロフィールを示すテキストデータが格納される。
「プロジェクト名」フィールドには、プロジェクトの名称を示すテキストデータが格納される。
「目標金額」フィールドには、プロジェクトの目標金額を示す値が格納される。
「概要」フィールドには、プロジェクトの概要を示すテキストデータが格納される。
「画像」フィールドには、プロジェクトの画像を示す画像データが格納される。
「開始日」フィールド及び「終了日」フィールドには、それぞれ、プロジェクトの開始日及び終了日を示す値が格納される。「開始日」フィールド及び「終了日」フィールドの情報は、プロジェクトの期間を示す。
「氏名」フィールド、「プロフィール」フィールド、「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、「画像」フィールド、「開始日」フィールド、及び、「終了日」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。

0041

「タイプ」フィールドには、プロジェクトのタイプを示すコードが格納される。タイプコード「AN」は、プロジェクトのタイプが「オールオアナッシング方式」であることを示す。タイプコード「DC」は、プロジェクトのタイプが「ダイレクトチャレンジ方式」であることを示す。
「タイプ」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
オールオアナッシング方式では、「終了日」フィールドに格納された値が示す日までに、支援金額の総額が「目標金額」フィールドの値に到達した場合にのみ、プロジェクト作成者に支援金額が渡され、かつ、支援者に報酬が送られる。
ダイレクトチャレンジ方式では、「終了日」フィールドに格納された値が示す日の支援金額の総額がプロジェクト作成者に渡される。

0042

(1−4−3)リワードデータベース(図6
第1実施形態のリワードデータベースのデータ構造について説明する。図6は、第1実施形態のリワードデータベースのデータ構造の一例を示す図である。

0043

リワードデータベースの各レコードには、リワードに関する情報(以下「リワード情報」という)が格納される。
1つのプロジェクトIDには、リワードデータベースの複数のレコードを関連付けることができる。
「リワード」とは、プロジェクトへの支援に対する報酬を意味する。

0044

図6に示すように、リワードデータベースは、「リワードID」フィールドと、「チケット上限数」フィールドと、「チケット配布数」フィールドと、「リワード名」フィールドと、「画像」フィールドと、「チケット金額」フィールドと、「説明」フィールドと、「予定日」フィールドとを含む。

0045

「リワードID」フィールドには、リワードIDが格納される。リワードIDは、リワード毎に固有の情報である。つまり、リワードIDは、リワードを識別する情報である。リワードIDは、リワードデータベースの各レコードの主キーである。リワードIDは、サーバ30が決定する情報である。

0046

「チケット上限数」フィールドには、1つのリワードにおいて提供されるチケットの上限数を示す値が格納される。
「チケット」とは、プロジェクトに対する支援への報酬を受け取る権利を意味する。
「チケット上限数」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。

0047

「チケット配布数」フィールドには、プロジェクトを支援した会員に配布したチケットの数を示す値が格納される。「チケット配布数」フィールドの値は、プロジェクトの支援者の数を示す。
「チケット配布数」フィールドの情報は、サーバ30が決定する情報である。

0048

「リワード名」フィールドには、リワードの名称を示すテキストデータが格納される。
「画像」フィールドには、リワードの画像を示す画像データが格納される。
「チケット金額」フィールドには、1つのチケットを取得するために必要な支援金額を示す値が格納される。
「説明」フィールドには、リワードの説明を示すテキストデータが格納される。
「予定日」フィールドには、チケットが利用可能になる日を示す値が格納される。
「リワード名」フィールド、「画像」フィールド、「チケット金額」フィールド、「説明」フィールド、及び、「予定日」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。

0049

(1−4−4)支援履歴データベース(図7
第1実施形態のリワードデータベースのデータ構造について説明する。図7は、第1実施形態の支援履歴データベースのデータ構造の一例を示す図である。

0050

支援履歴データベースの各レコードには、プロジェクトへの支援の履歴に関する情報(以下「支援履歴情報」という)が格納される。
1つの会員IDには、支援履歴データベースの複数のレコードを関連付けることができる。
「支援」とは、プロジェクトに対する資金の提供を意味する。

0051

図7に示すように、支援履歴データベースは、「支援ID」フィールドと、「支援金額」フィールドと、「支援日」フィールドとを含む。

0052

「支援ID」フィールドには、支援IDが格納される。支援IDは、支援毎に固有の情報である。つまり、支援IDは、支援を識別する情報である。支援IDは、支援履歴データベースの各レコードの主キーである。支援IDは、サーバ30が決定する情報である。

0053

「支援金額」フィールドには、支援金額を示す値が格納される。
「支援日」フィールドには、支援日を示す値が格納される。
「支援金額」フィールド及び「支援日」フィールドの情報は、サーバ30が決定する情報である。

0054

(1−4−5)チケットデータベース(図8図9
第1実施形態のチケットデータベースのデータ構造について説明する。図8は、第1実施形態のチケットデータベースのデータ構造の一例を示す図である。

0055

チケットデータベースの各レコードには、チケットに関する情報(以下「チケット情報」という)が格納される。
1つのリワードIDには、チケットデータベースの複数のレコードを関連付けることができる。

0056

図8に示すように、チケットデータベースは、「チケットID」フィールドと、「チケットオーナID」フィールドと、「支援ID」フィールドと、「受取トークン」フィールドと、「トークン期限」フィールドと、「ステータス」フィールドとを含む。

0057

「チケットID」フィールドには、チケットIDが格納される。チケットIDは、チケット毎に固有の情報である。つまり、チケットIDは、チケットを識別する情報である。チケットIDは、チケットデータベースの各レコードの主キーである。チケットIDは、サーバ30が決定する情報である。

0058

「チケットオーナID」フィールドには、チケットオーナIDが格納される。チケットオーナIDとは、チケットを所有する会員の会員IDである。

0059

「支援ID」フィールドには、チケットIDと所有者IDとを関連付けるトリガとなった支援の支援IDが格納される。

0060

「受取用トークン」フィールドには、紙チケットを介してチケット譲り受けるときに使用する受取用トークンを示す文字列が格納される。
「トークン期限」フィールドには、「受取用トークン」フィールドに格納された情報の利用期限を示す値である。
「受取用トークン」フィールド、及び、「トークン期限」フィールドの情報は、サーバ30が決定する情報である。

0061

「ステータス」フィールドには、チケットのステータスを示すコード(以下「ステータスコード」という)が格納される。

0062

第1実施形態のチケットのステータスについて説明する。図9は、第1実施形態のチケットのステータスの遷移を示す概略図である。

0063

図9に示すように、ステータスコードは、第1ステータスを示すコード「STA1」、第2ステータスを示すコード「STA2」、第3ステータスを示すコード「STA3」、及び、第4ステータスを示すコード「STA4」の何れかである。

0064

支援リクエスト(後述する)が行われた後、プロジェクトへの支援金入金の確認に成功すると、チケットのステータスは第1ステータスになる。
「第1ステータス」とは、チケットが利用可能である状態(以下「利用可能状態」という)を示す。ステータスコード「STA1」に関連付けられたチケットIDによって識別されるチケットは、利用可能であり、かつ、譲渡可能である。

0065

第1ステータスにおいてチケット譲渡リクエスト(後述する)が行われると、チケットのステータスは第2ステータスに遷移する。
「第2ステータス」とは、チケットの譲渡の処理が完了していない状態(以下「譲渡中状態」という)を示す。ステータスコード「STA2」に関連付けられたチケットIDによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。
第2ステータスにおいて譲渡が完了すると、チケットのステータスは第1ステータスに遷移する。

0066

第1ステータスにおいてチケット利用リクエスト(後述する)が行われると、チケットのステータスは第3ステータスに遷移する。
「第3ステータス」とは、チケット利用リクエストが行われた状態(以下「利用中状態」という)を示す。ステータスコード「STA3」に関連付けられたチケットIDによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。

0067

第4ステータスにおいてリワード完了リクエスト(後述する)が行わると、チケットのステータスは第4ステータスに遷移する。
「第4ステータス」とは、チケットが利用済である状態(以下「利用済状態」という)を示す。ステータスコード「STA4」に関連付けられたチケットIDによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。

0068

(1−4−6)譲渡履歴データベース(図10
第1実施形態の譲渡履歴データベースのデータ構造について説明する。図10は、第1実施形態の譲渡履歴データベースのデータ構造の一例を示す図である。

0069

譲渡履歴データベースの各レコードには、チケットの譲渡履歴に関する情報(以下「譲渡履歴情報」という)が格納される。
1つのチケットIDには、譲渡履歴データベースの複数のレコードを関連付けることができる。

0070

図10に示すように、譲渡履歴データベースは、「登録日」フィールドと、「譲渡人ID」フィールドと、「譲受人ID」フィールドとを含む。

0071

「登録日」フィールドには、各レコードの登録日を示す値が格納される。登録日は、譲渡履歴データベースの各レコードの主キーである。登録日は、サーバ30が決定する情報である。

0072

「譲渡人ID」フィールドには、譲渡人(つまり、譲渡が行われる前)のチケットオーナIDが格納される。

0073

「譲受人ID」フィールドには、譲受人(つまり、譲渡が行われた後)のチケットオーナIDが格納される。

0074

(1−5)情報処理において表示される画面(図11図22
第1実施形態の情報処理において表示される画面について説明する。図11図22は、第1実施形態の情報処理において表示される画面の例を示す図である。
図11図22の画面は、クライアント端末10の表示部14に表示される。各画面では、ユーザは、入力部13を用いて指示(入力フィールドへの入力、及び、ボタンの指定)を与えることができる。与えられた指示は、クライアント端末10からサーバ30に送信される。

0075

図11の画面P100は、トップ画面用のURL(Uniform Resource Locator)にアクセスされたときに表示される画面である。
画面P100は、「会員登録」ボタンB100aと、「プロジェクト作成」ボタンB100bと、「ログイン」ボタンB100cとを含む。

0076

画面P100において「会員登録」ボタンB100aが指定されると、画面P110が表示される。
画面P110は、入力フィールドF110と、「完了」ボタンB110とを含む。
入力フィールドF110は、会員登録に必要な情報を入力するための入力フィールドである。会員登録に必要な情報とは、例えば、氏名、メールアドレス、パスワード、画像、住所、及び、支払情報である。

0077

画面P110において入力フィールドF110に情報が入力され、かつ、「完了」ボタンB110が指定されると、クライアント端末10は、サーバ30に、会員登録の処理のリクエスト(以下「会員登録リクエスト」という)を送信する。

0078

図11の画面P100において「プロジェクト作成」ボタンB100bが指定されると、図12の画面P210が表示される。
画面P210は、入力フィールドF210a〜F210bと、「完了」ボタンB210とを含む。
入力フィールドF210a〜F210bは、プロジェクト情報を入力するための入力フィールドである。具体的には、入力フィールドF210aは、プロジェクトオーナの氏名、メールアドレス、及び、プロフィールを入力するための入力フィールドである。入力フィールドF210bは、プロジェクト名、目標金額、開始日、終了日、画像、及び、タイプを入力するための入力フィールドである。タイプを入力するための入力フィールドは、プルダウン形式入力可能である。

0079

画面P210において入力フィールドF210a〜F210bに情報が入力され、かつ、「完了」ボタンB210が指定されると、クライアント端末10は、サーバ30に、プロジェクト作成の処理のリクエスト(以下「プロジェクト作成リクエスト」という)を送信する。

0080

図11の画面P100において「ログイン」ボタンB100cが指定され、かつ、会員ID(例えば、会員ID「CU001」)及びパスワードが入力されると、図13の画面P310が表示される。
画面P310は、「支援」ボタンB310aと、「所有チケット一覧」ボタンB310bと、「チケット受取」ボタンB310cとを含む。

0081

画面P310において「支援」ボタンB310aが指定されると、画面P311が表示される。
画面P311は、画像IMG311a〜IMG311bと、領域A311a〜A311bと、「選択」ボタンB311a〜B311bとを含む。
画像IMG311a〜IMG311bは、支援の対象となるプロジェクトの画像(例えば、図5の「画像」フィールドに格納された画像データに対応する画像)である。
領域A311a〜A311bには、プロジェクト情報(例えば、プロジェクト名、参加者数残り日数、及び、達成金額)が表示される。「プロジェクト名」は、例えば、図5の「プロジェクト名」フィールドの情報である。「参加者数」は、プロジェクトを支援している会員の数(例えば、図6の「チケット配布数」フィールドの値)である。「残り日数」は、プロジェクトの終了日迄の残り日数(例えば、図5の「終了日」フィールドと画面P310が表示された日との差)である。「達成金額」は、支援金額の総額(例えば、図6の「チケット配布数」フィールドの値と、「チケット金額」フィールドの値との積)である。
「選択」ボタンB311a〜B311bは、それぞれ、領域A311a〜A311bに表示されたプロジェクト情報に関連するプロジェクトID(例えば、プロジェクトID「PR001」〜「PR002」)に関連付けられている。

0082

画面P311において「選択」ボタンB311aが指定されると、画面P312が表示される。
画面P312は、領域A312と、入力フィールドF312と、「完了」ボタンB312とを含む。
領域A312には、「選択」ボタンB311aに関連するプロジェクトID(例えば、プロジェクトID「PR001」)に関連付けられたリワード情報が表示される。「リワード名」は、例えば、図6の「リワード名」フィールドの情報である。「チケット金額」は、例えば、図6の「チケット金額」フィールドの値である。
入力フィールドF312は、取得を希望するチケットの数量を入力するための入力フィールドである。

0083

画面P312において入力フィールドF312に情報が入力され、かつ、「完了」ボタンB312が指定されると、クライアント端末10は、サーバ30に、支援の処理のリクエスト(以下「支援リクエスト」という)を送信する。

0084

画面P310において「所有チケット一覧」ボタンB310bが指定されると、図14の画面P320が表示される。
画面P320は、領域A320a〜A320bと、「利用」ボタンB320a〜B320bと、「譲渡」ボタンB320c〜B320dと、「発行」ボタンB320e〜B320fとを含む。
領域A320a〜A320bには、会員が所有しているチケットに関するチケット情報が表示される。「プロジェクト名」は、例えば、図5の「プロジェクト名」フィールドの情報である。「リワード名」は、例えば、図6の「リワード名」フィールドの情報である。「チケット金額」は、例えば、図6の「チケット金額」フィールドの値である。
「利用」ボタンB320a〜B320bは、それぞれ、領域A320a〜A320bに表示されたチケット情報に対応するチケットID(例えば、チケットID「TI001」〜「TI002」)に関連付けられている。
「譲渡」ボタンB320c〜B320dは、それぞれ、領域A320a〜A320bに表示されたリワード情報に対応するリワードIDに関連付けられている。
「発行」ボタンB320e〜B320fは、それぞれ、それぞれ、領域A320a〜A320bに表示されたリワード情報に対応するリワードIDに関連付けられている。

0085

画面P320において「利用」ボタンB320aが指定されると、画面P321が表示される。
画面P321は、領域A320aに表示された情報と、「YES」ボタンB321aと、「NO」ボタンB321bとを含む。
「YES」ボタンB321aが指定されると、クライアント端末10は、サーバ30に、「利用」ボタンB320aに関連付けられたチケットID(例えば、チケットID「TI001」)によって識別されるチケットを利用するためのチケット利用リクエストを送信する。
「NO」ボタンB321bが指定されると、画面P320に戻る。

0086

画面P320において「譲渡」ボタンB320cが指定されると、図15の画面P322が表示される。
画面P322は、領域A322a〜A322bと、入力フィールドF322a〜F322bと、「完了」ボタンB322とを含む。
領域A322aには、図14の領域A320aと同様の情報が表示される。
領域A322bには、チケットを受け取るために必要なURL(以下「受取用URL」という)が表示される。受取用URL「https://example.com/receive?token=ABCDEFG012345」は、チケットを受け取るための受取用トークン「ABCDEFG012345」を含む。
入力フィールドF322aは、領域A322bに表示されたURLの送信先となる会員(つまり、チケットの譲受人)の会員IDを入力するための入力フィールドである。
入力フィールドF322bは、領域A322bに表示されたURLの宛先となるメールアドレスを入力するための入力フィールドである。このメールアドレスは、図4の会員データベースにおいて会員IDに関連付けられたメールアドレスであってもよいし、会員IDに関連付けられていないメールアドレス(例えば、非会員ユーザのメールアドレス)であってもよい。

0087

画面P322において入力フィールドF322aに情報が入力され、かつ、「完了」ボタンB322が指定されると、クライアント端末10は、サーバ30に、チケットを譲渡するためのリクエスト(以下「チケット譲渡リクエスト」という)を送信する。

0088

画面P322の入力フィールドF322aに入力された会員ID(例えば、会員ID「CU999」)に基づいてログイン認証が行われると、図16の画面P330が表示される。
画面P330は、入力フィールドF330a〜F330bと、「完了」ボタンB330とを含む。
入力フィールドF330aは、受取用URLを入力するための入力フィールドである。入力フィールドF330aの受取用URLは、予め入力されていてもよいし、ユーザが入力部13を用いて入力してもよい。
入力フィールドF330bは、チケットを受け取るために必要なコード(以下「受取用コード」という)を入力するための入力フィールドである。

0089

画面P330において入力フィールドF330a又はF330bに情報が入力され、かつ、「完了」ボタンB330が指定されると、クライアント端末10は、サーバ30に、チケットを受け取るためのリクエスト(以下「チケット受取リクエスト」という)を送信する。

0090

図14の画面P320において「発行」ボタンB320eが指定されると、図17の画面P340が表示される。
画面P340は、入力フィールドF340と、「完了」ボタンB340とを含む。
入力フィールドF340は、譲受人の氏名、メールアドレス、及び、住所を入力するための入力フィールドである。

0091

画面P340において入力フィールドF340に情報が入力され、かつ、「完了」ボタンB340が指定されると、クライアント端末10は、サーバ30に、チケットを発行するためのリクエスト(以下「チケット発行リクエスト」という)を送信する。

0092

発行チケットを受け取ったユーザであって、かつ、会員IDを有していないユーザ(以下「非会員ユーザ」という)によってチケット受取画面のURLにアクセスされると、図18の画面P350が表示される。
画面P350は、入力フィールドF350a及びF350bと、「会員登録」ボタンB350a及び「ログイン」ボタンB350bとを含む。
入力フィールドF350a〜F350bは、それぞれ、図16の入力フィールドF330a〜F330bと同様である。

0093

入力フィールドF350a又はF350bに情報が入力され、かつ、「会員登録」ボタンB350aが指定されると、図11の画面P110が表示される。画面P110において入力フィールドF110に情報が入力され、かつ、「完了」ボタンB110が指定されると、クライアント端末10は、サーバ30に、会員登録リクエストと、チケット受取リクエストとを送信する。
入力フィールドF350a又はF350bに情報が入力され、かつ、「ログイン」ボタンB350bが指定されると、クライアント端末10は、サーバ30に、ログインリクエストと、チケット受取リクエストとを送信する。その結果、図13の画面P310が表示される。

0094

図11の画面P100において「ログイン」ボタンB100cが指定され、かつ、プロジェクトオーナID(例えば、プロジェクトオーナID「PO001」)及びパスワードが入力されると、図19の画面P410が表示される。
画面P410は、「プロジェクト管理」ボタンB410aは、「リワード管理」ボタンB410bと、「チケット管理」ボタンB410cとを含む。

0095

画面P410において「プロジェクト管理」ボタンB410aが指定されると、画面P411が表示される。
画面P411は、画像IMG411a〜IMG411bと、領域A411a〜A411bと、「編集ボタン」B411a〜B411bとを含む。
画像IMG411a〜IMG411bは、管理の対象となるプロジェクトの画像(例えば、図5の「画像」フィールドに格納された画像データに対応する画像)である。
領域A411a〜A411bには、プロジェクト情報(例えば、図5の「プロジェクト名」フィールド、「目標金額」フィールド、及び、「概要」フィールドの情報)が表示される。
「編集」ボタンB411a〜B411bは、それぞれ、領域A411a〜A411bに表示されたプロジェクト情報に関連するプロジェクトID(例えば、プロジェクトID「PR001」〜「PR002」)に関連付けられている。

0096

画面P411において「編集」ボタンB411aが指定されると、クライアント端末10は、サーバ30に対して、「編集」ボタンB411aに関連するプロジェクトIDに関連付けられたプロジェクト情報を編集するためのリクエスト(以下「プロジェクト編集リクエスト」という)を送信する。その結果、画面P412が表示される。図19には図示していないが、画面P412は、図12の画面P210と同様の入力フィールドF210a〜F210bと、「完了」ボタンB210とを含む。

0097

画面P410において「リワード管理」ボタンB410bが指定されると、図20の画面P420が表示される。
画面P420は、領域A420と、「リワード作成」ボタンB420aと、「選択」ボタンB420b〜B420cとを含む。
領域A420には、リワード情報(例えば、図6の「リワード名」フィールド、及び、「説明」フィールドの情報)が表示される。
「選択」ボタンB420b〜B420cは、領域A420に表示されたリワード情報に関連するリワードID(例えば、リワードID「RW001」〜「RW002」)に関連付けられている。

0098

画面P420において、「リワード作成」ボタンB420aが指定されると、画面P421が表示される。
画面P421は、入力フィールドF421と、「完了」ボタンB421とを含む。
入力フィールドF421は、リワードの作成に必要なリワード情報を入力するための入力フィールドである。リワードの作成に必要なリワード情報とは、例えば、リワード名、画像、説明、チケット上限数、チケット金額、及び、予定日である。

0099

画面P421において入力フィールドF421に情報が入力され、かつ、「完了」ボタンB421が指定されると、クライアント端末10は、サーバ30に、リワード作成の処理のリクエスト(以下「リワード作成リクエスト」という)を送信する。

0100

画面P420において、「編集」ボタンB420bが指定されると、図21の画面P422が表示される。
画面P422は、入力フィールドF422と、「完了」ボタンB422とを含む。
入力フィールドF422は、リワード情報を編集するための入力フィールドである。

0101

画面P422において入力フィールドF422に情報が入力され、かつ、「完了」ボタンB422が指定されると、クライアント端末10は、サーバ30に、リワード情報の編集のリクエスト(以下「リワード編集リクエスト」という)を送信する。

0102

図19の画面P410において「チケット管理」ボタンB410cが指定されると、図22の画面P430が表示される。
画面P430は、領域A430と、「選択」ボタンB430a〜B430bとを含む。
領域A430には、チケット情報(例えば、図8の「チケットID」フィールド、「チケットオーナID」フィールド、及び、「ステータス」フィールドの情報)と、チケットタイトル(例えば、図6のリワードID「RE001」に関連付けられた「リワード名」フィールドの情報)とが表示される。
「選択」ボタンB430a〜B430bは、それぞれ、領域A430に表示されたチケットID「TI001」〜「TI002]に関連付けられている。

0103

画面P430において「選択」ボタンB420aが指定されると、画面P431が表示される。
画面P431は、領域A431と、「完了」ボタンB431とを含む。
領域A431には、報酬の発送先となる会員に関する会員情報(例えば、図4の「氏名」フィールド、及び、「住所」フィールドの情報)が表示される。

0104

リワード(例えば、プロジェクトに関連する商品の発送)が完了した後に画面P431において「完了」ボタンB431が指定されると、クライアント端末10は、サーバ30に、チケットID「TI001」によって識別されるチケットのステータスを変更するためのリワード完了リクエストを送信する。

0105

(1−6)情報処理のフロー図23図30
第1実施形態の情報処理のフローについて説明する。以下の情報処理は、図2のCPU12が記憶装置11に記憶されたアプリケーション(例えば、ブラウザ)のプログラムを実行し、かつ、図3のCPU32が記憶装置31に記憶されたプログラムを実行することによって、実現される。
クライアント端末10とサーバ30とは、通信網NWを介して、https通信を行うことによって以下の情報処理を実現する。

0106

(1−6−1)会員登録の処理のフロー(図23
第1実施形態の会員登録の処理について説明する。図23は、第1実施形態の会員登録の処理のシーケンス図である。

0107

図23のクライアント端末10のユーザは、非会員ユーザである。

0108

はじめに、クライアント端末10は、トップ画面の表示(S100)を実行する。
具体的には、非会員ユーザが、入力部13を用いて、トップ画面用のURLを指定すると、CPU12は、図11の画面P100を表示部14に表示する。

0109

クライアント端末10は、会員登録画面の表示(S101)を実行する。
具体的には、非会員ユーザが、入力部13を用いて、図11の画面P100の「会員登録」ボタンB100aを指定すると、CPU12は、サーバ30と通信することによって、画面P110を表示部14に表示する。

0110

クライアント端末10は、会員リクエスト(S102)を実行する。
具体的には、非会員ユーザが、入力部13を用いて、図11の画面P110の入力フィールドF110に情報を入力し、かつ、「完了」ボタンB110を指定すると、CPU12は、会員登録リクエストを作成する。会員登録リクエストは、入力フィールドF110に入力された情報を含む。
次に、CPU12は、会員登録リクエストをサーバ30に送信する。

0111

サーバ30は、データベースの更新(S300)を実行する。
具体的には、CPU32は、図4の会員データベースに新規レコードを追加する。新規レコードの「会員ID」フィールドには、新しい会員IDが格納される。新規レコードの「メールアドレス」フィールド、「パスワード」フィールド、「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドには、それぞれ、会員登録リクエストに含まれる情報(氏名、メールアドレス、パスワード、画像、住所、及び、支払情報)が格納される。

0112

以上の処理により、会員登録の処理が終了する。

0113

(1−6−2)プロジェクト作成の処理のフロー(図24
第1実施形態のプロジェクト作成の処理について説明する。図24は、第1実施形態のプロジェクト作成の処理のシーケンス図である。

0114

図24のクライアント端末10のユーザは、プロジェクト作成者である。

0115

はじめに、クライアント端末10は、図23と同様に、トップ画面の表示(S100)を実行する。

0116

クライアント端末10は、プロジェクト作成画面の表示(S110)を実行する。
具体的には、プロジェクト作成者が、入力部13を用いて、図11の画面P100の「プロジェクト作成」ボタンB100bを指定すると、CPU12は、サーバ30と通信することによって、図12の画面P210を表示部14に表示する。

0117

クライアント端末10は、プロジェクト作成リクエスト(S111)を実行する。
具体的には、プロジェクト作成者が、入力部13を用いて、図12の画面P210の入力フィールドF210a〜F210bに情報を入力し、かつ、「完了」ボタンB210を指定すると、CPU12は、プロジェクト作成リクエストを作成する。プロジェクト作成リクエストは、入力フィールドF210a〜F210bに入力された情報を含む。
次に、CPU12は、プロジェクト作成リクエストをサーバ30に送信する。

0118

サーバ30は、プロジェクトの審査(S310)を実行する。
具体的には、CPU32は、記憶装置31に記憶された要件情報に基づいて、プロジェクト作成リクエストに含まれる情報(プロジェクトオーナの氏名、プロジェクトオーナのメールアドレス、プロジェクトオーナのプロフィール、プロジェクト名、プロジェクトの目標金額、プロジェクトの概要、プロジェクトの開始日、プロジェクトの終了日、プロジェクトの画像、及び、プロジェクトのタイプ)がプロジェクト要件を満たすか否かを審査する。
「要件情報」とは、プロジェクトとして登録するための要件を示す情報である。
なお、プロジェクト作成リクエストに含まれる情報の一部がプロジェクト要件を満たすか否かを、サーバ30のオペレータが審査してもよい。この場合、CPU32が、プロジェクト作成リクエストに含まれる情報の一部について審査を行い、オペレータが、残りの部分について審査を行う。

0119

サーバ30は、データベースの更新(S311)を実行する。
具体的には、プロジェクト作成リクエストに含まれる情報がプロジェクト要件を満たす場合、CPU32は、図5のプロジェクトデータベースに新規レコードを追加する。新規レコードの「プロジェクトID」フィールド及び「プロジェクトオーナID」フィールドには、それぞれ、新しいプロジェクトID及び新しいプロジェクトオーナIDが格納される。新規レコードの「パスワード」フィールドには、ランダムで決定されたパスワードが格納される。新規レコードの「メールアドレス」フィールド、「氏名」フィールド、「プロフィール」フィールド、「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、「画像」フィールド、「開始日」フィールド、「終了日」フィールド、及び、「タイプ」フィールドには、それぞれ、プロジェクト作成リクエストに含まれる情報(メールアドレス、氏名、プロフィール、プロジェクト名、目標金額、概要、画像、開始日、終了日、及び、タイプ)が格納される。

0120

以上の処理により、プロジェクト作成の処理が終了する。

0121

(1−6−3)支援の処理のフロー(図25
第1実施形態の支援の処理について説明する。図25は、第1実施形態の支援の処理のシーケンス図である。

0122

図25のクライアント端末10のユーザは、会員ユーザ(会員ID「CU001」名「会員1」)である。

0123

はじめに、クライアント端末10は、図23と同様に、トップ画面の表示(S100)を実行する。

0124

クライアント端末10は、ログインリクエスト(S120)を実行する。
具体的には、会員ユーザが、入力部13を用いて、図11の画面P100の「ログイン」ボタンB100cを指定し、かつ、会員ID及びパスワードを入力すると、CPU12は、ログインリクエストをサーバ30に送信する。ログインリクエストは、会員ID及びパスワードを含む。

0125

サーバ30は、ログイン認証(S320)を実行する。
具体的には、CPU32は、ログインリクエストに含まれる会員ID及びパスワードと、図4の会員データベースの「会員ID」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれる会員ID及びパスワードと、会員データベースの「会員ID」フィールド及び「パスワード」フィールドの情報とが一致する場合、CPU32は、ログインを許可する。一方、ログインリクエストに含まれる会員ID及びパスワードと、会員データベースの「会員ID」フィールド及び「パスワード」フィールドの情報とが一致しない場合、CPU32は、ログインを拒否する。

0126

ログインが許可されると、クライアント端末10は、会員ホーム画面の表示(S121)を実行する。
具体的には、CPU32は、ログインリクエストに含まれる会員IDに対応する会員ホーム画面を表示させるためのレスポンスをクライアント端末10に送信する。
次に、CPU12は、サーバ30から送信されたレスポンスに基づいて、図13の画面P310を表示部14に表示する。

0127

クライアント端末10は、プロジェクト選択画面の表示(S122)を実行する。
具体的には、会員ユーザが、入力部13を用いて、図13の画面P310の「支援」ボタンB310aを指定すると、CPU12は、サーバ30と通信することによって、画面P311を表示部14に表示する。画面P311には、選択可能なプロジェクト(例えば、返金条件(後述する)を満たしていないプロジェクト)に関するプロジェクト情報が表示される。

0128

クライアント端末10は、リワード選択画面の表示(S123)を実行する。
具体的には、会員ユーザが、入力部13を用いて、図13の画面P311の「選択」ボタンB311aを指定すると、CPU12は、リクエストをサーバ30に送信する。このリクエストは、「選択」ボタンB311aに関連付けられたプロジェクトID「PR001」を含む。
次に、CPU32は、クライアント端末10から送信されたリクエストに含まれるプロジェクトID「PR001」に対応するプロジェクト選択画面を表示させるためのレスポンスをクライアント端末10に送信する。
次に、CPU12は、サーバ30から送信されたレスポンスに基づいて、画面P312を表示部14に表示する。画面P312には、選択可能なリワードに関するリワード情報(例えば、図6の「チケット配布数」フィールドの値が「チケット上限数」フィールドの値未満であるレコードの情報)が表示される。

0129

クライアント端末10は、支援リクエスト(S124)を実行する。
具体的には、会員ユーザが、入力部13を用いて、図13の画面P312の入力フィールドF312に、取得を希望するチケットの数量を入力し、かつ、「完了」ボタンB312を指定すると、CPU12は、支援リクエストを作成する。支援リクエストは、リワードIDと、リワードIDに対応する数量(入力フィールドF312に入力された情報)とを含む。
次に、CPU12は、支援リクエストをサーバ30に送信する。

0130

サーバ30は、入金の確認(S321)を実行する。
具体的には、CPU32は、図6のリワードデータベースを参照して、支援リクエストに含まれるリワードIDに対応する数量とチケット金額との積を計算する。この計算結果は、会員ユーザの支援金額を意味する。
次に、CPU32は、図4の会員データベースを参照して、ログインリクエストに含まれる会員IDに関連付けられた支払情報に基づいて、決済リクエストの送信先となるクレジットカード会社のサーバを特定する。
次に、CPU32は、所定時間毎に、金融機関等のサーバに、入金の確認を要求するためのリクエストを送信する。

0131

サーバ30は、入金の確認に成功すると(S321−YES)、データベースの更新(S322)を実行する。
具体的には、CPU32は、支援リクエストに含まれる情報(リワードID、及び、リワードIDに対応する数量)に基づいて、図6のリワードデータベースの「チケット配布数」フィールドを更新する。
次に、CPU32は、図7の支援履歴データベースに新規レコードを追加する。新規レコードの「支援ID」フィールドには、新しい支援IDが格納される。新規レコードの「支援金額」フィールドには、支援金額を示す値が格納される。新規レコードの「支援日」フィールドには、支援リクエスト(S124)の実行日を示す値が格納される。
次に、CPU32は、図8のチケットデータベースに新規レコードを追加する。新規レコードの「支援ID」フィールドには、支援履歴データベースの新規レコードの「支援ID」フィールドに格納された支援IDが格納される。新規レコードの「ステータス」フィールドには、ステータスコード「STA1」が格納される。これにより、チケットのステータスは、利用可能状態になる。

0132

以上の処理により、支援の処理が終了する。

0133

(1−6−4)チケット利用の処理のフロー(図26
第1実施形態のチケット利用の処理について説明する。図26は、第1実施形態のチケット利用の処理のシーケンス図である。

0134

図26のクライアント端末10−1のユーザは、チケットオーナ(会員ID「CU001」)である。クライアント端末10−2のユーザは、プロジェクトオーナ(プロジェクトオーナID「PO001」)である。

0135

はじめに、クライアント端末10−1〜10−2は、図23と同様に、トップ画面の表示(S100)を実行する。
クライアント端末10−1は、図25と同様に、ログインリクエスト(S120)を実行する。
サーバ30は、図25と同様に、ログインリクエスト(S120)に対するログイン認証(S320)を実行する。
クライアント端末10−1は、図25と同様に、会員ホーム画面の表示(S121)を実行する。

0136

クライアント端末10−1は、チケット一覧画面の表示(S130)を実行する。
具体的には、チケットオーナが、入力部13を用いて、図13の画面P310の「所有チケット一覧」ボタンB310bを指定すると、CPU12は、サーバ30と通信することによって、図14の画面P320を表示部14に表示する。画面P320には、チケットオーナが所有するチケットのうち利用可能状態であるチケットに関するチケット情報(例えば、図8の「ステータス」フィールドにチケットコード「STA1」が格納されたレコードの情報)が表示される。

0137

クライアント端末10−1は、チケット利用画面の表示(S131)を実行する。
具体的には、チケットオーナが、入力部13を用いて、図14の画面P320の「利用」ボタンB320aを指定すると、CPU12は、サーバ30と通信を行うことによって、画面P321を表示部14に表示する。画面P321には、「利用」ボタンB320aに関連付けられたチケットIDに関連する情報(例えば、プロジェクト名、リワード名、及び、チケット金額)が表示される。

0138

クライアント端末10−1は、チケット利用リクエスト(S132)を実行する。
具体的には、チケットオーナが、図14の画面P321の「YES」ボタンB321aを指定すると、CPU12は、チケット利用リクエストをサーバ30に送信する。チケット利用リクエストは、画面P320において指定された「利用」ボタンB320aに関連付けられたチケットIDを含む。
次に、CPU32は、図8のチケットデータベースにおいて、クライアント端末10−1から送信されたチケット利用リクエストに含まれるチケットIDに関連付けられた「ステータス」フィールドにステータスコード「STA3」を格納する。これにより、チケットのステータスは、利用可能状態から利用中状態になる。

0139

クライアント端末10−2は、ログインリクエスト(S133)を実行する。
具体的には、会員ユーザが、入力部13を用いて、図11の画面P100の「ログイン」ボタンB100cを指定し、かつ、プロジェクトオーナID及びパスワードを入力すると、CPU12は、ログインリクエストをサーバ30に送信する。ログインリクエストは、プロジェクトオーナID及びパスワードを含む。

0140

サーバ30は、ログインリクエスト(S133)に対するログイン認証(S320)を実行する。
具体的には、CPU32は、ログインリクエストに含まれるプロジェクトオーナID及びパスワードと、図5のプロジェクトデータベースの「プロジェクトオーナID」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれるプロジェクトオーナID及びパスワードと、プロジェクトデータベースの「プロジェクトオーナID」フィールド及び「パスワード」フィールドの情報とが一致する場合、CPU32は、ログインを許可する。一方、ログインリクエストに含まれるプロジェクトオーナID及びパスワードと、プロジェクトデータベースの「プロジェクトオーナID」フィールド及び「パスワード」フィールドの情報とが一致しない場合、CPU32は、ログインを拒否する。

0141

ログインが許可されると、クライアント端末10−2は、プロジェクトオーナホーム画面の表示(S134)を実行する。
具体的には、CPU32は、ログインリクエストに含まれるプロジェクトオーナIDに対応するプロジェクトオーナホーム画面を表示させるためのレスポンスをクライアント端末10−2に送信する。
次に、CPU12は、サーバ30から送信されたレスポンスに基づいて、図19の画面P410を表示部14に表示する。

0142

S330の後に、クライアント端末10−2は、チケット管理画面の表示(S135)を実行する。
具体的には、プロジェクトオーナが、入力部13を用いて、図19の画面P410の「チケット管理」ボタンB410cを指定すると、CPU12は、サーバ30と通信することによって、図22の画面P430を表示部14に表示する。画面P430には、選択可能なチケットに関するチケット情報(例えば、図8のチケットデータベースの情報)が表示される。

0143

クライアント端末10−2は、リワード完了画面の表示(S136)を実行する。
具体的には、プロジェクトオーナが、入力部13を用いて、図22の画面P430の「選択」ボタンB430aを指定すると、CPU12は、リクエストをサーバ30に送信する。このリクエストは、「選択」ボタンB430aに関連付けられたチケットIDを含む。
次に、CPU32は、図8のチケットデータベースにおいてクライアント端末10−2から送信されたリクエストに含まれるチケットIDに関連付けられたチケットオーナID(つまり、チケットオーナを識別する会員ID)を特定する。
次に、CPU32は、特定した会員IDに対応するリワード完了画面を表示させるためのレスポンスをクライアント端末10−2に送信する。
CPU12は、サーバ30から送信されたレスポンスに基づいて、画面P431を表示部14に表示する。画面P431には、CPU32が特定した会員IDに関連付けられた会員情報(例えば、図4の「氏名」フィールド、及び、「住所」フィールドの情報)が表示される。

0144

クライアント端末10−2は、リワード完了リクエスト(S136)を実行する。
具体的には、プロジェクトオーナが、報酬をチケットオーナ宛に発送した後、入力部13を用いて、図22の画面P431の「完了」ボタンB431を指定すると、CPU12は、リワード完了リクエストをサーバ30に送信する。リワード完了リクエストは、指定された「選択」ボタンB430aに関連付けられたチケットIDを含む。

0145

サーバ30は、データベースの更新(S331)を実行する。
具体的には、CPU32は、図8のチケットデータベースにおいて、クライアント端末10−2から送信されたリワード完了リクエストに含まれるチケットIDに関連付けられた「ステータス」フィールドにステータスコード「STA4」を格納する。これにより、チケットのステータスは、利用中状態から利用済状態になる。

0146

以上の処理により、チケット利用の処理が終了する。

0147

(1−6−5)チケット譲渡の処理(1)のフロー(図27
第1実施形態のチケット譲渡の処理の第1例について説明する。図27は、第1実施形態のチケット譲渡の処理の第1例のシーケンス図である。

0148

図27のクライアント端末10−1のユーザは、チケットオーナ(会員ID「CU001」)である。クライアント端末10−2のユーザは、会員ユーザ(会員ID「CU999」)である。

0149

はじめに、クライアント端末10−1〜10−2は、図23と同様に、トップ画面の表示(S100)を実行する。
クライアント端末10−1〜10−2は、図25と同様に、ログインリクエスト(S120)を実行する。
サーバ30は、図25と同様に、ログインリクエスト(S120)に対するログイン認証(S320)を実行する。
クライアント端末10−1〜10−2は、図25と同様に、会員ホーム画面の表示(S121)を実行する。
クライアント端末10−1は、図26と同様に、チケット一覧画面の表示(S130)を実行する。

0150

クライアント端末10−1は、チケット譲渡画面の表示(S140)を実行する。
具体的には、チケットオーナが、入力部13を用いて、図14の画面P320の「譲渡」ボタンB320cを指定すると、CPU12は、サーバ30と通信することによって、図15の画面P322を表示部14に表示する。画面P322には、「譲渡」ボタンB320cに関連付けられたチケットIDに関連する情報(例えば、プロジェクト名、リワード名、及び、チケット金額)と、当該チケットIDによって識別されるチケットを譲渡するために必要なURLとが表示される。
チケットオーナが、入力部13を用いて、画面P322の入力フィールドF322aに譲受人の会員IDを入力し、かつ、「完了」ボタンB322を指定すると、CPU12は、チケット譲渡リクエストをサーバ30に送信する。チケット譲渡リクエストは、ログインリクエストに含まれる会員ID「CU001」と、「譲渡」ボタンB320cに関連付けられたチケットIDと、入力フィールドF322aに入力された会員ID「CU999」とを含む。

0151

サーバ30は、データベースの更新(S340)を実行する。
具体的には、CPU32は、図8のチケットデータベースにおいて、チケット譲渡リクエトに含まれるチケットIDに関連付けられた「ステータス」フィールドにステータスコード「STA2」を格納する。これにより、チケットのステータスは、譲渡中状態になる。

0152

クライアント端末10−2は、チケット受取画面の表示(S142)を実行する。
具体的には、譲受人が、入力部13を用いて、図13の画面P310の「チケット受取」ボタンB310cを指定すると、CPU12は、サーバ30と通信することによって、図16の画面P330を表示部14に表示する。画面P330には、チケット譲渡リクエストに含まれるチケットIDに関連付けられた受取用URLが予め表示される。

0153

クライアント端末10−2は、チケット受取リクエスト(S143)を実行する。
具体的には、譲受人が、図16の画面P330の入力フィールドF330aに表示された受取用URLを指定(例えば、入力フィールドF330aに予め表示された受取用URLをクリック、又は、入力フィールドF330aに受取用URLを入力)すると、CPU12は、チケット受取リクエストをサーバ30に送信する。チケット受取リクエストは、受取用URLと、譲受人を識別する会員ID「CU999」とを含む。

0154

サーバ30は、データベースの更新(S341)を実行する。
具体的には、CPU32は、図8のチケットデータベースにおいて、クライアント端末10−2から送信されたチケット受取リクエストに含まれる受取用URLに関連付けられたチケットIDを含むレコードを特定する。
次に、CPU32は、特定したレコードの「トークン期限」フィールドの値が示す期限をS143の実行日が過ぎていない場合、当該レコードの「チケットオーナ」フィールドに、譲受人を識別する会員ID「CU999」を格納する。これにより、チケットオーナが譲受人(会員ID「999」)に変わる。
次に、CPU32は、チケットデータベースにおいて、特定したレコードの「ステータス」フィールドに、ステータスコード「STA1」を格納する。これにより、チケットのステータスは、利用可能状態になる。
次に、CPU32は、受取用URLに関連付けられたチケットIDに関連付けられた譲渡履歴データベース(図10)に新規レコードを追加する。新規レコードの「登録日」フィールドには、S341の実行日「2016/01/10」を示す値が格納される。新規レコードの「譲渡人ID」フィールドには、譲渡人を識別する会員ID「CU001」が格納される。新規レコードの「譲受人ID」フィールドには、譲受人を識別する会員ID「CU999」が格納される。これにより、チケットの譲渡履歴が更新される。

0155

このように、サーバ30は、チケット譲渡リクエスト(S141)が行われてからチケット受取リクエスト(S143)が行われるまでの間、譲渡されるチケットを利用できないようにする。
また、サーバ30は、チケット譲渡の処理を実行する毎に、チケットの譲渡履歴を更新する。

0156

以上の処理により、チケット譲渡の処理が終了する。

0157

(1−6−6)チケット譲渡の処理(2)のフロー(図28
第1実施形態のチケット譲渡の処理の第2例について説明する。図28は、第1実施形態のチケット譲渡の処理の第2例のシーケンス図である。

0158

図28のクライアント端末10−1のユーザは、チケットオーナ(会員ID「CU001」)である。クライアント端末10−2のユーザは、非会員ユーザである。

0159

はじめに、クライアント端末10−1は、図23と同様に、トップ画面の表示(S100)を実行する。
クライアント端末10−1は、図25と同様に、ログインリクエスト(S120)を実行する。
サーバ30は、図25と同様に、ログインリクエスト(S120)に対するログイン認証(S320)を実行する。
クライアント端末10−1は、それぞれ、図25及び図26と同様に、会員ホーム画面の表示(S121)及びチケット一覧画面の表示(S130)を実行する。

0160

クライアント端末10−1は、チケット発行画面の表示(S150)を実行する。
具体的には、チケットオーナが、入力部13を用いて、図14の画面P320の「発行」ボタンB320eを指定すると、CPU12は、サーバ30と通信することによって、図17の画面P340を表示部14に表示する。
次に、チケットオーナが、入力部13を用いて、画面P340の入力フィールドF340に譲受人の氏名、メールアドレス、及び、住所を入力し、かつ、「完了」ボタンB340を指定すると、CPU12は、チケット発行リクエストをサーバ30に送信する。チケット発行リクエストは、入力フィールドF340に入力された情報と、「発行」ボタンB320eに関連付けられたチケットID「TI001」とを含む。

0161

サーバ30は、紙チケットの発行(S350)を実行する。
具体的には、CPU32は、図8のチケットデータベースにおいて、チケット発行リクエトに含まれるチケットIDに関連付けられたトークンと、当該チケットIDに関連付けられたプロジェクト名、及び、リワード名とを紙チケットに印刷する。
サーバ30のオペレータは、チケット発行リクエトに含まれる入力フィールドF340の情報(譲受人の氏名、及び、住所)宛に、印刷された紙チケットを発送する。

0162

サーバ30は、データベースの更新(S351)を実行する。
具体的には、CPU32は、図8のチケットデータベースにおいて、チケット発行リクエトに含まれるチケットIDに関連付けられた「受取用トークン」フィールドに新しい受取用トークンを示す情報を格納し、かつ、「トークン期限」フィールドに新しい期限日を示す値を格納する。
次に、CPU32は、チケットデータベースにおいて、チケット発行リクエトに含まれるチケットIDに関連付けられた「ステータス」フィールドにステータスコード「STA2」を格納する。これにより、チケットのステータスは、利用可能状態から譲渡中状態になる。

0163

クライアント端末10−2は、チケット受取画面の表示(S152)を実行する。
具体的には、譲受人が、入力部13を用いて、所定のURLにアクセスすると、CPU12は、サーバ30と通信することによって、図18の画面P350を表示部14に表示する。

0164

クライアント端末10−2は、チケット受取リクエスト(S153)を実行する。
具体的には、譲受人が、図18の画面P350の入力フィールドF350に、紙チケットに印刷された受取用トークン「123456」を入力し、かつ、「会員登録」ボタン350aを指定すると、CPU12は、チケット受取リクエストをサーバ30に送信する。チケット受取リクエストは、入力フィールドF350に入力された受取用トークンを含む。

0165

クライアント端末10−2は、図23と同様に、会員登録画面の表示(S101)、及び、会員登録リクエスト(S102)を実行する。

0166

サーバ30は、データベースの更新(S352)を実行する。
具体的には、CPU32は、図4の会員データベースに新規レコードを追加する。新規レコードの「会員ID」フィールドには、新しい会員ID「CU999」が格納される。新規レコードの「メールアドレス」フィールド、「パスワード」フィールド、「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドには、それぞれ、会員登録リクエストに含まれる情報(氏名、メールアドレス、パスワード、画像、住所、及び、支払情報)が格納される。
次に、CPU32は、図8のチケットデータベースにおいて、クライアント端末10−2から送信されたチケット受取リクエストに含まれる受取用トークンに関連付けられたチケットIDに関連付けられた「チケットオーナ」フィールドに、会員データベースの新規レコードに含まれる会員ID「CU999」を格納する。これにより、チケットオーナが譲受人(会員ID「999」)に変わる。
次に、CPU32は、チケットデータベースにおいて、特定したレコードの「ステータス」フィールドに、ステータスコード「STA1」を格納する。これにより、チケットのステータスは、利用可能状態になる。
次に、CPU32は、チケットデータベースにおいて、受取用トークンに関連付けられたチケットIDを特定する。
次に、CPU32は、特定したチケットIDに関連付けられた譲渡履歴データベース(図10)に新規レコードを追加する。新規レコードの「登録日」フィールドには、S352の実行日「2016/01/10」を示す値が格納される。新規レコードの「譲渡人ID」フィールドには、譲渡人を識別する会員ID「CU001」が格納される。新規レコードの「譲受人ID」フィールドには、譲受人を識別する会員ID「CU999」が格納される。これにより、チケットの譲渡履歴が更新される。

0167

このように、サーバ30は、チケット発行リクエスト(S151)が行われてからチケット受取リクエスト(S153)及び会員登録リクエスト(S102)が行われるまでの間、譲渡されるチケットを利用できないようにする。
また、サーバ30は、チケット譲渡の処理を実行する毎に、チケットの譲渡履歴を更新する。

0168

以上の処理により、チケット譲渡の処理が終了する。

0169

(1−6−7)プロジェクト編集の処理のフロー(図29
第1実施形態のプロジェクト編集の処理について説明する。図29は、第1実施形態のプロジェクト編集の処理のシーケンス図である。

0170

図29のクライアント端末10のユーザは、プロジェクトオーナ(会員ID「CU001」)である。

0171

はじめに、クライアント端末10は、図23と同様に、トップ画面の表示(S100)を実行する。
クライアント端末10は、図26と同様に、ログインリクエスト(S133)を実行する。
サーバ30は、図26と同様に、ログインリクエスト(S133)に対するログイン認証(S320)を実行する。
クライアント端末10は、図26と同様に、プロジェクトオーナホーム画面の表示(S134)を実行する。

0172

クライアント端末10は、プロジェクト管理画面の表示(S160)を実行する。
具体的には、プロジェクトオーナが、入力部13を用いて、図19の画面P410の「プロジェクト管理」ボタンB410aを指定すると、CPU12は、サーバ30と通信することによって、画面P411を表示部14に表示する。画面P411には、選択可能なプロジェクトに関するプロジェクト情報(例えば、図5のプロジェクトデータベースにおいて、ログインリクエストに含まれるプロジェクトオーナIDに関連付けられた「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、及び、「画像」フィールドの情報)が表示される。

0173

クライアント端末10は、プロジェクト編集画面の表示(S161)を実行する。
具体的には、プロジェクトオーナが、入力部13を用いて、図19の画面P411の「編集」ボタンB411aを指定すると、CPU12は、サーバ30と通信することによって、画面P412を表示部14に表示する。

0174

クライアント端末10は、プロジェクト編集リクエスト(S162)を実行する。
具体的には、プロジェクトオーナが、入力部13を用いて、図19の画面P412の入力フィールド(不図示)に所定の情報を入力し、かつ、「完了」ボタン(不図示)を指定すると、CPU12は、プロジェクト編集リクエストをサーバ30に送信する。プロジェクト編集リクエストは、「編集」ボタンB411aに関連付けられたプロジェクトIDと、画面P412の入力フィールドに入力された情報とを含む。

0175

サーバ30は、プロジェクトの審査(S360)を実行する。
具体的には、CPU32は、記憶装置31に記憶された要件情報に基づいて、プロジェクト編集リクエストに含まれる情報がプロジェクト要件を満たすか否かを審査する。
「要件情報」とは、プロジェクトとして登録するための要件を示す情報である。
なお、プロジェクト編集リクエストに含まれる情報の一部がプロジェクト要件を満たすか否かを、サーバ30のオペレータが審査してもよい。この場合、CPU32が、プロジェクト編集リクエストに含まれる情報の一部について審査を行い、オペレータが、残りの部分について審査を行う。

0176

サーバ30は、データベースの更新(S361)を実行する。
具体的には、プロジェクト編集リクエストに含まれる情報がプロジェクト要件を満たす場合、CPU32は、図5のプロジェクトデータベースにおいて、プロジェクト編集リクエストに含まれる情報に基づいて、プロジェクト編集リクエストに含まれるプロジェクトIDに関連付けられたレコードを更新する。

0177

以上の処理により、プロジェクト編集の処理が終了する。

0178

(1−6−8)返金の処理のフロー(図30
第1実施形態の返金の処理について説明する。図30は、第1実施形態の返金の処理のシーケンス図である。

0179

図30のクライアント端末10のユーザは、チケットオーナ(会員ID「CU001」)である。

0180

はじめに、サーバ30は、プロジェクトの返金条件の判定(S370)を実行する。
具体的には、CPU32は、一定期間毎に、図5のレコードのうち、「タイプ」フィールドにタイプコード「AN」が格納されたレコードについて、返金条件が成立したか否かを判定する。返金条件は、例えば、「終了日」フィールドに格納された値が示す終了日前に、支援金額の合計が「目標金額」フィールドの値に到達しなかった場合に成立する。

0181

返金条件が成立した場合(S371:YES)、サーバ30は、返金通知(S372)を実行する。
具体的には、CPU32は、返金条件が成立したプロジェクトを識別するプロジェクトIDに関連付けられたリワードデータベース(図8)を特定する。
次に、CPU32は、図4の会員データベースを参照して、特定したリワードデータベースの「チケットオーナID」フィールドに格納された会員IDに関連付けられたレコードを特定する。
次に、CPU32は、特定したレコードの「メールアドレス」フィールドに格納されたメールアドレス宛にメールを送信する。このメールには、返金リクエストを実行するためのウェブページのURLが示される。

0182

クライアント端末10は、ログインリクエスト(S170)を実行する。
具体的には、チケットオーナが、入力部13を用いて、S372において送信されたメールに示されたURLを指定すると、CPU12は、ログインリクエストをサーバ30に送信する。ログインリクエストは、S372において特定されたリワードデータベースの「チケットオーナID」フィールドに格納された会員IDを含む。

0183

サーバ30は、図25と同様に、ログインリクエスト(S120)に対するログイン認証(S320)を実行する。

0184

クライアント端末10は、返金画面の表示(S171)を実行する。
具体的には、CPU12は、サーバ30と通信を行うことによって、返金リクエストを実行するためのウェブページを表示部14に表示する。

0185

クライアント端末10は、返金リクエスト(S172)を実行する。
具体的には、チケットオーナが、入力部13を用いて、返金画面において返金先の口座情報(例えば、銀行名、支店名、口座番号、及び、口座名義人を示す情報)を入力すると、CPU12は、返金リクエストをサーバ30に送信する。返金リクエストは、返金口座情報と、ログインリクエストに含まれる会員IDとを含む。

0186

サーバ30は、返金(S373)を実行する。
具体的には、CPU32は、返金リクエストに含まれる返金口座情報に対応する口座に支援金額を振り込む。

0187

サーバ30は、データベースの更新(S374)を実行する。
具体的には、CPU32は、図5のプロジェクトデータベースにおいて、返金条件が成立したプロジェクトを識別するプロジェクトIDに関連付けられた「タイプ」フィールドに、終了したプロジェクトであることを示すタイプコード「FIN」を格納する。

0188

以上の処理により、返金の処理が終了する。

0189

(1−7)小括
第1実施形態について小括する。

0190

CPU32(情報処理装置の一例)は、クラウドファンディングの会員を識別する会員ID(ユーザ識別情報の一例)と、クラウドファンディングのプロジェクトを識別するプロジェクトID(プロジェクト識別情報の一例)とを記憶する記憶装置31にアクセス可能である。
CPU32は、チケットオーナ(第1ユーザの一例)の指示に応じて、チケットオーナを識別する会員ID(第1ユーザ識別情報の一例)と、プロジェクトIDとに、プロジェクトへの支援金額を示す情報を関連付けて記憶する(例えば、S322の処理)。
また、CPU32は、チケットオーナを識別する会員IDに、プロジェクトへの支援に対するチケットID(チケット識別情報の一例)を関連付けて記憶する(例えば、S322の処理)。
チケットオーナからの指示に応じて、チケットオーナを識別する会員IDとチケットIDとの関連付けを解除し、かつ、チケットオーナによって指定された会員ユーザを識別する会員ID(第2ユーザ識別情報の一例)にチケットIDを関連付けて記憶する(例えば、S141〜S341の処理)。

0191

これにより、プロジェクトに支援した会員は、報酬を受け取る権利を他の会員に譲渡することができる。
したがって、プロジェクトに支援した会員は、他の会員に譲渡する際に金銭取引を行うことによって、支援金額を回収することができる。
また、他の会員は、プロジェクトの支援の受け付けが終了した後も、当該プロジェクトの報酬を受け取る権利を確保することができる。
つまり、本実施形態によれば、クラウドファンディングにおいて、プロジェクトの報酬を受け取る権利のn(nは2以上の整数次流通を実現することができる。その結果、クラウドファンディングの利便性が高くなるので、クラウドファンディングの普及が促進される。

0192

さらに、CPU32は、チケットを譲り受けた会員(第2ユーザの一例)の指示に応じて、チケットを譲り受けた会員を識別する会員ID(第2ユーザ識別情報の一例)とチケットIDとの関連付けを解除し、かつ、チケットを譲り受けた会員によって指定された譲受人(第3ユーザの一例)を識別する会員ID(第3ユーザ識別情報の一例)にチケットIDを関連付けて記憶する(例えば、S141〜S142の処理)。

0193

さらに、CPU32は、チケット譲渡の処理を実行する度に、チケットIDに、譲渡人を識別する会員ID(指示を与えたユーザを識別するユーザ識別情報の一例)と、譲受人を識別する会員ID(指示を与えたユーザによって指定されたユーザを識別するユーザ識別情報の一例)との組合せを関連付けて記憶する(例えば、S341の処理)。

0194

これにより、チケットの流通経路を容易に知ることができる。
チケットの流通経路は、プロジェクトオーナにとって、プロジェクトに有益な事項(例えば、プロジェクトに対する関心の大きさ、プロジェクトに関心を持っているユーザの傾向等)を特定する上で有益な情報である。

0195

さらに、CPU32は、チケットオーナの指示に応じて、譲受人(チケットオーナ以外のユーザの一例)がチケットを譲り受けるために必要な受取用トークン(譲渡情報の一例)が印刷された紙チケットを発行する(例えば、S350の処理)。

0196

これにより、チケットの流通形態を多様化することができる。
例えば、チケットオーナは、紙チケットをイーコマースや金券を取り扱う小売店を介して、クラウドファンディングサービスの非会員ユーザに売却することができる。
また、紙チケットを受け取った非会員ユーザをクラウドファンディングサービスへの会員登録に誘導することによって、クラウドファンディングサービスの会員数を増やすことができる。

0197

さらに、CPU32は、紙チケットを受け取ったユーザ(チケットオーナ以外のユーザの一例)によって、紙チケットに印刷された受取用トークンが入力された場合、チケットオーナを識別する会員IDとチケットIDとの関連付けを解除し、かつ、受取用トークンを入力した会員を識別する会員識別情報にチケットIDを関連付けて記憶する(例えば、S152〜S352の処理)。

0198

さらに、CPU32は、チケットオーナを識別する会員IDとチケットIDとの対応付けを解除してから、受取用トークンを入力した会員を識別する会員IDにチケットIDを関連付けて記憶するまでの間(例えば、S350〜S352の間)、チケットを利用できない状態にする(例えば、S351の処理)。

0199

これにより、紙チケットを発行してから譲受人がチケットオーナになるまでの間のチケットの不正利用を防ぐことができる。

0200

(2)その他の変形例
上述の実施形態では、クライアント端末10にインストールされたウェブブラウザと、サーバ30とがhttps通信を行うことによって情報処理が実現される例について説明したが、本実施形態はこれに限られるものではない。
例えば、本実施形態の情報処理は、クライアント端末10にインストールされた専用アプリケーション(ブラウザ以外のアプリケーション)と、サーバ30とがhttps通信を行うことによっても実現可能である。
また、本実施形態の情報処理は、専用アプリケーションのみによって実現されてもよい。この場合、クライアント端末10とサーバ30との間の通信は不要である。
また、本実施形態の通信方式は、https通信に限られるものではない。

0201

上述の実施形態では、サーバ30に設けられた記憶装置31にデータベースを記憶する例について説明したが、本実施形態はこれに限られるものではない。
例えば、本実施形態の情報処理は、サーバ30の外部に設けられた記憶装置にデータベースを記憶する(つまり、CPU32は、通信インタフェース35を介してデータベースにアクセスする)場合にも適用可能である。

0202

以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態及び変形例は、組合せ可能である。

0203

1 :情報処理システム
10 :クライアント端末
11 :記憶装置
12 :CPU
13 :入力部
14 :表示部
15 :通信インタフェース
30 :サーバ
31 :記憶装置
32 :CPU
33 :入力部
34 :表示部
35 :通信インタフェース

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ