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

JP2025036522AActive Publication Date: 2025-03-14MIXI INC
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2024227813
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-12-24
Publication Date
2025-03-14
Estimated Expiration
2038-09-28

AI Technical Summary

Benefits of technology

【0011】 本発明によれば、第1プレイヤにある特典が付与される場合に第2プレイヤにも付加特典が付与される。よって、関係を構築したプレイヤどうしを関連付けて登録するように本発明を使用すれば、ゲームのプレイヤどうしが積極的に関係を構築しようとすることが期待できる。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025036522000001_ABST
    Figure 2025036522000001_ABST
Patent Text Reader

Abstract

To efficiently guide game players so that the players construct relationships.SOLUTION: A "game information processing device" (e.g., a user management server 10) includes: means to associate and register a first player and a second player (e.g., a registration part 410 and a registration part 414); and means to grant a first additional privilege (e.g., a lottery part 420 and a granting part 423) to the second player who is not involved in a first privilege acquisition process on condition that the second player is registered in association with the first player in a case where the first privilege is granted to the first player who is involved in the first privilege acquisition process.SELECTED DRAWING: Figure 4
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to an electronic game that uses a display capable of displaying two or more dimensions. [Background technology]

[0002] There are known electronic games that have a mechanism for allowing multiple users to share the lottery process. 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 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] JP 2017-055790 A Summary of the Invention [Problem to be solved by the invention]

[0004] In the game system described in Patent Document 1, the recipient of a game item according to the result of a lottery process for a group is set to one of the users belonging to the group. Therefore, it is not assumed that a game item according to the result of a lottery process for a group will be given to multiple users who each belong to the group. In addition, it is not assumed that the game item will be given to a user with whom the screen information of the lottery process is not shared.

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

[0006] In order to solve the above problem, the present invention provides a method for providing an additional benefit to a second player who is not involved in a process of obtaining a benefit, when the second player is provided with the benefit, on condition that the second player is registered in association with the first player. The present invention includes, for example, the following aspects.

[0007] [A] A "game information processing device" according to one embodiment of the present invention comprises a registration means for registering a first player and a second player in association with each other, and an awarding means for awarding a first additional benefit to the second player not involved in the acquisition process when the first benefit is awarded to the first player involved in the process of acquiring the first benefit, on the condition that the second player is registered in association with the first player.

[0008] [B] A "control method" of an information processing device which is one embodiment of the present invention includes a registration step of registering a first player and a second player in association with each other, and an awarding step of awarding a first additional benefit to the second player not involved in the acquisition process when the first benefit is awarded to the first player involved in the process of acquiring the first benefit, on the condition that the second player is registered in association with the first player.

[0009] [C] The "control program" which is one aspect of the present invention causes a computer of an information processing device to realize 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 the second player not involved in the acquisition process when the first benefit is granted to the first player involved in the process of obtaining the first benefit, on the condition that the second player is registered in association with the first player.

[0010] [D] A control program recorded in a "computer-readable recording medium" which is one embodiment of the present invention causes a computer of an information processing device to realize a registration function of registering a first player and a second player in association with each other, and a granting function of granting a first additional benefit to the second player not involved in the acquisition process when the first benefit is granted to the first player involved in the process of obtaining the first benefit, on the condition that the second player is registered in association with the first player. Effect of the Invention

[0011] According to the present invention, when a certain privilege is granted to a first player, an additional privilege is also granted to a second player. Therefore, by using the present invention to associate and register players who have built a relationship with each other, it is expected that players of a game will actively try to build relationships with each other.

[0012] The following technical limitations may be added to the "game information processing device" in [A] above. In addition, similar technical limitations may be added 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.

[0013] (1) When the second benefit is awarded to the second player who was involved in the process of acquiring the second benefit, the awarding means further awards a second additional benefit to the first player who was not involved in the process of acquiring the second benefit, on condition that the first player is registered in association with the second player. This provides benefits to both parties registered in association, and is expected to encourage players to build relationships more proactively.

[0014] (2) The system further comprises a receiving means for receiving a request from the second player to increase the availability of the second benefit in the process of obtaining the second benefit, and the granting means grants the first player the second additional benefit equivalent to the second benefit when the second benefit determined in response to or taking into account the request from the second player received by the receiving means is granted to the second player. This increases the availability of a specific benefit and allows a strategy to be adopted that reduces the possibility of the benefits overlapping, so that players who have the same first and second preferred benefits are expected to actively try to build relationships with each other.

