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

Abstract

To provide an information processing device, information processing method and program enhancing a player's satisfaction by allowing the player to play even such an event that the player has lost an opportunity to play by termination of a time range set for the event.SOLUTION: An information processing device includes a control unit 37 controlling playability of an event based on a relation between a time range set for the event in a game and a current time. After the time range has been terminated, when a prescribed condition is satisfied depending on a prescribed operation of a user, the control unit 37 allows the user having executed the prescribed operation to play the event for a prescribed time.SELECTED DRAWING: Figure 10

Description

Application for application of Article 30, Paragraph 2 of the Patent Act has been filed. [Disclosure fact 1] Website posting date: January 30, 2020, Website address: https://www.youtube.com/watch?v=kKpgNBvMVxc&feature=youtu.be, Publisher: Mixi, Inc. [Disclosure fact 2] Website posting date: January 30, 2020, Website address: https://www.monster-strike.com/news/20200130_7.html, Publisher: Mixi, Inc.

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

Conventionally, games such as online games have been known in which the player selects various events that occur and progresses through the game by completing the selected events.

For example, Patent Document 1 discloses an information processing device that can easily select events (referred to as "quests" in Patent Document 1) that can be played for a limited time, which are the units of play in a game.

JP 2019-188132 A

However, events such as those described in Patent Document 1 are only available for a limited period of time, and so users often miss out on the opportunity to play when the period set for the event ends, which can leave users dissatisfied.

The present invention aims to provide an information processing device, information processing method, and program that can improve a user's game satisfaction by enabling them to play an event even if the time range set for the event has ended and the opportunity to play has been lost.

An information processing device according to one aspect of the present invention has a control unit that controls whether or not an event can be played based on the relationship between a time range set for an in-game event and the current time, and when a predetermined condition is met in response to a predetermined operation by the user after the time range ends, the control unit allows the user who performed the predetermined operation to play the event for a predetermined time.

According to one aspect of the present invention, it is possible to play an event even if the time range set for the event has ended and the opportunity to play has been lost, thereby improving the user's level of satisfaction with the game.

1 is a conceptual diagram of a game system including an information processing device according to an embodiment of the present invention. FIG. 2 is an explanatory diagram showing an example of a time range during which an event is carried out. FIG. 13 illustrates an example of an event list screen. FIG. 13 is a diagram showing an example of a list screen of ended events that can be revived. FIG. 13 is a diagram showing an example of a completed event revival confirmation screen. FIG. 13 is a diagram showing an example of an end event overwrite confirmation screen. FIG. 13 illustrates an example of an event list screen. 1 is a diagram illustrating the hardware configuration of an information processing device and a terminal according to an embodiment of the present invention. FIG. 2 is an explanatory diagram of functions of a terminal according to an embodiment of the present invention. FIG. 2 is an explanatory diagram of functions of a server constituting an information processing device according to an embodiment of the present invention. 13 is a flowchart showing the flow of an event play possibility determination process. 13 is a flowchart showing the flow of an ended event revival process. 13 is a flowchart showing another flow of the ended event revival processing. 13 is a flowchart showing the flow of an ended event revival process in cooperative play.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An information processing device, an information processing method, and a program according to the present invention will be described in detail below with reference to preferred embodiments shown in the accompanying drawings.
The embodiment described below is merely an example 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. Naturally, the present invention also includes equivalents thereof.
Furthermore, the screen examples shown in each of the figures referenced in the following description are merely examples, and examples of the screen configuration, the information displayed, and the specific contents of the GUI (Graphical User Interface), etc., can be freely designed and changed according to the design specifications and user preferences.

<About the game>
The communication system shown in FIG. 1 (hereinafter referred to as game system S) is a communication system including an information processing device according to one embodiment of the present invention (hereinafter referred to as server 30), and provides a game to a user U.

A "game" is an online game provided using the game system S, and is an electronic game in which the player selects various events that occur and progresses through the game (hereinafter referred to as "play") as they complete the selected events. In this embodiment, an example of a game is one in which a user U forms a team of multiple characters, controls the characters through specific actions to fight enemy characters, and progresses by sequentially challenging and clearing multiple events prepared within the game. In the game of this embodiment, the user U can obtain various objects that can be used within the game by logging in, clearing events, purchasing, drawing lots, etc.

"Objects" include, for example, characters that move in response to user U's operations in the game, and items that give an advantage in the game. The number of objects possessed increases in response to logging in, clearing an event, purchasing, winning a lottery, etc., and the number possessed decreases as the object is consumed or discarded in the game.

The "lottery" is one of the mechanisms within the game by which the above objects can be obtained, and is carried out at the request of user U while playing the game. In the lottery, multiple objects with different winning probabilities are prepared as candidates, and one or a predetermined number of objects are selected from the multiple candidate objects, and the selected objects are given to user U.

There are various types of lotteries, including, for example, a "single-shot" lottery that is held only once, and an "N-type" lottery in which N lotteries (N is a natural number equal to or greater than 2) are held in succession. There are also various conditions for holding a lottery, including a lottery that can be held by consuming a lottery item that can be obtained for free, a lottery that can be held by consuming a lottery item that has been purchased for a fee, and a lottery that can be held as a reward for clearing an event.

An "event", also known as a "quest", refers to a task given to the user U in the game, i.e., an individual stage that constitutes the game. A time range and achievement conditions are set for each event, and various events occur as the game progresses. Events include, for example, events in which an player encounters or fights an enemy character, events in which the objective is to reach a certain point, and events in which an object such as an item can be obtained. Completing an event by satisfying the set achievement conditions is referred to as clearing the event, and when the user U clears the event, he or she can receive a clear reward.
In this embodiment, an event in which you fight an enemy character and can obtain that enemy character as a reward for clearing the event, i.e., an event in which you can incorporate the enemy character as an ally into your team in the next or subsequent events, will be taken as an example and will be described below.

