Game information processing device, control method for information processing device, and control program

Abstract

To efficiently guide game players to build relationships with each other. [Solution] A "game information processing device" (for example, a user management server 10) according to one aspect of the present invention includes means for registering a first player and a second player in association (for example, registration unit 410, registration unit 414), and means for granting a first additional bonus to a second player who was not involved in the acquisition process of the first bonus, provided that the second player is registered in association with the first player (for example, lottery unit 420, granting unit 423).

Description

Technical Field

[0001] The present invention relates to an electronic game using a display capable of two-dimensional or higher-dimensional display.

Background Art

[0002] There is known an electronic game having a mechanism for sharing the process of lottery processing among a plurality of users. For example, in the game system described in Patent Document 1, a server that executes a lottery process (so-called gacha) for a group in response to an execution request from a certain user in the group transmits screen information representing a series of execution screens from the start to the end of the lottery process to the terminals of all users belonging to the group in real time.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the game system described in Patent Document 1, the destination to which a game item is to be given according to the result of the lottery process for a group is set to any one of the users belonging to the group. Therefore, it is not assumed that game items according to the result of the lottery process for the group are given to a plurality of users belonging to the group respectively. Also, it is not assumed that the game item is given to a user who has not shared the screen information of the lottery process.

[0005] The problem to be solved by the present invention is to efficiently induce the players of the game to build relationships with each other.

Means for Solving the Problems

[0006] To solve the above problems, the present invention grants an additional benefit to a second player who was not involved in the acquisition process of a certain benefit, provided that the second player is registered in association with the first player, when the benefit is granted to the first player who was involved in the acquisition process of the benefit. The present invention includes, for example, the following embodiments.

[0007] [A] A “game information processing device” according to one aspect of the present invention includes registration means for registering a first player and a second player in association with each other, and granting means for granting a first additional bonus to a second player who was not involved in the process of obtaining the first bonus, provided that the second player is registered in association with the first player, when the first bonus is granted to the first player who was involved in the process of obtaining the first bonus.

[0008] [B] A "control method" for an information processing device according to one aspect of the present invention includes a registration step of registering a first player and a second player in association with each other, and a granting step of granting a first additional benefit to the second player who was not involved in the process of obtaining the first benefit, provided that the second player is registered in association with the first player, when the first benefit is granted to the first player who was involved in the process of obtaining the first benefit.

[0009] [C] A "control program" in one aspect of the present invention provides the computer of an information processing device with a registration function for registering a first player and a second player in association with each other, and a granting function for granting a first additional benefit to a second player who was not involved in the process of obtaining the first benefit, provided that the second player is registered in association with the first player, when the first benefit is granted to the first player who was involved in the process of obtaining the first benefit.

[0010] [D] A control program recorded on a "computer-readable recording medium" according to one aspect of the present invention causes the computer of the information processing device to implement a registration function for registering a first player and a second player in association, and a granting function for granting a first additional benefit to a second player who was not involved in the process of obtaining the first benefit, provided that the second player is registered in association with the first player, when the first benefit is granted to the first player who was involved in the process of obtaining the first benefit. [Effects of the Invention]

[0011] According to the present invention, if a first player is granted a special benefit, the second player is also granted an additional benefit. Therefore, by using the present invention to associate and register players who have established relationships with each other, it can be expected that players in the game will actively try to build relationships with each other.

[0012] The "game information processing device" in [A] above may be subject to the following technical limitations. Furthermore, similar technical limitations may be applied to the "control method" in [B] above, the "control program" in [C] above, and the control program recorded in the "recording medium" in [D] above, respectively.

[0013] (1) The granting means further grants the second additional benefit to the first player who was not involved in the process of obtaining the second benefit, provided that the first player is registered in association with the second player when the second benefit is granted to the second player who was involved in the process of obtaining the second benefit. This is expected to be beneficial to both parties who are registered in association, and therefore encourages players to build relationships with each other more actively.

[0014] (2) The system further includes a receiving means for receiving requests from the second player to improve the likelihood of obtaining the second reward during the process of obtaining the second reward, and the granting means grants the first player a second additional reward equivalent to the second reward when the second reward is granted to the second player in response to or in consideration of the request from the second player received by the receiving means. This allows for the adoption of a strategy that improves the likelihood of obtaining a particular reward and reduces the possibility of overlapping rewards, and it can be expected that players who have the same first and second choice rewards will actively try to build relationships with each other.

[0015] (3) The system further comprises notification means for informing the second player of the content of the first additional benefit to be granted to the second player, and the receiving means receives a request from the second player to improve the availability of the second benefit after the content of the first additional benefit has been notified to the second player. This makes it possible to switch to a strategy of improving the availability of the second benefit once the first benefit is obtained, and it is expected that players who have the same first and second benefit will try to build relationships with each other more actively.

[0016] (4) The registration means registers the first player, the second player, and the third player in association with each other, and the granting means further grants the third additional benefit to the first and second players who were not involved in the process of obtaining the third benefit, provided that they are registered in association with the third player, when the third benefit is granted to the third player who was involved in the process of obtaining the third benefit, and also grants the first additional benefit and the second additional benefit to the third player who was not involved in either the process of obtaining the first benefit or the process of obtaining the second benefit, provided that they are registered in association with the first and second players, respectively. As a result, all players who build relationships benefit, and it is expected that players will actively try to build relationships with each other.

[0017] (5) The receiving means further receives a request from the first player to improve the likelihood of obtaining the first reward during the process of obtaining the first reward, and the granting means grants the second and third players the first additional reward equivalent to the first reward when the first reward is granted to the first player in response to or in consideration of the request from the first player received by the receiving means. This allows for the adoption of a strategy that improves the likelihood of obtaining a particular reward and reduces the likelihood of obtaining the same reward multiple times, and it can be expected that players who have the same first, second, or third choice reward will actively try to build relationships with each other.

[0018] (6) The notification means further notifies the first player of the content of the third additional benefit to be granted to the first player, and the receiving means receives a request from the first player to improve the availability of the first benefit after the content of the third additional benefit has been notified to the first player. This makes it possible to switch to a strategy to improve the availability of the second-choice benefit once the first-choice benefit is obtained, and then to switch to a strategy to improve the availability of the third-choice benefit once the second-choice benefit is obtained, so it can be expected that players who have the same first to third-choice benefits will try to build relationships with each other more actively.

[0019] (7) The system further includes a means for presenting the acquisition request of the first player, who is soliciting partners for association registration, to the second player who is considering applying to the solicitation, and the registration means registers the first player and the second player who has applied to the solicitation by the first player in association. This makes it easier for players with the same acquisition request to build relationships with each other.

[0020] (8) The registration means further provides information about the first player who has set an acquisition request and is soliciting partners for association registration to the second player in response to a search request that specifies search conditions for the acquisition request, and the registration means registers the first player and the second player who has applied to the solicitation by the first player in association. This makes it easier for players with the same acquisition request to build relationships with each other.

[0021] (9) The registration means registers a first group including the first player and the second player, and a second group including the first player but not the second player, and the granting means grants the first additional benefit to the second player only if the first group is included in the one or more designated groups to which the first additional benefit is to be granted. This makes it possible to adjust the recipients of the additional benefit when the first player belongs to multiple groups.

[0022] (10) The registering means further registers a third group that includes the second player and does not include the first player. The awarding means awards the second additional privilege to the first player only when the first group is included in the single or multiple designated groups that are the awarding destinations of the second additional privilege. Thereby, when the second player belongs to a plurality of groups, the awarding destination of the additional privilege can be adjusted.

[0023] (11) The awarding means identifies the designated group according to at least any one of the designation by the player, the nature of the process of obtaining the privilege, and the content of the privilege. Thereby, the designated group is identified manually or automatically.

[0024] In this specification, terms are used as follows.

[0025] (1) "Game" refers to an electronic game provided in at least a partially online game service. In a broad sense, it refers to the game service itself, and in a narrow sense, it refers to an individual stage that constitutes the game service. An individual stage may be called a quest. "Player" refers to a user of the game service. "Play" refers to a player playing by advancing a specific game.

[0026] (2) "Registering the first player and the second player in association with each other" means registering the first player and the second player directly or indirectly in association with each other. For example, the identification information of the first player and the identification information of the second player may be directly associated and registered. Also, for example, the identification information of the first player and the identification information of the second player may be respectively associated with the identification information of a group and registered.

[0027] (3) “Benefits” include rewards and operations that directly or indirectly contribute to playing the game more advantageously. Rewards include in-game elements (e.g., currency items, recovery items, crafting material items, characters, and other objects). Operations include favorable treatment (e.g., setting or changing parameters used in or outside of a stage to be advantageous to the player). To “grant” benefits includes, for example, registering in-game elements as rewards in association with a player, and applying favorable treatment as an operation to a player.

[0028] (4) The “acquisition process” of a reward refers to the series of steps taken until the reward is obtained. The “acquisition process” may be limited to the series of steps taken after players have been associated and registered (in this embodiment, after group registration has been made). The steps include processing by various devices and operations by players. The “acquisition process” of a reward may be a sufficient condition for obtaining the reward, or it may be a necessary condition for obtaining the reward. For example, if a certain reward (e.g., a reward for completing a quest) is definitively granted upon completion of a predetermined mission (e.g., clearing a specific stage in the game), the series of steps taken from the start of the mission to its completion constitute the acquisition process of the reward. Also, for example, if a certain reward (e.g., a reward for the gacha result) is granted after a predetermined event (e.g., a gacha in the game), the series of steps taken from the start to the end of the event constitute the acquisition process of the reward.

[0029] (5) "Participation" in the acquisition process means actively or passively engaging in at least some of the steps included in the acquisition process. "Participation" includes both engaging alone (e.g., playing a stage solo, playing a single gacha) and engaging with other players (e.g., playing a stage multiplayer, playing a multi-gacha). "Participation" in the acquisition process includes, for example, contributing to the acquisition.

[0030] (6) "Additional benefits" are benefits similar to regular benefits, and are special benefits granted to players who were not involved in the process of obtaining the regular benefits or who did not contribute to obtaining the regular benefits. "Additional benefits" may be benefits equivalent to regular benefits, or benefits that differ from regular benefits. For example, if regular benefits are game elements as rewards, additional benefits may also be the same game elements.

[0031] (7) A “request to improve the availability of a reward” means a request that probabilistically or definitively improves the availability of a particular reward candidate from among several reward candidates. Availability may be improved absolutely or relatively. There may be one or more requests. For example, requests to select a particular reward candidate, requests to relatively increase the probability of selecting a particular reward candidate, and requests to narrow down the options of reward candidates so that a particular reward candidate remains are included in “requests to improve the availability of a reward.” Requests to narrow down the options of reward candidates that include a particular reward candidate include, for example, requests to exclude at least some of the reward candidates other than the particular reward candidate from the options, requests to keep only the candidates from the group to which the particular reward candidate belongs from the options, requests to exclude at least some of the candidates from which the particular reward candidate does not belong from the options, and requests to exclude some of the reward candidates other than the particular reward candidate from the options.

[0032] (8) When determining a reward "on request," for example, the specific reward candidate selected by a request to select a specific reward candidate may be determined as the recipient. When determining a reward "taking requests into consideration," for example, the recipient may be determined by probability calculation using selection probabilities set based on a request to relatively increase the probability of selecting a specific reward candidate, or the recipient may be determined from the options narrowed down based on a request to narrow down the options of reward candidates so that a specific reward candidate remains. [Brief explanation of the drawing]

[0033] [Figure 1] This is a block diagram illustrating the network configuration of a game system. (Example) [Figure 2] This is a block diagram illustrating the electrical configuration of a server device. (Example) [Figure 3] This is a block diagram illustrating the electrical configuration of a user device. (Example) [Figure 4] This is a block diagram illustrating the functional configuration of a user management server. (Example) [Figure 5] This is an explanatory diagram illustrating the data structure related to the lottery function. (Example) [Figure 6] This is a sequence diagram illustrating the recruitment procedure for short-distance recruitment. (Example) [Figure 7] This is a sequence diagram illustrating the application procedure for short-distance recruitment. (Example) [Figure 8] This is a sequence diagram illustrating the recruitment procedure for social media-based recruitment. (Example) [Figure 9] This is a sequence diagram illustrating the application procedure for recruitment via social media. (Example) [Figure 10] This is a sequence diagram illustrating the group registration procedure. (Example) [Figure 11] This is a flowchart illustrating the procedure for executing a combined lottery. (Example) [Modes for carrying out the invention]

[0034] [1. Embodiments] [1-1. Overview] In this embodiment, in order to efficiently encourage game players to build relationships with each other, when a reward is granted to a first player who was involved in the process of obtaining that reward, an additional reward is granted to a second player who was not involved in the process of obtaining that reward, provided that they are registered in association with the first player. Therefore, by operating the system in a way that associates and registers players who have built relationships with each other, it can be expected that game players will actively try to build relationships with each other.

[0035] [1-2. Game Information Processing Device] The game information processing device according to the embodiment (for example, user management server 10) includes means for registering a first player and a second player in association (for example, registration unit 410, registration unit 414), and means for granting a first additional bonus to a second player who was not involved in the acquisition process of the first bonus, provided that the second player is registered in association with the first player (for example, lottery unit 420, granting unit 423). [Examples]

[0036] [2. Examples] [2-1. Overview of Game Services] This embodiment relates to a game service (hereinafter referred to as "the service of the embodiment") that is provided at least in part online. In the service of the embodiment, the player is provided with an electronic game (a game in the broad sense) in which the player sequentially controls four characters (monsters) that make up a deck through predetermined actions and challenges multiple stages (games in the narrow sense) provided within the game. Hereinafter, these stages will be referred to as "quests".

[0037] [2-2. Overview of the lottery function] Furthermore, in the electronic game of the service of the embodiment, players are provided with a mechanism (lottery function) that allows them to try their luck at a lottery (gacha) outside of quests, either in exchange for consuming specific in-game elements (e.g., currency items, exchange items) or unconditionally, and to obtain rewards (gacha rewards) as a result of the lottery. The lottery function is implemented in the game system that provides the service of the embodiment (hereinafter referred to as the "system of the embodiment").

[0038] There are two ways to participate in the lottery: a single lottery (single gacha) where one player attempts the lottery alone, and a group lottery (multi-gacha) where 2 to 4 registered players cooperate to attempt the lottery. In a group lottery, the results of each player's individual lottery attempts are shared with other players belonging to the same group.

[0039] [2-3. Overview of the combined lottery] The lottery function in this embodiment efficiently guides game players to register with each other as a group (an example of "building relationships"). When a player belonging to a certain group is granted a regular gacha reward (an example of "special perks") through the lottery procedure (the process of obtaining gacha rewards), other players who have registered with the group but have not participated in the lottery procedure (in other words, other players who are not in a position to be granted regular gacha rewards) are granted an additional reward (an example of "additional perks") equivalent to the regular gacha reward, on the condition that they belong to that group.

[0040] Specifically, the lottery function according to this embodiment accepts a request from a player in each lottery step of a composite lottery to improve the likelihood of obtaining a particular gacha reward, grants the player a gacha reward determined in response to or taking into account the request, and grants additional rewards equivalent to the gacha reward to other players belonging to the same group as the player in question.

[0041] Each player can initiate the combined lottery process at any time after registering with the group. In particular, each player can request an improvement in the chances of obtaining a specific gacha reward in their own lottery process after learning about the additional rewards they will receive through the lottery process involving other players in the same group.

[0042] These features allow players who have registered as a group to cooperate and adopt strategies that improve the likelihood of obtaining specific rewards while reducing the possibility of duplicate rewards. Furthermore, each time a player obtains a reward with a relatively high desire level (gacha reward, additional reward), they can sequentially switch to a strategy that improves the likelihood of obtaining rewards with a relatively low desire level (gacha reward, additional reward). Therefore, with the lottery function according to this embodiment, it can be expected that players who desire the same reward will actively try to build relationships with each other.

[0043] [2-4. System Configuration of the Example] [2-4-1. Network Configuration] (1) Overview Figure 1 illustrates the network configuration of the system in the embodiment. As illustrated in Figure 1, the system in the embodiment includes a user management server 10 that manages users of the service in the embodiment, a data management server 20 that manages data related to the service in the embodiment, and multiple user terminals 30 (30-1, 30-2, ..., 30-n) (n: natural number) used by multiple users, each of them.

[0044] The user management server 10 and the user terminal 30 can exchange data via the communication network 40. The data management server 20 can access built-in or externally connectable storage 21. The user management server 10 can read and write data to and from the storage 21 via the data management server 20.

[0045] The communication network 40 may include at least one of the existing networks such as the Internet, mobile phone networks, wireless WANs (Wireless Wide Area Networks), wireless LANs (Wireless Local Area Networks), and Ethernet (registered trademark).

[0046] (2) User management server User management server 10 is a server device (computer) on which the web server program is installed.

[0047] The user management server 10, in response to a request, instructs the data management server 20 to retrieve the necessary data from the storage 21 and provides it to the requester (response). The user management server 10 also instructs the data management server 20 to register the necessary data in the storage 21 in response to a request.

[0048] Furthermore, a server system may be configured by linking multiple server devices, and the functions of the user management server 10 may be shared or the load on the user management server 10 may be distributed.

[0049] (3) Data management server The data management server 20 is a server device (computer) on which the DB server program is installed. The data management server 20, together with the storage 21, constitutes a DBMS (Database Management System).

[0050] The data management server 20 retrieves the necessary data from the storage 21 in response to a request and provides it to the requester (response). In response to a request, the necessary data is registered in storage 21. Storage 21 is a storage device that stores data related to the service of the embodiment.

[0051] Furthermore, a server system may be configured by linking multiple server devices, and the functions of the data management server 20 may be shared or the load on the data management server 20 may be distributed. Alternatively, multiple storage devices may be provided, and each type of data stored in storage 21 may be stored separately, or the data stored in storage 21 may be distributed across multiple storage devices.

[0052] (4) User terminal User terminal 30 is a user device (computer) on which a predetermined game program is installed.

[0053] In this embodiment, the user device can be a general-purpose portable device on which a program can be installed (e.g., a mobile phone, smartphone, tablet terminal, tablet PC (personal computer), wearable device, etc.) or a general-purpose processing device (e.g., a PC (personal computer), etc.).

[0054] [2-4-2. Electrical Configuration] (1) Electrical configuration of the server device Figure 2 illustrates the electrical configuration of a server device. The server device illustrated in Figure 2 is an MPU. It includes a control processing unit 210 including a Micro-Processing Unit (Micro-Processing Unit) and ROM (Read Only Memory), a main memory 220 including RAM (Random Access Memory), an auxiliary storage device 230 including an HDD (Hard Disk Drive), an input device 240 including a mouse and keyboard, an output device 250 including a display and speakers, and a communication control device 260 including a network interface card.

[0055] The main memory 220, auxiliary memory 230, input device 240, output device 250, and communication control device 260 are each connected to the control processing device 210 via a bus line.

[0056] The control processing unit 210 (1) reads the program stored in the auxiliary storage device 230 onto the main storage device 220, (2) acquires data from at least one of the input device 240, the auxiliary storage device 230, and the communication control device 260 according to the instructions of the program, (3) performs calculations and processing on the acquired data according to the procedure specified in the program, and (4) provides the calculated and processed data to at least one of the auxiliary storage device 230, the output device 250, and the communication control device 260.

[0057] (2) Electrical configuration of user equipment Figure 3 illustrates the electrical configuration of the user device. The user device illustrated in Figure 3 includes an MPU 310 which constitutes the control processing unit, a RAM 320 which constitutes the main memory unit, a ROM 330 and an EEPROM (Electrically Erasable Programmable Read-Only Memory) 340 which constitute the auxiliary memory unit, a touch panel display 350 which constitutes the input unit and display unit, a speaker 360 which constitutes the audio output unit, a NIC (Network Interface Controller) 370 and a wireless LAN (Local Area Network) chip 380 which constitute the communication control unit, and a GPS (Global Positioning System) unit 390 which constitutes the location acquisition unit.

[0058] RAM320, ROM330, EEPROM340, touch panel display350, speaker360, NIC370, wireless LAN chip380, and GPS unit390 are connected to MPU310 via a bus line.

[0059] The MPU310 (1) reads a program stored in ROM330 or EEPROM340 onto RAM320, (2) acquires data from at least one of the touch panel display 350, EEPROM340, NIC370, wireless LAN chip 380, and GPS unit 390 according to the program's instructions, (3) performs calculations and processing on the acquired data according to the procedure specified in the program, and (4) provides the calculated and processed data to at least one of the EEPROM340, touch panel display 350, speaker 360, NIC370, and wireless LAN chip 380.

[0060] [2-4-3. Functional configuration related to the lottery function] Figure 4 illustrates the functional configuration of the lottery function of the system in the embodiment. As illustrated in Figure 4, the user management server 10 includes a registration unit 410 that associates and registers multiple players and a lottery unit 420 that performs a lottery (gacha). The registration unit 410 includes a recruitment acceptance unit 411, a search unit 412, an application acceptance unit 413, and a registration unit 414. The lottery unit 420 includes a reception unit 421, an execution unit 422, an allocation unit 423, and a notification unit 424.

[0061] The functions of the user management server 10 are realized by installing an operating system (OS) for the server device and programs (e.g., drivers, applications) that run on that OS on the server device. The programs to be installed on the server device are CDs (Compact Discs), DVDs (Digital Versatile Discs), and MO disks. The data may be distributed on a recording medium such as a Magneto-Optical disk or flash memory and read from the recording medium to the server device, or it may be supplied to the server device by superimposing it on a carrier wave via the communication network 40 or other communication network.

[0062] Recruitment Department 411 accepts recruitment requests (hereinafter referred to as "member recruitment") from players who wish to participate in the combined lottery, for members of a group related to the combined lottery. Member recruitment searches for members who are located near the recruiter (hereinafter referred to as "nearby recruitment") and members who are players to whom the recruiter can provide a URL (Uniform Resource Locator) (hereinafter referred to as "SNS recruitment").

[0063] The search unit 412 searches for member recruitment in response to requests from players who wish to participate in the combined lottery. The search unit 412 searches for, for example, local recruitment or SNS recruitment. The application acceptance unit 413 accepts applications from players who wish to participate in the combined lottery for specific member recruitment.

[0064] The registration unit 414 registers a group associated with a specific member recruitment, linking the player who recruited members (recruiter, host) and the players who applied to the recruitment (applicant, guest). The maximum number of members in a group, including the recruiter and applicant, can be set arbitrarily. In this embodiment, the maximum number of members is set to 4.

[0065] The reception unit 421 receives requests to improve the likelihood of a player obtaining a specific gacha reward in a lottery procedure that the player is participating in. In this embodiment, a request to improve the likelihood of obtaining a specific gacha reward is a combination of a request to probabilistically improve the likelihood of obtaining a specific gacha reward candidate from among multiple gacha reward candidates, and a request to definitively improve it. More specifically, the reception unit 421 receives, in this order, a request to narrow down the options of gacha reward candidates by specifying an attribute, and a request to select a specific gacha reward candidate from among the gacha reward candidates presented as options.

[0066] The execution unit 422, in a lottery procedure that a player attempts, takes into account the request received by the reception unit 421 to determine a candidate for the gacha reward (in-game character) to be given to the player. In this embodiment, in the first stage, the player is asked to select one of five character attributes, and in the second stage, five characters that meet predetermined criteria for the selected character attribute are selected. The predetermined criteria are, for example, that the character's level is above a predetermined value.

[0067] The reward distribution unit 423 grants the regular gacha reward to a player who has performed the lottery procedure. The reward distribution unit 423 also grants additional gacha rewards equivalent to the gacha reward to other players who were not involved in the lottery procedure, provided they belong to the same group as the aforementioned player. The granted rewards (characters) are added to each player's character box within the game app.

[0068] The notification unit 424 notifies other players of the contents of the additional gacha reward when a player who has performed the lottery procedure is granted a regular gacha reward, and consequently, an additional gacha reward equivalent to that gacha reward is granted to other players. The means of notification are arbitrary. In this embodiment, the fact that a gacha reward has been granted is notified explicitly or implicitly by displaying a predetermined icon on the home screen of the game application.

[0069] [2-4-4. Data Structure] Figure 5 illustrates the data structure in the system of the embodiment. Player management information (Figure 5(a)) is generated or updated when a group is registered. Group member management information (Figure 5(b)) is generated when a group is registered. Group status management information (Figure (c)) is generated when a group is registered and is updated (deactivated) after all members belonging to the group have completed the lottery procedure. Virtual waiting room information (Figure 5(d)) and virtual waiting management information (Figure 5(e)) are generated when a member recruitment is accepted. In addition, the virtual waiting management information is updated each time an application for the recruitment is accepted.

[0070] (1) Player management information The storage 21 stores player management information for each player, which manages the group to which the player belongs. As illustrated in Figure 5(a), the player management information associates at least one "Player ID" with a "Membership Group" (Group ID) for each player. In this embodiment, since each player is not permitted to belong to multiple groups, there is only one "Group ID" associated with the "Player ID".

[0071] (2) Group Member Management Information Storage 21 stores group member management information for each group, which manages the members belonging to that group. As illustrated in Figure 5(b), the group member management information associates at least one "recruiter" (player ID) and one or more "applicants" (player IDs) with the "group ID".

[0072] (3) Group status information Storage 21 stores group status information that manages the status for each group. As illustrated in Figure 5(c), the group status information associates at least a "Target Category" and a "Status" with a "Group ID". The "Target Category" indicates the category of the reward to be shared. In this embodiment, the "Target Category" is a fixed value for the category indicating gacha rewards. The "Status" indicates the status of the group (e.g., enabled / inactive). The status of the group is set to enabled when the group is registered, and updated to disabled after all players belonging to the group have performed the lottery procedure.

[0073] (4) Virtual waiting room information Storage 21 stores virtual waiting room information that records various parameters related to the virtual waiting room corresponding to each member recruitment. As illustrated in Figure 5(d), the virtual waiting room information associates at least the "Virtual Waiting Room ID" with the "Recruiter" (Player ID), "Recruitment Category," "Participation Conditions," and "Status." The "Recruitment Category" indicates, for example, a nearby recruitment that recruits members located nearby or an SNS recruitment that recruits members outside the system of the embodiment. The "Participation Conditions" are, for example, temporal conditions, spatial conditions (geographical conditions), a password, etc. The "Status" indicates the status of the member recruitment (e.g., recruiting / recruiting closed).

[0074] (5) Virtual standby management information Storage 21 stores virtual waiting management information for each virtual waiting room, which manages the applicants for member recruitment. As illustrated in Figure 5(e), the virtual waiting management information associates at least one or more "applicants" (player IDs) with the "virtual waiting room ID".

[0075] [2-5. Group Registration] [2-5-1. Short distance recruitment] (1) Recruitment procedures for short-distance recruitment Figure 6 illustrates the recruitment procedure in short-distance recruitment. Figure 6 shows the procedure for short-distance recruitment when a player (host) using user terminal 30a selects a composite lottery (multi-gacha).

[0076] In S605, the user terminal 30a receives an instruction from the host to display the gacha selection screen. This instruction is, for example, a tap on a button (link) displayed in the menu on the game application screen. In S610, the user terminal 30a receives a selection operation from the host 1 for the lottery (gacha). This selection operation is, for example, a tap on a gacha selection button displayed on the game application screen.

[0077] In S615, the user terminal 30a accepts the host's selection of a multi-gacha (combined lottery). This selection is, for example, a tap on a button displayed on the game app screen along with text indicating a multi-gacha. In S620, the user terminal 30a accepts the host's selection of a multi-gacha based on nearby recruitment. This selection is, for example, a tap on a button displayed on the game app screen with "nearby" or similar text.

[0078] In S625, the user terminal 30a receives a command operation from the host to recruit nearby members. In this embodiment of the service, the host can set a password (for example, a three-digit number sequence) when recruiting members. If a password is set, the setting is also accepted. If a password is set automatically, the password is displayed. In S630, the user terminal 30a determines its current location. The GPS unit 390 is used to determine the current location.

[0079] In S635, the user terminal 30a instructs the user management server 10 to request a nearby location. This instruction may include a set password and location data indicating the current location of the user terminal 30a. In S640, the user management server 10 notifies the user terminal 30a that the nearby location request has been received. In S645, the user management server 10 registers new virtual waiting room information (Figure 5(d)) and virtual waiting management information (Figure 5(e)) in the storage 21 and creates a virtual waiting room. At this time, the "recruitment category" is nearby location, the "participation condition" is being located near the location indicated by the location data included in the recruitment instruction, and the "status" is recruiting. If the recruitment instruction includes a password, that password also constitutes a "participation condition".

[0080] (2) Application procedures for short-distance recruitment Figure 7 illustrates the application procedure for a nearby recruitment. Figure 7 shows the application procedure for a nearby recruitment when a player (guest) using user terminal 30b selects a combined lottery (multi-gacha).

[0081] In S705, the user terminal 30b receives an instruction operation from the guest to display the gacha selection screen. This instruction operation is, for example, a tap operation on a button (link) displayed in the menu on the game application screen. In S710, the user terminal 30b receives an operation from the guest to select a lottery (gacha). This selection operation is, for example, a tap operation on a gacha selection button displayed on the game application screen.

[0082] In S715, the user terminal 30b receives a search instruction from the guest for nearby recruitment. If the guest specifies a password during the search, the terminal also accepts that specification. In S720, the user terminal 30b determines its current location. The GPS unit 390 is used to determine the current location.

[0083] In S725, the user terminal 30b instructs the user management server 10 to search for nearby recruitment (virtual waiting room) that meets the participation conditions. This instruction may include a specified password and location data indicating the current location of the user terminal 30b. In S730, the user management server 10 identifies nearby recruitment (virtual waiting room information) that meets the participation conditions for the guest from among the virtual waiting room information stored in storage 21.

[0084] In S735, the user management server 10 provides the search results to the user terminal 30b. In S740, the user terminal 30b notifies the user management server 10 of its selection of one of the two nearby recruitment opportunities, in response to the guest's actions. In S745, the user management server 10 grants the user terminal 30b permission to apply to the selected nearby recruitment opportunity.

