JP2019091503A - 情報処理装置 - Google Patents

Abstract

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

Description

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

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

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

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

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

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

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

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

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

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

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

図１に示すように、情報処理システム１は、クライアント端末１０（１０−１〜１０−ｎ）と、サーバ３０とを備える。
クライアント端末１０と、サーバ３０とは、通信網ＮＷ（例えば、インターネット）を介して、通信（例えば、ｈｔｔｐｓ通信）を行うことができる。

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

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

図２に示すように、クライアント端末１０は、ＣＰＵ（Central Processing Unit）１１と、記憶装置１１と、入力部１３と、表示部１４と、通信インタフェース１５とを備える。

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

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

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

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

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

（１−３）サーバの構成（図３）
第１実施形態のサーバの構成について説明する。図３は、第１実施形態のサーバの構成を示す図である。

図３に示すように、サーバ３０は、記憶装置３１と、ＣＰＵ３２と、入力部３３と、表示部３４と、通信インタフェース３５とを備える。

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

ＣＰＵ３２は、記憶装置３１に記憶されたプログラムを起動することによって、サーバ３０の機能を実現するように構成される。

入力部３３及び表示部３４は、それぞれ、図２の入力部１３及び表示部１４と同様である。

通信インタフェース３５は、サーバ３０と通信網ＮＷとの間の通信を制御するように構成される。

（１−４）データベースのデータ構造（図４〜図７）
第１実施形態のデータベースのデータ構造について説明する。

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

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

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

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

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

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

（１−４−２）プロジェクトデータベース（図５）
第１実施形態のプロジェクトデータベースのデータ構造について説明する。図５は、第１実施形態のプロジェクトデータベースのデータ構造の一例を示す図である。

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

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

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

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

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

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

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

（１−４−３）リワードデータベース（図６）
第１実施形態のリワードデータベースのデータ構造について説明する。図６は、第１実施形態のリワードデータベースのデータ構造の一例を示す図である。

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

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

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

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

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

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

（１−４−４）支援履歴データベース（図７）
第１実施形態のリワードデータベースのデータ構造について説明する。図７は、第１実施形態の支援履歴データベースのデータ構造の一例を示す図である。

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

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

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

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

（１−４−５）チケットデータベース（図８〜図９）
第１実施形態のチケットデータベースのデータ構造について説明する。図８は、第１実施形態のチケットデータベースのデータ構造の一例を示す図である。

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

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

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

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

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

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

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

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

図９に示すように、ステータスコードは、第１ステータスを示すコード「ＳＴＡ１」、第２ステータスを示すコード「ＳＴＡ２」、第３ステータスを示すコード「ＳＴＡ３」、及び、第４ステータスを示すコード「ＳＴＡ４」の何れかである。

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

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

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

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

（１−４−６）譲渡履歴データベース（図１０）
第１実施形態の譲渡履歴データベースのデータ構造について説明する。図１０は、第１実施形態の譲渡履歴データベースのデータ構造の一例を示す図である。

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

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

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

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

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

（１−５）情報処理において表示される画面（図１１〜図２２）
第１実施形態の情報処理において表示される画面について説明する。図１１〜図２２は、第１実施形態の情報処理において表示される画面の例を示す図である。
図１１〜図２２の画面は、クライアント端末１０の表示部１４に表示される。各画面では、ユーザは、入力部１３を用いて指示（入力フィールドへの入力、及び、ボタンの指定）を与えることができる。与えられた指示は、クライアント端末１０からサーバ３０に送信される。

図１１の画面Ｐ１００は、トップ画面用のＵＲＬ（Uniform Resource Locator）にアクセスされたときに表示される画面である。
画面Ｐ１００は、「会員登録」ボタンＢ１００ａと、「プロジェクト作成」ボタンＢ１００ｂと、「ログイン」ボタンＢ１００ｃとを含む。

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

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

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

画面Ｐ２１０において入力フィールドＦ２１０ａ〜Ｆ２１０ｂに情報が入力され、かつ、「完了」ボタンＢ２１０が指定されると、クライアント端末１０は、サーバ３０に、プロジェクト作成の処理のリクエスト（以下「プロジェクト作成リクエスト」という）を送信する。

図１１の画面Ｐ１００において「ログイン」ボタンＢ１００ｃが指定され、かつ、会員ＩＤ（例えば、会員ＩＤ「ＣＵ００１」）及びパスワードが入力されると、図１３の画面Ｐ３１０が表示される。
画面Ｐ３１０は、「支援」ボタンＢ３１０ａと、「所有チケット一覧」ボタンＢ３１０ｂと、「チケット受取」ボタンＢ３１０ｃとを含む。

画面Ｐ３１０において「支援」ボタンＢ３１０ａが指定されると、画面Ｐ３１１が表示される。
画面Ｐ３１１は、画像ＩＭＧ３１１ａ〜ＩＭＧ３１１ｂと、領域Ａ３１１ａ〜Ａ３１１ｂと、「選択」ボタンＢ３１１ａ〜Ｂ３１１ｂとを含む。
画像ＩＭＧ３１１ａ〜ＩＭＧ３１１ｂは、支援の対象となるプロジェクトの画像（例えば、図５の「画像」フィールドに格納された画像データに対応する画像）である。
領域Ａ３１１ａ〜Ａ３１１ｂには、プロジェクト情報（例えば、プロジェクト名、参加者数、残り日数、及び、達成金額）が表示される。「プロジェクト名」は、例えば、図５の「プロジェクト名」フィールドの情報である。「参加者数」は、プロジェクトを支援している会員の数（例えば、図６の「チケット配布数」フィールドの値）である。「残り日数」は、プロジェクトの終了日迄の残り日数（例えば、図５の「終了日」フィールドと画面Ｐ３１０が表示された日との差）である。「達成金額」は、支援金額の総額（例えば、図６の「チケット配布数」フィールドの値と、「チケット金額」フィールドの値との積）である。
「選択」ボタンＢ３１１ａ〜Ｂ３１１ｂは、それぞれ、領域Ａ３１１ａ〜Ａ３１１ｂに表示されたプロジェクト情報に関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」〜「ＰＲ００２」）に関連付けられている。

画面Ｐ３１１において「選択」ボタンＢ３１１ａが指定されると、画面Ｐ３１２が表示される。
画面Ｐ３１２は、領域Ａ３１２と、入力フィールドＦ３１２と、「完了」ボタンＢ３１２とを含む。
領域Ａ３１２には、「選択」ボタンＢ３１１ａに関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」）に関連付けられたリワード情報が表示される。「リワード名」は、例えば、図６の「リワード名」フィールドの情報である。「チケット金額」は、例えば、図６の「チケット金額」フィールドの値である。
入力フィールドＦ３１２は、取得を希望するチケットの数量を入力するための入力フィールドである。

