Information processing device, information processing method, and program

Abstract

To prevent an opportunity for desired processing to be executed from being lost in a configuration in which a content of processing executed in an event within a game is determined according to a play situation of the game prior to holding of the event.SOLUTION: An information processing device includes: a changing unit for changing attributes of an object user according to whether the object user that plays a game is in a state that he or she has not executed a predetermined play of the game for a predetermined period; and a processing unit for executing processing according to the attributes of the object user when the object user plays the game during an event holding period in the game. The changing unit does not change the attributes of the object user even when the object user executes the predetermined play from a predetermined time point prior to the event holding period to the holding of the event.SELECTED DRAWING: Figure 6

Description

[Technical field]

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

[0002] It is important for game providers to keep users who play a game from getting bored and to keep them playing. For this reason, the game play status of users of the game may be managed, and measures may be taken to encourage users who have not played the game for a certain period of time to play the game again.

[0003] For example, as described in Patent Document 1, an event (an event within a game) may be held to encourage users who have not played a game for a long time to play the game again. This makes it possible to draw users who have not played for a long time back into the game. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2018-187400 A Summary of the Invention [Problem to be solved by the invention]

[0005] In addition, as part of a measure to attract users who have not played for a long time to play the game, it is assumed that attributes are set for users according to whether or not they have not played the game for a specified period of time, and when a user with a specific attribute plays the above-mentioned event and satisfies a specified condition, a process such as granting a reward is executed. In such a case, a user who expects the desired process to be executed will maintain the specific attribute until the event is held and participate in the event.

[0006] However, if a user with a particular attribute plays the game at a certain time before the event and the attribute changes as a result, the desired process will not be executed even if the user attends the event afterwards. In such a case, it may be difficult to attract users who have not played the game for a certain period of time back to the game by holding the event, and there is a risk that the purpose of holding the event will not be achieved.

[0007] Therefore, an objective of the present invention is to provide an information processing device, an information processing method, and a program that are capable of preventing an opportunity to execute a desired process from being missed in a configuration in which the content of the processing to be executed during an in-game event is determined according to the game play status before the event is held. [Means for solving the problem]

[0008] An information processing device according to one embodiment of the present invention comprises a change unit that changes the attributes of a target user depending on whether a target user playing a game has not performed a specified play of the game for a specified period of time, and a processing unit that executes processing according to the attributes of the target user when the target user plays the game during an event period in the game, and is characterized in that the change unit does not change the attributes of the target user even if the target user performs a specified play from a specified point in time prior to the event period until the event is held. Effect of the Invention

[0009] According to one aspect of the present invention, when the content of processing to be executed during an in-game event is determined based on the game play status before the event is held, it is possible to prevent a target user from missing an opportunity to have the desired processing executed. [Brief description of the drawings]

[0010] [Figure 1] FIG. 13 is a diagram showing a schedule for an event. [Diagram 2]1 is a conceptual diagram of a gaming communication system including an information processing device according to one embodiment of the present invention. [Diagram 3] FIG. 2 is a diagram illustrating the hardware configuration of each of a terminal and an information processing device according to an embodiment of the present invention. [Figure 4] FIG. 2 is an explanatory diagram of functions of a terminal according to an embodiment of the present invention. [Diagram 5] FIG. 13 shows how the home screen displayed during the game changes as attributes are changed. [Figure 6] FIG. 2 is an explanatory diagram of functions of an information processing device according to an embodiment of the present invention. [Figure 7] FIG. 13 is a diagram showing conditions for granting rewards. [Figure 8] FIG. 13 is a diagram showing types of rewards. [Figure 9] FIG. 1 is a diagram showing a process flow relating to playing an event (part 1). [Figure 10] FIG. 13 is a diagram showing a process flow relating to playing an event (part 2). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] An information processing device, an information processing method, and a program according to the present invention will be described below with reference to preferred embodiments (hereinafter, referred to as the present embodiment) shown in the accompanying drawings.

[0012] The embodiment described below is merely one of the specific examples given to facilitate understanding of the present invention, and is not intended to limit the present invention. In other words, the present invention may be modified or improved from the embodiment described below without departing from the spirit of the present invention. In addition, the present invention naturally includes its equivalents.

[0013] In addition, the screen examples shown in the drawings referenced in the following description are merely examples, and the screen configuration examples, the content of the information displayed, and the GUI (Graphical User Interface), etc. can be freely designed according to the system design specifications and user preferences, and can be changed as appropriate.

[0014] [About the game according to this embodiment] Prior to describing the information processing device according to this embodiment, a specific game (hereinafter simply referred to as a "game") that can be played through the information processing device will be described.

[0015] A game is game content that a user can play by operating a game terminal, and more specifically, is an online game that uses data communication. Here, online games may include, for example, social games that can be used with only a web browser and a social networking service (SNS) account.

[0016] When playing a game, a user performs a login operation on his / her own terminal. The login operation is an operation performed in order to play a game, and corresponds to, for example, an operation for starting an application program for the game, or an operation for inputting login information (specifically, a user name, a password, etc.). When the login operation is performed, communication begins between the information processing device according to this embodiment and the user's terminal.

[0017] After logging in, the user can play game units called quests or stages (hereafter referred to as quests). A quest is an in-game event that usually has a time limit and is played with the goal of clearing it (satisfying the conditions for achievement) within the time limit.

