Crowdfunding 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 about crowdfunding projects. [Background technology]

[0002] Various systems have been proposed for utilizing points given to users for using credit cards. For example, Patent Document 1 discloses an investment management system that converts points given to users into cash and invests them in crowdfunding for real estate investment. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6899006 Specification Summary of the Invention [Problem to be solved by the invention]

[0004] However, the conventional investment management systems described above do not have a function to assist each user in selecting a specific crowdfunding project from among a large number of crowdfunding projects.

[0005] The present invention has been made in consideration of the above circumstances, and its main purpose is to provide a crowdfunding management system that can solve the above problems. [Means for solving the problem]

[0006] In order to solve the above problems, one aspect of the crowdfunding management system of the present invention comprises a project identification unit that identifies crowdfunding projects suitable for a credit card member based on the credit card member's credit card usage history, and a project provision unit that provides the credit card member with project information indicating the identified crowdfunding projects.

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

[0008] In addition, in the above aspect, the project identification unit may identify a crowdfunding project supported by a credit card affiliated store that the credit card member has a history of using as a crowdfunding project suitable for the credit card member, and the project provision unit may provide the project information to the credit card member, including affiliated store information indicating the credit card affiliated store that the credit card member has a history of using.

[0009] In addition, in the above aspect, the project identification unit may identify a crowdfunding project supported by a credit card member that is likely to be used by the credit card member as a crowdfunding project suitable for the credit card member, and the project provision unit may provide the project information to the credit card member, including member store information indicating the identified credit card member.

[0010] In the above aspect, the case identification unit may identify a credit card affiliated store that is likely to be used by the credit card member based on the attributes of the credit card member.

[0011] In the above aspect, the case identification unit may identify credit card affiliated stores that are likely to be used by the credit card member based on the credit card usage history.

[0012] In addition, in the above aspect, the system may further include a support project acquisition unit that acquires support project information indicating the crowdfunding projects supported by each credit card member, a second project identification unit that identifies a crowdfunding project suitable for each credit card member store based on the acquired support project information, and a second project provision unit that provides each credit card member store with second project information indicating the identified crowdfunding project.

[0013] In addition, in the above aspect, the second project identification unit may identify a crowdfunding project supported by a credit card member who has a history of use at the credit card member store as a crowdfunding project suitable for the credit card member store.

[0014] In addition, in the above aspect, the second project identification unit may identify a crowdfunding project supported by a credit card member that is likely to be used at a credit card affiliated store as a crowdfunding project suitable for the credit card affiliated store.

[0015] In addition, in the above aspect, the second case identification unit may identify a credit card member who is likely to be able to use the credit card member store based on attributes of the credit card member store.

[0016] In the above aspect, the second case identifying unit may identify a credit card member who is likely to use the credit card member store based on a usage record at the credit card member store.

[0017] In addition, another aspect of the crowdfunding management system of the present invention includes an attribute acquisition unit that acquires attributes of credit card members, a project identification unit that identifies crowdfunding projects suitable for the credit card members based on the acquired attributes, and a project provision unit that provides project information indicating the identified crowdfunding projects to the credit card members. [Effects of the Invention]

[0018] According to the present invention, it is possible to inform credit card members of crowdfunding projects that are suitable for them. [Brief explanation of the drawings]

[0019] [Figure 1] FIG. 1 is a block diagram showing the configuration of a crowdfunding management system and its communication destinations. [Figure 2A] FIG. 4 is a diagram showing an example of the layout of a case database. [Figure 2B] FIG. 10 is a diagram showing an example of the layout of a membership database. [Figure 2C] FIG. 10 is a diagram showing an example of the layout of an affiliated store database. [Figure 3] 10 is a flowchart showing the procedure of a first member provision process. [Figure 4] 10 is a flowchart showing the procedure of a second member provision process. [Figure 5] 10 is a flowchart showing the procedure of a third member provision process. [Figure 6] FIG. 10 is a diagram showing an example of a web statement display. [Figure 7] 10 is a flowchart showing the procedure of a fourth member providing process. [Figure 8] 10 is a flowchart showing the procedure of a first affiliated store providing process. [Figure 9] FIG. 10 is a diagram showing an example of a sales information screen. [Figure 10] 10 is a flowchart showing the procedure of a second affiliated store providing process. DETAILED DESCRIPTION OF THE INVENTION