画面Ｐ３１２において入力フィールドＦ３１２に情報が入力され、かつ、「完了」ボタンＢ３１２が指定されると、クライアント端末１０は、サーバ３０に、支援の処理のリクエスト（以下「支援リクエスト」という）を送信する。

画面Ｐ３１０において「所有チケット一覧」ボタンＢ３１０ｂが指定されると、図１４の画面Ｐ３２０が表示される。
画面Ｐ３２０は、領域Ａ３２０ａ〜Ａ３２０ｂと、「利用」ボタンＢ３２０ａ〜Ｂ３２０ｂと、「譲渡」ボタンＢ３２０ｃ〜Ｂ３２０ｄと、「発行」ボタンＢ３２０ｅ〜Ｂ３２０ｆとを含む。
領域Ａ３２０ａ〜Ａ３２０ｂには、会員が所有しているチケットに関するチケット情報が表示される。「プロジェクト名」は、例えば、図５の「プロジェクト名」フィールドの情報である。「リワード名」は、例えば、図６の「リワード名」フィールドの情報である。「チケット金額」は、例えば、図６の「チケット金額」フィールドの値である。
「利用」ボタンＢ３２０ａ〜Ｂ３２０ｂは、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたチケット情報に対応するチケットＩＤ（例えば、チケットＩＤ「ＴＩ００１」〜「ＴＩ００２」）に関連付けられている。
「譲渡」ボタンＢ３２０ｃ〜Ｂ３２０ｄは、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたリワード情報に対応するリワードＩＤに関連付けられている。
「発行」ボタンＢ３２０ｅ〜Ｂ３２０ｆは、それぞれ、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたリワード情報に対応するリワードＩＤに関連付けられている。

画面Ｐ３２０において「利用」ボタンＢ３２０ａが指定されると、画面Ｐ３２１が表示される。
画面Ｐ３２１は、領域Ａ３２０ａに表示された情報と、「ＹＥＳ」ボタンＢ３２１ａと、「ＮＯ」ボタンＢ３２１ｂとを含む。
「ＹＥＳ」ボタンＢ３２１ａが指定されると、クライアント端末１０は、サーバ３０に、「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤ（例えば、チケットＩＤ「ＴＩ００１」）によって識別されるチケットを利用するためのチケット利用リクエストを送信する。
「ＮＯ」ボタンＢ３２１ｂが指定されると、画面Ｐ３２０に戻る。

画面Ｐ３２０において「譲渡」ボタンＢ３２０ｃが指定されると、図１５の画面Ｐ３２２が表示される。
画面Ｐ３２２は、領域Ａ３２２ａ〜Ａ３２２ｂと、入力フィールドＦ３２２ａ〜Ｆ３２２ｂと、「完了」ボタンＢ３２２とを含む。
領域Ａ３２２ａには、図１４の領域Ａ３２０ａと同様の情報が表示される。
領域Ａ３２２ｂには、チケットを受け取るために必要なＵＲＬ（以下「受取用ＵＲＬ」という）が表示される。受取用ＵＲＬ「https://example.com/receive?token=ABCDEFG012345」は、チケットを受け取るための受取用トークン「ABCDEFG012345」を含む。
入力フィールドＦ３２２ａは、領域Ａ３２２ｂに表示されたＵＲＬの送信先となる会員（つまり、チケットの譲受人）の会員ＩＤを入力するための入力フィールドである。
入力フィールドＦ３２２ｂは、領域Ａ３２２ｂに表示されたＵＲＬの宛先となるメールアドレスを入力するための入力フィールドである。このメールアドレスは、図４の会員データベースにおいて会員ＩＤに関連付けられたメールアドレスであってもよいし、会員ＩＤに関連付けられていないメールアドレス（例えば、非会員ユーザのメールアドレス）であってもよい。

画面Ｐ３２２において入力フィールドＦ３２２ａに情報が入力され、かつ、「完了」ボタンＢ３２２が指定されると、クライアント端末１０は、サーバ３０に、チケットを譲渡するためのリクエスト（以下「チケット譲渡リクエスト」という）を送信する。

画面Ｐ３２２の入力フィールドＦ３２２ａに入力された会員ＩＤ（例えば、会員ＩＤ「ＣＵ９９９」）に基づいてログイン認証が行われると、図１６の画面Ｐ３３０が表示される。
画面Ｐ３３０は、入力フィールドＦ３３０ａ〜Ｆ３３０ｂと、「完了」ボタンＢ３３０とを含む。
入力フィールドＦ３３０ａは、受取用ＵＲＬを入力するための入力フィールドである。入力フィールドＦ３３０ａの受取用ＵＲＬは、予め入力されていてもよいし、ユーザが入力部１３を用いて入力してもよい。
入力フィールドＦ３３０ｂは、チケットを受け取るために必要なコード（以下「受取用コード」という）を入力するための入力フィールドである。

画面Ｐ３３０において入力フィールドＦ３３０ａ又はＦ３３０ｂに情報が入力され、かつ、「完了」ボタンＢ３３０が指定されると、クライアント端末１０は、サーバ３０に、チケットを受け取るためのリクエスト（以下「チケット受取リクエスト」という）を送信する。

図１４の画面Ｐ３２０において「発行」ボタンＢ３２０ｅが指定されると、図１７の画面Ｐ３４０が表示される。
画面Ｐ３４０は、入力フィールドＦ３４０と、「完了」ボタンＢ３４０とを含む。
入力フィールドＦ３４０は、譲受人の氏名、メールアドレス、及び、住所を入力するための入力フィールドである。

画面Ｐ３４０において入力フィールドＦ３４０に情報が入力され、かつ、「完了」ボタンＢ３４０が指定されると、クライアント端末１０は、サーバ３０に、チケットを発行するためのリクエスト（以下「チケット発行リクエスト」という）を送信する。

発行チケットを受け取ったユーザであって、かつ、会員ＩＤを有していないユーザ（以下「非会員ユーザ」という）によってチケット受取画面のＵＲＬにアクセスされると、図１８の画面Ｐ３５０が表示される。
画面Ｐ３５０は、入力フィールドＦ３５０ａ及びＦ３５０ｂと、「会員登録」ボタンＢ３５０ａ及び「ログイン」ボタンＢ３５０ｂとを含む。
入力フィールドＦ３５０ａ〜Ｆ３５０ｂは、それぞれ、図１６の入力フィールドＦ３３０ａ〜Ｆ３３０ｂと同様である。