[0015] (3) The game system further comprises a notification means for notifying the second player of the content of the first additional benefit to be given to the second player, and the reception means receives a request for increasing the availability of the second benefit made by the second player after the content of the first additional benefit is notified to the second player. This makes it possible to switch to a strategy of increasing the availability of the second benefit once the first preferred benefit is obtained, so that players who have the same first and second preferred benefits are expected to more actively try to build relationships with each other.

[0016] (4) The registering means registers the first player, the second player, and the third player in association with each other, and the granting means further grants a third additional privilege to the first player and the second player not involved in the acquisition process on condition that they are registered in association with the third player when the third privilege is granted to the third player involved in the process of obtaining the third privilege, and grants the first additional privilege and the second additional privilege to the third player not involved in either the process of obtaining the first privilege or the process of obtaining the second privilege on condition that they are registered in association with the first player and the second player, respectively. This provides benefits to everyone who has built a relationship, 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 increase the availability of the first benefit in the process of obtaining the first benefit, and the granting means grants the second player and the third player the first additional benefit equivalent to the first benefit when the first benefit determined in accordance with the request from the first player received by the receiving means or taking the request into consideration is granted to the first player. This increases the availability of a specific benefit and allows a strategy to be adopted that reduces the possibility of duplicated acquisition of the benefit, so that players who have the same first, second, and third preferred benefits are expected to 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 given to the first player, and the receiving means receives a request for increasing the availability of the first benefit made by the first player after the content of the third additional benefit is notified to the first player. This makes it possible to switch to a strategy of increasing the availability of the second preferred benefit when the first preferred benefit is obtained, and subsequently to a strategy of increasing the availability of the third preferred benefit when the second preferred benefit is obtained, so that players having the same first, second and third preferred benefits are expected to more actively try to build relationships with each other.

[0019] (7) A presentation means is further provided for presenting the desire of the first player who is seeking a partner for association registration to the second player who is considering applying for the invitation, and the registration means registers the first player and the second player who applied for the invitation by the first player in association with each other. This makes it easier for players with the same desire to build a relationship.

[0020] (8) A search means is further provided for providing information about the first player who has set a request for acquisition and is looking for a partner for association registration to the second player in response to a search request specifying search conditions related to the request for acquisition, and the registration means registers the first player and the second player who applied for the request by the first player in association with each other. This makes it easier for players with the same request to build a relationship.

[0021] (9) The registering 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, and the granting means grants the first additional benefit to the second player only if the first group is included in one or more designated groups to which the first additional benefit is to be granted. This makes it possible to adjust the grant destination of the additional benefit when the first player belongs to multiple groups.

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

[0023] (11) The granting means specifies the designated group in accordance with at least one of the following: designation by a player, the nature of the process of obtaining the privilege, and the contents of the privilege. In this way, the designated group is specified manually or automatically.

[0024] In this specification, the following terms are used:

[0025] (1) "Game" refers to an electronic game provided at least in part through an 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 a game service. An individual stage is sometimes called a quest. "Player" refers to a user of a game service. "Play" refers to a player progressing through a particular game.

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

[0027] (3) "Benefit" includes rewards and operations that directly or indirectly contribute to playing the game advantageously. Rewards include in-game elements (e.g., currency items, recovery items, synthesis material items, characters, and other objects). Operation includes advantageous handling (e.g., setting or changing parameters used in or outside a stage in a direction that is advantageous to the player). "Giving" a benefit includes, for example, associating and registering an in-game element as a reward with a player, and applying advantageous handling as an operation to a player.

[0028] (4) The "process of acquiring" a privilege refers to a series of steps until the privilege is acquired. The "process of acquiring" may be limited to a series of steps performed after players are associated with each other and registered (in the embodiment, after group registration is performed). The procedure includes processing by various devices and operations by players. The "process of acquiring" a privilege may be a sufficient condition for acquiring the privilege, or may be a necessary condition for acquiring the privilege. For example, if a certain privilege (e.g., a reward for clearing a quest) is definitely granted on the condition that a certain mission (e.g., clearing a certain stage in a game) is accomplished, a series of steps from the start of the challenge to the completion of the mission corresponds to the process of acquiring the privilege. Also, for example, if a certain privilege (e.g., a reward for the result of a gacha) is granted through a certain event (e.g., a gacha in a game), a series of steps from the start to the end of the event corresponds to the process of acquiring the privilege.

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

[0030] (6) "Additional benefit" refers to a special benefit that is similar to a normal benefit and is given to a player who is not involved in the process of obtaining the normal benefit or who has not contributed to obtaining the normal benefit. An "additional benefit" may be a benefit that is the same as a normal benefit, or a benefit that is different from the normal benefit. For example, if a normal benefit is a game element as a reward, an additional benefit may also be the same game element.

[0031] (7) "Request to improve the availability of a benefit" refers to a request to probabilistically or deterministically improve the availability of a specific benefit candidate among multiple benefit candidates. The availability may be improved absolutely or relatively. The number of requests may be singular or multiple. For example, a request to select a specific benefit candidate, a request to relatively increase the selection probability of a specific benefit candidate, a request to narrow down the options of benefit candidates so that a specific benefit candidate remains, etc. are included in "request to improve the availability of a benefit". A request to narrow down the options of benefit candidates including a specific benefit candidate includes, for example, a request to exclude at least some of the benefit candidates other than the specific benefit candidate from the options, a request to leave only the candidates of a group to which the specific benefit candidate belongs from the options, a request to exclude at least some of the candidates of a group to which the specific benefit candidate does not belong from the options, a request to exclude some of the benefit candidates other than the specific benefit candidate from the options, etc.

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

[0033] [Figure 1] FIG. 1 is a block diagram illustrating a network configuration of a game system according to an embodiment of the present invention. [Diagram 2] FIG. 1 is a block diagram illustrating an example of an electrical configuration of a server device (embodiment); [Diagram 3] FIG. 1 is a block diagram illustrating an example of an electrical configuration of a user device (embodiment); [Figure 4] FIG. 1 is a block diagram illustrating a functional configuration of a user management server according to an embodiment of the present invention; [Diagram 5] FIG. 13 is an explanatory diagram illustrating an example of a data configuration related to a lottery function (Example); [Figure 6] FIG. 13 is a sequence diagram illustrating a recruitment procedure in short-distance recruitment (embodiment); [Figure 7] FIG. 13 is a sequence diagram illustrating an application procedure for short-distance recruitment (embodiment); [Figure 8] FIG. 13 is a sequence diagram illustrating a recruitment procedure in SNS recruitment (embodiment); [Figure 9] FIG. 13 is a sequence diagram illustrating an application procedure for SNS recruitment (embodiment); [Figure 10] FIG. 11 is a sequence diagram illustrating a procedure for registering a group (embodiment); [Figure 11] FIG. 13 is a flow diagram illustrating an example of a procedure for executing a composite lottery (embodiment). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] [1. Embodiment] [1-1. Overview] In this embodiment, in order to efficiently induce players of a game to build relationships with each other, when a first player who has been involved in the process of acquiring a certain benefit is given the benefit, an additional benefit is given to a second player who has not been involved in the process of acquiring the benefit, on the condition that the second player is associated and registered with the first player. Therefore, if players who have built relationships are registered in association with each other, it is expected that players of the game will actively try to build relationships with each other.

[0035] [1-2. Game information processing device] A game information processing device (e.g., user management server 10) according to an embodiment includes means for registering a first player and a second player in association with each other (e.g., registration unit 410, registration unit 414), and means for granting a first additional benefit to the second player not involved in the acquisition process when the first benefit is granted to the first player involved in the process of acquiring the first benefit, on the condition that the second player is registered in association with the first player (e.g., lottery unit 420, granting unit 423). EXAMPLES

[0036] 2. Working Examples [2-1. Overview of Game Services] This embodiment relates to a game service (hereinafter referred to as the "service of the embodiment") at least part of which is provided online. In the service of the embodiment, an electronic game (game in a broader sense) is provided to a player in which the player sequentially controls four characters (monsters) that make up a deck by performing predetermined actions, and sequentially challenges a plurality of stages (game in a narrower sense) prepared within the game. Hereinafter, the stages are referred to as "quests."

[0037] [2-2. Overview of lottery function] In addition, in the electronic game in the service of the embodiment, a mechanism (lottery function) is provided for the player to challenge a lottery (gacha) outside of a quest, either in exchange for consuming specific in-game elements (e.g., currency items, exchange items) or unconditionally, and obtain a reward as a result of the lottery (gacha reward). The lottery function is implemented in a game system (hereinafter referred to as the "system of the embodiment") that provides the service of the embodiment.

[0038] There are two types of lottery challenges: a single player challenges alone (single gacha), and a multi-player challenge (multi-gacha) in which two to four players registered in a group cooperate to challenge. In a multi-player lottery, the results of each player's individual challenges to the lottery are shared with other players in the same group.

[0039] [2-3. Overview of the Composite Lottery] The lottery function of this embodiment efficiently guides players of the game to register as groups (an example of "building relationships"), so that when a regular gacha reward (an example of a "benefit") is awarded to a player belonging to a certain group through a lottery procedure (the process of obtaining a gacha reward), an additional reward (an example of an "additional benefit") equivalent to the regular gacha reward is awarded to other players who are not involved in the lottery procedure after group registration (in other words, other players who are not in a position to be awarded a regular gacha reward) on the condition that they belong to the same group.

[0040] Specifically, the lottery function of this embodiment accepts a request from a player to increase the availability of a specific gacha reward in each lottery procedure of a composite lottery, awards the player a gacha reward determined in accordance with or taking into account the request, and awards additional rewards equivalent to the gacha reward to other players who belong to the same group as the player.

[0041] Each player can start the lottery procedure of the composite lottery at any time after group registration. In particular, each player can request to increase the availability of a specific gacha reward in the lottery procedure in which he / she is involved after learning the content of the additional reward that will be granted to him / her through the lottery procedure in which other players belonging to the same group are involved.

[0042] These features allow players who have registered as a group to cooperate with each other to adopt a strategy that improves the availability of a specific reward while reducing the possibility of duplication of the reward. Each time a reward with a relatively high desired level (gacha reward, additional reward) is obtained, the strategy can be switched to one that improves the availability of rewards with a relatively low desired level (gacha reward, additional reward). Therefore, the lottery function according to this embodiment is expected to encourage players who desire the same reward to actively build relationships with each other.

[0043] [2-4. System configuration of the embodiment] [2-4-1. Network configuration] (1) Overview Fig. 1 illustrates a network configuration of a system according to an embodiment. As illustrated in Fig. 1, the system according to the embodiment includes a user management server 10 that manages users of the service according to the embodiment, a data management server 20 that manages data related to the service according to the embodiment, and a plurality of user terminals 30 (30-1, 30-2, ... 30-n) (n: natural number) that are used by a plurality of users, respectively.

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

[0045] The communication network 40 may include at least one of existing networks such as the Internet, a mobile phone network, a wireless wide area network (WAN), a wireless local area network (LAN), and Ethernet (registered trademark).

[0046] (2) User management server The user management server 10 is a server device (computer) in which a Web server program is installed.

[0047] In response to a request, the user management server 10 causes the data management server 20 to obtain necessary data from the storage 21 and provides the data to the request source (response). In addition, in response to a request, the user management server 10 causes the data management server 20 to register necessary data in the storage 21.

[0048] A server system may be configured by linking a plurality of 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 dispersed.

[0049] (3) Data management server The data management server 20 is a server device (computer) in which a DB server program is installed. The data management server 20 and the storage 21 constitute a DBMS (DataBase Management System).

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

[0051] A server system may be configured by linking a plurality of server devices to share the functions of the data management server 20 or to distribute the load on the data management server 20. Also, a plurality of storage devices may be prepared and the storage 21 may store data separately for each type, or the data stored in the storage 21 may be distributed among a plurality of storage devices.

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

[0053] In this embodiment, the user device may be a general-purpose portable device (e.g., a mobile phone, a smartphone, a tablet terminal, a tablet PC (personal computer), a wearable device, etc.) on which a program can be installed, 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 FIG. 2 illustrates an electrical configuration of a server device. The server device illustrated in FIG. The system has a control processing device 210 including a Micro-Processing Unit (Micro-Processing Unit) and a ROM (Read Only Memory), a main memory device 220 including a RAM (Random Access Memory), an auxiliary memory device 230 including a HDD (Hard Disc Drive), an input device 240 including a mouse and a keyboard, an output device 250 including a display and speakers, and a communication control device 260 including a network card (Network Interface Card).

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

[0056] The control processing device 210 (1) loads a program stored in the auxiliary memory device 230 onto the main memory device 220, (2) acquires data from at least one of the input device 240, the auxiliary memory device 230, and the communication control device 260 in accordance with the instructions of the program, (3) calculates and processes the acquired data in accordance with a procedure specified in the program, and (4) provides the calculated and processed data to at least one of the auxiliary memory device 230, the output device 250, and the communication control device 260.

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

[0058] The RAM 320, the ROM 330, the EEPROM 340, the touch panel display 350, the speaker 360, the NIC 370, the wireless LAN chip 380, and the GPS unit 390 are connected to the MPU 310 via a bus line.

[0059] MPU 310 (1) loads a program stored in ROM 330 or EEPROM 340 onto RAM 320, (2) acquires data from at least one of touch panel display 350, EEPROM 340, NIC 370, wireless LAN chip 380, and GPS unit 390 in accordance with instructions from the program, (3) calculates and processes the acquired data in a procedure specified in the program, and (4) provides the calculated and processed data to at least one of EEPROM 340, touch panel display 350, speaker 360, NIC 370, and wireless LAN chip 380.

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

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

[0062] The recruitment reception unit 411 accepts recruitment of group members related to the composite lottery by a player who wants to try the composite lottery (hereinafter referred to as "member recruitment"). The member recruitment searches for member recruitment targeting other players located in the vicinity of the recruiter (hereinafter referred to as "close-distance recruitment") and member recruitment targeting other 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 a request from a player who is going to try the combined lottery. The search unit 412 searches for, for example, short-distance recruitment or SNS recruitment. The application acceptance unit 413 accepts an application for a specific member recruitment from a player who is going to try the combined lottery.

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

[0065] The reception unit 421 receives a request from a player to increase the availability of a specific gacha reward in a lottery procedure that the player is trying. In this embodiment, the request to increase the availability of a specific gacha reward is a combination of a request to probabilistically increase the availability of a specific gacha reward candidate from among multiple gacha reward candidates, and a request to deterministically increase the availability. More specifically, the reception unit 421 receives, in this order, a request to specify an attribute to narrow down the options for gacha reward candidates, and a request to select a specific gacha reward candidate from the gacha reward candidates presented as options.

[0066] The execution unit 422 determines candidates for gacha rewards (in-game characters) to be given to a player in a lottery procedure that the player challenges, taking into consideration the request accepted by the acceptance unit 421. In this embodiment, in the first stage, the player is made to select one of five character attributes, and in the second stage, five characters that satisfy a predetermined criterion in the selected character attribute are selected. The predetermined criterion is, for example, that the character level is equal to or higher than a predetermined value.

[0067] The granting unit 423 grants a normal gacha reward to a player who has executed the lottery procedure. The granting unit 423 also grants a gacha additional reward equivalent to the gacha reward to other players who have not been involved in the lottery procedure, on condition that they belong to the same group as the player. The granted reward (character) is added to the character box in the game app of each player.

[0068] When a regular gacha reward is given to a player who has executed the lottery procedure, and a gacha additional reward equivalent to the gacha reward is given to another player, the notification unit 424 notifies the other player of the content of the gacha additional reward. The notification means is arbitrary. In this embodiment, the fact that the gacha additional reward has been given is explicitly or suggestively notified by displaying a predetermined icon on the home screen of the game app, for example.

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

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

[0071] (2) Group member management information The storage 21 stores group member management information for managing members belonging to each group. As illustrated in Fig. 5(b), the group member management information associates at least a "recruiter" (player ID) and one or more "applicants" (player IDs) with a "group ID."

[0072] (3) Group status information The storage 21 stores group status information that manages the status for each group. As illustrated in FIG. 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 of a category indicating the gacha reward. The "status" indicates the status of the group (e.g., valid / invalid). The status of the group is set to valid, for example, when the group is registered, and is updated to invalid after all players belonging to the group execute the lottery procedure.

[0073] (4) Virtual waiting room information The 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 FIG. 5(d), the virtual waiting room information associates at least a "recruiter" (player ID), a "recruitment category", a "participation conditions", and a "status" with a "virtual waiting room ID". The "recruitment category" indicates, for example, a short-distance recruitment for recruiting members located in the vicinity, or an SNS recruitment for recruiting members outside the system of the embodiment. The "participation conditions" are, for example, a time condition, a spatial condition (geographical condition), a password, etc. The "status" indicates the status of member recruitment (for example, recruiting / recruitment completed).

[0074] (5) Virtual standby management information The storage 21 stores virtual waiting management information for managing applicants for member recruitment for each virtual waiting room. As exemplified in FIG. 5(e), the virtual standby management information at least associates one or more "applicants" (player IDs) with a "virtual standby room ID."

[0075] [2-5. Group registration] [2-5-1. Short distance recruitment] (1) Recruitment procedures for short-distance recruitment Fig. 6 illustrates a recruitment procedure in short-distance recruitment. Fig. 6 illustrates the procedure for short-distance recruitment when a combined lottery (multi-gacha) is selected by a player (host) using the user terminal 30a.

[0076] In S605, the user terminal 30a accepts an instruction operation by the host to display a gacha selection screen. The instruction operation is, for example, a tap operation on a button (link) displayed in a menu on the game application screen. In S610, the user terminal 30a accepts a selection operation of a lottery (gacha) by the host 1. The selection operation is, for example, a tap operation 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 combined lottery (multi-gacha). The selection is, for example, a tap operation on a button displayed on the game app screen together with a message meaning multi-gacha. In S620, the user terminal 30a accepts the host's selection of a combined lottery by short-distance recruitment. The selection is, for example, a tap operation on a button displayed on the game app screen as "short distance".

[0078] In S625, the user terminal 30a accepts an instruction operation for short-distance recruitment by the host. In the service of the embodiment, the host can set a password (e.g., a three-digit number string) 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 identifies the current location. The GPS unit 390 is used to identify the current location.

[0079] In S635, the user terminal 30a instructs the user management server 10 to recruit people in the short distance. The 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 of the acceptance of the short distance recruitment. In S645, the user management server 10 registers new virtual waiting room information (FIG. 5(d)) and virtual waiting management information (FIG. 5(e)) in the storage 21 and creates a virtual waiting room. At this time, the "recruitment category" is short distance recruitment, the "participation condition" is to be located in the vicinity of the location indicated by the location data included in the recruitment instruction, and the "status" is recruiting. Furthermore, if a password is included in the recruitment instruction, the password also constitutes the "participation condition".

[0080] (2) Application procedure for short-distance recruitment Fig. 7 illustrates an application procedure for a short-distance recruitment. Fig. 7 illustrates an application procedure for a short-distance recruitment when a combined lottery (multi-gacha) is selected by a player (guest) using the user terminal 30b.

[0081] In S705, the user terminal 30b accepts an instruction operation by the guest to display a gacha selection screen. The instruction operation is, for example, a tap operation on a button (link) displayed in a menu on the game application screen. In S710, the user terminal 30b accepts a selection operation of a lottery (gacha) by the guest. The 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 accepts a search instruction operation for nearby recruitment by the guest. If the guest specifies a password when searching, the specification is also accepted. In S720, the user terminal 30b identifies the current location. The GPS unit 390 is used to identify the current location.

[0083] In S725, the user terminal 30b instructs the user management server 10 to search for a short-distance recruitment (virtual waiting room) that satisfies the participation condition. The 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 a short-distance recruitment (virtual waiting room information) that satisfies the participation condition of the guest from among the virtual waiting room information stored in the storage 21.

[0084] In S735, the user management server 10 provides the search result to the user terminal 30b. In S740, the user terminal 30b selects one of the two short-distance recruitments in response to an operation by the guest and notifies the user management server 10. In S745, the user management server 10 permits the user terminal 30b to apply for the selected short-distance recruitment.

[0085] In S750, the user terminal 30b instructs the user management server 10 to apply for the selected short-distance recruitment in response to the guest's application instruction operation. In S755, the user management server 10 adds the player ID of the applicant (guest) to the virtual standby management information (FIG. 5(e)) stored in the storage 21, and accepts the application from the guest for the selected short-distance recruitment. In S760, the user management server 10 notifies the user terminal 30a of the acceptance of the application for the short-distance recruitment.

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

[0087] In S805, the user terminal 30a accepts an instruction operation by the host to display a gacha selection screen. The instruction operation is, for example, a tap operation on a button (link) displayed in a menu on the game application screen. In S810, the user terminal 30a accepts a selection operation of a lottery (gacha) by the host. The selection operation is, for example, a tap operation 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). The selection is, for example, a tap operation on a button displayed on the game application screen together with a wording meaning multi-gacha. In S820, the user terminal 30a accepts the host's selection of a combined lottery (SNS multi-gacha) by SNS recruitment. The selection is, for example, a tap operation on a button displayed on the game application screen as "SNS".

[0089] In S825, the user terminal 30a accepts the host's instruction operation for SNS recruitment. In S830, the user terminal 30a instructs the user management server 10 to recruit users for SNS. In S835, the user management server 10 notifies the user terminal 30a of the acceptance of the SNS recruitment. The notification may include a URL to which is added a command to start the SNS program and data that can identify the recruitment. In S840, a message including the above URL is sent from the user terminal 30a to the user terminal 30b, directly or indirectly via another device, outside the system of the embodiment.

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

[0091] (2) Application procedure for SNS recruitment Fig. 9 illustrates an example of an application procedure for an SNS recruitment. Fig. 9 illustrates an application procedure for an SNS recruitment in the case where a combined lottery (multi-gacha) is selected by a player (guest) using the user terminal 30b.

[0092] 3 In S920, the user terminal 30b instructs the user management server 10 to search for SNS invitations (virtual waiting rooms) that satisfy the participation conditions by accessing the above URL. In S925, the user management server 10 identifies SNS invitations (virtual waiting rooms) that satisfy the participation conditions of the guest from among the virtual waiting rooms stored in the 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 an SNS invitation in response to an operation by the guest. In S940, the user management server 10 permits the user terminal 30b to apply for the selected SNS invitation.