[0018] In this embodiment, a user can play a quest alone, and can also play the same quest together with other users. That is, multiple users can play the same quest together at the same time. Such a cooperative play (multiplay) is realized by one user acting as a host and other users acting as guests.

[0019] A host is one form of participation in cooperative play, and invites guests to play quests together with the guests. When inviting guests, the user who will be the host selects the quest to be played on a selection screen (not shown), specifies cooperative play, and waits for applications from other users. The host also has the authority to instruct the start of joint play and can start joint play at a timing determined by the host. In this embodiment, at least two users (in other words, a host and one or more guests) are required to start joint play.

[0020] A guest is a participant who applies for a quest from a host and plays a quest together with the host. When applying for a quest from a host, a user who is to become a guest selects the quest to be played on a selection screen (not shown), and if there is a host who is recruiting guests for the selected quest, the user specifies that host and applies to become a guest (for example, by touching the host's icon displayed on the screen).

[0021] Co-op play can be realized by using known communication technology. Specifically, when one user acts as a host and invites guests, and other users apply for the invitation, a communication path for co-op play is established, and then data communication required for co-op play is performed according to a known communication method.

[0022] Furthermore, in games, events are held according to a predetermined schedule. In the events, players can play quests (stages) specific to the event. Event information (e.g., the event period, etc.) is usually announced through a home screen displayed within the game, or by using media such as television or the Internet.

[0023] In the present embodiment, the event is held for the purpose of inducing users to play the game. More specifically, an event planned for the purpose of inducing users with a specific attribute to play the game is held for a predetermined period of time.

[0024] Here, the user's attribute is determined according to whether or not the user has not performed a specified play of the game for a specified period of time. If the user has not performed a specified play for a specified period of time, the user's attribute is a first attribute, and if the user has not performed a specified play for a specified period of time, the user's attribute is a second attribute. "Predetermined play" includes playing a game quest, playing a quest together or alone, logging into the game, etc. Also, playing the game so that a status value (for example, a user rank, which will be described later) is equal to or greater than a reference value also falls under "predetermined play". The "predetermined period" is an arbitrary period, and in this embodiment, it is set to N days (N is a natural number) as an example. "A state in which a predetermined play has not been performed for a predetermined period of time" corresponds to, for example, a state in which N days have passed since the last login, or since the last time a quest was played (or since the last time a cooperative play was performed). Also, a state in which a status value (for example, a user rank, described below) does not reach a reference value for a period of N days is included in "a state in which a predetermined play has not been performed for a predetermined period of time". Furthermore, a state in which a player has never played a game before is also included in "a state in which a predetermined play has not been performed for a predetermined period of time". In this embodiment, a state in which N days have elapsed since the last login, or a state in which the player has never played the game and has never logged in, is defined as a "state in which a specified play has not been performed for a specified period of time."

[0025] In this embodiment, the attributes are classified into three types: "defective", "new", and "existing". Churn is an attribute when N days have elapsed since the last (most recent) login. The attribute may be churn when N days have elapsed since the last time a cooperative play was performed. Alternatively, for a user who has only logged in but has not played a quest, the attribute may be churn when N days have elapsed since the user last played a quest. The "new" attribute is for a user who has never played the game before and has never logged in to the game. The "dismissed" and "new" correspond to the first attribute that satisfies the above-mentioned predetermined conditions. The existing attribute is an attribute when the time elapsed since the last login has not reached N days. The existing attribute corresponds to the second attribute that does not satisfy the above-mentioned predetermined condition.

[0026] The classification of attributes is not limited to the above three types (i.e., defection, new, and existing). For example, an attribute when the user rank does not reach a reference value may be a first attribute, and an attribute when the user rank reaches the reference value may be a second attribute. The user rank is a user's status value that increases according to, for example, the number of times a quest is cleared.

[0027] In this embodiment, an event is held for the purpose of inducing users whose attributes are lapsed or new to the game. In other words, by holding the event, it is possible to arouse interest or concern in the game among users whose attributes are lapsed or new, and in particular to bring users whose attributes are lapsed back to the game. In the following description, "playing an event" means playing a quest for the event.

[0028] In this embodiment, in order to effectively achieve the purpose of the event described above, if a user satisfies a predetermined condition during the event period, the user is given a reward. Here, the predetermined condition is that the user plays together with other users and clears the event quest together with the other users. However, the condition is not limited to this, and may be, for example, that the user plays the event together with other users, that the number of times the event quest is cleared reaches a predetermined number, or that the number of times the user logs in during the event period reaches a predetermined number.

[0029] Regarding the conditions for providing rewards, if a user with a defecting or new attribute cooperates with another user to clear a quest for an event, a reward is provided to the new or new attribute user. Also, if a user with an existing attribute becomes a host and cooperates with another user with a defecting or new attribute as a guest to clear a quest for an event, a reward is provided to the existing attribute user.

[0030] The reward is an item and character (hereinafter, "item") that can be used in the game, or a valuable item that can be exchanged for an item (for example, virtual currency that can be used in the game, or an item required to conduct a lottery for an item in the game). In addition, a function that can be temporarily enjoyed during the game progress (for example, an effect such as increasing a character's status value) may be given as a reward. In addition, a coupon that can be used at an actual store may be given as a reward.

[0031] It should be noted that "granting a reward" means providing the user to whom the reward is to be granted with data for using the reward in the game or at a real store, etc. For example, when granting a reward that can be used in the game, such as an item, value that can be exchanged for an item, or efficacy, data for playing the game after obtaining the reward is provided. When granting a reward that can be used at a real store, such as a coupon, text data or image data for presenting the reward at the store, etc. is provided.

[0032] A user who expects to receive a reward in an event needs to play the event with his / her own attribute being lapsed or new, or to play the event together with other users with the attribute being lapsed or new.

[0033] On the other hand, an event is announced before it is held. Specifically, as shown in Figure 1, an event announcement period is set before the event is held, and the event is announced within this announcement period. In this embodiment, the event period is set to, for example, one week to several weeks, or one month to several months, and the event announcement period is set to be shorter than the event period, for example, one day to several days, or one week to several weeks.

[0034] In the schedule shown in FIG. 1, suppose that a user with the attribute of defection happens to play or log into the game at a certain point during the event announcement period (specifically, at the point indicated by the cross in FIG. 1). In that case, the user's attribute is changed from defection to existing. Even if the user plays the event after that, he or she will not be given a reward unless he or she plays together with another user with the attribute of defection or new. By missing the opportunity to receive a reward in this way, the user's motivation to play the event may be lost, and as a result, the purpose of holding the event may not be achieved.

[0035] Therefore, in this embodiment, attribute changes accompanying game play during the event announcement period are postponed. That is, even if the user performs a predetermined play (e.g., playing a quest) from the start of the event announcement (first day of announcement), which is a time point (predetermined time point) before the event is held, until the event is held, the user's attributes do not change and remain the same as at the time of the announcement start. In other words, the user's attributes at the time of the event start are determined by the attributes at the time of the announcement start. As a result, the user can maintain the attributes at the time of the announcement start until the event is held and can participate in the event with those attributes. For example, a user whose attributes at the time of the announcement start are defecting or new can play the event with those attributes.

[0036] Here, the attribute at the time when the notification starts is determined depending on whether or not the time elapsed since the last login date and time has reached N days at that point (including the state where the user has never logged in before). If the time elapsed has reached N days, the attribute at that point will be churn or new. Conversely, if the time elapsed has not reached N days, the attribute at that point will be existing. In addition, to supplement the method of determining the attribute, even if the attribute is an existing attribute at the time of starting the announcement, there may be cases where the above-mentioned elapsed time reaches N days during the announcement period. In this embodiment, even in such a case, as long as the attribute is an existing attribute at the time of starting the announcement, the attribute is maintained as it is until the event is held. However, this is not limited to this, and when the above-mentioned elapsed time reaches N days during the announcement period, the attribute may be changed to defection at that point.

[0037] In addition, in this embodiment, when a user whose attribute is a defector or a new user at the start of the event plays the event and satisfies a predetermined condition, the attribute of the user changes to the existing attribute, and the existing attribute of the user is maintained during the event period thereafter. Here, the predetermined condition is the same condition as the condition for granting a reward, and specifically, the user plays together with another user and clears a quest for the event together with the other user. However, the predetermined condition is not limited to this, and may be, for example, a condition that the event is played together with another user, a condition that the number of times the quest for the event is cleared reaches a predetermined number, or a condition that the number of times the user logs in during the event period reaches a predetermined number.

[0038] In addition, even if the attribute is changed to an existing attribute during the event period, there may be cases in which the time elapsed from the last login date and time reaches N days during the subsequent event period. In this embodiment, even in such a case, since the attribute is changed to an existing attribute during the event period, the attribute is maintained as the existing attribute during the subsequent event period. However, this is not limited to this, and when the above-mentioned time elapsed reaches N days during the event period after the attribute is changed to an existing attribute, the attribute may be changed from an existing attribute to a defection at that point.

[0039] [Gaming information processing system] Next, a description will be given of an information processing system for a game (hereinafter, a game system S) including the information processing device according to this embodiment. In the following, we will focus on one of the users who plays a game using the game system S, and refer to that user as the "target user," while the other users as "other users."

[0040] The gaming system S is an information processing system constructed for a target user to play a game. In the gaming system S, as shown in Fig. 2, terminals 10 of each user including the target user and a server 12 are communicatively connected via a communication network 14 such as the Internet and a mobile communication network. In FIG. 2, for convenience of illustration, the number of terminals 10 is three, but this is not limited to this, and the number of terminals 10 may be any number, and when performing collaborative play of an event, it is sufficient to have at least two terminals 10.

[0041] The terminal 10 is a device that is operated by a user to play a game. The server 12 is an example of an information processing device, which provides data for game progress to the terminal 10 and manages the game progress status and current attributes, etc., for each of multiple users including the target user. In addition, when multiple users play an event together, the server 12 communicates with the terminal 10 of each user to mediate the joint play of the event. In this embodiment, the server 12 is configured by one computer, but is not limited to this and may be configured by a plurality of computers.

[0042] The communication network 14 is a communication line network between the terminal 10 and the server 12, and is mainly composed of the Internet and a mobile communication network, and may include a LAN (Local Area Network), a WAN (Wide Area Network), an intranet, Ethernet (registered trademark), etc.

[0043] [Terminal and server configuration] The configurations of the terminal 10 and the server 12 will be described with reference to Fig. 3. For convenience of illustration, only one terminal 10 is shown in Fig. 3.

[0044] The terminal 10 is a gaming terminal that can be carried by the target user, and specifically, is configured as a smartphone, a mobile phone, a notebook PC, a tablet terminal, a wearable terminal, or a dedicated gaming device with a communication function.

[0045] As shown in FIG. 3, the terminal 10 has, as hardware devices, a processor 21, a memory 22, a communication interface 23, a storage 24, an input device 25 and an output device 26, and these devices are electrically connected via a bus 27.

[0046] Furthermore, as software, a program for an operating system (OS) and an application program for games are installed in the terminal 10. The processor 21 executes these programs, allowing the user to play games through the terminal 10.

[0047] More specifically, the target user starts up a game application program on his / her terminal 10 and performs a predetermined login operation (e.g., pressing a login button). Thereafter, the target user can proceed through the game by performing operations for progressing through the game while viewing the play screen displayed on the display screen. Furthermore, if the target user specifies a quest for joint play in the manner described above, he / she can play the quest jointly with other users.

[0048] The server 12 is a server computer that distributes game data, and is configured, for example, by a server computer for a social game (specifically, an SNS server). As shown in FIG. 3, the server 12 has, as hardware devices, a processor 101, a memory 102, a communication interface 103, a storage 104, an input device 105, and an output device 106, and these devices are electrically connected via a bus 107.

[0049] Furthermore, a program for the OS and an information processing program for the game are installed as software in the server 12. These programs correspond to the “program” of the present invention, and are read by the processor 101 of the server 12. The processor 101 executes the above program, and the server 12 executes various information processes related to the game as an information processing device for the game. Specifically, by executing the above program, the server 12 distributes game data to the terminal 10 of the target user, monitors the game play status of the target user, and updates the attributes of the target user according to the play status.

[0050] Of the hardware devices of the terminal 10 and the server 12, the processors 21, 101 may be configured with a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), an MCU (Micro Controller Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), or the like.

[0051] The memories 22 and 102 may be configured with semiconductor memories such as a Read Only Memory (ROM) and a Random Access Memory (RAM). The communication interfaces 23 and 103 may be configured, for example, by a network interface card or a communication interface board, etc. Incidentally, the standard of data communication by the communication interfaces 23 and 103 is not particularly limited, and examples thereof include communication by wireless LAN based on Wi-fi (registered trademark), communication by a 3G, 4G or 5G mobile communication system, and communication based on LTE (Long Term Evolution).

[0052] Storage 24, 104 is a flash memory, HDD (Hard Disc Drive), SSD It may be composed of a Solid State Drive (SD), Flexible Disc (FD), Magneto-Optical disc (MO disc), Compact Disc (CD), Digital Versatile Disc (DVD), Secure Digital card (SD card), or Universal Serial Bus memory (USB memory), etc.

[0053] The input devices 25 and 105 may be, for example, a keyboard, a mouse, a touch panel, etc. The output devices 26 and 106 may be, for example, a display and a speaker, etc.

[0054] [Device features] Next, the configuration of the terminal 10 will be described again from a functional perspective with reference to FIG. 4, the terminal 10 has a terminal operation unit 31, a terminal transmission unit 32, a terminal reception unit 33, a terminal storage unit 34, and a terminal display unit 35. These functional units are realized by cooperation between the above-mentioned hardware devices of the terminal 10 and various programs as software installed in the terminal 10. Each functional unit will be described below.

[0055] The terminal operation unit 31 accepts a login operation performed by the target user to play the game, or various operations performed by the target user while playing the game. The operations during game play accepted by the terminal operation unit 31 include a designation operation, a selection operation, an application operation, etc. The designation operation is an operation for designating either solo play or cooperative play as the play format for a quest. The selection operation is an operation for selecting either host or guest as the participation format for cooperative play. The application operation is an operation for applying to become a guest when another user is recruiting guests as a host.

[0056] The terminal-side transmitting unit 32 transmits various data related to the game, such as the login date and time of the target user and the contents of operations performed by the target user while playing the game, to the server 12 via the communication network 14. The data transmitted by the terminal-side transmitting unit 32 includes data indicating the contents of each operation, such as a designation operation, a selection operation, and an application operation, accepted by the terminal-side operating unit 31.

[0057] The terminal side receiving unit 33 receives various data transmitted from the server 12 via the communication network 14. The data transmitted from the server 12 includes data for game progress, data for information notification, data related to other users participating in the joint play, and data on rewards given to the target user (strictly speaking, data for using the rewards), etc.

[0058] The terminal-side storage unit 34 stores data that the terminal-side receiving unit 33 receives from the server 12, information that the terminal-side transmitting unit 32 transmits to the server 12, and the like.

[0059] The terminal display unit 35 expands the data received by the terminal receiving unit 33 from the server 12, and displays a game play screen or an information notification screen according to the data on the display of the terminal 10. The screens displayed by the terminal display unit 35 include a home screen shown in FIG.

[0060] Regarding the home screen, as shown in Fig. 5, an icon I indicating the attributes of the target user during the event period is displayed on the screen. This icon I changes with changes in the attributes, and for example, when the attribute is changed from defection or new to existing, the display state shown in the upper diagram of Fig. 5 is changed to the display state shown in the lower diagram.

[0061] [Server Functions] Next, the configuration of the server 12 will be described again from a functional standpoint with reference to FIG. 6, the server 12 has a server-side transmitting unit 111, a server-side receiving unit 112, a server-side storage unit 113, a changing unit 114, and a processing unit 115. The processing unit 115 has a reward granting processing unit 116 and a user number determination unit 117. These functional units are realized by cooperation between the hardware devices of the server 12 described above and various programs as software installed in the server 12. Each functional unit will be described below.

[0062] The server-side transmitting unit 111 transmits various data related to the game, including data for game progress, to the target user's terminal 10. The data transmitted by the server-side transmitting unit 111 includes data for information notification, for example, display data for a home screen including the aforementioned icon I for confirming attributes.

[0063] The server-side receiving unit 112 receives various data related to the game, such as data indicating the content of operations performed by the target user while playing the game, sent from the target user's terminal 10. The data received by the server-side receiving unit 112 includes, for example, data indicating the date and time when the target user performed a login operation.

[0064] The server-side storage unit 113 stores the current attributes of the target user and each of the other users. The server-side storage unit 113 also stores information indicated by the data received by the server-side receiving unit 112, including the target user's last login date and time. Furthermore, the server-side storage unit 113 stores the number of times the target user played an event together with other users during the event period (hereinafter referred to as the number of times of joint play).

[0065] The change unit 114 changes the attributes of the target user stored in the server-side memory unit 113 depending on the game play status of the target user (i.e., whether or not the target user has not performed a specified play of the game for a specified period of time). For example, when the attribute of the target user is "leaving," when the target user logs in to play a game, the server-side receiving unit 112 receives data indicating the time of login from the target user's terminal 10. The change unit 114 uses this as a trigger to change the attribute of the target user stored in the server-side storage unit 113 from "leaving" to "existing."

[0066] Also, as described above, in this embodiment, even if a target user whose attribute is defector or new plays a game during the event announcement period, the change unit 114 does not change the attribute of the target user (postpones the attribute change) and leaves the attribute as defector or new. Furthermore, when a target user with an attribute of defector or new plays an event together with other users and clears a quest for the event, the change unit 114 changes the attribute of the target user from defector or new to existing. After that, the attribute of the target user is maintained as it is during the event period.

[0067] When the target user plays a game during the event period, the processing unit 115 executes a predetermined process on the target user. The content of the process executed by the processing unit 115 on the target user differs between a case where the attribute of the target user during the event period is defection or new, and a case where the attribute of the target user during the event period is existing.

[0068] Specifically, when a target user plays cooperatively with other users and clears a quest for an event, the reward granting processing unit 116 of the processing unit 115 executes a reward granting process to grant a reward according to the attributes of the target user. The reward granting rules will be explained with reference to FIG. 7. In the case where any of the following cases (1) to (3) applies, the reward granting processing unit 116 executes the reward granting process to grant a reward to the target user. (1) When a target user whose attributes are a defector or new user becomes a host and plays an event together with another user as a guest. (2) When a target user with an existing attribute acts as a host and plays an event together with another user with a defected or new attribute as a guest. (3) When a target user whose attributes are a defector or new user becomes a guest and plays an event together with another user who is a host and is recruiting guests. As shown in Fig. 7, even if a target user with an existing attribute becomes a host and plays an event together with other users with existing attributes, the reward granting process is not executed. Also, if a target user with an existing attribute becomes a guest and plays an event together with other users with defected or new attributes as a host, a reward is granted to the other users, but no reward is granted to the target user.

[0069] Returning to the explanation of the reward granting process, the content of the reward granted to the target user in the reward granting process is determined according to the attributes of the target user at that time. The content of the reward also depends on the number of users (including the target user) who played the event together that have attributes of defection or new users (hereinafter referred to as the number of co-play users). The content of the reward will be explained with reference to the example shown in Fig. 8. For example, when a target user whose attribute is defector or new plays an event together with other users and clears a quest for the event, the target user will be given a reward of "1 item A + 1 item B + reward C." This reward will be given only when the target user's attribute is defector or new. Here, when a defecting or new target user participates in a joint play of an event and clears a quest for the event, the attribute of the target user is changed to the existing attribute accordingly, and the existing attribute is maintained during the event period thereafter. Therefore, the number of times the reward described above is given during the event period is only one.

[0070] Also, assume that a target user with an existing attribute becomes a host, and other users with defecting or new attributes become guests, and play an event together with the other users to clear a quest for the event. In this case, the user number determination unit 117 of the processing unit 115 determines the number of users with defecting or new attributes (hereinafter, referred to as the number of cooperative play users) among the multiple users who performed cooperative play. The number of cooperative play users corresponds to the number of other users who play the event together with the target user and who have defecting or new attributes.

[0071] Then, the reward granting processing unit 116 grants the target user a reward according to the number of co-play users. For example, if the number of co-play users is two, in the example shown in FIG. 8, a reward for two users (one item A, two items B, and special offer C) is granted. Incidentally, in the example shown in Fig. 8, the number of co-play users is counted up and carried over to subsequent gameplays. For example, suppose that the number of co-play users at a certain point in time is two, and in the next co-play, the target user plays an event with three other users whose attributes are defectors or new users. In that case, the reward given to the target user will be "1 item A + 2 items B + reward C" x 3 people, and the number of co-play users will be counted up to 5 (= 2 people + 3 people). In the example shown in Fig. 8, when the number of co-play users reaches 5, all of the rewards prepared for the target user will be granted. However, there is no need to set a particular limit on the number of rewards granted to the target user, and even if there is a limit, the number (i.e., the upper limit of the number of rewards granted) may be determined arbitrarily.

[0072] [Information processing flow according to this embodiment] Next, the information processing flow by the gaming system S, in particular the flow related to playing an event, will be described with reference to FIGS. The process flow described below employs the information processing method of the present invention. In other words, each step in the process described below corresponds to a component of the information processing method of the present invention. In the following, the target user is assumed to be user X, and the flow from before the event announcement begins to the end of the event will be described.

[0073] The process flow starts with a user X logging in to the terminal 10 to play a game. Specifically, as shown in Fig. 9, when the flow starts, the terminal operation unit 31 of the terminal 10 accepts the login operation, and the terminal transmission unit 32 transmits data indicating the login date and time to the server 12 (S001). The server reception unit 112 receives the above data transmitted from the terminal 10 (S002).

[0074] Thereafter, the server-side transmitting unit 111 transmits data for game progress to the terminal 10 of the user X (S003), and the terminal-side receiving unit 33 receives the transmitted data (S004). This starts playing the game on the terminal 10 of the user X.

[0075] On the other hand, when the user X performs various operations while playing the game, the terminal operation unit 31 accepts the operations, and the terminal transmission unit 32 transmits data indicating the contents of the accepted operations to the server 12 (S005). The data transmitted by the terminal transmission unit 32 includes data indicating the contents of a designation operation, a selection operation, an application operation, etc. In the server 12, the server reception unit 112 receives the operation data transmitted from the terminal 10 (S006).

[0076] Next, the server 12 determines whether the current time is before the event is announced (S007), and if it is before the event is announced, it further determines whether the attribute of user X stored in the server-side memory unit 113 is lapsed or new (S008). If the attribute of user X is defected or new, the change unit 114 of the server 12 changes the attribute of user X stored in the server-side storage unit 113 to an existing attribute (S009). If the attribute of user X is an existing attribute, the attribute of user X is maintained as it is (S010). If the current time is before the event is announced, the process flow ends when the game play ends (S011).

[0077] If the current time is not before the event announcement in step 007, it is determined whether the event is in the event announcement period or during the event (S012), as shown in Fig. 10. If the current time is during the event announcement period and the attribute of user X stored in the server-side storage unit 113 at the announcement start time is lapsed or new, the change unit 114 does not change the attribute of user X to the existing attribute even if user X logs into the game during the announcement period. Therefore, the attribute of user X is maintained as lapsed or new during the event announcement period. On the other hand, if the attributes of user X at the time of the start of the announcement are the existing ones, the attributes of user X are maintained as they are during the event announcement period. During the event announcement period, the processing flow ends when the game ends. (S011).

[0078] If it is determined in step S012 that the current time is during an event, when user X plays the event during that time and completes a quest for the event (S013), the server 12 determines the play style at that time (S014). If the play mode determined in step S014 is cooperative play, the server 12 determines whether the user X is a host or a guest in the cooperative play (S015). After that, the server 12 further determines the attributes of the user X stored in the server-side storage unit 113 at the time of playing the event (strictly speaking, at the time of clearing the quest) (S016, S017).

[0079] The attributes of User X in steps S016 and S017 are determined according to the attributes at the start of the event period and whether or not the event quest has been cleared through cooperative play. The attributes at the start of the event period are the attributes that have been maintained since the start of the event announcement, and the attributes at the start of the announcement are determined according to the date and time 2 of the last login operation performed before the announcement starts. Specifically, if N days have elapsed since the last login date and time (including cases where no login operation has been performed in the past), User X's attribute becomes churn or churn, and if N days have not elapsed, User X's attribute becomes existing. In addition, if User X, whose attribute is defector or new at the start of the event period, has not yet cleared the event quest by playing together with other users, User X's attribute at that time will be defector or new. In cases other than those mentioned above, such as when User X's attributes already exist at the time the event announcement begins, or when User X has cleared a quest for the event by playing together with other users, User X's attributes will be considered existing.

[0080] In steps S016 and S017, if the attribute of user X stored in the server-side storage unit 113 is defected or new, the processing unit 115 (more specifically, the reward granting processing unit 116) of the server 12 executes a reward granting process (S018). As a result, a reward is granted to user X who clears the event quest by playing together with other users. At this time, the content of the reward granted to user X will be the content when the attribute of user X is defected or new, for example, "1 item A + 2 items B + benefit C" in the case shown in FIG. 8.

[0081] Furthermore, if the attribute of user X stored in the server-side storage unit 113 is defected or new, when user X clears the event quest by playing together with another user, the change unit 114 changes the attribute of user X to the existing attribute (S019). After that, the attribute of user X is maintained as it is during the implementation period of the event.

[0082] In addition, when user X plays an event as a host and the attributes of user X stored in the server-side memory unit 113 are existing, the server 12 determines whether or not the other users who played the event together with user X as guests include a user whose attribute is defected or new (S020). If the multiple users who have engaged in joint play include other users whose attributes are defectors or new users, the user number determination unit 117 of the processing unit 115 determines the number of other users whose attributes are defectors or new users, i.e., the number of joint play users (S021). When the number of co-play users is one or more, the reward granting processing unit 116 of the processing unit 115 executes a reward granting process, and a reward is granted to the user X who cleared the event quest by co-playing with other users (S022). At this time, the content of the reward granted to the user X depends on the number of co-play users identified in step S021. For example, when the number of co-play users identified is two, for example, in the case shown in FIG. 8, a reward of "one item A + two items B + special benefit C" x two people is granted to the user X.

[0083] On the other hand, if User X, whose attribute is an existing user, plays a joint event as a guest, User X will not receive a reward even if he or she clears the event quest. Also, if User X, who is an existing user, plays a joint event as a host, and the number of joint play users is zero, User X will not receive a reward even if he or she clears the event quest.

[0084] Then, when an event is played during the event period, the processing flow proceeds according to the procedure described above (specifically, the procedure shown in FIG. 10), and the processing flow ends when the game play is finally completed (S011).

[0085] [summary] The server 12 as an information processing device according to this embodiment includes a change unit 114 and a processing unit 115. The change unit 114 changes the attributes of the target user depending on whether the target user has not performed a predetermined play of the game for a predetermined period of time, and the processing unit 115 executes processing according to the attributes of the target user when the target user plays a game during an event period. In addition, the change unit 114 does not change the attributes of the target user even if the target user plays a game from a predetermined time point before the event period until the event is held. With this configuration, the target user can maintain the attributes at the predetermined time point before the event is held until the event is held, and can participate in the event with those attributes. As a result, if a target user desires a process that would be executed if the user played a game with a specific attribute during the event period, the target user can ensure that the process is executed without missing an opportunity to execute the process. In other words, a target user whose attribute is a specific attribute at a predetermined time before the event is held can play the event while maintaining the specific attribute, since the attribute does not change between the predetermined time and the event. As a result, the target user can enjoy the benefit of the process that would be executed if the user played a game with a specific attribute during the event period.

[0086] In addition, in this embodiment, if a predetermined play has not been performed for a predetermined time at a predetermined time point before the event is held, the attribute of the target user is set to the first attribute (defector or new), and otherwise the attribute of the target user is set to the second attribute (existing). In other words, the attribute of the target user is determined according to the state at a predetermined time point before the event is held, and the target user can maintain the attribute at the predetermined time point until the event is held and participate in the event.

[0087] In addition, in this embodiment, the content of the processing performed by the processing unit 115 when the attribute of the target user is departing or new during the event period differs from the content of the processing performed when the attribute of the target user is existing during the event period. In the above configuration, there are cases where the target user is about to play an event in anticipation of a process that is executed when the attribute is, for example, defection or new. In such cases, a configuration that does not change the attribute even if the target player plays the game from a predetermined point before the event is held until the event is held is meaningful.

[0088] Furthermore, in this embodiment, when the play of a target user who has defected or is new satisfies a predetermined condition during the event period (specifically, when a quest for the event is cleared in a cooperative play), the change unit 114 changes the attribute of the target user to the existing attribute. This makes it possible to limit the number of times that the process performed when the attribute of the target user is defected or new (specifically, the reward granting process when the attribute of the target user is defected or new) is performed during the event period. As a result, for example, it is possible to increase the rarity (scarcity) of the reward granted to the target user when the attribute is defected or new.

[0089] In addition, in this embodiment, the attribute of the target user that is changed from defection or new to existing during the event period is maintained as it is during the event period thereafter. This makes it possible to limit the number of times that the reward granting process is executed when the attribute of the target user is defection or new to one. As a result, it is possible to further increase the rarity (scarcity) of the reward granted to the target user when the attribute is defection or new.

[0090] In this embodiment, the reward granting processing unit 116 of the processing unit 115 executes a reward granting process to grant a reward to a target user who plays an event together with other users during the event period and clears a quest for the event, according to the attributes of the target user. In such a configuration, the target user tries to play the event with an attribute of defection or new in order to obtain a reward. In such a case, a configuration in which the attribute is not changed even if the target player plays the game from a predetermined point before the event is held until the event is held is meaningful.

[0091] In addition, in this embodiment, when a target user with an existing attribute becomes a host during the event period and plays an event together with another user with a defecting or new attribute as a guest, the reward granting processing unit 116 executes the reward granting process. With this configuration, even if the target user has an existing attribute, a reward is granted by playing together with another user with a defecting or new attribute, so that the target user's motivation for playing together can be aroused.

[0092] In this embodiment, when a target user whose attribute is defection or new becomes a host during an event period and plays an event together with another user as a guest, the reward granting processing unit 116 executes a reward granting process. With this configuration, a reward is granted to the target user whose attribute is defection or new, regardless of the attributes of the other users, so that the target user's motivation for playing together can be aroused.

[0093] In the reward granting process of this embodiment, the reward granting processing unit 116 grants a reward to the target user according to the number of users with the attribute of defection or new among the multiple users who played the event together (i.e., the number of co-play users). This can more effectively stimulate the target user's motivation to play together with other users with the attribute of defection or new.

[0094] In addition, although it is an embodiment different from this embodiment, when a target user with an existing attribute becomes a host during the start period of an event and plays an event jointly with another user with a defecting or new attribute as a guest, the processing unit 115 may specify the number of times (the number of times of joint play). In this case, in the reward granting process, the reward granting processing unit 116 may grant the target user a reward according to the number of times of joint play. Even with such a configuration, it is possible to more effectively arouse the target user's motivation to play jointly with other users with defecting or new attributes.

[0095] In this embodiment, the predetermined time is the start time of the announcement of the event. For example, when the announcement of an event starts, there is a tendency for an increase in users to react to the announcement and play the game in a predetermined way (specifically, log in or play a quest). Even in such a situation, since the attributes are not changed even if the predetermined game play is performed from the start time of the announcement to the start of the event, target users whose attributes are defectors or new users at the start time of the announcement can play the event while maintaining their attributes.

[0096] In addition, in the present embodiment, an example of an information processing method using the information processing device of the present invention has been described, but the present invention is not limited thereto. Any information processing method may be used in which a computer changes the attributes of a target user playing a game depending on whether or not the target user has not performed a predetermined play of the game for a predetermined period of time, and when the target user plays during an event period in the game, the computer executes processing according to the attributes of the target user, and the computer does not change the attributes of the target user even if the target user performs a predetermined play from a predetermined time point before the event period until the event is held. With the above information processing method, the target user can maintain the attributes at a predetermined time before the event until the event starts, and can participate in the event with those attributes. This makes it possible to avoid a situation in which a process that would be executed if the user played the game with a specific attribute during the event period is not executed due to a change in attribute before the event starts.

[0097] The information processing method according to the present embodiment is realized by the server 12 alone, or by a combination of the terminal 10 and the server 152. Here, the server 12 may be a server computer for ASP (Application Service Provider), SaaS (Software as a Service), PaaS (Platform as a Service), or IaaS (Infrastructure as a Service). In this case, a series of information processes related to playing the game (excluding input and display of information) are executed by the server 12, so that the terminal 10 is only required to perform operations for progressing the game and display images, etc.

[0098] In addition, in this embodiment, a program that causes a computer that is the server 12 to function as an information processing device has been described. This program is a program that is read by a computer, and causes the computer to change the attributes of a target user playing a game depending on whether or not the target user has not performed a specified play of the game for a specified period of time, and when the target user plays during an event period in the game, causes the computer to execute processing according to the attributes of the target user, and does not cause the computer to change the attributes of the target user even if the target user performs a specified play from a specified point in time prior to the event period until the event is held.

[0099] The above-mentioned program may be obtained by reading it from a computer-readable recording medium, or may be obtained by receiving (downloading) it via a network such as the Internet or an intranet.

[0100] <<Other embodiments>> Although the information processing device, information processing method, and program of the present invention have been described above using specific examples, the above-mentioned embodiment is merely an example, and other embodiments are possible. For example, in the above embodiment, the server 12 functions as the information processing device of the present invention, but some or all of the functions of the server 12 may be provided in the terminal 10.

[0101] In the above embodiment, the processing executed by the processing unit 115 when the target user plays the game during the event period is a reward granting process, and whether or not a reward is granted and the content of the reward to be granted are determined according to the attributes of the target user during the event period. However, the processing executed according to the attributes of the target user during the event period may be a process other than the reward granting process, and may be, for example, a process of progressing the story of the game according to the attributes of the target user. In this case, the content of the processing (for example, the progress of the story, or more simply, the scenario) may be different between the case where the target user's attribute is a defector or new user and the case where the target user's attribute is an existing user, so that the target user whose attribute is a defector or new user can be effectively guided to the event.

[0102] In the above embodiment, when a target user whose attribute is defector or new plays an event together with another user and clears a quest for the event, a reward is given to the target user. However, this is not limited to this, and a reward may be given to the target user even when a target user whose attribute is defector or new clears a quest for the event alone.

[0103] In the above embodiment, the predetermined time before the event is held is the start time of the announcement of the event, and even if the target user performs a predetermined play of the game from the start time of the announcement to the event, the attribute of the target user is not changed. However, this is not limited to this, and for example, the attribute change due to a predetermined play of the game may be postponed from a time other than the start time of the announcement (however, limited to a time before the event is held) to the event. [Explanation of symbols]

[0104] 10 Terminal 12 Server (information processing device) 14 Communication Networks 21 Processors 22 Memory 23 Communication Interface 24. Storage 25 Input Devices 26 Output Devices 27 Bus 31 Terminal side operation unit 32 Terminal side transmitter 33 Terminal side receiving section 34 Terminal side memory unit 35 Terminal display unit 101 Processor 102 Memory 103 Communication Interface 104 Storage 105 Input Device 106 Output Device 107 Bus 111 Server side transmitter 112 Server side receiver 113 Server side storage unit 114 Changes 115 Processing section 116 Reward Granting Processing Unit 117 User Number Identification Unit I Icon S Gaming System

Claims

[Claim 1] a change unit that changes an attribute of a target user who plays a game depending on whether or not the target user has not performed a predetermined play of the game for a predetermined period of time; a processing unit that executes a process according to an attribute of the target user when the target user plays the game during an event period of the game, The change unit is an information processing device that does not change the attributes of the target user even if the target user performs the predetermined play from a predetermined point before the event is held until the event is held.

Images