入力フィールドＦ３５０ａ又はＦ３５０ｂに情報が入力され、かつ、「会員登録」ボタンＢ３５０ａが指定されると、図１１の画面Ｐ１１０が表示される。画面Ｐ１１０において入力フィールドＦ１１０に情報が入力され、かつ、「完了」ボタンＢ１１０が指定されると、クライアント端末１０は、サーバ３０に、会員登録リクエストと、チケット受取リクエストとを送信する。
入力フィールドＦ３５０ａ又はＦ３５０ｂに情報が入力され、かつ、「ログイン」ボタンＢ３５０ｂが指定されると、クライアント端末１０は、サーバ３０に、ログインリクエストと、チケット受取リクエストとを送信する。その結果、図１３の画面Ｐ３１０が表示される。

図１１の画面Ｐ１００において「ログイン」ボタンＢ１００ｃが指定され、かつ、プロジェクトオーナＩＤ（例えば、プロジェクトオーナＩＤ「ＰＯ００１」）及びパスワードが入力されると、図１９の画面Ｐ４１０が表示される。
画面Ｐ４１０は、「プロジェクト管理」ボタンＢ４１０ａは、「リワード管理」ボタンＢ４１０ｂと、「チケット管理」ボタンＢ４１０ｃとを含む。

画面Ｐ４１０において「プロジェクト管理」ボタンＢ４１０ａが指定されると、画面Ｐ４１１が表示される。
画面Ｐ４１１は、画像ＩＭＧ４１１ａ〜ＩＭＧ４１１ｂと、領域Ａ４１１ａ〜Ａ４１１ｂと、「編集ボタン」Ｂ４１１ａ〜Ｂ４１１ｂとを含む。
画像ＩＭＧ４１１ａ〜ＩＭＧ４１１ｂは、管理の対象となるプロジェクトの画像（例えば、図５の「画像」フィールドに格納された画像データに対応する画像）である。
領域Ａ４１１ａ〜Ａ４１１ｂには、プロジェクト情報（例えば、図５の「プロジェクト名」フィールド、「目標金額」フィールド、及び、「概要」フィールドの情報）が表示される。
「編集」ボタンＢ４１１ａ〜Ｂ４１１ｂは、それぞれ、領域Ａ４１１ａ〜Ａ４１１ｂに表示されたプロジェクト情報に関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」〜「ＰＲ００２」）に関連付けられている。

画面Ｐ４１１において「編集」ボタンＢ４１１ａが指定されると、クライアント端末１０は、サーバ３０に対して、「編集」ボタンＢ４１１ａに関連するプロジェクトＩＤに関連付けられたプロジェクト情報を編集するためのリクエスト（以下「プロジェクト編集リクエスト」という）を送信する。その結果、画面Ｐ４１２が表示される。図１９には図示していないが、画面Ｐ４１２は、図１２の画面Ｐ２１０と同様の入力フィールドＦ２１０ａ〜Ｆ２１０ｂと、「完了」ボタンＢ２１０とを含む。

画面Ｐ４１０において「リワード管理」ボタンＢ４１０ｂが指定されると、図２０の画面Ｐ４２０が表示される。
画面Ｐ４２０は、領域Ａ４２０と、「リワード作成」ボタンＢ４２０ａと、「選択」ボタンＢ４２０ｂ〜Ｂ４２０ｃとを含む。
領域Ａ４２０には、リワード情報（例えば、図６の「リワード名」フィールド、及び、「説明」フィールドの情報）が表示される。
「選択」ボタンＢ４２０ｂ〜Ｂ４２０ｃは、領域Ａ４２０に表示されたリワード情報に関連するリワードＩＤ（例えば、リワードＩＤ「ＲＷ００１」〜「ＲＷ００２」）に関連付けられている。

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

画面Ｐ４２１において入力フィールドＦ４２１に情報が入力され、かつ、「完了」ボタンＢ４２１が指定されると、クライアント端末１０は、サーバ３０に、リワード作成の処理のリクエスト（以下「リワード作成リクエスト」という）を送信する。

画面Ｐ４２０において、「編集」ボタンＢ４２０ｂが指定されると、図２１の画面Ｐ４２２が表示される。
画面Ｐ４２２は、入力フィールドＦ４２２と、「完了」ボタンＢ４２２とを含む。
入力フィールドＦ４２２は、リワード情報を編集するための入力フィールドである。

画面Ｐ４２２において入力フィールドＦ４２２に情報が入力され、かつ、「完了」ボタンＢ４２２が指定されると、クライアント端末１０は、サーバ３０に、リワード情報の編集のリクエスト（以下「リワード編集リクエスト」という）を送信する。

図１９の画面Ｐ４１０において「チケット管理」ボタンＢ４１０ｃが指定されると、図２２の画面Ｐ４３０が表示される。
画面Ｐ４３０は、領域Ａ４３０と、「選択」ボタンＢ４３０ａ〜Ｂ４３０ｂとを含む。
領域Ａ４３０には、チケット情報（例えば、図８の「チケットＩＤ」フィールド、「チケットオーナＩＤ」フィールド、及び、「ステータス」フィールドの情報）と、チケットタイトル（例えば、図６のリワードＩＤ「ＲＥ００１」に関連付けられた「リワード名」フィールドの情報）とが表示される。
「選択」ボタンＢ４３０ａ〜Ｂ４３０ｂは、それぞれ、領域Ａ４３０に表示されたチケットＩＤ「ＴＩ００１」〜「ＴＩ００２］に関連付けられている。

画面Ｐ４３０において「選択」ボタンＢ４２０ａが指定されると、画面Ｐ４３１が表示される。
画面Ｐ４３１は、領域Ａ４３１と、「完了」ボタンＢ４３１とを含む。
領域Ａ４３１には、報酬の発送先となる会員に関する会員情報（例えば、図４の「氏名」フィールド、及び、「住所」フィールドの情報）が表示される。

リワード（例えば、プロジェクトに関連する商品の発送）が完了した後に画面Ｐ４３１において「完了」ボタンＢ４３１が指定されると、クライアント端末１０は、サーバ３０に、チケットＩＤ「ＴＩ００１」によって識別されるチケットのステータスを変更するためのリワード完了リクエストを送信する。

