JP6539847B2 - 情報処理装置 - Google Patents
情報処理装置 Download PDFInfo
- Publication number
- JP6539847B2 JP6539847B2 JP2016038766A JP2016038766A JP6539847B2 JP 6539847 B2 JP6539847 B2 JP 6539847B2 JP 2016038766 A JP2016038766 A JP 2016038766A JP 2016038766 A JP2016038766 A JP 2016038766A JP 6539847 B2 JP6539847 B2 JP 6539847B2
- Authority
- JP
- Japan
- Prior art keywords
- project
- ticket
- information
- field
- screen
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
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）のプログラム、情報処理を実行するアプリケーション（例えば、ブラウザ）のプログラム等である。
情報処理に必要なデータは、例えば、情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）である。
ＣＰＵ１２は、記憶装置１１に記憶されたプログラムを起動することによって、アプリケーションの機能を実現するように構成される。
入力部１３は、ユーザの指示を受け付けるように構成される。入力部１３は、例えば、キーボード、ポインティングデバイス、タッチパネル等である。
表示部１４は、ユーザに情報を提示するように構成される。表示部１４は、例えば、液晶ディスプレイである。
通信インタフェース１５は、クライアント端末１０と通信網ＮＷとの間の通信を制御するように構成される。
（１−３）サーバの構成（図３）
第１実施形態のサーバの構成について説明する。図３は、第１実施形態のサーバの構成を示す図である。
第１実施形態のサーバの構成について説明する。図３は、第１実施形態のサーバの構成を示す図である。
図３に示すように、サーバ３０は、記憶装置３１と、ＣＰＵ３２と、入力部３３と、表示部３４と、通信インタフェース３５とを備える。
記憶装置３１は、情報処理に必要なプログラム、データ、及び、データベースを記憶する記憶装置である。記憶装置３１は、例えば、ＲＯＭ、ＲＡＭ、及び、ストレージ（例えば、フラッシュメモリ又はハードディスク）の組合せである。
情報処理に必要なプログラムは、例えば、ＯＳ（Operating System）のプログラム、サーバ３０の機能を実現するアプリケーションのプログラム等である。
情報処理に必要なデータは、例えば、要件情報（後述する）である。
情報処理に必要なプログラムは、例えば、ＯＳ（Operating System）のプログラム、サーバ３０の機能を実現するアプリケーションのプログラム等である。
情報処理に必要なデータは、例えば、要件情報（後述する）である。
ＣＰＵ３２は、記憶装置３１に記憶されたプログラムを起動することによって、サーバ３０の機能を実現するように構成される。
入力部３３及び表示部３４は、それぞれ、図２の入力部１３及び表示部１４と同様である。
通信インタフェース３５は、サーバ３０と通信網ＮＷとの間の通信を制御するように構成される。
（１−４）データベースのデータ構造（図４〜図７）
第１実施形態のデータベースのデータ構造について説明する。
第１実施形態のデータベースのデータ構造について説明する。
（１−４−１）会員データベース（図４）
第１実施形態の会員データベースのデータ構造について説明する。図４は、第１実施形態の会員データベースのデータ構造を示す図である。
第１実施形態の会員データベースのデータ構造について説明する。図４は、第１実施形態の会員データベースのデータ構造を示す図である。
会員データベースの各レコードには、会員に関する情報（以下「会員情報」という）が格納される。
図４に示すように、会員データベースは、「会員ＩＤ」フィールドと、「メールアドレス」フィールドと、「パスワード」フィールドと、「氏名」フィールドと、「画像」フィールドと、「住所」フィールドと、「支払情報」フィールドとを含む。
「会員ＩＤ」フィールドには、会員ＩＤが格納される。会員ＩＤは、会員として登録されたユーザ毎に固有の情報である。つまり、会員ＩＤは、会員を識別する情報である。会員ＩＤは、会員データベースの各レコードの主キーである。会員ＩＤは、サーバ３０が決定する情報である。
「メールアドレス」フィールドには、会員のメールアドレスを示すテキストデータが格納される。
「パスワード」フィールドには、会員のパスワードを示すテキストデータが格納される。
「メールアドレス」フィールド及び「パスワード」フィールドの情報は、会員のログイン認証のために参照される。「メールアドレス」フィールド及び「パスワード」フィールドの情報は、会員が任意に決定する情報である。
「パスワード」フィールドには、会員のパスワードを示すテキストデータが格納される。
「メールアドレス」フィールド及び「パスワード」フィールドの情報は、会員のログイン認証のために参照される。「メールアドレス」フィールド及び「パスワード」フィールドの情報は、会員が任意に決定する情報である。
「氏名」フィールドには、会員の氏名を示すテキストデータが格納される。
「画像」フィールドには、会員の画像を示す画像データが格納される。
「住所」フィールドには、会員の住所を示すテキストデータが格納される。
「支払情報」フィールドには、会員の支払に関する情報（例えば、クレジットカード番号）を示す値が格納される。
「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドの情報は、会員が任意に決定する情報である。
「画像」フィールドには、会員の画像を示す画像データが格納される。
「住所」フィールドには、会員の住所を示すテキストデータが格納される。
「支払情報」フィールドには、会員の支払に関する情報（例えば、クレジットカード番号）を示す値が格納される。
「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドの情報は、会員が任意に決定する情報である。
（１−４−２）プロジェクトデータベース（図５）
第１実施形態のプロジェクトデータベースのデータ構造について説明する。図５は、第１実施形態のプロジェクトデータベースのデータ構造の一例を示す図である。
第１実施形態のプロジェクトデータベースのデータ構造について説明する。図５は、第１実施形態のプロジェクトデータベースのデータ構造の一例を示す図である。
プロジェクトデータベースの各レコードには、プロジェクトに関する情報（以下「プロジェクト情報」という）が格納される。
「プロジェクト」とは、クラウドファンディングにおいて、会員からの支援の対象を意味する。
「プロジェクト」とは、クラウドファンディングにおいて、会員からの支援の対象を意味する。
図５に示すように、プロジェクトデータベースは、「プロジェクトＩＤ」フィールドと、「プロジェクトオーナＩＤ」フィールドと、「パスワード」フィールドと、「メールアドレス」フィールドと、「氏名」フィールドと、「プロフィール」フィールドと、「プロジェクト名」フィールドと、「目標金額」フィールドと、「概要」フィールドと、「画像」フィールドと、「開始日」フィールドと、「終了日」フィールドと、「タイプ」フィールドとを含む。
「プロジェクトＩＤ」フィールドには、プロジェクトＩＤが格納される。プロジェクトＩＤは、プロジェクト毎に固有の情報である。つまり、プロジェクトＩＤは、プロジェクトを識別する情報である。プロジェクトＩＤは、プロジェクトデータベースの各レコードの主キーである。プロジェクトＩＤは、サーバ３０が決定する情報である。
「プロジェクトオーナＩＤ」フィールドには、プロジェクトオーナＩＤが格納される。プロジェクトオーナＩＤは、プロジェクトオーナＩＤは、プロジェクトオーナを識別する情報である。
「パスワード」フィールドには、プロジェクトオーナとしてログインするためのパスワードが格納される。
「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドは、サーバ３０が決定する情報である。
「プロジェクトオーナ」とは、プロジェクトの作成者として登録されたユーザを意味する。プロジェクトオーナは、プロジェクトを管理する権限を有する。
「パスワード」フィールドには、プロジェクトオーナとしてログインするためのパスワードが格納される。
「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドは、サーバ３０が決定する情報である。
「プロジェクトオーナ」とは、プロジェクトの作成者として登録されたユーザを意味する。プロジェクトオーナは、プロジェクトを管理する権限を有する。
「メールアドレス」フィールドには、プロジェクトオーナのメールアドレスを示すテキストデータが格納される。「メールアドレス」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
「氏名」フィールドには、プロジェクトオーナの氏名を示すテキストデータが格納される。
「プロフィール」フィールドには、プロジェクトオーナのプロフィールを示すテキストデータが格納される。
「プロジェクト名」フィールドには、プロジェクトの名称を示すテキストデータが格納される。
「目標金額」フィールドには、プロジェクトの目標金額を示す値が格納される。
「概要」フィールドには、プロジェクトの概要を示すテキストデータが格納される。
「画像」フィールドには、プロジェクトの画像を示す画像データが格納される。
「開始日」フィールド及び「終了日」フィールドには、それぞれ、プロジェクトの開始日及び終了日を示す値が格納される。「開始日」フィールド及び「終了日」フィールドの情報は、プロジェクトの期間を示す。
「氏名」フィールド、「プロフィール」フィールド、「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、「画像」フィールド、「開始日」フィールド、及び、「終了日」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
「プロフィール」フィールドには、プロジェクトオーナのプロフィールを示すテキストデータが格納される。
「プロジェクト名」フィールドには、プロジェクトの名称を示すテキストデータが格納される。
「目標金額」フィールドには、プロジェクトの目標金額を示す値が格納される。
「概要」フィールドには、プロジェクトの概要を示すテキストデータが格納される。
「画像」フィールドには、プロジェクトの画像を示す画像データが格納される。
「開始日」フィールド及び「終了日」フィールドには、それぞれ、プロジェクトの開始日及び終了日を示す値が格納される。「開始日」フィールド及び「終了日」フィールドの情報は、プロジェクトの期間を示す。
「氏名」フィールド、「プロフィール」フィールド、「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、「画像」フィールド、「開始日」フィールド、及び、「終了日」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
「タイプ」フィールドには、プロジェクトのタイプを示すコードが格納される。タイプコード「ＡＮ」は、プロジェクトのタイプが「オールオアナッシング方式」であることを示す。タイプ「コード「ＤＣ」は、プロジェクトのタイプが「ダイレクトチャレンジ方式」であることを示す。
「タイプ」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
オールオアナッシング方式では、「終了日」フィールドに格納された値が示す日までに、支援金額の総額が「目標金額」フィールドの値に到達した場合にのみ、プロジェクト作成者に支援金額が渡され、かつ、支援者に報酬が送られる。
ダイレクトチャレンジ方式では、「終了日」フィールドに格納された値が示す日の支援金額の総額がプロジェクト作成者に渡される。
「タイプ」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
オールオアナッシング方式では、「終了日」フィールドに格納された値が示す日までに、支援金額の総額が「目標金額」フィールドの値に到達した場合にのみ、プロジェクト作成者に支援金額が渡され、かつ、支援者に報酬が送られる。
ダイレクトチャレンジ方式では、「終了日」フィールドに格納された値が示す日の支援金額の総額がプロジェクト作成者に渡される。
（１−４−３）リワードデータベース（図６）
第１実施形態のリワードデータベースのデータ構造について説明する。図６は、第１実施形態のリワードデータベースのデータ構造の一例を示す図である。
第１実施形態のリワードデータベースのデータ構造について説明する。図６は、第１実施形態のリワードデータベースのデータ構造の一例を示す図である。
リワードデータベースの各レコードには、リワードに関する情報（以下「リワード情報」という）が格納される。
１つのプロジェクトＩＤには、リワードデータベースの複数のレコードを関連付けることができる。
「リワード」とは、プロジェクトへの支援に対する報酬を意味する。
１つのプロジェクトＩＤには、リワードデータベースの複数のレコードを関連付けることができる。
「リワード」とは、プロジェクトへの支援に対する報酬を意味する。
図６に示すように、リワードデータベースは、「リワードＩＤ」フィールドと、「チケット上限数」フィールドと、「チケット配布数」フィールドと、「リワード名」フィールドと、「画像」フィールドと、「チケット金額」フィールドと、「説明」フィールドと、「予定日」フィールドとを含む。
「リワードＩＤ」フィールドには、リワードＩＤが格納される。リワードＩＤは、リワード毎に固有の情報である。つまり、リワードＩＤは、リワードを識別する情報である。リワードＩＤは、リワードデータベースの各レコードの主キーである。リワードＩＤは、サーバ３０が決定する情報である。
「チケット上限数」フィールドには、１つのリワードにおいて提供されるチケットの上限数を示す値が格納される。
「チケット」とは、プロジェクトに対する支援への報酬を受け取る権利を意味する。
「チケット上限数」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
「チケット」とは、プロジェクトに対する支援への報酬を受け取る権利を意味する。
「チケット上限数」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
「チケット配布数」フィールドには、プロジェクトを支援した会員に配布したチケットの数を示す値が格納される。「チケット配布数」フィールドの値は、プロジェクトの支援者の数を示す。
「チケット配布数」フィールドの情報は、サーバ３０が決定する情報である。
「チケット配布数」フィールドの情報は、サーバ３０が決定する情報である。
「リワード名」フィールドには、リワードの名称を示すテキストデータが格納される。
「画像」フィールドには、リワードの画像を示す画像データが格納される。
「チケット金額」フィールドには、１つのチケットを取得するために必要な支援金額を示す値が格納される。
「説明」フィールドには、リワードの説明を示すテキストデータが格納される。
「予定日」フィールドには、チケットが利用可能になる日を示す値が格納される。
「リワード名」フィールド、「画像」フィールド、「チケット金額」フィールド、「説明」フィールド、及び、「予定日」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
「画像」フィールドには、リワードの画像を示す画像データが格納される。
「チケット金額」フィールドには、１つのチケットを取得するために必要な支援金額を示す値が格納される。
「説明」フィールドには、リワードの説明を示すテキストデータが格納される。
「予定日」フィールドには、チケットが利用可能になる日を示す値が格納される。
「リワード名」フィールド、「画像」フィールド、「チケット金額」フィールド、「説明」フィールド、及び、「予定日」フィールドの情報は、プロジェクトオーナが任意に決定する情報である。
（１−４−４）支援履歴データベース（図７）
第１実施形態の支援履歴データベースのデータ構造について説明する。図７は、第１実施形態の支援履歴データベースのデータ構造の一例を示す図である。
第１実施形態の支援履歴データベースのデータ構造について説明する。図７は、第１実施形態の支援履歴データベースのデータ構造の一例を示す図である。
支援履歴データベースの各レコードには、プロジェクトへの支援の履歴に関する情報（以下「支援履歴情報」という）が格納される。
１つの会員ＩＤには、支援履歴データベースの複数のレコードを関連付けることができる。
「支援」とは、プロジェクトに対する資金の提供を意味する。
１つの会員ＩＤには、支援履歴データベースの複数のレコードを関連付けることができる。
「支援」とは、プロジェクトに対する資金の提供を意味する。
図７に示すように、支援履歴データベースは、「支援ＩＤ」フィールドと、「支援金額」フィールドと、「支援日」フィールドとを含む。
「支援ＩＤ」フィールドには、支援ＩＤが格納される。支援ＩＤは、支援毎に固有の情報である。つまり、支援ＩＤは、支援を識別する情報である。支援ＩＤは、支援履歴データベースの各レコードの主キーである。支援ＩＤは、サーバ３０が決定する情報である。
「支援金額」フィールドには、支援金額を示す値が格納される。
「支援日」フィールドには、支援日を示す値が格納される。
「支援金額」フィールド及び「支援日」フィールドの情報は、サーバ３０が決定する情報である。
「支援日」フィールドには、支援日を示す値が格納される。
「支援金額」フィールド及び「支援日」フィールドの情報は、サーバ３０が決定する情報である。
（１−４−５）チケットデータベース（図８〜図９）
第１実施形態のチケットデータベースのデータ構造について説明する。図８は、第１実施形態のチケットデータベースのデータ構造の一例を示す図である。
第１実施形態のチケットデータベースのデータ構造について説明する。図８は、第１実施形態のチケットデータベースのデータ構造の一例を示す図である。
チケットデータベースの各レコードには、チケットに関する情報（以下「チケット情報」という）が格納される。
１つのリワードＩＤには、チケットデータベースの複数のレコードを関連付けることができる。
１つのリワードＩＤには、チケットデータベースの複数のレコードを関連付けることができる。
図８に示すように、チケットデータベースは、「チケットＩＤ」フィールドと、「チケットオーナＩＤ」フィールドと、「支援ＩＤ」フィールドと、「受取用トークン」フィールドと、「トークン期限」フィールドと、「ステータス」フィールドとを含む。
「チケットＩＤ」フィールドには、チケットＩＤが格納される。チケットＩＤは、チケット毎に固有の情報である。つまり、チケットＩＤは、チケットを識別する情報である。チケットＩＤは、チケットデータベースの各レコードの主キーである。チケットＩＤは、サーバ３０が決定する情報である。
「チケットオーナＩＤ」フィールドには、チケットオーナＩＤが格納される。チケットオーナＩＤとは、チケットを所有する会員の会員ＩＤである。
「支援ＩＤ」フィールドには、チケットＩＤと所有者ＩＤとを関連付けるトリガとなった支援の支援ＩＤが格納される。
「受取用トークン」フィールドには、紙チケットを介してチケット譲り受けるときに使用する受取用トークンを示す文字列が格納される。
「トークン期限」フィールドには、「受取用トークン」フィールドに格納された情報の利用期限を示す値である。
「受取用トークン」フィールド、及び、「トークン期限」フィールドの情報は、サーバ３０が決定する情報である。
「トークン期限」フィールドには、「受取用トークン」フィールドに格納された情報の利用期限を示す値である。
「受取用トークン」フィールド、及び、「トークン期限」フィールドの情報は、サーバ３０が決定する情報である。
「ステータス」フィールドには、チケットのステータスを示すコード（以下「ステータスコード」という）が格納される。
第１実施形態のチケットのステータスについて説明する。図９は、第１実施形態のチケットのステータスの遷移を示す概略図である。
図９に示すように、ステータスコードは、第１ステータスを示すコード「ＳＴＡ１」、第２ステータスを示すコード「ＳＴＡ２」、第３ステータスを示すコード「ＳＴＡ３」、及び、第４ステータスを示すコード「ＳＴＡ４」の何れかである。
支援リクエスト（後述する）が行われた後、プロジェクトへの支援金の入金の確認に成功すると、チケットのステータスは第１ステータスになる。
「第１ステータス」とは、チケットが利用可能である状態（以下「利用可能状態」という）を示す。ステータスコード「ＳＴＡ１」に関連付けられたチケットＩＤによって識別されるチケットは、利用可能であり、かつ、譲渡可能である。
「第１ステータス」とは、チケットが利用可能である状態（以下「利用可能状態」という）を示す。ステータスコード「ＳＴＡ１」に関連付けられたチケットＩＤによって識別されるチケットは、利用可能であり、かつ、譲渡可能である。
第１ステータスにおいてチケット譲渡リクエスト（後述する）が行われると、チケットのステータスは第２ステータスに遷移する。
「第２ステータス」とは、チケットの譲渡の処理が完了していない状態（以下「譲渡中状態」という）を示す。ステータスコード「ＳＴＡ２」に関連付けられたチケットＩＤによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。
第２ステータスにおいて譲渡が完了すると、チケットのステータスは第１ステータスに遷移する。
「第２ステータス」とは、チケットの譲渡の処理が完了していない状態（以下「譲渡中状態」という）を示す。ステータスコード「ＳＴＡ２」に関連付けられたチケットＩＤによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。
第２ステータスにおいて譲渡が完了すると、チケットのステータスは第１ステータスに遷移する。
第１ステータスにおいてチケット利用リクエスト（後述する）が行われると、チケットのステータスは第３ステータスに遷移する。
「第３ステータス」とは、チケット利用リクエストが行われた状態（以下「利用中状態」という）を示す。ステータスコード「ＳＴＡ３」に関連付けられたチケットＩＤによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。
「第３ステータス」とは、チケット利用リクエストが行われた状態（以下「利用中状態」という）を示す。ステータスコード「ＳＴＡ３」に関連付けられたチケットＩＤによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。
第４ステータスにおいてリワード完了リクエスト（後述する）が行わると、チケットのステータスは第４ステータスに遷移する。
「第４ステータス」とは、チケットが利用済である状態（以下「利用済状態」という）を示す。ステータスコード「ＳＴＡ４」に関連付けられたチケットＩＤによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。
「第４ステータス」とは、チケットが利用済である状態（以下「利用済状態」という）を示す。ステータスコード「ＳＴＡ４」に関連付けられたチケットＩＤによって識別されるチケットは、利用不可能であり、かつ、譲渡不可能である。
（１−４−６）譲渡履歴データベース（図１０）
第１実施形態の譲渡履歴データベースのデータ構造について説明する。図１０は、第１実施形態の譲渡履歴データベースのデータ構造の一例を示す図である。
第１実施形態の譲渡履歴データベースのデータ構造について説明する。図１０は、第１実施形態の譲渡履歴データベースのデータ構造の一例を示す図である。
譲渡履歴データベースの各レコードには、チケットの譲渡履歴に関する情報（以下「譲渡履歴情報」という）が格納される。
１つのチケットＩＤには、譲渡履歴データベースの複数のレコードを関連付けることができる。
１つのチケットＩＤには、譲渡履歴データベースの複数のレコードを関連付けることができる。
図１０に示すように、譲渡履歴データベースは、「登録日」フィールドと、「譲渡人ＩＤ」フィールドと、「譲受人ＩＤ」フィールドとを含む。
「登録日」フィールドには、各レコードの登録日を示す値が格納される。登録日は、譲渡履歴データベースの各レコードの主キーである。登録日は、サーバ３０が決定する情報である。
「譲渡人ＩＤ」フィールドには、譲渡人（つまり、譲渡が行われる前）のチケットオーナＩＤが格納される。
「譲受人ＩＤ」フィールドには、譲受人（つまり、譲渡が行われた後）のチケットオーナＩＤが格納される。
（１−５）情報処理において表示される画面（図１１〜図２２）
第１実施形態の情報処理において表示される画面について説明する。図１１〜図２２は、第１実施形態の情報処理において表示される画面の例を示す図である。
図１１〜図２２の画面は、クライアント端末１０の表示部１４に表示される。各画面では、ユーザは、入力部１３を用いて指示（入力フィールドへの入力、及び、ボタンの指定）を与えることができる。与えられた指示は、クライアント端末１０からサーバ３０に送信される。
第１実施形態の情報処理において表示される画面について説明する。図１１〜図２２は、第１実施形態の情報処理において表示される画面の例を示す図である。
図１１〜図２２の画面は、クライアント端末１０の表示部１４に表示される。各画面では、ユーザは、入力部１３を用いて指示（入力フィールドへの入力、及び、ボタンの指定）を与えることができる。与えられた指示は、クライアント端末１０からサーバ３０に送信される。
図１１の画面Ｐ１００は、トップ画面用のＵＲＬ（Uniform Resource Locator）にアクセスされたときに表示される画面である。
画面Ｐ１００は、「会員登録」ボタンＢ１００ａと、「プロジェクト作成」ボタンＢ１００ｂと、「ログイン」ボタンＢ１００ｃとを含む。
画面Ｐ１００は、「会員登録」ボタンＢ１００ａと、「プロジェクト作成」ボタンＢ１００ｂと、「ログイン」ボタンＢ１００ｃとを含む。
画面Ｐ１００において「会員登録」ボタンＢ１００ａが指定されると、画面Ｐ１１０が表示される。
画面Ｐ１１０は、入力フィールドＦ１１０と、「完了」ボタンＢ１１０とを含む。
入力フィールドＦ１１０は、会員登録に必要な情報を入力するための入力フィールドである。会員登録に必要な情報とは、例えば、氏名、メールアドレス、パスワード、画像、住所、及び、支払情報である。
画面Ｐ１１０は、入力フィールドＦ１１０と、「完了」ボタンＢ１１０とを含む。
入力フィールドＦ１１０は、会員登録に必要な情報を入力するための入力フィールドである。会員登録に必要な情報とは、例えば、氏名、メールアドレス、パスワード、画像、住所、及び、支払情報である。
画面Ｐ１１０において入力フィールドＦ１１０に情報が入力され、かつ、「完了」ボタンＢ１１０が指定されると、クライアント端末１０は、サーバ３０に、会員登録の処理のリクエスト（以下「会員登録リクエスト」という）を送信する。
図１１の画面Ｐ１００において「プロジェクト作成」ボタンＢ１００ｂが指定されると、図１２の画面Ｐ２１０が表示される。
画面Ｐ２１０は、入力フィールドＦ２１０ａ〜Ｆ２１０ｂと、「完了」ボタンＢ２１０とを含む。
入力フィールドＦ２１０ａ〜Ｆ２１０ｂは、プロジェクト情報を入力するための入力フィールドである。具体的には、入力フィールドＦ２１０ａは、プロジェクトオーナの氏名、メールアドレス、及び、プロフィールを入力するための入力フィールドである。入力フィールドＦ２１０ｂは、プロジェクト名、目標金額、開始日、終了日、画像、及び、タイプを入力するための入力フィールドである。タイプを入力するための入力フィールドは、プルダウン形式で入力可能である。
画面Ｐ２１０は、入力フィールドＦ２１０ａ〜Ｆ２１０ｂと、「完了」ボタンＢ２１０とを含む。
入力フィールドＦ２１０ａ〜Ｆ２１０ｂは、プロジェクト情報を入力するための入力フィールドである。具体的には、入力フィールドＦ２１０ａは、プロジェクトオーナの氏名、メールアドレス、及び、プロフィールを入力するための入力フィールドである。入力フィールドＦ２１０ｂは、プロジェクト名、目標金額、開始日、終了日、画像、及び、タイプを入力するための入力フィールドである。タイプを入力するための入力フィールドは、プルダウン形式で入力可能である。
画面Ｐ２１０において入力フィールドＦ２１０ａ〜Ｆ２１０ｂに情報が入力され、かつ、「完了」ボタンＢ２１０が指定されると、クライアント端末１０は、サーバ３０に、プロジェクト作成の処理のリクエスト（以下「プロジェクト作成リクエスト」という）を送信する。
図１１の画面Ｐ１００において「ログイン」ボタンＢ１００ｃが指定され、かつ、会員ＩＤ（例えば、会員ＩＤ「ＣＵ００１」）及びパスワードが入力されると、図１３の画面Ｐ３１０が表示される。
画面Ｐ３１０は、「支援」ボタンＢ３１０ａと、「所有チケット一覧」ボタンＢ３１０ｂと、「チケット受取」ボタンＢ３１０ｃとを含む。
画面Ｐ３１０は、「支援」ボタンＢ３１０ａと、「所有チケット一覧」ボタンＢ３１０ｂと、「チケット受取」ボタンＢ３１０ｃとを含む。
画面Ｐ３１０において「支援」ボタンＢ３１０ａが指定されると、画面Ｐ３１１が表示される。
画面Ｐ３１１は、画像ＩＭＧ３１１ａ〜ＩＭＧ３１１ｂと、領域Ａ３１１ａ〜Ａ３１１ｂと、「選択」ボタンＢ３１１ａ〜Ｂ３１１ｂとを含む。
画像ＩＭＧ３１１ａ〜ＩＭＧ３１１ｂは、支援の対象となるプロジェクトの画像（例えば、図５の「画像」フィールドに格納された画像データに対応する画像）である。
領域Ａ３１１ａ〜Ａ３１１ｂには、プロジェクト情報（例えば、プロジェクト名、参加者数、残り日数、及び、達成金額）が表示される。「プロジェクト名」は、例えば、図５の「プロジェクト名」フィールドの情報である。「参加者数」は、プロジェクトを支援している会員の数（例えば、図６の「チケット配布数」フィールドの値）である。「残り日数」は、プロジェクトの終了日迄の残り日数（例えば、図５の「終了日」フィールドと画面Ｐ３１０が表示された日との差）である。「達成金額」は、支援金額の総額（例えば、図６の「チケット配布数」フィールドの値と、「チケット金額」フィールドの値との積）である。
「選択」ボタンＢ３１１ａ〜Ｂ３１１ｂは、それぞれ、領域Ａ３１１ａ〜Ａ３１１ｂに表示されたプロジェクト情報に関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」〜「ＰＲ００２」）に関連付けられている。
画面Ｐ３１１は、画像ＩＭＧ３１１ａ〜ＩＭＧ３１１ｂと、領域Ａ３１１ａ〜Ａ３１１ｂと、「選択」ボタンＢ３１１ａ〜Ｂ３１１ｂとを含む。
画像ＩＭＧ３１１ａ〜ＩＭＧ３１１ｂは、支援の対象となるプロジェクトの画像（例えば、図５の「画像」フィールドに格納された画像データに対応する画像）である。
領域Ａ３１１ａ〜Ａ３１１ｂには、プロジェクト情報（例えば、プロジェクト名、参加者数、残り日数、及び、達成金額）が表示される。「プロジェクト名」は、例えば、図５の「プロジェクト名」フィールドの情報である。「参加者数」は、プロジェクトを支援している会員の数（例えば、図６の「チケット配布数」フィールドの値）である。「残り日数」は、プロジェクトの終了日迄の残り日数（例えば、図５の「終了日」フィールドと画面Ｐ３１０が表示された日との差）である。「達成金額」は、支援金額の総額（例えば、図６の「チケット配布数」フィールドの値と、「チケット金額」フィールドの値との積）である。
「選択」ボタンＢ３１１ａ〜Ｂ３１１ｂは、それぞれ、領域Ａ３１１ａ〜Ａ３１１ｂに表示されたプロジェクト情報に関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」〜「ＰＲ００２」）に関連付けられている。
画面Ｐ３１１において「選択」ボタンＢ３１１ａが指定されると、画面Ｐ３１２が表示される。
画面Ｐ３１２は、領域Ａ３１２と、入力フィールドＦ３１２と、「完了」ボタンＢ３１２とを含む。
領域Ａ３１２には、「選択」ボタンＢ３１１ａに関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」）に関連付けられたリワード情報が表示される。「リワード名」は、例えば、図６の「リワード名」フィールドの情報である。「チケット金額」は、例えば、図６の「チケット金額」フィールドの値である。
入力フィールドＦ３１２は、取得を希望するチケットの数量を入力するための入力フィールドである。
画面Ｐ３１２は、領域Ａ３１２と、入力フィールドＦ３１２と、「完了」ボタンＢ３１２とを含む。
領域Ａ３１２には、「選択」ボタンＢ３１１ａに関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」）に関連付けられたリワード情報が表示される。「リワード名」は、例えば、図６の「リワード名」フィールドの情報である。「チケット金額」は、例えば、図６の「チケット金額」フィールドの値である。
入力フィールドＦ３１２は、取得を希望するチケットの数量を入力するための入力フィールドである。
画面Ｐ３１２において入力フィールドＦ３１２に情報が入力され、かつ、「完了」ボタンＢ３１２が指定されると、クライアント端末１０は、サーバ３０に、支援の処理のリクエスト（以下「支援リクエスト」という）を送信する。
画面Ｐ３１０において「所有チケット一覧」ボタンＢ３１０ｂが指定されると、図１４の画面Ｐ３２０が表示される。
画面Ｐ３２０は、領域Ａ３２０ａ〜Ａ３２０ｂと、「利用」ボタンＢ３２０ａ〜Ｂ３２０ｂと、「譲渡」ボタンＢ３２０ｃ〜Ｂ３２０ｄと、「発行」ボタンＢ３２０ｅ〜Ｂ３２０ｆとを含む。
領域Ａ３２０ａ〜Ａ３２０ｂには、会員が所有しているチケットに関するチケット情報が表示される。「プロジェクト名」は、例えば、図５の「プロジェクト名」フィールドの情報である。「リワード名」は、例えば、図６の「リワード名」フィールドの情報である。「チケット金額」は、例えば、図６の「チケット金額」フィールドの値である。
「利用」ボタンＢ３２０ａ〜Ｂ３２０ｂは、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたチケット情報に対応するチケットＩＤ（例えば、チケットＩＤ「ＴＩ００１」〜「ＴＩ００２」）に関連付けられている。
「譲渡」ボタンＢ３２０ｃ〜Ｂ３２０ｄは、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたリワード情報に対応するリワードＩＤに関連付けられている。
「発行」ボタンＢ３２０ｅ〜Ｂ３２０ｆは、それぞれ、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたリワード情報に対応するリワードＩＤに関連付けられている。
画面Ｐ３２０は、領域Ａ３２０ａ〜Ａ３２０ｂと、「利用」ボタンＢ３２０ａ〜Ｂ３２０ｂと、「譲渡」ボタンＢ３２０ｃ〜Ｂ３２０ｄと、「発行」ボタンＢ３２０ｅ〜Ｂ３２０ｆとを含む。
領域Ａ３２０ａ〜Ａ３２０ｂには、会員が所有しているチケットに関するチケット情報が表示される。「プロジェクト名」は、例えば、図５の「プロジェクト名」フィールドの情報である。「リワード名」は、例えば、図６の「リワード名」フィールドの情報である。「チケット金額」は、例えば、図６の「チケット金額」フィールドの値である。
「利用」ボタンＢ３２０ａ〜Ｂ３２０ｂは、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたチケット情報に対応するチケットＩＤ（例えば、チケットＩＤ「ＴＩ００１」〜「ＴＩ００２」）に関連付けられている。
「譲渡」ボタンＢ３２０ｃ〜Ｂ３２０ｄは、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたリワード情報に対応するリワードＩＤに関連付けられている。
「発行」ボタンＢ３２０ｅ〜Ｂ３２０ｆは、それぞれ、それぞれ、領域Ａ３２０ａ〜Ａ３２０ｂに表示されたリワード情報に対応するリワードＩＤに関連付けられている。
画面Ｐ３２０において「利用」ボタンＢ３２０ａが指定されると、画面Ｐ３２１が表示される。
画面Ｐ３２１は、領域Ａ３２０ａに表示された情報と、「ＹＥＳ」ボタンＢ３２１ａと、「ＮＯ」ボタンＢ３２１ｂとを含む。
「ＹＥＳ」ボタンＢ３２１ａが指定されると、クライアント端末１０は、サーバ３０に、「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤ（例えば、チケットＩＤ「ＴＩ００１」）によって識別されるチケットを利用するためのチケット利用リクエストを送信する。
「ＮＯ」ボタンＢ３２１ｂが指定されると、画面Ｐ３２０に戻る。
画面Ｐ３２１は、領域Ａ３２０ａに表示された情報と、「ＹＥＳ」ボタンＢ３２１ａと、「ＮＯ」ボタンＢ３２１ｂとを含む。
「ＹＥＳ」ボタンＢ３２１ａが指定されると、クライアント端末１０は、サーバ３０に、「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤ（例えば、チケットＩＤ「ＴＩ００１」）によって識別されるチケットを利用するためのチケット利用リクエストを送信する。
「ＮＯ」ボタンＢ３２１ｂが指定されると、画面Ｐ３２０に戻る。
画面Ｐ３２０において「譲渡」ボタンＢ３２０ｃが指定されると、図１５の画面Ｐ３２２が表示される。
画面Ｐ３２２は、領域Ａ３２２ａ〜Ａ３２２ｂと、入力フィールドＦ３２２ａ〜Ｆ３２２ｂと、「完了」ボタンＢ３２２とを含む。
領域Ａ３２２ａには、図１４の領域Ａ３２０ａと同様の情報が表示される。
領域Ａ３２２ｂには、チケットを受け取るために必要なＵＲＬ（以下「受取用ＵＲＬ」という）が表示される。受取用ＵＲＬ「https://example.com/receive?token=ABCDEFG012345」は、チケットを受け取るための受取用トークン「ABCDEFG012345」を含む。
入力フィールドＦ３２２ａは、領域Ａ３２２ｂに表示されたＵＲＬの送信先となる会員（つまり、チケットの譲受人）の会員ＩＤを入力するための入力フィールドである。
入力フィールドＦ３２２ｂは、領域Ａ３２２ｂに表示されたＵＲＬの宛先となるメールアドレスを入力するための入力フィールドである。このメールアドレスは、図４の会員データベースにおいて会員ＩＤに関連付けられたメールアドレスであってもよいし、会員ＩＤに関連付けられていないメールアドレス（例えば、非会員ユーザのメールアドレス）であってもよい。
画面Ｐ３２２は、領域Ａ３２２ａ〜Ａ３２２ｂと、入力フィールドＦ３２２ａ〜Ｆ３２２ｂと、「完了」ボタンＢ３２２とを含む。
領域Ａ３２２ａには、図１４の領域Ａ３２０ａと同様の情報が表示される。
領域Ａ３２２ｂには、チケットを受け取るために必要なＵＲＬ（以下「受取用ＵＲＬ」という）が表示される。受取用ＵＲＬ「https://example.com/receive?token=ABCDEFG012345」は、チケットを受け取るための受取用トークン「ABCDEFG012345」を含む。
入力フィールドＦ３２２ａは、領域Ａ３２２ｂに表示されたＵＲＬの送信先となる会員（つまり、チケットの譲受人）の会員ＩＤを入力するための入力フィールドである。
入力フィールドＦ３２２ｂは、領域Ａ３２２ｂに表示されたＵＲＬの宛先となるメールアドレスを入力するための入力フィールドである。このメールアドレスは、図４の会員データベースにおいて会員ＩＤに関連付けられたメールアドレスであってもよいし、会員ＩＤに関連付けられていないメールアドレス（例えば、非会員ユーザのメールアドレス）であってもよい。
画面Ｐ３２２において入力フィールドＦ３２２ａに情報が入力され、かつ、「完了」ボタンＢ３２２が指定されると、クライアント端末１０は、サーバ３０に、チケットを譲渡するためのリクエスト（以下「チケット譲渡リクエスト」という）を送信する。
画面Ｐ３２２の入力フィールドＦ３２２ａに入力された会員ＩＤ（例えば、会員ＩＤ「ＣＵ９９９」）に基づいてログイン認証が行われると、図１６の画面Ｐ３３０が表示される。
画面Ｐ３３０は、入力フィールドＦ３３０ａ〜Ｆ３３０ｂと、「完了」ボタンＢ３３０とを含む。
入力フィールドＦ３３０ａは、受取用ＵＲＬを入力するための入力フィールドである。入力フィールドＦ３３０ａの受取用ＵＲＬは、予め入力されていてもよいし、ユーザが入力部１３を用いて入力してもよい。
入力フィールドＦ３３０ｂは、チケットを受け取るために必要なコード（以下「受取用コード」という）を入力するための入力フィールドである。
画面Ｐ３３０は、入力フィールドＦ３３０ａ〜Ｆ３３０ｂと、「完了」ボタンＢ３３０とを含む。
入力フィールドＦ３３０ａは、受取用ＵＲＬを入力するための入力フィールドである。入力フィールドＦ３３０ａの受取用ＵＲＬは、予め入力されていてもよいし、ユーザが入力部１３を用いて入力してもよい。
入力フィールドＦ３３０ｂは、チケットを受け取るために必要なコード（以下「受取用コード」という）を入力するための入力フィールドである。
画面Ｐ３３０において入力フィールドＦ３３０ａ又はＦ３３０ｂに情報が入力され、かつ、「完了」ボタンＢ３３０が指定されると、クライアント端末１０は、サーバ３０に、チケットを受け取るためのリクエスト（以下「チケット受取リクエスト」という）を送信する。
図１４の画面Ｐ３２０において「発行」ボタンＢ３２０ｅが指定されると、図１７の画面Ｐ３４０が表示される。
画面Ｐ３４０は、入力フィールドＦ３４０と、「完了」ボタンＢ３４０とを含む。
入力フィールドＦ３４０は、譲受人の氏名、メールアドレス、及び、住所を入力するための入力フィールドである。
画面Ｐ３４０は、入力フィールドＦ３４０と、「完了」ボタンＢ３４０とを含む。
入力フィールドＦ３４０は、譲受人の氏名、メールアドレス、及び、住所を入力するための入力フィールドである。
画面Ｐ３４０において入力フィールドＦ３４０に情報が入力され、かつ、「完了」ボタンＢ３４０が指定されると、クライアント端末１０は、サーバ３０に、チケットを発行するためのリクエスト（以下「チケット発行リクエスト」という）を送信する。
発行チケットを受け取ったユーザであって、かつ、会員ＩＤを有していないユーザ（以下「非会員ユーザ」という）によってチケット受取画面のＵＲＬにアクセスされると、図１８の画面Ｐ３５０が表示される。
画面Ｐ３５０は、入力フィールドＦ３５０ａ及びＦ３５０ｂと、「会員登録」ボタンＢ３５０ａ及び「ログイン」ボタンＢ３５０ｂとを含む。
入力フィールドＦ３５０ａ〜Ｆ３５０ｂは、それぞれ、図１６の入力フィールドＦ３３０ａ〜Ｆ３３０ｂと同様である。
画面Ｐ３５０は、入力フィールドＦ３５０ａ及びＦ３５０ｂと、「会員登録」ボタンＢ３５０ａ及び「ログイン」ボタンＢ３５０ｂとを含む。
入力フィールドＦ３５０ａ〜Ｆ３５０ｂは、それぞれ、図１６の入力フィールドＦ３３０ａ〜Ｆ３３０ｂと同様である。
入力フィールドＦ３５０ａ又はＦ３５０ｂに情報が入力され、かつ、「会員登録」ボタンＢ３５０ａが指定されると、図１１の画面Ｐ１１０が表示される。画面Ｐ１１０において入力フィールドＦ１１０に情報が入力され、かつ、「完了」ボタンＢ１１０が指定されると、クライアント端末１０は、サーバ３０に、会員登録リクエストと、チケット受取リクエストとを送信する。
入力フィールドＦ３５０ａ又はＦ３５０ｂに情報が入力され、かつ、「ログイン」ボタンＢ３５０ｂが指定されると、クライアント端末１０は、サーバ３０に、ログインリクエストと、チケット受取リクエストとを送信する。その結果、図１３の画面Ｐ３１０が表示される。
入力フィールドＦ３５０ａ又はＦ３５０ｂに情報が入力され、かつ、「ログイン」ボタンＢ３５０ｂが指定されると、クライアント端末１０は、サーバ３０に、ログインリクエストと、チケット受取リクエストとを送信する。その結果、図１３の画面Ｐ３１０が表示される。
図１１の画面Ｐ１００において「ログイン」ボタンＢ１００ｃが指定され、かつ、プロジェクトオーナＩＤ（例えば、プロジェクトオーナＩＤ「ＰＯ００１」）及びパスワードが入力されると、図１９の画面Ｐ４１０が表示される。
画面Ｐ４１０は、「プロジェクト管理」ボタンＢ４１０ａは、「リワード管理」ボタンＢ４１０ｂと、「チケット管理」ボタンＢ４１０ｃとを含む。
画面Ｐ４１０は、「プロジェクト管理」ボタンＢ４１０ａは、「リワード管理」ボタンＢ４１０ｂと、「チケット管理」ボタンＢ４１０ｃとを含む。
画面Ｐ４１０において「プロジェクト管理」ボタンＢ４１０ａが指定されると、画面Ｐ４１１が表示される。
画面Ｐ４１１は、画像ＩＭＧ４１１ａ〜ＩＭＧ４１１ｂと、領域Ａ４１１ａ〜Ａ４１１ｂと、「編集ボタン」Ｂ４１１ａ〜Ｂ４１１ｂとを含む。
画像ＩＭＧ４１１ａ〜ＩＭＧ４１１ｂは、管理の対象となるプロジェクトの画像（例えば、図５の「画像」フィールドに格納された画像データに対応する画像）である。
領域Ａ４１１ａ〜Ａ４１１ｂには、プロジェクト情報（例えば、図５の「プロジェクト名」フィールド、「目標金額」フィールド、及び、「概要」フィールドの情報）が表示される。
「編集」ボタンＢ４１１ａ〜Ｂ４１１ｂは、それぞれ、領域Ａ４１１ａ〜Ａ４１１ｂに表示されたプロジェクト情報に関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」〜「ＰＲ００２」）に関連付けられている。
画面Ｐ４１１は、画像ＩＭＧ４１１ａ〜ＩＭＧ４１１ｂと、領域Ａ４１１ａ〜Ａ４１１ｂと、「編集ボタン」Ｂ４１１ａ〜Ｂ４１１ｂとを含む。
画像ＩＭＧ４１１ａ〜ＩＭＧ４１１ｂは、管理の対象となるプロジェクトの画像（例えば、図５の「画像」フィールドに格納された画像データに対応する画像）である。
領域Ａ４１１ａ〜Ａ４１１ｂには、プロジェクト情報（例えば、図５の「プロジェクト名」フィールド、「目標金額」フィールド、及び、「概要」フィールドの情報）が表示される。
「編集」ボタンＢ４１１ａ〜Ｂ４１１ｂは、それぞれ、領域Ａ４１１ａ〜Ａ４１１ｂに表示されたプロジェクト情報に関連するプロジェクトＩＤ（例えば、プロジェクトＩＤ「ＰＲ００１」〜「ＰＲ００２」）に関連付けられている。
画面Ｐ４１１において「編集」ボタンＢ４１１ａが指定されると、クライアント端末１０は、サーバ３０に対して、「編集」ボタンＢ４１１ａに関連するプロジェクトＩＤに関連付けられたプロジェクト情報を編集するためのリクエスト（以下「プロジェクト編集リクエスト」という）を送信する。その結果、画面Ｐ４１２が表示される。図１９には図示していないが、画面Ｐ４１２は、図１２の画面Ｐ２１０と同様の入力フィールドＦ２１０ａ〜Ｆ２１０ｂと、「完了」ボタンＢ２１０とを含む。
画面Ｐ４１０において「リワード管理」ボタンＢ４１０ｂが指定されると、図２０の画面Ｐ４２０が表示される。
画面Ｐ４２０は、領域Ａ４２０と、「リワード作成」ボタンＢ４２０ａと、「選択」ボタンＢ４２０ｂ〜Ｂ４２０ｃとを含む。
領域Ａ４２０には、リワード情報（例えば、図６の「リワード名」フィールド、及び、「説明」フィールドの情報）が表示される。
「選択」ボタンＢ４２０ｂ〜Ｂ４２０ｃは、領域Ａ４２０に表示されたリワード情報に関連するリワードＩＤ（例えば、リワードＩＤ「ＲＷ００１」〜「ＲＷ００２」）に関連付けられている。
画面Ｐ４２０は、領域Ａ４２０と、「リワード作成」ボタンＢ４２０ａと、「選択」ボタンＢ４２０ｂ〜Ｂ４２０ｃとを含む。
領域Ａ４２０には、リワード情報（例えば、図６の「リワード名」フィールド、及び、「説明」フィールドの情報）が表示される。
「選択」ボタンＢ４２０ｂ〜Ｂ４２０ｃは、領域Ａ４２０に表示されたリワード情報に関連するリワードＩＤ（例えば、リワードＩＤ「ＲＷ００１」〜「ＲＷ００２」）に関連付けられている。
画面Ｐ４２０において、「リワード作成」ボタンＢ４２０ａが指定されると、画面Ｐ４２１が表示される。
画面Ｐ４２１は、入力フィールドＦ４２１と、「完了」ボタンＢ４２１とを含む。
入力フィールドＦ４２１は、リワードの作成に必要なリワード情報を入力するための入力フィールドである。リワードの作成に必要なリワード情報とは、例えば、リワード名、画像、説明、チケット上限数、チケット金額、及び、予定日である。
画面Ｐ４２１は、入力フィールドＦ４２１と、「完了」ボタンＢ４２１とを含む。
入力フィールドＦ４２１は、リワードの作成に必要なリワード情報を入力するための入力フィールドである。リワードの作成に必要なリワード情報とは、例えば、リワード名、画像、説明、チケット上限数、チケット金額、及び、予定日である。
画面Ｐ４２１において入力フィールドＦ４２１に情報が入力され、かつ、「完了」ボタンＢ４２１が指定されると、クライアント端末１０は、サーバ３０に、リワード作成の処理のリクエスト（以下「リワード作成リクエスト」という）を送信する。
画面Ｐ４２０において、「編集」ボタンＢ４２０ｂが指定されると、図２１の画面Ｐ４２２が表示される。
画面Ｐ４２２は、入力フィールドＦ４２２と、「完了」ボタンＢ４２２とを含む。
入力フィールドＦ４２２は、リワード情報を編集するための入力フィールドである。
画面Ｐ４２２は、入力フィールドＦ４２２と、「完了」ボタンＢ４２２とを含む。
入力フィールドＦ４２２は、リワード情報を編集するための入力フィールドである。
画面Ｐ４２２において入力フィールドＦ４２２に情報が入力され、かつ、「完了」ボタンＢ４２２が指定されると、クライアント端末１０は、サーバ３０に、リワード情報の編集のリクエスト（以下「リワード編集リクエスト」という）を送信する。
図１９の画面Ｐ４１０において「チケット管理」ボタンＢ４１０ｃが指定されると、図２２の画面Ｐ４３０が表示される。
画面Ｐ４３０は、領域Ａ４３０と、「選択」ボタンＢ４３０ａ〜Ｂ４３０ｂとを含む。
領域Ａ４３０には、チケット情報（例えば、図８の「チケットＩＤ」フィールド、「チケットオーナＩＤ」フィールド、及び、「ステータス」フィールドの情報）と、チケットタイトル（例えば、図６のリワードＩＤ「ＲＥ００１」に関連付けられた「リワード名」フィールドの情報）とが表示される。
「選択」ボタンＢ４３０ａ〜Ｂ４３０ｂは、それぞれ、領域Ａ４３０に表示されたチケットＩＤ「ＴＩ００１」〜「ＴＩ００２］に関連付けられている。
画面Ｐ４３０は、領域Ａ４３０と、「選択」ボタンＢ４３０ａ〜Ｂ４３０ｂとを含む。
領域Ａ４３０には、チケット情報（例えば、図８の「チケットＩＤ」フィールド、「チケットオーナＩＤ」フィールド、及び、「ステータス」フィールドの情報）と、チケットタイトル（例えば、図６のリワードＩＤ「ＲＥ００１」に関連付けられた「リワード名」フィールドの情報）とが表示される。
「選択」ボタンＢ４３０ａ〜Ｂ４３０ｂは、それぞれ、領域Ａ４３０に表示されたチケットＩＤ「ＴＩ００１」〜「ＴＩ００２］に関連付けられている。
画面Ｐ４３０において「選択」ボタンＢ４２０ａが指定されると、画面Ｐ４３１が表示される。
画面Ｐ４３１は、領域Ａ４３１と、「完了」ボタンＢ４３１とを含む。
領域Ａ４３１には、報酬の発送先となる会員に関する会員情報（例えば、図４の「氏名」フィールド、及び、「住所」フィールドの情報）が表示される。
画面Ｐ４３１は、領域Ａ４３１と、「完了」ボタンＢ４３１とを含む。
領域Ａ４３１には、報酬の発送先となる会員に関する会員情報（例えば、図４の「氏名」フィールド、及び、「住所」フィールドの情報）が表示される。
リワード（例えば、プロジェクトに関連する商品の発送）が完了した後に画面Ｐ４３１において「完了」ボタンＢ４３１が指定されると、クライアント端末１０は、サーバ３０に、チケットＩＤ「ＴＩ００１」によって識別されるチケットのステータスを変更するためのリワード完了リクエストを送信する。
（１−６）情報処理のフロー（図２３〜図３０）
第１実施形態の情報処理のフローについて説明する。以下の情報処理は、図２のＣＰＵ１２が記憶装置１１に記憶されたアプリケーション（例えば、ブラウザ）のプログラムを実行し、かつ、図３のＣＰＵ３２が記憶装置３１に記憶されたプログラムを実行することによって、実現される。
クライアント端末１０とサーバ３０とは、通信網ＮＷを介して、ｈｔｔｐｓ通信を行うことによって以下の情報処理を実現する。
第１実施形態の情報処理のフローについて説明する。以下の情報処理は、図２のＣＰＵ１２が記憶装置１１に記憶されたアプリケーション（例えば、ブラウザ）のプログラムを実行し、かつ、図３のＣＰＵ３２が記憶装置３１に記憶されたプログラムを実行することによって、実現される。
クライアント端末１０とサーバ３０とは、通信網ＮＷを介して、ｈｔｔｐｓ通信を行うことによって以下の情報処理を実現する。
（１−６−１）会員登録の処理のフロー（図２３）
第１実施形態の会員登録の処理について説明する。図２３は、第１実施形態の会員登録の処理のシーケンス図である。
第１実施形態の会員登録の処理について説明する。図２３は、第１実施形態の会員登録の処理のシーケンス図である。
図２３のクライアント端末１０のユーザは、非会員ユーザである。
はじめに、クライアント端末１０は、トップ画面の表示（Ｓ１００）を実行する。
具体的には、非会員ユーザが、入力部１３を用いて、トップ画面用のＵＲＬを指定すると、ＣＰＵ１２は、図１１の画面Ｐ１００を表示部１４に表示する。
具体的には、非会員ユーザが、入力部１３を用いて、トップ画面用のＵＲＬを指定すると、ＣＰＵ１２は、図１１の画面Ｐ１００を表示部１４に表示する。
クライアント端末１０は、会員登録画面の表示（Ｓ１０１）を実行する。
具体的には、非会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「会員登録」ボタンＢ１００ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ１１０を表示部１４に表示する。
具体的には、非会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「会員登録」ボタンＢ１００ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ１１０を表示部１４に表示する。
クライアント端末１０は、会員リクエスト（Ｓ１０２）を実行する。
具体的には、非会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１１０の入力フィールドＦ１１０に情報を入力し、かつ、「完了」ボタンＢ１１０を指定すると、ＣＰＵ１２は、会員登録リクエストを作成する。会員登録リクエストは、入力フィールドＦ１１０に入力された情報を含む。
次に、ＣＰＵ１２は、会員登録リクエストをサーバ３０に送信する。
具体的には、非会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１１０の入力フィールドＦ１１０に情報を入力し、かつ、「完了」ボタンＢ１１０を指定すると、ＣＰＵ１２は、会員登録リクエストを作成する。会員登録リクエストは、入力フィールドＦ１１０に入力された情報を含む。
次に、ＣＰＵ１２は、会員登録リクエストをサーバ３０に送信する。
サーバ３０は、データベースの更新（Ｓ３００）を実行する。
具体的には、ＣＰＵ３２は、図４の会員データベースに新規レコードを追加する。新規レコードの「会員ＩＤ」フィールドには、新しい会員ＩＤが格納される。新規レコードの「メールアドレス」フィールド、「パスワード」フィールド、「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドには、それぞれ、会員登録リクエストに含まれる情報（氏名、メールアドレス、パスワード、画像、住所、及び、支払情報）が格納される。
具体的には、ＣＰＵ３２は、図４の会員データベースに新規レコードを追加する。新規レコードの「会員ＩＤ」フィールドには、新しい会員ＩＤが格納される。新規レコードの「メールアドレス」フィールド、「パスワード」フィールド、「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドには、それぞれ、会員登録リクエストに含まれる情報（氏名、メールアドレス、パスワード、画像、住所、及び、支払情報）が格納される。
以上の処理により、会員登録の処理が終了する。
（１−６−２）プロジェクト作成の処理のフロー（図２４）
第１実施形態のプロジェクト作成の処理について説明する。図２４は、第１実施形態のプロジェクト作成の処理のシーケンス図である。
第１実施形態のプロジェクト作成の処理について説明する。図２４は、第１実施形態のプロジェクト作成の処理のシーケンス図である。
図２４のクライアント端末１０のユーザは、プロジェクト作成者である。
はじめに、クライアント端末１０は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０は、プロジェクト作成画面の表示（Ｓ１１０）を実行する。
具体的には、プロジェクト作成者が、入力部１３を用いて、図１１の画面Ｐ１００の「プロジェクト作成」ボタンＢ１００ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１２の画面Ｐ２１０を表示部１４に表示する。
具体的には、プロジェクト作成者が、入力部１３を用いて、図１１の画面Ｐ１００の「プロジェクト作成」ボタンＢ１００ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１２の画面Ｐ２１０を表示部１４に表示する。
クライアント端末１０は、プロジェクト作成リクエスト（Ｓ１１１）を実行する。
具体的には、プロジェクト作成者が、入力部１３を用いて、図１２の画面Ｐ２１０の入力フィールドＦ２１０ａ〜Ｆ２１０ｂに情報を入力し、かつ、「完了」ボタンＢ２１０を指定すると、ＣＰＵ１２は、プロジェクト作成リクエストを作成する。プロジェクト作成リクエストは、入力フィールドＦ２１０ａ〜Ｆ２１０ｂに入力された情報を含む。
次に、ＣＰＵ１２は、プロジェクト作成リクエストをサーバ３０に送信する。
具体的には、プロジェクト作成者が、入力部１３を用いて、図１２の画面Ｐ２１０の入力フィールドＦ２１０ａ〜Ｆ２１０ｂに情報を入力し、かつ、「完了」ボタンＢ２１０を指定すると、ＣＰＵ１２は、プロジェクト作成リクエストを作成する。プロジェクト作成リクエストは、入力フィールドＦ２１０ａ〜Ｆ２１０ｂに入力された情報を含む。
次に、ＣＰＵ１２は、プロジェクト作成リクエストをサーバ３０に送信する。
サーバ３０は、プロジェクトの審査（Ｓ３１０）を実行する。
具体的には、ＣＰＵ３２は、記憶装置３１に記憶された要件情報に基づいて、プロジェクト作成リクエストに含まれる情報（プロジェクトオーナの氏名、プロジェクトオーナのメールアドレス、プロジェクトオーナのプロフィール、プロジェクト名、プロジェクトの目標金額、プロジェクトの概要、プロジェクトの開始日、プロジェクトの終了日、プロジェクトの画像、及び、プロジェクトのタイプ）がプロジェクト要件を満たすか否かを審査する。
「要件情報」とは、プロジェクトとして登録するための要件を示す情報である。
なお、プロジェクト作成リクエストに含まれる情報の一部がプロジェクト要件を満たすか否かを、サーバ３０のオペレータが審査してもよい。この場合、ＣＰＵ３２が、プロジェクト作成リクエストに含まれる情報の一部について審査を行い、オペレータが、残りの部分について審査を行う。
具体的には、ＣＰＵ３２は、記憶装置３１に記憶された要件情報に基づいて、プロジェクト作成リクエストに含まれる情報（プロジェクトオーナの氏名、プロジェクトオーナのメールアドレス、プロジェクトオーナのプロフィール、プロジェクト名、プロジェクトの目標金額、プロジェクトの概要、プロジェクトの開始日、プロジェクトの終了日、プロジェクトの画像、及び、プロジェクトのタイプ）がプロジェクト要件を満たすか否かを審査する。
「要件情報」とは、プロジェクトとして登録するための要件を示す情報である。
なお、プロジェクト作成リクエストに含まれる情報の一部がプロジェクト要件を満たすか否かを、サーバ３０のオペレータが審査してもよい。この場合、ＣＰＵ３２が、プロジェクト作成リクエストに含まれる情報の一部について審査を行い、オペレータが、残りの部分について審査を行う。
サーバ３０は、データベースの更新（Ｓ３１１）を実行する。
具体的には、プロジェクト作成リクエストに含まれる情報がプロジェクト要件を満たす場合、ＣＰＵ３２は、図５のプロジェクトデータベースに新規レコードを追加する。新規レコードの「プロジェクトＩＤ」フィールド及び「プロジェクトオーナＩＤ」フィールドには、それぞれ、新しいプロジェクトＩＤ及び新しいプロジェクトオーナＩＤが格納される。新規レコードの「パスワード」フィールドには、ランダムで決定されたパスワードが格納される。新規レコードの「メールアドレス」フィールド、「氏名」フィールド、「プロフィール」フィールド、「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、「画像」フィールド、「開始日」フィールド、「終了日」フィールド、及び、「タイプ」フィールドには、それぞれ、プロジェクト作成リクエストに含まれる情報（メールアドレス、氏名、プロフィール、プロジェクト名、目標金額、概要、画像、開始日、終了日、及び、タイプ）が格納される。
具体的には、プロジェクト作成リクエストに含まれる情報がプロジェクト要件を満たす場合、ＣＰＵ３２は、図５のプロジェクトデータベースに新規レコードを追加する。新規レコードの「プロジェクトＩＤ」フィールド及び「プロジェクトオーナＩＤ」フィールドには、それぞれ、新しいプロジェクトＩＤ及び新しいプロジェクトオーナＩＤが格納される。新規レコードの「パスワード」フィールドには、ランダムで決定されたパスワードが格納される。新規レコードの「メールアドレス」フィールド、「氏名」フィールド、「プロフィール」フィールド、「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、「画像」フィールド、「開始日」フィールド、「終了日」フィールド、及び、「タイプ」フィールドには、それぞれ、プロジェクト作成リクエストに含まれる情報（メールアドレス、氏名、プロフィール、プロジェクト名、目標金額、概要、画像、開始日、終了日、及び、タイプ）が格納される。
以上の処理により、プロジェクト作成の処理が終了する。
（１−６−３）支援の処理のフロー（図２５）
第１実施形態の支援の処理について説明する。図２５は、第１実施形態の支援の処理のシーケンス図である。
第１実施形態の支援の処理について説明する。図２５は、第１実施形態の支援の処理のシーケンス図である。
図２５のクライアント端末１０のユーザは、会員ユーザ（会員ＩＤ「ＣＵ００１」名「会員１」）である。
はじめに、クライアント端末１０は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０は、ログインリクエスト（Ｓ１２０）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「ログイン」ボタンＢ１００ｃを指定し、かつ、会員ＩＤ及びパスワードを入力すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、会員ＩＤ及びパスワードを含む。
具体的には、会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「ログイン」ボタンＢ１００ｃを指定し、かつ、会員ＩＤ及びパスワードを入力すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、会員ＩＤ及びパスワードを含む。
サーバ３０は、ログイン認証（Ｓ３２０）を実行する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれる会員ＩＤ及びパスワードと、図４の会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれる会員ＩＤ及びパスワードと、会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致する場合、ＣＰＵ３２は、ログインを許可する。一方、ログインリクエストに含まれる会員ＩＤ及びパスワードと、会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致しない場合、ＣＰＵ３２は、ログインを拒否する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれる会員ＩＤ及びパスワードと、図４の会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれる会員ＩＤ及びパスワードと、会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致する場合、ＣＰＵ３２は、ログインを許可する。一方、ログインリクエストに含まれる会員ＩＤ及びパスワードと、会員データベースの「会員ＩＤ」フィールド及び「パスワード」フィールドの情報とが一致しない場合、ＣＰＵ３２は、ログインを拒否する。
ログインが許可されると、クライアント端末１０は、会員ホーム画面の表示（Ｓ１２１）を実行する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれる会員ＩＤに対応する会員ホーム画面を表示させるためのレスポンスをクライアント端末１０に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、図１３の画面Ｐ３１０を表示部１４に表示する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれる会員ＩＤに対応する会員ホーム画面を表示させるためのレスポンスをクライアント端末１０に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、図１３の画面Ｐ３１０を表示部１４に表示する。
クライアント端末１０は、プロジェクト選択画面の表示（Ｓ１２２）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１０の「支援」ボタンＢ３１０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ３１１を表示部１４に表示する。画面Ｐ３１１には、選択可能なプロジェクト（例えば、返金条件（後述する）を満たしていないプロジェクト）に関するプロジェクト情報が表示される。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１０の「支援」ボタンＢ３１０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ３１１を表示部１４に表示する。画面Ｐ３１１には、選択可能なプロジェクト（例えば、返金条件（後述する）を満たしていないプロジェクト）に関するプロジェクト情報が表示される。
クライアント端末１０は、リワード選択画面の表示（Ｓ１２３）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１１の「選択」ボタンＢ３１１ａを指定すると、ＣＰＵ１２は、リクエストをサーバ３０に送信する。このリクエストは、「選択」ボタンＢ３１１ａに関連付けられたプロジェクトＩＤ「ＰＲ００１」を含む。
次に、ＣＰＵ３２は、クライアント端末１０から送信されたリクエストに含まれるプロジェクトＩＤ「ＰＲ００１」に対応するプロジェクト選択画面を表示させるためのレスポンスをクライアント端末１０に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ３１２を表示部１４に表示する。画面Ｐ３１２には、選択可能なリワードに関するリワード情報（例えば、図６の「チケット配布数」フィールドの値が「チケット上限数」フィールドの値未満であるレコードの情報）が表示される。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１１の「選択」ボタンＢ３１１ａを指定すると、ＣＰＵ１２は、リクエストをサーバ３０に送信する。このリクエストは、「選択」ボタンＢ３１１ａに関連付けられたプロジェクトＩＤ「ＰＲ００１」を含む。
次に、ＣＰＵ３２は、クライアント端末１０から送信されたリクエストに含まれるプロジェクトＩＤ「ＰＲ００１」に対応するプロジェクト選択画面を表示させるためのレスポンスをクライアント端末１０に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ３１２を表示部１４に表示する。画面Ｐ３１２には、選択可能なリワードに関するリワード情報（例えば、図６の「チケット配布数」フィールドの値が「チケット上限数」フィールドの値未満であるレコードの情報）が表示される。
クライアント端末１０は、支援リクエスト（Ｓ１２４）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１２の入力フィールドＦ３１２に、取得を希望するチケットの数量を入力し、かつ、「完了」ボタンＢ３１２を指定すると、ＣＰＵ１２は、支援リクエストを作成する。支援リクエストは、リワードＩＤと、リワードＩＤに対応する数量（入力フィールドＦ３１２に入力された情報）とを含む。
次に、ＣＰＵ１２は、支援リクエストをサーバ３０に送信する。
具体的には、会員ユーザが、入力部１３を用いて、図１３の画面Ｐ３１２の入力フィールドＦ３１２に、取得を希望するチケットの数量を入力し、かつ、「完了」ボタンＢ３１２を指定すると、ＣＰＵ１２は、支援リクエストを作成する。支援リクエストは、リワードＩＤと、リワードＩＤに対応する数量（入力フィールドＦ３１２に入力された情報）とを含む。
次に、ＣＰＵ１２は、支援リクエストをサーバ３０に送信する。
サーバ３０は、入金の確認（Ｓ３２１）を実行する。
具体的には、ＣＰＵ３２は、図６のリワードデータベースを参照して、支援リクエストに含まれるリワードＩＤに対応する数量とチケット金額との積を計算する。この計算結果は、会員ユーザの支援金額を意味する。
次に、ＣＰＵ３２は、図４の会員データベースを参照して、ログインリクエストに含まれる会員ＩＤに関連付けられた支払情報に基づいて、決済リクエストの送信先となるクレジットカード会社のサーバを特定する。
次に、ＣＰＵ３２は、所定時間毎に、金融機関等のサーバに、入金の確認を要求するためのリクエストを送信する。
具体的には、ＣＰＵ３２は、図６のリワードデータベースを参照して、支援リクエストに含まれるリワードＩＤに対応する数量とチケット金額との積を計算する。この計算結果は、会員ユーザの支援金額を意味する。
次に、ＣＰＵ３２は、図４の会員データベースを参照して、ログインリクエストに含まれる会員ＩＤに関連付けられた支払情報に基づいて、決済リクエストの送信先となるクレジットカード会社のサーバを特定する。
次に、ＣＰＵ３２は、所定時間毎に、金融機関等のサーバに、入金の確認を要求するためのリクエストを送信する。
サーバ３０は、入金の確認に成功すると（Ｓ３２１−ＹＥＳ）、データベースの更新（Ｓ３２２）を実行する。
具体的には、ＣＰＵ３２は、支援リクエストに含まれる情報（リワードＩＤ、及び、リワードＩＤに対応する数量）に基づいて、図６のリワードデータベースの「チケット配布数」フィールドを更新する。
次に、ＣＰＵ３２は、図７の支援履歴データベースに新規レコードを追加する。新規レコードの「支援ＩＤ」フィールドには、新しい支援ＩＤが格納される。新規レコードの「支援金額」フィールドには、支援金額を示す値が格納される。新規レコードの「支援日」フィールドには、支援リクエスト（Ｓ１２４）の実行日を示す値が格納される。
次に、ＣＰＵ３２は、図８のチケットデータベースに新規レコードを追加する。新規レコードの「支援ＩＤ」フィールドには、支援履歴データベースの新規レコードの「支援ＩＤ」フィールドに格納された支援ＩＤが格納される。新規レコードの「ステータス」フィールドには、ステータスコード「ＳＴＡ１」が格納される。これにより、チケットのステータスは、利用可能状態になる。
具体的には、ＣＰＵ３２は、支援リクエストに含まれる情報（リワードＩＤ、及び、リワードＩＤに対応する数量）に基づいて、図６のリワードデータベースの「チケット配布数」フィールドを更新する。
次に、ＣＰＵ３２は、図７の支援履歴データベースに新規レコードを追加する。新規レコードの「支援ＩＤ」フィールドには、新しい支援ＩＤが格納される。新規レコードの「支援金額」フィールドには、支援金額を示す値が格納される。新規レコードの「支援日」フィールドには、支援リクエスト（Ｓ１２４）の実行日を示す値が格納される。
次に、ＣＰＵ３２は、図８のチケットデータベースに新規レコードを追加する。新規レコードの「支援ＩＤ」フィールドには、支援履歴データベースの新規レコードの「支援ＩＤ」フィールドに格納された支援ＩＤが格納される。新規レコードの「ステータス」フィールドには、ステータスコード「ＳＴＡ１」が格納される。これにより、チケットのステータスは、利用可能状態になる。
以上の処理により、支援の処理が終了する。
（１−６−４）チケット利用の処理のフロー（図２６）
第１実施形態のチケット利用の処理について説明する。図２６は、第１実施形態のチケット利用の処理のシーケンス図である。
第１実施形態のチケット利用の処理について説明する。図２６は、第１実施形態のチケット利用の処理のシーケンス図である。
図２６のクライアント端末１０−１のユーザは、チケットオーナ（会員ＩＤ「ＣＵ００１」）である。クライアント端末１０−２のユーザは、プロジェクトオーナ（プロジェクトオーナＩＤ「ＰＯ００１」）である。
はじめに、クライアント端末１０−１〜１０−２は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０−１は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１は、図２５と同様に、会員ホーム画面の表示（Ｓ１２１）を実行する。
クライアント端末１０−１は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１は、図２５と同様に、会員ホーム画面の表示（Ｓ１２１）を実行する。
クライアント端末１０−１は、チケット一覧画面の表示（Ｓ１３０）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、図１３の画面Ｐ３１０の「所有チケット一覧」ボタンＢ３１０ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１４の画面Ｐ３２０を表示部１４に表示する。画面Ｐ３２０には、チケットオーナが所有するチケットのうち利用可能状態であるチケットに関するチケット情報（例えば、図８の「ステータス」フィールドにチケットコード「ＳＴＡ１」が格納されたレコードの情報）が表示される。
具体的には、チケットオーナが、入力部１３を用いて、図１３の画面Ｐ３１０の「所有チケット一覧」ボタンＢ３１０ｂを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１４の画面Ｐ３２０を表示部１４に表示する。画面Ｐ３２０には、チケットオーナが所有するチケットのうち利用可能状態であるチケットに関するチケット情報（例えば、図８の「ステータス」フィールドにチケットコード「ＳＴＡ１」が格納されたレコードの情報）が表示される。
クライアント端末１０−１は、チケット利用画面の表示（Ｓ１３１）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「利用」ボタンＢ３２０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信を行うことによって、画面Ｐ３２１を表示部１４に表示する。画面Ｐ３２１には、「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤに関連する情報（例えば、プロジェクト名、リワード名、及び、チケット金額）が表示される。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「利用」ボタンＢ３２０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信を行うことによって、画面Ｐ３２１を表示部１４に表示する。画面Ｐ３２１には、「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤに関連する情報（例えば、プロジェクト名、リワード名、及び、チケット金額）が表示される。
クライアント端末１０−１は、チケット利用リクエスト（Ｓ１３２）を実行する。
具体的には、チケットオーナが、図１４の画面Ｐ３２１の「ＹＥＳ」ボタンＢ３２１ａを指定すると、ＣＰＵ１２は、チケット利用リクエストをサーバ３０に送信する。チケット利用リクエストは、画面Ｐ３２０において指定された「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤを含む。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−１から送信されたチケット利用リクエストに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ３」を格納する。これにより、チケットのステータスは、利用可能状態から利用中状態になる。
具体的には、チケットオーナが、図１４の画面Ｐ３２１の「ＹＥＳ」ボタンＢ３２１ａを指定すると、ＣＰＵ１２は、チケット利用リクエストをサーバ３０に送信する。チケット利用リクエストは、画面Ｐ３２０において指定された「利用」ボタンＢ３２０ａに関連付けられたチケットＩＤを含む。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−１から送信されたチケット利用リクエストに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ３」を格納する。これにより、チケットのステータスは、利用可能状態から利用中状態になる。
クライアント端末１０−２は、ログインリクエスト（Ｓ１３３）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「ログイン」ボタンＢ１００ｃを指定し、かつ、プロジェクトオーナＩＤ及びパスワードを入力すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、プロジェクトオーナＩＤ及びパスワードを含む。
具体的には、会員ユーザが、入力部１３を用いて、図１１の画面Ｐ１００の「ログイン」ボタンＢ１００ｃを指定し、かつ、プロジェクトオーナＩＤ及びパスワードを入力すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、プロジェクトオーナＩＤ及びパスワードを含む。
サーバ３０は、ログインリクエスト（Ｓ１３３）に対するログイン認証（Ｓ３２０）を実行する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、図５のプロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、プロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とが一致する場合、ＣＰＵ３２は、ログインを許可する。一方、ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、プロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とが一致しない場合、ＣＰＵ３２は、ログインを拒否する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、図５のプロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とを照合する。ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、プロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とが一致する場合、ＣＰＵ３２は、ログインを許可する。一方、ログインリクエストに含まれるプロジェクトオーナＩＤ及びパスワードと、プロジェクトデータベースの「プロジェクトオーナＩＤ」フィールド及び「パスワード」フィールドの情報とが一致しない場合、ＣＰＵ３２は、ログインを拒否する。
ログインが許可されると、クライアント端末１０−２は、プロジェクトオーナホーム画面の表示（Ｓ１３４）を実行する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれるプロジェクトオーナＩＤに対応するプロジェクトオーナホーム画面を表示させるためのレスポンスをクライアント端末１０−２に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、図１９の画面Ｐ４１０を表示部１４に表示する。
具体的には、ＣＰＵ３２は、ログインリクエストに含まれるプロジェクトオーナＩＤに対応するプロジェクトオーナホーム画面を表示させるためのレスポンスをクライアント端末１０−２に送信する。
次に、ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、図１９の画面Ｐ４１０を表示部１４に表示する。
Ｓ３３０の後に、クライアント端末１０−２は、チケット管理画面の表示（Ｓ１３５）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１０の「チケット管理」ボタンＢ４１０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図２２の画面Ｐ４３０を表示部１４に表示する。画面Ｐ４３０には、選択可能なチケットに関するチケット情報（例えば、図８のチケットデータベースの情報）が表示される。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１０の「チケット管理」ボタンＢ４１０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図２２の画面Ｐ４３０を表示部１４に表示する。画面Ｐ４３０には、選択可能なチケットに関するチケット情報（例えば、図８のチケットデータベースの情報）が表示される。
クライアント端末１０−２は、リワード完了画面の表示（Ｓ１３６）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図２２の画面Ｐ４３０の「選択」ボタンＢ４３０ａを指定すると、ＣＰＵ１２は、リクエストをサーバ３０に送信する。このリクエストは、「選択」ボタンＢ４３０ａに関連付けられたチケットＩＤを含む。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいてクライアント端末１０−２から送信されたリクエストに含まれるチケットＩＤに関連付けられたチケットオーナＩＤ（つまり、チケットオーナを識別する会員ＩＤ）を特定する。
次に、ＣＰＵ３２は、特定した会員ＩＤに対応するリワード完了画面を表示させるためのレスポンスをクライアント端末１０−２に送信する。
ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ４３１を表示部１４に表示する。画面Ｐ４３１には、ＣＰＵ３２が特定した会員ＩＤに関連付けられた会員情報（例えば、図４の「氏名」フィールド、及び、「住所」フィールドの情報）が表示される。
具体的には、プロジェクトオーナが、入力部１３を用いて、図２２の画面Ｐ４３０の「選択」ボタンＢ４３０ａを指定すると、ＣＰＵ１２は、リクエストをサーバ３０に送信する。このリクエストは、「選択」ボタンＢ４３０ａに関連付けられたチケットＩＤを含む。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいてクライアント端末１０−２から送信されたリクエストに含まれるチケットＩＤに関連付けられたチケットオーナＩＤ（つまり、チケットオーナを識別する会員ＩＤ）を特定する。
次に、ＣＰＵ３２は、特定した会員ＩＤに対応するリワード完了画面を表示させるためのレスポンスをクライアント端末１０−２に送信する。
ＣＰＵ１２は、サーバ３０から送信されたレスポンスに基づいて、画面Ｐ４３１を表示部１４に表示する。画面Ｐ４３１には、ＣＰＵ３２が特定した会員ＩＤに関連付けられた会員情報（例えば、図４の「氏名」フィールド、及び、「住所」フィールドの情報）が表示される。
クライアント端末１０−２は、リワード完了リクエスト（Ｓ１３６）を実行する。
具体的には、プロジェクトオーナが、報酬をチケットオーナ宛に発送した後、入力部１３を用いて、図２２の画面Ｐ４３１の「完了」ボタンＢ４３１を指定すると、ＣＰＵ１２は、リワード完了リクエストをサーバ３０に送信する。リワード完了リクエストは、指定された「選択」ボタンＢ４３０ａに関連付けられたチケットＩＤを含む。
具体的には、プロジェクトオーナが、報酬をチケットオーナ宛に発送した後、入力部１３を用いて、図２２の画面Ｐ４３１の「完了」ボタンＢ４３１を指定すると、ＣＰＵ１２は、リワード完了リクエストをサーバ３０に送信する。リワード完了リクエストは、指定された「選択」ボタンＢ４３０ａに関連付けられたチケットＩＤを含む。
サーバ３０は、データベースの更新（Ｓ３３１）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたリワード完了リクエストに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ４」を格納する。これにより、チケットのステータスは、利用中状態から利用済状態になる。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたリワード完了リクエストに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ４」を格納する。これにより、チケットのステータスは、利用中状態から利用済状態になる。
以上の処理により、チケット利用の処理が終了する。
（１−６−５）チケット譲渡の処理（１）のフロー（図２７）
第１実施形態のチケット譲渡の処理の第１例について説明する。図２７は、第１実施形態のチケット譲渡の処理の第１例のシーケンス図である。
第１実施形態のチケット譲渡の処理の第１例について説明する。図２７は、第１実施形態のチケット譲渡の処理の第１例のシーケンス図である。
図２７のクライアント端末１０−１のユーザは、チケットオーナ（会員ＩＤ「ＣＵ００１」）である。クライアント端末１０−２のユーザは、会員ユーザ（会員ＩＤ「ＣＵ９９９」）である。
はじめに、クライアント端末１０−１〜１０−２は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０−１〜１０−２は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１〜１０−２は、図２５と同様に、会員ホーム画面の表示（Ｓ１２１）を実行する。
クライアント端末１０−１は、図２６と同様に、チケット一覧画面の表示（Ｓ１３０）を実行する。
クライアント端末１０−１〜１０−２は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１〜１０−２は、図２５と同様に、会員ホーム画面の表示（Ｓ１２１）を実行する。
クライアント端末１０−１は、図２６と同様に、チケット一覧画面の表示（Ｓ１３０）を実行する。
クライアント端末１０−１は、チケット譲渡画面の表示（Ｓ１４０）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「譲渡」ボタンＢ３２０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１５の画面Ｐ３２２を表示部１４に表示する。画面Ｐ３２２には、「譲渡」ボタンＢ３２０ｃに関連付けられたチケットＩＤに関連する情報（例えば、プロジェクト名、リワード名、及び、チケット金額）と、当該チケットＩＤによって識別されるチケットを譲渡するために必要なＵＲＬとが表示される。
チケットオーナが、入力部１３を用いて、画面Ｐ３２２の入力フィールドＦ３２２ａに譲受人の会員ＩＤを入力し、かつ、「完了」ボタンＢ３２２を指定すると、ＣＰＵ１２は、チケット譲渡リクエストをサーバ３０に送信する。チケット譲渡リクエストは、ログインリクエストに含まれる会員ＩＤ「ＣＵ００１」と、「譲渡」ボタンＢ３２０ｃに関連付けられたチケットＩＤと、入力フィールドＦ３２２ａに入力された会員ＩＤ「ＣＵ９９９」とを含む。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「譲渡」ボタンＢ３２０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１５の画面Ｐ３２２を表示部１４に表示する。画面Ｐ３２２には、「譲渡」ボタンＢ３２０ｃに関連付けられたチケットＩＤに関連する情報（例えば、プロジェクト名、リワード名、及び、チケット金額）と、当該チケットＩＤによって識別されるチケットを譲渡するために必要なＵＲＬとが表示される。
チケットオーナが、入力部１３を用いて、画面Ｐ３２２の入力フィールドＦ３２２ａに譲受人の会員ＩＤを入力し、かつ、「完了」ボタンＢ３２２を指定すると、ＣＰＵ１２は、チケット譲渡リクエストをサーバ３０に送信する。チケット譲渡リクエストは、ログインリクエストに含まれる会員ＩＤ「ＣＵ００１」と、「譲渡」ボタンＢ３２０ｃに関連付けられたチケットＩＤと、入力フィールドＦ３２２ａに入力された会員ＩＤ「ＣＵ９９９」とを含む。
サーバ３０は、データベースの更新（Ｓ３４０）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット譲渡リクエトに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ２」を格納する。これにより、チケットのステータスは、譲渡中状態になる。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット譲渡リクエトに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ２」を格納する。これにより、チケットのステータスは、譲渡中状態になる。
クライアント端末１０−２は、チケット受取画面の表示（Ｓ１４２）を実行する。
具体的には、譲受人が、入力部１３を用いて、図１３の画面Ｐ３１０の「チケット受取」ボタンＢ３１０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１６の画面Ｐ３３０を表示部１４に表示する。画面Ｐ３３０には、チケット譲渡リクエストに含まれるチケットＩＤに関連付けられた受取用ＵＲＬが予め表示される。
具体的には、譲受人が、入力部１３を用いて、図１３の画面Ｐ３１０の「チケット受取」ボタンＢ３１０ｃを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１６の画面Ｐ３３０を表示部１４に表示する。画面Ｐ３３０には、チケット譲渡リクエストに含まれるチケットＩＤに関連付けられた受取用ＵＲＬが予め表示される。
クライアント端末１０−２は、チケット受取リクエスト（Ｓ１４３）を実行する。
具体的には、譲受人が、図１６の画面Ｐ３３０の入力フィールドＦ３３０ａに表示された受取用ＵＲＬを指定（例えば、入力フィールドＦ３３０ａに予め表示された受取用ＵＲＬをクリック、又は、入力フィールドＦ３３０ａに受取用ＵＲＬを入力）すると、ＣＰＵ１２は、チケット受取リクエストをサーバ３０に送信する。チケット受取リクエストは、受取用ＵＲＬと、譲受人を識別する会員ＩＤ「ＣＵ９９９」とを含む。
具体的には、譲受人が、図１６の画面Ｐ３３０の入力フィールドＦ３３０ａに表示された受取用ＵＲＬを指定（例えば、入力フィールドＦ３３０ａに予め表示された受取用ＵＲＬをクリック、又は、入力フィールドＦ３３０ａに受取用ＵＲＬを入力）すると、ＣＰＵ１２は、チケット受取リクエストをサーバ３０に送信する。チケット受取リクエストは、受取用ＵＲＬと、譲受人を識別する会員ＩＤ「ＣＵ９９９」とを含む。
サーバ３０は、データベースの更新（Ｓ３４１）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたチケット受取リクエストに含まれる受取用ＵＲＬに関連付けられたチケットＩＤを含むレコードを特定する。
次に、ＣＰＵ３２は、特定したレコードの「トークン期限」フィールドの値が示す期限をＳ１４３の実行日が過ぎていない場合、当該レコードの「チケットオーナ」フィールドに、譲受人を識別する会員ＩＤ「ＣＵ９９９」を格納する。これにより、チケットオーナが譲受人（会員ＩＤ「９９９」）に変わる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、特定したレコードの「ステータス」フィールドに、ステータスコード「ＳＴＡ１」を格納する。これにより、チケットのステータスは、利用可能状態になる。
次に、ＣＰＵ３２は、受取用ＵＲＬに関連付けられたチケットＩＤに関連付けられた譲渡履歴データベース（図１０）に新規レコードを追加する。新規レコードの「登録日」フィールドには、Ｓ３４１の実行日「２０１６／０１／１０」を示す値が格納される。新規レコードの「譲渡人ＩＤ」フィールドには、譲渡人を識別する会員ＩＤ「ＣＵ００１」が格納される。新規レコードの「譲受人ＩＤ」フィールドには、譲受人を識別する会員ＩＤ「ＣＵ９９９」が格納される。これにより、チケットの譲渡履歴が更新される。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたチケット受取リクエストに含まれる受取用ＵＲＬに関連付けられたチケットＩＤを含むレコードを特定する。
次に、ＣＰＵ３２は、特定したレコードの「トークン期限」フィールドの値が示す期限をＳ１４３の実行日が過ぎていない場合、当該レコードの「チケットオーナ」フィールドに、譲受人を識別する会員ＩＤ「ＣＵ９９９」を格納する。これにより、チケットオーナが譲受人（会員ＩＤ「９９９」）に変わる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、特定したレコードの「ステータス」フィールドに、ステータスコード「ＳＴＡ１」を格納する。これにより、チケットのステータスは、利用可能状態になる。
次に、ＣＰＵ３２は、受取用ＵＲＬに関連付けられたチケットＩＤに関連付けられた譲渡履歴データベース（図１０）に新規レコードを追加する。新規レコードの「登録日」フィールドには、Ｓ３４１の実行日「２０１６／０１／１０」を示す値が格納される。新規レコードの「譲渡人ＩＤ」フィールドには、譲渡人を識別する会員ＩＤ「ＣＵ００１」が格納される。新規レコードの「譲受人ＩＤ」フィールドには、譲受人を識別する会員ＩＤ「ＣＵ９９９」が格納される。これにより、チケットの譲渡履歴が更新される。
このように、サーバ３０は、チケット譲渡リクエスト（Ｓ１４１）が行われてからチケット受取リクエスト（Ｓ１４３）が行われるまでの間、譲渡されるチケットを利用できないようにする。
また、サーバ３０は、チケット譲渡の処理を実行する毎に、チケットの譲渡履歴を更新する。
また、サーバ３０は、チケット譲渡の処理を実行する毎に、チケットの譲渡履歴を更新する。
以上の処理により、チケット譲渡の処理が終了する。
（１−６−６）チケット譲渡の処理（２）のフロー（図２８）
第１実施形態のチケット譲渡の処理の第２例について説明する。図２８は、第１実施形態のチケット譲渡の処理の第２例のシーケンス図である。
第１実施形態のチケット譲渡の処理の第２例について説明する。図２８は、第１実施形態のチケット譲渡の処理の第２例のシーケンス図である。
図２８のクライアント端末１０−１のユーザは、チケットオーナ（会員ＩＤ「ＣＵ００１」）である。クライアント端末１０−２のユーザは、非会員ユーザである。
はじめに、クライアント端末１０−１は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０−１は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１は、それぞれ、図２５及び図２６と同様に、会員ホーム画面の表示（Ｓ１２１）及びチケット一覧画面の表示（Ｓ１３０）を実行する。
クライアント端末１０−１は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１は、それぞれ、図２５及び図２６と同様に、会員ホーム画面の表示（Ｓ１２１）及びチケット一覧画面の表示（Ｓ１３０）を実行する。
クライアント端末１０−１は、チケット発行画面の表示（Ｓ１５０）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「発行」ボタンＢ３２０ｅを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１７の画面Ｐ３４０を表示部１４に表示する。
次に、チケットオーナが、入力部１３を用いて、画面Ｐ３４０の入力フィールドＦ３４０に譲受人の氏名、メールアドレス、及び、住所を入力し、かつ、「完了」ボタンＢ３４０を指定すると、ＣＰＵ１２は、チケット発行リクエストをサーバ３０に送信する。チケット発行リクエストは、入力フィールドＦ３４０に入力された情報と、「発行」ボタンＢ３２０ｅに関連付けられたチケットＩＤ「ＴＩ００１」とを含む。
具体的には、チケットオーナが、入力部１３を用いて、図１４の画面Ｐ３２０の「発行」ボタンＢ３２０ｅを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、図１７の画面Ｐ３４０を表示部１４に表示する。
次に、チケットオーナが、入力部１３を用いて、画面Ｐ３４０の入力フィールドＦ３４０に譲受人の氏名、メールアドレス、及び、住所を入力し、かつ、「完了」ボタンＢ３４０を指定すると、ＣＰＵ１２は、チケット発行リクエストをサーバ３０に送信する。チケット発行リクエストは、入力フィールドＦ３４０に入力された情報と、「発行」ボタンＢ３２０ｅに関連付けられたチケットＩＤ「ＴＩ００１」とを含む。
サーバ３０は、紙チケットの発行（Ｓ３５０）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられたトークンと、当該チケットＩＤに関連付けられたプロジェクト名、及び、リワード名とを紙チケットに印刷する。
サーバ３０のオペレータは、チケット発行リクエトに含まれる入力フィールドＦ３４０の情報（譲受人の氏名、及び、住所）宛に、印刷された紙チケットを発送する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられたトークンと、当該チケットＩＤに関連付けられたプロジェクト名、及び、リワード名とを紙チケットに印刷する。
サーバ３０のオペレータは、チケット発行リクエトに含まれる入力フィールドＦ３４０の情報（譲受人の氏名、及び、住所）宛に、印刷された紙チケットを発送する。
サーバ３０は、データベースの更新（Ｓ３５１）を実行する。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられた「受取用トークン」フィールドに新しい受取用トークンを示す情報を格納し、かつ、「トークン期限」フィールドに新しい期限日を示す値を格納する。
次に、ＣＰＵ３２は、チケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ２」を格納する。これにより、チケットのステータスは、利用可能状態から譲渡中状態になる。
具体的には、ＣＰＵ３２は、図８のチケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられた「受取用トークン」フィールドに新しい受取用トークンを示す情報を格納し、かつ、「トークン期限」フィールドに新しい期限日を示す値を格納する。
次に、ＣＰＵ３２は、チケットデータベースにおいて、チケット発行リクエトに含まれるチケットＩＤに関連付けられた「ステータス」フィールドにステータスコード「ＳＴＡ２」を格納する。これにより、チケットのステータスは、利用可能状態から譲渡中状態になる。
クライアント端末１０−２は、チケット受取画面の表示（Ｓ１５２）を実行する。
具体的には、譲受人が、入力部１３を用いて、所定のＵＲＬにアクセスすると、ＣＰＵ１２は、サーバ３０と通信することによって、図１８の画面Ｐ３５０を表示部１４に表示する。
具体的には、譲受人が、入力部１３を用いて、所定のＵＲＬにアクセスすると、ＣＰＵ１２は、サーバ３０と通信することによって、図１８の画面Ｐ３５０を表示部１４に表示する。
クライアント端末１０−２は、チケット受取リクエスト（Ｓ１５３）を実行する。
具体的には、譲受人が、図１８の画面Ｐ３５０の入力フィールドＦ３５０に、紙チケットに印刷された受取用トークン「123456」を入力し、かつ、「会員登録」ボタン３５０ａを指定すると、ＣＰＵ１２は、チケット受取リクエストをサーバ３０に送信する。チケット受取リクエストは、入力フィールドＦ３５０に入力された受取用トークンを含む。
具体的には、譲受人が、図１８の画面Ｐ３５０の入力フィールドＦ３５０に、紙チケットに印刷された受取用トークン「123456」を入力し、かつ、「会員登録」ボタン３５０ａを指定すると、ＣＰＵ１２は、チケット受取リクエストをサーバ３０に送信する。チケット受取リクエストは、入力フィールドＦ３５０に入力された受取用トークンを含む。
クライアント端末１０−２は、図２３と同様に、会員登録画面の表示（Ｓ１０１）、及び、会員登録リクエスト（Ｓ１０２）を実行する。
サーバ３０は、データベースの更新（Ｓ３５２）を実行する。
具体的には、ＣＰＵ３２は、図４の会員データベースに新規レコードを追加する。新規レコードの「会員ＩＤ」フィールドには、新しい会員ＩＤ「ＣＵ９９９」が格納される。新規レコードの「メールアドレス」フィールド、「パスワード」フィールド、「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドには、それぞれ、会員登録リクエストに含まれる情報（氏名、メールアドレス、パスワード、画像、住所、及び、支払情報）が格納される。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたチケット受取リクエストに含まれる受取用トークンに関連付けられたチケットＩＤに関連付けられた「チケットオーナ」フィールドに、会員データベースの新規レコードに含まれる会員ＩＤ「ＣＵ９９９」を格納する。これにより、チケットオーナが譲受人（会員ＩＤ「９９９」）に変わる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、特定したレコードの「ステータス」フィールドに、ステータスコード「ＳＴＡ１」を格納する。これにより、チケットのステータスは、利用可能状態になる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、受取用トークンに関連付けられたチケットＩＤを特定する。
次に、ＣＰＵ３２は、特定したチケットＩＤに関連付けられた譲渡履歴データベース（図１０）に新規レコードを追加する。新規レコードの「登録日」フィールドには、Ｓ３５２の実行日「２０１６／０１／１０」を示す値が格納される。新規レコードの「譲渡人ＩＤ」フィールドには、譲渡人を識別する会員ＩＤ「ＣＵ００１」が格納される。新規レコードの「譲受人ＩＤ」フィールドには、譲受人を識別する会員ＩＤ「ＣＵ９９９」が格納される。これにより、チケットの譲渡履歴が更新される。
具体的には、ＣＰＵ３２は、図４の会員データベースに新規レコードを追加する。新規レコードの「会員ＩＤ」フィールドには、新しい会員ＩＤ「ＣＵ９９９」が格納される。新規レコードの「メールアドレス」フィールド、「パスワード」フィールド、「氏名」フィールド、「画像」フィールド、「住所」フィールド、及び、「支払情報」フィールドには、それぞれ、会員登録リクエストに含まれる情報（氏名、メールアドレス、パスワード、画像、住所、及び、支払情報）が格納される。
次に、ＣＰＵ３２は、図８のチケットデータベースにおいて、クライアント端末１０−２から送信されたチケット受取リクエストに含まれる受取用トークンに関連付けられたチケットＩＤに関連付けられた「チケットオーナ」フィールドに、会員データベースの新規レコードに含まれる会員ＩＤ「ＣＵ９９９」を格納する。これにより、チケットオーナが譲受人（会員ＩＤ「９９９」）に変わる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、特定したレコードの「ステータス」フィールドに、ステータスコード「ＳＴＡ１」を格納する。これにより、チケットのステータスは、利用可能状態になる。
次に、ＣＰＵ３２は、チケットデータベースにおいて、受取用トークンに関連付けられたチケットＩＤを特定する。
次に、ＣＰＵ３２は、特定したチケットＩＤに関連付けられた譲渡履歴データベース（図１０）に新規レコードを追加する。新規レコードの「登録日」フィールドには、Ｓ３５２の実行日「２０１６／０１／１０」を示す値が格納される。新規レコードの「譲渡人ＩＤ」フィールドには、譲渡人を識別する会員ＩＤ「ＣＵ００１」が格納される。新規レコードの「譲受人ＩＤ」フィールドには、譲受人を識別する会員ＩＤ「ＣＵ９９９」が格納される。これにより、チケットの譲渡履歴が更新される。
このように、サーバ３０は、チケット発行リクエスト（Ｓ１５１）が行われてからチケット受取リクエスト（Ｓ１５３）及び会員登録リクエスト（Ｓ１０２）が行われるまでの間、譲渡されるチケットを利用できないようにする。
また、サーバ３０は、チケット譲渡の処理を実行する毎に、チケットの譲渡履歴を更新する。
また、サーバ３０は、チケット譲渡の処理を実行する毎に、チケットの譲渡履歴を更新する。
以上の処理により、チケット譲渡の処理が終了する。
（１−６−７）プロジェクト編集の処理のフロー（図２９）
第１実施形態のプロジェクト編集の処理について説明する。図２９は、第１実施形態のプロジェクト編集の処理のシーケンス図である。
第１実施形態のプロジェクト編集の処理について説明する。図２９は、第１実施形態のプロジェクト編集の処理のシーケンス図である。
図２９のクライアント端末１０のユーザは、プロジェクトオーナ（会員ＩＤ「ＣＵ００１」）である。
はじめに、クライアント端末１０は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０は、図２６と同様に、ログインリクエスト（Ｓ１３３）を実行する。
サーバ３０は、図２６と同様に、ログインリクエスト（Ｓ１３３）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０は、図２６と同様に、プロジェクトオーナホーム画面の表示（Ｓ１３４）を実行する。
クライアント端末１０は、図２６と同様に、ログインリクエスト（Ｓ１３３）を実行する。
サーバ３０は、図２６と同様に、ログインリクエスト（Ｓ１３３）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０は、図２６と同様に、プロジェクトオーナホーム画面の表示（Ｓ１３４）を実行する。
クライアント端末１０は、プロジェクト管理画面の表示（Ｓ１６０）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１０の「プロジェクト管理」ボタンＢ４１０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ４１１を表示部１４に表示する。画面Ｐ４１１には、選択可能なプロジェクトに関するプロジェクト情報（例えば、図５のプロジェクトデータベースにおいて、ログインリクエストに含まれるプロジェクトオーナＩＤに関連付けられた「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、及び、「画像」フィールドの情報）が表示される。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１０の「プロジェクト管理」ボタンＢ４１０ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ４１１を表示部１４に表示する。画面Ｐ４１１には、選択可能なプロジェクトに関するプロジェクト情報（例えば、図５のプロジェクトデータベースにおいて、ログインリクエストに含まれるプロジェクトオーナＩＤに関連付けられた「プロジェクト名」フィールド、「目標金額」フィールド、「概要」フィールド、及び、「画像」フィールドの情報）が表示される。
クライアント端末１０は、プロジェクト編集画面の表示（Ｓ１６１）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１１の「編集」ボタンＢ４１１ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ４１２を表示部１４に表示する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１１の「編集」ボタンＢ４１１ａを指定すると、ＣＰＵ１２は、サーバ３０と通信することによって、画面Ｐ４１２を表示部１４に表示する。
クライアント端末１０は、プロジェクト編集リクエスト（Ｓ１６２）を実行する。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１２の入力フィールド（不図示）に所定の情報を入力し、かつ、「完了」ボタン（不図示）を指定すると、ＣＰＵ１２は、プロジェクト編集リクエストをサーバ３０に送信する。プロジェクト編集リクエストは、「編集」ボタンＢ４１１ａに関連付けられたプロジェクトＩＤと、画面Ｐ４１２の入力フィールドに入力された情報とを含む。
具体的には、プロジェクトオーナが、入力部１３を用いて、図１９の画面Ｐ４１２の入力フィールド（不図示）に所定の情報を入力し、かつ、「完了」ボタン（不図示）を指定すると、ＣＰＵ１２は、プロジェクト編集リクエストをサーバ３０に送信する。プロジェクト編集リクエストは、「編集」ボタンＢ４１１ａに関連付けられたプロジェクトＩＤと、画面Ｐ４１２の入力フィールドに入力された情報とを含む。
サーバ３０は、プロジェクトの審査（Ｓ３６０）を実行する。
具体的には、ＣＰＵ３２は、記憶装置３１に記憶された要件情報に基づいて、プロジェクト編集リクエストに含まれる情報がプロジェクト要件を満たすか否かを審査する。
「要件情報」とは、プロジェクトとして登録するための要件を示す情報である。
なお、プロジェクト編集リクエストに含まれる情報の一部がプロジェクト要件を満たすか否かを、サーバ３０のオペレータが審査してもよい。この場合、ＣＰＵ３２が、プロジェクト編集リクエストに含まれる情報の一部について審査を行い、オペレータが、残りの部分について審査を行う。
具体的には、ＣＰＵ３２は、記憶装置３１に記憶された要件情報に基づいて、プロジェクト編集リクエストに含まれる情報がプロジェクト要件を満たすか否かを審査する。
「要件情報」とは、プロジェクトとして登録するための要件を示す情報である。
なお、プロジェクト編集リクエストに含まれる情報の一部がプロジェクト要件を満たすか否かを、サーバ３０のオペレータが審査してもよい。この場合、ＣＰＵ３２が、プロジェクト編集リクエストに含まれる情報の一部について審査を行い、オペレータが、残りの部分について審査を行う。
サーバ３０は、データベースの更新（Ｓ３６１）を実行する。
具体的には、プロジェクト編集リクエストに含まれる情報がプロジェクト要件を満たす場合、ＣＰＵ３２は、図５のプロジェクトデータベースにおいて、プロジェクト編集リクエストに含まれる情報に基づいて、プロジェクト編集リクエストに含まれるプロジェクトＩＤに関連付けられたレコードを更新する。
具体的には、プロジェクト編集リクエストに含まれる情報がプロジェクト要件を満たす場合、ＣＰＵ３２は、図５のプロジェクトデータベースにおいて、プロジェクト編集リクエストに含まれる情報に基づいて、プロジェクト編集リクエストに含まれるプロジェクトＩＤに関連付けられたレコードを更新する。
以上の処理により、プロジェクト編集の処理が終了する。
（１−６−８）返金の処理のフロー（図３０）
第１実施形態の返金の処理について説明する。図３０は、第１実施形態の返金の処理のシーケンス図である。
第１実施形態の返金の処理について説明する。図３０は、第１実施形態の返金の処理のシーケンス図である。
図３０のクライアント端末１０のユーザは、チケットオーナ（会員ＩＤ「ＣＵ００１」）である。
はじめに、サーバ３０は、プロジェクトの返金条件の判定（Ｓ３７０）を実行する。
具体的には、ＣＰＵ３２は、一定期間毎に、図５のレコードのうち、「タイプ」フィールドにタイプコード「ＡＮ」が格納されたレコードについて、返金条件が成立したか否かを判定する。返金条件は、例えば、「終了日」フィールドに格納された値が示す終了日前に、支援金額の合計が「目標金額」フィールドの値に到達しなかった場合に成立する。
具体的には、ＣＰＵ３２は、一定期間毎に、図５のレコードのうち、「タイプ」フィールドにタイプコード「ＡＮ」が格納されたレコードについて、返金条件が成立したか否かを判定する。返金条件は、例えば、「終了日」フィールドに格納された値が示す終了日前に、支援金額の合計が「目標金額」フィールドの値に到達しなかった場合に成立する。
返金条件が成立した場合（Ｓ３７１：ＹＥＳ）、サーバ３０は、返金通知（Ｓ３７２）を実行する。
具体的には、ＣＰＵ３２は、返金条件が成立したプロジェクトを識別するプロジェクトＩＤに関連付けられたリワードデータベース（図８）を特定する。
次に、ＣＰＵ３２は、図４の会員データベースを参照して、特定したリワードデータベースの「チケットオーナＩＤ」フィールドに格納された会員ＩＤに関連付けられたレコードを特定する。
次に、ＣＰＵ３２は、特定したレコードの「メールアドレス」フィールドに格納されたメールアドレス宛にメールを送信する。このメールには、返金リクエストを実行するためのウェブページのＵＲＬが示される。
具体的には、ＣＰＵ３２は、返金条件が成立したプロジェクトを識別するプロジェクトＩＤに関連付けられたリワードデータベース（図８）を特定する。
次に、ＣＰＵ３２は、図４の会員データベースを参照して、特定したリワードデータベースの「チケットオーナＩＤ」フィールドに格納された会員ＩＤに関連付けられたレコードを特定する。
次に、ＣＰＵ３２は、特定したレコードの「メールアドレス」フィールドに格納されたメールアドレス宛にメールを送信する。このメールには、返金リクエストを実行するためのウェブページのＵＲＬが示される。
クライアント端末１０は、ログインリクエスト（Ｓ１７０）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、Ｓ３７２において送信されたメールに示されたＵＲＬを指定すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、Ｓ３７２において特定されたリワードデータベースの「チケットオーナＩＤ」フィールドに格納された会員ＩＤを含む。
具体的には、チケットオーナが、入力部１３を用いて、Ｓ３７２において送信されたメールに示されたＵＲＬを指定すると、ＣＰＵ１２は、ログインリクエストをサーバ３０に送信する。ログインリクエストは、Ｓ３７２において特定されたリワードデータベースの「チケットオーナＩＤ」フィールドに格納された会員ＩＤを含む。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０は、返金画面の表示（Ｓ１７１）を実行する。
具体的には、ＣＰＵ１２は、サーバ３０と通信を行うことによって、返金リクエストを実行するためのウェブページを表示部１４に表示する。
具体的には、ＣＰＵ１２は、サーバ３０と通信を行うことによって、返金リクエストを実行するためのウェブページを表示部１４に表示する。
クライアント端末１０は、返金リクエスト（Ｓ１７２）を実行する。
具体的には、チケットオーナが、入力部１３を用いて、返金画面において返金先の口座情報（例えば、銀行名、支店名、口座番号、及び、口座名義人を示す情報）を入力すると、ＣＰＵ１２は、返金リクエストをサーバ３０に送信する。返金リクエストは、返金口座情報と、ログインリクエストに含まれる会員ＩＤとを含む。
具体的には、チケットオーナが、入力部１３を用いて、返金画面において返金先の口座情報（例えば、銀行名、支店名、口座番号、及び、口座名義人を示す情報）を入力すると、ＣＰＵ１２は、返金リクエストをサーバ３０に送信する。返金リクエストは、返金口座情報と、ログインリクエストに含まれる会員ＩＤとを含む。
サーバ３０は、返金（Ｓ３７３）を実行する。
具体的には、ＣＰＵ３２は、返金リクエストに含まれる返金口座情報に対応する口座に支援金額を振り込む。
具体的には、ＣＰＵ３２は、返金リクエストに含まれる返金口座情報に対応する口座に支援金額を振り込む。
サーバ３０は、データベースの更新（Ｓ３７４）を実行する。
具体的には、ＣＰＵ３２は、図５のプロジェクトデータベースにおいて、返金条件が成立したプロジェクトを識別するプロジェクトＩＤに関連付けられた「タイプ」フィールドに、終了したプロジェクトであることを示すタイプコード「ＦＩＮ」を格納する。
具体的には、ＣＰＵ３２は、図５のプロジェクトデータベースにおいて、返金条件が成立したプロジェクトを識別するプロジェクトＩＤに関連付けられた「タイプ」フィールドに、終了したプロジェクトであることを示すタイプコード「ＦＩＮ」を格納する。
以上の処理により、返金の処理が終了する。
（１−７）小括
第１実施形態について小括する。
第１実施形態について小括する。
ＣＰＵ３２（情報処理装置の一例）は、クラウドファンディングの会員を識別する会員ＩＤ（ユーザ識別情報の一例）と、クラウドファンディングのプロジェクトを識別するプロジェクトＩＤ（プロジェクト識別情報の一例）とを記憶する記憶装置３１にアクセス可能である。
ＣＰＵ３２は、チケットオーナ（第１ユーザの一例）の指示に応じて、チケットオーナを識別する会員ＩＤ（第１ユーザ識別情報の一例）と、プロジェクトＩＤとに、プロジェクトへの支援金額を示す情報を関連付けて記憶する（例えば、Ｓ３２２の処理）。
また、ＣＰＵ３２は、チケットオーナを識別する会員ＩＤに、プロジェクトへの支援に対するチケットＩＤ（チケット識別情報の一例）を関連付けて記憶する（例えば、Ｓ３２２の処理）。
チケットオーナからの指示に応じて、チケットオーナを識別する会員ＩＤとチケットＩＤとの関連付けを解除し、かつ、チケットオーナによって指定された会員ユーザを識別する会員ＩＤ（第２ユーザ識別情報の一例）にチケットＩＤを関連付けて記憶する（例えば、Ｓ１４１〜Ｓ３４１の処理）。
ＣＰＵ３２は、チケットオーナ（第１ユーザの一例）の指示に応じて、チケットオーナを識別する会員ＩＤ（第１ユーザ識別情報の一例）と、プロジェクトＩＤとに、プロジェクトへの支援金額を示す情報を関連付けて記憶する（例えば、Ｓ３２２の処理）。
また、ＣＰＵ３２は、チケットオーナを識別する会員ＩＤに、プロジェクトへの支援に対するチケットＩＤ（チケット識別情報の一例）を関連付けて記憶する（例えば、Ｓ３２２の処理）。
チケットオーナからの指示に応じて、チケットオーナを識別する会員ＩＤとチケットＩＤとの関連付けを解除し、かつ、チケットオーナによって指定された会員ユーザを識別する会員ＩＤ（第２ユーザ識別情報の一例）にチケットＩＤを関連付けて記憶する（例えば、Ｓ１４１〜Ｓ３４１の処理）。
これにより、プロジェクトに支援した会員は、報酬を受け取る権利を他の会員に譲渡することができる。
したがって、プロジェクトに支援した会員は、他の会員に譲渡する際に金銭取引を行うことによって、支援金額を回収することができる。
また、他の会員は、プロジェクトの支援の受け付けが終了した後も、当該プロジェクトの報酬を受け取る権利を確保することができる。
つまり、本実施形態によれば、クラウドファンディングにおいて、プロジェクトの報酬を受け取る権利のｎ（ｎは２以上の整数）次流通を実現することができる。その結果、クラウドファンディングの利便性が高くなるので、クラウドファンディングの普及が促進される。
したがって、プロジェクトに支援した会員は、他の会員に譲渡する際に金銭取引を行うことによって、支援金額を回収することができる。
また、他の会員は、プロジェクトの支援の受け付けが終了した後も、当該プロジェクトの報酬を受け取る権利を確保することができる。
つまり、本実施形態によれば、クラウドファンディングにおいて、プロジェクトの報酬を受け取る権利のｎ（ｎは２以上の整数）次流通を実現することができる。その結果、クラウドファンディングの利便性が高くなるので、クラウドファンディングの普及が促進される。
さらに、ＣＰＵ３２は、チケットを譲り受けた会員（第２ユーザの一例）の指示に応じて、チケットを譲り受けた会員を識別する会員ＩＤ（第２ユーザ識別情報の一例）とチケットＩＤとの関連付けを解除し、かつ、チケットを譲り受けた会員によって指定された譲受人（第３ユーザの一例）を識別する会員ＩＤ（第３ユーザ識別情報の一例）にチケットＩＤを関連付けて記憶する（例えば、Ｓ１４１〜Ｓ１４２の処理）。
さらに、ＣＰＵ３２は、チケット譲渡の処理を実行する度に、チケットＩＤに、譲渡人を識別する会員ＩＤ（指示を与えたユーザを識別するユーザ識別情報の一例）と、譲受人を識別する会員ＩＤ（指示を与えたユーザによって指定されたユーザを識別するユーザ識別情報の一例）との組合せを関連付けて記憶する（例えば、Ｓ３４１の処理）。
これにより、チケットの流通経路を容易に知ることができる。
チケットの流通経路は、プロジェクトオーナにとって、プロジェクトに有益な事項（例えば、プロジェクトに対する関心の大きさ、プロジェクトに関心を持っているユーザの傾向等）を特定する上で有益な情報である。
チケットの流通経路は、プロジェクトオーナにとって、プロジェクトに有益な事項（例えば、プロジェクトに対する関心の大きさ、プロジェクトに関心を持っているユーザの傾向等）を特定する上で有益な情報である。
さらに、ＣＰＵ３２は、チケットオーナの指示に応じて、譲受人（チケットオーナ以外のユーザの一例）がチケットを譲り受けるために必要な受取用トークン（譲渡情報の一例）が印刷された紙チケットを発行する（例えば、Ｓ３５０の処理）。
これにより、チケットの流通形態を多様化することができる。
例えば、チケットオーナは、紙チケットをイーコマースや金券を取り扱う小売店を介して、クラウドファンディングサービスの非会員ユーザに売却することができる。
また、紙チケットを受け取った非会員ユーザをクラウドファンディングサービスへの会員登録に誘導することによって、クラウドファンディングサービスの会員数を増やすことができる。
例えば、チケットオーナは、紙チケットをイーコマースや金券を取り扱う小売店を介して、クラウドファンディングサービスの非会員ユーザに売却することができる。
また、紙チケットを受け取った非会員ユーザをクラウドファンディングサービスへの会員登録に誘導することによって、クラウドファンディングサービスの会員数を増やすことができる。
さらに、ＣＰＵ３２は、紙チケットを受け取ったユーザ（チケットオーナ以外のユーザの一例）によって、紙チケットに印刷された受取用トークンが入力された場合、チケットオーナを識別する会員ＩＤとチケットＩＤとの関連付けを解除し、かつ、受取用トークンを入力した会員を識別する会員識別情報にチケットＩＤを関連付けて記憶する（例えば、Ｓ１５２〜Ｓ３５２の処理）。
さらに、ＣＰＵ３２は、チケットオーナを識別する会員ＩＤとチケットＩＤとの対応付けを解除してから、受取用トークンを入力した会員を識別する会員ＩＤにチケットＩＤを関連付けて記憶するまでの間（例えば、Ｓ３５０〜Ｓ３５２の間）、チケットを利用できない状態にする（例えば、Ｓ３５１の処理）。
これにより、紙チケットを発行してから譲受人がチケットオーナになるまでの間のチケットの不正利用を防ぐことができる。
（２）第２実施形態
第２実施形態について説明する。第２実施形態は、ライブファンディングの例である。
ライブファンディングとは、ライブファンディング会場内にいる会員ユーザが、ライブファンディング会場内で行われるプロジェクトオーナのプレゼンテーションを見て、プロジェクトへの投票、又は、リワードの予約を行う形式のクラウドファンディングである。
第２実施形態について説明する。第２実施形態は、ライブファンディングの例である。
ライブファンディングとは、ライブファンディング会場内にいる会員ユーザが、ライブファンディング会場内で行われるプロジェクトオーナのプレゼンテーションを見て、プロジェクトへの投票、又は、リワードの予約を行う形式のクラウドファンディングである。
（２−１）情報処理システムの構成（図３１）
第２実施形態の情報処理システムの構成について説明する。図３１は、第２実施形態の情報処理システムのシステム構成図である。
第２実施形態の情報処理システムの構成について説明する。図３１は、第２実施形態の情報処理システムのシステム構成図である。
図３１に示すように、ライブファンディング会場内には、複数のクライアント端末１０−１〜１０−４と、サーバ３０と、ホスト端末５０とが設けられる。クライアント端末１０−１〜１０−３は、それぞれ、ライブファンディング会場内にいる会員（会員ＩＤ「ＣＵ００１」〜「ＣＵ００３」）が使用する。クライアント端末１０−４は、ライブファンディング会場内にいるプロジェクトオーナ（プロジェクトオーナＩＤ「ＰＯ００１」）が使用する。
ライブファンディング会場外には、クライアント端末１０−５が設けられる。クライアント端末１０−５は、ライブファンディング会場外にいる会員（会員ＩＤ「ＣＵ０１０」）が使用する。
各クライアント端末１０−１〜１０−５、及び、ホスト端末５０は、通信網ＮＷを介して、サーバ３０に接続されている。
ライブファンディング会場外には、クライアント端末１０−５が設けられる。クライアント端末１０−５は、ライブファンディング会場外にいる会員（会員ＩＤ「ＣＵ０１０」）が使用する。
各クライアント端末１０−１〜１０−５、及び、ホスト端末５０は、通信網ＮＷを介して、サーバ３０に接続されている。
プロジェクトオーナ（プロジェクトオーナＩＤ「ＰＯ００１」）は、ライブファンディング会場内で、プロジェクトに関するプレゼンテーションを実施する。プレゼンテーション資料は、ライブ会場内のスクリーンＳＣに表示される。
ライブファンディング会場内にいる会員（会員ＩＤ「ＣＵ００１」〜「ＣＵ００３」）は、それぞれ、クライアント端末１０−１〜１０−３の入力部１３を用いて指示を与えることによって、プロジェクト情報がアップロードされたＷｅｂサイト（例えば、サーバ３０が提供するＷｅｂサイト）にアクセスする。これにより、ライブファンディング会場内にいる会員（会員ＩＤ「ＣＵ００１」〜「ＣＵ００３」）は、各人のクライアント端末１０−１〜１０−３で、プロジェクト情報を見ることができる。ライブファンディング会場内にいる会員（会員ＩＤ「ＣＵ００１」〜「ＣＵ００３」）は、プロジェクトオーナ（プロジェクトオーナＩＤ「ＰＯ００１」）のプレゼンテーションと、表示部１４に表示されたプロジェクト情報を見ながら、プロジェクトを支援するか否かを検討する。
ライブファンディング会場には、ビデオカメラＶＣが設けられている。ビデオカメラＶＣは、ライブファンディング会場の様子（例えば、プレゼンテーション及びスクリーンＳＣの様子）を撮影しながら、動画データを生成する。
ホスト端末５０の構成は、クライアント端末１０の構成（図２）と同様である。
ホスト端末５０は、ビデオカメラＶＣに接続されている。ホスト端末５０は、ビデオカメラＶＣが生成した動画データを、動画配信サイトのＷｅｂサーバ（不図示）に順次アップロードする。
ホスト端末５０は、ビデオカメラＶＣに接続されている。ホスト端末５０は、ビデオカメラＶＣが生成した動画データを、動画配信サイトのＷｅｂサーバ（不図示）に順次アップロードする。
ライブファンディング会場外にいる会員（会員ＩＤ「ＣＵ０１０」）は、クライアント端末１０−４の入力部１３を用いて指示を与えることによって、動画配信サイトと、プロジェクト情報がアップロードされたＷｅｂサイトとにアクセスする。これにより、ライブファンディング会場外にいる会員（会員ＩＤ「ＣＵ０１０」）は、ライブファンディング会場外から、ライブファンディング会場の様子と、プロジェクト情報とを見ることができる。
（２−１）データベースのデータ構造（図３２〜図３３）
第２実施形態のデータベースのデータ構造について説明する。
第２実施形態のデータベースのデータ構造について説明する。
（２−１−１）投票データベース（図３２）
第２実施形態の投票データベースのデータ構造について説明する。図３２は、第２実施形態の投票データベースのデータ構造の一例を示す図である。
第２実施形態の投票データベースのデータ構造について説明する。図３２は、第２実施形態の投票データベースのデータ構造の一例を示す図である。
投票データベースの各レコードには、プロジェクトへの投票に関する情報（以下「投票情報」という）が格納される。
１つのプロジェクトＩＤには、投票データベースの複数のレコードを関連付けることができる。
１つのプロジェクトＩＤには、投票データベースの複数のレコードを関連付けることができる。
図３２に示すように、投票データベースは、「投票ＩＤ」フィールドと、「会員ＩＤ」フィールドと、「投票日時」フィールドとを含む。
「投票ＩＤ」フィールドには、投票ＩＤが格納される。投票ＩＤは、投票毎に固有の情報である。つまり、投票ＩＤは、プロジェクトへの投票を識別する情報である。投票ＩＤは、投票データベースの各レコードの主キーである。投票ＩＤは、サーバ３０が決定する情報である。
「会員ＩＤ」フィールドには、投票を行った会員の会員ＩＤが格納される。
「投票日時」フィールドには、投票が行われた日時を示す値が格納される。
「会員ＩＤ」フィールド及び「投票日時」フィールドの情報は、サーバ３０が決定する情報である。
「投票日時」フィールドには、投票が行われた日時を示す値が格納される。
「会員ＩＤ」フィールド及び「投票日時」フィールドの情報は、サーバ３０が決定する情報である。
（２−１−２）予約データベース（図３３）
第２実施形態の予約データベースのデータ構造について説明する。図３３は、第２実施形態の予約データベースのデータ構造の一例を示す図である。
第２実施形態の予約データベースのデータ構造について説明する。図３３は、第２実施形態の予約データベースのデータ構造の一例を示す図である。
予約データベースの各レコードには、リワードの予約に関する情報（以下「予約情報」という）が格納される。
１つのリワードＩＤには、予約データベースの複数のレコードを関連付けることができる。
１つのリワードＩＤには、予約データベースの複数のレコードを関連付けることができる。
図３３に示すように、予約データベースは、「予約ＩＤ」フィールドと、「会員ＩＤ」フィールドと、「予約日時」フィールドとを含む。
「予約ＩＤ」フィールドには、予約ＩＤが格納される。予約ＩＤは、予約毎に固有の情報である。つまり、予約ＩＤは、予約を識別する情報である。予約ＩＤは、予約データベースの各レコードの主キーである。予約ＩＤは、サーバ３０が決定する情報である。
「会員ＩＤ」フィールドには、予約を行った会員の会員ＩＤが格納される。
「予約日時」フィールドには、予約日時を示す値が格納される。
「会員ＩＤ」フィールド及び「予約日時」フィールドの情報は、サーバ３０が決定する情報である。
「予約日時」フィールドには、予約日時を示す値が格納される。
「会員ＩＤ」フィールド及び「予約日時」フィールドの情報は、サーバ３０が決定する情報である。
（２−２）情報処理において表示される画面（図３４〜図３６）
第２実施形態の情報処理において表示される画面について説明する。図３４〜図３６は、第２実施形態の情報処理において表示される画面の例を示す図である。
図３４〜図３６の画面は、クライアント端末１０の表示部１４又はライブファンディング会場内のスクリーンＳＣに表示される。表示部１４に表示される各画面では、ユーザは、入力部１３を用いて指示（入力フィールドへの入力、及び、ボタンの指定）を与えることができる。与えられた指示は、クライアント端末１０からサーバ３０に送信される。
第２実施形態の情報処理において表示される画面について説明する。図３４〜図３６は、第２実施形態の情報処理において表示される画面の例を示す図である。
図３４〜図３６の画面は、クライアント端末１０の表示部１４又はライブファンディング会場内のスクリーンＳＣに表示される。表示部１４に表示される各画面では、ユーザは、入力部１３を用いて指示（入力フィールドへの入力、及び、ボタンの指定）を与えることができる。与えられた指示は、クライアント端末１０からサーバ３０に送信される。
図３４の画面Ｐ１５００は、スクリーン画面である。
画面Ｐ１５００は、領域Ａ１５００ａ〜Ａ１５００ｂを含む。
画面Ｐ１５００は、領域Ａ１５００ａ〜Ａ１５００ｂを含む。
領域Ａ１５００ａには、プロジェクトオーナのプレゼンテーション資料が表示される。
領域Ａ１５００ｂには、プロジェクトに対する投票数（つまり、プロジェクトに投票した会員ユーザの数）が表示される。
領域Ａ１５００ｂには、プロジェクトに対する投票数（つまり、プロジェクトに投票した会員ユーザの数）が表示される。
画面Ｐ１５０１は、画面Ｐ１５００が更新された後のスクリーン画面である。
画面Ｐ１５０１は、領域Ａ１５００ａ〜Ａ１５００ｂに加えて、領域Ａ１５０１を含む。
画面Ｐ１５０１は、領域Ａ１５００ａ〜Ａ１５００ｂに加えて、領域Ａ１５０１を含む。
領域Ａ１５０１には、プロジェクトを構成するリワードに対する予約数（つまり、リワードを予約した会員ユーザの数）が表示される。
図３５の画面Ｐ１１００は、会員ホーム画面である。
画面Ｐ１１００は、「ライブ」ボタンＢ１１００を含む点において、第１実施形態の画面Ｐ３１０（図１３）と異なる。
画面Ｐ１１００は、「ライブ」ボタンＢ１１００を含む点において、第１実施形態の画面Ｐ３１０（図１３）と異なる。
画面Ｐ１１００において「ライブ」ボタンＢ１１００が指定されると、画面Ｐ１１０１が表示される。画面Ｐ１１０１は、ライブメニュー画面である。
画面Ｐ１１０１は、領域Ａ１１０１と、「選択」ボタンＢ１１０１ａ〜Ｂ１１０１ｂとを含む。
画面Ｐ１１０１は、領域Ａ１１０１と、「選択」ボタンＢ１１０１ａ〜Ｂ１１０１ｂとを含む。
領域Ａ１１０１には、ライブファンディングにエントリーされたプロジェクトに関するプロジェクト情報（例えば、プロジェクト名、プロジェクトオーナ名、及び、プロジェクト説明）が表示される。
「選択」ボタンＢ１１０１ａ〜Ｂ１１０１ｂは、ライブファンディングにエントリーされたプロジェクトのプロジェクトＩＤに関連付けられている。
「選択」ボタンＢ１１０１ａ〜Ｂ１１０１ｂは、ライブファンディングにエントリーされたプロジェクトのプロジェクトＩＤに関連付けられている。
「選択」ボタンＢ１１０１ａが指定されると、図３６の画面Ｐ１１０２が表示される。画面Ｐ１１０２は、ライブプロジェクト画面である。
画面Ｐ１１０２は、領域Ａ１１０２ａ〜Ａ１１０２ｃと、「投票」ボタンＢ１１０２ａと、「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃとを含む。
画面Ｐ１１０２は、領域Ａ１１０２ａ〜Ａ１１０２ｃと、「投票」ボタンＢ１１０２ａと、「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃとを含む。
領域Ａ１１０２ａには、プロジェクト情報（例えば、プロジェクト名、及び、プロジェクトオーナ名）が表示される。
領域Ａ１１０２ｂ〜Ａ１１０２ｃには、それぞれ、プロジェクトに含まれるリワードに関するリワード情報（例えば、リワード名、チケット金額、及び、リワードの説明）が表示される。
「投票」ボタンＢ１１０２ａは、プロジェクトＩＤに関連付けられている。
「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃは、リワードＩＤに関連付けられている。
領域Ａ１１０２ｂ〜Ａ１１０２ｃには、それぞれ、プロジェクトに含まれるリワードに関するリワード情報（例えば、リワード名、チケット金額、及び、リワードの説明）が表示される。
「投票」ボタンＢ１１０２ａは、プロジェクトＩＤに関連付けられている。
「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃは、リワードＩＤに関連付けられている。
「投票」ボタンＢ１１０２ａが指定されると、指定された「投票」ボタンＢ１１０２ａに関連付けられたプロジェクトＩＤによって識別されるプロジェクトへの投票が行われる。
「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃが指定されると、指定された「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃに関連付けられたリワードＩＤによって識別されるリワードが予約される。
「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃが指定されると、指定された「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃに関連付けられたリワードＩＤによって識別されるリワードが予約される。
（２−３）情報処理のフロー（図３７）
第２実施形態の情報処理のフローについて説明する。以下の情報処理は、図２のＣＰＵ１２が記憶装置１１に記憶されたアプリケーション（例えば、ブラウザ）のプログラムを実行し、かつ、図３のＣＰＵ３２が記憶装置３１に記憶されたプログラムを実行することによって、実現される。
クライアント端末１０と、サーバ３０と、ホスト端末５０とは、通信網ＮＷを介して、ｈｔｔｐｓ通信を行うことによって以下の情報処理を実現する。
第２実施形態の情報処理のフローについて説明する。以下の情報処理は、図２のＣＰＵ１２が記憶装置１１に記憶されたアプリケーション（例えば、ブラウザ）のプログラムを実行し、かつ、図３のＣＰＵ３２が記憶装置３１に記憶されたプログラムを実行することによって、実現される。
クライアント端末１０と、サーバ３０と、ホスト端末５０とは、通信網ＮＷを介して、ｈｔｔｐｓ通信を行うことによって以下の情報処理を実現する。
（２−３−１）ライブファンディングの処理のフロー（図３７）
第２実施形態のライブファンディングの処理について説明する。図３７は、第２実施形態のライブファンディングの処理のシーケンス図である。
第２実施形態のライブファンディングの処理について説明する。図３７は、第２実施形態のライブファンディングの処理のシーケンス図である。
図３７のクライアント端末１０−１のユーザは、ライブファンディング会場内にいる会員ユーザ（会員ＩＤ「ＣＵ００１」）である。
はじめに、ホスト端末５０は、動画データのアップロード（Ｓ１５００）を実行する。
具体的には、ホスト端末５０のＣＰＵ１２は、ビデオカメラＶＣによって生成された動画データをサーバ３０に送信する。
動画データのアップロード（Ｓ１５００）の実行は、プレゼンテーションが終了するまで継続する。
具体的には、ホスト端末５０のＣＰＵ１２は、ビデオカメラＶＣによって生成された動画データをサーバ３０に送信する。
動画データのアップロード（Ｓ１５００）の実行は、プレゼンテーションが終了するまで継続する。
ホスト端末５０は、スクリーン画面の表示（Ｓ１５０１）を実行する。
具体的には、ホスト端末５０のＣＰＵ１２は、図３４の画面Ｐ１５００をスクリーンＳＣに表示する。
具体的には、ホスト端末５０のＣＰＵ１２は、図３４の画面Ｐ１５００をスクリーンＳＣに表示する。
一方、クライアント端末１０−１は、図２３と同様に、トップ画面の表示（Ｓ１００）を実行する。
クライアント端末１０−１は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１は、図２５と同様に、会員ホーム画面の表示（Ｓ１２１）を実行する。但し、第２実施形態では、図３５の画面Ｐ１１００が表示部１４に表示される。
クライアント端末１０−１は、図２５と同様に、ログインリクエスト（Ｓ１２０）を実行する。
サーバ３０は、図２５と同様に、ログインリクエスト（Ｓ１２０）に対するログイン認証（Ｓ３２０）を実行する。
クライアント端末１０−１は、図２５と同様に、会員ホーム画面の表示（Ｓ１２１）を実行する。但し、第２実施形態では、図３５の画面Ｐ１１００が表示部１４に表示される。
クライアント端末１０−１は、ライブメニュー画面の表示（Ｓ１１００）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図３５の画面Ｐ１１００の「ライブ」ボタンＢ１１００を指定すると、ＣＰＵ１２は、サーバ３０と通信を行うことによって、画面Ｐ１１０１を表示部１４に表示する。
具体的には、会員ユーザが、入力部１３を用いて、図３５の画面Ｐ１１００の「ライブ」ボタンＢ１１００を指定すると、ＣＰＵ１２は、サーバ３０と通信を行うことによって、画面Ｐ１１０１を表示部１４に表示する。
クライアント端末１０−１は、ライブプロジェクト画面の表示（Ｓ１１０１）を実行する。
具体的には、会員ユーザが、入力部１３を用いて、図３５の画面Ｐ１１０１の「選択」ボタンＢ１１０１ａを指定すると、ＣＰＵ１２は、サーバ３０と通信を行うことによって、図３６の画面Ｐ１１０２を表示部１４に表示する。
具体的には、会員ユーザが、入力部１３を用いて、図３５の画面Ｐ１１０１の「選択」ボタンＢ１１０１ａを指定すると、ＣＰＵ１２は、サーバ３０と通信を行うことによって、図３６の画面Ｐ１１０２を表示部１４に表示する。
クライアント端末１０−１は、ライブリクエスト（Ｓ１１０２）を実行する。
例えば、会員ユーザが、入力部１３を用いて、図３６の画面Ｐ１１０２の「投票」ボタンＢ１１０２ａを指定すると、ＣＰＵ１２は、投票リクエスト（ライブリクエストの一例）をサーバ３０に送信する。投票リクエストは、会員ＩＤ「ＣＵ００１」と、指定された「投票」ボタンＢ１１０２ａに関連付けられたプロジェクトＩＤ「ＰＲ００１」とを含む。
例えば、会員ユーザが、入力部１３を用いて、画面Ｐ１１０２の「欲しい」ボタンＢ１１０２ｂを指定すると、ＣＰＵ１２は、予約リクエスト（ライブリクエストの一例）をサーバ３０に送信する。予約リクエストは、会員ＩＤ「ＣＵ００１」と、指定された「欲しい」ボタンＢ１１０２ｂに関連付けられたリワードＩＤ「ＲＥ００１」とを含む。
例えば、会員ユーザが、入力部１３を用いて、図３６の画面Ｐ１１０２の「投票」ボタンＢ１１０２ａを指定すると、ＣＰＵ１２は、投票リクエスト（ライブリクエストの一例）をサーバ３０に送信する。投票リクエストは、会員ＩＤ「ＣＵ００１」と、指定された「投票」ボタンＢ１１０２ａに関連付けられたプロジェクトＩＤ「ＰＲ００１」とを含む。
例えば、会員ユーザが、入力部１３を用いて、画面Ｐ１１０２の「欲しい」ボタンＢ１１０２ｂを指定すると、ＣＰＵ１２は、予約リクエスト（ライブリクエストの一例）をサーバ３０に送信する。予約リクエストは、会員ＩＤ「ＣＵ００１」と、指定された「欲しい」ボタンＢ１１０２ｂに関連付けられたリワードＩＤ「ＲＥ００１」とを含む。
サーバ３０は、データベースの更新（Ｓ１３００）を実行する。
一例として、ライブリクエストが投票リクエストである場合、ＣＰＵ３２は、投票リクエストに含まれるプロジェクトＩＤ「ＰＲ００１」に関連付けられた図３２の投票データベースに新規レコードを追加する。新規レコードの「投票ＩＤ」フィールドには、新しい投票ＩＤが格納される。新規レコードの「会員ＩＤ」フィールドには、投票リクエストに含まれる会員ＩＤ「ＣＵ００１」が格納される。「投票日時」フィールドには、投票リクエストをサーバ３０が受信した日時を示す値が格納される。
一例として、ライブリクエストが予約リクエストである場合、ＣＰＵ３２は、予約リクエストに含まれるリワードＩＤ「ＲＷ００１」に関連付けられた図３３の予約データベースに新規レコードを追加する。新規レコードの「予約ＩＤ」フィールドには、新しい予約ＩＤが格納される。新規レコードの「会員ＩＤ」フィールドには、予約リクエストに含まれる会員ＩＤ「ＣＵ００１」が格納される。「予約日時」フィールドには、予約リクエストをサーバ３０が受信した日時を示す値が格納される。
サーバ３０は、通知（Ｓ１３０１）を実行する。
一例として、ライブリクエストが投票リクエストである場合、ＣＰＵ３２は、図３３の投票データベースのレコードの数を含む通知をホスト端末５０に送信する。
この場合、通知（Ｓ１３０１）は、ライブリクエスト（Ｓ１１０２）が実行される度に実行されてもよいし、一定期間毎（例えば、１０秒毎）に実行されてもよい。
この場合、通知（Ｓ１３０１）は、ライブリクエスト（Ｓ１１０２）が実行される度に実行されてもよいし、一定期間毎（例えば、１０秒毎）に実行されてもよい。
一例として、ライブリクエストが予約リクエストである場合、ＣＰＵ３２は、予約リクエストを受信したことを示す通知をホスト端末５０に送信する。
この場合、通知（Ｓ１３０１）は、ライブリクエスト（Ｓ１１０２）が実行される度に実行される。
この場合、通知（Ｓ１３０１）は、ライブリクエスト（Ｓ１１０２）が実行される度に実行される。
ホスト端末５０は、スクリーン画面の更新（Ｓ１５０２）を実行する。
一例として、ライブリクエストが投票リクエストである場合、ホスト端末５０のＣＰＵ１２は、図３４の画面Ｐ１５０１の領域Ａ１５００ｂに示すように、プレゼンテーション中のプロジェクトに対する投票数を更新する。
一例として、ライブリクエストが予約リクエストである場合、ホスト端末５０のＣＰＵ１２は、図３４の画面Ｐ１５０１の領域Ａ１５０１に示すように、プレゼンテーション中のプロジェクトに含まれるリワードの予約が行われたことを示す画像ＩＭＧ１５０１（例えば、ポップアップ画像）を表示する。画像ＩＭＧ１５０１は、プレゼンテーションが終了するまで領域Ａ１５０１に表示し続けてもよいし、一定時間が経過したときに削除してもよい。
なお、クライアント端末１０−１のユーザがライブファンディング会場外にいる会員ユーザ（会員ＩＤ「ＣＵ０１０」）であっても、図３７の処理は適用可能である。
以上の処理により、ライブファンディングの処理が終了する。
ライブファンディングの終了後に、プロジェクトがローンチされると（例えば、図５の「開始日」フィールドが示す日になると）、サーバ３０は、図３３の予約データベースの「会員ＩＤ」フィールドに関連付けられた「メールアドレス」フィールド（図４）のメールアドレス宛に、プロジェクトがローンチされたことを示すメッセージを送信する。
（２−４）小括
第２実施形態について小括する。
第２実施形態について小括する。
ＣＰＵ３２（情報処理装置の一例）は、クラウドファンディングの会員ユーザを識別する会員ＩＤ（ユーザ識別情報の一例）と、クラウドファンディングのプロジェクトを識別するプロジェクトＩＤ（プロジェクト識別情報の一例）とを記憶する記憶装置３１にアクセス可能である。
ＣＰＵ３２は、ライブファンディング会場内にいる会員ユーザ（第１ユーザの一例）の指示に応じて、会員ＩＤと、プロジェクトＩＤとに、投票ＩＤ（投票情報の一例）を関連付けて記憶する（例えば、Ｓ１３００の処理）。
ＣＰＵ３２は、ライブファンディング会場内にいる会員ユーザの指示に応じて、会員ＩＤに、予約ＩＤ（予約情報の一例）を関連付けて記憶する（例えば、Ｓ１３００の処理）。
ＣＰＵ３２は、投票ＩＤ、又は、予約ＩＤの少なくとも１つに基づいて、ライブファンディング会場に設けられたスクリーンに表示する画面を更新する（例えば、Ｓ１３０１〜Ｓ１５０２の処理）。
ＣＰＵ３２は、ライブファンディング会場内にいる会員ユーザ（第１ユーザの一例）の指示に応じて、会員ＩＤと、プロジェクトＩＤとに、投票ＩＤ（投票情報の一例）を関連付けて記憶する（例えば、Ｓ１３００の処理）。
ＣＰＵ３２は、ライブファンディング会場内にいる会員ユーザの指示に応じて、会員ＩＤに、予約ＩＤ（予約情報の一例）を関連付けて記憶する（例えば、Ｓ１３００の処理）。
ＣＰＵ３２は、投票ＩＤ、又は、予約ＩＤの少なくとも１つに基づいて、ライブファンディング会場に設けられたスクリーンに表示する画面を更新する（例えば、Ｓ１３０１〜Ｓ１５０２の処理）。
これにより、ライブファンディング会場内にいる会員ユーザは、プロジェクトオーナのプレゼンテーションと、プロジェクトに対する投票、又は、リワードに対する予約の動向を見ながら、プロジェクトへの支援を検討することができる。
そのため、プロジェクトオーナは、プロジェクトの価値に見合った支援を受けることができる。
また、ユーザは、価値の高いプロジェクトを支援する機会、及び、プロジェクトの支援に対する報酬を受け取る機会の逸失を防ぐことができる。
そのため、プロジェクトオーナは、プロジェクトの価値に見合った支援を受けることができる。
また、ユーザは、価値の高いプロジェクトを支援する機会、及び、プロジェクトの支援に対する報酬を受け取る機会の逸失を防ぐことができる。
さらに、ＣＰＵ３２は、スクリーンに、領域Ａ１５００ｂの値（プロジェクトへの投票の数の一例）を表示してもよい（例えば、Ｓ１３０１〜Ｓ１５０２の処理）。
さらに、ＣＰＵ３２は、スクリーンに、画像ＩＭＧ１５０１（報酬が予約されたことを示す画像の一例）を表示してもよい（例えば、Ｓ１３０１〜Ｓ１５０２の処理）。
さらに、ＣＰＵ３２は、スクリーンに、画像ＩＭＧ１５０１（報酬が予約されたことを示す画像の一例）を表示してもよい（例えば、Ｓ１３０１〜Ｓ１５０２の処理）。
これにより、ライブファンディング内にいる会員ユーザは、ライブファンディングへの他の会員ユーザの関心をリアルタイムで知ることができる。その結果、ライブファンディングの趣向性が向上するので、会員ユーザによるプロジェクトへの支援（特に、リワードの予約）を促進することができる。
（２−５）変形例
第２実施形態の変形例について説明する。
第２実施形態の変形例について説明する。
図３７のライブリクエスト（Ｓ１１０２）において、予約リクエストが行われた場合、サーバ３０は、在庫引当を行ってもよい。
具体的には、ＣＰＵ３２は、図３３の予約データベースのレコードの数の分だけ、リワードデータベースの「チケット上限数」フィールドの値を減少させる。これにより、図３６の「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃを指定した会員ユーザの分の在庫を確保することができる。
具体的には、ＣＰＵ３２は、図３３の予約データベースのレコードの数の分だけ、リワードデータベースの「チケット上限数」フィールドの値を減少させる。これにより、図３６の「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃを指定した会員ユーザの分の在庫を確保することができる。
図３７のライブリクエスト（Ｓ１１０２）において、予約リクエストが行われた場合、サーバ３０は、在庫引当に加えて、決済（例えば、図２５の入金の確認（Ｓ３２１））を実行してもよい。
ライブファンディング会場内にいる会員ユーザに二次元バーコードを配布してもよい。
具体的には、図３７のライブファンディングの処理を実行する前に、ライブファンディング会場内の会員ユーザに二次元バーコードを配布する。二次元バーコードは、図３５の画面Ｐ１１０１のＵＲＬに関連付けられている。会員ユーザが、クライアント端末１０に設けられたカメラで二次元バーコードを撮影すると、ＣＰＵ１２は、二次元バーコードに関連付けられたＵＲＬにアクセスする。これにより、画面Ｐ１１０１が表示部１４に表示される。
この場合、トップ画面の表示（Ｓ１００）〜会員ホーム画面の表示（Ｓ１１００）は省略可能である。
具体的には、図３７のライブファンディングの処理を実行する前に、ライブファンディング会場内の会員ユーザに二次元バーコードを配布する。二次元バーコードは、図３５の画面Ｐ１１０１のＵＲＬに関連付けられている。会員ユーザが、クライアント端末１０に設けられたカメラで二次元バーコードを撮影すると、ＣＰＵ１２は、二次元バーコードに関連付けられたＵＲＬにアクセスする。これにより、画面Ｐ１１０１が表示部１４に表示される。
この場合、トップ画面の表示（Ｓ１００）〜会員ホーム画面の表示（Ｓ１１００）は省略可能である。
クラウドファンディング会場内にいる会員ユーザと、クラウドファンディング会場外にいる会員とを区別してもよい。
具体的には、ＣＰＵ３２は、図４の会員データベースにおいて、二次元バーコードを介して図３５の画面Ｐ１１０１を表示させた会員ユーザの会員ＩＤにフラグを設定する。ＣＰＵ３２は、フラグが設定された会員ＩＤに対して、以下の処理の少なくとも１つを実行する。
・図３６の「投票」ボタンＢ１１０２ａを表示する。この場合、ライブファンディング会場外にいる会員ユーザは、プロジェクトに投票することはできない。
・図３６の「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃを表示する。この場合、ライブファンディング会場外にいる会員ユーザは、リワードを予約することはできない。
・ライブファンディング会場内にいる会員ユーザに対して、チケット金額を割り引く。
具体的には、ＣＰＵ３２は、図４の会員データベースにおいて、二次元バーコードを介して図３５の画面Ｐ１１０１を表示させた会員ユーザの会員ＩＤにフラグを設定する。ＣＰＵ３２は、フラグが設定された会員ＩＤに対して、以下の処理の少なくとも１つを実行する。
・図３６の「投票」ボタンＢ１１０２ａを表示する。この場合、ライブファンディング会場外にいる会員ユーザは、プロジェクトに投票することはできない。
・図３６の「欲しい」ボタンＢ１１０２ｂ〜Ｂ１１０２ｃを表示する。この場合、ライブファンディング会場外にいる会員ユーザは、リワードを予約することはできない。
・ライブファンディング会場内にいる会員ユーザに対して、チケット金額を割り引く。
上述の第２実施形態は、第１実施形態以外のクラウドファンディング（例えば、プロジェクトを支援した会員に対して、チケットの代わりに、報酬を与えるクラウドファンディング）にも適用可能である。
（３）その他の変形例
上述の実施形態では、クライアント端末１０にインストールされたウェブブラウザと、サーバ３０と、ホスト端末５０とがｈｔｔｐｓ通信を行うことによって情報処理が実現される例について説明したが、本実施形態はこれに限られるものではない。
例えば、本実施形態の情報処理は、クライアント端末１０にインストールされた専用アプリケーション（ブラウザ以外のアプリケーション）と、サーバ３０と、ホスト端末５０とがｈｔｔｐｓ通信を行うことによっても実現可能である。
また、本実施形態の情報処理は、専用アプリケーションのみによって実現されてもよい。この場合、クライアント端末１０とサーバ３０との間の通信は不要である。
また、本実施形態の通信方式は、ｈｔｔｐｓ通信に限られるものではない。
上述の実施形態では、クライアント端末１０にインストールされたウェブブラウザと、サーバ３０と、ホスト端末５０とがｈｔｔｐｓ通信を行うことによって情報処理が実現される例について説明したが、本実施形態はこれに限られるものではない。
例えば、本実施形態の情報処理は、クライアント端末１０にインストールされた専用アプリケーション（ブラウザ以外のアプリケーション）と、サーバ３０と、ホスト端末５０とがｈｔｔｐｓ通信を行うことによっても実現可能である。
また、本実施形態の情報処理は、専用アプリケーションのみによって実現されてもよい。この場合、クライアント端末１０とサーバ３０との間の通信は不要である。
また、本実施形態の通信方式は、ｈｔｔｐｓ通信に限られるものではない。
上述の実施形態では、サーバ３０に設けられた記憶装置３１にデータベースを記憶する例について説明したが、本実施形態はこれに限られるものではない。
例えば、本実施形態の情報処理は、サーバ３０の外部に設けられた記憶装置（例えば、ホスト端末５０の記憶装置１１）にデータベースを記憶する（つまり、ＣＰＵ３２は、通信インタフェース３５を介してデータベースにアクセスする）場合にも適用可能である。
例えば、本実施形態の情報処理は、サーバ３０の外部に設けられた記憶装置（例えば、ホスト端末５０の記憶装置１１）にデータベースを記憶する（つまり、ＣＰＵ３２は、通信インタフェース３５を介してデータベースにアクセスする）場合にも適用可能である。
以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態及び変形例は、組合せ可能である。
１ ：情報処理システム
１０ ：クライアント端末
１１ ：記憶装置
１２ ：ＣＰＵ
１３ ：入力部
１４ ：表示部
１５ ：通信インタフェース
３０ ：サーバ
３１ ：記憶装置
３２ ：ＣＰＵ
３３ ：入力部
３４ ：表示部
３５ ：通信インタフェース
５０ ：ホスト端末
１０ ：クライアント端末
１１ ：記憶装置
１２ ：ＣＰＵ
１３ ：入力部
１４ ：表示部
１５ ：通信インタフェース
３０ ：サーバ
３１ ：記憶装置
３２ ：ＣＰＵ
３３ ：入力部
３４ ：表示部
３５ ：通信インタフェース
５０ ：ホスト端末
Claims (4)
- クラウドファンディングの会員であるユーザを識別するユーザ識別情報と、前記クラウドファンディングのプロジェクトを識別するプロジェクト識別情報とを記憶する記憶装置にアクセス可能な情報処理装置であって、
前記プロジェクトのプロジェクトオーナによるプレゼンテーションが行われるライブファンディング会場内にいる第１ユーザの指示に応じて、前記第１ユーザを識別する第１ユーザ識別情報と、前記プロジェクト識別情報と、前記プロジェクトへの支援に対する報酬の予約に関する予約情報と、を関連付けて記憶する手段を備え、
前記予約情報に基づいて、ライブファンディング会場に設けられたスクリーンに、予約が行われたことを示す画面を表示する手段を備え、
前記ライブファンディングの終了後に前記プロジェクトがローンチされると、前記第１ユーザに、前記プロジェクトがローンチされたことを示すメッセージを送信する手段を備え、
前記メッセージを受信した第１ユーザの指示に基づいて、前記第１ユーザ識別情報と、前記プロジェクト識別情報と、前記プロジェクトへの支援の金額を示す情報と、を関連付けて記憶する手段を備え、
前記第１ユーザ識別情報に、前記プロジェクトへの支援に対する報酬を受け取る権利であるチケットを識別するチケット識別情報を関連付けて記憶する手段を備え、
前記第１ユーザからの指示に応じて、前記第１ユーザ識別情報と前記チケット識別情報との関連付けを解除し、かつ、前記第１ユーザによって指定された第２ユーザを識別する第２ユーザ識別情報に前記チケット識別情報を関連付ける手段を備える、
情報処理装置。 - 前記プロジェクトへの投票に関する投票情報と、前記第１ユーザ識別情報と、を関連付けて記憶する手段を備え、
前記表示する手段は、前記投票情報に基づいて、前記スクリーンに、前記プロジェクトへの投票の数を示す画面を表示する、
請求項１に記載の情報処理装置。 - 前記プロジェクト識別情報と、前記チケットの上限数に関する情報と、を関連付けて記憶する手段を備え、
前記予約情報を前記プロジェクト識別情報に関連付けたことに応じて、前記チケットの上限数に関する情報を更新する、
請求項１又は２に記載の情報処理装置。 - 前記第１ユーザ識別情報に関連付けられた前記プロジェクトへの支援の金額は、前記ライブファンディング会場にいない第２ユーザを識別する第２ユーザ識別情報に関連付けられる前記プロジェクトへの支援の金額に対して割り引かれた金額である、
請求項１〜３の何れかに記載の情報処理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016038766A JP6539847B2 (ja) | 2016-03-01 | 2016-03-01 | 情報処理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016038766A JP6539847B2 (ja) | 2016-03-01 | 2016-03-01 | 情報処理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2017156927A JP2017156927A (ja) | 2017-09-07 |
| JP6539847B2 true JP6539847B2 (ja) | 2019-07-10 |
Family
ID=59810217
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016038766A Active JP6539847B2 (ja) | 2016-03-01 | 2016-03-01 | 情報処理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6539847B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7042000B2 (ja) | 2019-11-25 | 2022-03-25 | 株式会社マクアケ | 情報処理装置、情報処理方法、及びプログラム |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001006009A (ja) * | 1999-06-18 | 2001-01-12 | Toshiba Corp | 無線投票システム |
| JP2002329032A (ja) * | 2001-04-26 | 2002-11-15 | Furekkusuai:Kk | 通信投票システムとその方法、およびそのためのプログラム |
| US20050272495A1 (en) * | 2004-06-02 | 2005-12-08 | Joseph Penner | Game show system and method for conducting same |
| JP2006268442A (ja) * | 2005-03-24 | 2006-10-05 | Seiko Epson Corp | 画像合成表示装置と携帯端末装置と画像合成表示プログラムと記録媒体と画像合成表示方法 |
| WO2015053406A1 (ja) * | 2013-10-12 | 2015-04-16 | 株式会社ハイスピードボーイズ | コンテンツ配信システム |
-
2016
- 2016-03-01 JP JP2016038766A patent/JP6539847B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2017156927A (ja) | 2017-09-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230117907A1 (en) | Methods and systems for the efficient transfer of entities on a blockchain | |
| US10360570B2 (en) | System and method for conducting a gift value transaction | |
| US20130268377A1 (en) | Gift collaboration social network service | |
| JP6967116B1 (ja) | 電子チケット管理システムおよびプログラム | |
| US20110302012A1 (en) | System and method for redeeming coupons | |
| US20060155645A1 (en) | Image uploading and print-on demand system and method, namely for art and photographs | |
| JP2011095944A (ja) | 電子商取引管理及び電子決済一体システム及び情報処理装置 | |
| US20150120342A1 (en) | Method and apparatus for self-portrait event check-in | |
| CN114846494A (zh) | 具有可定制预购功能的产品发布系统、方法和设备 | |
| JP2023011611A (ja) | ブロックチェーンネットワークを介してデータを通信し、格納し、及び処理するためのブロックチェーンベースのシステム及び方法 | |
| US20180210964A1 (en) | Third-party database interaction to provision users | |
| JP2018045428A (ja) | 譲渡仲介システム | |
| US20150120343A1 (en) | Method and apparatus for socially contingent event admission purchase | |
| US20160078509A1 (en) | Apparatus, system, and method of managing transactions of electronic books | |
| JP6539847B2 (ja) | 情報処理装置 | |
| JP6532097B2 (ja) | 情報処理装置 | |
| KR20220095068A (ko) | 부동산 중개 서비스 시스템 및 그 방법 | |
| JP6149525B2 (ja) | 電子新聞提供システム、新聞ポータルサイトのサーバ装置、新聞社サーバ装置 | |
| JP6504607B2 (ja) | 情報処理装置 | |
| JP2007317124A (ja) | プリント受注・管理サーバーシステム、および画像ネットワークシステム | |
| JP4679048B2 (ja) | 電子チケット管理・流通システム及び電子チケット流通サーバ | |
| JP2014174562A (ja) | 情報処理装置及びプログラム | |
| JP2016173624A (ja) | 電子書籍販売仲介システムおよびプログラム | |
| JP7079037B1 (ja) | 情報処理方法、情報処理装置、情報処理プログラムおよび記録媒体 | |
| US11928725B2 (en) | Methods for searching and obtaining design items and meta data concerning the design items |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20180501 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20180524 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20180625 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20190118 |
|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20190118 |
|
| A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20190131 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190219 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190306 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190402 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190415 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20190507 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190515 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6539847 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |