Crowd funding management system

Abstract

To provide a crowd funding management system capable of activating support for crowd funding projects.SOLUTION: A card company server (crowd funding management system) 1 comprises: a project identification unit for identifying a crowd funding project suitable for a credit card member based on the credit card usage record of the credit card member; and a project providing unit for providing the credit card member with project information indicating the identified crowd funding project.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a crowdfunding management system that provides information on crowdfunding projects.

Background Art

[0002] Conventionally, various systems have been proposed for utilizing points given to users through the use of credit cards. For example, Patent Document 1 discloses an investment management system that cashes in points given to users and invests them in real estate investment crowdfunding.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the case of the above conventional investment management system, when each user selects a specific crowdfunding project from among a large number of crowdfunding projects, it does not have a function to assist in that selection.

[0005] The present invention has been made in view of such circumstances, and its main object is to provide a crowdfunding management system that can solve the above problems.

Means for Solving the Problems

[0006] To solve the above problems, a crowdfunding management system according to one aspect of the present invention includes a case identification unit that identifies a crowdfunding project suitable for the credit card member based on the usage record of the credit card of the credit card member, and a case providing unit that provides case information indicating the identified crowdfunding project to the credit card member.

[0007] In the above aspect, the case identification unit may identify a crowdfunding project suitable for the credit card member based on the goods or services purchased by using the credit card.

[0008] Also, in the above aspect, the case identification unit may identify a crowdfunding project supported by a credit card affiliated store with usage records of the credit card member as a crowdfunding project suitable for the credit card member, and the case providing unit may provide the case information including the affiliated store information indicating the credit card affiliated store with usage records to the credit card member.

[0009] Also, in the above aspect, the case identification unit may identify a crowdfunding project supported by a credit card affiliated store that the credit card member is likely to use as a crowdfunding project suitable for the credit card member, and the case providing unit may provide the case information including the affiliated store information indicating the identified credit card affiliated store to the credit card member.

[0010] Also, in the above aspect, the case identification unit may identify a credit card affiliated store that the credit card member is likely to use based on the attributes of the credit card member.

[0011] Also, in the above aspect, the case identification unit may identify a credit card affiliated store that the credit card member is likely to use based on the usage record of the credit card.

[0012] Further, in the above aspect, a support case acquisition unit that acquires support case information indicating a crowdfunding case supported by each credit card member, a second case identification unit that identifies a crowdfunding case suitable for each credit card affiliated store based on the acquired support case information, and a second case providing unit that provides second case information indicating the identified crowdfunding case to each of the credit affiliated stores may be further provided.

[0013] Further, in the above aspect, the second case identification unit may identify a crowdfunding case supported by a credit card member with usage record at a credit card affiliated store as a crowdfunding case suitable for the credit card affiliated store.

[0014] Further, in the above aspect, the second case identification unit may identify a crowdfunding case supported by a credit card member with high usage possibility at a credit card affiliated store as a crowdfunding case suitable for the credit card affiliated store.

[0015] Further, in the above aspect, the second case identification unit may identify a credit card member with high usage possibility at the credit card affiliated store based on the attributes of the credit card affiliated store.

[0016] Further, in the above aspect, the second case identification unit may identify a credit card member with high usage possibility at the credit card affiliated store based on the usage record at the credit card affiliated store.

[0017] Moreover, a crowdfunding management system according to another aspect of the present invention includes an attribute acquisition unit that acquires the attributes of a credit card member, a case identification unit that identifies a crowdfunding case suitable for the credit card member based on the acquired attributes, and a case providing unit that provides case information indicating the identified crowdfunding case to the credit card member.

Effect of the Invention

[0018] According to the present invention, it is possible to notify a credit card member of a crowdfunding project suitable for the member.

Brief Description of the Drawings

[0019]

Figure 1

Figure 2A

Figure 2B

Figure 2C

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Modes for Carrying Out the Invention

[0020] Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings. Note that each of the embodiments shown below is an example of a method and an apparatus for embodying the technical idea of the present invention, and the technical idea of the present invention is not limited to the following. The technical idea of the present invention can be variously modified within the technical scope described in the claims.

