JP6504607B2 - Information processing device - Google Patents

Description

  The present invention relates to an information processing apparatus used for crowd funding.

In recent years, a service called crowdfunding has become widespread apart from e-commerce, which allows shopping on the web.
Crowdfunding is a mechanism to provide fund creators who have created a project with funds assisted by a supporter for a project (for example, a project for developing a new product) via the Internet.

  In particular, in the case of purchase-type crowdfunding, a project creator sends a reward (for example, a newly developed product) for support to a project to a supporter (see, for example, Non-Patent Document 1). The purchase-type crowdfunding is similar to e-commerce in that it can receive a reward for paying a certain amount of money.

"Kickstarter", [online], Kickstarter, Inc., [search on April 18, 2012], Internet <URL: http://www.kickstarter.com/>

However, in the conventional crowdfunding, even after funding is provided, it is not possible to receive a reward until the project is completed and the reward is completed.
Also, with conventional crowdfunding, it is not possible to cancel the support even if the interest in the supported project diminishes between the time the fund is supported and the time the reward is received.
Further, in the case of the conventional crowdfunding, in the case of the all-or-nothing method, the support can not be received after the total amount of the supported funds reaches a predetermined amount and the support period has expired. Therefore, even for projects in which a large number of users are interested, the number of supporters is limited.

  For these reasons, crowdfunding is a psychological barrier for users to use services. This psychological barrier prevents the spread of crowdfunding.

  An object of the present invention is to provide an information processing apparatus capable of promoting the spread of crowd funding.

One aspect of the present invention is
An information processing apparatus capable of accessing a storage device that stores user identification information identifying a user who is a member of a crowdfunding project and project identification information identifying a project of the crowdfunding,
A unit that associates and stores information indicating the amount of support for the project with the first user identification information identifying the first user and the project identification information in accordance with an instruction from the first user;
A means for associating and storing ticket identification information identifying a right to receive a reward for support for the project with the first user identification information;
A second user identification information identifying a second user designated by the first user, canceling the association between the first user identification information and the ticket identification information in response to an instruction from the first user. Means for associating and storing the ticket identification information with
An information processing apparatus comprising:

  Promote the spread of crowdfunding.

The system configuration figure of the information processing system of a 1st embodiment. The figure which shows the structure of the client terminal of 1st Embodiment. The figure which shows the structure of the server of 1st Embodiment. The figure which shows the data structure of the member database of 1st Embodiment. The figure which shows an example of the data structure of the project database of 1st Embodiment. The figure which shows an example of the data structure of the reward database of 1st Embodiment. A figure showing an example of data structure of support history database of a 1st embodiment. The figure which shows an example of the data structure of the ticket database of 1st Embodiment. Schematic which shows transition of the status of the ticket of 1st Embodiment. A figure showing an example of data structure of transfer history database of a 1st embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. FIG. 7 is a view showing an example of a screen displayed in the information processing of the first embodiment. The sequence diagram of the process of the member registration of 1st Embodiment. The sequence diagram of the processing of project creation of a 1st embodiment. The sequence diagram of the process of assistance of 1st Embodiment. FIG. 7 is a sequence diagram of ticket use processing according to the first embodiment. FIG. 8 is a sequence diagram of a first example of ticket transfer processing according to the first embodiment. FIG. 10 is a sequence diagram of a second example of ticket transfer processing according to the first embodiment. FIG. 5 is a sequence diagram of processing of project editing according to the first embodiment. A sequence diagram of processing of refund of a 1st embodiment.

(1) First Embodiment (1-1) Configuration of Information Processing System (FIG. 1)
The configuration of the information processing system of the first embodiment will be described. FIG. 1 is a system configuration diagram of an information processing system according to the first embodiment.

As shown in FIG. 1, the information processing system 1 includes client terminals 10 (10-1 to 10-n) and a server 30.
The client terminal 10 and the server 30 can perform communication (for example, https communication) via the communication network NW (for example, the Internet).

The client terminal 10 is an example of an information processing apparatus used by a user. The client terminal 10 is, for example, a smartphone, a tablet terminal, a personal computer or the like.
The server 30 is an example of an information processing apparatus that executes predetermined processing based on a request transmitted from the client terminal 10. The server 30 is, for example, a web server.

(1-2) Configuration of client terminal (FIG. 2)
The configuration of the client terminal of the first embodiment will be described. FIG. 2 is a diagram showing the configuration of the client terminal according to the first embodiment.

  As shown in FIG. 2, the client terminal 10 includes a central processing unit (CPU) 11, a storage device 11, an input unit 13, a display unit 14, and a communication interface 15.

The storage device 11 is configured to store programs and data necessary for information processing. The storage device 11 is, for example, a combination of a read only memory (ROM), a random access memory (RAM), and a storage (for example, a flash memory or a hard disk).
The programs necessary for information processing are, for example, a program of an OS (Operating System), a program of an application (for example, a browser) that executes information processing, and the like.
The data necessary for the information processing is, for example, data obtained by executing the information processing (that is, an execution result of the information processing).

  The CPU 12 is configured to realize the function of the application by activating a program stored in the storage device 11.

  The input unit 13 is configured to receive an instruction of the user. The input unit 13 is, for example, a keyboard, a pointing device, a touch panel, or the like.

  The display unit 14 is configured to present information to the user. The display unit 14 is, for example, a liquid crystal display.

  The communication interface 15 is configured to control communication between the client terminal 10 and the communication network NW.

(1-3) Configuration of server (FIG. 3)
The configuration of the server of the first embodiment will be described. FIG. 3 is a diagram showing the configuration of the server according to the first embodiment.

  As shown in FIG. 3, the server 30 includes a storage device 31, a CPU 32, an input unit 33, a display unit 34, and a communication interface 35.

The storage device 31 is a storage device that stores programs, data, and a database necessary for information processing. The storage device 31 is, for example, a combination of a ROM, a RAM, and a storage (for example, a flash memory or a hard disk).
The programs necessary for information processing are, for example, a program of an OS (Operating System), a program of an application for realizing the function of the server 30, and the like.
Data necessary for information processing is, for example, requirement information (described later).

  The CPU 32 is configured to realize the function of the server 30 by activating a program stored in the storage device 31.

  The input unit 33 and the display unit 34 are the same as the input unit 13 and the display unit 14 in FIG. 2, respectively.

  The communication interface 35 is configured to control communication between the server 30 and the communication network NW.

(1-4) Data structure of database (FIGS. 4 to 7)
The data structure of the database of the first embodiment will be described.

(1-4-1) Membership database (Figure 4)
The data structure of the member database of the first embodiment will be described. FIG. 4 is a view showing the data structure of the member database of the first embodiment.

  Each record of the member database stores information on members (hereinafter referred to as "member information").

  As shown in FIG. 4, the member database includes a "member ID" field, an "email address" field, a "password" field, a "name" field, an "image" field, an "address" field, and " Payment Information "field.

  A member ID is stored in the "member ID" field. The member ID is information unique to each user registered as a member. That is, the member ID is information for identifying a member. The member ID is a primary key of each record of the member database. The member ID is information that the server 30 determines.

In the "e-mail address" field, text data indicating a member's e-mail address is stored.
In the "password" field, text data indicating a member's password is stored.
The information in the "Email Address" field and the "Password" field is referenced for member login authentication. The information in the "mail address" field and the "password" field is information that the member decides arbitrarily.

In the "name" field, text data indicating the name of the member is stored.
Image data indicating an image of the member is stored in the “image” field.
In the "address" field, text data indicating the address of the member is stored.
The “Payment Information” field stores a value indicating information (eg, a credit card number) on payment of the member.
The information in the "name" field, the "image" field, the "address" field, and the "payment information" field is information that the member decides arbitrarily.