[0094] In S945, the user terminal 30b instructs the user management server 10 to apply for the selected SNS invitation in response to the application instruction operation by the guest. In S950, the user management server 10 adds the player ID of the applicant (guest) to the virtual standby management information (FIG. 5(e)) stored in the storage 21, and accepts the application from the guest to the selected SNS invitation. In S955, the user management server 10 notifies the user terminal 30a of the acceptance of the application for the SNS invitation.

[0095] [2-5-3. Group registration] Fig. 10 shows an example of a group registration procedure for recruiting members. Fig. 10 shows a procedure in which group registration is performed after confirmation by a player (host) using the user terminal 30a.

[0096] In S1005, the user terminal 30a presents the member candidates to the host. The presentation may be, for example, a list of the member candidates. The display items may include, for example, the nicknames of the member candidates. When an area corresponding to a member is tapped, detailed information about the member may be displayed. The detailed information may include the content of the reward desired to be obtained. In S1010, a member confirmation instruction operation by the host is accepted.

[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 (FIG. 5(b)) is generated, with the "recruiter" in the virtual waiting room information (FIG. 5(d)) and each "applicant" stored in the virtual waiting management information (FIG. 5(e)) as members. In addition, group status management information (FIG. 5(c)) is generated, with the "recruiter" in the virtual waiting room information (FIG. 5(d)) and each "applicant" stored in the virtual waiting management information (FIG. 5(e)) as members. (c)) is generated.

[0098] [2-6. Compound lottery] 11 illustrates an example of a composite lottery execution procedure. The composite lottery by the player (host) using the user terminal 30a and the composite lottery by the player (guest) using the user terminal 30b can both be started at any time after the group registration is completed. Therefore, each player in the group can start their own composite lottery by coordinating the start of the lottery procedure, after learning the contents of the gacha additional reward from the composite lottery started earlier by another player.

[0099] In S1105, the user terminal 30 instructs the user management server 10 to start a lottery (gacha). The host's instruction may be given at the same time as the group registration instruction (S1015 in FIG. 10), or at any time after the group registration. The guest's instruction is given at any time after the group registration.

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

[0101] In S1130, the user management server 10 executes a lottery process. In this embodiment, five characters of level 6 (maximum value) in the selected attribute are selected. In S1135, the user management server 10 provides the lottery result 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 the reward candidates. In S1150, the user terminal 30 transmits selection information of the reward candidates to the user management server 10. The transmission of the selection information corresponds to a request to deterministically increase the availability of a particular reward.

[0103] In S1155, the user management server 10 grants the selected candidate as a gacha reward to the player who participated in the lottery procedure. In addition, a gacha additional reward equivalent to the gacha reward is granted to other players who are not involved in the lottery procedure, on the condition that they belong to the same group as the player who participated. The granting of the reward is performed, for example, by storing the ID of the character granted as the reward in the storage 21 in association with the player ID of each player.

[0104] In S1160, the user management server 10 notifies the user terminal 30 that the gacha reward has been awarded. At this time, the other players are also notified that the gacha additional reward has been awarded. In S1165, the user terminal 30 executes a lottery (gacha) result presentation.

[0105] [3. Modifications] [3-1. Variation 1] In the embodiment, each player is not permitted to belong to multiple groups, so the "group ID" associated with the "player ID" is limited to one (FIG. 5(a)). In contrast, each player may be permitted to belong to multiple groups. In this case, multiple "group IDs" can be associated with the "player ID."

[0106] [3-2. Variation 2] In the embodiment, the "target category" is fixed to a category indicating gacha rewards. In contrast, the "reward category" may be another category. For example, it may be a category indicating rewards for completing a quest. For example, it may be configured so that relationships can be built (group registration) for each "target category."

[0107] [3-3. Variation 3] The host's request for a member may be presented to a guest who is considering applying for the request, and the host and the guest who applied for the member request may be registered in association with each other. This makes it easier for players with the same request to build a relationship.

[0108] [3-4. Variation 4] Information about hosts who have set a desire to acquire and are looking for people to register as related members may be provided to guests in response to a search request specifying search conditions related to the desire to acquire, and the host and the guest who applied for the member recruitment may be registered in association with each other. This makes it easier for players with the same desire 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, and the first additional benefit may be given to player B only if the first group is included in one or more first designated groups to which the first additional benefit is to be given. This makes it possible to adjust the recipients of the additional benefit when player A belongs to multiple groups.

[0110] At this time, a third group including player B but not player A is further registered, and only if the first group is included in one or more second designated groups to which the second additional benefit is to be granted, the second additional benefit is granted to player A. This makes it possible to adjust the grantees 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: a designation by a player belonging to the first group, the nature of the process of obtaining the first benefit, and the contents of the first benefit. In this way, the first designated group is identified manually or automatically. Similarly, the second designated group is identified according to at least one of the following: a designation by a player belonging to the second group, the nature of the process of obtaining the second benefit, and the contents of the second benefit. In this way, the second designated group is identified manually or automatically. [Explanation of symbols]