[0021] [System Configuration] FIG. 1 is a block diagram showing the configuration of the crowdfunding management system and its communication destinations according to the present embodiment. In the present embodiment, a card company server 1 operated by a credit card company functions as a crowdfunding management system. The user terminal 2 is a device provided on the credit card member (hereinafter simply referred to as "member") side, and is composed of a personal computer, a smartphone, or the like. The franchise terminal 3 is a device provided on the franchise side of the credit card, and is composed of a personal computer, a CAT (Credit Authorization Terminal), or the like.

[0022] The card company server 1, the user terminal 2, and the franchise terminal 3 can communicate with each other via the network 101. More specifically, the card company server 1 and the user terminal 2 communicate with each other via the Internet, and the card company server 1 and the franchise terminal 3 communicate with each other via the Internet or a dedicated line.

[0023] The card company server 1 is a computer including a control unit including a CPU, a RAM, and a ROM, and a storage unit, and each process described later is executed by this control unit. In addition, in the storage unit of the card company server 1, a project database (DB) 11A for storing information on crowdfunding projects, a member DB 11B for storing information on members, a franchise DB 11C for storing information on franchises, and a usage record DB 11D for storing information on the usage record of the members' credit cards are provided. Details of these databases will be described below.

[0024] (A) Project DB 11A FIG. 2A is a diagram showing an example of the layout of the project DB 11A. The project DB 11A has at least items such as an identifier (project ID) of a crowdfunding project, a name (project name), a category, a target amount, a total amount of donations received so far (supported amount), and a fundraising deadline. Among these, the project name, the target amount, and the fundraising deadline are information declared by the initiator of the crowdfunding project, and the project ID and the category are information determined by the credit card company server 1. Also, the total supported amount is the total amount of support by supporters and is information updated between the start of fundraising and the fundraising deadline.

[0025] (B) Member DB 11B FIG. 2B is a diagram showing an example of the layout of the member DB 11B. The member DB 11B has at least a member identifier (member ID) and name, and a project ID (supported project) of a crowdfunding project supported by the member. The supported project is stored when a member makes a decision to support a specific crowdfunding project. Note that information such as the member's address and email address is also stored in the member DB 11B as the member's contact information. The credit card company server 1 can provide various information to each member using this contact information. Also, information such as gender, age, and family composition is stored in the member DB 11B as various attributes other than the member's name and address.

[0026] When a supported project is registered in the member DB 11B, a donation is made to the supported project when the member's credit card is used. Specifically, the donation is made using points owned by the member (points given to each member according to the use of the credit card). Also, a donation may be made in an amount obtained by multiplying the usage amount of the credit card by a predetermined rate. In this case, the amount is collected from the member.

[0027] (C) Franchisee DB 11C Figure 2C is a diagram showing an example of the layout of the franchise store DB 11C. The franchise store DB 11C has at least a franchise store identifier (franchise store ID) and name (store name), and a project ID (supported project) of a crowdfunding project supported by the franchise store. The supported project is stored when the franchise store makes a decision to support a specific crowdfunding project. Note that the franchise store DB 11C also stores the address and email address of the franchise store as the contact information of the franchise store. The credit card company server 1 can provide various information to each franchise store using this contact information.

[0028] When a supported project is registered in the franchise store DB 11C, a donation is made to the supported project when a member uses a credit card at that franchise store. Specifically, a donation is made in an amount obtained by applying a predetermined rate to the sales amount by credit card at the franchise store. Also, it may be possible to target only the sales amount by the use of a specific member (for example, a member who supports the supported project). In these cases, the amount of the donation is collected from the franchise store.

[0029] (D) Usage record DB 11D The usage record DB 11D stores information such as the usage date and time, the franchise store used, the usage amount, and the purchase content (products / services) as the usage record of the member's credit card. Each time the credit card is used, the usage record is added to the usage record DB 11D.

[0030] [System operation] Next, the operation of the credit card company server 1 configured as described above will be described with reference to a flowchart. In this embodiment, a member providing process for providing information on a crowdfunding project suitable for each member to the member, and a franchise store providing process for providing information on a crowdfunding project suitable for each franchise store to the franchise store are executed. Hereinafter, the details of each process will be described.

[0031] (1) Member providing process The card company server 1 provides information on crowdfunding projects to each member in a plurality of ways. The following are examples of such methods.

[0032] (1-1) First member providing process In the first member providing process, based on the products and services purchased by the member using the credit card, a crowdfunding project suitable for the member is identified, and information on the project is provided to the member. This first member providing process is repeatedly executed at a predetermined timing, such as once a month.