[0020] Preferred embodiments of the present invention will be described below with reference to the drawings. Note that the following embodiments are merely examples of methods and devices for embodying the technical concept of the present invention, and the technical concept of the present invention is not limited to the following. Various modifications can be made to the technical concept of the present invention within the technical scope described in the claims.

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

[0022] The card company server 1, the user terminal 2, and the affiliated store terminal 3 can communicate with each other via a 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 affiliated store terminal 3 communicate with each other via the Internet or a dedicated line.

[0023] The card company server 1 is a computer equipped with a control unit including a CPU, RAM, and ROM, and a storage unit, and the control unit executes the various processes described below. The storage unit of the card company server 1 also includes a project database (DB) 11A that stores information about crowdfunding projects, a member DB 11B that stores information about members, an affiliated store DB 11C that stores information about affiliated stores, and a usage history DB 11D that stores information about members' credit card usage histories. Each of these databases will be described in detail below.

[0024] (A) Matter DB11A 2A is a diagram showing an example of the layout of the project DB 11A. The project DB 11A has at least the following fields: a crowdfunding project identifier (project ID), name (project name), category, target amount, total donations made to date (support amount), and fundraising deadline. Of these, the project name, target amount, and fundraising deadline are information declared by the crowdfunding project initiator, while the project ID and category are information determined by the card company server 1. The total support amount is the total amount of support provided by supporters, and is information that is updated between the start of fundraising and the fundraising deadline.

[0025] (B) Member DB11B FIG. 2B is a diagram showing an example of the layout of member DB 11B. Member DB 11B contains at least the member's identifier (member ID) and name, as well as the project ID (supported project) of the crowdfunding project that the member is supporting. A supported project is stored when a member decides to support a specific crowdfunding project. Member DB 11B also stores information such as the member's address and email address as contact information for the member. The card company server 1 can use this contact information to provide various information to each member. In addition to the member's name and address, member DB 11B also stores information such as gender, age, and family composition as various attributes.

[0026] If a support project is registered in the member DB 11B, a donation is made to that support project when the member uses their credit card. Specifically, the donation is made using points owned by the member (points awarded to each member when they use their credit card). Alternatively, a donation may be made in the amount calculated by multiplying the amount of credit card usage by a specified rate. In this case, the amount is collected from the member.

[0027] (C) Member store DB11C FIG. 2C is a diagram showing an example of the layout of the affiliated store DB 11C. The affiliated store DB 11C contains at least the identifier (affiliated store ID) and name (store name) of the affiliated store, as well as the project ID (supported project) of the crowdfunding project that the affiliated store is supporting. A supported project is stored when a member store decides to support a specific crowdfunding project. The affiliated store DB 11C also stores the address, email address, etc. of the member store as contact information for the member store. The card company server 1 can use this contact information to provide various information to each member store.

[0028] If a support project is registered in the member store DB 11C, a donation is made to that support project when a member uses their credit card at that member store. Specifically, a donation is made in an amount calculated based on a predetermined percentage of the sales amount made by credit card at that member store. It may also be possible to limit the donation to sales made by a specific member (for example, a member who is supporting the support project). In these cases, the amount to be donated is collected from the member store.

[0029] (D) Usage history DB11D The usage history DB11D stores information on the member's credit card usage history, such as the date and time of use, the affiliated store used, the amount used, and the purchase details (goods and services). Each time the credit card is used, a usage history is added to the usage history DB11D.

[0030] [System Operation] Next, the operation of the card company server 1 configured as described above will be explained with reference to a flowchart. In this embodiment, a member provision process is executed to provide each member with information about crowdfunding projects suitable for that member, and an affiliated store provision process is executed to provide each affiliated store with information about crowdfunding projects suitable for that member. Each process will be explained in detail below.

[0031] (1) Membership provision processing The card company server 1 provides information about the crowdfunding project to each member in a number of ways. Examples of these methods are given below.

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

[0033] 3 is a flowchart showing the procedure for the first member provision process. The card company server 1 first acquires the credit card usage history from the usage history DB 11D (S101), and then, based on the purchase details (purchased goods and services) included in the usage history, identifies a project suitable for the member who purchased the project from among the crowdfunding projects stored in the project DB 11A (S102).