（１−６）情報処理のフロー（図２３〜図３０）
第１実施形態の情報処理のフローについて説明する。以下の情報処理は、図２のＣＰＵ１２が記憶装置１１に記憶されたアプリケーション（例えば、ブラウザ）のプログラムを実行し、かつ、図３のＣＰＵ３２が記憶装置３１に記憶されたプログラムを実行することによって、実現される。
クライアント端末１０とサーバ３０とは、通信網ＮＷを介して、ｈｔｔｐｓ通信を行うことによって以下の情報処理を実現する。

（１−６−１）会員登録の処理のフロー（図２３）
第１実施形態の会員登録の処理について説明する。図２３は、第１実施形態の会員登録の処理のシーケンス図である。

図２３のクライアント端末１０のユーザは、非会員ユーザである。

はじめに、クライアント端末１０は、トップ画面の表示（Ｓ１００）を実行する。
具体的には、非会員ユーザが、入力部１３を用いて、トップ画面用のＵＲＬを指定すると、ＣＰＵ１２は、図１１の画面Ｐ１００を表示部１４に表示する。

クライアント端末１０は、会員登録画面の表示（Ｓ１０１）を実行する。
具体的には、非会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「会員登録」ボタンＢ１００ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ１１０を表示部１４に表示する。

クライアント端末１０は、会員リクエスト（Ｓ１０２）を実行する。
具体的には、非会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１１０の入力フィールドＦ１１０に情報を入力し、かつ、「完了」ボタンＢ１１０を指定すると、ＣＰＵ１２は、会員登録リクエストを作成する。会員登録リクエストは、入力フィールドＦ１１０に入力された情報を含む。
次に、ＣＰＵ１２は、会員登録リクエストをサーバ３０に送信する。

サーバ３０は、データベースの更新（Ｓ３００）を実行する。
具体的には、ＣＰＵ３２は、図４の会員データベースに新規レコードを追加する。新規レコードの「会員ＩＤ」フィールドには、新しい会員ＩＤが格納される。新規レコードの「メールアドレス」フィールド、「パスワード」フィールド、「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドには、それぞれ、会員登録リクエストに含まれる情報（氏名、メールアドレス、パスワード、画像、住所、及び、支払情報）が格納される。

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

（１−６−２）プロジェクト作成の処理のフロー（図２４）
第１実施形態のプロジェクト作成の処理について説明する。図２４は、第１実施形態のプロジェクト作成の処理のシーケンス図である。

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

はじめに、クライアント端末１０は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。

クライアント端末１０は、プロジェクト作成画面の表示（Ｓ１１０）を実行する。
具体的には、プロジェクト作成者が、入力部１３を用いて、図１１の画面Ｐ１００の「プロジェクト作成」ボタンＢ１００ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１２の画面Ｐ２１０を表示部１４に表示する。

クライアント端末１０は、プロジェクト作成リクエスト（Ｓ１１１）を実行する。
具体的には、プロジェクト作成者が、入力部１３を用いて、図１２の画面Ｐ２１０の入力フィールドＦ２１０ａ〜Ｆ２１０ｂに情報を入力し、かつ、「完了」ボタンＢ２１０を指定すると、ＣＰＵ１２は、プロジェクト作成リクエストを作成する。プロジェクト作成リクエストは、入力フィールドＦ２１０ａ〜Ｆ２１０ｂに入力された情報を含む。
次に、ＣＰＵ１２は、プロジェクト作成リクエストをサーバ３０に送信する。

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

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

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

（１−６−３）支援の処理のフロー（図２５）
第１実施形態の支援の処理について説明する。図２５は、第１実施形態の支援の処理のシーケンス図である。

図２５のクライアント端末１０のユーザは、会員ユーザ（会員ＩＤ「ＣＵ００１」名「会員１」）である。

はじめに、クライアント端末１０は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。

クライアント端末１０は、ログインリクエスト（Ｓ１２０）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「ログイン」ボタンＢ１００ｃを指定し、かつ、会員ＩＤ及びパスワードを入力すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、会員ＩＤ及びパスワードを含む。

サーバ３０は、ログイン認証（Ｓ３２０）を実行する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれる会員ＩＤ及びパスワードと、図４の会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれる会員ＩＤ及びパスワードと、会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致する場合、ＣＰＵ３２は、ログインを許可する。一方、ログインリクエストに含まれる会員ＩＤ及びパスワードと、会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致しない場合、ＣＰＵ３２は、ログインを拒否する。

ログインが許可されると、クライアント端末１０は、会員ホーム画面の表示（Ｓ１２１）を実行する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれる会員ＩＤに対応する会員ホーム画面を表示させるためのレスポンスをクライアント端末１０に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、図１３の画面Ｐ３１０を表示部１４に表示する。

クライアント端末１０は、プロジェクト選択画面の表示（Ｓ１２２）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１０の「支援」ボタンＢ３１０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ３１１を表示部１４に表示する。画面Ｐ３１１には、選択可能なプロジェクト（例えば、返金条件（後述する）を満たしていないプロジェクト）に関するプロジェクト情報が表示される。

クライアント端末１０は、リワード選択画面の表示（Ｓ１２３）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１１の「選択」ボタンＢ３１１ａを指定すると、ＣＰＵ１２は、リクエストをサーバ３０に送信する。このリクエストは、「選択」ボタンＢ３１１ａに関連付けられたプロジェクトＩＤ「ＰＲ００１」を含む。
次に、ＣＰＵ３２は、クライアント端末１０から送信されたリクエストに含まれるプロジェクトＩＤ「ＰＲ００１」に対応するプロジェクト選択画面を表示させるためのレスポンスをクライアント端末１０に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ３１２を表示部１４に表示する。画面Ｐ３１２には、選択可能なリワードに関するリワード情報（例えば、図６の「チケット配布数」フィールドの値が「チケット上限数」フィールドの値未満であるレコードの情報）が表示される。

クライアント端末１０は、支援リクエスト（Ｓ１２４）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１２の入力フィールドＦ３１２に、取得を希望するチケットの数量を入力し、かつ、「完了」ボタンＢ３１２を指定すると、ＣＰＵ１２は、支援リクエストを作成する。支援リクエストは、リワードＩＤと、リワードＩＤに対応する数量（入力フィールドＦ３１２に入力された情報）とを含む。
次に、ＣＰＵ１２は、支援リクエストをサーバ３０に送信する。

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