(1-4-2) Project database (Figure 5)
The data structure of the project database of the first embodiment will be described. FIG. 5 is a view showing an example of the data structure of the project database of the first embodiment.

Each record of the project database stores information on the project (hereinafter referred to as "project information").
"Project" means the target of support from members in crowdfunding.

  As shown in FIG. 5, the project database includes a "project ID" field, a "project owner ID" field, a "password" field, an "email address" field, a "name" field, and a "profile" field. , "Project name" field, "target amount" field, "summary" field, "image" field, "start date" field, "end date" field, and "type" field.

  The project ID is stored in the "project ID" field. Project ID is information unique to each project. That is, the project ID is information for identifying a project. Project ID is the primary key of each record in the project database. The project ID is information that the server 30 determines.

The project owner ID is stored in the "project owner ID" field. The project owner ID is information identifying a project owner.
The "password" field stores a password for logging in as a project owner.
The “project owner ID” field and the “password” field are information that the server 30 determines.
"Project owner" means a user registered as a creator of a project. The project owner has the authority to manage the project.

  In the "e-mail address" field, text data indicating the e-mail address of the project owner is stored. The information in the "mail address" field is information that the project owner arbitrarily determines.

In the "name" field, text data indicating the name of the project owner is stored.
In the "profile" field, text data indicating the profile of the project owner is stored.
In the "project name" field, text data indicating the name of the project is stored.
In the "target amount" field, a value indicating the target amount for the project is stored.
In the "Summary" field, text data indicating a summary of the project is stored.
The “image” field stores image data indicating an image of a project.
The “start date” field and the “end date” field store values indicating the start date and end date of the project, respectively. The information in the "Start Date" field and the "End Date" field indicate the duration of the project.
The information in the "Name" field, "Profile" field, "Project Name" field, "Target amount" field, "Summary" field, "Image" field, "Start date" field, and "End date" field is It is information that the owner decides arbitrarily.

The "type" field contains a code indicating the type of project. The type code “AN” indicates that the project type is “all or nothing”. The type code “DC” indicates that the project type is “direct challenge method”.
The information in the “type” field is information that the project owner arbitrarily determines.
In the all-or-nothing method, the support amount is passed to the project creator only when the total amount of the support amount reaches the value of the “target amount” field by the date indicated by the value stored in the “end date” field. And rewards are sent to the supporters.
In the direct challenge method, the total amount of assistance for the day indicated by the value stored in the "end date" field is passed to the project creator.

(1-4-3) Reward database (Figure 6)
The data structure of the reward database of the first embodiment will be described. FIG. 6 is a view showing an example of the data structure of the reward database of the first embodiment.

In each record of the reward database, information on reward (hereinafter referred to as "reward information") is stored.
One project ID can be associated with a plurality of records in the reward database.
"Reward" means a reward for supporting the project.

  As shown in FIG. 6, the reward database includes a "reward ID" field, a "ticket upper limit number" field, a "ticket distribution number" field, a "reward name" field, an "image" field, and a "ticket amount". Field, a "description" field, and a "scheduled date" field.

  The reward ID is stored in the "reward ID" field. The reward ID is information unique to each reward. That is, the reward ID is information for identifying a reward. The reward ID is a primary key of each record of the reward database. The reward ID is information that the server 30 determines.

The “upper limit number of tickets” field stores a value indicating the upper limit number of tickets provided in one reward.
"Ticket" means the right to receive compensation for support for the project.
The information in the "limit number of tickets" field is information that the project owner arbitrarily determines.

The "number of tickets distributed" field stores a value indicating the number of tickets distributed to members supporting the project. The value of the "number of tickets distributed" field indicates the number of supporters of the project.
The information in the "ticket distribution number" field is information that the server 30 determines.

In the "reward name" field, text data indicating the name of the reward is stored.
In the "image" field, image data indicating an image of the reward is stored.
In the "ticket amount" field, a value indicating the supporting amount necessary to obtain one ticket is stored.
In the "description" field, text data indicating a description of the reward is stored.
The "scheduled date" field stores a value indicating the date when the ticket becomes available.
Information in the "reward name" field, the "image" field, the "ticket amount" field, the "description" field, and the "scheduled date" field is information that the project owner arbitrarily determines.

(1-4-4) Support history database (Figure 7)
The data structure of the reward database of the first embodiment will be described. FIG. 7 is a view showing an example of the data structure of the support history database of the first embodiment.

In each record of the support history database, information (hereinafter referred to as "support history information") related to the support history of the project is stored.
One member ID can be associated with a plurality of records in the support history database.
“Support” means providing funding for the project.

  As shown in FIG. 7, the support history database includes a “support ID” field, a “support amount” field, and a “support date” field.

  The support ID is stored in the "support ID" field. The support ID is information unique to each support. That is, support ID is information which identifies support. The support ID is a primary key of each record of the support history database. The support ID is information that the server 30 determines.

The "support amount" field stores a value indicating the support amount.
The "support date" field stores a value indicating a support date.
The information of the "support amount" field and the "support date" field is information determined by the server 30.

(1-4-5) Ticket Database (FIGS. 8-9)
The data structure of the ticket database of the first embodiment will be described. FIG. 8 is a view showing an example of the data structure of the ticket database of the first embodiment.

Each record of the ticket database stores information on a ticket (hereinafter referred to as "ticket information").
One reward ID can be associated with a plurality of records in the ticket database.

  As shown in FIG. 8, the ticket database includes a "ticket ID" field, a "ticket owner ID" field, a "support ID" field, a "token for receipt" field, a "token due date" field, and a "status". Including the 'field'.

  The ticket ID is stored in the "ticket ID" field. The ticket ID is information unique to each ticket. That is, ticket ID is information which identifies a ticket. The ticket ID is a primary key of each record in the ticket database. The ticket ID is information that the server 30 determines.

  The ticket owner ID is stored in the "ticket owner ID" field. The ticket owner ID is a member ID of a member who owns a ticket.

  In the "support ID" field, the support ID of the support that is the trigger for associating the ticket ID with the owner ID is stored.

In the "token for receipt" field, a character string indicating a receipt token to be used when receiving a ticket via a paper ticket is stored.
The "token due date" field is a value indicating the use due date of the information stored in the "token for receipt" field.
Information in the “token for receipt” field and the “token due date” field is information determined by the server 30.

  In the "status" field, a code indicating the status of the ticket (hereinafter referred to as "status code") is stored.

  The status of the ticket according to the first embodiment will be described. FIG. 9 is a schematic view showing the transition of the status of the ticket according to the first embodiment.

  As shown in FIG. 9, the status code includes a code "STA1" indicating the first status, a code "STA2" indicating the second status, a code "STA3" indicating the third status, and a code indicating the fourth status. "STA4".

After the support request (described later) is made, if the confirmation of the deposit of the support money to the project is successful, the status of the ticket becomes the first status.
The “first status” indicates a state in which the ticket is available (hereinafter referred to as “available state”). The ticket identified by the ticket ID associated with the status code "STA1" is available and transferable.

When a ticket transfer request (described later) is performed in the first status, the status of the ticket transitions to the second status.
The “second status” indicates a state in which the process of transferring the ticket has not been completed (hereinafter referred to as “in transfer state”). The ticket identified by the ticket ID associated with the status code "STA2" is unavailable and non-transferable.
When the transfer is completed in the second status, the status of the ticket transitions to the first status.

When a ticket use request (described later) is performed in the first status, the status of the ticket transitions to the third status.
The “third status” indicates a state in which a ticket use request has been made (hereinafter referred to as “in-use state”). The ticket identified by the ticket ID associated with the status code "STA3" is unavailable and not transferable.

When a reward completion request (described later) is made in the fourth status, the ticket status changes to the fourth status.
The “fourth status” indicates a state in which the ticket has been used (hereinafter referred to as “used state”). The ticket identified by the ticket ID associated with the status code "STA4" is unavailable and not transferable.