[0034] Various processes are performed in step S102. For example, crowdfunding projects related to nature conservation may be identified for a member who purchased outdoor equipment, or crowdfunding projects for the restoration of Kumamoto Castle may be identified for a member who purchased a book on Sengoku warlords. It is also possible to identify crowdfunding projects related to disaster recovery in other municipalities for a member who made hometown tax donations to a municipality that suffered a disaster, or crowdfunding projects related to the development of a children's park for a member who made payments to a kindergarten or nursery school. In this way, crowdfunding projects related to the purchased product or service are identified.

[0035] Next, the card company server 1 outputs project information indicating the identified crowdfunding project to the member (S103). This output is performed depending on the means of providing the project to the member. For example, if the project information is to be provided to the member by email, the card company server 1 sends an email containing the project information using the member's email address stored in the member DB 11B. If the project information is to be provided to the member via the web, the card company server 1 issues a URL at which the project information can be viewed and notifies the member of that URL. If the project information is to be provided to the member on paper, the card company server 1 outputs the project information to a system for printing the paper medium.

[0036] The project information includes information stored in the project DB 11A, such as the project name, category, target amount, total support amount, and collection deadline, as well as a URL for viewing detailed information about the crowdfunding project (donation targets, returns, details about the initiator, etc.). Members can use this URL to check the detailed information about the crowdfunding project.

[0037] (1-2) Secondary member provision processing In the second member provision process, a crowdfunding project suitable for the member is identified based on the member's attributes, and information about that project is provided to the member. This second member provision process, like the first member provision process, is also executed repeatedly at a predetermined timing.

[0038] 4 is a flowchart showing the procedure for the second member provision process. The card company server 1 first acquires member information about the member from the member DB 11B (S201), and then identifies a project suitable for the member from among the crowdfunding projects stored in the project DB 11A based on the member's attributes (address, age, gender, family structure, etc.) included in the member information (S202).

[0039] Various processes are performed in step S202. For example, crowdfunding projects related to disaster recovery in a specific city or town may be identified for members who live in that city or town, or crowdfunding projects related to the development of a children's park may be identified for members with families that have young children. In this way, crowdfunding projects related to member attributes such as address and family structure are identified.

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

[0041] (1-3) Third-party member provision processing In the third member provision process, a project suitable for a specific member is identified from among the crowdfunding projects supported by each member store, and information about that project is provided to that member. This third member provision process, like the first member provision process, is also executed repeatedly at a predetermined timing.

[0042] 5 is a flowchart showing the steps of the third member provision process. First, the card company server 1 extracts the project to be processed from the crowdfunding projects stored in the project DB 11A (S301). Next, the card company server 1 refers to the affiliated store DB 11C to identify the affiliated store supporting the project to be processed (S302).

[0043] Next, the card company server 1 acquires the credit card usage history from the usage history DB 11D (S303), and identifies members who have a usage history at the affiliated store identified in step S302 (S304).

[0044] In addition, the card company server 1 identifies members who have no history of use at the affiliated store but who are likely to use the affiliated store in the future (S305). For example, members who are likely to use the store in the future are identified based on their attributes, such as members whose addresses are close to the location of the affiliated store, or members whose age, gender, or family structure is the same or similar to that of members who have a history of use at the affiliated store.

[0045] In step S305, members who have a high probability of using their credit card may be identified based on their credit card usage history. For example, members who have a history of using their credit card at other affiliated stores that have similar attributes (location, products and services offered, etc.) to the affiliated store may be identified as members who have a high probability of using their credit card at the affiliated store.

[0046] Next, the card company server 1 identifies members who are likely to support the crowdfunding project extracted in step S301 from among the members identified in steps S304 and S305 (S306). For example, the card company server 1 determines whether the crowdfunding project is related to the products or services purchased by each member using their credit card, and if it determines that there is a relationship, identifies the member as a member who is likely to support the crowdfunding project. Alternatively, the card company server 1 may determine whether the crowdfunding project is related to the attributes of each member, and if it determines that there is a relationship, identifies the member as a member who is likely to support the crowdfunding project. The determination of whether the purchase details or member attributes are related to the crowdfunding project can be performed in the same manner as in the first member provision process or the second member provision process.

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

