JP7644401B2 - Information processing device, information processing method, and program - Google Patents

Description

The present invention relates to an information processing device, an information processing method, and a program.

For example, in bicycle racing, horse racing, boat racing, and other competitions, a voting device that accepts votes from voters (users) is used. Voters can cast their votes 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, voters can predict the results of the race 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 their predictions, they can purchase a voting ticket by marking the race number, the betting method such as trifecta or wide, the car number of the athlete being voted for, the amount to be bet, etc. on the ballot paper.

Japanese Patent Application Publication No. 11-96253

Here, when a user who votes purchases a voting ticket by himself/herself, the user may win a large amount in one event but lose a large amount in another event, and it is predicted that the user's payout amount over a given period (e.g., 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.

The present invention was made in consideration of the circumstances described above, and aims to provide technology that can stabilize the payout amount obtained by voting compared to when an individual votes alone.

The information processing device according to one aspect of the present invention includes 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 a group, and a distribution unit that distributes a payout amount according to the voting results of each user in the competition in accordance with distribution conditions set for the group.

According to the present invention, it is possible to stabilize the payout amount obtained by voting compared to when an individual votes alone.

1 is a diagram illustrating an example of a system configuration of a voting system according to an embodiment of the present invention. FIG. 2 illustrates an example of a hardware configuration of a server. FIG. 2 illustrates an example of a functional block configuration of a server. 4 shows examples of a user management DB, a group management DB, and a distribution condition DB. 13 is a flowchart illustrating an example of a processing procedure performed by a server. FIG. 13 is an explanatory diagram of distribution condition 1. FIG. 13 is an explanatory diagram of distribution condition 2. FIG. 13 is an explanatory diagram of distribution condition 3. FIG. 13 is an explanatory diagram of distribution condition 4. FIG. 2 illustrates an example of a functional block configuration of a server.

The following describes an embodiment of the present invention with reference to the attached drawings. In each drawing, the same reference numerals denote the same or similar configurations.

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 communicatively connected to 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.

The server 10 may be configured with one or more physical servers, or may be configured with a virtual server running 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.

For each competition where voting takes 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 predetermined value held by each user, and managing the payout amount (payout amount) according to the results of the competition.

Competition includes any sport in which multiple participants (teams or individuals) compete for ranking, such as bicycle racing, horse racing, boat racing, auto racing, soccer, baseball, and rugby.

A group is a group established for the purpose of distributing refund amounts. 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 the "host user").

Voting means that each user selects a race number, a betting method (e.g., trifecta or wide), a betting target (athlete or animal), etc. based on the predicted results, and bets (wagers) a predetermined value.

The predetermined value is a value that can be used for voting, and may be, for example, money or points. In addition to voting, the points may be usable in a predetermined service or game. Furthermore, the points may be, for example, points that a user who plays a predetermined service or game can receive for free 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."

In this embodiment, payout distribution conditions (such as a method for averaging revenues and profits and losses) are set for the group. When each user belonging to the group casts a vote, they can receive a payout amount according to the voting results, in accordance with the distribution conditions set for the group (details will be described later).

<Hardware Configuration>
2 is a diagram showing an example of a hardware configuration of the server 10. The server 10 includes a processor 11 such as a central processing unit (CPU) or a graphical processing unit (GPU), a storage device 12 such as a memory, a hard disk drive (HDD) and/or a solid state drive (SSD), a communication interface (IF) 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.

<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 using a storage unit 12 provided 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.

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 when distributing refund amounts.

FIG. 4A shows an example of the user management DB 101 .
In the user management DB 101, 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 the group to which the user belongs. "User ID" is an identifier for uniquely identifying the user. "Possession value" is a predetermined value that the user can use for voting. "Income/expense information" is composed of an investment amount for each competition, a recovery amount, and a payout amount. "Investment amount" represents a predetermined value voted for by the user, "recovery amount" represents a predetermined value recovered by the user based on the voting results, and "payout amount" represents a predetermined value distributed to the user according to the distribution conditions set for the group to which the user belongs.

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 to belong to a group, such as years of voting experience and age. As described above, this embodiment assumes a case in which 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.

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. Regarding C in Fig. 4, for group A, a method (distribution condition 1) of averaging the profits and losses and earnings of each user belonging to group A and distributing the refund amount to each user is registered, and for group B, a method (distribution condition 2) of distributing a larger amount to a user with a larger profit is registered, 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.

The condition reception unit (second reception unit) 110 receives a group ID that identifies the group from the host user who is the initiator of the group, along with the conditions for belonging to the group. The condition reception unit 110 registers the received group ID and the conditions for belonging in the group management DB 102 in association with each other.

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 being recruited") to the terminal 20 of each user using the voting system 1, and notifies them 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, it 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.

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

The voting execution unit 140 purchases voting tickets according to the received voting details, and detects whether each user's vote was correct or not (i.e., the voting result) based on the result of the corresponding competition.

The distribution unit 150 distributes the payout amount to each user based on the voting results of each detected 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, so it will not be described here.

<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 in which each of a plurality of users belonging to a certain group casts a vote in a competition.

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.

In step S2, the voting execution unit 140 purchases a voting ticket according to the received voting details, and detects whether or not each user's vote is correct (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 footage of the competition, or the voting result may be detected based on the received competition result data that represents the competition result received from an external source.