[0112] 10 User management server (an example of a "game information processing device") 20 Data Management Server 21 Storage 30 User terminals 40 Communication Network 410 Registration Department 411 Recruitment Department 412 Search Department 413 Application Reception Department 414 Registration Department 420 Lottery section 421 Reception 423 Grant Department 424 Information Department

Claims

1. A registration means for registering a first player and a second player in association with each other; a granting means for granting a first additional privilege to the second player who is not involved in the process of obtaining a first privilege, on condition that the second player is registered in association with the first player, when the first privilege is granted to the first player who is involved in the process of obtaining the first privilege; A game information processing device comprising:

2. the granting means further grants a second additional privilege to the first player not involved in the acquisition process, on condition that the first player is registered in association with the second player, when the second privilege is granted to the second player involved in the acquisition process of the second privilege. The game information processing device according to claim 1 .

3. a receiving means for receiving a request for increasing availability of the second benefit from the second player during the process of obtaining the second benefit, the granting means grants the first player the second additional benefit equivalent to the second benefit when the second benefit determined in response to or taking into consideration the request by the second player accepted by the accepting means is granted to the second player; The game information processing device according to claim 2.

4. a notification means for notifying the second player of the content of the first additional benefit to be given to the second player, the receiving means receives a request for increasing availability of the second benefit made by the second player after the content of the first additional benefit is 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 a third additional privilege to the first player and the second player not involved in the process of obtaining a third privilege, on condition that the first and second players are registered in association with the third player, when the third privilege is granted to the third player who has been involved in the process of obtaining the third privilege, and grants the first additional privilege and the second additional privilege to the third player not involved in either the process of obtaining the first privilege or the process of obtaining the second privilege, on condition that the third player and the third player are registered in association with the first player and the second player, respectively. The game information processing device according to claim 4.

6. the receiving means further receives a request for increasing availability of the first benefit by the first player during a process of obtaining the first benefit; the granting means grants the second player and the third player the first additional privilege equivalent to the first privilege when the first privilege determined in response to or taking into consideration a request by the first player accepted by the accepting means is granted to the first player; The game information processing device according to claim 5.

7. the notifying means further notifies the first player of the content of the third additional benefit to be given to the first player; the receiving means receives a request for increasing availability of the first benefit made by the first player after the content of the third additional benefit is notified to the first player; The game information processing device according to claim 6.

8. The game device further includes a presentation means for presenting a request for the first player who is seeking a partner for association registration to the second player who is considering applying for the recruitment, the registration means registers the first player and the second player who applied for the recruitment by the first player in association with each other; 5. The game information processing device according to claim 3 or 4.

9. a search means for providing information about the first player who has set a request for acquisition and is looking for a partner for association registration to the second player in response to a search request specifying a search condition related to the request for acquisition, the registration means registers the first player and the second player who applied for the recruitment by the first player in association with each other; 5. The game information processing device according to claim 3 or 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 and not including the second player, the granting means grants the first additional benefit to the second player only when the first group is included in one or more designated groups to which the first additional benefit is to be granted; 10. The game information processing device according to claim 1, wherein the first and second game devices are connected to each other.

11. the registration means further registers a third group including the second player and not including the first player; the granting means grants the second additional benefit to the first player only when the first group is included in one or more designated groups to which the second additional benefit is to be granted; The game information processing device according to claim 10.

12. the granting means specifies the designated group in accordance with at least one of the following: a designation by a player, the nature of a process for obtaining the privilege, and the contents of the privilege; The game information processing device according to claim 10 or 11.

13. a registration step of registering a first player and a second player in association with each other; a granting step of granting a first additional privilege to the second player who is not involved in the acquisition process of the first privilege, on condition that the second player is registered in association with the first player, when the first privilege is granted to the first player who is involved in the acquisition process of the first privilege; A method for controlling an information processing device.

14. A registration function for registering a first player and a second player in association with each other; a granting function for granting a first additional privilege to a second player who is not involved in the acquisition process of a first privilege, on condition that the second player is registered in association with the first player, when the first privilege is granted to the first player who is involved in the acquisition process of the first privilege; A control program that causes the computer of an information processing device to realize the above.

Citation Information

Patent Citations

  • Game control device, game control method, program, game system, and lottery device

    JP2014068728A

  • Information processing apparatus

    JP2017213293A

  • Program

    WO2017047204A1

  • Program

    JP2017055790A