(1-4-6) Transfer history database (Fig. 10)
The data structure of the transfer history database of the first embodiment will be described. FIG. 10 is a view showing an example of the data structure of the transfer history database of the first embodiment.

In each record of the transfer history database, information on the transfer history of the ticket (hereinafter referred to as "transfer history information") is stored.
One ticket ID can be associated with a plurality of records in the transfer history database.

  As shown in FIG. 10, the transfer history database includes a “registration date” field, a “transferee ID” field, and a “transferee ID” field.

  The “registration date” field stores a value indicating the registration date of each record. The registration date is a primary key of each record of the transfer history database. The registration date is information that the server 30 determines.

  The "owner ID" field stores the ticket owner ID of the transferor (that is, before the transfer is made).

  In the "Assignee ID" field, a ticket owner ID of the assignee (that is, after the transfer has been performed) is stored.

(1-5) Screens Displayed in Information Processing (FIGS. 11 to 22)
The screen displayed in the information processing of the first embodiment will be described. 11 to 22 are diagrams showing examples of screens displayed in the information processing of the first embodiment.
The screens of FIGS. 11 to 22 are displayed on the display unit 14 of the client terminal 10. On each screen, the user can give an instruction (input to an input field and designation of a button) using the input unit 13. The given instruction is transmitted from the client terminal 10 to the server 30.

The screen P100 in FIG. 11 is a screen displayed when the URL (Uniform Resource Locator) for the top screen is accessed.
The screen P100 includes a “membership registration” button B100a, a “project creation” button B100b, and a “login” button B100c.

When the “membership registration” button B100a is designated on the screen P100, the screen P110 is displayed.
The screen P110 includes an input field F110 and a "Done" button B110.
The input field F110 is an input field for inputting information required for member registration. The information necessary for member registration is, for example, a name, an e-mail address, a password, an image, an address, and payment information.

  When the information is input to the input field F110 in the screen P110 and the “Done” button B110 is specified, the client terminal 10 requests the server 30 for a request for member registration processing (hereinafter referred to as “member registration request”). Send.

When the “project creation” button B100b is designated on the screen P100 of FIG. 11, the screen P210 of FIG. 12 is displayed.
The screen P210 includes input fields F210a to F210b and a "Done" button B210.
The input fields F210a to F210b are input fields for inputting project information. Specifically, the input field F210a is an input field for inputting a name, an e-mail address, and a profile of a project owner. The input field F210b is an input field for inputting a project name, a target amount, a start date, an end date, an image, and a type. An input field for inputting a type can be input in a pull-down format.

  When information is input in the input fields F210a to F210b on the screen P210 and the “Done” button B210 is specified, the client terminal 10 requests the server 30 to make a project creation processing request (hereinafter referred to as “project creation request” Send).

When the “login” button B100c is designated on the screen P100 of FIG. 11 and the member ID (for example, the member ID “CU001”) and the password are input, the screen P310 of FIG. 13 is displayed.
The screen P310 includes a "support" button B310a, a "owned ticket list" button B310b, and a "ticket reception" button B310c.

When the “support” button B310a is designated on the screen P310, the screen P311 is displayed.
The screen P311 includes images IMG311a to IMG311b, areas A311a to A311b, and "select" buttons B311a to B311b.
The images IMG311a to IMG311b are images of a project to be supported (for example, an image corresponding to image data stored in the “image” field of FIG. 5).
Project information (for example, the project name, the number of participants, the remaining number of days, and the achieved amount of money) is displayed in the areas A311a to A311b. The “project name” is, for example, information of the “project name” field of FIG. The "number of participants" is the number of members supporting the project (for example, the value of the "number of tickets distributed" field in FIG. 6). The “remaining days” is the remaining days until the end date of the project (for example, the difference between the “end date” field in FIG. 5 and the date when the screen P310 is displayed). The "achievement amount" is the total amount of the support amount (for example, the product of the value of the "ticket distribution number" field in FIG. 6 and the value of the "ticket amount" field).
The "select" buttons B311a to B311b are associated with project IDs (for example, project IDs "PR001" to "PR002") related to the project information displayed in the areas A311a to A311b, respectively.

When the “select” button B 311 a is designated on the screen P 311, the screen P 312 is displayed.
The screen P312 includes an area A312, an input field F312, and a "Done" button B312.
In the area A312, the reward information associated with the project ID (for example, the project ID “PR001”) associated with the “select” button B311a is displayed. The “reward name” is, for example, information of the “reward name” field of FIG. The “ticket amount” is, for example, the value of the “ticket amount” field in FIG.
The input field F312 is an input field for inputting the number of tickets desired to be acquired.

  When the information is input to the input field F312 on the screen P312 and the “Done” button B312 is designated, the client terminal 10 transmits a request for support processing (hereinafter referred to as “support request”) to the server 30. .

When the “owned ticket list” button B 310 b is designated on the screen P 310, the screen P 320 in FIG. 14 is displayed.
The screen P320 includes areas A320a to A320b, "use" buttons B320a to B320b, "transfer" buttons B320c to B320d, and "issue" buttons B320e to B320f.
In the areas A320a to A320b, ticket information on tickets owned by the member is displayed. The “project name” is, for example, information of the “project name” field of FIG. The “reward name” is, for example, information of the “reward name” field of FIG. The “ticket amount” is, for example, the value of the “ticket amount” field in FIG.
The “use” buttons B320a to B320b are associated with ticket IDs (for example, ticket IDs “TI001” to “TI002”) corresponding to the ticket information displayed in the areas A320a to A320b, respectively.
The "assignment" buttons B320c to B320d are respectively associated with the reward IDs corresponding to the reward information displayed in the areas A320a to A320b.
The “issue” buttons B320 e to B 320 f are respectively associated with the reward IDs corresponding to the reward information displayed in the areas A 320 a to A 320 b.

When the “use” button B 320 a is designated on the screen P 320, the screen P 321 is displayed.
The screen P321 includes the information displayed in the area A320a, the "YES" button B321a, and the "NO" button B321b.
When the “YES” button B 321 a is designated, the client terminal 10 causes the server 30 to use the ticket identified by the ticket ID (for example, ticket ID “TI001”) associated with the “use” button B 320 a. Send a ticket usage request.
If the “NO” button B 321 b is designated, the screen returns to screen P 320.

When the “assignment” button B 320 c is designated on the screen P 320, the screen P 322 in FIG. 15 is displayed.
The screen P322 includes areas A322a to A322b, input fields F322a to F322b, and a "Done" button B322.
In the area A 322 a, information similar to that of the area A 320 a in FIG. 14 is displayed.
In the area A 322 b, a URL required to receive a ticket (hereinafter, referred to as “reception URL”) is displayed. The reception URL “https://example.com/receive?token=ABCDEFG012345” includes a reception token “ABCDEFG012345” for receiving a ticket.
The input field F322a is an input field for inputting the member ID of the member (that is, the transferee of the ticket) to which the URL displayed in the area A322b is to be transmitted.
The input field F322b is an input field for inputting an e-mail address as a destination of the URL displayed in the area A322b. This e-mail address may be an e-mail address associated with the member ID in the member database of FIG. 4 or may be an e-mail address not associated with the member ID (e.g., e-mail address of a non-member user) .

  When information is input to input field F 322 a in screen P 322 and “done” button B 322 is specified, client terminal 10 requests server 30 to transfer a ticket (hereinafter referred to as “ticket transfer request”) Send