"Time range" refers to the range of event duration set for each event, as shown in Fig. 2. A time range is assigned to each event, and is set so that, in principle, some event is always held. Time ranges may also be set to overlap so that multiple events are held simultaneously in the same time period.
2, the time range of "Event Title A" is the two-hour range from 0:00 to 2:00 on February 14th, which is the range indicated by the solid line in the figure, and if the current time is within that time range, user U can play "Event Title A." Also, the time range of "Event Title B" (four hours from 0:00 to 4:00 on February 14th) is set to overlap with the same time period, and user U can select and play either "Event Title A" or "Event Title B" if the current time is within that overlapping time range.

In principle, user U cannot play an ended event that has ended after the set time range has elapsed. However, in this embodiment, even if the event is an ended event, if a predetermined condition is satisfied in response to a predetermined operation by user U, user U who performed the predetermined operation can revive the ended event and play it, so long as the event is within the recovery period of the ended event. Note that the number of times that a ended event can be revived may be limited to a predetermined number of times (for example, once) for each event.

A "recovery period" refers to a period of time (e.g., within 24 hours after the end of an event) during which a user U can revive a ended event by performing a specified operation. For example, as shown in FIG. 2, the recovery period for "Event Title A" is the 24-hour period from 2:00 on February 14th to 2:00 on February 15th, which is the range indicated by the dashed line in the figure. In this case, the period during which a ended event can be revived and played may be limited to within the recovery period, or it may be possible to play the ended event beyond the recovery period by performing a specified operation within the recovery period. Ended events within the recovery period that have not been revived are also referred to as reviveable events.

A "predetermined operation" is an operation that user U performs within the game to revive a ended event, and specifically refers to using an item and consuming that item after the time range of the event has ended. The item used here may be, for example, a general-purpose item that can be used for various purposes within the game, such as for conducting lotteries, or it may be a dedicated item for reviving ended events. Note that if user U has a dedicated item, the dedicated item may be automatically consumed before the general-purpose item when using the item.

The "predetermined condition" is a condition that is set in advance to revive a ended event, and can be satisfied by performing the above-mentioned predetermined operation. In other words, in this embodiment, the predetermined condition is that the user U uses and consumes an item within the recovery period of the ended event.

"Reviving" refers to making the ended event playable for a specified period of time for the user U who performed the specified operation described above.

"Specified time" refers to the time (e.g., one hour) during which the user U who performed the specified operation can play the revived ended event. For example, as shown in FIG. 2, for "Event Title A," if the specified operation is performed at 21:30 on February 14th during the recovery period, the specified time is set to be from 21:30 to 22:30 on February 14th.

In this embodiment, the number of ended events that can be revived and played simultaneously is limited to a predetermined number or less (for example, one, etc.).
For example, if the number of end events that can be played simultaneously is one, and another end event (second event) is revived and made playable in response to the above-mentioned specified operation by user U while an already revived end event (first event) is in a playable state (i.e., within the specified time of the first event), the specified time of the already revived first event is ended and it becomes unplayable, and the playable end event is changed from the first event to the second event. Note that the second event may not be revived and cannot be played until the specified time has elapsed and the first event has ended.

In addition, in this embodiment, after an event has ended, the same event may be held again. For example, as shown in FIG. 2, "Event Title F" is held once at 6:00 on February 14th, but is held again at 18:00 on February 14th. In this case, the first time range (three hours from 6:00 to 9:00 on February 14th) corresponds to the first time range, and the second time range (three hours from 18:00 to 21:00 on February 14th) corresponds to the second time range. In this case, even if the user U performs a predetermined operation between the first time range and the second time range to revive "Event Title F" whose first time range has ended, depending on the timing of the predetermined operation (for example, 17:30 on February 14th), the predetermined time set for the revived "Event Title F" may partially overlap with the second time range. In this way, if the ended event will be held again if you wait a little longer, and an opportunity to play the ended event again without having to consume an item occurs, an alert may be notified to the user U to reconfirm.

Now, referring to Figures 3 to 7, we will explain the transition of screens displayed on the user terminal 10 when the user U revives a ended event. Figures 3 to 7 are examples of screens displayed on the user terminal 10 operated by the user U during gameplay.

First, as shown in FIG. 3, when an event is selected, an event list screen 50 is displayed on the user terminal 10 .
Events that the user U can play, i.e., events within a time range (e.g., "event title Z"), are displayed in a line on the event list screen 50. For each event, an explanation such as the event title, difficulty level, enemy character (character obtained as a clear reward), and remaining time range is displayed so that the content of the event can be recognized.
The event list screen 50 also displays a navigation button 52 for transitioning to a reviveable event list screen 51 for selecting and reviving a ended event.

When the user U taps or otherwise operates the guidance button 52 on the event list screen 50, a reviveable event list screen 51 is displayed as shown in FIG.
The reviveable event list screen 51 displays reviveable events associated with each user U in a line. For each reviveable event, an explanation such as whether or not it has been cleared, the play conditions, the character obtained as a reward for clearing it, the difficulty level, and the remaining recovery period is displayed so that the content of the event can be recognized. The reviveable events displayed on the reviveable event list screen 51 are limited to finished events that are within the recovery period and have not been revived, and finished events that have already been revived are deleted from the reviveable event list screen 51. In addition, a reviveable event that does not satisfy the play conditions, such as when the user U does not have a character that has reached the level to play the event, is displayed in a manner that is distinguishable from other reviveable events (for example, grayed out) so that it cannot be selected even if the user U taps or the like. In addition, the reviveable events are, in principle, arranged in order from the oldest to the oldest end date and time, but it is also possible to select or sort them by tapping the sort button 53 or the like.
The reviveable event list screen 51 also displays the number of special items possessed for reviving ended events.