サーバ３０は、入金の確認に成功すると（Ｓ３２１−ＹＥＳ）、データベースの更新（Ｓ３２２）を実行する。
具体的には、ＣＰＵ３２は、支援リクエストに含まれる情報（リワードＩＤ、及び、リワードＩＤに対応する数量）に基づいて、図６のリワードデータベースの「チケット配布数」フィールドを更新する。
次に、ＣＰＵ３２は、図７の支援履歴データベースに新規レコードを追加する。新規レコードの「支援ＩＤ」フィールドには、新しい支援ＩＤが格納される。新規レコードの「支援金額」フィールドには、支援金額を示す値が格納される。新規レコードの「支援日」フィールドには、支援リクエスト（Ｓ１２４）の実行日を示す値が格納される。
次に、ＣＰＵ３２は、図８のチケットデータベースに新規レコードを追加する。新規レコードの「支援ＩＤ」フィールドには、支援履歴データベースの新規レコードの「支援ＩＤ」フィールドに格納された支援ＩＤが格納される。新規レコードの「ステータス」フィールドには、ステータスコード「ＳＴＡ１」が格納される。これにより、チケットのステータスは、利用可能状態になる。

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

（１−６−４）チケット利用の処理のフロー（図２６）
第１実施形態のチケット利用の処理について説明する。図２６は、第１実施形態のチケット利用の処理のシーケンス図である。

図２６のクライアント端末１０−１のユーザは、チケットオーナ（会員ＩＤ「ＣＵ００１」）である。クライアント端末１０−２のユーザは、プロジェクトオーナ（プロジェクトオーナＩＤ「ＰＯ００１」）である。

はじめに、クライアント端末１０−１〜１０−２は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０−１は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１は、図２５と同様に、会員ホーム画面の表示（Ｓ１２１）を実行する。

クライアント端末１０−１は、チケット一覧画面の表示（Ｓ１３０）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、図１３の画面Ｐ３１０の「所有チケット一覧」ボタンＢ３１０ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１４の画面Ｐ３２０を表示部１４に表示する。画面Ｐ３２０には、チケットオーナが所有するチケットのうち利用可能状態であるチケットに関するチケット情報（例えば、図８の「ステータス」フィールドにチケットコード「ＳＴＡ１」が格納されたレコードの情報）が表示される。

クライアント端末１０−１は、チケット利用画面の表示（Ｓ１３１）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「利用」ボタンＢ３２０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信を行うことによって、画面Ｐ３２１を表示部１４に表示する。画面Ｐ３２１には、「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤに関連する情報（例えば、プロジェクト名、リワード名、及び、チケット金額）が表示される。

クライアント端末１０−１は、チケット利用リクエスト（Ｓ１３２）を実行する。
具体的には、チケットオーナが、図１４の画面Ｐ３２１の「ＹＥＳ」ボタンＢ３２１ａを指定すると、ＣＰＵ１２は、チケット利用リクエストをサーバ３０に送信する。チケット利用リクエストは、画面Ｐ３２０において指定された「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤを含む。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−１から送信されたチケット利用リクエストに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ３」を格納する。これにより、チケットのステータスは、利用可能状態から利用中状態になる。

クライアント端末１０−２は、ログインリクエスト（Ｓ１３３）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「ログイン」ボタンＢ１００ｃを指定し、かつ、プロジェクトオーナＩＤ及びパスワードを入力すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、プロジェクトオーナＩＤ及びパスワードを含む。

サーバ３０は、ログインリクエスト（Ｓ１３３）に対するログイン認証（Ｓ３２０）を実行する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、図５のプロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、プロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とが一致する場合、ＣＰＵ３２は、ログインを許可する。一方、ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、プロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とが一致しない場合、ＣＰＵ３２は、ログインを拒否する。

ログインが許可されると、クライアント端末１０−２は、プロジェクトオーナホーム画面の表示（Ｓ１３４）を実行する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれるプロジェクトオーナＩＤに対応するプロジェクトオーナホーム画面を表示させるためのレスポンスをクライアント端末１０−２に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、図１９の画面Ｐ４１０を表示部１４に表示する。

Ｓ３３０の後に、クライアント端末１０−２は、チケット管理画面の表示（Ｓ１３５）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１０の「チケット管理」ボタンＢ４１０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図２２の画面Ｐ４３０を表示部１４に表示する。画面Ｐ４３０には、選択可能なチケットに関するチケット情報（例えば、図８のチケットデータベースの情報）が表示される。

クライアント端末１０−２は、リワード完了画面の表示（Ｓ１３６）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図２２の画面Ｐ４３０の「選択」ボタンＢ４３０ａを指定すると、ＣＰＵ１２は、リクエストをサーバ３０に送信する。このリクエストは、「選択」ボタンＢ４３０ａに関連付けられたチケットＩＤを含む。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいてクライアント端末１０−２から送信されたリクエストに含まれるチケットＩＤに関連付けられたチケットオーナＩＤ（つまり、チケットオーナを識別する会員ＩＤ）を特定する。
次に、ＣＰＵ３２は、特定した会員ＩＤに対応するリワード完了画面を表示させるためのレスポンスをクライアント端末１０−２に送信する。
ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ４３１を表示部１４に表示する。画面Ｐ４３１には、ＣＰＵ３２が特定した会員ＩＤに関連付けられた会員情報（例えば、図４の「氏名」フィールド、及び、「住所」フィールドの情報）が表示される。

クライアント端末１０−２は、リワード完了リクエスト（Ｓ１３６）を実行する。
具体的には、プロジェクトオーナが、報酬をチケットオーナ宛に発送した後、入力部１３を用いて、図２２の画面Ｐ４３１の「完了」ボタンＢ４３１を指定すると、ＣＰＵ１２は、リワード完了リクエストをサーバ３０に送信する。リワード完了リクエストは、指定された「選択」ボタンＢ４３０ａに関連付けられたチケットＩＤを含む。

サーバ３０は、データベースの更新（Ｓ３３１）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたリワード完了リクエストに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ４」を格納する。これにより、チケットのステータスは、利用中状態から利用済状態になる。

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

（１−６−５）チケット譲渡の処理（１）のフロー（図２７）
第１実施形態のチケット譲渡の処理の第１例について説明する。図２７は、第１実施形態のチケット譲渡の処理の第１例のシーケンス図である。

図２７のクライアント端末１０−１のユーザは、チケットオーナ（会員ＩＤ「ＣＵ００１」）である。クライアント端末１０−２のユーザは、会員ユーザ（会員ＩＤ「ＣＵ９９９」）である。

はじめに、クライアント端末１０−１〜１０−２は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０−１〜１０−２は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１〜１０−２は、図２５と同様に、会員ホーム画面の表示（Ｓ１２１）を実行する。
クライアント端末１０−１は、図２６と同様に、チケット一覧画面の表示（Ｓ１３０）を実行する。