When login authentication is performed based on the member ID (for example, member ID “CU999”) input to the input field F322a of the screen P322, the screen P330 of FIG. 16 is displayed.
The screen P330 includes input fields F330a to F330b and a "Done" button B330.
The input field F330a is an input field for inputting a reception URL. The reception URL of the input field F 330 a may be input in advance, or may be input by the user using the input unit 13.
The input field F330b is an input field for inputting a code required to receive a ticket (hereinafter referred to as a "receiving code").

  When information is input in the input field F330a or F330b on the screen P330 and the "done" button B330 is designated, the client terminal 10 requests the server 30 to receive a ticket (hereinafter referred to as "ticket reception request"). Send).

When the “issue” button B 320 e is designated on the screen P 320 of FIG. 14, the screen P 340 of FIG. 17 is displayed.
The screen P340 includes an input field F340 and a "Done" button B340.
The input field F340 is an input field for inputting the name, e-mail address and address of the transferee.

  When information is input to input field F340 in screen P340 and "done" button B340 is specified, client terminal 10 requests server 30 to issue a ticket (hereinafter referred to as "ticket issuance request"). Send

The screen P 350 of FIG. 18 is displayed when the user of the ticket receiving screen accesses the URL of the ticket reception screen by a user who has received the issuance ticket and does not have a member ID (hereinafter referred to as “non-member user”). .
The screen P350 includes input fields F350a and F350b, a "membership registration" button B350a, and a "login" button B350b.
The input fields F350a to F350b are respectively similar to the input fields F330a to F330b of FIG.

When the information is input to the input field F 350 a or F 350 b and the “membership registration” button B 350 a is designated, the screen P 110 of FIG. 11 is displayed. When the information is input to the input field F110 in the screen P110 and the “Done” button B110 is designated, the client terminal 10 transmits a member registration request and a ticket reception request to the server 30.
When the information is input in the input field F 350 a or F 350 b and the “login” button B 350 b is designated, the client terminal 10 transmits a login request and a ticket reception request to the server 30. As a result, the screen P310 of FIG. 13 is displayed.

When the “login” button B100c is designated on the screen P100 of FIG. 11 and a project owner ID (for example, a project owner ID “PO001”) and a password are input, a screen P410 of FIG. 19 is displayed.
The screen P410 includes a "project management" button B410a, a "reward management" button B410b, and a "ticket management" button B410c.

When the “project management” button B410a is designated on the screen P410, the screen P411 is displayed.
The screen P411 includes images IMG411a to IMG411b, areas A411a to A411b, and "edit buttons" B411a to B411b.
Images IMG411 a to IMG 411 b are images of a project to be managed (for example, an image corresponding to image data stored in the “image” field of FIG. 5).
Project information (for example, information of the “project name” field, the “target amount” field, and the “summary” field) of FIG. 5 is displayed in the areas A 411 a to A 411 b.
The “edit” buttons B411a to B411b are associated with project IDs (for example, project IDs “PR001” to “PR002”) related to the project information displayed in the areas A411a to A411b, respectively.

  When the “edit” button B 411 a is designated on the screen P 411, the client terminal 10 requests the server 30 to edit project information associated with the project ID related to the “edit” button B 411 a (hereinafter referred to as “ Send project edit request. As a result, screen P412 is displayed. Although not shown in FIG. 19, the screen P412 includes input fields F210a to F210b similar to the screen P210 of FIG. 12 and a “Done” button B210.

When the "reward management" button B410b is designated on the screen P410, the screen P420 of FIG. 20 is displayed.
The screen P420 includes an area A420, a "reward creation" button B420a, and a "selection" button B420b to B420c.
In the area A 420, reward information (for example, information of the “reward name” field and the “description” field of FIG. 6) is displayed.
The “select” buttons B420b to B420c are associated with the reward IDs (for example, the reward IDs “RW001” to “RW002”) related to the reward information displayed in the area A420.

When the “Reward Creation” button B 420 a is designated on the screen P 420, the screen P 421 is displayed.
The screen P421 includes an input field F421 and a “Done” button B421.
The input field F421 is an input field for inputting reward information necessary for creating a reward. The reward information necessary for creating a reward is, for example, a reward name, an image, an explanation, a ticket upper limit number, a ticket amount, and a scheduled date.

  When information is input to the input field F421 and the “Done” button B421 is specified on the screen P421, the client terminal 10 requests the server 30 to request for processing of reward creation (hereinafter referred to as “reward creation request”). Send.

When the “edit” button B 420 b is designated on the screen P 420, the screen P 422 of FIG. 21 is displayed.
The screen P422 includes an input field F422 and a "Done" button B422.
The input field F422 is an input field for editing the reward information.

  When information is input to the input field F 422 in the screen P 422 and the “Done” button B 422 is designated, the client terminal 10 requests the server 30 to edit the reward information (hereinafter referred to as “reward editing request”). Send.

When the “ticket management” button B 410 c is designated on the screen P 410 of FIG. 19, the screen P 430 of FIG. 22 is displayed.
The screen P430 includes an area A430 and "select" buttons B430a to B430b.
In the area A430, ticket information (for example, information of “ticket ID” field, “ticket owner ID” field, and “status” field of FIG. 8) and a ticket title (for example, reward ID “RE001” of FIG. 6) Information in the "reward name" field associated with the
The "select" buttons B430a to B430b are associated with the ticket IDs "TI001" to "TI002" displayed in the area A430, respectively.

When the “select” button B 420 a is designated on the screen P 430, the screen P 431 is displayed.
The screen P431 includes an area A431 and a “Done” button B431.
The area A 431 displays member information (for example, information in the “name” field and the “address” field) in FIG. 4 regarding the member to which the reward is to be sent.

  When the “Done” button B431 is designated on the screen P431 after the completion of the reward (for example, shipping of the product related to the project), the client terminal 10 causes the server 30 to select the ticket identified by the ticket ID “TI001”. Send a reward completion request to change the status.

(1-6) Flow of information processing (FIGS. 23 to 30)
A flow of information processing of the first embodiment will be described. The following information processing is performed by the CPU 12 of FIG. 2 executing a program of an application (for example, a browser) stored in the storage device 11 and the CPU 32 of FIG. 3 executing the program stored in the storage device 31. Is realized.
The client terminal 10 and the server 30 implement the following information processing by performing https communication via the communication network NW.

(1-6-1) Flow of Member Registration Processing (FIG. 23)
The process of member registration of the first embodiment will be described. FIG. 23 is a sequence diagram of member registration processing according to the first embodiment.

  The user of the client terminal 10 of FIG. 23 is a non-member user.

First, the client terminal 10 executes display of the top screen (S100).
Specifically, when the non-member user designates the URL for the top screen using the input unit 13, the CPU 12 displays the screen P <b> 100 of FIG. 11 on the display unit 14.

The client terminal 10 executes display of the member registration screen (S101).
Specifically, when a non-member user designates “Member registration” button B 100 a of screen P 100 in FIG. 11 using input unit 13, CPU 12 communicates with server 30 to display screen P 110 as display unit 14. Display on

The client terminal 10 executes a member request (S102).
Specifically, when a non-member user inputs information in the input field F110 of the screen P110 of FIG. 11 using the input unit 13 and designates the “Done” button B110, the CPU 12 requests a member registration request. create. The membership registration request includes the information entered in the input field F110.
Next, the CPU 12 transmits a member registration request to the server 30.

The server 30 executes database update (S300).
Specifically, the CPU 32 adds a new record to the member database of FIG. A new member ID is stored in the "member ID" field of the new record. Information included in the member registration request (name) in the “mail address” field, “password” field, “name” field, “image” field, “address” field, and “payment information” field of the new record , Email address, password, image, address, and payment information) are stored.

  By the above process, the process of member registration is completed.

(1-6-2) Flow of project creation processing (Figure 24)
The process of creating a project according to the first embodiment will be described. FIG. 24 is a sequence diagram of processing of project creation according to the first embodiment.

  The user of the client terminal 10 in FIG. 24 is a project creator.

  First, the client terminal 10 displays the top screen (S100) as in FIG.