In step S3, the distribution unit 150 distributes the refund amount to each user based on the detected voting results of each user and the distribution conditions set for the group to which the user belongs, and then ends the process. Below, specific examples of the variations in distribution conditions that can be set are explained with reference to Figures 6 to 9. For ease of explanation, in Figures 6 to 9, it is assumed 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.

<Distribution Condition 1>
In distribution condition 1, the profits and losses of all users belonging to the group are averaged to determine the amount of payout to each user. FIG.
The distribution unit 150 first grasps the balance (i.e., the investment amount and the return amount) of each user (see A in FIG. 6).

Next, the distribution unit 150 calculates the total balance of all users (see B in Figure 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 calculates the balance per user by dividing the total balance by the number of users (see C in Figure 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.

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 Figure 6). In this case, since the balance per person is 4,000 yen, the payout amount to user A is 54,000 yen (= 50,000 yen + 4,000 yen), the payout amount to user B is 14,000 yen (= 10,000 yen + 4,000 yen), and the payout amount to user C is 44,000 yen (= 40,000 yen + 4,000 yen).

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

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).

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 Figure 7). In this case, since the balances of users A, B, and C are 4,510 yen, 5,476 yen, and 2,013 yen, respectively, the payout amount for user A is 54,510 yen (= 50,000 yen + 4,510 yen), the payout amount for user B is 15,476 yen (= 10,000 yen + 5,476 yen), and the payout amount for user C is 42,013 yen (= 40,000 yen + 2,013 yen).

<Distribution Condition 3>
In the distribution condition 3, the amount of the refund to each user is determined by averaging only the profits of each user. FIG.
The distribution unit 150 first grasps the balance (i.e., the investment amount and the return amount) of each user (see A in FIG. 8).

Next, the distribution unit 150 identifies users who are making a profit (hereafter referred to as profit users) and calculates the total profit amount of the profit users (total profit) (see B in Figure 8). In this case, 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.

The distribution unit 150 then divides the total profit by the number of users to determine the distributed profit per user (see C in Figure 8). In this case, the total profit is 27,000 yen, and since there are three users, the distributed profit per user is 9,000 yen.

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

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

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 user A's balance is 6,000 yen (= 12,000 yen x 0.5), user B's balance is 1,200 yen (= 12,000 yen x 0.1), and user C's balance is 4,800 yen (= 12,000 yen x 0.4).

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 Figure 9). In this case, 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).

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 voting result 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 in a competition.

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. described in the embodiments are not limited to those illustrated, and can be modified as appropriate. In addition, configurations shown in different embodiments can be partially replaced or combined with each other.

In this embodiment, the case where the 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 the 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.

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. It is also possible to execute votes (i.e., purchase voting tickets) only for votes approved by the host user who is the initiator of the group. In this case, the vote execution unit (execution unit) 140 executes votes only for 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 it has received, but temporarily holds them. After that, if the host user approves the reserved vote, the vote execution unit 140 actually executes the 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 is not in line with the host user's intention (for example, making a huge investment in a triplet).

In addition, in this 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 voting policy (longshot, safe bet) set. 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 (e.g., 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 the predetermined odds described above "cannot be selected."
Furthermore, the host user may set a range of odds that can be voted for as a voting policy. As an example, the host user may set a range of high odds that can be voted for of "10 times or more, less than 20 times," and a range of low odds that can be voted for of "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.

Figure 10 is a diagram showing an example of a functional block configuration of a server 10 according to a modified example. The server 10 shown in Figure 10 is the server 10 shown in Figure 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.

Each user belonging to the group operates the terminal 20 to indicate whether to vote for the group or 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, it sends it to the management unit 160. When the management unit 160 determines based on the received voting instruction that user A wishes to vote individually for 2000 yen, it accesses the user management DB 101, subtracts the specified predetermined value (here, 2000 yen) from the personal value held by user A, and instructs the voting execution unit 140 to purchase a voting ticket according to the voting content. Note that the operation after this is the same as in this embodiment, and therefore will not be described.

Although not specifically mentioned in this embodiment, a limit may be set for 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 the host user who initiates the group. By setting a limit, it is possible to prevent overspending of funds.

In addition, if a user belonging to a group does not bet a predetermined value equal to or greater than a set threshold (e.g., a total of 50,000 yen or more) by the time a predetermined competition is completed (e.g., by the time half of the competitions held on that day are completed), the user may be excluded from the distribution of the refund amount. For example, at the time when six competitions are completed, 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 predetermined value threshold (a total of 50,000 yen or more), user C will be excluded from the distribution of the refund amount, and users A and B will be able to receive a refund amount that is commensurate with their investment.

C. Others [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.

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

[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.

According to Appendix 2, it is possible to reduce the variation in experience points related to each user's votes.

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

Additional Note 3 makes it 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).

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

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

[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.

According to Appendix 5, it is possible to prevent votes that deviate from the voting guidelines.

[Appendix 6]
An information processing device 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.

According to Appendix 6, while belonging to a group, it is possible to both vote for the group and vote personally.

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

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

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

According to Appendix 8, the payout from voting is more stable than if an individual voted alone.

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...vote acceptance unit, 140...vote execution unit, 150...distribution unit

Claims (6)

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 terminal 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. 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; 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. The processor receives a setting of a voting policy for a group in a competition for ranking 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. 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. 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 terminal 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