[0033] Figure 3 is a flowchart showing the procedure of the first member providing process. The card company server 1 first obtains the credit card usage record from the usage record DB 11D (S101), and based on the purchase content (purchased products and services) included in the usage record, identifies a project suitable for the member who purchased it from among the crowdfunding projects stored in the project DB 11A (S102).

[0034] In step S102, various processes are performed. For example, it is assumed that a crowdfunding project related to nature protection is identified for a member who purchased outdoor supplies, or a crowdfunding project for the restoration of Kumamoto Castle is identified for a member who purchased a book on a Warring States general. Also, it is possible to assume that a crowdfunding project related to disaster recovery in other municipalities is identified for a member who made a hometown tax payment to a municipality affected by a disaster, or a crowdfunding project related to the maintenance of a children's park is identified for a member who made a payment to a kindergarten or nursery school. In this way, a crowdfunding project related to the purchased products and services will be identified.

[0035] Next, the card company server 1 outputs case information indicating the specified crowdfunding project to the member (S103). This output is executed according to the means of providing to the member. For example, when providing to the member by email, the card company server 1 uses the email address of the member stored in the member DB11B to send an email including the case information. Also, when providing to the member using the web, the card company server 1 issues a URL through which the case information can be viewed and notifies the member of the URL. Further, if providing to the member in paper form, the card company server 1 outputs the case information to a system for printing the paper form.

[0036] The case information includes, in addition to each information such as the case name, category, target amount, total amount of support, and fundraising deadline stored in the case DB11A, a URL for viewing the detailed content of the crowdfunding project (such as the donation target, return, and details of the proposer). The member can confirm the detailed content of the crowdfunding project by using this URL.

[0037] (1-2) Second member providing process In the second member providing process, a crowdfunding project suitable for the member is specified based on the member's attributes, and information regarding the project is provided to the member. This second member providing process is also repeatedly executed at a predetermined timing, similar to the first member providing process.

[0038] Figure 4 is a flowchart showing the procedure of the second member providing process. First, the card company server 1 acquires member information regarding the member from the member DB11B (S201), and based on the attributes of the member (such as address, age, gender, and family composition) included in the member information, specifies a project suitable for the member from among the crowdfunding projects stored in the case DB11A (S202).

[0039] In step S202, various processes are performed. For example, it is assumed that a crowdfunding project related to disaster reconstruction in a specific municipality is specified for members living in that municipality, or a crowdfunding project related to the maintenance of a children's park is specified for members with a family structure having young children. In this way, a crowdfunding project related to the attributes of members such as address and family structure will be specified.

[0040] Next, the card company server 1 outputs case information indicating the specified crowdfunding project to the member (S203). This output is executed according to the means of providing to the member, similar to the case of the first member providing process. Also, the content of the case information is the same as in the case of the first member providing process.

[0041] (1-3) Third member providing process In the third member providing process, a case suitable for a specific member is specified from among the crowdfunding projects supported by each franchise store, and information regarding that case is provided to the member. This third member providing process is also repeatedly executed at a predetermined timing, similar to the first member providing process.

[0042] FIG. 5 is a flowchart showing the procedure of the third member providing process. First, the card company server 1 extracts a case to be processed from among the crowdfunding projects stored in the case DB11A (S301). Next, the card company server 1 refers to the franchise store DB11C to specify the franchise stores that support the case to be processed (S302).

[0043] Next, the card company server 1 obtains the credit card usage record from the usage record DB11D (S303), and specifies the members who have a usage record at the franchise store specified in step S302 (S304).

[0044] In addition, although the card company server 1 has no usage record at the franchise store, it identifies members who are likely to use the franchise store in the future (S305). For example, members whose residence is close to the location of the franchise store, members whose age, gender, or family composition is the same or similar to that of members with usage records at the franchise store, etc., are identified as members with high usage potential based on the attributes of the members.

[0045] In step S305, members with high usage potential may be identified based on the usage record of the credit card. For example, members with usage records at other franchise stores that are similar in attributes (location, handled goods / services, etc.) to the franchise store may be identified as members with high usage potential at the franchise store.

[0046] Next, the card company server 1 identifies members who are likely to support the crowdfunding project to be processed, which was extracted in step S301, from among the members identified in steps S304 and S305 (S306). For example, it is determined whether the crowdfunding project is related to the goods / services purchased by each member using a credit card. If it is determined that there is a relationship, the member is identified as a member who is likely to support the crowdfunding project. Also, it is determined whether the crowdfunding project is related to the attributes of each member. If it is determined that there is a relationship, the member may be identified as a member who is likely to support the crowdfunding project. The determination of the presence or absence of the relevance between the purchase content or the member's attributes and the crowdfunding project can be made in the same manner as in the case of the first member-providing process or the second member-providing process.

[0047] Next, the card company server 1 outputs the project information indicating the crowdfunding project to be processed to the members identified in step S306 (S307). This output is executed according to the means of providing to the members, similar to the case of the first member-providing process. Also, the content of the project information is the same as in the case of the first member-providing process.

[0048] In the above-described third member provision process, the target of case information provision is narrowed down by identifying members with a high likelihood of support in step S306. However, without such narrowing, case information may be provided to all members with usage records and members with a high likelihood of usage.

[0049] Also, in the above-described third member provision process, first the affiliated store is identified (S302), and then members with usage records at that affiliated store and members with a high likelihood of usage are identified (S304 and S305). However, first the members may be identified, and then the affiliated stores where those members have usage records and the affiliated stores with a high likelihood of usage may be identified. As long as the members and the affiliated stores can be associated as a result, either procedure may be adopted.

[0050] In the above-described first to third member provision processes, specific case information is provided to specific members. As described above, various means of provision are envisioned. Hereinafter, an example will be given of the case where case information is provided via so-called web details that can be used to confirm usage details on a web browser by the third member provision process.

[0051] The member can access the credit card company server 1 using the user terminal 2 at a desired timing and refer to the web details. In the case of this embodiment, the web details include case information indicating a crowdfunding case suitable for the member.

[0052] FIG. 6 is a diagram showing an example of the display of web details. In these web details, the usage date and time, store name, purchase content, amount, etc. are displayed as in the case of conventional web details. On the other hand, information (recommended case) representing the crowdfunding case shown in the case information provided to the member is displayed. In this case, information representing the crowdfunding case supported by the affiliated store where usage occurred (the affiliated store where the member has a usage record) is displayed. Further, the web details display information (approval possibility) indicating whether or not to approve of the recommended case. URLs for outputting specific information are linked to these recommended cases and approval possibility as described later.

[0053] Also, in the example shown in FIG. 6, information regarding a crowdfunding project supported by a franchise store with a high availability for the member is also displayed. Specifically, below the message "The following stores also support crowdfunding projects", the store name of the franchise store with a high availability, information representing the crowdfunding project supported by the franchise store (recommended project), and the approval status for the recommended project are displayed.

[0054] When a member clicks on a recommended project in the web details, in addition to each piece of information stored in the project DB 11A such as the project name, category, target amount, total supported amount, and fundraising deadline, the donation target, return, and details of the proposer, etc. are displayed on the web browser. As a result, the member can confirm the details of the recommended project.

[0055] Also, as a result of considering the content of the recommended project, if the member decides to support the recommended project, the member clicks on "YES" in the approval status. In this case, information indicating that the support for the recommended project is agreed is sent from the user terminal 2 to the credit card company server 1. In this case, the credit card company server 1 stores the project ID of this recommended project as the supported project of the member in the member DB 11B. As a result, it becomes possible to execute the support for the recommended project by the member.

[0056] On the other hand, if the member decides not to support the recommended project, the member clicks on "NO" in the approval status. In this case, information indicating that the support for the recommended project was not agreed is sent from the user terminal 2 to the credit card company server 1. In this case, the credit card company server 1 stores information indicating that the member did not agree to support the recommended project. By using this information, when providing case information to the member thereafter, it becomes possible to take actions such as excluding the cases for which approval of support was not obtained.

[0057] (1-4) Fourth member provision process In the fourth member-providing process, when each member uses a credit card, information regarding a crowdfunding project suitable for the member is provided to the member. This fourth member-providing process is executed each time a member uses a credit card.

[0058] FIG. 7 is a flowchart showing the procedure of the fourth member-providing process. When a member uses a credit card at a specific franchise store, predetermined information such as the member ID is transmitted from the franchise store terminal 3 to the credit card company server 1, and a credit check (authorization) is executed at the credit card company server 1 using the information. If the use of the credit card is approved as a result, the credit card company server 1 acquires card usage information regarding this use (S401). This card usage information includes the member ID and the franchise store ID, etc.

[0059] Next, the credit card company server 1 refers to the franchise store DB11C to identify the crowdfunding projects supported by the franchise store used this time (S402). If there are no crowdfunding projects supported by the franchise store, the subsequent processing is not executed.

[0060] Next, the credit card company server 1 outputs project information indicating the identified crowdfunding project to the member (S403). This output is executed according to the usage mode of the credit card. For example, when a member uses a credit card at the storefront of a franchise store, the project information is transmitted from the credit card company server 1 to the franchise store terminal 3 provided at the storefront. In this case, the franchise store terminal 3 prints a usage statement including information such as the project name of the crowdfunding project shown in the project information. The member can know the crowdfunding projects supported by the franchise store by referring to the usage statement.

[0061] In addition, if a member uses a credit card at an online store operated by a franchisee, case information is sent from the card company server 1 to the web server that operates the online store. In this case, the web server transmits a usage detail including information such as the above-mentioned case name to the user terminal 2 operated by the member. As a result, the member can know the crowdfunding cases supported by the franchisee.

[0062] In the above fourth member provision process, only the supported cases of the franchisees used are notified to the members. In addition to this, for example, supported cases of other franchisees (franchisees with high usability for the member) having attributes similar to the franchisee may be notified to the members.

[0063] Through the above member provision processes, members can grasp crowdfunding cases suitable for themselves. Therefore, members can easily select the crowdfunding cases they support. As a result, donations for crowdfunding using points of credit cards etc. are promoted, and activation of support for each case can be expected.

[0064] In addition, according to the third member provision process, members can grasp crowdfunding cases supported by franchisees that the members have used and those that the members have no usage record of but have a high possibility of use. When the member uses a credit card at these franchisees, donations will be made to the crowdfunding case from both the member and the franchisee, resulting in stronger support.

[0065] (2) Franchisee Provision Process The card company server 1 provides information on crowdfunding cases to each franchisee by a plurality of methods. The methods are exemplified below.

[0066] (2-1) First Franchisee Provision Process In the first franchise store provision process, a case suitable for a specific franchise store is identified from among the crowdfunding cases supported by each member, and information regarding the case is provided to the relevant franchise store. This franchise store provision process is repeatedly executed at a predetermined timing, such as once a month.

[0067] Figure 8 is a flowchart showing the procedure of the fourth member provision process. First, the credit card company server 1 extracts a case to be processed from among the crowdfunding cases stored in the case DB 11A (S501). Next, the credit card company server 1 refers to the member DB 11B to identify the members who are supporting the case to be processed (S502).

[0068] Next, the credit card company server 1 acquires the credit card usage history from the usage history DB 11D (S503), and identifies the franchise stores where there is a usage history for the members identified in step S502 (S504).

[0069] In addition, the credit card company server 1 identifies franchise stores where, although there is no usage history for the relevant member, there is a high likelihood that the member will use them in the future (S505). For example, franchise stores with a high likelihood of use are identified based on the attributes of the franchise stores, such as franchise stores in a location close to the member's address, and franchise stores with attributes (location, handled goods and services, etc.) similar to those of the franchise stores where the member has a usage history.

[0070] In step S505, franchise stores with a high likelihood of use may be identified based on the credit card usage history at each franchise store. For example, franchise stores where there is a usage history for other members with attributes (age, gender, family composition, etc.) similar to those of the members who have a usage history at the relevant franchise store may be identified as franchise stores where the member has a high likelihood of use.

[0071] Next, the credit card company server 1 identifies, from among the affiliated stores identified in steps S504 and S505, the affiliated stores that are likely to support the crowdfunding project to be processed extracted in step S501 (S506). For example, it is determined whether or not the crowdfunding project is related to the products / services handled by each affiliated store or the location of each affiliated store, and if it is determined that there is a relationship, the affiliated store is identified as an affiliated store highly likely to support the crowdfunding project. In this case, it is conceivable that a crowdfunding project related to nature protection is determined to be related to an affiliated store handling outdoor supplies, or a crowdfunding project related to the maintenance of a children's park is determined to be related to an affiliated store having a store near the children's park.

[0072] Next, the credit card company server 1 outputs the project information indicating the crowdfunding project to be processed to the affiliated stores identified in step S506 (S507). This output is executed according to the means of providing to the affiliated stores. For example, when providing to an affiliated store by email, the credit card company server 1 uses the email address of the affiliated store stored in the affiliated store DB11C to send an email including the project information. Also, when providing to an affiliated store using the web, the credit card company server 1 issues a URL through which the project information can be viewed and notifies the affiliated store of the URL. Also, in the case of providing to an affiliated store in a paper medium, the credit card company server 1 outputs the project information to a system for printing the paper medium.

[0073] Similar to the case of the member provision process, in addition to each information such as the project name, category, target amount, total amount of support, and fundraising deadline stored in the project DB11A, the project information includes a URL for viewing the detailed content (donation target, return, details of the proposer, etc.) of the crowdfunding project. The affiliated store can confirm the detailed content of the crowdfunding project by using this URL.

[0074] In the above-described first franchisee-providing process, the target of providing case information is narrowed down by identifying franchisees with a high likelihood of support in step S506. However, instead of performing such narrowing, case information may be provided to all franchisees with usage records and those with a high likelihood of usage without performing such narrowing.

[0075] Also, in the above-described first franchisee-providing process, members are identified first (S502), and then franchisees with usage records and those with a high likelihood of usage for those members are identified (S504 and S505). However, franchisees may be identified first, and then members with usage records and those with a high likelihood of usage at those franchisees may be identified. As long as members and franchisees can be associated as a result, either procedure may be adopted.

[0076] In the above-described first member-providing process, specific case information is provided to specific franchisees. As described above, various means of providing it are conceivable. Hereinafter, the case where case information is provided via a sales information screen on which each franchisee displays credit card sales information will be exemplified.

[0077] The franchisee can access the card company server 1 using the franchisee terminal 3 at a desired timing and refer to the sales information screen. In the case of the present embodiment, the sales information screen includes case information indicating a crowdfunding case suitable for the franchisee.

[0078] FIG. 9 is a diagram showing an example of the display of the sales information screen. On this sales information screen, as in the case of the conventional sales information screen, sales records (member ID, amount, etc.) in the month to be processed are displayed. On the other hand, information (recommended case) representing the crowdfunding case shown in the case information provided to the franchisee is displayed. In this case, information representing the crowdfunding case supported by the member is displayed. Further, on this sales information screen, information (approval possibility) indicating whether or not to approve of the recommended case is displayed. URLs for outputting specific information are linked to these recommended cases and approval possibility as will be described later.

[0079] Also, in the example shown in FIG. 9, information regarding crowdfunding projects supported by members with a high likelihood of using the franchise store is also displayed. Specifically, below the message "Members with a high likelihood of using your store are supporting the following crowdfunding projects", information representing the crowdfunding projects (recommended projects) supported by members with a high likelihood of use, and the approval status for such recommended projects are displayed.

[0080] When a franchise store clicks on a recommended project in the sales information screen, in addition to each piece of information stored in the project DB11A such as the project name, category, target amount, total amount of support, and fundraising deadline, details such as the donation target, return, and details of the originator are displayed on the web browser. As a result, the franchise store can confirm the details of the recommended project.

[0081] Also, as a result of considering the content of the recommended project, if the franchise store decides to support the recommended project, the franchise store clicks on "YES" in the approval status. In this case, information indicating that the support for the recommended project has been agreed upon is sent from the franchise store terminal 3 to the credit card company server 1. In this case, the credit card company server 1 stores the project ID of this recommended project as the supported project of the franchise store in the franchise store DB11C. As a result, it becomes possible to execute the support for the recommended project by the franchise store.

[0082] On the other hand, if the franchise store decides not to support the recommended project, the franchise store clicks on "NO" in the approval status. In this case, information indicating that the support for the recommended project has not been agreed upon is sent from the franchise store terminal 3 to the credit card company server 1. In this case, the credit card company server 1 stores information indicating that the franchise store did not agree to support the recommended project. By using this information, when providing project information to the franchise store thereafter, it becomes possible to take actions such as excluding projects for which approval of support was not obtained.

[0083] (2-2) Second franchise store providing process In the second franchise store provision process, when each member uses a credit card, information regarding a crowdfunding project suitable for the franchise store where the card was used is provided to that franchise store. This second franchise store provision process is executed each time a member uses a credit card.

[0084] FIG. 10 is a flowchart showing the procedure of the second franchise store provision process. Similar to the case of the fourth member provision process described above, if the use of the credit card is approved as a result of a credit inquiry by the card company server 1, the card company server 1 acquires card usage information regarding this use (S601). This card usage information includes the member ID, the franchise store ID, and the like.