クライアント端末１０−１は、チケット譲渡画面の表示（Ｓ１４０）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「譲渡」ボタンＢ３２０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１５の画面Ｐ３２２を表示部１４に表示する。画面Ｐ３２２には、「譲渡」ボタンＢ３２０ｃに関連付けられたチケットＩＤに関連する情報（例えば、プロジェクト名、リワード名、及び、チケット金額）と、当該チケットＩＤによって識別されるチケットを譲渡するために必要なＵＲＬとが表示される。
チケットオーナが、入力部１３を用いて、画面Ｐ３２２の入力フィールドＦ３２２ａに譲受人の会員ＩＤを入力し、かつ、「完了」ボタンＢ３２２を指定すると、ＣＰＵ１２は、チケット譲渡リクエストをサーバ３０に送信する。チケット譲渡リクエストは、ログインリクエストに含まれる会員ＩＤ「ＣＵ００１」と、「譲渡」ボタンＢ３２０ｃに関連付けられたチケットＩＤと、入力フィールドＦ３２２ａに入力された会員ＩＤ「ＣＵ９９９」とを含む。

サーバ３０は、データベースの更新（Ｓ３４０）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット譲渡リクエトに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ２」を格納する。これにより、チケットのステータスは、譲渡中状態になる。

クライアント端末１０−２は、チケット受取画面の表示（Ｓ１４２）を実行する。
具体的には、譲受人が、入力部１３を用いて、図１３の画面Ｐ３１０の「チケット受取」ボタンＢ３１０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１６の画面Ｐ３３０を表示部１４に表示する。画面Ｐ３３０には、チケット譲渡リクエストに含まれるチケットＩＤに関連付けられた受取用ＵＲＬが予め表示される。

クライアント端末１０−２は、チケット受取リクエスト（Ｓ１４３）を実行する。
具体的には、譲受人が、図１６の画面Ｐ３３０の入力フィールドＦ３３０ａに表示された受取用ＵＲＬを指定（例えば、入力フィールドＦ３３０ａに予め表示された受取用ＵＲＬをクリック、又は、入力フィールドＦ３３０ａに受取用ＵＲＬを入力）すると、ＣＰＵ１２は、チケット受取リクエストをサーバ３０に送信する。チケット受取リクエストは、受取用ＵＲＬと、譲受人を識別する会員ＩＤ「ＣＵ９９９」とを含む。

サーバ３０は、データベースの更新（Ｓ３４１）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたチケット受取リクエストに含まれる受取用ＵＲＬに関連付けられたチケットＩＤを含むレコードを特定する。
次に、ＣＰＵ３２は、特定したレコードの「トークン期限」フィールドの値が示す期限をＳ１４３の実行日が過ぎていない場合、当該レコードの「チケットオーナ」フィールドに、譲受人を識別する会員ＩＤ「ＣＵ９９９」を格納する。これにより、チケットオーナが譲受人（会員ＩＤ「９９９」）に変わる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、特定したレコードの「ステータス」フィールドに、ステータスコード「ＳＴＡ１」を格納する。これにより、チケットのステータスは、利用可能状態になる。
次に、ＣＰＵ３２は、受取用ＵＲＬに関連付けられたチケットＩＤに関連付けられた譲渡履歴データベース（図１０）に新規レコードを追加する。新規レコードの「登録日」フィールドには、Ｓ３４１の実行日「２０１６／０１／１０」を示す値が格納される。新規レコードの「譲渡人ＩＤ」フィールドには、譲渡人を識別する会員ＩＤ「ＣＵ００１」が格納される。新規レコードの「譲受人ＩＤ」フィールドには、譲受人を識別する会員ＩＤ「ＣＵ９９９」が格納される。これにより、チケットの譲渡履歴が更新される。

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

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

（１−６−６）チケット譲渡の処理（２）のフロー（図２８）
第１実施形態のチケット譲渡の処理の第２例について説明する。図２８は、第１実施形態のチケット譲渡の処理の第２例のシーケンス図である。

図２８のクライアント端末１０−１のユーザは、チケットオーナ（会員ＩＤ「ＣＵ００１」）である。クライアント端末１０−２のユーザは、非会員ユーザである。

はじめに、クライアント端末１０−１は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０−１は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１は、それぞれ、図２５及び図２６と同様に、会員ホーム画面の表示（Ｓ１２１）及びチケット一覧画面の表示（Ｓ１３０）を実行する。

クライアント端末１０−１は、チケット発行画面の表示（Ｓ１５０）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「発行」ボタンＢ３２０ｅを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１７の画面Ｐ３４０を表示部１４に表示する。
次に、チケットオーナが、入力部１３を用いて、画面Ｐ３４０の入力フィールドＦ３４０に譲受人の氏名、メールアドレス、及び、住所を入力し、かつ、「完了」ボタンＢ３４０を指定すると、ＣＰＵ１２は、チケット発行リクエストをサーバ３０に送信する。チケット発行リクエストは、入力フィールドＦ３４０に入力された情報と、「発行」ボタンＢ３２０ｅに関連付けられたチケットＩＤ「ＴＩ００１」とを含む。

サーバ３０は、紙チケットの発行（Ｓ３５０）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられたトークンと、当該チケットＩＤに関連付けられたプロジェクト名、及び、リワード名とを紙チケットに印刷する。
サーバ３０のオペレータは、チケット発行リクエトに含まれる入力フィールドＦ３４０の情報（譲受人の氏名、及び、住所）宛に、印刷された紙チケットを発送する。

サーバ３０は、データベースの更新（Ｓ３５１）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられた「受取用トークン」フィールドに新しい受取用トークンを示す情報を格納し、かつ、「トークン期限」フィールドに新しい期限日を示す値を格納する。
次に、ＣＰＵ３２は、チケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ２」を格納する。これにより、チケットのステータスは、利用可能状態から譲渡中状態になる。

クライアント端末１０−２は、チケット受取画面の表示（Ｓ１５２）を実行する。
具体的には、譲受人が、入力部１３を用いて、所定のＵＲＬにアクセスすると、ＣＰＵ１２は、サーバ３０と通信することによって、図１８の画面Ｐ３５０を表示部１４に表示する。

クライアント端末１０−２は、チケット受取リクエスト（Ｓ１５３）を実行する。
具体的には、譲受人が、図１８の画面Ｐ３５０の入力フィールドＦ３５０に、紙チケットに印刷された受取用トークン「123456」を入力し、かつ、「会員登録」ボタン３５０ａを指定すると、ＣＰＵ１２は、チケット受取リクエストをサーバ３０に送信する。チケット受取リクエストは、入力フィールドＦ３５０に入力された受取用トークンを含む。