[0048] In the above-mentioned third member provision process, the target recipients of the project information are narrowed down by identifying members who are likely to provide support in step S306, but it is also possible to provide project information to all members who have a history of use and members who are likely to use the project information without narrowing down the target recipients in this way.

[0049] Furthermore, in the above-described third member provision process, the affiliated store is first identified (S302), and then members who have a history of use at that affiliated store and members who are likely to be of use there are identified (S304 and S305), but it is also possible to identify the member first, and then identify affiliated stores that the member has a history of use at and members who are likely to be of use there. Either procedure may be adopted as long as it is possible to associate the member with the affiliated store as a result.

[0050] In the above-described first to third member provision processes, specific project information is provided to specific members. As mentioned above, various means of provision are conceivable. Below, we will explain an example of a case where project information is provided via so-called web details, which allow users to check usage details on a web browser, in the third member provision process.

[0051] Members can access the card company server 1 using the user terminal 2 at any time they wish and view their online statement. In this embodiment, the online statement includes project information indicating crowdfunding projects suitable for the member.

[0052] FIG. 6 is a diagram showing an example of a web statement display. This web statement displays the date and time of purchase, store name, purchase details, amount, etc., as with conventional web statements, but also displays information about crowdfunding projects (recommended projects) shown in the project information provided to the member. In this case, information about crowdfunding projects supported by the affiliated store used (affiliated store with which the member has a history of use) is displayed. Furthermore, this web statement displays information indicating whether or not the member supports the recommended project (support / disagreement). These recommended projects and support / disagreement are linked to URLs for outputting specific information, as will be described later.

[0053] In addition, in the example shown in Figure 6, information about crowdfunding projects supported by affiliated stores that are likely to be of use to the member is also displayed. Specifically, below the message "The following stores are also supporting crowdfunding projects," the names of affiliated stores that are likely to be of use to the member, information about the crowdfunding projects that the affiliated stores are supporting (recommended projects), and whether or not the member supports the recommended projects are displayed.

[0054] When a member clicks on a recommended project in the web statement, the information stored in the project DB 11A, such as the project name, category, target amount, total support amount, and collection deadline, as well as details of the donation target, return, and initiator, are displayed on the web browser. This allows the member to check the details of the recommended project.

[0055] Furthermore, if the member decides to support the recommended case after considering the contents of the recommended case, the member clicks "YES" in the approval / disapproval section. In this case, information indicating that the member has agreed to support the recommended case is sent from the user terminal 2 to the card company server 1. In this case, the card company server 1 stores the case ID of this recommended case as the member's support case in the member DB 11B. This allows the member to support the recommended case.

[0056] On the other hand, if the member decides not to support the recommended project, the member clicks "NO" in the approval / disapproval section. In this case, information indicating that the member did not agree to support the recommended project is sent from the user terminal 2 to the card company server 1. In this case, the card company server 1 stores information indicating that the member did not agree to support the recommended project. By using this information, when project information is subsequently provided to the member, it becomes possible to take measures such as removing projects for which consent to support was not obtained.

[0057] (1-4) 4th Membership Provision Processing In the fourth member provision process, when each member uses a credit card, information about crowdfunding projects suitable for that member is provided to that member. This fourth member provision process is executed each time a member uses a credit card.

[0058] 7 is a flowchart showing the procedure for the fourth member provision process. When a member uses a credit card at a specific affiliated store, predetermined information such as a member ID is sent from the affiliated store terminal 3 to the card company server 1, and the card company server 1 uses this information to perform a credit inquiry (authorization). If the credit card use is approved as a result, the card company server 1 obtains card use information related to this use (S401). This card use information includes the member ID, affiliated store ID, etc.

[0059] Next, the card company server 1 refers to the member store DB 11C and identifies the crowdfunding project supported by the member store used this time (S402). Note that if there is no crowdfunding project supported by the member store, the subsequent processing will not be executed.

