Information processing device, information processing method, and program

Abstract

To provide technology that can stabilize an amount of refunds obtained from voting compared to when an individual votes alone.SOLUTION: In a step S1, a voting reception unit 130 starts receiving voting from a terminal 20 of each user belonging to a group. In a step S2, a voting execution unit 140 purchases voting tickets according to received voting details, and detects, on the basis of results of corresponding competitions, whether voting of each user is correct. In a step S3, a distribution unit 150 distributes, on the basis of distribution conditions set for the group to which each user belongs, an amount of refunds to each user with the detected voting result of each user and ends the processing.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to an information processing device, an information processing method, and a program. [Background technology]

[0002] For example, in races such as bicycle racing, horse racing, and boat racing, a voting device that accepts votes from voters (users) is used. A voter can vote by writing the voting information required for voting on a ballot paper and inputting it into the voting device. As an example, in the case of bicycle racing, a voter can predict the race result by referring to information such as past race results, the condition of the athletes on the day of the race, and odds, and based on the predicted result, can purchase a voting ticket by marking the race number, the betting method such as trifecta or wide, the car number of the athlete to be voted for, the amount to be bet, etc. on the ballot paper. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 11-96253 Summary of the Invention [Problem to be solved by the invention]

[0004] Here, when a user who votes purchases a betting ticket by himself / herself, the user may win a large amount in one competition, but may lose a large amount in another competition, and it is predicted that the user's payout amount over a certain period (for example, one day or one week) will be unstable. This is thought to be one of the factors that alienates users who have never voted or have little voting experience.

[0005] The present invention has been made in consideration of the circumstances described above, and aims to provide a technology that can stabilize the payout amount obtained by voting compared to when an individual votes alone. [Means for solving the problem]

[0006] An information processing device according to one embodiment of the present invention comprises a first reception unit that receives votes for a competition in which rankings are determined from each of a plurality of users belonging to a group, and a distribution unit that distributes a payout amount based on the voting results of each user in the competition in accordance with distribution conditions set for the group. Effect of the Invention

[0007] According to the present invention, it is possible to stabilize the payout amount obtained by voting, compared to when an individual votes alone. [Brief description of the drawings]

[0008] [Figure 1] 1 is a diagram illustrating an example of a system configuration of a voting system according to an embodiment of the present invention. [Diagram 2] FIG. 2 illustrates an example of a hardware configuration of a server. [Diagram 3] FIG. 2 illustrates an example of a functional block configuration of a server. [Figure 4] 1 shows an example of a user management DB, a group management DB, and a distribution condition DB. [Diagram 5] 13 is a flowchart illustrating an example of a processing procedure performed by a server. [Figure 6] FIG. 13 is an explanatory diagram of distribution condition 1. [Figure 7] FIG. 13 is an explanatory diagram of distribution condition 2. [Figure 8] FIG. 13 is an explanatory diagram of distribution condition 3. [Figure 9] FIG. 13 is an explanatory diagram of distribution condition 4. [Figure 10] FIG. 2 illustrates an example of a functional block configuration of a server. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described with reference to the accompanying drawings, in which the same reference numerals denote the same or similar configurations.

[0010] A. This embodiment <System configuration> Fig. 1 is a diagram showing an example of a system configuration of a voting system 1 according to this embodiment. The voting system 1 shown in Fig. 1 includes a server 10 and one or more terminals 20. The server 10 and the terminals 20 are connected to each other so as to be able to communicate with each other via a communication network N such as the Internet, an intranet, a wireless LAN, or mobile communication. The server 10 and the terminals 20 may be referred to as information processing devices.

[0011] The server 10 may be configured with one or more physical servers, or may be configured with a virtual server operating on a hypervisor, or may be configured with a cloud server. The terminal 20 is a terminal used by a user, and the user can cast a vote for a voting target by operating the terminal 20. The terminal 20 is, for example, a mobile phone (including a smartphone), a tablet terminal, a personal computer, etc.