クライアント端末１０−２は、図２３と同様に、会員登録画面の表示（Ｓ１０１）、及び、会員登録リクエスト（Ｓ１０２）を実行する。

サーバ３０は、データベースの更新（Ｓ３５２）を実行する。
具体的には、ＣＰＵ３２は、図４の会員データベースに新規レコードを追加する。新規レコードの「会員ＩＤ」フィールドには、新しい会員ＩＤ「ＣＵ９９９」が格納される。新規レコードの「メールアドレス」フィールド、「パスワード」フィールド、「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドには、それぞれ、会員登録リクエストに含まれる情報（氏名、メールアドレス、パスワード、画像、住所、及び、支払情報）が格納される。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたチケット受取リクエストに含まれる受取用トークンに関連付けられたチケットＩＤに関連付けられた「チケットオーナ」フィールドに、会員データベースの新規レコードに含まれる会員ＩＤ「ＣＵ９９９」を格納する。これにより、チケットオーナが譲受人（会員ＩＤ「９９９」）に変わる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、特定したレコードの「ステータス」フィールドに、ステータスコード「ＳＴＡ１」を格納する。これにより、チケットのステータスは、利用可能状態になる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、受取用トークンに関連付けられたチケットＩＤを特定する。
次に、ＣＰＵ３２は、特定したチケットＩＤに関連付けられた譲渡履歴データベース（図１０）に新規レコードを追加する。新規レコードの「登録日」フィールドには、Ｓ３５２の実行日「２０１６／０１／１０」を示す値が格納される。新規レコードの「譲渡人ＩＤ」フィールドには、譲渡人を識別する会員ＩＤ「ＣＵ００１」が格納される。新規レコードの「譲受人ＩＤ」フィールドには、譲受人を識別する会員ＩＤ「ＣＵ９９９」が格納される。これにより、チケットの譲渡履歴が更新される。

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

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

（１−６−７）プロジェクト編集の処理のフロー（図２９）
第１実施形態のプロジェクト編集の処理について説明する。図２９は、第１実施形態のプロジェクト編集の処理のシーケンス図である。

図２９のクライアント端末１０のユーザは、プロジェクトオーナ（会員ＩＤ「ＣＵ００１」）である。

はじめに、クライアント端末１０は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０は、図２６と同様に、ログインリクエスト（Ｓ１３３）を実行する。
サーバ３０は、図２６と同様に、ログインリクエスト（Ｓ１３３）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０は、図２６と同様に、プロジェクトオーナホーム画面の表示（Ｓ１３４）を実行する。

クライアント端末１０は、プロジェクト管理画面の表示（Ｓ１６０）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１０の「プロジェクト管理」ボタンＢ４１０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ４１１を表示部１４に表示する。画面Ｐ４１１には、選択可能なプロジェクトに関するプロジェクト情報（例えば、図５のプロジェクトデータベースにおいて、ログインリクエストに含まれるプロジェクトオーナＩＤに関連付けられた「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、及び、「画像」フィールドの情報）が表示される。

クライアント端末１０は、プロジェクト編集画面の表示（Ｓ１６１）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１１の「編集」ボタンＢ４１１ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ４１２を表示部１４に表示する。

クライアント端末１０は、プロジェクト編集リクエスト（Ｓ１６２）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１２の入力フィールド（不図示）に所定の情報を入力し、かつ、「完了」ボタン（不図示）を指定すると、ＣＰＵ１２は、プロジェクト編集リクエストをサーバ３０に送信する。プロジェクト編集リクエストは、「編集」ボタンＢ４１１ａに関連付けられたプロジェクトＩＤと、画面Ｐ４１２の入力フィールドに入力された情報とを含む。

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

サーバ３０は、データベースの更新（Ｓ３６１）を実行する。
具体的には、プロジェクト編集リクエストに含まれる情報がプロジェクト要件を満たす場合、ＣＰＵ３２は、図５のプロジェクトデータベースにおいて、プロジェクト編集リクエストに含まれる情報に基づいて、プロジェクト編集リクエストに含まれるプロジェクトＩＤに関連付けられたレコードを更新する。

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

（１−６−８）返金の処理のフロー（図３０）
第１実施形態の返金の処理について説明する。図３０は、第１実施形態の返金の処理のシーケンス図である。

図３０のクライアント端末１０のユーザは、チケットオーナ（会員ＩＤ「ＣＵ００１」）である。

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

返金条件が成立した場合（Ｓ３７１：ＹＥＳ）、サーバ３０は、返金通知（Ｓ３７２）を実行する。
具体的には、ＣＰＵ３２は、返金条件が成立したプロジェクトを識別するプロジェクトＩＤに関連付けられたリワードデータベース（図８）を特定する。
次に、ＣＰＵ３２は、図４の会員データベースを参照して、特定したリワードデータベースの「チケットオーナＩＤ」フィールドに格納された会員ＩＤに関連付けられたレコードを特定する。
次に、ＣＰＵ３２は、特定したレコードの「メールアドレス」フィールドに格納されたメールアドレス宛にメールを送信する。このメールには、返金リクエストを実行するためのウェブページのＵＲＬが示される。

クライアント端末１０は、ログインリクエスト（Ｓ１７０）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、Ｓ３７２において送信されたメールに示されたＵＲＬを指定すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、Ｓ３７２において特定されたリワードデータベースの「チケットオーナＩＤ」フィールドに格納された会員ＩＤを含む。

サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。

クライアント端末１０は、返金画面の表示（Ｓ１７１）を実行する。
具体的には、ＣＰＵ１２は、サーバ３０と通信を行うことによって、返金リクエストを実行するためのウェブページを表示部１４に表示する。

クライアント端末１０は、返金リクエスト（Ｓ１７２）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、返金画面において返金先の口座情報（例えば、銀行名、支店名、口座番号、及び、口座名義人を示す情報）を入力すると、ＣＰＵ１２は、返金リクエストをサーバ３０に送信する。返金リクエストは、返金口座情報と、ログインリクエストに含まれる会員ＩＤとを含む。

サーバ３０は、返金（Ｓ３７３）を実行する。
具体的には、ＣＰＵ３２は、返金リクエストに含まれる返金口座情報に対応する口座に支援金額を振り込む。

サーバ３０は、データベースの更新（Ｓ３７４）を実行する。
具体的には、ＣＰＵ３２は、図５のプロジェクトデータベースにおいて、返金条件が成立したプロジェクトを識別するプロジェクトＩＤに関連付けられた「タイプ」フィールドに、終了したプロジェクトであることを示すタイプコード「ＦＩＮ」を格納する。

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

