Information processing device, information processing method, program, and information processing system

Abstract

To perform prompt confirmation of propriety of participation into multi-play.SOLUTION: An information processing device includes: an impartation section for imparting priority to a first user who satisfies a first condition of multiple users who apply for multi-play; a first output section for displaying a first screen for receiving predetermined operation in a terminal operated by the first user; a setting section for setting the first user to a player of the multi-play when predetermined operation by the first user satisfies a second condition; and a second output section for displaying a second screen for notifying non-permission of participation into multi-play in a terminal operated by a second user who does not satisfy the first condition of multiple users.SELECTED DRAWING: Figure 5

Description

[Technical field]

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

[0002] Multiple players may cooperate to play one quest. This form of play is called "multiplayer". In multiplayer, the host player recruits other players, and the game begins when all the players are present. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2023-68318 A Summary of the Invention [Problem to be solved by the invention]

[0004] Participation in multiplayer games is accepted on a first-come, first-served basis until the number of participants is reached. However, before the start of a multiplayer game, there may be vacancies among some of the applicants who were accepted to participate. For this reason, a screen for selecting the game media to be used in the multiplayer game is presented not only to applicants who were accepted to participate, but also to applicants who were not accepted to participate. As a result, there are cases where applicants find out that they are not accepted to participate after selecting the game media.

[0005] One of the objects of the present invention is to enable early confirmation of whether or not a player can participate in a multiplayer game. [Means for solving the problem]

[0006] One form of the present invention is an information processing device having: a granting unit that grants priority to a first user among multiple users who have applied to play in a multiplayer game, who satisfies a first condition; a first output unit that displays a first screen for accepting a specified operation on a terminal operated by the first user; a setting unit that sets the first user as a player of the multiplayer game if the specified operation by the first user satisfies a second condition; and a second output unit that displays a second screen on a terminal operated by a second user among the multiple users who does not satisfy the first condition, notifying the user that he or she cannot participate in the multiplayer game. Effect of the Invention

[0007] According to one aspect of the present invention, it is possible to quickly check whether or not a player can participate in a multiplayer game. [Brief description of the drawings]

[0008] [Figure 1] FIG. 2 is a diagram illustrating an example of a configuration of an information processing system assumed in the first embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of a functional configuration of a server. [Diagram 3] 11 is a table illustrating an example of player information. [Figure 4] FIG. 13 is a diagram illustrating an example of a cooperative play recruitment list. [Diagram 5] 13 is a flowchart illustrating an example of a processing operation when players for cooperative play are being recruited. [Figure 6] FIG. 13 is a diagram illustrating a display example of a deck selection screen in the first embodiment. [Figure 7] FIG. 13 is a diagram illustrating an example of a display of a dialog box. [Figure 8] FIG. 13 is a diagram illustrating an example of the display of the deck selection screen after the time limit has elapsed. [Figure 9] 13A and 13B are diagrams illustrating an example of a dialog box displayed to a user who performs a predetermined operation after the priority is released; [Figure 10] FIG. 13 is a diagram illustrating a change in the display of the recruitment list when recruitment ends. [Figure 11]13 is a diagram illustrating the correspondence between the order of acceptance of applications and the processes to be applied. FIG. [Figure 12] FIG. 13 is a diagram illustrating a process flow in a case where all users to whom priority has been granted perform a predetermined operation within a time limit. [Figure 13] 13 is a diagram illustrating a process flow when priority rights are released for some users. FIG. [Figure 14] 13 is a flowchart illustrating an example of a processing operation for push-distributing a re-recruitment of player candidates. [Figure 15] FIG. 13 is a diagram illustrating an example of a re-recruitment notification. [Figure 16] FIG. 13 is a diagram illustrating another example of a notification of re-recruitment. [Figure 17] 13 is a flowchart illustrating an example of a processing operation in which a time limit extension function is added. [Figure 18] 13 is a flowchart illustrating an example of a processing operation according to Concrete Example 1 of the fourth embodiment. [Figure 19] 13 is a diagram illustrating the relationship between the play history of the player information and the time limit. FIG. [Figure 20] 13 is a flowchart illustrating an example of a processing operation according to concrete example 2 of embodiment 4. [Figure 21] A diagram explaining the relationship between the number of times time runs out and the time limit on the deck selection screen for cooperative play. [Figure 22] 13 is a flowchart illustrating an example of a processing operation according to Concrete Example 3 of the fourth embodiment. [Figure 23] FIG. 13 is a diagram illustrating the relationship between a login history and a time limit. [Figure 24] 13 is a flowchart illustrating an example of a processing operation according to Concrete Example 4 of the fourth embodiment. [Diagram 25] 11 is a diagram illustrating the relationship between the account creation date and time and the time limit. FIG. [Figure 26] FIG. 13 is a diagram illustrating an example of the display of a deck selection screen in embodiment 5. [Figure 27] A figure explaining an example of the display of information on game content selected by another player. [Figure 28]FIG. 13 is a diagram illustrating an example of a deck selection screen displaying information about the game medium selected by the host user. [Figure 29] 13 is a diagram illustrating an example in which a display area for second cooperative play and a display area for third cooperative play are provided separately. FIG. [Diagram 30] A figure explaining another example in which a display area for second cooperative play and a display area for third cooperative play are provided separately. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example of a form for carrying out the present invention, and the embodiment of the present invention is not limited to the embodiment described below. Therefore, the technical scope of the present invention is not limited to the scope described in the following embodiments. For example, various modifications or improvements to the contents described in the embodiments are also included in the technical scope of the present invention. The various functional units described below are realized through the execution of programs by, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), or other processors.

[0010] <Terminology> First, the terms used in the embodiments will be described. "Program" is used as a general term for the OS (Operating System) and application programs. "Game" refers to a computer game. The virtual space in which a game takes place is called the "game space." The setting of a game space may be, for example, a virtual city or a virtual country.

[0011] Games are divided into in-games and out-games. The "in-game" is the main part of the game, and is made up of sub-games called "quests." In many cases, the difficulty of the quest and the enemy characters (i.e. boss characters) that appear in the quests vary from quest to quest. For example, conditions for achievement are set for each quest, and players who achieve the conditions are given a reward. The "out-game" is a part of the game other than the in-game. In the out-game, for example, acquisition, development, selection, etc. of game media to be used in play are performed. The out-game may also be composed of one or more quests.

[0012] "Achievement conditions" may include, for example, defeating all enemy characters in a quest, defeating a specific enemy character, arriving at a specific location or point, or obtaining a specific item. The specific enemy characters include, for example, boss characters, and the specific items include, for example, coins, equipment, weapons, treasure chests, and the like. Fulfilling the conditions is also called "clearing the game" or "beating the game." "Player" refers to a user who plays a game by operating a terminal.

[0013] "Terminals" include terminals operated by users (hereinafter also referred to as "user terminals"), as well as servers located on the Internet or other networks. When clearly distinguishing between users and players, the terminals operated by players are referred to as "player terminals." When a game is executed on a server, the user terminal is used as a so-called input / output device. That is, the user terminal is used to display images related to the game and to input operations. The images are generally moving images.

[0014] A "social game" is a game that can be played by multiple people and incorporates elements of SNS (Social Networking Service). For example, there are online games. The "mode of play" includes play by one player alone (hereinafter also referred to as "single play") and play by multiple players who have a predetermined relationship (hereinafter also referred to as "multiple play").

[0015] Depending on the game, it may only be possible to play single player, only multiplayer, or the option to choose between single player and multiplayer. Some games use position information of an object (eg, a player character) operated by a player within a game space (virtual space), while other games do not use such position information.

[0016] "Multiplayer games" include, for example, games in which players compete against other players (hereinafter referred to as "competitive games"), games in which players compete against other players for game results (hereinafter referred to as "competitive games"), and games in which players work together to achieve a common goal (for example, completing the game) (hereinafter referred to as "cooperative games"). Playing a battle game is called battle play, playing a competitive game is called competitive play, and playing a cooperative game is called cooperative play.

[0017] A user who invites other users to play a cooperative game is called a "host" or "host user," and a user who responds to the invitation is called a "guest" or "guest user." A "deck" refers to a combination of one or more game media (hereinafter also referred to as "objects") used to play a quest. There is a limit to the number of game media that can be used to make up a deck. For example, it is set to four. The game can be played by selecting a deck or by creating a new deck.

[0018] In the case of cooperative play, a deck for cooperative play is organized by combining one or more game media used by each player. The game content to be used in the cooperative play is selected by selecting a deck. For example, if the number of guests recruited is three, the game content at the top of the selected deck will be the game content used by each guest. If only one guest is being recruited, the two game media located at the top and second positions of the selected deck will be selected as the game media to be used by the guest.

[0019] By the way, if there are two guests, the game media at the top of the deck selected by each guest will be provided. The remaining two will be the first and second game media selected by the host. When all players participating in the cooperative play have selected their game content, the cooperative play begins. The players proceed with the cooperative play by operating the game content they have selected in turn or simultaneously. "Specified value" refers to information that can be exchanged on the network, such as electronic money, crypto assets, in-game currency, legal tender, points, etc.

[0020] <Embodiment 1> <System configuration> FIG. 1 is a diagram showing an example of a configuration of an information processing system 1 assumed in the first embodiment. An information processing system 1 shown in FIG. 1 includes a server 10 that manages the progress of a social game, user terminals 20A, 20B, 20C, 20D, and 20E operated by respective users, and a network N that connects these so that they can communicate with each other. When the user terminals 20A, 20B, 20C, 20D, and 20E are not distinguished from one another, they are referred to as user terminals 20. On the other hand, when distinguishing between users corresponding to the user terminals 20, they are referred to in combination with a symbol representing the user. In the following description, the user terminal 20 may also be referred to as the "terminal 20."

[0021] 1, the number of user terminals 20 is five, but in reality, the number may be two or more. However, in the cooperative play envisioned in the embodiment, the number of guests is assumed to be three. One user is associated with one user terminal 20. In other words, one user account is associated with one user terminal 20. In Fig. 1, the user corresponding to the user terminal 20A is represented as user A, the user corresponding to the user terminal 20B is represented as user B, etc. Note that a user who plays a quest is referred to as a player, as described above. The network N may be, for example, the Internet, a LAN (Local Area Network), or a mobile communication system such as 4G or 5G. The network N may be a wired network or a wireless network, or may be a combination of a wired network and a wireless network.

[0022] The server 10 is one or more computers used to provide a social game. When the server 10 is made up of multiple computers, the multiple computers cooperate with each other via a network N to enable players to play the social game. The server 10 may be an on-premise server or a cloud server. Cloud servers include, for example, IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service). The server 10 is an example of an information processing device.

[0023] The user terminal 20 is a terminal operated by a user who plays a social game. The user terminal 20 is, for example, a smartphone, a tablet computer, a notebook or desktop computer, a game terminal, a head-mounted terminal (a so-called headset), or a glasses-type terminal (a so-called smart glasses). Incidentally, smart glasses are glasses-type devices equipped with a small display and a light-guiding component that focuses an image displayed on the display on the retina. The user terminal 20 has a communication function with the network N. The user terminal 20 in this embodiment is used as an input / output device for the server 10. However, when a part of an application program of a social game is executed on the user terminal 20, the user terminal 20 is treated as an example of an information processing device.

[0024] <Server hardware configuration> The server 10 comprises a processor 11 that controls the overall operation of the terminal, a memory 12, an auxiliary storage device 13, and a communication interface 14. The processor 11 is, for example, a CPU. The memory 12 is composed of a ROM (=Read Only Memory) in which a BIOS (=Basic Input Output System) and the like are stored, and a RAM (=Random Access Memory) used as a work area for the processor 11.

[0025] The auxiliary storage device 13 is, for example, a hard disk device or a semiconductor storage device. The auxiliary storage device 13 stores various information related to the application program of the social game to be played and the progress of the game. The communication interface 14 is a device that enables communication with an external terminal such as a user terminal 20. The communication interface 14 is required to have a communication function that is compatible with the network N used for communication.

[0026] <Hardware configuration of user terminal> The user terminal 20 comprises a processor 21 that controls the overall operation of the terminal, a memory 22, an auxiliary storage device 23, a communication interface 24, and a display 25. The processor 21 is, for example, a CPU. The memory 22 is composed of a ROM in which a BIOS and the like are stored, and a RAM used as a work area for the processor 21. The auxiliary storage device 23 is, for example, a hard disk device or a semiconductor storage. The communication interface 24 is a device that enables communication with an external terminal such as the server 10. The communication interface 24 is required to have a communication function that is compatible with the network N used for communication. The display 25 is, for example, a liquid crystal display or an organic EL (Electro Luminescence) display.

[0027] <Server functional configuration> Fig. 2 is a diagram illustrating an example of the functional configuration of the server 10. Note that the functional configuration shown in Fig. 2 is an example of a functional unit realized through the execution of a program. The server 10 includes an attachment unit 101 , a first output unit 102 , a setting unit 103 , a second output unit 104 , and a storage unit 110 . Of these, the storage unit 110 is realized by the memory 12 (see FIG. 1) and the auxiliary storage device 13 (see FIG. 1).

[0028] <Information stored in the memory unit> First, an example of information stored in storage unit 110 will be described. In the storage unit 110 shown in FIG. The storage unit 110 also stores quest information, game media information, deck information, and the like. The quest information stores various information related to the quest to be managed. The game media information stores attributes and attribute values ​​of the game media, ability points, and the like. The deck information stores information on the deck being used in play and decks registered by the user, and the like.

[0029] <Player Information> In the player information 111, various pieces of information related to the player playing the quest are stored. 3 is a table for explaining an example of the player information 111. In the case of FIG. 3, a user account 111A, an account creation date and time 111B, a play history 111C, a login history 111D, and a number of time-outs 111E on the deck selection screen for cooperative play are stored as the player information 111. Note that the information shown in FIG. 3 is an example of the player information 111.

[0030] The user account 111A is an account registered by a user, and is added each time a new registration is made. When a new registration is made, a login password is also registered. In the case of FIG. 3, U100 to U104 corresponding to users A to E are registered. The account creation date and time 111B is the date and time when the account was created. In the case of Fig. 3, the creation date and time of U103 is the oldest, and the creation date and time of U100 is the newest. The play history 111C includes the number of times the user played a game (or quest), the play time for each play, the total play time, the results of the play, the type of play, etc. Figure 3 shows an example of the number of times cooperative play was played. In the case of Figure 3, U103 has played the most, and U100 has played the least.

[0031] The login history 111D includes the number of times each user logged in, the date and time of login, the length of time the user logged in, etc. In Fig. 3, the number of logins is illustrated. In Fig. 3, U103 has logged in the most, and U100 has logged in the least. The number of timeouts 111E on the deck selection screen for cooperative play is the number of times time has run out during the selection of a deck to be used in the applied cooperative play. In the case of this embodiment, the deck selection screen is displayed only to users who applied before the number of applicants reaches the number of people invited. However, if there is a user who does not select a deck, cooperative play cannot start. Therefore, a time limit is provided as a mechanism to encourage early deck selection. The time limit here is an example of a predetermined time. The number of timeouts 111E on the deck selection screen for cooperative play indicates the number of times a deck could not be selected within the time limit. In the case of FIG. 3, U100 has the most number of times, and U103 has the least number of times.

[0032] <Processing performed by the functional unit> The following describes basic processing functions executed by the attachment unit 101 (see FIG. 2), the first output unit 102 (see FIG. 2), the setting unit 103 (see FIG. 2), and the second output unit 104 (see FIG. 2). Detailed processing functions provided in each functional unit will be explained in conjunction with examples of expected processing operations at appropriate times.

[0033] The granting unit 101 is a functional unit that grants priority to a user (hereinafter referred to as a "first user") who satisfies a first condition among a plurality of users who have applied to play cooperatively, which is a form of multiplay. The "first condition" here is a prerequisite for granting priority, and means, for example, that "the order in which the application was accepted is within the upper limit." The upper limit here is the number of people being recruited. Therefore, if the number of people being recruited is three, only users whose application was accepted within the top three will satisfy the first condition.

[0034] In this way, by granting priority only to users who satisfy the first condition, it is possible to quickly distinguish between users who are permitted to participate in cooperative play and users who are not permitted to participate in cooperative play. In addition, the first condition may be specified as the timing at which the selection of a quest to play from a list (hereinafter referred to as the "recruitment list") of one or more quests that are recruiting users (i.e., potential players) to participate in cooperative play is accepted (i.e., the order in which the selection is accepted) earlier than that of other users.

[0035] However, the first condition may include not only the order in which the applications were received or the order in which the quest selections were received, but also the satisfaction of the recruitment conditions and other conditions. Recruitment conditions and other conditions include, for example, the user's ability and level, playing history, the level of the game media owned by the user, being friends with the host user, and being close to the host user (for example, within 400 m).

[0036] When the first condition is specified by "the order in which the application was accepted is within the upper limit" and the "recruitment conditions", the granting unit 101 grants priority to an applicant user who satisfies the recruitment conditions and whose application was accepted within the upper limit. The first condition may be specified or editable by the host user each time a host is recruited. In this embodiment, unless the host user specifies the first condition, "the application acceptance order is within the upper limit" is used as the first condition.

[0037] Here, "priority" refers to the right to be given priority over other users in participating in cooperative play. A user who has been granted priority is provisionally reserved to participate in cooperative play. The user here is a potential player. However, because it is a provisional reservation, the user who has been granted priority has not yet confirmed that he or she will participate in the cooperative play that he or she has applied to play.

[0038] The first output unit 102 is a functional unit that displays a screen (hereinafter referred to as a "first screen") for receiving a predetermined operation on the terminal 20 operated by the first user (i.e., a user to which priority has been granted). The predetermined operation here refers to an operation for confirming participation in cooperative play.

[0039] The predetermined operation is, for example, an operation to select a deck to be used in cooperative play. The operation to select a deck may be, for example, tapping the "Select" button on the screen, tapping the "Confirm" button, tapping the "Execute" button, tapping the "Deploy" button, or may be tapping, double-tapping, swiping, tapping the first screen, or other specific operation on a specific deck displayed on the screen. In addition, the predetermined operation may be, for example, input of a password, a secret word, or a code, or consent to the participation conditions required by the host user. A combination of these operations may be used as the "predetermined operation."

[0040] On the first screen, images, icons, operation buttons, explanatory text, and the like used for accepting the predetermined operation are displayed according to the contents of the predetermined operation. For example, if the specified operation is the selection of a deck, the first screen not only allows the selection of a deck to be used in cooperative play, but also allows the confirmation of the game media that make up the deck, as well as the change of one or more game media that make up the deck. In addition, in the case of a user for whom a deck to be used in cooperative play is automatically selected based on prior settings or selections, the display of the first screen is used to confirm the game media that make up the deck to be used in cooperative play.

[0041] The setting unit 103 is a functional unit that sets the first user (that is, the user to whom priority has been given) as a player in joint play when a predetermined operation by the first user satisfies a second condition. In this embodiment, if the predetermined operation of the user to whom priority has been granted further satisfies the second condition, the user is set as a player in the cooperative play. In other words, participation in the cooperative play is confirmed. The "second condition" here is a condition for confirming participation in cooperative play, and may be, for example, one or more of the following: "accepting a specified operation within the time limit from the display of the first screen," "accepting a specified operation within the time limit from applying for cooperative play that is open to participants," and "the specified operation is correct."

[0042] In this embodiment, the second condition is "accepting a predetermined operation within a time limit." The time limit here is set in order to quickly determine whether or not a user can participate. In this embodiment, five seconds is used as the time limit. However, the time limit may be seven or ten seconds. Also, the host user may be able to specify or change the time limit. In this case, the host user can be involved in determining which users will participate as players by adjusting the time limit.

[0043] In addition, the granting unit 101 is also provided with a function for canceling the priority granted to a first user who does not satisfy the second condition (i.e., a user to whom priority has been granted) when the first user who does not satisfy the second condition appears. Cancellation of the priority means that a vacancy has occurred among the first users participating in the cooperative play. The first user whose priority has been cancelled is treated as one of the other users who applied to play cooperatively but were not given priority. In addition, the priority that has been cancelled can be re-granted.

[0044] Cooperative play begins when the number of players equal to the number of recruited players is reached. For this reason, it is necessary to fill vacancies among first users as soon as possible. Therefore, the granting unit 101 is also provided with a function of granting the priority granted to the first user who did not satisfy the second condition to another user who applied to the cooperative play earlier. Note that the timing of the application may be specified based on the order of acceptance after it is determined that the second condition is not satisfied, or may be specified based on the order of acceptance after the priority is actually released. This function gives users other than the first user who meets the second condition an opportunity to participate in cooperative play.

[0045] However, if a user whose priority has been released performs a predetermined operation before priority is given to other users who have applied for the recruitment (for example, if the predetermined operation is performed immediately after the time limit has elapsed), the user will be allowed to participate in the cooperative play as a player. This is because, although it is outside the time limit, the user's participation in the cooperative play is confirmed by the predetermined operation satisfying the second condition. In the first place, the users whose priority has been removed are those who applied earlier than other users, and they can start cooperative play sooner than if priority were granted to other players and they were to wait for them to select a deck.

[0046] However, if a user whose priority has been released performs a predetermined operation before other users, and the other users are given the released priority, the above-mentioned problem occurs. That is, even if the first screen for accepting a predetermined operation is displayed and the user selects a deck, the user is notified that he or she cannot participate in cooperative play. Therefore, if a user whose priority has been released performs a predetermined operation before the priority is granted to another user, the system is controlled so that the released priority cannot be granted to another user. For example, the released priority is considered to have been granted again to the user who performed the predetermined operation after the priority was released.

[0047] The second output unit 104 is a functional unit that displays a screen (hereinafter referred to as the "second screen") on a terminal 20 operated by a second user among the multiple users who does not satisfy the first condition (i.e., a user who has not been granted priority) notifying the user that he or she cannot participate in cooperative play. The second screen displays an image, icon, explanatory text, etc. to notify the user that they cannot participate in cooperative play. In addition, if the priority has been granted to another user at the time the user whose priority has been released performs a specified operation after the time limit, the second screen will also be displayed to the user whose priority has been released.

[0048] <Processing when applying for cooperative play> An example of the processing operation executed when applying for cooperative play will be described below with reference to Figs. 4 to 13.

[0049] <Cooperative play recruitment list> FIG. 4 is a diagram illustrating an example of a cooperative play invitation list 200. As shown in FIG. In the recruitment list 200 shown in FIG. 4, four recruitment bulletin boards 201 and a “search again” button 202 are arranged. All four recruitment bulletin boards 201 have a common layout. In the case of FIG. 4, the recruitment bulletin board 201 is made up of a host character icon 211 , a host name 212 , a quest name 213 , a quest boss character name 214 , a quest icon 215 , and a host medal 216 .

[0050] The host character icon 211 displays an icon of the game medium used by the host user in cooperative play. The game medium here is the game medium located at the top of the deck selected by the host user. Therefore, even if the host user is the same, if the game medium located at the top of the deck is different, a different icon will be displayed. Also, even if the host user is different, if the game medium located at the top of the deck is the same, the same icon will be displayed.

[0051] The host name 212 is the user name of the host user. The host name 212 displays a nickname or the like registered by the host user. The host name 212 is displayed as text. Through the host name 212, the user can identify the host user. The quest name 213 is the name of the quest that is the subject of the cooperative play. The quest name 213 is displayed in text. The user can identify the quest through the quest name 213.

[0052] The quest boss character name 214 is the name of the boss character that appears in the quest that is the target of the cooperative play. The boss character name 214 is displayed in text. Through the boss character name 214, the user can identify the boss character that is obtained by clearing the quest. The quest icon 215 is an icon registered for a quest that is the subject of cooperative play.

[0053] The host medal 216 is an icon of a medal possessed by the host user. The host medal 216 represents the host user's ability as a player. The host medal 216 is displayed only for host users who have set the display of medals. Therefore, the host medal 216 is not displayed on the second and third recruiting bulletin boards 201 from the top. Since the recruitment of players will end at any time, when the "search again" button 202 is operated, the display contents of the recruitment list 200 are switched to a recruitment bulletin board 201 regarding cooperative play that is being recruited at the time of the operation.

[0054] <Processing operation example> 5 is a flowchart for explaining an example of a processing operation when players for cooperative play are recruited. Note that the symbol S shown in the figure means a step. The processing operation shown in FIG. 5 is executed by the processor 11 (see FIG. 1) of the server 10 (see FIG. 1) through cooperation of the attachment unit 101, the first output unit 102, the setting unit 103, and the second output unit 104.

[0055] The processing operation shown in FIG. 5 is started at the same time as the recruitment of players to participate in cooperative play is started. The processing operation shown in Fig. 5 is repeatedly executed on a user-by-user basis until the recruitment bulletin board 201 (see Fig. 4) where cooperative play has not yet started is terminated. Therefore, when multiple applications are detected at once, multiple processing operations shown in Fig. 5 are executed in parallel.

[0056] First, processor 11 determines whether or not to accept an application (step 1). An application is made when a user who wishes to participate in cooperative play selects one of the recruitment bulletin boards 201 displayed in the recruitment list 200. If no application is detected for the target recruitment bulletin board 201, a negative result is obtained in step 1. In this case, the processor 11 repeats the determination in step 1. If an application to the target recruitment bulletin board 201 is detected, a positive result is obtained in step 1. In this case, processor 11 determines whether or not there is a vacancy in the number of people being recruited (step 2). In the present embodiment, the number of people being recruited is three.

[0057] If there is one or more vacancies in the recruitment position (i.e., if the first condition is satisfied), a positive result is obtained in step 2. In this case, processor 11 gives priority to the user who is the applicant (i.e., the first user) (step 3). Next, the processor 11 displays a deck selection screen on the user terminal operated by the user to whom the priority has been granted (step 4).

[0058] 6 is a diagram for explaining a display example of the deck selection screen 220 in the first embodiment. The deck selection screen 220 here is an example of the first screen. In the case of the present embodiment, the deck selection screen 220 displays, as an initial screen, for example, the deck used in the previous play of the target quest or the deck used in the previous clear. The deck selection screen 220 shown in FIG. 6 is composed of a deck name 221, a list of icons 222 of the game media that make up the deck, a “Details” button 223, a “Bulk Formation” button 224, a “Deployment” button 225, and a remaining time display 226.

[0059] 6, icons corresponding to three game media are displayed in the icon list 222. The leftmost position of the icon list 222 is the top position. Therefore, when this deck is selected, the game media corresponding to the icon (heart mark icon) located at the leftmost position of the icon list 222 will be used in cooperative play. When the "Details" button 223 is operated, detailed information about the three game media displayed in the icon list 222 is displayed on the screen.

[0060] Operating the "Bulk Edit" button 224 transitions to a screen for changing all three game media that make up the deck at once. The "Deploy" button 225 is a button used to select a deck to be used in cooperative play, and the deck to be used in cooperative play is confirmed by operating the "Deploy" button 225. In other words, the game media to be used in cooperative play is confirmed. Operating the "Deploy" button 225 corresponds to a predetermined operation.

[0061] The remaining time display 226 is used to notify the remaining time before the operation of the "dispatch" button 225 is required. The remaining gauge 226B is a display field that displays the length of the remaining time by the length of the gauge. A user who wishes to participate in cooperative play is required to operate the "Deploy" button 225 before the remaining time 226A is displayed as "0 seconds". The priority granted state is maintained until the remaining time 226A is displayed as "0 seconds". On the other hand, if the "Deploy" button 225 is not operated before the remaining time 226A is displayed as "0 seconds", the granted priority is cancelled.

[0062] Returning to the explanation of Figure 5. If a negative result is obtained in step 2 (i.e., if there are no vacancies in the number of positions available at the time the application is accepted), processor 11 outputs a dialog box to terminal 20 of the relevant user informing the user that he or she cannot participate in the cooperative play for which he or she has applied (step 5). 7 is a diagram for explaining a display example of the dialog box 230. In Fig. 7, parts corresponding to those in Fig. 4 are denoted by the same reference numerals.

[0063] 7, a dialog box 230 is displayed superimposed on the screen of the recruitment list 200, informing the user that he / she cannot participate in the selected recruitment bulletin board 201. This dialog box 230 is an example of the second screen. 7, the dialogue box 230 displays "Dialogue" and "Failed to enter the room." Incidentally, the "room" represents a virtual room where a quest that is the subject of cooperative play or players who participate in cooperative play gather. Note that the expression in the dialog box 230 is just one example, and other expressions such as "Unable to successfully connect to quest" may be used as long as it conveys that the player cannot participate in the play.

[0064] Returning to the explanation of Fig. 5, specifically, the scene returns to the display of the deck selection screen 220 (see Fig. 6). When the deck selection screen 220 is displayed on the terminal 20 of the user to whom priority has been granted, the processor 11 determines whether or not it is within the time limit (step 6). The time limit is determined in advance. As described above, in this embodiment, the time limit is five seconds. Since the measurement starts at 5 seconds, a positive result is obtained in step 6. In this case, processor 11 determines whether or not a predetermined operation has been accepted (step 7).

[0065] The predetermined operation is an operation for confirming participation in cooperative play, such as selecting a deck. If the predetermined operation is not detected, a negative result is obtained in step 7. In this case, processor 11 returns to step 6. If the state in which the predetermined operation is not detected continues, the time from the start of measurement exceeds the time limit, and a negative result is obtained in step 6. In this case, processor 11 cancels the priority of the user who has not performed a predetermined operation within the time limit even after deck selection screen 220 has been displayed (step 8).

[0066] 8 is a diagram for explaining a display example of the deck selection screen 220 after the time limit has elapsed. In Fig. 8, parts corresponding to those in Fig. 6 are denoted by the same reference numerals. In the case of FIG. 8, the remaining time display 226A shows "0 seconds" and the remaining gauge 226B display has also disappeared. Even if the remaining time 226A shows "0" seconds, various buttons can be operated. Although not shown in FIG. 8, a pop-up may be displayed to inform the player that the priority has been released. For example, a message may be displayed saying "Your priority has been released. Even if you select a deck, you may not be able to participate in cooperative play."

[0067] The cancellation of the priority creates a vacancy in the number of positions available. Therefore, if another user applies after the priority is cancelled, a positive result is obtained in step 2, and the user is granted priority (step 3). For another user who has been newly granted priority, the process from step 4 onwards is carried out. Returning to the explanation of Figure 5. When the priority is released in step 8, processor 11 determines whether or not a predetermined operation has been received before the priority is given to another user (step 9). If the priority was granted to another user before accepting the predetermined operation by the user from whom the priority has been released, a negative result is obtained in step 9. In this case, processor 11 returns to step 5 and displays dialog box 230 on the user's operation screen.

[0068] 9 is a diagram for explaining a display example of a dialog box 230 that is displayed to a user who performs a predetermined operation after the priority right is released. In Fig. 9, the parts corresponding to Fig. 7 and Fig. 8 are denoted by the same reference numerals. Dialog box 230 shown in Fig. 9 is displayed to a user who has selected a deck, and is therefore displayed superimposed on deck selection screen 220. This differs from dialog box 230 (see Fig. 7) that is displayed to a user who is notified that they cannot participate at the time they apply to play cooperatively.

[0069] Returning to the explanation of Figure 5. If the user whose priority was released performs a predetermined operation before the priority is granted to another user, a positive result is obtained in step 9. If a positive result is obtained in step 7, or if a positive result is obtained in step 9, processor 11 sets the corresponding user as a player in cooperative play (step 10). After executing step 5 or after executing step 10, processor 11 determines whether or not all players have been determined (step 11).

[0070] If the determined number of players is less than the number of players to be recruited, a negative result is obtained in step 11. In this case, processor 11 returns to step 1. In this case, processor 11 repeatedly executes the above-described processing operations. On the other hand, if the number of confirmed players reaches the number of players to be recruited, an affirmative result is obtained in step 11. In this case, processor 11 ends the processing operation for recruiting participants in cooperative play shown in Fig. 5. After this, processor 11 starts cooperative play between the host user and the players whose participation has been confirmed.

[0071] 10 is a diagram for explaining a change in the display of the recruitment list 200 when recruitment ends. In FIG. 10, the same reference numerals as in FIG. 4 are used. In the case of the recruitment list 200 shown in Fig. 10, the number of recruitment bulletin boards 201 is three. This is because recruitment has ended for one of the recruitment bulletin boards 201 displayed in the recruitment list 200 shown in Fig. 4. However, if another recruitment bulletin board 201 is added in its place, the number of displayed recruitment bulletin boards 201 may remain the same.

[0072] <Relationship between application acceptance order and applicable process> 11 is a diagram for explaining the correspondence relationship between the order of acceptance of applications and the processes to be applied. The contents shown in FIG. 11 correspond to steps 1 to 5 in FIG. The vertical axis in FIG. 11 is the time axis, with time progressing in the direction indicated by the arrow. In the case of FIG. 11, the host is user A. The numbers in the squares indicate the order in which the applications were received. The first place in the order of receipt is user B, the second place is user C, the third place is user D, and the fourth place is user E.

[0073] In this embodiment, the number of people being recruited is three. Therefore, priority is given to users B, C, and D who are ranked in the top three in the reception order. Also, on the terminals 20 of users B, C, and D, a deck selection screen 220 (see FIG. 6) is displayed. On the other hand, the users ranked 4th and after in the reception order (i.e., users E, F, G, H, etc.) are over the number of people available. Therefore, a dialog box 230 (see FIG. 7) is displayed on the terminals 20 of these users to notify them that they cannot participate.

[0074] Fig. 12 is a diagram for explaining the flow of processing when all users to whom priority has been granted perform a predetermined operation within a time limit. In Fig. 12, parts corresponding to those in Fig. 11 are denoted by the same reference numerals. As shown in FIG. 12, in this case, all of users B, C, and D are set as players. In this case, a list screen of players confirmed at the same time as the predetermined operation is displayed on the terminals 20 of users B, C, and D. For example, when the predetermined operation is performed in the order of users B, C, and D, two users, user A who is the host and user B who is the guest, are displayed on the terminal 20B of user B as a list screen. Furthermore, three users, user A who is the host and users B and C who are guests, are displayed on the terminal 20C of user C as a list screen. Similarly, four users, user A who is the host and users B, C, and D who are guests, are displayed on the terminal 20D of user D as a list screen.

[0075] Fig. 13 is a diagram for explaining the flow of processing when priority rights are released for some users. In Fig. 13, parts corresponding to those in Fig. 11 are denoted by the same reference numerals. In the case of FIG. 13 as well, users B, C, and D are given priority. In the case of FIG. 13, users B and C who performed a predetermined operation within the time limit are also set as players. On the other hand, priority is released for user D who did not perform a predetermined operation (e.g., selecting a deck) within the time limit. As a result of this release of priority, a vacancy occurs in the number of people being recruited. In Fig. 13, priority is given to user W, who is first in the order of acceptance of applications after the priority is released, and at the same time, deck selection screen 220 (see Fig. 6) is displayed on terminal 20W of user W. In Fig. 13, user W has performed a predetermined operation (e.g., selecting a deck) within the time limit, and therefore user W is set as the player.

[0076] It should be noted that a dialog box 230 (see FIG. 7) notifying users X, Y, Z, . . . who applied after user W is displayed on their terminals 20, notifying them that they will not be able to participate. Incidentally, user D has no way of knowing that priority has been granted to user W. For this reason, there is a possibility that user W may perform a predetermined operation (e.g., deck selection) on the deck selection screen 220 after priority has been granted to user W. In this case, a dialog box 230 (see FIG. 9) notifying that user D cannot participate is displayed on the terminal 20D operated by user D, similar to users X, Y, Z, etc.

[0077] Incidentally, if a predetermined operation (e.g., selection of a deck) is performed by user D before accepting the application of user W, user D is set as the player. In this case, a list screen of the confirmed players is displayed on the terminal 20D of user D. Specifically, the list screen displays four people: user A who is the host, and users B, C, and D who are guests. In this case, user W, like other users X, Y, and Z, is presented with a dialog box 230 (see FIG. 7) informing him / her that he / she cannot participate.

[0078] <Summary> As described above, in this embodiment, the server 10 (see FIG. 1) displays the deck selection screen 220 (see FIG. 6) only on the terminals 20 of users who have applied to play cooperatively and whose acceptance rank is within the number of people being recruited, and displays a dialog box 230 (see FIG. 7) on the terminals 20 of users whose acceptance rank exceeds the number of people being recruited, informing them that they will not be able to participate in cooperative play. Therefore, users who respond to a call for players for cooperative play can quickly confirm whether or not they can participate in cooperative play. As a result, compared to when users are notified that they cannot participate after selecting a deck to use in cooperative play, this reduces dissatisfaction among users who are not allowed to participate.

[0079] In addition, in the present embodiment, even if a user has a lower application acceptance rank than the number of people being recruited, if the user does not select a deck within the time limit, the server 10 assumes that the user has no intention or has a low intention to participate in cooperative play and cancels the priority. As a result, other users who have a lower application acceptance rank can have more opportunities to participate in cooperative play.

[0080] <Embodiment 2> This embodiment is also premised on the system configuration and processing operations of the information processing system 1 (see FIG. 1) described in the first embodiment. The granting unit 101 (see FIG. 2) in the second embodiment is provided with a function of notifying the terminal 20 of a user who satisfies a predetermined condition among second users (i.e., users to whom priority has not been granted) of a re-recruitment of players for cooperative play. That is, the granting unit 101 in the present embodiment is provided with a function of pushing a notification of a re-recruitment of players due to a vacancy.

[0081] The maximum range of users who can be the targets of the push distribution here are those who have responded to a call for players for cooperative play but have been placed low on the acceptance list and therefore have been shown a dialog box 230 (see FIG. 7) indicating that they cannot participate. However, the granting unit 101 in this embodiment performs push distribution only to users who satisfy a predetermined condition among the second users. Users who will be the recipients of the push distribution have an advantage in that they can notice the re-recruitment earlier than users who will not be the recipients of the push distribution.

[0082] Therefore, the "predetermined condition" is set to identify some second users who will be treated more favorably than other second users. One of the specified conditions is that the first application was received in a high order. For example, excluding the top three users in terms of the number of applications, the users in the top 10 (4th to 13th place in the application order) and the users in the top 100 (4th to 103rd place in the application order) are considered. Of course, the numbers here are just examples. The number of people here may be changed depending on the number of vacancies. For example, the number of people specified by the predetermined conditions may be increased when there are two vacancies compared to when there is one vacancy. However, the number of people who can become players through re-recruitment is one or at most three. Therefore, the same number of people may be targeted regardless of the number of vacancies.

[0083] One of the predetermined conditions may be a second user viewing the recruitment list 200 (see FIG. 4). A second user who has closed the recruitment list 200 on the recruitment bulletin board 201 (see FIG. 4) may be considered to have no intention or little intention to apply for cooperative play. However, the cooperative play that is the target of the push distribution is a cooperative play that the second user has applied for at least once. Therefore, the predetermined condition may be a user who is not currently viewing the recruitment list 200.

[0084] One of the predetermined conditions is that the user is a friend of the host user. If this condition is adopted, it becomes possible to give preferential treatment to the host user's friends over other users. One of the predefined conditions is to be close to the host user (for example, within 400m). If this condition is adopted, it becomes possible to give preferential treatment to companions (who are not friends in the system) who are close to the host user over other users. If no new applications are detected after the push distribution, a second push distribution may be executed, or the predetermined conditions used for the push distribution may be changed to other conditions. When changing the predetermined conditions, the conditions may be changed so that the number of target users increases, or the conditions may be changed so that the target users do not overlap.

[0085] FIG. 14 is a flowchart illustrating an example of a process of push-distributing a re-recruitment of player candidates. In this embodiment, the processing operations shown in FIG. 14 are executed in parallel with the processing operations shown in FIG. First, processor 11 determines whether or not a vacancy has occurred among the player candidates before cooperative play starts (step 21). A vacancy occurs when a user does not perform the specified operation within the time limit (a negative result in step 6 of Figure 5) or when a user whose priority has been released appears (when step 8 of Figure 5 is executed).

[0086] When no vacancy occurs among the player candidates, a negative result is obtained in step 21. In this case, processor 11 repeats the determination of step 21. Note that cooperative play may start without any vacancy occurring among the player candidates. If a vacancy occurs among the player candidates, a positive result is obtained in step 21. In this case, processor 11 pushes a notice of re-recruitment to users who were higher in the acceptance order among the users who were notified that they could not participate in the first application (step 22). Note that the push delivery can be a one-time only delivery, even if a vacancy occurs multiple times among the player candidates for the same cooperative play, or a notification can be sent each time it occurs.

[0087] Fig. 15 is a diagram for explaining an example of a notification of re-recruitment. In Fig. 15, parts corresponding to those in Fig. 4 are denoted by the same reference numerals. In the case of Fig. 15, a re-recruitment icon 229 is displayed on the second recruitment bulletin board 201 from the top. This re-recruitment icon 229 may be displayed, for example, by flashing or by high brightness. Also, the re-recruitment icon 229 may be displayed in a color tone or font size that stands out against the surrounding color tone so that it can be recognized by the user, or may be displayed with motion. By making it conspicuous, it is possible to make the re-recruitment easier to notice. The display of the recruitment list 200 on the terminal 20 of the user who is not the target of the push distribution notifying the re-recruitment remains the same as the display described in FIG.

[0088] Fig. 16 is a diagram for explaining another example of a notification of re-recruitment. In Fig. 16, parts corresponding to those in Fig. 4 are denoted by the same reference numerals. In the case of FIG. 16, the dialog box 230 is displayed in front of the recruitment list 200 in a pop-up format. 16, a dialog box 230 is arranged with a re-recruitment message 231 and a re-recruitment bulletin board 232 which is the subject of the re-recruitment. Incidentally, the re-recruitment message 231 is given the title "Attention!" and displays the fact that re-recruitment is underway and the number of vacancies, such as "Re-recruitment has begun due to vacancies" or "There is one vacancy."

[0089] The wording is arbitrary, and it is possible to express it as, for example, "We are currently recruiting players again" or "We are currently recruiting one player due to a vacancy." The content of the re-recruitment bulletin board 232 is the same as the recruitment bulletin board 201 that is the target of the re-recruitment among the recruitment bulletin boards 201 illustrated in Fig. 4. Since the re-recruitment bulletin board 232 is displayed in the dialog box 230, it is easy to apply by tapping the re-recruitment bulletin board 232. In this way, the display using the dialog box 230 is more noticeable than the display using the re-recruitment icon 229 (see FIG. 15).

[0090] <Summary> As described above, in the present embodiment, the server 10 (see FIG. 1) is added with a function of notifying only the terminals 20 of users (i.e., second users) who satisfy certain conditions that a player is being re-recruited when a vacancy occurs among the candidate players (i.e., first users). This notification allows the second user to easily notice that the cooperative play for which the second user was once notified that he or she could not participate is re-recruiting players. As a result, the second user who meets the predetermined conditions can be given priority over other users to fill the vacancy.

[0091] <Embodiment 3> This embodiment is also premised on the system configuration and processing operations of the information processing system 1 (see FIG. 1) described in the first embodiment. The setting unit 103 (see FIG. 2) in the second embodiment is provided with a function to extend the time limit when an operation for changing game media (including changing the deck) is received during selection of game media to be used in cooperative play (i.e., during selection of a deck). That is, the setting unit 103 in the present embodiment is provided with a function to rescue a user who is seriously considering which game media to use in cooperative play from running out of time.

[0092] As described above, when the "Deploy" button 225 (see FIG. 6) is operated within the time limit to determine the deck to be used, the game media to be used in cooperative play is also determined. Therefore, in the first embodiment, a user (ie, a first user) whose time limit expires without operating the "attack" button 225 is considered to have no intention of becoming a player in cooperative play, and the priority is cancelled. On the other hand, a user who is making changes to the deck composition is likely to be seriously considering the game content to be used in cooperative play.

[0093] In this embodiment, the operation related to changing game media is the operation of the "Bulk Edit" button 224. Note that the operation related to changing game media may also include the operation of a "Change" button or a "Switch" button, which are not shown on the deck selection screen 220 (see FIG. 6). In this embodiment, the time limit is extended by adding additional time. The additional time is, for example, 30 seconds. In this case, the time limit is changed from 5 seconds to 35 seconds. Note that 30 seconds is just an example, and it may be 10 seconds or 20 seconds.

[0094] In addition, when the elapsed time limit is measured by a count-up method, the upper limit of the count-up may be changed from 5 seconds to 30 seconds. The time limit can also be extended by stopping the measurement of the time limit. For example, if an operation to change the game media is accepted with three seconds remaining, the display of the remaining time may be stopped at three seconds. However, if the measurement could be stopped indefinitely, cooperative play would never start, which would be a nuisance to the host user and other guest users. Therefore, it is desirable to set an upper limit for the time that the measurement is stopped, and to resume the measurement once the upper limit has been reached. Incidentally, the timing for extending the time limit may be when an operation to change the game medium is accepted, or when the time limit has elapsed.

[0095] Fig. 17 is a flowchart for explaining an example of a processing operation in which a time limit extension function is added. Note that in Fig. 17, parts corresponding to those in Fig. 5 are denoted by the same reference numerals. In the processing operation example shown in FIG. 17, steps 31 and 32 are executed between steps 6 and 7. In the present embodiment, if a positive result is obtained in step 6, processor 11 determines whether or not an operation to change the game media has been accepted before the time limit has elapsed (step 31).

[0096] If the change operation is accepted, a positive result is obtained in step 31. In this case, processor 11 extends the time limit (step 32). After this, processor 11 proceeds to step 7. On the other hand, if a change operation has not been accepted, a negative result is obtained in step 31. In this case, processor 11 skips step 32 and proceeds directly to step 7. The subsequent processing operations are the same as those in Fig. 5. That is, it is determined whether or not a predetermined operation has been accepted, and step 6 or step 10 is executed depending on the result of the determination.

[0097] <Summary> As described above, the server 10 in this embodiment (see FIG. 1) is provided with a function to extend the time limit when an operation to change the deck (i.e., change the game media) is received during deck selection (i.e., during game media selection). This function can prevent a situation where a user who is likely to participate is unable to join cooperative play due to time running out.

[0098] <Fourth embodiment> This embodiment is also premised on the system configuration and processing operations of the information processing system 1 (see FIG. 1) described in embodiment 1. Note that the processing operations described in this embodiment can be combined with each of the above-mentioned embodiments. In the above-mentioned embodiment 3, a function for extending the time limit in conjunction with a change in game media during the restricted period was described. In this embodiment, however, a case will be described in which a time limit to be applied to a first user (a user to whom priority has been granted) is individually set based on the attributes of the first user. The attributes used here include, for example, the user's play history, the number of times the second condition was not met (i.e., the number of times the time ran out), the number of logins, the date and time of account creation, and the presence or absence of a history of spending a predetermined value and the amount of spending. However, these are only examples. Below, specific examples will be explained for each of these attribute examples.

[0099] <Example 1: Setting based on play history> The setting unit 103 (see FIG. 2) of the first specific example is provided with a function for individually setting a time limit to be applied to a first user (a user to whom priority has been granted) in accordance with the play history of the first user. Fig. 18 is a flowchart illustrating an example of a processing operation according to Concrete Example 1 of Embodiment 4. The processing operation shown in Fig. 18 is executed in parallel with, for example, the processing operation shown in Fig. 5 and the processing operation shown in Fig. 17.

[0100] First, processor 11 acquires the play history of the user to whom priority has been granted (step 41). In this specific example, the number of times the user has played the game (quest) is used as the play history. However, the play time for each play, the total play time, the result of the play, the type of play, etc. may also be acquired as the play history. Next, processor 11 sets a time limit for each user according to the acquired play history (step 42). For example, if the number of people being recruited is three, the time limits for each of the three people may be different.

[0101] Processor 11 basically sets a longer time limit for users who are not accustomed to playing, and sets a shorter time limit for users who are accustomed to playing. However, a minimum time limit (for example, 5 seconds) should be set to prevent the time limit from being too short, because there is a concern that even users who are accustomed to playing will frequently run out of time if the time limit is set too short.

[0102] Although the purpose is to make it easier for users who are not accustomed to playing to participate in the game, if the time limit is set too long, it is likely to cause dissatisfaction among other players. Therefore, it is desirable to set an upper limit on the settable time limit. Basically, each user cannot know the time limit of the other users. Therefore, the time limit of the least accustomed user may be uniformly applied to the other users. In this case, the other users are given the benefit of an extended time limit. In addition, the other users can notice the presence of a user who is not accustomed to playing from the difference in the initial value shown in the remaining time display 226 (see FIG. 6). It is also possible to predict the approximate time when cooperative play will start.

[0103] Fig. 19 is a diagram for explaining the relationship between the play history 111C of the player information 111 and the time limit. In Fig. 19, the same reference numerals are used to denote parts corresponding to those in Fig. 3. In the case of Fig. 19, the number of plays is illustrated as the play history 111C. In Fig. 19, it is assumed that priority is given to three players, U100 to U102. In the case of Fig. 19, a time limit of 20 seconds is set for U100, who has played once. A time limit of 5 seconds is set for U101, who has played 102 times. A time limit of 7 seconds is set for U102, who has played 65 times.

[0104] <Example 2: Setting by the number of timeouts> The setting unit 103 (see FIG. 2) of the concrete example 2 is provided with a function of individually setting a time limit to be applied to a first user (a user to whom priority has been granted) depending on the number of times the first user fails to satisfy the second condition within the time limit. More specifically, the setting unit 103 is provided with a function of setting a time limit (hereinafter also referred to as a "first predetermined time") for a first user who fails to satisfy the second condition many times within the time limit longer than a time limit (hereinafter also referred to as a "second predetermined time") for a first user who fails to satisfy the second condition few times within the time limit.

[0105] Fig. 20 is a flowchart illustrating an example of processing operations according to Concrete Example 2 of Embodiment 4. The processing operations shown in Fig. 20 are also executed in parallel with the processing operations shown in Fig. 5 and the processing operations shown in Fig. 17, for example.

[0106] First, processor 11 obtains the number of times the time has expired on the deck selection screen for cooperative play of the user to whom priority has been granted (step 51). It is preferable to limit the number of timeouts to the number of times they occurred in the most recent specified period (e.g., six months). If there is no restriction on the specified period, a user who is currently accustomed to playing would be evaluated based on the number of times they occurred when they were not accustomed to playing. Next, processor 11 sets a time limit for each user according to the acquired number of times the time has run out (step 52). In this specific example, the number of times the time has run out is used as an index representing accustomment to playing.

[0107] Therefore, processor 11 sets a longer time limit (ie, the first predetermined period) for a user who has a large number of time-outs, and sets a shorter time limit (ie, the second predetermined period) for a user who has a small number of time-outs. As in Example 1, a minimum value (for example, 5 seconds) is set for the time limit to prevent the time limit from becoming too short.

[0108] 21 is a diagram for explaining the relationship between the number of times time runs out 111E and the time limit on the deck selection screen 220 for cooperative play (see FIG. 6). In FIG. 21, the same reference numerals are used to denote parts corresponding to those in FIG. In the case of Fig. 21, it is assumed that priority is given to three people, U100 to U102. In the case of Fig. 21, a time limit of 20 seconds is set for U100, who has timed out five times. A time limit of 5 seconds is set for U101, who has timed out zero times. A time limit of 7 seconds is set for U102, who has timed out once.

[0109] <Example 3: Setting by login history> The setting unit 103 (see FIG. 2) of the concrete example 3 is provided with a function for individually setting a time limit to be applied to a first user (a user to whom priority has been granted) according to the login history of the first user. More specifically, the setting unit 103 is provided with a function for setting a time limit for a first user who has logged in less frequently (i.e., a "first predetermined time") to be longer than a time limit for a first user who has logged in more frequently (i.e., a second predetermined time).

[0110] Fig. 22 is a flowchart illustrating an example of a processing operation according to Concrete Example 3 of Embodiment 4. The processing operation shown in Fig. 22 is also executed in parallel with, for example, the processing operation shown in Fig. 5 and the processing operation shown in Fig. 17.

[0111] First, the processor 11 acquires the login history of the user to whom priority has been granted (step 61). In this specific example, the number of times each user has logged in is acquired as the login history. However, the login date and time, the length of time each user was logged in, etc. may also be acquired as the login history. Next, the processor 11 sets a time limit for each user according to the acquired login history (step 62).

[0112] In this specific example, a user who has logged in more frequently is evaluated as being more accustomed to playing. Therefore, processor 11 sets a longer time limit (i.e., the first predetermined period) for a user who has logged in less frequently, and sets a shorter time limit (i.e., the second predetermined period) for a user who has logged in more frequently. As with other examples, the time limit should have a minimum value (e.g., 5 seconds) to prevent the time limit from being too short.

[0113] Fig. 23 is a diagram for explaining the relationship between the login history 111D and the time limit. In Fig. 23, the same reference numerals are used to denote the same parts as in Fig. 3. In the case of Fig. 23, it is assumed that priority is given to three users, U100 to U102. In the case of Fig. 23, a time limit of 20 seconds is set for U100, who has logged in once. A time limit of 5 seconds is set for U101, who has logged in 56 times. A time limit of 7 seconds is set for U102, who has logged in 36 times.

[0114] <Example 4: Setting by account creation date and time> The setting unit 103 (see FIG. 2) of the concrete example 4 is provided with a function for individually setting a time limit to be applied to a first user (a user to whom priority has been granted) according to the date and time of the account creation of the first user. More specifically, the setting unit 103 is provided with a function for setting a time limit for a first user who has created an account only a short time ago (i.e., a "first predetermined time") longer than a time limit for a first user who has created an account many days ago (i.e., a second predetermined time).

[0115] Fig. 24 is a flowchart illustrating an example of a processing operation according to Concrete Example 4 of Embodiment 4. The processing operation shown in Fig. 24 is also executed in parallel with, for example, the processing operation shown in Fig. 5 and the processing operation shown in Fig. 17. First, the processor 11 obtains the creation date and time of the account of the user to which priority has been granted (step 71). Next, processor 11 sets a time limit for each user according to the time that has elapsed since the account was created (step 72).

[0116] In this specific example, a user who has spent a longer time playing is evaluated as being more accustomed to playing. Therefore, processor 11 sets a longer time limit (i.e., the first predetermined period) for a user who has spent a shorter time playing, and sets a shorter time limit (i.e., the second predetermined period) for a user who has spent a longer time playing. As with other examples, the time limit should have a minimum value (e.g., 5 seconds) to prevent the time limit from being too short.

[0117] Fig. 25 is a diagram for explaining the relationship between the account creation date and time 111B and the time limit. In Fig. 25, the same reference numerals are used to denote parts corresponding to those in Fig. 3. In the case of FIG. 25 as well, it is assumed that priority is given to three users, U100 to U102. In the case of FIG. 25, the creation date of U100's account is the newest, and the number of days since its creation is assumed to be 0 days. For this reason, the time limit is set to 20 seconds. Furthermore, the creation date of U101's account is the oldest, and the number of days since its creation is assumed to be 365 days. For this reason, the time limit is set to 5 seconds. Furthermore, the creation date of U102's account is three months later than U101. For this reason, the time limit is set to 7 seconds.

[0118] <Summary> As described above, the server 10 (see FIG. 1) in this embodiment is provided with a function for individually setting a time limit to be applied to a first user (a user to which priority has been granted) based on the attributes of the first user. This function makes it possible to prevent users who are not accustomed to playing, such as beginners, from being unable to join cooperative play due to time running out.

[0119] <Embodiment 5> This embodiment is also premised on the system configuration and processing operations of the information processing system 1 (see FIG. 1) described in embodiment 1. Note that the processing operations described in this embodiment can be combined with each of the above-mentioned embodiments. The first output unit 102 (see FIG. 2) in the fifth embodiment is provided with a function of presenting, on a screen (i.e., the first screen) for receiving a predetermined operation from a first user (a user to whom priority has been granted), information on at least one of the game media selected by the host user who invited participants in cooperative play and the game media selected by the other first users. That is, the first output unit 102 in the present embodiment is provided with a function of presenting, on the deck selection screen 220 (see FIG. 6), information on the game media selected by the other players.

[0120] As described above, the deck used in cooperative play is composed of game media provided by each player (including the host user). For this reason, for example, rather than all four being the same object (player character or game medium), having all four different objects is more likely to be advantageous in clearing a quest due to the diversity of the objects. However, in the case of the embodiment described above, the objects used by the host user can be confirmed by the host character icon 211 (see FIG. 4) on the recruitment bulletin board 201 (see FIG. 4), but the objects used by other players cannot be known.

[0121] Therefore, the first output unit 102 used in this embodiment is provided with a function for presenting information about the game media selected by other players on the deck selection screen 220. The information here may be presented by icons or text. Note that information about the game contents is only presented to other users who have confirmed their selection of the game contents, and therefore, while the selection of the game contents by other users has not been confirmed, no information is presented.

[0122] 26 is a diagram for explaining a display example of the deck selection screen 220 in embodiment 5. In FIG. 26, parts corresponding to those in FIG. 6 are denoted by the same reference numerals. In the case of the deck selection screen 220 shown in FIG. 26, the other player character column 227 is displayed. 26 is an initial screen. Therefore, the remaining time display 226 shows "5 seconds."

[0123] 26, it is assumed that information about the game medium used by the host user is not presented. In this case, the maximum number of pieces of information displayed in the other player character column 227 is two, which is one less than the number of people being recruited (three). In FIG. 27, the two squares drawn with dashed lines indicate that there are two other players and that the other players have not yet finished selecting the game content they will use. However, the display does not have to be dashed lines or squares. It may also be displayed as a grayed-out screen. In addition, if the selection of game content by other players has not been completed, it is also possible to display nothing in the other player character column 227.