[0012] For each competition in which voting is taking place, the server 10 performs various processes such as managing the groups to which each user belongs, managing the votes cast by each user, managing the specified value held by each user, and managing the payout amount (payout amount) based on the results of the competition.

[0013] The competition includes any competition in which multiple participants (teams or individuals) compete for ranking, such as bicycle racing, horse racing, boat racing, auto racing, soccer, baseball, and rugby.

[0014] A group is a group established for the purpose of distributing refunds. In this embodiment, the conditions for membership in the group (e.g., years of voting experience, age, etc.) are set by a user who belongs to the group and who is the initiator of the group (hereinafter referred to as a "host user").

[0015] Voting means that each user specifies the race number, betting method (for example, trifecta or wide), betting target (athlete or animal), etc. based on the predicted results, and votes (bet) a predetermined value.

[0016] The predetermined value is a value that can be used for voting, and may be, for example, money or points. The points may be usable in a predetermined service or game in addition to voting. Furthermore, the points may be, for example, points that a user who plays a predetermined service or game can receive free of charge within the predetermined service or game (free points), or points that can be received in exchange for paying money (by charging) within the predetermined service or game (paid points). The predetermined value may simply be referred to as "value."

[0017] In this embodiment, payout distribution conditions (method of averaging profits and losses, etc.) are set for the group. When each user belonging to the group casts a vote, he or she can receive a payout amount according to the voting result in accordance with the distribution conditions set for the group (details will be described later).

[0018] <Hardware configuration> 2 is a diagram showing an example of a hardware configuration of the server 10. The server 10 has a processor 11 such as a CPU (Central Processing Unit) or a GPU (Graphical processing unit), a storage device 12 such as a memory, an HDD (Hard Disk Drive) and / or an SSD (Solid State Drive), a communication IF (Interface) 13 for wired or wireless communication, an input device 14 for accepting input operations, and an output device 15 for outputting information. The input device 14 is, for example, a keyboard, a touch panel, a mouse, and / or a microphone. The output device 15 is, for example, a display and / or a speaker.

[0019] <Function block configuration> FIG. 3 is a diagram showing an example of a functional block configuration of the server 10. The server 10 includes a storage unit 100, a condition receiving unit 110, a soliciting unit 120, a vote receiving unit 130, a vote executing unit 140, and a distribution unit 150. The storage unit 100 can be realized by using a storage unit 12 included in the server 10. The condition receiving unit 110, the soliciting unit 120, the vote receiving unit 130, the vote executing unit 140, and the distribution unit 150 can be realized by the processor 11 of the server 10 executing a program stored in the storage unit 12. The program can be stored in a storage medium. The storage medium storing the program may be a non-transitory computer readable storage medium. The non-transitory storage medium is not particularly limited, and may be, for example, a storage medium such as a USB memory or a CD-ROM.

[0020] The memory unit 100 stores a user management DB 101 that manages various information related to users, a group management DB 102 that manages various information related to groups to which each user belongs, and a distribution conditions DB 103 that stores distribution conditions for distributing refund amounts.

[0021] FIG. 4A shows an example of the user management DB 101. In the user management DB101, group IDs, user IDs, possession values, and income / expense information are registered in association with each other. "Group ID" is an identifier for uniquely identifying a group to which a user belongs. "User ID" is an identifier for uniquely identifying a user. "Possession value" is a predetermined value that a user can use for voting. "Income / expense information" is composed of an investment amount for each event, a recovery amount, and a refund amount. "Investment amount" represents a predetermined value bet by a user, "recovery amount" represents a predetermined value recovered by the user based on the voting results, and "refund amount" represents a predetermined value distributed to the user according to the distribution conditions set for the group to which the user belongs.

[0022] FIG. 4B shows an example of the group management DB 102. Group management DB 102 stores group IDs and membership conditions in association with each other. The "membership conditions" include the conditions necessary for belonging to a group, such as years of voting experience and age. As described above, in this embodiment, it is assumed that the membership conditions are set by a host user who is a user belonging to a group and who is the initiator of the group, but this is not intended to be limiting. The membership conditions may be set in advance on the system side, or may be set by a system administrator who does not belong to the group.