[0060] Next, the card company server 1 outputs project information indicating the identified crowdfunding project to the member (S403). This output is performed depending on the usage pattern of the credit card. For example, when a member uses a credit card at an affiliated store, the project information is sent from the card company server 1 to the affiliated store terminal 3 installed at the store. In this case, the affiliated store terminal 3 prints out a statement of usage including information such as the project name of the crowdfunding project indicated in the statement of usage. By referring to the statement of usage, the member can find out which crowdfunding projects the affiliated store is supporting.

[0061] Furthermore, when a member uses a credit card at an online shop operated by a member store, project information is sent from the card company server 1 to the web server that operates the online shop. In this case, the web server sends a statement of use including information such as the project name to the user terminal 2 operated by the member. This allows the member to know which crowdfunding projects the member store is supporting.

[0062] In the above-mentioned fourth member provision process, only the support requests of the affiliated store that was used are notified to the member, but in addition, the member may also be notified of support requests of other affiliated stores that have similar attributes to the affiliated store (affiliated stores that the member is likely to use).

[0063] The above member provision process allows members to understand which crowdfunding projects are best suited to them. This allows members to easily select which crowdfunding projects they want to support. As a result, crowdfunding donations using credit card points, etc., are encouraged, and it is expected that support for each project will be boosted.

[0064] Furthermore, with the third member provision process, members can identify crowdfunding projects supported by affiliated stores they have used in the past and affiliated stores they have not used in the past but have a high possibility of using. When the member uses his / her credit card at these affiliated stores, both the member and the affiliated store will make a donation to the crowdfunding project, providing even stronger support.

[0065] (2) Processing provided by affiliated stores The card company server 1 provides information about the crowdfunding project to each affiliated store in a number of ways, examples of which are given below.

[0066] (2-1) Processing provided by the first affiliated store In the first affiliated store provision process, a project suitable for a specific affiliated store is identified from among the crowdfunding projects supported by each member, and information about that project is provided to the affiliated store. This affiliated store provision process is executed repeatedly at a predetermined time, such as once a month.

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

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

[0069] In addition, the card company server 1 identifies affiliated stores that the member has not used in the past but that are likely to be used by the member in the future (S505). For example, affiliated stores that are likely to be used in the future are identified based on the attributes of the affiliated stores, such as affiliated stores located near the member's address, or affiliated stores with similar attributes (location, products and services offered, etc.) to affiliated stores that the member has used in the past.

[0070] In step S505, a merchant with a high probability of use may be identified based on the credit card usage history at each merchant. For example, a merchant that has a usage history with other members who have similar attributes (age, gender, family structure, etc.) to a member who has a usage history at the merchant may be identified as a merchant that the member is likely to use.

[0071] Next, the card company server 1 identifies, from among the member stores identified in steps S504 and S505, member stores that are likely to support the crowdfunding project extracted in step S501 (S506). For example, it determines whether the crowdfunding project is related to the products and services offered by each member store or the location of each member store, and if it determines that there is a relationship, it identifies the member store as one that is likely to support the crowdfunding project. In this case, it is possible that a crowdfunding project related to nature conservation would be determined to be related to a member store that sells outdoor equipment, or a crowdfunding project related to the development of a children's park would be determined to be related to a member store that has a store near the children's park.

[0072] Next, the card company server 1 outputs project information indicating the crowdfunding project to be processed to the affiliated store identified in step S506 (S507). This output is performed depending on the means of providing the project to the affiliated store. For example, if the project information is to be provided to the affiliated store by email, the card company server 1 sends an email containing the project information using the email address of the affiliated store stored in the affiliated store DB 11C. If the project information is to be provided to the affiliated store via the web, the card company server 1 issues a URL at which the project information can be viewed and notifies the affiliated store of that URL. If the project information is to be provided to the affiliated store on paper, the card company server 1 outputs the project information to a system for printing the paper medium.

[0073] As with the member provision process, the project information includes information stored in the project DB 11A, such as the project name, category, target amount, total support amount, and collection deadline, as well as a URL for viewing the detailed content of the crowdfunding project (donation target, return, details of the initiator, etc.). Member stores can use this URL to check the detailed content of the crowdfunding project.

[0074] In the above-mentioned first affiliated store provision process, the target of provision of project information is narrowed down by identifying affiliated stores that are likely to provide support in step S506, but it is also possible to provide project information to all affiliated stores that have a history of use and affiliated stores that are likely to be used without performing such narrowing down.