When the user U selects an arbitrary revivable event that he/she wishes to revive on the revivable event list screen 51 and taps or the like, a ended event revival confirmation screen 54 is displayed as shown in FIG.
The ended event revival confirmation screen 54 displays the details of the event to be revived (e.g., "Event Title A"), an explanation for reviving the event, an accept button 55 and a reject button 56, and provides a final confirmation to the user U as to whether or not to revive the selected event using the item.

On the other hand, when user U selects and taps, etc., any revivable event that he or she wishes to revive on the revivable event list screen 51, if there is a terminated event that has already been revived (limited to events within a specified time period), a terminated event overwrite confirmation screen 57 is displayed, as shown in Figure 6.
The ended event overwrite confirmation screen 57 displays the details of the revived ended event to be deleted (e.g., "Event Title B"), the details of the event to be revived (e.g., "Event Title A"), an explanation for reviving the event, an accept button 55 and a reject button 56, and provides a final confirmation to the user U as to whether or not to revive the selected event using an item after ending the revived ended event. The details of the revived ended event to be deleted also display the remaining specified time.

When user U taps the accept button 55 on the ended event revival confirmation screen 54 or the ended event overwrite confirmation screen 57, an event list screen 50 is displayed in which the revived ended event is displayed alongside events within the time range, as shown in FIG. 7. At this time, the revived ended event is displayed at the top as a matter of priority. Like other events, the revived ended event is displayed with an explanation such as the event title, difficulty level, enemy character (character obtained as a clear reward), and the remaining specified time so that the content of the event can be recognized. In addition, the revived ended event is labeled "revived" so that it can be distinguished from other events. The revived ended event may also be displayed with a different design or color, etc., so that it can be distinguished from other events.

Then, user U can select the ended event that he or she revived on the event list screen 50 and tap or otherwise select the event to play for a specified period of time even if the current time is not within the time range set for that event.

In this embodiment, not only can a user U play alone, but multiple users U can also operate their own user terminals 10 to play a common event simultaneously in what is known as multiplay (hereafter referred to as cooperative play). In this cooperative play, a cooperative relationship is formed between a user U (hereafter referred to as a host) who hosts a cooperative play for a specific event and invites friends, and a user U (hereafter referred to as a guest) who responds to the invitation and participates in the cooperative play, and the progress of the play is synchronized between the users playing cooperatively.

Cooperative play is conducted through the communication function of the user terminal 10 of each user U. Specifically, when a user U applies to participate in a cooperative play invited by a host and the host accepts the application, a communication path for cooperative play is established between the user U as a guest and the host. The qualifications for applying for cooperative play are not particularly limited and can be set arbitrarily. For example, a friend user who has a friendship with a user U and has been mutually approved by the users U may apply.

Then, various data required for cooperative play is sent and received according to a known communication method. The data at this time may be sent in a client-server manner via the server 30, or in a P2P (peer-to-peer) manner without the server 30. The cooperative play style is classified into a fully synchronous type and an asynchronous type, but either style may be adopted. The fully synchronous type includes a key input synchronization type and a command input type, and the asynchronous type includes a server-centralized processing type and a client-distributed processing type.

Note that games that support cooperative play include cooperative play games in which multiple users U cooperate, and competitive games in which users U compete against each other, but either type is acceptable. Also, the upper limit (maximum number of players) on the number of users U in one cooperative play session is not particularly limited and may be set to any number, but it is recommended to set it to a maximum of about four people, for example.

Even in this case of cooperative play, user U can revive a ended event. However, in order to play a revived ended event cooperatively, all users U, both the host and the guest participating in the cooperative play, must perform the above-mentioned specified operation and satisfy the specified conditions. In addition, in order to play a revived ended event cooperatively, it must be at least within the specified time of the ended event revived by the host, and if the specified time of the ended event revived by the host has already passed, the guest will play the revived ended event alone. Note that if an event similar to the ended event revived by the host is within the time range for the guest and does not qualify as an ended event, the guest can participate in cooperative play without having to go to the trouble of reviving that event.

<Configuration of Game System S>
Next, the configuration of a game system S for providing the above game to the user U will be described.
1, the game system S is constructed so that a user U can play a game, and is composed of an information terminal (hereinafter referred to as a user terminal 10) operated by the user U, and a server 30. The user terminal 10 and the server 30 are connected to each other so as to be able to communicate with each other via a network N such as the Internet.

The user terminal 10 is equipped with a program stored therein and a processor that executes the program, and is carried by its owner, the user U, who operates the user terminal 10 when playing. The user terminal 10 may be any known device used as a gaming terminal, such as a smartphone, mobile phone, laptop PC, tablet terminal, wearable terminal, or dedicated gaming device with communication functions. The number of user terminals 10 constituting the game system S is not particularly limited and may be any number, but in FIG. 1, for convenience of illustration, the number of user terminals 10 is shown as three.

The server 30 is a computer that constitutes the information processing device of the present invention. For example, it is constituted by a server computer managed by a game provider, and is responsible for processing the progress of the game. Specifically, it manages the game account and status of each user U, and distributes game progress data to each user U. Furthermore, the server 30 is not limited to a server device consisting of a single computer that performs a specific function on its own, but may be constituted by a group of server devices consisting of multiple computers that are distributed and work together to perform a specific function.

The network N may be any network that connects the user terminal 10 and the server 30 in a state that enables data communication. It may be wired or wireless, and includes the Internet, mobile communication networks, LANs (Local Area Networks), WANs (Wide Area Networks), intranets, Ethernet (registered trademark), and the like. In addition, the user terminals 10 may communicate with each other via the network N, or may communicate directly without going through the network N via Bluetooth (registered trademark), Wifi-Direct, and the like.

In the game system S of this embodiment, the game progresses as a result of the user terminal 10 and the server 30 working together in the above configuration. Specifically, part of the game progress processing is performed on the server 30 side, and part of the graphic processing, etc. is executed on the user terminal 10 side. For example, the server 30 side executes a program including certain rules, logic, and algorithms. Meanwhile, the user terminal 10 side synchronizes with the server 30 and generates various events to progress the game according to the same rules, logic, and algorithms as the program executed on the server 30.

<Configuration of User Terminal 10>
Next, the configuration of the user terminal 10 according to this embodiment will be described.
As shown in Figure 8, the user terminal 10 has, as its hardware configuration, a processor 11, a memory device 12, a communication interface (referred to as communication I/F in Figure 8) 13, an input device 14 and an output device 15, and these devices are electrically connected via a bus not shown.

The processor 11 includes, for example, a central processing unit, a microprocessor, a graphics processing unit, or a digital signal processor, and executes various types of arithmetic processing based on programs or data stored in the storage device 12, and controls each part of the user terminal 10. The programs executed by the processor 11 include an OS (Operating System), which is system software for controlling the entire user terminal 10, and application programs for games, and the functions of the user terminal 10 that constitutes the game system S are fulfilled by reading and executing these various programs by the processor 11.

The storage device 12 includes, for example, a memory or storage, and stores various programs and data.
The memory is composed of semiconductor memory such as ROM (Read Only Memory) and RAM (Random Access Memory), and provides a working area for the processor 11 by temporarily storing programs and data, and temporarily stores various data generated by the processing executed by the processor 11.
The storage stores various data related to the game, and is composed of, for example, flash memory, HDD (Hard Disc Drive), SSD (Solid State Drive), FD (Flexible Disc), MO disk (Magneto-Optical disc), CD (Compact Disc), DVD (Digital Versatile Disc), SD card (Secure Digital card), and USB memory (Universal Serial Bus memory), etc.

The communication interface 13 is, for example, configured with a network interface card (NIC) or the like, and controls the communication processing of the user terminal 10. There are no particular limitations on the communication standard used by the communication interface 13, and any public communication standard can be applied without restrictions. In addition, the communication method used by the communication interface 13 may be a wireless method or a wired method.

The input device 14 is a device that receives operations from the user U and generates data indicating the content of the received operations. Examples that can be used include operation keys, operation buttons, a microphone for collecting sound, and a camera for taking pictures that are provided on the user terminal 10.

The output device 15 is a device that draws a screen to display images and character string information, and plays audio. As an example, a liquid crystal display or an organic electroluminescence (EL) display provided in the user terminal 10, a head-mounted display, and a speaker can be used. In this embodiment, the output device 15 has at least a display. The display may have the functions of both the input device 14 and the output device 15, such as a touch panel display.

Next, the configuration of the user terminal 10 will be described again from a functional perspective with reference to FIG.
9, the user terminal 10 includes a plurality of functional units, specifically, an operation identification unit 16, a terminal-side storage unit 17, a terminal-side generation unit 18, a terminal-side transmission/reception unit 19, and a display processing unit 20. These functional units are realized by cooperation between the hardware devices of the user terminal 10 and programs stored in the user terminal 10 as software.

[Operation identification unit 16]
The operation identification unit 16 is mainly realized by the processor 11 and the input device 14, and identifies the contents of various operations performed by the user U through the input device 14 of the user terminal 10. The operations identified by the operation identification unit 16 include operations for progressing the game and operations related to cooperative play (operations related to inviting participation in cooperative play, applying for cooperative play, and accepting or rejecting the application), etc. The operations for progressing the game also include an operation for selecting an event to be played, an operation for selecting an end event to be revived, and an operation for instructing the use of an item to revive an end event, etc.

[Terminal side storage unit 17]
The terminal-side memory unit 17 is realized mainly by the processor 11 and the storage device 12, and stores various data related to the progress of the game (for example, video data, image data, audio data, etc.).

[Terminal side generation unit 18]
The terminal-side generating unit 18 is mainly realized by the processor 11 and the storage device 12, and generates game operation data and the like according to the operation content of the user U identified by the operation identifying unit 16. The game operation data generated here includes event selection data based on an event selection operation or an end event selection operation, item use instruction data based on an item use instruction operation, and operation data related to joint play (including operation data related to soliciting joint play, applying for joint play, and whether or not the application is accepted). These generated data are transmitted to the server 30 by the terminal-side transmitting/receiving unit 19.

[Terminal side transmitting/receiving unit 19]
The terminal-side transmitting/receiving unit 19 is mainly realized by the processor 11, the storage device 12, and the communication interface 13, and transmits and receives data and information between the server 30 and the user terminals 10 of other users U. For example, while playing a game, the terminal-side transmitting/receiving unit 19 receives game progress data sent from the server 30 and transmits game operation data to the server 30. Furthermore, when a game is being played jointly, the terminal-side transmitting/receiving unit 19 may transmit and receive joint play data (specifically, game operation data of each user U) between the user terminals 10 of other users U.

[Display Processing Unit 20]
The display processing unit 20 is mainly realized by the processor 11, the storage device 12, and the output device 15, and executes a display process to display data and information received by the terminal-side transmitting/receiving unit 19 on the display by a browsing function. Specifically, the display processing unit 20 draws a game screen when the game starts, and during game play, expands game progress data received by the terminal-side transmitting/receiving unit 19 from the server 30, and displays images and other information on the game screen. During game play, the display processing unit 20 also displays images that change according to game operation data generated by the terminal-side generating unit 18 (specifically, images that move according to the operation of the user U) on the game screen.

<Configuration of Server 30>
Next, the configuration of the server 30 according to the present embodiment will be described.
As shown in FIG. 8, the server 30 has a hardware configuration similar to that of a typical server computer, and includes a processor 31, a storage device 32, and a communication interface (referred to as communication I/F in FIG. 8) 33, and these devices are electrically connected via a bus not shown.

The processor 31 is composed of a CPU, MPU, GPU, DSP, etc., and executes various processes by executing programs installed in the server 30. The programs executed by the processor 31 include an OS, which is system software for controlling the entire server 30, and application programs for causing the server 30 to function as the information processing device of the present invention.

The storage device 32 includes, for example, a memory or storage, and stores various programs and data.
The memory is composed of semiconductor memory such as ROM and RAM, and provides a working area for the processor 31 by temporarily storing programs and data, and temporarily stores data generated by various processes executed by the processor 31.
The storage stores various data related to the user U and games, etc., and is composed of, for example, a flash memory, an HDD, an SSD, an FD, an MO disk, a CD, a DVD, an SD card, a USB memory, etc. Note that a server computer for a database connected to the server 30 via the network N may be used as the storage.

The communication interface 33 is, for example, configured with a network interface card or the like, and controls the communication processing of the server 30. There are no particular limitations on the communication standard used by the communication interface 33, and any public communication standard can be applied without restrictions. In addition, the communication method used by the communication interface 33 may be a wireless method or a wired method.

Next, the configuration of the server 30 will be described again from the functional aspect with reference to Fig. 10. As shown in Fig. 10, the server 30 has a plurality of functional units, specifically, a server-side storage unit 34, a server-side transmission/reception unit 35, a server-side generation unit 36, a control unit 37, an information provision unit 38, and a notification unit 39. These functional units are realized by cooperation between the hardware devices of the server 30 and programs as software stored in the server 30. When the server 30 is configured by a plurality of computers, the above functions may be distributed so that each of the plurality of computers performs a different function.