[0085] Next, the card company server 1 refers to the member DB11B and identifies the crowdfunding projects supported by the member who is using the credit card this time (S602). If there are no crowdfunding projects supported by the member, the subsequent processing is not executed.

[0086] Next, the card company server 1 outputs project information indicating the identified crowdfunding project to the franchise store (S603). This output is executed according to the usage pattern of the credit card. For example, when a member uses a credit card at the storefront of a franchise store, the card company server 1 transmits the project information to the franchise store terminal 3 provided at that storefront. In this case, the franchise store terminal 3 displays the project name and the like of the crowdfunding project shown in the project information on the display unit or prints it on a paper medium. As a result, the franchise store can know the crowdfunding projects supported by the member.

[0087] Also, if a member uses a credit card at the online store operated by the franchisee, case information is transmitted from the card company server 1 to the web server that operates the online store. In this case, the web server transmits information including the information such as the above-mentioned case name to the franchisee terminal 3. As a result, the franchisee can know the crowdfunding case supported by the member.

[0088] In the above second franchisee-provided process, only the support cases of the members who use the credit card this time are notified to the franchisee. In addition to that, for example, support cases of other members (members with high availability for the franchisee) whose attributes are similar to those of the member may be notified to the franchisee.

[0089] Through the above-mentioned franchisee-provided processes, the franchisee can grasp crowdfunding cases supported by members who have already had usage records at the store and members who have no usage records but have a high possibility of using the store as crowdfunding cases suitable for the franchisee. The franchisee's support for these crowdfunding cases is equivalent to the support for the crowdfunding cases supported by these members. Therefore, for the franchisee, it becomes possible to improve customer satisfaction and expect to promote the use of credit cards by members. Therefore, the franchisee will actively consider supporting crowdfunding cases, and as a result, the promotion of crowdfunding donations will be achieved.

[0090] (Other Embodiments) In the above-described embodiment, the content assumes a single credit card company, but it is also possible to assume multiple credit card companies. For example, for multiple credit card companies, a card company integration system that accumulates various information such as information on members and affiliated stores and usage records can be constructed. If this card company integration system provides these various information related to other companies to the card company server 1 of each credit card company, it is possible to realize the above-described embodiment assuming multiple credit card companies. Since an infrastructure service that can register various information of multiple credit card companies has already been realized, the above-described embodiment can also be realized assuming multiple credit card companies by using such an infrastructure service.

Explanation of Signs

[0091] 1 Card company server 11A Project DB 11B Member DB 11C Affiliated store DB 11D Usage record DB 2 User terminal 3 Affiliated store terminal 101 Network

Claims

1. A case identification unit that identifies a crowdfunding project suitable for the credit card member based on the credit card usage record of the credit card member, and a case providing unit that provides case information including the target amount and the fundraising period of the identified crowdfunding project to the credit card member A crowdfunding management system comprising:

2. An attribute acquisition unit that acquires the attributes of a credit card member, A case identification unit that identifies a crowdfunding project suitable for the credit card member based on the acquired attributes, and a case providing unit that provides case information including the target amount and the fundraising period of the identified crowdfunding project to the credit card member A crowdfunding management system comprising:

3. The case providing unit provides the case information together with the usage details indicating the credit card usage record within a predetermined period, The crowdfunding management system according to claim 1 or 2.

4. The case providing unit provides the case information for each usage detail, The crowdfunding management system according to claim 3.

5. A support case acquisition unit that acquires support case information indicating the crowdfunding projects supported by each credit card member, A second case identification unit that identifies a crowdfunding project suitable for each credit card franchise based on the acquired support case information, and a second case providing unit that provides second case information indicating the identified crowdfunding project to each credit card franchise Further comprising: The crowdfunding management system according to any one of claims 1 to 4.

6. The second case identification unit identifies a crowdfunding project supported by a credit card member with a usage record at a credit card franchise as a crowdfunding project suitable for the credit card franchise, The crowdfunding management system according to claim 5.

7. The second case identification unit identifies a crowdfunding project supported by a credit card member with a high likelihood of usage at a credit card franchise as a crowdfunding project suitable for the credit card franchise, The crowdfunding management system according to claim 5 or 6.

8. The second case specifying unit specifies credit card members who are highly likely to be available at the credit card affiliated store based on the attributes of the credit card affiliated store. The crowdfunding management system according to claim 7.

Images