[0023] FIG. 4C shows an example of the distribution condition DB 103. In the distribution condition DB 103, group IDs and distribution conditions for refund amounts are registered in association with each other. To explain C in Fig. 4, for group A, a method (distribution condition 1) is registered in which the profits and losses and earnings of each user belonging to group A are averaged and a refund amount is distributed to each user, and for group B, a method (distribution condition 2) is registered in which the more profitable a user is, the larger the distribution is, and so on. The distribution conditions may be set, for example, by the host user, or may be set in advance on the system side, or may be set by a system operator who does not belong to the group.

[0024] The condition receiving unit (second receiving unit) 110 receives a group ID for identifying the group and a condition for belonging to the group from the host user who is the initiator of the group. The condition receiving unit 110 registers the received group ID and the belonging condition in the group management DB 102 in association with each other.

[0025] The recruiting unit 120 recruits members (i.e., users) to belong to the group for which the membership conditions have been accepted. As an example, the recruiting unit 120 transmits the group membership conditions (e.g., "5 or more years of voting experience, 5 people to be recruited") to the terminal 20 of each user using the voting system 1, and notifies the user that recruitment for the group has begun. After that, when the recruiting unit 120 receives a request from a user who meets the membership conditions to join the group, the recruiting unit 120 approves the user as a user who belongs to the group. For example, when a certain user A is approved as a user who belongs to group A, the recruiting unit 120 registers the user ID (U0001) of user A in the user management DB 101 in association with the group ID (G001) of group A, as shown in A of FIG. 4 above.

[0026] The vote acceptance unit (first acceptance unit) 130 accepts votes for the competition from the terminal 20 of each user belonging to the group. As described above, a vote from each user includes specifications such as a user ID, a group ID, a competition number, a voting method, a voting target, and a predetermined value of the vote.

[0027] The voting execution unit 140 purchases voting tickets in accordance with the accepted voting details, and detects whether or not each user's vote is correct (that is, the voting result) based on the result of the corresponding competition.

[0028] The distribution unit 150 distributes the payout amount to each user based on the detected voting result of each user and the distribution conditions set for the group to which the user belongs. Note that the specific method of distributing the payout amount will be described in detail later and will not be described here.

[0029] <Processing Procedure> Fig. 5 is a flowchart showing an example of a processing procedure performed by the server 10. The flowchart shown in Fig. 5 assumes a case where each of a plurality of users belonging to a certain group casts a vote in a competition.

[0030] In step S1, the vote acceptance unit 130 starts accepting votes from the terminal 20 of each user belonging to the group. Each user casts their vote by operating the screen of the terminal 20 while watching the competition. When the terminal 20 accepts a vote from each user, it transmits voting information to the server 10, including specifications such as the user ID, group ID, competition number, voting method, voting target, and the amount of a predetermined value to be voted. The vote acceptance unit 130 accepts votes by receiving the voting information from the terminal 20.

[0031] In step S2, the voting execution unit 140 purchases a voting ticket according to the accepted voting contents, and detects whether each user's vote is correct or not (i.e., the voting result) based on the result of the corresponding competition. Here, the voting result may be detected automatically, for example, by analyzing live broadcast video of the competition, or may receive competition result data indicating the competition result from an external source, and detect the voting result based on the received competition result data.

[0032] In step S3, the distribution unit 150 distributes the refund amount to each user based on the detected voting result of each user and the distribution conditions set for the group to which the user belongs, and ends the process. Below, a specific example of a variation of the distribution conditions that can be set will be described with reference to Figs. 6 to 9. For convenience of explanation, Figs. 6 to 9 assume that in a group to which three users, User A, User B, and User C, belong, the investment amounts of User A, User B, and User C are 50,000 yen, 10,000 yen, and 40,000 yen, respectively, and the recovery amounts are 70,000 yen, 17,000 yen, and 25,000 yen, respectively.

[0033] <Distribution condition 1> In the distribution condition 1, the profit and loss of all users belonging to the group are averaged to determine the amount of refund to each user. FIG. 6 is an explanatory diagram of the distribution condition 1. The distribution unit 150 first grasps the balance (that is, the investment amount and the return amount) of each user (see A in FIG. 6).