（１−７）小括
第１実施形態について小括する。

ＣＰＵ３２（情報処理装置の一例）は、クラウドファンディングの会員を識別する会員ＩＤ（ユーザ識別情報の一例）と、クラウドファンディングのプロジェクトを識別するプロジェクトＩＤ（プロジェクト識別情報の一例）とを記憶する記憶装置３１にアクセス可能である。
ＣＰＵ３２は、チケットオーナ（第１ユーザの一例）の指示に応じて、チケットオーナを識別する会員ＩＤ（第１ユーザ識別情報の一例）と、プロジェクトＩＤとに、プロジェクトへの支援金額を示す情報を関連付けて記憶する（例えば、Ｓ３２２の処理）。
また、ＣＰＵ３２は、チケットオーナを識別する会員ＩＤに、プロジェクトへの支援に対するチケットＩＤ（チケット識別情報の一例）を関連付けて記憶する（例えば、Ｓ３２２の処理）。
チケットオーナからの指示に応じて、チケットオーナを識別する会員ＩＤとチケットＩＤとの関連付けを解除し、かつ、チケットオーナによって指定された会員ユーザを識別する会員ＩＤ（第２ユーザ識別情報の一例）にチケットＩＤを関連付けて記憶する（例えば、Ｓ１４１〜Ｓ３４１の処理）。

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

さらに、ＣＰＵ３２は、チケットを譲り受けた会員（第２ユーザの一例）の指示に応じて、チケットを譲り受けた会員を識別する会員ＩＤ（第２ユーザ識別情報の一例）とチケットＩＤとの関連付けを解除し、かつ、チケットを譲り受けた会員によって指定された譲受人（第３ユーザの一例）を識別する会員ＩＤ（第３ユーザ識別情報の一例）にチケットＩＤを関連付けて記憶する（例えば、Ｓ１４１〜Ｓ１４２の処理）。

さらに、ＣＰＵ３２は、チケット譲渡の処理を実行する度に、チケットＩＤに、譲渡人を識別する会員ＩＤ（指示を与えたユーザを識別するユーザ識別情報の一例）と、譲受人を識別する会員ＩＤ（指示を与えたユーザによって指定されたユーザを識別するユーザ識別情報の一例）との組合せを関連付けて記憶する（例えば、Ｓ３４１の処理）。

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

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

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

さらに、ＣＰＵ３２は、紙チケットを受け取ったユーザ（チケットオーナ以外のユーザの一例）によって、紙チケットに印刷された受取用トークンが入力された場合、チケットオーナを識別する会員ＩＤとチケットＩＤとの関連付けを解除し、かつ、受取用トークンを入力した会員を識別する会員識別情報にチケットＩＤを関連付けて記憶する（例えば、Ｓ１５２〜Ｓ３５２の処理）。

さらに、ＣＰＵ３２は、チケットオーナを識別する会員ＩＤとチケットＩＤとの対応付けを解除してから、受取用トークンを入力した会員を識別する会員ＩＤにチケットＩＤを関連付けて記憶するまでの間（例えば、Ｓ３５０〜Ｓ３５２の間）、チケットを利用できない状態にする（例えば、Ｓ３５１の処理）。

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

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

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

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

１ ：情報処理システム
１０ ：クライアント端末
１１ ：記憶装置
１２ ：ＣＰＵ
１３ ：入力部
１４ ：表示部
１５ ：通信インタフェース
３０ ：サーバ
３１ ：記憶装置
３２ ：ＣＰＵ
３３ ：入力部
３４ ：表示部
３５ ：通信インタフェース

Claims (6)

1. クラウドファンディング の会員であるユーザを識別するユーザ識別情報と、前記クラウドファンディングのプロジェクトを識別するプロジェクト識別情報とを記憶する記憶装置にアクセス可能な情報処理装置であって、
   第１ユーザの指示に応じて、前記第１ユーザを識別する第１ユーザ識別情報と、前記プロジェクト識別情報とに、前記プロジェクトへの支援の金額を示す情報を関連付けて記憶する第１関連付け手段と、
   前記第１ユーザ識別情報に、前記プロジェクトへの支援に対する報酬を受け取る権利を識別するチケット識別情報を関連付けて記憶する第２関連付け手段と、
   前記第１ユーザからの指示に応じて、前記第１ユーザ識別情報と前記チケット識別情報との関連付けを解除し、かつ、前記第１ユーザによって指定された第２ユーザを識別する第２ユーザ識別情報に前記チケット識別情報を関連付ける第３関連付け手段と、
   を備える、情報処理装置。
2. 前記第３関連付け手段は、前記第２ユーザの指示に応じて、前記第２ユーザ識別情報と前記チケット識別情報との関連付けを解除し、かつ、前記第２ユーザによって指定された第３ユーザを識別する第３ユーザ識別情報に前記チケット識別情報を関連付けて記憶する、
   請求項１に記載の情報処理装置。
3. 前記第３関連付け手段による処理が実行される度に、前記チケット識別情報に、前記指示を与えたユーザを識別するユーザ識別情報と、前記指示を与えたユーザによって指定されたユーザを識別するユーザ識別情報との組合せを関連付けて記憶する第４関連付け手段をさらに備える、
   請求項１又は２に記載の情報処理装置。
4. 前記チケット識別情報に関連付けられたユーザ識別情報によって識別されるユーザであるチケットオーナの指示に応じて、前記チケットオーナ以外のユーザが前記報酬を受け取る権利を譲り受けるために必要な譲渡情報が印刷された紙チケットを発行する発行手段をさらに備える、
   請求項１〜３の何れかに記載の情報処理装置。
5. 前記チケットオーナ以外のユーザによって、前記発行手段によって発行された紙チケットに印刷された譲渡情報が入力された場合、前記チケットオーナを識別するユーザ識別情報と前記チケット識別情報との関連付けを解除し、かつ、前記譲渡情報を入力したユーザを識別するユーザ識別情報に前記チケット識別情報を関連付けて記憶する第５関連付け手段をさらに備える、
   請求項４に記載の情報処理装置。
6. 前記第５関連付け手段が前記チケットオーナを識別するユーザ識別情報と前記チケット識別情報との対応付けを解除してから、前記第５関連付け手段が前記譲渡情報を入力したユーザを識別するユーザ識別情報に前記チケット識別情報を関連付けて記憶するまでの間、前記報酬を受け取る権利を利用できない状態にする手段をさらに備える、
   請求項５に記載の情報処理装置。

Images