[0085] In S750, user terminal 30b instructs user management server 10 to apply to the selected nearby recruitment in response to the guest's application instruction operation. In S755, user management server 10 adds the applicant's (guest's) player ID to the virtual waiting management information (Figure 5(e)) stored in storage 21 and accepts the guest's application to the selected nearby recruitment. In S760, user management server 10 notifies user terminal 30a that the application to the nearby recruitment has been accepted.

[0086] [2-5-2. Recruitment via SNS] (1) Recruitment procedures for SNS recruitment Figure 8 illustrates the recruitment procedure in SNS recruitment. Figure 8 shows the SNS recruitment procedure for a player (guest) using user terminal 30b when a combined lottery (multi-gacha) is selected by a player (host) using user terminal 30a.

[0087] In S805, the user terminal 30a receives an instruction from the host to display the gacha selection screen. This instruction is, for example, a tap on a button (link) displayed in the menu on the game application screen. In S810, the user terminal 30a receives an instruction from the host to select a lottery (gacha). This selection is, for example, a tap on a gacha selection button displayed on the game application screen.

[0088] In S815, the user terminal 30a accepts the host's selection of a combined lottery (multi-gacha). This selection is, for example, a tap operation on a button displayed on the game app screen along with text indicating multi-gacha. In S820, the user terminal 30a accepts the host's selection of a combined lottery (SNS multi-gacha) via SNS recruitment. This selection is, for example, a tap operation on a button displayed on the game app screen with "SNS" or similar text.

[0089] In S825, user terminal 30a receives an instruction from the host to initiate an SNS recruitment. In S830, user terminal 30a instructs user management server 10 to initiate an SNS recruitment. In S835, user management server 10 notifies user terminal 30a that it has received the SNS recruitment. This notification may include a URL with an SNS program startup command and data that can identify the recruitment. In S840, user terminal 30a sends a message containing the above URL to user terminal 30b, either directly or indirectly via another device, outside the system of this embodiment.

[0090] In S845, user terminal 30a instructs user management server 10 to start the SNS recruitment by accessing the above URL. In S850, user management server 10 notifies user terminal 30a that it has received the instruction to start the SNS recruitment. In S855, user management server 10 registers new virtual waiting room information (Figure 5(d)) and virtual waiting management information (Figure 5(e)) in storage 21 and creates a virtual waiting room. At this time, the "recruitment category" is SNS recruitment, the "participation conditions" are applications by accessing the above URL, and the "status" is recruiting.

[0091] (2) Application procedure for recruitment via social media Figure 9 illustrates the application procedure for SNS recruitment. Figure 9 shows the application procedure for SNS recruitment when a player (guest) using user terminal 30b selects a combined lottery (multi-gacha).

[0092] 3 In S920, the user terminal 30b instructs the user management server 10 to search for SNS recruitment (virtual waiting room) that meets the participation requirements by accessing the above URL. In S925, the user management server 10 identifies an SNS recruitment (virtual waiting room information) that meets the participation requirements for the guest from among the virtual waiting room information stored in storage 21.

[0093] In S930, the user management server 10 provides the search results to the user terminal 30b. In S935, the user terminal 30b selects and notifies the user management server 10 of the SNS recruitment in response to the guest's operation. In S940, the user management server 10 grants the user terminal 30b permission to apply to the selected SNS recruitment.

[0094] In S945, user terminal 30b instructs user management server 10 to apply to the selected SNS recruitment in response to the guest's application instruction operation. In S950, user management server 10 adds the applicant's (guest's) player ID to the virtual waiting management information (Figure 5(e)) stored in storage 21 and accepts the guest's application to the selected SNS recruitment. In S955, user management server 10 notifies user terminal 30a that the application to the SNS recruitment has been accepted.

[0095] [2-5-3. Group Registration] Figure 10 illustrates the group registration procedure for recruiting members. Figure 10 shows the procedure for group registration after verification by the player (host) using user terminal 30a.

[0096] In S1005, the user terminal 30a presents member candidates to the host. The presentation can be, for example, a list display of member candidates. The displayed items may include, for example, the nickname of the member candidate. When a corresponding area is reached or tapped, detailed information about that member may be displayed. The detailed information may include the content of the reward that the user wishes to receive. In S1010, the host accepts a member confirmation command operation.

[0097] In S1015, the user terminal 30a instructs the user management server 10 to register a group in response to the host's operation. In S1020, the user management server 10 registers a new group. Here, group member management information (Figure 5(b)) is generated, with the "recruiter" from the virtual waiting room information (Figure 5(d)) and each "applicant" stored in the virtual waiting management information (Figure 5(e)) as members, respectively. Also, group status management information (Figure 5 (c)) is generated.

[0098] [2-6. Composite lottery] Figure 11 illustrates the procedure for executing a combined lottery. Both the combined lottery performed by the player (host) using user terminal 30a and the combined lottery performed by the player (guest) using user terminal 30b can be started at any time after group registration is complete. Therefore, each player in the group can coordinate the start of the lottery procedure so that they can learn about the contents of the additional gacha rewards from a combined lottery started by another player before starting their own combined lottery.

[0099] In S1105, the user terminal 30 instructs the user management server 10 to start the lottery (gacha). This instruction by the host may be made, for example, at the same time as the instruction to register a group (S1015 in Figure 10), or at any time after group registration. This instruction by the guest is made at any time after group registration.

[0100] In S1110, the user terminal 30 displays an attribute selection screen. In this embodiment, the five character attribute options are presented. In S1115, the user terminal 30 accepts the attribute selection from the host 4 or guest. In S1120, the user terminal 30 sends the attribute selection information to the user management server 10 and instructs it to execute the lottery process. The transmission of this selection information corresponds to a request that probabilistically increases the likelihood of obtaining a specific reward. In S1125, the user terminal 30 starts the lottery (gacha) execution animation.

[0101] In S1130, the user management server 10 performs a lottery process. In this embodiment, five characters with a level of 6 (maximum value) in the selected attributes are selected. In S1135, the user management server 10 provides the lottery results to the user terminal 30. In this embodiment, information on the five characters is provided.

[0102] In S1140, the user terminal 30 presents reward candidates. In this embodiment, the five characters provided in S1135 are presented. In S1145, the user terminal 30 accepts the selection of reward candidates. In S1150, the user terminal 30 transmits the selected reward candidate information to the user management server 10. The transmission of this selection information corresponds to a request that definitively improves the likelihood of obtaining a specific reward.

[0103] In S1155, the user management server 10 grants the selected candidates as gacha rewards to the players who participated in this lottery procedure. In addition, it grants gacha supplementary rewards equivalent to the said gacha rewards to other players who did not participate in the lottery procedure, provided that they belong to the same group as the players who participated. The granting of rewards is done, for example, by associating the ID of the character to be granted as a reward with each player's player ID and storing it in storage 21.

[0104] In S1160, the user management server 10 notifies the user terminal 30 that the distribution of gacha rewards has been completed. At this time, other players are also notified that additional gacha rewards have been distributed. In S1165, the user terminal 30 executes the lottery (gacha) result animation.

[0105] [3. Variant] [3-1. Variation 1] In this embodiment, since each player is not permitted to belong to multiple groups, only one "Group ID" can be associated with a "Player ID" (Figure 5(a)). In contrast, each player may be permitted to belong to multiple groups. In this case, multiple "Group IDs" can be associated with a "Player ID".

[0106] [3-2. Variation 2] In this example, the "Target Category" is fixed to the category representing gacha rewards. However, the "Reward Category" may be any other category. For example, it may be a category representing rewards for completing quests. For example, the system may be configured to allow the creation of relationships (group registration) for each "Target Category".

[0107] [3-3. Modified Example 3] The host's request for a partner to be registered can be displayed to guests considering applying for that request, and the host and the guest who applied for the member recruitment can be registered as a couple. This makes it easier for players with the same acquisition request to build relationships.

[0108] [3-4. Modification 4] Information about hosts who are seeking partners to associate with them, based on their acquisition preferences, may be provided to guests in response to search requests that specify search criteria related to acquisition preferences. The hosts and guests who have applied to join the group may then be registered in association. This makes it easier for players with the same acquisition preferences to build relationships.

[0109] [3-5. Variation 5] A first group including player A and player B, and a second group including player A but not player B, may be registered separately. The first additional benefit may be granted to player B only if the first group is included in one or more designated first groups to which the first additional benefit is to be granted. This allows for adjustment of who receives the additional benefit when player A belongs to multiple groups.

[0110] At this time, a third group including Player B but excluding Player A is further registered, and the second additional benefit is granted to Player A only if the first group is included in the one or more second designated groups to which the second additional benefit is granted. This makes it possible to adjust the recipients of the additional benefit when Player B belongs to multiple groups.

[0111] At this time, the first designated group is identified according to at least one of the following: the designation by the players belonging to the first group, the nature of the acquisition process for the first benefit, or the content of the first benefit. This allows the first designated group to be identified manually or automatically. Similarly, the second designated group is identified according to at least one of the following: the designation by the players belonging to the second group, the nature of the acquisition process for the second benefit, or the content of the second benefit. This allows the second designated group to be identified manually or automatically. [Explanation of Symbols]

[0112] 10. User Management Server (An example of a "Game Information Processing Unit") 20 Data Management Server 21 Storage 30 User terminals 40 Communication Networks 410 Registration Department 411 Recruitment Department 412 Search Section 413 Application Reception Department 414 Registration Department 420 Lottery section 421 Reception Department 423 Assignment section 424 Hochi Department

Claims

1. A registration means for registering the first player and the second player in association, Granting means for granting a first additional benefit to a second player who was not involved in the process of obtaining the first benefit, provided that the second player is registered in association with the first player, when the first benefit is granted to the first player who was involved in the process of obtaining the first benefit. A game information processing device equipped with the following features.

2. The granting means further grants the second additional benefit to the first player who was not involved in the process of obtaining the second benefit, provided that the first player is registered in association with the second player, when the second benefit is granted to the second player who was involved in the process of obtaining the second benefit. The game information processing device according to claim 1.

3. The system further includes a means for receiving requests from the second player to improve the likelihood of obtaining the second bonus during the process of obtaining the second bonus, The granting means grants the first player a second additional benefit equivalent to the second benefit when the second benefit, which is determined in response to or in consideration of a request from the second player received by the receiving means, is granted to the second player. The game information processing device according to claim 2.

4. The system further includes a notification means for informing the second player of the details of the first additional benefit to be granted to the second player, The receiving means receives a request from the second player to improve the availability of the second bonus after the content of the first bonus has been notified to the second player. The game information processing device according to claim 3.

5. The registration means registers the first player, the second player, and the third player in association with each other. The granting means further grants the third additional benefit to the first and second players who were not involved in the acquisition process of the third benefit, provided that they are registered in association with the third player, when the third benefit is granted to the third player who was involved in the acquisition process of the third benefit, and also grants the first additional benefit and the second additional benefit to the third player who was not involved in either the acquisition process of the first benefit or the acquisition process of the second benefit, provided that they are registered in association with the first and second players, respectively. The game information processing device according to claim 4.

6. The receiving means further receives requests to improve the likelihood of the first player obtaining the first reward during the process of obtaining the first reward, The granting means grants the second player and the third player the first additional benefit equivalent to the first benefit when the first benefit, which is determined in response to or in consideration of a request from the first player received by the receiving means, is granted to the first player. The game information processing device according to claim 5.

7. The notification means further notifies the first player of the content of the third additional benefit to be granted to the first player, The receiving means receives a request from the first player to improve the availability of the first bonus after the content of the third additional bonus has been notified to the first player. The game information processing device according to claim 6.

8. The system further includes a means for presenting the first player's desire to acquire a partner for association registration to the second player who is considering applying for the said recruitment, The registration means registers the first player and the second player who applied to the recruitment by the first player in association with each other. The game information processing device according to claim 3 or claim 4.

9. The system further comprises a search means that provides information about the first player, who has set a request for acquisition and is seeking a partner for association registration, to the second player in response to a search request that specifies search conditions for the acquisition request. The registration means registers the first player and the second player who applied to the recruitment by the first player in association with each other. The game information processing device according to claim 3 or claim 4.

10. The registration means registers a first group including the first player and the second player, and a second group including the first player but not including the second player, The granting means grants the first additional benefit to the second player only if the first group is included in the one or more designated groups to which the first additional benefit is granted. A game information processing device according to any one of claims 1 to 4, 8, or 9.

11. The registration means further registers a third group which includes the second player but does not include the first player, The granting means grants the second additional benefit to the first player only if the first group is included in the one or more designated groups to which the second additional benefit is granted. The game information processing device according to claim 10.

12. The granting means identifies a designated group according to at least one of the following: designation by the player, the nature of the process of obtaining the reward, or the content of the reward. The game information processing device according to claim 10 or claim 11.

13. The registration stage involves registering the first player and the second player in association, In the case where the first bonus is granted to the first player who was involved in the process of obtaining the first bonus, the first additional bonus is granted to the second player who was not involved in the process of obtaining the first bonus, on the condition that the second player is registered in association with the first player. A control method for an information processing device, including the control method for an information processing device.

14. A registration function that associates and registers the first player and the second player, A granting function that grants the first additional bonus to the second player who was not involved in the acquisition process of the first bonus, provided that the second player is registered in association with the first player, when the first bonus is granted to the first player who was involved in the acquisition process of the first bonus. A control program that enables the computer of an information processing device to implement this.

Images