The client terminal 10 executes display of a project creation screen (S110).
Specifically, when the project creator designates the "Create project" button B100b of the screen P100 of FIG. 11 using the input unit 13, the CPU 12 communicates with the server 30 to make the screen P210 of FIG. It is displayed on the display unit 14.

The client terminal 10 executes a project creation request (S111).
Specifically, when the project creator inputs information in the input fields F210a to F210b of the screen P210 of FIG. 12 using the input unit 13 and designates the “Done” button B210, the CPU 12 creates the project Create a request The project creation request includes the information input to the input fields F210a to F210b.
Next, the CPU 12 sends a project creation request to the server 30.

The server 30 executes examination of the project (S310).
Specifically, based on the requirement information stored in the storage device 31, the CPU 32 includes information (project owner's name, project owner's email address, project owner's profile, project name, project name) included in the project creation request. Examine whether the target amount, project outline, project start date, project end date, project image and project type) meet the project requirements.
"Requirement information" is information indicating requirements for registration as a project.
Note that the operator of the server 30 may examine whether part of the information included in the project creation request satisfies the project requirements. In this case, the CPU 32 examines part of the information included in the project creation request, and the operator examines the remaining part.

The server 30 executes database update (S311).
Specifically, when the information included in the project creation request satisfies the project requirements, the CPU 32 adds a new record to the project database of FIG. A new project ID and a new project owner ID are stored in the "project ID" field and the "project owner ID" field of the new record, respectively. A randomly determined password is stored in the "password" field of the new record. New record "mail address" field, "name" field, "profile" field, "project name" field, "target amount" field, "summary" field, "image" field, "start date" field, "end date" In the "field" and "type" fields, the information (email address, name, profile, project name, target amount, summary, image, start date, end date, and type) contained in the project creation request is Stored.

  By the above process, the process of project creation is completed.

(1-6-3) Flow of support processing (FIG. 25)
The support process of the first embodiment will be described. FIG. 25 is a sequence diagram of support processing according to the first embodiment.

  The user of the client terminal 10 of FIG. 25 is a member user (member ID “CU001” name “member 1”).

  First, the client terminal 10 displays the top screen (S100) as in FIG.

The client terminal 10 executes a login request (S120).
Specifically, when the member user designates the “login” button B100c of the screen P100 of FIG. 11 using the input unit 13 and inputs the member ID and the password, the CPU 12 sends a login request to the server 30. Send. The login request includes a member ID and a password.

The server 30 executes login authentication (S320).
Specifically, the CPU 32 collates the member ID and password included in the login request with the information in the “member ID” field and the “password” field of the member database of FIG. 4. If the member ID and password included in the login request match the information in the “member ID” field and the “password” field of the member database, the CPU 32 permits the login. On the other hand, when the member ID and password included in the login request do not match the information in the “member ID” field and the “password” field of the member database, the CPU 32 rejects the login.

When login is permitted, the client terminal 10 executes display of the member home screen (S121).
Specifically, the CPU 32 transmits, to the client terminal 10, a response for displaying a member home screen corresponding to the member ID included in the login request.
Next, the CPU 12 displays the screen P310 of FIG. 13 on the display unit 14 based on the response transmitted from the server 30.

The client terminal 10 executes display of a project selection screen (S122).
Specifically, when the member user designates the “support” button B 310 a of the screen P 310 in FIG. 13 using the input unit 13, the CPU 12 displays the screen P 311 on the display unit 14 by communicating with the server 30. Do. In the screen P311, project information on a selectable project (for example, a project not satisfying the refund condition (described later)) is displayed.

The client terminal 10 executes display of the reward selection screen (S123).
Specifically, when the member user designates the “select” button B 311 a on the screen P 311 of FIG. 13 using the input unit 13, the CPU 12 transmits a request to the server 30. This request includes the project ID "PR001" associated with the "select" button B311a.
Next, the CPU 32 transmits, to the client terminal 10, a response for displaying a project selection screen corresponding to the project ID “PR001” included in the request transmitted from the client terminal 10.
Next, the CPU 12 displays the screen P312 on the display unit 14 based on the response transmitted from the server 30. On the screen P312, reward information on selectable rewards (for example, information of a record in which the value of the “ticket distribution number” field in FIG. 6 is less than the value of the “ticket upper limit number” field) is displayed.

The client terminal 10 executes the support request (S124).
Specifically, when the member user inputs the number of tickets desired to be acquired into the input field F312 of the screen P312 of FIG. 13 using the input unit 13 and designates the “Done” button B312, the CPU 12 Creates a support request. The support request includes a reward ID and a quantity corresponding to the reward ID (information input to the input field F312).
Next, the CPU 12 transmits a support request to the server 30.

The server 30 executes payment confirmation (S321).
Specifically, the CPU 32 calculates the product of the quantity corresponding to the reward ID included in the support request and the ticket amount with reference to the reward database of FIG. This calculation result means the support amount of the member user.
Next, the CPU 32 refers to the member database of FIG. 4 to identify the server of the credit card company to which the payment request is to be sent, based on the payment information associated with the member ID included in the login request.
Next, the CPU 32 transmits a request for requesting confirmation of payment to a server such as a financial institution every predetermined time.

When the confirmation of payment is successful (S321-YES), the server 30 executes updating of the database (S322).
Specifically, the CPU 32 updates the “ticket distribution number” field of the reward database of FIG. 6 based on the information (reward ID and the quantity corresponding to the reward ID) included in the support request.
Next, the CPU 32 adds a new record to the support history database of FIG. A new support ID is stored in the "support ID" field of the new record. In the "support amount" field of the new record, a value indicating the support amount is stored. In the "support date" field of the new record, a value indicating the execution date of the support request (S124) is stored.
Next, the CPU 32 adds a new record to the ticket database of FIG. The support ID stored in the "support ID" field of the new record of the support history database is stored in the "support ID" field of the new record. The status code "STA1" is stored in the "status" field of the new record. By this, the status of the ticket becomes available.

  The above processing completes the support processing.

(1-6-4) Flow of processing of ticket use (FIG. 26)
The process of using a ticket according to the first embodiment will be described. FIG. 26 is a sequence diagram of ticket use processing according to the first embodiment.

  The user of the client terminal 10-1 in FIG. 26 is a ticket owner (member ID “CU001”). The user of the client terminal 10-2 is a project owner (project owner ID "PO001").

First, the client terminals 10-1 to 10-2 execute the display of the top screen (S100) as in FIG.
The client terminal 10-1 executes a login request (S120) as in FIG.
The server 30 executes login authentication (S320) in response to the login request (S120) as in FIG.
The client terminal 10-1 executes display (S121) of the member home screen as in the case of FIG.

The client terminal 10-1 executes display of the ticket list screen (S130).
Specifically, when the ticket owner designates the “owned ticket list” button B 310 b of the screen P 310 of FIG. 13 using the input unit 13, the CPU 12 communicates with the server 30 to display the screen P 320 of FIG. It is displayed on the display unit 14. On the screen P320, ticket information (for example, information of a record in which the ticket code “STA1” is stored in the “status” field of FIG. 8) related to the available ticket among the tickets owned by the ticket owner is displayed. .

The client terminal 10-1 executes display of the ticket use screen (S131).
Specifically, when the ticket owner designates the “use” button B 320 a of the screen P 320 in FIG. 14 using the input unit 13, the CPU 12 communicates with the server 30 to display the screen P 321 on the display unit 14. indicate. The screen P 321 displays information (for example, a project name, a reward name, and a ticket amount) related to the ticket ID associated with the “use” button B 320 a.

The client terminal 10-1 executes a ticket use request (S132).
Specifically, when the ticket owner designates the “YES” button B 321 a on the screen P 321 of FIG. 14, the CPU 12 transmits a ticket use request to the server 30. The ticket use request includes the ticket ID associated with the “use” button B 320 a designated on the screen P 320.
Next, the CPU 32 stores the status code "STA3" in the "status" field associated with the ticket ID included in the ticket use request transmitted from the client terminal 10-1 in the ticket database of FIG. As a result, the status of the ticket changes from available to in-use.

The client terminal 10-2 executes a login request (S133).
Specifically, when the member user designates the “login” button B100c of the screen P100 of FIG. 11 using the input unit 13 and inputs the project owner ID and the password, the CPU 12 requests the server 30 to issue a login request. Send to The login request includes the project owner ID and password.

The server 30 executes login authentication (S320) in response to the login request (S133).
Specifically, the CPU 32 collates the project owner ID and password included in the login request with the information of the “project owner ID” field and the “password” field of the project database of FIG. 5. If the project owner ID and password included in the login request match the information in the “project owner ID” field and the “password” field of the project database, the CPU 32 permits login. On the other hand, when the project owner ID and password included in the login request do not match the information in the “project owner ID” field and the “password” field of the project database, the CPU 32 rejects the login.

When login is permitted, the client terminal 10-2 executes display of the project owner home screen (S134).
Specifically, the CPU 32 transmits, to the client terminal 10-2, a response for displaying a project owner home screen corresponding to the project owner ID included in the login request.
Next, the CPU 12 displays the screen P410 of FIG. 19 on the display unit 14 based on the response transmitted from the server 30.

After S330, the client terminal 10-2 executes display of the ticket management screen (S135).
Specifically, when the project owner designates the “ticket management” button B410c of the screen P410 in FIG. 19 using the input unit 13, the CPU 12 communicates with the server 30 to display the screen P430 in FIG. Display on the part 14 On the screen P430, ticket information (for example, information on the ticket database of FIG. 8) regarding selectable tickets is displayed.

The client terminal 10-2 executes display of the reward completion screen (S136).
Specifically, when the project owner specifies the “select” button B 430 a on the screen P 430 in FIG. 22 using the input unit 13, the CPU 12 transmits a request to the server 30. This request includes the ticket ID associated with the “select” button B 430 a.
Next, the CPU 32 specifies a ticket owner ID (that is, a member ID for identifying the ticket owner) associated with the ticket ID included in the request transmitted from the client terminal 10-2 in the ticket database of FIG.
Next, the CPU 32 transmits, to the client terminal 10-2, a response for displaying a reward completion screen corresponding to the specified member ID.
The CPU 12 displays a screen P431 on the display unit 14 based on the response transmitted from the server 30. On the screen P431, member information (for example, information of “name” field and “address” field in FIG. 4) associated with the member ID specified by the CPU 32 is displayed.

The client terminal 10-2 executes a reward completion request (S136).
Specifically, after the project owner has sent the reward to the ticket owner, the CPU 12 selects the reward completion request from the server 30 when the “completion” button B 431 of the screen P 431 in FIG. 22 is designated using the input unit 13. Send to The reward completion request includes the ticket ID associated with the designated “select” button B 430 a.

The server 30 executes database update (S331).
Specifically, the CPU 32 stores the status code "STA4" in the "status" field associated with the ticket ID included in the reward completion request transmitted from the client terminal 10-2 in the ticket database of FIG. As a result, the status of the ticket changes from in use to used.

  The above process ends the ticket use process.

(1-6-5) Flow of ticket transfer process (1) (FIG. 27)
A first example of ticket transfer processing according to the first embodiment will be described. FIG. 27 is a sequence diagram of a first example of ticket transfer processing according to the first embodiment.

  The user of the client terminal 10-1 in FIG. 27 is a ticket owner (member ID “CU001”). The user of the client terminal 10-2 is a member user (member ID "CU 999").

First, the client terminals 10-1 to 10-2 execute the display of the top screen (S100) as in FIG.
The client terminals 10-1 to 10-2 execute the login request (S120) as in FIG.
The server 30 executes login authentication (S320) in response to the login request (S120) as in FIG.
The client terminals 10-1 to 10-2 execute the display of the member home screen (S121) as in FIG.
The client terminal 10-1 executes the display (S130) of the ticket list screen as in FIG.

The client terminal 10-1 executes display of the ticket transfer screen (S140).
Specifically, when the ticket owner designates the “assignment” button B 320 c of the screen P 320 in FIG. 14 using the input unit 13, the CPU 12 communicates with the server 30 to display the screen P 322 in FIG. Display on 14. It is necessary to transfer information associated with the ticket ID associated with the “assignment” button B 320 c (for example, project name, reward name, and ticket amount) and the ticket identified by the ticket ID on the screen P 322. URL is displayed.
When the ticket owner inputs the member ID of the assignee into the input field F 322 a of the screen P 322 using the input unit 13 and designates the “Done” button B 322, the CPU 12 transmits a ticket transfer request to the server 30. . The ticket transfer request includes the member ID “CU001” included in the login request, the ticket ID associated with the “transfer” button B 320 c, and the member ID “CU 999” input to the input field F 322 a.

The server 30 executes database update (S340).
Specifically, the CPU 32 stores the status code "STA2" in the "status" field associated with the ticket ID included in the ticket transfer request in the ticket database of FIG. As a result, the ticket status is in the state of being transferred.

The client terminal 10-2 executes display of a ticket reception screen (S142).
Specifically, when the assignee designates the “ticket reception” button B 310 c of the screen P 310 of FIG. 13 using the input unit 13, the CPU 12 displays the screen P 330 of FIG. 16 by communicating with the server 30. Display on the part 14 On the screen P330, the reception URL associated with the ticket ID included in the ticket transfer request is displayed in advance.

The client terminal 10-2 executes a ticket reception request (S143).
Specifically, the assignee designates the receiving URL displayed in the input field F330a of the screen P330 in FIG. 16 (for example, clicks the receiving URL previously displayed in the input field F330a or the input field F330a When the reception URL is input, the CPU 12 transmits a ticket reception request to the server 30. The ticket receipt request includes a receipt URL and a member ID "CU 999" for identifying the transferee.

The server 30 executes database update (S341).
Specifically, the CPU 32 specifies, in the ticket database of FIG. 8, a record including a ticket ID associated with the reception URL included in the ticket reception request transmitted from the client terminal 10-2.
Next, when the execution date of S143 has not passed the time limit indicated by the value of the “token due date” field of the specified record, the CPU 32 identifies a transferee in the “ticket owner” field of the record. Is stored. As a result, the ticket owner changes to a transferee (member ID "999").
Next, the CPU 32 stores the status code “STA1” in the “status” field of the specified record in the ticket database. By this, the status of the ticket becomes available.
Next, the CPU 32 adds a new record to the transfer history database (FIG. 10) associated with the ticket ID associated with the receiving URL. The "registration date" field of the new record stores a value indicating the execution date "2016/01/10" of S341. In the "assigner ID" field of the new record, a member ID "CU001" for identifying the assignee is stored. In the "transferee ID" field of the new record, a member ID "CU 999" for identifying the transferee is stored. Thereby, the transfer history of the ticket is updated.

As described above, the server 30 prevents the use of the transferred ticket from the time the ticket transfer request (S141) is made to the time the ticket receipt request (S143) is made.
In addition, the server 30 updates the ticket transfer history each time the ticket transfer process is performed.

  The ticket transfer process is completed by the above process.

(1-6-6) Flow of Ticket Transfer Processing (2) (FIG. 28)
A second example of ticket transfer processing according to the first embodiment will be described. FIG. 28 is a sequence diagram of a second example of ticket transfer processing according to the first embodiment.

  The user of the client terminal 10-1 in FIG. 28 is a ticket owner (member ID “CU001”). The user of the client terminal 10-2 is a non-member user.

First, the client terminal 10-1 executes display of the top screen (S100) as in FIG.
The client terminal 10-1 executes a login request (S120) as in FIG.
The server 30 executes login authentication (S320) in response to the login request (S120) as in FIG.
The client terminal 10-1 executes the display of the member home screen (S121) and the display of the ticket list screen (S130) as in FIGS. 25 and 26, respectively.

The client terminal 10-1 executes display (S150) of the ticket issuance screen.
Specifically, when the ticket owner designates the “issue” button B 320 e of the screen P 320 in FIG. 14 using the input unit 13, the CPU 12 communicates with the server 30 to display the screen P 340 in FIG. Display on 14.
Next, the ticket owner uses the input unit 13 to enter the name, e-mail address, and address of the transferee in the input field F340 of the screen P340, and when the “Done” button B340 is designated, the CPU 12 Send a ticket issue request to the server 30. The ticket issuance request includes the information input to the input field F340 and the ticket ID "TI001" associated with the "issue" button B320e.

The server 30 issues a paper ticket (S350).
Specifically, in the ticket database of FIG. 8, the CPU 32 prints a token associated with the ticket ID included in the ticket issue request, a project name associated with the ticket ID, and a reward name on a paper ticket. Do.
The operator of the server 30 sends the printed paper ticket to the information (the name and address of the assignee) of the input field F340 included in the ticket issuance request.

The server 30 executes database update (S351).
Specifically, in the ticket database of FIG. 8, the CPU 32 stores information indicating a new receipt token in the “token for receipt” field associated with the ticket ID included in the ticket issuance request, and Store a value indicating the new due date in the field.
Next, the CPU 32 stores the status code “STA2” in the “status” field associated with the ticket ID included in the ticket issuance request in the ticket database. As a result, the status of the ticket changes from available to being transferred.

The client terminal 10-2 executes display (S152) of the ticket reception screen.
Specifically, when the assignee accesses a predetermined URL using the input unit 13, the CPU 12 communicates with the server 30 to display the screen P 350 of FIG. 18 on the display unit 14.

The client terminal 10-2 executes a ticket reception request (S153).
Specifically, when the assignee inputs the receipt token “123456” printed on the paper ticket in the input field F 350 of the screen P 350 of FIG. 18 and designates the “member registration” button 350 a, , Send a ticket receipt request to the server 30. The ticket receipt request includes the receipt token input in the input field F350.

  The client terminal 10-2 executes display of a member registration screen (S101) and a member registration request (S102) as in FIG.

The server 30 executes database update (S352).
Specifically, the CPU 32 adds a new record to the member database of FIG. A new member ID "CU 999" is stored in the "member ID" field of the new record. Information included in the member registration request (name) in the “mail address” field, “password” field, “name” field, “image” field, “address” field, and “payment information” field of the new record , Email address, password, image, address, and payment information) are stored.
Next, in the ticket database shown in FIG. 8, the CPU 32 displays the member database in the “ticket owner” field associated with the ticket ID associated with the receipt token included in the ticket receipt request transmitted from the client terminal 10-2. The member ID "CU 999" included in the new record of is stored. As a result, the ticket owner changes to a transferee (member ID "999").
Next, the CPU 32 stores the status code “STA1” in the “status” field of the specified record in the ticket database. By this, the status of the ticket becomes available.
Next, the CPU 32 specifies the ticket ID associated with the receipt token in the ticket database.
Next, the CPU 32 adds a new record to the transfer history database (FIG. 10) associated with the identified ticket ID. A value indicating the execution date "2016/01/10" of S352 is stored in the "registration date" field of the new record. In the "assigner ID" field of the new record, a member ID "CU001" for identifying the assignee is stored. In the "transferee ID" field of the new record, a member ID "CU 999" for identifying the transferee is stored. Thereby, the transfer history of the ticket is updated.

As described above, the server 30 prevents the use of the transferred ticket from the time when the ticket issuance request (S151) is made until the time the ticket receipt request (S153) and the member registration request (S102) are made.
In addition, the server 30 updates the ticket transfer history each time the ticket transfer process is performed.

  The ticket transfer process is completed by the above process.

(1-6-7) Project editing process flow (FIG. 29)
The process of project editing according to the first embodiment will be described. FIG. 29 is a sequence diagram of project editing processing according to the first embodiment.

  The user of the client terminal 10 in FIG. 29 is a project owner (member ID “CU001”).

First, the client terminal 10 displays the top screen (S100) as in FIG.
The client terminal 10 executes a login request (S133) as in FIG.
The server 30 executes login authentication (S320) in response to the login request (S133), as in FIG.
The client terminal 10 displays the project owner home screen (S134) as in FIG.

The client terminal 10 executes display of the project management screen (S160).
Specifically, when the project owner designates the “project management” button B 410 a of the screen P 410 of FIG. 19 using the input unit 13, the CPU 12 communicates the server 30 to display the screen P 411 on the display unit 14. indicate. The screen P 411 displays project information on selectable projects (for example, “project name” field, “target amount” field, “summary” field associated with the project owner ID included in the login request in the project database in FIG. 5) , And "image" field information is displayed.

The client terminal 10 executes display of a project editing screen (S161).
Specifically, when the project owner designates the “edit” button B 411 a of the screen P 411 in FIG. 19 using the input unit 13, the CPU 12 displays the screen P 412 on the display unit 14 by communicating with the server 30. Do.

The client terminal 10 executes a project editing request (S162).
Specifically, when the project owner inputs predetermined information in an input field (not shown) of screen P 412 in FIG. 19 using input unit 13 and designates a “completion” button (not shown), The CPU 12 sends a project editing request to the server 30. The project edit request includes the project ID associated with the “edit” button B 411 a and the information input in the input field of the screen P 412.

The server 30 executes examination of the project (S360).
Specifically, based on the requirement information stored in the storage device 31, the CPU 32 examines whether the information included in the project editing request satisfies the project requirements.
"Requirement information" is information indicating requirements for registration as a project.
The operator of the server 30 may examine whether part of the information included in the project editing request satisfies the project requirements. In this case, the CPU 32 examines part of the information included in the project editing request, and the operator examines the remaining part.

The server 30 executes database update (S361).
Specifically, when the information included in the project edit request satisfies the project requirements, the CPU 32 associates the project ID included in the project edit request with the project ID based on the information included in the project edit request in the project database of FIG. Update selected records.

  The above process completes the project editing process.

(1-6-8) Flow of refund processing (FIG. 30)
The process of refunding according to the first embodiment will be described. FIG. 30 is a sequence diagram of refund processing according to the first embodiment.

  The user of the client terminal 10 in FIG. 30 is a ticket owner (member ID “CU001”).

First, the server 30 executes judgment (S370) of the refund condition of the project.
Specifically, the CPU 32 determines, for each fixed period, whether or not a refund condition is satisfied for the record of FIG. 5 in which the type code “AN” is stored in the “type” field. The refund condition is satisfied, for example, when the sum of the support amounts has not reached the value of the “target amount” field before the end date indicated by the value stored in the “end date” field.

If the refund condition is satisfied (S371: YES), the server 30 executes a refund notification (S372).
Specifically, the CPU 32 identifies a reward database (FIG. 8) associated with the project ID that identifies the project for which the refund condition is satisfied.
Next, the CPU 32 refers to the member database of FIG. 4 to identify the record associated with the member ID stored in the “ticket owner ID” field of the identified reward database.
Next, the CPU 32 sends an e-mail to the e-mail address stored in the “e-mail address” field of the specified record. This email indicates the URL of the web page for executing the refund request.

The client terminal 10 executes a login request (S170).
Specifically, when the ticket owner designates the URL indicated in the mail transmitted in S372 using the input unit 13, the CPU 12 transmits a login request to the server 30. The login request includes the member ID stored in the "ticket owner ID" field of the reward database identified in S372.

  The server 30 executes login authentication (S320) in response to the login request (S120) as in FIG.

The client terminal 10 executes display of the refund screen (S171).
Specifically, the CPU 12 communicates with the server 30 to display a web page for executing a refund request on the display unit 14.

The client terminal 10 executes a refund request (S172).
Specifically, when the ticket owner inputs account information of the refund destination (for example, information indicating a bank name, a branch name, an account number, and an account holder) on the refund screen using the input unit 13, the CPU 12 Sends a refund request to the server 30. The refund request includes refund account information and a member ID included in the login request.

The server 30 executes the refund (S373).
Specifically, the CPU 32 transfers the support amount to the account corresponding to the refund account information included in the refund request.

The server 30 executes database update (S374).
Specifically, in the project database of FIG. 5, the CPU 32 has a type code “FIN” indicating that the project is completed in the “type” field associated with the project ID identifying the project for which the refund condition is satisfied. Store.

  The above processing completes the refund processing.

(1-7) Summary The first embodiment will be summarized.

The CPU 32 (an example of an information processing apparatus) stores a member ID (an example of user identification information) for identifying a crowdfunding member and a project ID (an example of project identification information) for identifying a crowdfunding project. The storage device 31 is accessible.
In response to an instruction from the ticket owner (an example of the first user), the CPU 32 includes information indicating a support amount for the project in a member ID (an example of the first user identification information) identifying the ticket owner and the project ID. It associates and stores (for example, the process of S322).
Further, the CPU 32 associates and stores a ticket ID (an example of ticket identification information) for support to the project with a member ID identifying a ticket owner (for example, the process of S322).
In response to an instruction from the ticket owner, the association between the ticket ID and the member ID identifying the ticket owner is released, and a member ID identifying the member user designated by the ticket owner (an example of second user identification information) The ticket ID is associated with the ticket ID and stored (for example, the processing of S141 to S341).

In this way, members who support the project can transfer the right to receive compensation to other members.
Therefore, a member who supports the project can recover the support amount by performing a financial transaction when transferring to another member.
In addition, other members can secure the right to receive compensation for the project even after the acceptance of support for the project has ended.
That is, according to the present embodiment, in the crowdfunding, it is possible to realize n (n is an integer of 2 or more) secondary distribution of the right to receive the reward of the project. As a result, the convenience of crowdfunding becomes high, and the spread of crowdfunding is promoted.

  Further, the CPU 32 cancels the association between the ticket ID and the member ID (an example of the second user identification information) for identifying the member who has obtained the ticket according to the instruction of the member (an example of the second user) who has received the ticket. And store the ticket ID in association with the member ID (an example of the third user identification information) identifying the assignee (an example of the third user) designated by the member who has acquired the ticket (for example, S141 to S142) Processing of

  Furthermore, every time the CPU 32 executes a ticket transfer process, the ticket ID includes a member ID for identifying the transferor (an example of user identification information for identifying a user who has given an instruction) and a member ID for identifying the transferee. A combination with (an example of user identification information identifying a user specified by a user who has given an instruction) is associated and stored (for example, the process of S341).

This makes it possible to easily know the ticket distribution path.
The ticket distribution path is information useful to the project owner in identifying matters that are useful to the project (for example, the degree of interest in the project, the tendency of users who are interested in the project, etc.).

  Further, the CPU 32 issues a paper ticket on which a receiving token (an example of assignment information) necessary for the transferee (an example of a user other than the ticket owner) to obtain a ticket is printed in accordance with the instruction of the ticket owner. (For example, the process of S350).

Thereby, the distribution form of the ticket can be diversified.
For example, a ticket owner can sell paper tickets to non-member users of crowdfunding services through e-commerce and retailers that handle cash vouchers.
Further, the number of members of the crowdfunding service can be increased by guiding the nonmember users who have received the paper ticket to the membership registration for the crowdfunding service.

  Furthermore, when the receiving token printed on the paper ticket is input by the user who received the paper ticket (an example of the user other than the ticket owner), the CPU 32 associates the ticket ID with the member ID identifying the ticket owner. And store the ticket ID in association with the member identification information identifying the member who has input the receiving token (for example, the processing of S152 to S352).

  Further, the CPU 32 cancels the association between the ticket ID and the member ID identifying the ticket owner, and stores the ticket ID in association with the member ID identifying the member who has input the receiving token (for example, , S350 to S352), the ticket can not be used (for example, the process of S351).

  This makes it possible to prevent unauthorized use of the ticket from the issuance of the paper ticket to the transferee becoming the ticket owner.

(2) Other Modifications In the above-described embodiment, an example in which the information processing is realized by performing the https communication between the web browser installed in the client terminal 10 and the server 30 has been described. It is not limited to this.
For example, the information processing of the present embodiment can also be realized by performing https communication between the dedicated application (application other than the browser) installed in the client terminal 10 and the server 30.
Further, the information processing of the present embodiment may be realized only by a dedicated application. In this case, communication between the client terminal 10 and the server 30 is unnecessary.
Further, the communication method of the present embodiment is not limited to the https communication.

Although the above-mentioned embodiment demonstrated the example which memorize | stores a database in the memory | storage device 31 provided in the server 30, this embodiment is not limited to this.
For example, the information processing of the present embodiment is also applicable to the case where a database is stored in a storage device provided outside the server 30 (that is, the CPU 32 accesses the database via the communication interface 35).

  As mentioned above, although the embodiment of the present invention was described in detail, the scope of the present invention is not limited to the above-mentioned embodiment. Further, various modifications and changes can be made to the embodiment described above without departing from the spirit of the present invention. In addition, the above embodiments and modifications can be combined.

1: Information processing system 10: Client terminal 11: Storage device 12: CPU
13: input unit 14: display unit 15: communication interface 30: server 31: storage device 32: CPU
33: input unit 34: display unit 35: communication interface

Claims (6)

An information processing apparatus capable of accessing a storage device that stores user identification information identifying a user who is a member of a crowdfunding project and project identification information identifying a project of the crowdfunding,
First association means for associating and storing information indicating the amount of support for the project with the first user identification information identifying the first user and the project identification information in accordance with an instruction from the first user; ,
A second association unit that associates and stores ticket identification information identifying the right to receive a reward for support for the project with the first user identification information;
A second user identification information identifying a second user designated by the first user, canceling the association between the first user identification information and the ticket identification information in response to an instruction from the first user. Third association means for associating the ticket identification information with
An information processing apparatus comprising: The third association unit cancels the association between the second user identification information and the ticket identification information according to an instruction of the second user, and identifies a third user designated by the second user. Storing the ticket identification information in association with the third user identification information
An information processing apparatus according to claim 1. Each time the processing by the third association means is executed, user identification information identifying the user who gave the instruction to the ticket identification information, and user identification identifying the user specified by the user who gave the instruction The information processing apparatus further comprises fourth association means for associating and storing a combination with information;
The information processing apparatus according to claim 1. Transfer information necessary for a user other than the ticket owner to obtain the right to receive the reward is printed according to an instruction of a ticket owner who is a user identified by the user identification information associated with the ticket identification information. It further comprises issuing means for issuing a paper ticket,
The information processing apparatus according to any one of claims 1 to 3. When the transfer information printed on the paper ticket issued by the issuing means is input by a user other than the ticket owner, the user identification information for identifying the ticket owner and the ticket identification information are released from association. And the fifth association means for associating and storing the ticket identification information with user identification information identifying a user who has input the transfer information.
The information processing apparatus according to claim 4. After the fifth association means cancels the association between the user identification information identifying the ticket owner and the ticket identification information, the fifth association means identifies user identification information identifying the user who has input the transfer information. The system further comprises means for making the right to receive the reward unavailable until the ticket identification information is associated and stored.
The information processing apparatus according to claim 5 .

Images