[0124] 27 is a diagram illustrating an example of a display of information on game content selected by another player. In FIG. 27, parts corresponding to those in FIG. 26 are denoted by the same reference numerals. 27, two seconds have passed since the initial screen was displayed on the deck selection screen 220. Therefore, the remaining time display 226 shows "3 seconds." In Fig. 27, it is assumed that two other players have selected game content within two seconds from the initial screen. Therefore, two icons indicating the game content selected by the other players are displayed in the other player character column 227 shown in Fig. 27. Each icon may be displayed in association with information such as the user name of the player who selected the game content (i.e., the first user).

[0125] 28 is a diagram illustrating a display example of a deck selection screen 220 on which information on the game media selected by the host user is displayed. In FIG. 28, parts corresponding to those in FIG. 26 are denoted by the same reference numerals. The deck selection screen 220 shown in Figure 28 also shows the initial screen. Therefore, the remaining time display 226 shows the remaining time as "5 seconds." In the case of FIG. 28, even though it is the initial screen, icons indicating the game media used by the host user are displayed in the other player character column 227. As mentioned above, the game medium used by the host user can be confirmed on the recruitment bulletin board 201 (see FIG. 4), but by displaying it in the other player character column 227 of the deck selection screen 220, the risk of mistakenly selecting the same game medium as the game medium used by the host user can be reduced.

[0126] <Summary> As described above, the server 10 (see FIG. 1) in this embodiment is provided with a function for presenting, on a screen (i.e., the first screen) for accepting a predetermined operation from a first user (a user to whom priority has been granted), information on at least one of the game media selected by the host user who has invited participants in cooperative play and the game media selected by other first users. This function makes it possible to select game content by referring to game content selected by other players even within the time limit.

[0127] <Sixth embodiment> This embodiment is also premised on the system configuration and processing operations of the information processing system 1 (see FIG. 1) described in embodiment 1. Note that the processing operations described in this embodiment can be combined with each of the above-mentioned embodiments. The second output unit 104 (see Figure 2) in embodiment 6 is provided with a function to distinguishably display a second cooperative play that satisfies a condition based on a cooperative play in which participation was not permitted in a previous application, and a third cooperative play that does not satisfy the above-mentioned condition, in a list of one or more cooperative plays to which a second user (i.e., a user not granted priority) can apply, which is displayed on a terminal 20 operated by the second user.

[0128] In addition, the second output unit 104 is provided with a function for setting, as a second cooperative play that satisfies the above-mentioned conditions, a cooperative play in which the game medium that appears is a quest that is the same as or similar to a cooperative play in which participation was not approved in a previous application, as the second cooperative play. That is, the second output unit 104 in this embodiment is provided with a function of supporting a user who has not been allowed to participate in a cooperative play to which he or she has applied to apply to another cooperative play. In this embodiment, as described above, "support" is intended to make it easier to discover other cooperative plays with the same or similar conditions as a cooperative play in which participation was not permitted in a previous application (hereinafter also referred to as the "previously applied for play").

[0129] Incidentally, an example of the second cooperative play is a cooperative play in which the game medium used by the host user is the same as the game medium used by the host user of the previous applied play. Another example of the second cooperative play is a cooperative play in which the attributes of the game content used by the host user are the same as the attributes of the game content used by the host user of the previous applied play. Another example of the second cooperative play is a cooperative play in which the range of game media levels used by the host user is the same as the range of game media used by the host user of the previous applied play.

[0130] Another example of second cooperative play is cooperative play in which the boss character that appears in the quest is the same as the boss character that appears in the quest of the previous application play. Another example of second cooperative play is cooperative play in which there is a high degree of overlap between enemy characters that appear in a quest and enemy characters that appear in a quest of a previously applied play. Examples of high overlap include when there are more than a predetermined number of overlapping enemy characters (e.g., 10), or when the overlap rate between enemy characters appearing in a quest and enemy characters appearing in a quest of a previous applied play is greater than a predetermined rate (e.g., 80%).

[0131] In addition, distinguishable expressions of the recruitment bulletin board 201 corresponding to the second cooperative play and the recruitment bulletin board 201 corresponding to the third cooperative play include, for example, differences in brightness and color tone used to display the recruitment bulletin board 201 for the second cooperative play and the third cooperative play, differences in the display column in which the recruitment bulletin board 201 is placed, push delivery of the second cooperative play, and pop-up display of the second cooperative play.

[0132] Fig. 29 is a diagram for explaining an example in which a display column 217 for second cooperative play and a display column 218 for third cooperative play are provided separately. In Fig. 29, parts corresponding to those in Fig. 4 are denoted by the same reference numerals. 29, the display field 217 for the second cooperative play displays three recruitment bulletin boards 201 in which the quests to be played and the boss characters are the same as those in the previous application play. Note that the game media used by the host user of the first and second recruitment bulletin boards 201 from the top are also the same as those in the previous application play. In the case of FIG. 29, the display field 218 for the third cooperative play displays one recruitment bulletin board 201 in which the quests and boss characters to be played are different from those in the previous applied play.

[0133] Figure 30 is a diagram illustrating another example in which a display column 217 for second cooperative play and a display column 218 for third cooperative play are provided separately. In Figure 30, parts corresponding to those in Figure 29 are denoted by the same reference numerals. In the case of FIG. 30, only the first recruitment bulletin board 201 from the top of the display column 217 for the second cooperative play has the same quest to be played, boss character, and game medium used by the host user as the previous applied play. In addition, the first recruitment bulletin board 201 from the top of the display column 217 for the second cooperative play has a boss character that is the same as that of the previous application play.

[0134] <Summary> As described above, the server 10 (see FIG. 1) in this embodiment is provided with a function for supporting a user who has not been allowed to participate in a cooperative play to which he or she has applied, in applying to another cooperative play. This function can support a user who was not accepted to participate in a cooperative play that he or she applied for to apply for other cooperative plays with the same or similar conditions.

[0135] <Other embodiments> The form of the invention is not limited to the above-described embodiment. For example, it is possible to combine elements of each embodiment as appropriate. The combination here includes the deletion of elements of each embodiment.

[0136] In the above-described embodiment, a mechanism that can notify a user early on whether or not they can participate in a multiplayer game was described for any cooperative play. However, the mechanism of the above-described embodiment may not be executed in response to applications for cooperative play where the users recruited are "friends only" or for cooperative play where a "password" is set as a recruitment condition.

[0137] <Summary> The main features of the information processing device, the information processing method, and the program described in the embodiments will be described below. [General-purpose subject] One object of the present invention is to make it possible to notify a player that he or she will not be able to participate in a multiplayer game before a predetermined operation is performed. Another object of the present invention is to provide an opportunity to perform a predetermined operation only to users who can participate in multiplay.

[0138] Issues corresponding to [Appendix 1] One of the objects of the present invention is to enable early confirmation of whether or not a player can participate in a multiplayer game. [Appendix 1] An information processing device having: a granting unit that grants priority to a first user who satisfies a first condition among multiple users who have applied to play in a multiplayer game; a first output unit that displays a first screen for accepting a predetermined operation on a terminal operated by the first user; a setting unit that sets the first user as a player of the multiplayer game if the predetermined operation by the first user satisfies a second condition; and a second output unit that displays a second screen on a terminal operated by a second user among the multiple users who does not satisfy the first condition, notifying the user that he or she cannot participate in the multiplayer game. This information processing device makes it possible to quickly check whether or not a player can participate in a multiplayer game.

[0139] Issues corresponding to [Appendix 2] One of the objects of the present invention is to be able to give a second user an opportunity to participate in a multiplay game when a first user becomes unavailable. [Supplementary Note 2] In the information processing device according to Supplementary Note 1, the granting unit cancels the priority granted to the first user who did not satisfy the second condition. This information processing device can provide the second user with an opportunity to participate in a multiplay game when a vacancy occurs among the first users.

[0140] Issues corresponding to [Appendix 3] One of the objects of the present invention is to enable a first user to be given the opportunity to participate in a multiplayer game on a first-come, first-served basis when a vacancy occurs among the first users. [Appendix 3] An information processing device as described in Appendix 2, wherein the granting unit grants the priority that was granted to the first user who did not satisfy the second condition to another user who applied for multiplayer play earlier. With this information processing device, when a vacancy occurs among the first users, the opportunity to participate in a multiplay can be given on a first-come, first-served basis.

[0141] Issues corresponding to [Appendix 4] One of the objects of the present invention is to prioritize filling a vacancy with a second user when a vacancy occurs with a first user. [Appendix 4] The information processing device according to appendix 2, wherein the granting unit notifies the terminal of a second user who satisfies a predetermined condition of re-recruitment of players for multiplayer play. With this information processing device, when a vacancy occurs in the first user, the second user can be given priority in filling the vacancy.

[0142] Issues corresponding to [Appendix 5] One of the objectives of the present invention is to provide priority on a first-come, first-served basis within available quota. [Appendix 5] The information processing device according to appendix 1, wherein the first condition is that the order in which applications for multiplayer play are accepted is within the number of people being recruited. This information processing device allows priority to be given on a first-come, first-served basis within the number of people being recruited.

[0143] Issues corresponding to [Appendix 6] One of the objects of the present invention is to prompt a user to whom priority has been granted to perform a predetermined operation. [Supplementary Note 6] The information processing device according to Supplementary Note 1, wherein the second condition is to perform a predetermined operation within a predetermined time from the display of the first screen. This information processing device can prompt a user to whom priority has been granted to perform a predetermined operation.