[0075] Furthermore, in the above-described first affiliated store provision process, the member is first identified (S502), and then the affiliated stores with which the member has a history of use and the affiliated stores with high potential for use are identified (S504 and S505). However, it is also possible to identify the affiliated store first, and then identify the members with a history of use at that affiliated store and the members with high potential for use. Either procedure may be adopted as long as it is possible to associate the member with the affiliated store as a result.

[0076] In the first member provision process, specific project information is provided to a specific affiliated store. As mentioned above, various means of provision are conceivable. Below, we will explain an example in which project information is provided via a sales information screen that displays credit card sales information at each affiliated store.

[0077] The affiliated store can access the card company server 1 at any time using the affiliated store terminal 3 and refer to the sales information screen. In this embodiment, this sales information screen includes project information that indicates crowdfunding projects that are suitable for the affiliated store.

[0078] FIG. 9 is a diagram showing an example of a sales information screen. As with conventional sales information screens, this sales information screen displays actual sales (member ID, amount, etc.) for the month being processed, while also displaying information representing crowdfunding projects (recommended projects) shown in the project information provided to affiliated stores. In this case, information representing crowdfunding projects supported by the member is displayed. Furthermore, this sales information screen displays information indicating whether or not the member supports the recommended project (approval / non-approval). These recommended projects and approval / non-approval information are linked to URLs for outputting specific information, as will be described later.

[0079] In addition, in the example shown in Figure 9, information about crowdfunding projects supported by members who are likely to use the affiliated store is also displayed. Specifically, below the message "Members who are likely to use your store are supporting the following crowdfunding projects," information about crowdfunding projects supported by members who are likely to use the store (recommended projects) and whether or not you support the recommended projects is displayed.

[0080] When a member store clicks on a recommended project on the sales information screen, the information stored in the project DB 11A, such as the project name, category, target amount, total support amount, and collection deadline, as well as details of the donation target, return, and initiator, are displayed on the web browser. This allows the member store to check the details of the recommended project.

[0081] Furthermore, if the affiliated store decides to support the recommended project after considering the content of the recommended project, the affiliated store clicks "YES" in the approval / disapproval section. In this case, information indicating that support for the recommended project has been agreed to is sent from the affiliated store terminal 3 to the card company server 1. In this case, the card company server 1 stores the project ID of this recommended project as a support project for that affiliated store in the affiliated store DB 11C. This enables the affiliated store to support the recommended project.

[0082] On the other hand, if the affiliated store decides not to support the recommended project, the affiliated store clicks "NO" in the approval / disapproval section. In this case, information indicating that the affiliated store did not agree to support the recommended project is sent from the affiliated store terminal 3 to the card company server 1. In this case, the card company server 1 stores information indicating that the affiliated store did not agree to support the recommended project. By using this information, when providing project information to the affiliated store in the future, it becomes possible to take measures such as removing projects for which consent to support was not obtained.

[0083] (2-2) Processing provided by the second affiliated store In the second affiliated store provision process, when a member uses a credit card, information about a crowdfunding project suitable for the affiliated store is provided to the affiliated store. This second affiliated store provision process is executed each time a member uses a credit card.

[0084] 10 is a flowchart showing the procedure for the second affiliated store provision process. As in the fourth member provision process described above, if the credit card use is approved as a result of the credit inquiry by the card company server 1, the card company server 1 acquires card usage information related to this use (S601). This card usage information includes the member ID, affiliated store ID, etc.

[0085] Next, the card company server 1 refers to the member DB 11B and identifies the crowdfunding project that the member who will be using the credit card this time is supporting (S602). Note that if there is no crowdfunding project that the member is supporting, the subsequent processing will not be executed.

[0086] Next, the card company server 1 outputs project information indicating the identified crowdfunding project to the affiliated store (S603). This output is performed depending on the usage pattern of the credit card. For example, when a member uses a credit card at an affiliated store's storefront, the card company server 1 sends the project information to the affiliated store terminal 3 installed at the storefront. In this case, the affiliated store terminal 3 displays the project name of the crowdfunding project indicated in the project information on a display unit or prints it on paper media. This allows the affiliated store to know the crowdfunding project that the member is supporting.