[Server-side storage unit 34]
The server-side memory unit 34 is mainly realized by the processor 31 and the storage device 32, and stores various data including data regarding the user U and data regarding the game progress processing (game progress data).
The data relating to user U includes an identifier (user ID or terminal ID) that identifies user U or the user terminal 10 used by user U, and various information associated with that identifier (user U's personal information, the model of the user terminal 10, access history, payment history, and game progress such as status, etc.).
The game progression data includes information about characters owned by user U (such as name, attributes, abilities, and level), information about other objects such as items owned by user U, and various information about events set for each user U (such as the time range of an event, the recovery period for a completed event, and the revival status of a completed event).

[Server side transmitting/receiving unit 35]
The server-side transmitting/receiving unit 35 is mainly realized by the processor 31, the storage device 32, and the communication interface 33, and transmits and receives data and information to and from the user terminal 10. For example, during game play, the server-side transmitting/receiving unit 35 transmits game progress data to the user terminal 10 of the user U, and receives game operation data from the user terminal 10. Also, during joint play of the game, the server-side transmitting/receiving unit 35 receives joint play data from each of the user terminals 10 of the multiple users U who are playing jointly, and transmits data for synchronizing the users U (game progress data in a broad sense) to each user terminal 10.

[Server-side generation unit 36]
The server-side generation unit 36 is mainly realized by the processor 31 and the storage device 32, and generates data to be transmitted by the server-side transmission/reception unit 35. The data generated here specifically includes game progress data corresponding to the game operation data received from the user terminal 10, etc. The game progress data also includes event list screen display data for displaying the event list screen 50 on the user terminal 10, reviveable event list screen display data for displaying the reviveable event list screen 51 on the user terminal 10, confirmation screen data for displaying the ended event revival confirmation screen 54 or the ended event overwrite confirmation screen 57 on the user terminal 10, event data for displaying information about a selected event on the user terminal 10 to allow the user U to play the event, joint play start screen data for displaying a joint play start screen notifying that joint play will start on the user terminals 10 of the multiple users U who will play jointly, and data for synchronizing the multiple users U who will play jointly while the joint play is being performed.

[Control unit 37]
The control unit 37 is mainly realized by the processor 31 and the storage device 32, and controls whether or not the user U can play an event based on the relationship between the time range set for each event in the game and the current time. Furthermore, the control unit 37 controls so that even if the event has ended beyond the set time range, the user U performs a predetermined operation such as using an item within a recovery period after the end of the event to satisfy a predetermined condition, thereby reviving the ended event, and allows the user U who performed the predetermined operation to play the revived ended event for a predetermined time. Furthermore, in the case of cooperative play, the control unit 37 controls so that the revived ended event can be played when all of the host and guests participating in the cooperative play, except for the user U whose cooperative play event is within the time range, satisfy a predetermined condition.
The control unit 37 limits the number of times that a finished event can be revived to a predetermined number for each event. The control unit 37 also limits the number of finished events that can be revived and played simultaneously to a predetermined number or less by ending a first event for a predetermined time and making the first event unplayable, and changing the playable finished event from the first event to the second event, or by making the second event unplayable until the first event has ended after a predetermined time has elapsed.

[Information providing unit 38]
The information providing unit 38 is mainly realized by the processor 31, the storage device 32, and the communication interface 33, and cooperates with the server-side transmitting/receiving unit 35 to provide the user terminal 10 with information on reviveable events that can be revived among ended events, which is set for each user U according to the game progress status of the user U, etc. Note that the information on the reviveable events is provided to the user terminal 10 as reviveable event list screen display data.

[Notification unit 39]
The notification unit 39 is mainly realized by the processor 31, the storage device 32, and the communication interface 33, and works in cooperation with the server-side transceiver unit 35 to notify the user terminal 10 of an alert when a specified time set for an event that is revived in response to a specified operation by user U overlaps with the second time range of the event.

In general, the user terminal 10 and the server 30 have various functions other than those described above, but here we will only explain the characteristic functions that provide the desired effect in the game system S of the present invention, and will not illustrate or explain other known functions, etc.

<Processing flow of game system S>
Next, the flow of processing executed in the game system S configured as described above will be described with reference to FIGS.
The information processing method of this embodiment is realized by using a game system S that functions as a computer system; in other words, the information processing method of this embodiment is applied to the information processing performed by the game system S.

The information processing executed in the game system S in this embodiment is broadly composed of two processes: a process [event playability determination process] that determines whether or not an event can be played based on the relationship between the time range set for each event and the current time, and a process [ended event revival process] that revives an ended event whose time range has ended and makes it playable. Each process will be explained individually below.

[Event play availability decision process]
First, the event play availability determination process will be described with reference to FIG.
The "event play availability determination process" is a process executed by the server 30, which determines whether or not the user U can play the event based on the relationship between the time range set for each event and the current time.

As shown in FIG. 11, the server 30 compares the current time with the time range set for the event, and if it determines that the current time is within the time range for the event (S101: YES), it starts the event if it has not yet started, or continues the event if it has already started, thereby setting the event to a playable state for the user U (S102), and adds the event that has been set to a playable state to the event list screen 50 as shown in FIG. 3 (S103).

On the other hand, if the server 30 determines that the current time is not within the time range of the event (S101: NO), it ends the ongoing event, sets the event to an unplayable state for the user U (S104), and deletes the ended event that has been set to an unplayable state from the event list screen 50 (S105). The server 30 then compares the current time with the recovery period of the ended event, and if it determines that the current time is within the recovery period of the ended event (S106: YES), it adds the ended event to the reviveable event list screen 51 as shown in FIG. 4 (S107). Note that if it determines that the current time is not within the recovery period of the ended event (S106: NO), it does not perform the process of S107 and moves to the next process.

Then, the server 30 transmits to the user terminal 10 the event list screen display data for displaying the event list screen 50 and the revivable event list screen display data for displaying the revivable event list screen 51 (S108), and ends the processing.

When the above series of steps is completed, the event play possibility determination process is completed. After that, the above series of steps is repeatedly performed while the user U is playing the game, or as time passes even if the user U is not playing the game.
The above is an example of the event play possibility determination process.

[End event revival process]
Next, the ended event revival process will be described with reference to FIG. 12 and FIG.
The "ended event revival process" is a process executed on the server 30, and refers to a process of reviving an ended event whose time range has ended, making it playable.

As shown in FIG. 12, when the server 30 receives from the user terminal 10 event selection data indicating a terminated event (revivable event) selected by the user U from the reviveable event list screen 51 (S201), the server 30 determines whether the user U satisfies the play conditions (S202).

If the server 30 determines that the user U meets the play conditions (S202: YES), it then compares the predetermined time that would be set if the ended event were revived with the second time range, and if it determines that the predetermined time does not overlap with the second time range (S203: YES) or that the predetermined time overlaps with the second time range (S203: NO), it transmits notification data to display an alert to the user terminal 10 to notify the alert (S204), and if the user U confirms and accepts the alert (S205: YES), it determines whether there are other ended events that have already been revived, i.e., whether the first event is playable (S206). Note that even if there is no second time range for the ended event, it is determined that the predetermined time does not overlap with the second time range (S203: YES).

When the server 30 determines that there is no other ended event that has already been revived (S206: YES), it transmits confirmation screen data to the user terminal 10 to display a ended event revival confirmation screen 54 as shown in FIG. 5, and notifies the user U of the revival confirmation (S207). On the other hand, when the server 30 determines that there is another ended event that has already been revived (S206: NO), it transmits confirmation screen data to the user terminal 10 to display a ended event overwrite confirmation screen 57 as shown in FIG. 6, and notifies the user U of the overwrite confirmation (S208). Then, when the server 30 determines that the user U has accepted the end event by tapping the accept button 55 on the ended event revival confirmation screen 54 or the ended event overwrite confirmation screen 57 (S209: YES), it then compares the current time with the recovery period of the ended event and determines whether the current time is within the recovery period of the ended event (S210).

When the server 30 determines that the current time is within the recovery period of the ended event (S210: YES), it consumes an item possessed by the user U (S211) and revives the selected ended event for the user U, making it playable (S212). The server 30 then deletes the selected ended event that has been set to a playable state from the reviveable event list screen 51, and adds it to the event list screen 50 as shown in FIG. 7 (S213).

Then, the server 30 transmits to the user terminal 10 the event list screen display data for displaying the event list screen 50 and the revivable event list screen display data for displaying the revivable event list screen 51 (S214), and ends the processing.

If the server 30 determines that the user U does not satisfy the play conditions (S202: NO), or that the current time is not within the recovery period of the ended event (S210: NO), it transmits notification data to the user terminal 10 indicating that the ended event cannot be revived, notifies the user U that revival is not possible (S215), and ends the process. If the user U does not accept the alert notification (S205: NO), or if it is determined that the user U has not accepted the notification by tapping the reject button 56 on the ended event revival confirmation screen 54 or the ended event overwrite confirmation screen 57 (S209: NO), the process ends.

In addition, in the end event revival process, if there is another end event that has already been revived, the first event may not be overwritten by the second event, and the second event may not be revived until the first event has ended after a predetermined time has elapsed.

Specifically, as shown in FIG. 13, when the server 30 receives from the user terminal 10 event selection data indicating a terminated event (revivable event) selected by the user U from the reviveable event list screen 51 (S301), the server 30 determines whether the user U satisfies the play conditions (S302).

If the server 30 determines that the user U meets the play conditions (S302: YES), it then compares the predetermined time that would be set if the ended event were revived with the second time range, and if it determines as a result of the comparison that the predetermined time does not overlap with the second time range (S303: YES), or if it determines that the predetermined time overlaps with the second time range (S303: NO), it sends notification data to the user terminal 10 to display an alert and notifies the user (S304). If the user U confirms and accepts the alert (S305: YES), it determines whether there are any other ended events that have already been revived, i.e., whether the first event is playable (S306).

When the server 30 determines that there are no other ended events that have already been revived (S306: YES), it sends confirmation screen data to the user terminal 10 to display a ended event revival confirmation screen 54 as shown in FIG. 5, and notifies the user U of the revival confirmation (S307). Then, when the server 30 determines that the user U has accepted the request by tapping the accept button 55 on the ended event revival confirmation screen 54 or the ended event overwrite confirmation screen 57 (S308: YES), it then compares the current time with the recovery period of the ended event and determines whether the current time is within the recovery period of the ended event (S309).

When the server 30 determines that the current time is within the recovery period of the ended event (S309: YES), it consumes an item possessed by the user U (S310) and revives the selected ended event for the user U, making it playable (S311). The server 30 then deletes the selected ended event that has been set to a playable state from the reviveable event list screen 51, and adds it to the event list screen 50 as shown in FIG. 7 (S312).

Then, the server 30 transmits to the user terminal 10 the event list screen display data for displaying the event list screen 50 and the revivable event list screen display data for displaying the revivable event list screen 51 (S313), and ends the processing.

If the server 30 determines that the user U does not satisfy the play conditions (S302: NO), if it determines that there is another ended event that has already been revived (S306: NO), or if it determines that the current time is not within the recovery period of the ended event (S309: NO), it sends notification data to the user terminal 10 indicating that the ended event cannot be revived, notifies the user U that revival is not possible (S314), and ends the process. If the user U does not accept the alert notification (S305: NO), or if it determines that the user U has not accepted the end event revival confirmation screen 54 by tapping the reject button 56, etc. (S308: NO), the process ends.

The ended event revival process ends when the series of steps shown in Fig. 12 or 13 above is completed. Thereafter, while the user U is playing the game, strictly speaking, when the user U selects an ended event (revivable event) from the reviveable event list screen 51, the series of steps described above is repeatedly performed.
The above is an example of the ended event revival process.

[End event revival processing in cooperative play]
Next, the ended event revival process, particularly the ended event revival process in cooperative play, will be described with reference to FIG.
"Ended event revival processing in collaborative play" refers to processing executed on the server 30, which revives an ended event whose time range has ended and makes it playable for both the host and guest when the host recruits friends to join in collaborative play for an ended event that the host revived via the ended event revival processing shown in Figure 12 or Figure 13 above.

As shown in FIG. 14, the server 30 first transmits a joint play invitation list that includes the ended event that the host has revived to other users U who may become guests (S401). Then, when the server 30 accepts an application from a guest to participate in a joint play of the revived ended event from the invitation list (S402), the server 30 determines whether the event in question is also an ended event that the guest has revived (S403).

When the server 30 determines that the guest has also revived the end event (S403: YES), it then compares the current time with the predetermined time of the end event revived by the host and determines whether the current time is within the predetermined time of the end event revived by the host (S404). When the server 30 determines that the current time is within the predetermined time of the end event revived by the host (S404: YES), it sets the guest to a state in which joint play of the revived end event is possible (S405), transmits joint play start screen data to the guest's user terminal 10 to display a joint play start screen notifying the guest that joint play will begin for the revived end event (S406), and ends the process.

On the other hand, if the server 30 determines that the event is not a revived ended event for the guest (S403: NO), or that the current time is not within the specified time period of the ended event revived by the host (S404: NO), it sends notification data to the guest's user terminal 10 indicating that the guest cannot participate in cooperative play, notifying the guest that he or she cannot participate in cooperative play (S407), and ends the process.

When the above series of steps is completed, the ended event revival process in the cooperative play is completed. Thereafter, while the user U is playing the game, or more precisely, when the host user U recruits friends to participate in the cooperative play for the revived ended event, the above series of steps is repeatedly performed.
The above is an example of the process of reviving an ended event in cooperative play.

<Other embodiments>
The present invention is not limited to the above-described embodiments.
In the above embodiment, the server 30 executes the program of the present invention and functions as the information processing device of the present invention, but some or all of the functions of the server 30 as an information processing device may be provided in the user terminal 10. For example, the user terminal 10 may be provided with a function equivalent to the control unit 37, etc.

In the present embodiment, an online game that utilizes data communication between the user terminal 10 operated by the user U and the server 30 has been described as an example of a game. However, the type of game is not particularly limited, and the game may be an offline game that does not require data communication. Also, for example, the game may be a social game that can be used with only a web browser and a SNS (Social Networking Service) account.

<Summary>
The main features of the information processing device, information processing method, and program according to the above-described embodiment are as follows.

[1] The information processing device according to this embodiment has a control unit that controls whether or not an event can be played based on the relationship between a time range set for an in-game event and the current time, and when a predetermined condition is satisfied in response to a predetermined operation by the user after the time range ends, the control unit enables the user who performed the predetermined operation to play the event for a predetermined time.
According to the information processing device, even if the time period set for an event has ended and the opportunity to play the event has been lost, the user can still play the event for a predetermined period of time by performing a predetermined operation to satisfy a predetermined condition, thereby improving the user's level of satisfaction with the game.

[2] In the above-mentioned information processing device, after the time range ends, if the number of times that the control unit has allowed the user to play an event in response to the user's specified operation has reached a specified number, the control unit will not allow the user to play the event in response to the user's specified operation.
This prevents the user from playing an event whose time range has ended indefinitely, even if the user performs a specified operation and fulfills a specified condition, thereby further improving the user's game satisfaction while maintaining game balance.

[3] In the above information processing device, the control unit limits the number of events that can be played simultaneously to a predetermined number or less after the time range ends.
As a result, even if a user performs a specified operation to satisfy a specified condition for an event whose time range has ended, the number of times that the user can play simultaneously is limited to a specified number or less, thereby further improving the user's game satisfaction while maintaining game balance.

[4] In the above-mentioned information processing device, the control unit makes the first event unplayable when, after the time ranges of the first event and the second event have ended, the second event is playable in response to a specified user operation while the first event is playable in response to a specified user operation.
As a result, even if a user performs a specified operation to satisfy a specified condition after the time ranges of the first event and the second event have ended, the user cannot play the first event and the second event simultaneously, thereby further improving the user's game satisfaction while maintaining game balance.

[5] In the above-mentioned information processing device, after the time ranges of the first event and the second event have ended, the control unit does not enable play of the second event in response to a specified operation by the user until the first event, which has become playable in response to a specified operation by the user, has ended after a specified time has elapsed.
As a result, even if a user performs a specified operation to satisfy a specified condition after the time ranges of the first event and the second event have ended, the user cannot play the first event and the second event simultaneously, thereby further improving the user's game satisfaction while maintaining game balance.

[6] In the above-mentioned information processing device, the information providing unit further provides the user with information regarding events that can be played in response to a specified operation by the user, among the events whose time range has ended, and the control unit enables the play of the event selected by the user based on the information.
This makes it easier for the user to select an event to play from among events whose time ranges have ended, further improving the user's level of satisfaction with the game.

[7] In the above-mentioned information processing device, a first time range and a second time range are defined for the event, the second time range is after the first time range, and the information processing device further has a notification unit that notifies an alert when a playable time range of an event that becomes playable in response to a specified user operation between the first time range and the second time range overlaps with the second time range.
This notifies the user that for an event for which the first time range has ended, it will be possible to play the event in the second time range even if the user does not perform a predetermined operation to satisfy a predetermined condition. This makes it easier for the user to select an event to play from among the events for which the time range (first time range) has ended, and also allows the user to reconsider whether or not to perform a predetermined operation for the event, thereby further improving the user's level of satisfaction with the game.

[8] In the above-mentioned information processing device, when a user recruits co-players to play a game together with the user and other users join the game as co-players to play together, the control unit enables the user and the other users to play the event after the time range ends if both the user and the other users satisfy predetermined conditions.
As a result, in cooperative play by multiple users, in order to play an event whose time range has ended, all users participating in the cooperative play must perform specified operations and satisfy specified conditions, thereby further improving users' game satisfaction while maintaining game balance.

[9] Furthermore, according to the information processing method of this embodiment, the computer controls whether or not an event can be played based on the relationship between a time range set for an in-game event and the current time, and after the time range ends, if a predetermined condition is satisfied in response to a predetermined operation by the user, the computer enables the user who performed the predetermined operation to play the event for a predetermined period of time.
According to the above information processing method, even if the time period set for an event has ended and the opportunity to play the event has been lost, the user can still play the event for a predetermined period of time by performing a predetermined operation to satisfy a predetermined condition, thereby improving the user's level of satisfaction with the game.

[10] Furthermore, according to the program of this embodiment, the program is executed by a computer, and causes the computer to control whether or not an event can be played based on the relationship between a time range set for an event in a game and the current time, and after the time range ends, if a predetermined condition is satisfied in response to a predetermined operation by the user, allows the user who performed the predetermined operation to play the event for a predetermined time.
According to the above program, even if the user misses an opportunity to play an event because the time period set for the event has ended, the user can still play the event for a predetermined period of time by performing a predetermined operation to satisfy a predetermined condition, thereby improving the user's level of satisfaction with the game.

10 User terminal 11 Processor 12 Storage device 13 Communication interface 14 Input device 15 Output device 16 Operation identification unit 17 Terminal side memory unit 18 Terminal side generation unit 19 Terminal side transmission/reception unit 20 Display processing unit 30 Server 31 Processor 32 Storage device 33 Communication interface 34 Server side memory unit 35 Server side transmission/reception unit 36 Server side generation unit 37 Control unit 38 Information provision unit 39 Notification unit 50 Event list screen 51 Reviveable event list screen 52 Guidance button 53 Sort button 54 Ended event revival confirmation screen 55 Accept button 56 Reject button 57 Ended event overwrite confirmation screen N Network S Game system U User

Claims (1)

a control unit that controls whether or not an event can be played in a game based on a relationship between a time range defined for the event and a current time;
The control unit is
After the time range ends, when a predetermined condition is satisfied in response to a predetermined operation by a user, the user who performed the predetermined operation is allowed to play the event for a predetermined period of time.
23. An information processing apparatus comprising:

Images