[0144] Issues corresponding to [Appendix 7] One of the objects of the present invention is to allow users who are more likely to participate to have an extended time to select game media. [Appendix 7] An information processing device as described in Appendix 6, wherein the setting unit extends the specified time when an operation to change the game medium is received during selection of the game medium. This information processing device can prevent a situation in which a user who is likely to participate is unable to join a multiplayer game due to time running out.

[0145] Issues corresponding to [Appendix 8] One of the objects of the present invention is to adjust the length of the predetermined time period depending on the attributes of the user. [Appendix 8] The information processing device according to appendix 6, wherein the setting unit individually sets the predetermined time to be applied to the first user according to the attributes of the first user. This information processing device makes it possible to adjust the length of the predetermined time period in accordance with the attributes of the user.

[0146] Issues corresponding to [Appendix 9] One of the objects of the present invention is to make it easier for users who have frequently failed to satisfy the second condition to participate in multiplay. [Appendix 9] An information processing device as described in Appendix 8, wherein the setting unit sets a first specified time for a first user who has failed to satisfy the second condition more times within the specified time to be longer than a second specified time for a first user who has failed to satisfy the second condition less times. This information processing device makes it easier for users who have not satisfied the second condition many times to participate in multiplay.

[0147] Issues corresponding to [Appendix 10] One of the objects of the present invention is to make it easier for users who log in infrequently to participate in multiplayer games. [Supplementary Note 10] In the information processing device according to Supplementary Note 8, the setting unit sets the first predetermined time for a first user who logs in less frequently to be longer than the second predetermined time for a first user who logs in more frequently. This information processing device makes it easier for users who log in infrequently to participate in multiplayer games.

[0148] Issues corresponding to [Appendix 11] One of the objects of the present invention is to enable selection of game media based on the selections of the user who has invited a multiplayer game and other users. [Appendix 11] An information processing device as described in Appendix 1, wherein the first output unit presents on the first screen information on at least one of the game media selected by the user who requested a multiplayer game and the game media selected by other first users. This information processing device makes it possible to select game media taking into consideration the selections made by the user who invited the player for multiplayer play and other users.

[0149] Issues corresponding to [Appendix 12] One of the objects of the present invention is to support a user who has been denied participation in a multiplayer game to which he or she has applied, in applying to other multiplayer games with the same or similar conditions. [Appendix 12] The information processing device described in Appendix 1, wherein the second output unit displays a second multi-play that satisfies a condition based on the multi-play and a third multi-play that does not satisfy the condition in a list of one or more multi-plays to which the second user can apply, which is displayed on a terminal operated by the second user, in such a manner that they can be distinguished from each other. This information processing device can support a user who was not accepted to participate in a multiplayer game to which he or she applied to apply for another multiplayer game with the same or similar conditions.

[0150] Issues corresponding to [Appendix 13] One of the objects of the present invention is to support a user who has been denied participation in a multiplayer game to which he or she has applied, in applying to other multiplayer games with the same or similar conditions. [Appendix 13] In the information processing device described in Appendix 12, the second output unit defines the second multiplay as a multiplay in which the game medium that appears is a quest that is the same as or similar to the multiplay. This information processing device can support a user who was not accepted to participate in a multiplayer game to which he or she applied to apply for another multiplayer game with the same or similar conditions.

[0151] Issues corresponding to [Appendix 14] One object of the present invention is to make it possible to notify a player that he or she will not be able to participate in a multiplayer game before a predetermined operation is performed. [Appendix 14] An information processing method which executes the following processes: a processor grants priority to a first user among multiple users who have applied to play in a multiplayer game, who satisfies a first condition; a processor causes a terminal operated by the first user to display a first screen for accepting a predetermined operation; a processor causes the terminal operated by the first user to set the first user as a player of the multiplayer game if the predetermined operation by the first user satisfies a second condition; and a processor causes a terminal operated by a second user among the multiple users who does not satisfy the first condition to display a second screen notifying the user that he or she cannot participate in the multiplayer game. This information processing method makes it possible to notify a player that he or she will not be able to participate in a multiplayer game before the player performs a predetermined operation.

[0152] Issues corresponding to [Appendix 15] One object of the present invention is to make it possible to notify a player that he or she will not be able to participate in a multiplayer game before a predetermined operation is performed. [Appendix 15] A program that executes processing to cause a processor to grant priority to a first user among multiple users who have applied to play in a multiplayer game, who satisfies a first condition, to display a first screen for accepting a specified operation on a terminal operated by the first user, and if the specified operation by the first user satisfies a second condition, to set the first user as a player in the multiplayer game, and to display a second screen on a terminal operated by a second user among the multiple users who does not satisfy the first condition, notifying the user that he or she cannot participate in the multiplayer game. This program makes it possible to notify a player that they will not be able to participate in a multiplayer game before a specific operation is performed.

[0153] Issues corresponding to [Appendix 16] One object of the present invention is to make it possible to notify a player that he or she will not be able to participate in a multiplayer game before a predetermined operation is performed. [Appendix 16] An information processing system having: a granting unit that grants priority to a first user who satisfies a first condition among multiple users who have applied to play in a multiplayer game; a first output unit that displays a first screen for accepting a predetermined operation on a terminal operated by the first user; a setting unit that sets the first user as a player of the multiplayer game if the predetermined operation by the first user satisfies a second condition; and a second output unit that displays a second screen on a terminal operated by a second user among the multiple users who does not satisfy the first condition, notifying the user that he or she cannot participate in the multiplayer game. This information processing system makes it possible to notify a player that they will not be able to participate in a multiplayer game before the player performs a predetermined operation. [Explanation of symbols]

[0154] 1...information processing system, 10...server, 11, 21...processor, 12, 22...memory, 13, 23...auxiliary storage device, 14, 24...communication interface, 25...display, 20, 20A, 20B, 20C, 20D, 20E, 20W...user terminal, 101...assignment unit, 101...notification unit, 102...first output unit, 103...setting unit, 104...second output unit, 110...storage unit

Claims

1. a granting unit that grants priority to a first user who satisfies a first condition among a plurality of users who have applied to play in a multiplayer game; a first output unit that displays a first screen for receiving a predetermined operation on a terminal operated by the first user; a setting unit that sets the first user as a player of the multiplay when the predetermined operation by the first user satisfies a second condition; a second output unit that displays a second screen notifying a second user, who does not satisfy the first condition, of the plurality of users that the second user cannot participate in the multiplay on a terminal operated by the second user; An information processing device having the above configuration.

2. The granting unit cancels the priority granted to the first user who does not satisfy the second condition. The information processing device according to claim 1 .

3. The granting unit grants the priority right granted to the first user who did not satisfy the second condition to another user who applied to play in the multiplay earlier. The information processing device according to claim 2 .

4. The granting unit notifies a terminal of a user who satisfies a predetermined condition among the second users of a re-recruitment of players for the multiplay. The information processing device according to claim 2 .

5. The first condition is that the order of acceptance of the application for the multiplayer game is within the number of people being recruited. The information processing device according to claim 1 .

6. the second condition is that the predetermined operation is performed within a predetermined time from the display of the first screen. The information processing device according to claim 1 .

7. When an operation for changing the game medium is received during selection of the game medium, the setting unit extends the predetermined time. The information processing device according to claim 6.

8. The setting unit sets the predetermined time period to be applied to the first user individually in accordance with an attribute of the first user. The information processing device according to claim 6.

9. The setting unit sets a first predetermined time for the first user who has not satisfied the second condition many times within the predetermined time to be longer than a second predetermined time for the first user who has not satisfied the second condition many times. The information processing device according to claim 8.

10. The setting unit sets a first predetermined time for the first user who logs in less frequently to be longer than a second predetermined time for the first user who logs in more frequently. The information processing device according to claim 8.

11. The first output unit presents, on the first screen, information on at least one of a game medium selected by the user who has invited the multiplayer game and a game medium selected by another first user. The information processing device according to claim 1 .

12. The second output unit, in a list of one or more multiplays to which the second user can apply, which is displayed on a terminal operated by the second user, displays a second multiplay that satisfies a condition based on the multiplay and a third multiplay that does not satisfy the condition in a manner that makes them distinguishable from each other. The information processing device according to claim 1 .

13. the second output unit defines a multiplay in which a game medium that appears has a quest that is the same as or similar to the multiplay as the second multiplay; The information processing device according to claim 12.

14. A process in which the processor grants priority to a first user who satisfies a first condition among a plurality of users who have applied to play in a multiplayer game; A process by a processor to display a first screen for receiving a predetermined operation on a terminal operated by the first user; a process in which, when the predetermined operation by the first user satisfies a second condition, the processor sets the first user as a player of the multiplay; a process by the processor of displaying a second screen on a terminal operated by a second user among the plurality of users who does not satisfy the first condition, the second screen notifying the user that the user cannot participate in the multiplay; An information processing method for performing the above.

15. causing the processor to give priority to a first user who satisfies a first condition among a plurality of users who have applied for the multiplay; causing a processor to display a first screen for receiving a predetermined operation on a terminal operated by the first user; when the predetermined operation by the first user satisfies a second condition, causing a processor to set the first user as a player of the multiplay; causing the processor to display, on a terminal operated by a second user among the plurality of users who does not satisfy the first condition, a second screen notifying the user that the second user cannot participate in the multiplay; A program that executes a process.

16. a granting unit that grants priority to a first user who satisfies a first condition among a plurality of users who have applied to play in a multiplayer game; a first output unit that displays a first screen for receiving a predetermined operation on a terminal operated by the first user; a setting unit that sets the first user as a player of the multiplay when the predetermined operation by the first user satisfies a second condition; a second output unit that displays a second screen notifying a second user, who does not satisfy the first condition, of the plurality of users that the second user cannot participate in the multiplay on a terminal operated by the second user; An information processing system having the above configuration.

Images