[0087] Furthermore, when a member uses a credit card at an online shop operated by an affiliated store, project information is sent from the card company server 1 to the web server that operates the online shop. In this case, the web server sends information including the above-mentioned project name and other information to the affiliated store terminal 3. This allows the affiliated store to know which crowdfunding project the member is supporting.

[0088] In the second merchant provision process described above, only the support requests of the member using the credit card this time are notified to the merchant, but in addition, the merchant may also be notified of support requests of other members with similar attributes to the member (members who are more likely to use the merchant).

[0089] Through each of the above-mentioned affiliated store provision processes, affiliated stores can identify crowdfunding projects that are suitable for them, such as those supported by members who have already used their store's services and members who have no experience but are likely to use their services. When affiliated stores support these crowdfunding projects, they are supporting the crowdfunding projects that these members are supporting. This allows affiliated stores to improve customer satisfaction and is expected to encourage members to use their credit cards. Therefore, affiliated stores will actively consider supporting crowdfunding projects, which will in turn encourage more crowdfunding donations.

[0090] (Other embodiments) Although the above embodiment is based on the assumption that one credit card company is involved, it is also possible to implement the embodiment based on the assumption that multiple credit card companies are involved. For example, if a card company integrated system is constructed that accumulates various information, such as information on members and affiliated stores and usage history, for multiple credit card companies, and this card company integrated system provides this various information related to other companies to the card company server 1 of each credit card company, it is possible to implement the above embodiment based on the assumption that multiple credit card companies are involved. Note that, since infrastructure services that allow various information on multiple credit card companies to be registered are already available, the above embodiment based on the assumption that multiple credit card companies are involved can also be implemented by utilizing such infrastructure services. [Explanation of symbols]

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

Claims

1. A project identification unit that identifies crowdfunding projects suitable for a credit card member based on the credit card member's credit card usage history; a project providing unit that provides project information indicating the identified crowdfunding project to the credit card member; Equipped with the project identification unit identifies a crowdfunding project supported by a credit card affiliated store that the credit card member has a history of using as a crowdfunding project suitable for the credit card member; the project providing unit provides the project information, including affiliated store information indicating the credit card affiliated store with the usage history, to the credit card member; Crowdfunding management system.

2. A project identification unit that identifies crowdfunding projects suitable for a credit card member based on the credit card member's credit card usage history; a project providing unit that provides project information indicating the identified crowdfunding project to the credit card member; Equipped with the project identification unit identifies, as a crowdfunding project suitable for the credit card member, a crowdfunding project supported by a credit card member store that is likely to be used by the credit card member; the project providing unit provides the project information, including affiliated store information indicating the credit card affiliated store, to the credit card member; Crowdfunding management system.

3. the case identification unit identifies a credit card affiliated store that is likely to be used by the credit card member based on the attributes of the credit card member; The crowdfunding management system according to claim 2 .

4. the case identification unit identifies a credit card affiliated store that the credit card member is likely to use based on the credit card usage history, The crowdfunding management system according to claim 2 or 3.

5. a support project acquisition unit that acquires support project information indicating crowdfunding projects supported by each credit card member; a second project identification unit that identifies crowdfunding projects suitable for each credit card member store based on the acquired support project information; a second project providing unit that provides second project information indicating the identified crowdfunding project to each of the credit card member stores; Further provided with A crowdfunding management system according to any one of claims 1 to 4.

6. the second project identification unit identifies crowdfunding projects supported by credit card members who have a track record of use at the credit card member store as crowdfunding projects suitable for the credit card member store; The crowdfunding management system according to claim 5 .

7. the second project identification unit identifies crowdfunding projects supported by credit card members that are likely to be used at credit card member stores as crowdfunding projects suitable for the credit card member stores; The crowdfunding management system according to claim 5 or 6.

8. the second case identification unit identifies a credit card member who is likely to be able to use the credit card at the credit card member store based on the attributes of the credit card member store, The crowdfunding management system according to claim 7.

9. the second case identification unit identifies a credit card member who is likely to use the credit card at the credit card member store based on a usage record at the credit card member store; The crowdfunding management system according to claim 7 or 8.

Images