[0034] Next, the distribution unit 150 calculates the total balance of all users (see B in FIG. 6). Here, the total investment amount is 100,000 yen and the total recovery amount is 112,000 yen, so the total balance of all users is 12,000 yen, which is the total recovery amount minus the total investment amount. The distribution unit 150 then divides the total balance by the number of users to calculate the balance per user (see C in FIG. 6). Here, the total balance is 12,000 yen and the number of users is three, so the balance per user is 4,000 yen.

[0035] Finally, the distribution unit 150 calculates the payout amount to each user by adding the balance per person to the investment amount of each user (see D in FIG. 6). In this case, since the balance per person is 4000 yen, the payout amount to user A is 54000 yen (=50000 yen + 4000 yen), the payout amount to user B is 14000 yen (=10000 yen + 4000 yen), and the payout amount to user C is 44000 yen (=40000 yen + 4000 yen).

[0036] <Distribution condition 2> The distribution condition 2 determines the amount of payout to each user so that the more profitable the user is, the larger the share of the user is. FIG. The distribution unit 150 first obtains the recovery rate (=recovery amount / investment amount) of each user (see A in FIG. 7). Here, the recovery rates of user A, user B, and user C are 1.4 times, 1.7 times, and 0.625 times, respectively.

[0037] Next, the distribution unit 150 calculates the total balance of all users (see B in FIG. 7). The total balance of all users can be explained in the same way as in B in FIG. 6, so it will not be explained here. The distribution unit 150 then calculates the balance of each user using the recovery rate of each user (see C in FIG. 7). In this example, the balance of user A is 4,510 yen (= 12,000 yen x 1.4 / (1.4 + 1.7 + 0.625)), the balance of user B is 5,476 yen (= 12,000 yen x 1.7 / (1.4 + 1.7 + 0.625), and the balance of user C is 2,013 yen (= 12,000 x 0.625 / (1.4 + 1.7 + 0.625).

[0038] Finally, the distribution unit 150 calculates the payout amount to each user by adding the balance of each user to the investment amount of each user (see D in FIG. 7). Here, since the balances of users A, B, and C are 4510 yen, 5476 yen, and 2013 yen, respectively, the payout amount to user A is 54510 yen (=50000 yen + 4510 yen), the payout amount to user B is 15476 yen (=10000 yen + 5476 yen), and the payout amount to user C is 42013 yen (=40000 yen + 2013 yen).

[0039] <Distribution condition 3> In the distribution condition 3, the amount of refund to each user is determined by averaging only the profits of each user. FIG. 8 is an explanatory diagram of the distribution condition 3. The distribution unit 150 first grasps the balance (that is, the investment amount and the return amount) of each user (see A in FIG. 8).

[0040] Next, the distribution unit 150 identifies users who are making profits (hereinafter referred to as profit users) and calculates the total profit amount (total profit) of the profit users (see B in FIG. 8). Here, user A's profit is 20,000 yen (=70,000 yen-50,000 yen) and user B's profit is 70,000 yen (=17,000 yen-10,000 yen), so the total profit is 27,000 yen. On the other hand, user C has incurred a loss of 15,000 yen (=25,000 yen-40,000 yen), so he is not a profit user.

[0041] Then, the distribution unit 150 calculates the distributed profit per user by dividing the total profit by the number of users (see C in FIG. 8). In this example, since the total profit is 27,000 yen and the number of users is three, the distributed profit per user is 9,000 yen.

[0042] Finally, the distribution unit 150 calculates the payout amount to each user by adding the distributed profit per person to the investment amount (users making a profit) or the recovery amount (users making a loss) (see D in FIG. 8). Here, since users A and B are making profits while user C is making a loss, the payout amount to user A is 59,000 yen (= 50,000 yen (investment amount) + 9,000 yen), the payout amount to user B is 19,000 yen (= 10,000 yen (investment amount) + 9,000 yen), and the payout amount to user C is 34,000 yen (= 25,000 yen (recovery amount) + 9,000 yen).

[0043] <Distribution condition 4> The distribution condition 4 determines the amount of payout to each user according to the investment ratio of each user. FIG.

[0044] The distribution unit 150 first grasps the balance of each user (i.e., the investment amount and the return amount) (see A in FIG. 9), and then calculates the total balance of all users (see B in FIG. 9). The distribution unit 150 then calculates the balance of each user according to the investment ratio (see C in FIG. 9). Here, the investment ratios of users A, B, and C are 0.5 (=5 / (5+1+4)), 0.1 (=1 / (5+1+4)), and 0.4 (=4 / (5+1+4)), respectively, so that the balance of user A is 6,000 yen (=12,000 yen×0.5), the balance of user B is 1,200 yen (=12,000 yen×0.1), and the balance of user C is 4,800 yen (=12,000 yen×0.4).

[0045] Finally, the distribution unit 150 calculates the payout amount for each user by adding the balance of each user to the investment amount of each user (see D in FIG. 9). Here, since the balances of users A, B, and C are 6,000 yen, 1,200 yen, and 4,800 yen, respectively, the payout amount for user A is 56,000 yen (= 50,000 yen + 6,000 yen), the payout amount for user B is 11,200 yen (= 10,000 yen + 1,200 yen), and the payout amount for user C is 44,800 yen (= 40,000 yen + 4,800 yen).

[0046] As described above, according to this embodiment, a user does not receive a payout amount according to the voting result based only on his / her own vote, but receives a payout amount according to the distribution conditions set for the group to which the user belongs. This makes it possible to stabilize the payout amount for users who vote on competitions.

[0047] B. Modifications The above-described embodiments are intended to facilitate understanding of the present invention, and are not intended to limit the present invention. The flow charts, sequences, elements included in the embodiments, and their arrangements, materials, conditions, shapes, sizes, etc. are not limited to those illustrated, and can be changed as appropriate. In addition, configurations shown in different embodiments can be partially replaced or combined with each other.

[0048] In this embodiment, the case where a payout amount is distributed to each user belonging to a group for each competition has been described, but, for example, after multiple competitions have finished (for example, after four competitions held in the morning have finished or after the final competition of the day has finished), the voting results of each user up to that point may be compiled and the payout amount may be distributed to each user.

[0049] In the present embodiment, the case where all votes of each user accepted by the vote acceptance unit 130 are executed has been described, but the present invention is not limited to this. Only votes approved by the host user who is the initiator of the group may be executed (i.e., a voting ticket is purchased). In this case, the vote execution unit (execution unit) 140 executes only votes that are votes of each user accepted by the vote acceptance unit 130 and approved by the host user. In other words, the vote execution unit 140 does not actually cast the votes of each user that have been accepted, but temporarily holds them. After that, the vote execution unit 140 actually executes the vote when the host user approves the held vote. Note that the host user can view and approve all votes of the group accepted by the vote acceptance unit 130 by appropriately operating the terminal 20. With this configuration, it is possible to prevent voting that does not conform to the host user's intention (for example, making a huge investment in a triplet).

[0050] In the present embodiment, the recruiting unit 120 recruits users to belong to a group based on the group membership conditions (such as years of voting experience and age) set by the host user, but the present invention is not limited to this. For example, the recruiting unit 120 may recruit users to belong to a group based on a set voting policy (longshot, safe bet). Here, the "voting policy" may represent the payout rate (so-called odds) or the range of odds for which each user belonging to the group can vote. As an example, when the voting policy is set to "longshot," only high odds (for example, 15 times or more) can be voted for, and odds other than the high odds are not displayed or are grayed out (blacked out), so that each user cannot select odds other than the high odds. On the other hand, when the voting policy is set to "Play it safe," only low odds (for example, less than 2:1) can be voted for, and odds other than low odds are not displayed or are grayed out (blacked out), so that each user cannot select odds other than low odds. However, when a user belonging to a group votes individually, not for the group, it is possible to remove the restriction that certain odds described above "cannot be selected." Furthermore, the host user may set the range of odds that can be voted for as a voting policy. As an example, the host user may set the range of high odds that can be voted for as "10 times or more, less than 20 times," and the range of low odds that can be voted for as "1 time or more, less than 3 times." Note that these ranges of odds that can be voted for are merely examples, and can be set arbitrarily by the host user. Furthermore, the voting policy may be set by the host user, but may also be set in advance on the system side, or may be set by the operator, etc.

[0051] Fig. 10 is a diagram showing an example of a functional block configuration of the server 10 according to a modified example. The server 10 shown in Fig. 10 is the server 10 shown in Fig. 3 with a management unit 160 added. The management unit 160 manages a group possession value (first value) and an individual possession value (second value) separately for each user. "Group possession value" refers to a predetermined value that can be used for voting for a group, and "individual possession value" refers to a predetermined value that can be used for voting by an individual.

[0052] Each user belonging to the group operates the terminal 20 to indicate whether to vote for the group or to vote individually, and to indicate the predetermined value to be used for voting. For example, when a user A belonging to the group inputs an instruction to vote 2000 yen individually (hereinafter referred to as a voting instruction), the input voting instruction is transmitted from the terminal 20 to the server 10. When the voting instruction is received by the voting reception unit 130 of the server 10, the voting instruction is sent to the management unit 160. When the management unit 160 determines based on the received voting instruction that the user A wishes to vote 2000 yen individually, the management unit 160 accesses the user management DB 101, subtracts the specified predetermined value (here, 2000 yen) from the personal possession value of the user A, and instructs the voting execution unit 140 to purchase a voting ticket according to the voting content. Note that the subsequent operations are the same as those in this embodiment, and therefore will not be described.

[0053] Although not specifically mentioned in this embodiment, a limit may be set on the amount of a predetermined value that each user can bet on. The limit may be set for each sport, or for multiple sports. The limit may be set, for example, by a host user who is the initiator of the group. Setting a limit makes it possible to prevent overspending of funds.

[0054] Furthermore, if a user belonging to a group does not bet a predetermined value (e.g., a total of 50,000 yen or more) equal to or greater than a set threshold by the end of a predetermined competition (e.g., by the end of half of the competitions held on that day), the user may be excluded from distribution of the refund amount. For example, assume that at the end of six competitions, users A and B have bet a total of 150,000 yen and 140,000 yen, respectively, while user C has only bet a total of 300 yen. In such a case, by setting the above-mentioned threshold value (a total of 50,000 yen or more), user C is excluded from distribution of the refund amount, and users A and B can receive a refund amount that is commensurate with their investment.

[0055] C.Other [Appendix 1] a first reception unit that receives votes for a competition in which rankings are competed for from each of a plurality of users belonging to the group; a distribution unit that distributes a payout amount according to the betting results of each user in the competition in accordance with distribution conditions set for the group; An information processing device comprising:

[0056] According to Appendix 1, the payout from voting is more stable than if an individual voted alone.

[0057] [Appendix 2] a second reception unit that receives a condition for belonging to the group from a host user who is a user belonging to the group and who is a founder of the group; The information processing device according to claim 1, further comprising: a recruiting unit that recruits the users to belong to the group based on the membership conditions.

[0058] According to Supplementary Note 2, it is possible to reduce variations in experience points regarding votes of each user.

[0059] [Appendix 3] 3. The information processing device of claim 2, further comprising an execution unit that executes votes for the competition received from each of the users and approved by the host user.

[0060] According to Appendix 3, it is possible to prevent betting that is not in line with the host user's intentions (such as investing a huge amount of money in a single bet).

[0061] [Appendix 4] The information processing device described in Appendix 1, further comprising a recruiting unit that recruits the users to belong to the group based on a voting policy for the competition that is set.

[0062] According to Appendix 4, it is possible to gather users who have voting policies similar to those within the group.

[0063] [Appendix 5] The information processing device according to claim 4, wherein the voting policy represents an odds range for voting targets for which each user belonging to the group can vote.

[0064] According to Appendix 5, it is possible to prevent votes that deviate from the voting policy.

[0065] [Appendix 6] An information processing device as described in any one of Appendices 1 to 5, further comprising a management unit that manages, for each user, separately a first value that can be used for the voting for the group to which the user belongs and a second value that the user can personally use for the voting.

[0066] According to Appendix 6, while belonging to a group, it is possible to vote both for the group and for personal voting.

[0067] [Appendix 7] An information processing method performed by an information processing device, accepting votes for a competition in which rankings are competed for from each of a plurality of users belonging to the group; distributing a payout amount according to the betting results of each user in the competition in accordance with distribution conditions set for the group; An information processing method comprising:

[0068] According to Appendix 7, the payout from voting is more stable than if an individual voted alone.

[0069] [Appendix 8] On the computer, accepting votes for a competition in which rankings are competed for from each of a plurality of users belonging to the group; distributing a payout amount according to the betting results of each user in the competition in accordance with distribution conditions set for the group; A program for executing the above.

[0070] According to Appendix 8, the payout from voting is more stable than if an individual voted alone. [Explanation of symbols]

[0071] 1... Voting system, 10... Server, 11... Processor, 12... Storage device, 13... Communication IF, 14... Input device, 15... Output device, 20... Terminal, 100... Storage unit, 101... User management DB, 102... Group management DB, 103... Distribution condition DB, 110... Condition acceptance unit, 120... Recruitment unit, 130... Voting acceptance unit, 140... Voting execution unit, 150... Distribution unit

Claims

1. a processor, the processor comprising: Accepting settings for a group regarding voting policies for a competition in which rankings are competed for from a terminal operated by a host user; A host user operates a terminal to accept a call for users to belong to a group that will vote based on the voting policy, Allowing each terminal of a plurality of users belonging to the group to vote within an odds range based on a voting policy in a group vote and restricting the terminals from voting outside the odds range; Votes for the competition are accepted from each device of multiple users belonging to the group, For each terminal of the plurality of users, in individual voting, there is no restriction on voting outside the odds range. , information processing device.

2. The processor further comprises: votes for the competition received from each terminal of a plurality of users belonging to the group; The information processing apparatus of claim 1 , further comprising: a host user configured to host the vote;

3. The processor further comprises: For each user belonging to a group, a first value available for the vote for the group to which the user belongs and a second value available for the vote by the user are managed separately.

3. The information processing device according to claim 1 or 2.

4. The processor accepts settings for a group of voting policies for a competition in which rankings are competed for from a terminal operated by a host user; The processor accepts, from a terminal operated by a host user, a call for users to belong to a group that will vote based on the voting policy; The processor allows each terminal of a plurality of users belonging to the group to vote within an odds range based on a voting policy in a group vote, while restricting the terminals from voting outside the odds range; The processor accepts votes for the competition from each terminal of a plurality of users belonging to the group; The processor does not impose any restriction on a vote outside the odds range in an individual vote for each terminal of the plurality of users. Information processing methods.

5. causing the processor to accept settings of voting policies for the group in a competition for rankings from a terminal operated by a host user; A processor is caused to accept, from a terminal operated by a host user, a call for users to belong to a group that will vote based on a voting policy; a processor that allows each terminal of a plurality of users belonging to the group to vote within an odds range based on a voting policy in a group vote, while restricting the terminals from voting outside the odds range; causing the processor to accept votes for the competition from each terminal of a plurality of users belonging to the group; The processor does not restrict a vote outside the odds range in an individual vote for each terminal of the plurality of users. A program that executes a process.

6. A server and a terminal device are provided, The server accepts settings for a group of voting policies for a competition in which rankings are competed for from a terminal operated by a host user; A host user operates a terminal to accept a call for users to belong to a group that will vote based on the voting policy, Allowing each terminal of a plurality of users belonging to the group to vote within an odds range based on a voting policy in a group vote and restricting the terminals from voting outside the odds range; Votes for the competition are accepted from each device of multiple users belonging to the group, For each terminal of the plurality of users, in individual voting, there is no restriction on voting outside the odds range. system.

Images