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

Abstract

PROBLEM TO BE SOLVED: To provide an information processing device, a program, and an information processing method that can suppress adverse effect of uniformity in privilege provision.

SOLUTION: According to the present invention, an information processing device includes a first imparting unit and a second imparting unit. The first imparting unit performs a first selection of an object to be imparted to a user. The second imparting unit performs a second selection of selecting a mode from a plurality of different modes, and performs a third selection of selecting an object to be imparted to the user in the mode selected in the second selection, to the user who satisfies a predetermined condition in the execution of the first selection.

SELECTED DRAWING: Figure 10

COPYRIGHT: (C)2023,JPO&INPIT

Description

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

Japanese Patent Laid-Open No. 2002-200001 discloses a technique of giving a predetermined privilege when a predetermined object is not awarded even after a predetermined number of lotteries are held.

Patent No. 6431877

In Patent Literature 1, when certain conditions are satisfied, a privilege is given only by a certain method, and the privilege provision to the user tends to be uniform. Due to this, problems such as a decrease in user satisfaction may occur.

SUMMARY OF THE INVENTION The present invention provides an information processing device, a program, and an information processing method capable of suppressing the harmful effects of uniformity in privilege provision.

An information processing apparatus according to an aspect of the present invention is an information processing apparatus including a first imparting unit and a second imparting unit, wherein the first imparting unit performs a first selection of an object to be imparted to a user. and the second providing unit performs a second selection of selecting a mode from among a plurality of different modes for the user who satisfies a predetermined condition in the execution of the first selection, and performs the second selection. The information processing apparatus performs a third selection of selecting an object to be given to the user in the mode selected by selection.

The second provision unit provides the user with a privilege (that is, a special object acquisition opportunity) when a predetermined condition is satisfied. According to one aspect of the present invention, a mode is selected by the second selection from a plurality of types of modes, and a third selection of selecting an object is performed in each mode. This makes it possible to provide the user with an opportunity to receive objects in different modes. Therefore, special object acquisition opportunities can be varied.

1 is a diagram showing an overview of an information processing device 1 according to an embodiment; FIG. 2 is a block diagram showing the hardware configuration of the information processing device 1; FIG. 3 is a block diagram showing the hardware configuration of the user terminal 3; FIG. 2 is a block diagram showing the functional configuration of the information processing device 1; FIG. 2 is a block diagram showing a specific example of the functional configuration of the information processing device 1; FIG. FIG. 6A is a diagram showing an example of each of the object table (character table) T1, user table T2, and object population table T3, and FIG. 6B is a diagram showing an example of population setting tables T4-1 to T4-9. FIG. 6C is a diagram illustrating variations of the population setting table, both of which are tables stored in the object storage unit 23. FIG. FIG. 7A is a diagram showing an example of a play history table (object provision result table) T5a, and FIG. 7B is an example of a play history table (number of executions of first selection) T5b1 and a play history table (number of mode selections) T5b2. FIG. 7C is a diagram showing an example of a play history table (quest history) T5c, both of which are tables stored by the play history storage unit 24. FIG. FIG. 8A shows an example of a mode selection probability table T6-1 corresponding to the number of first mode selections, and FIG. 8B shows an example of a mode selection probability table T6-2 corresponding to the number of executions of the first selection. FIG. 8C is a diagram showing an example of a mode selection probability table T6-3 corresponding to quest history, both of which are tables stored in the probability data storage unit 25. FIG. 4 is a sequence diagram for explaining the flow of object assignment according to the embodiment; FIG. FIG. 10 is a sequence diagram for explaining the flow of second selection and third selection according to the embodiment; FIG. 14 is a sequence diagram for explaining a third selection flow (object population table selection in the second mode) according to the modification; FIG. 11 is a sequence diagram for explaining the flow of object assignment (counting of the number of executions for each type of first selection) according to a modification; FIG. 11 is a diagram showing an example of a mode selection probability table (execution count for each type of first selection) according to a modification; FIG. 12 is a diagram showing an example of a mode selection probability table (mode probability control according to the number of times of giving a predetermined object) according to a modification; FIG. 13 is a sequence diagram for explaining the flow of object provision (presentation of designation candidates for user operation according to the type of first selection) according to another modification; FIG. 13 is a sequence diagram for explaining a third selection flow (presentation of designation candidates of user operation according to the type of first selection) according to another modification; It is an example of a table in which population IDs are associated in advance with first selection types (first type to n-th type). FIG. 14 is a sequence diagram for explaining a third selection flow (object provision according to past provision frequency) according to another modification; It is an example of an object provision result table to which an acquisition path column is added. FIG. 21 is a sequence diagram for explaining a third selection flow (both modes 1 and 2 are lotteries, but the content is different) according to another modification; 3 is a block diagram showing another specific example of the functional configuration of the information processing device 1; FIG.

Several embodiments of the present invention will be described below with reference to the drawings. Various features shown in the embodiments shown below can be combined with each other. In addition, the invention is established independently for each characteristic item.

<1. embodiment>
(1.1. Outline of information processing device 1)
An overview of an information processing apparatus 1 according to an embodiment will be described with reference to FIG. As shown in FIG. 1, the information processing device 1 is implemented by one or more servers (computers). The information processing device 1 is configured to be communicable with a user terminal 3 by being connected to a WAN (Wide Area Network) 2 such as the Internet.

The user terminal 3 is implemented by a mobile terminal (computer) such as a smart phone owned by a game user (hereinafter simply referred to as a user). The information processing apparatus 1 receives a request for providing an object (hereinafter simply referred to as a provision request) from a user via the user terminal 3 . Here, "object" is a general term for electronic data used by the user for the progress of the game. Objects may specifically include characters, items, cards, or avatars, for example. In the following embodiments, an example in which a character is provided as an object will be described.

When the information processing apparatus 1 receives an object provision request from a user, the information processing apparatus 1 selects one or a plurality of objects from among the objects that can be provided and provides the selected object to the user. Note that the information processing apparatus 1 may be configured so as not to provide more than a predetermined number of objects that can be provided to the user. This may allow the user to predict the cost required to obtain the desired object.

(1.2. Hardware configuration of information processing device 1)
A hardware configuration of the information processing apparatus 1 will be described with reference to FIG.

FIG. 2 is a block diagram showing the hardware configuration of the information processing device 1 according to this embodiment. The information processing device 1 includes a control section 11 and a storage section 12 . The control unit 11 controls the operation of the information processing apparatus 1 as a whole. The storage unit 12 functions as a work area when various programs are executed by the control unit 11 . Various programs and various data are stored in advance in the storage unit 12 .

Further, the information processing apparatus 1 includes a communication unit 13 that is connected to the user terminal 3 via a communication line and performs transmission and reception of various data. Further, an operation input unit 14 configured by a keyboard, a mouse, etc., for receiving input of various operations, and a monitor 15 such as a liquid crystal display device for displaying various images may be provided.

The control unit 11 , storage unit 12 , communication unit 13 , operation input unit 14 and monitor 15 are electrically connected to each other via a system bus 16 . Therefore, the control unit 11 accesses the storage unit 12, grasps the operation state of the operation input unit 14, displays images on the monitor 15, and communicates with other information processing devices such as the user terminal 3 via the communication unit 13. can transmit and receive various data.

(1.3. Hardware Configuration of User Terminal 3)
The hardware configuration of the user terminal 3 will be described with reference to FIG. The user terminal 3 includes, for example, a control unit 221 including a processor or the like, a storage unit 222 including a nonvolatile memory or the like, a communication unit 223 for performing wireless communication and/or wired communication, a display unit 224, a speaker 225 , a microphone 226 , a camera 227 and operation buttons 228 . The specific configuration of the user terminal 3 is not limited, and may be various mobile terminals, smart phones, tablet terminals, notebook PCs, and the like. When the user terminal 3 has a touch panel display, the display section 224 and the operation buttons 228 may be integrated with the touch panel display. The operation button 228 and the microphone 226 serve as an input interface (or input means) for the user to perform various input operations on the user terminal 3 .

(1.4. Functional Configuration of Information Processing Apparatus 1)
A functional configuration of the information processing apparatus 1 will be described with reference to FIG.

As shown in FIG. 4, the information processing device 1 includes a first imparting section 22a and a second imparting section 22b. The first imparting unit 22 a and the second imparting unit 22 b are implemented as functions of the control unit 11 . The first granting unit 22a makes a first selection of an object to be granted to the user. There are various variations in the specific object selection method in the "first selection". The “first selection” may be, for example, that the first granting unit 22a selects an object by lottery, that the first granting unit 22a selects an object according to user operation designation, or that the first granting unit 22a selects an object other than the lottery. Objects may be selected according to a predetermined rule. In the embodiment, as an example, it is assumed that the first selection is a lottery.

The second granting unit 22b performs a second selection and a third selection. "Second selection" is for the second providing unit 22b to select a mode from a plurality of different modes for the user who satisfies a predetermined condition in the execution of the first selection.

A "predetermined condition" is any condition that can be variously determined depending on the performance of the first selection. An example of a predetermined condition is that when the number of executions of the first selection by the same user reaches a predetermined number of times (for example, 10 times), it is determined that the predetermined condition is satisfied for that user, and the execution counter is set to 0 times. It may be returned. The number of executions referred to here may be, for example, the total number of executions. The total number of executions may be the total number of executions within a predetermined period. As another example of the predetermined condition, it may be determined that the user has satisfied the predetermined condition when the number of acquisitions of a predetermined predetermined object reaches a predetermined number. Another example of the predetermined condition is when the number of types of duplicated objects, the number of duplicates of one object, etc. reaches a predetermined threshold when there are duplicated objects in the currently owned objects. Alternatively, it may be determined that the user satisfies a predetermined condition.

"A plurality of different modes" can preset any number of mutually different modes. In the embodiment, as an example, two modes (first mode and second mode) are set in advance.

In the "third selection", the second granting unit 22b selects an object to be granted to the user in the mode selected in the second selection. There are various variations in the specific object selection method in the "third selection". The "third selection" may be, for example, the object selected by the second granting unit 22b by lottery, or may be selected by the second granting unit 22b according to user operation designation. Objects may be selected according to other predetermined rules. The third selection may be a selection method different from the first selection, or may be the same selection method.

FIG. 5 shows a concrete example of the functional configuration of the information processing apparatus 1 . FIG. 5 exemplifies the peripheral functional units together with the first imparting unit 22a and the second imparting unit 22b. In the example of FIG. 5, the information processing apparatus 1 includes a game providing unit 20, a game information storage unit 20a, a provision request receiving unit 21, an object providing unit 22, an object storage unit 23, and a play history storage unit 24. , a probability data storage unit 25 and an operation reception unit 26 . The object imparting section 22 includes the first imparting section 22a and the second imparting section 22b described with reference to FIG.

The game providing unit 20 provides a game to the user by communicating with the user terminal 3 using information such as a program read from the game information storage unit 20a. A user's play history is stored in the play history storage unit 24 via the game providing unit 20 . The specific content of the game provided by the game providing unit 20 is not limited. The game provided by the game providing unit 20 may be, for example, a role-playing game, an action game, a shooting game, a puzzle game, a racing game, a table game, a simulation game, or a music game. It may be a game or the like. The details of the game to be provided may also be set in various ways. For example, in the case of a simulation game, the subject may be sports as an example, or training or management as another example. Alternatively, the game may be a game that combines two or more of the game systems listed here. The play history also includes a history of clearing one or more "quests" set in the game.

The game providing unit 20 , the provision request accepting unit 21 , the object providing unit 22 , and the operation accepting unit 26 are implemented as functions of the control unit 11 . The game information storage unit 20 a , the object storage unit 23 , the play history storage unit 24 and the probability data storage unit 25 are realized as functions of the storage unit 12 . Specific operations of each functional unit will be described later.

The functional configuration described above may be implemented by a CPU (Central Processing Unit) implemented as the control unit 11 executing a program to implement various functions, or may be implemented by hardware.

When implemented by executing a program, the program may be stored in the storage unit 12 or may be stored in a non-temporary computer-readable recording medium. Alternatively, a program stored in an external storage device may be read out and realized by so-called cloud computing. Further, when implemented by hardware, it may be implemented by various circuits such as ASIC, SOC, FPGA, or DRP.

(1.5. Table configuration)
Tables stored in the object storage unit 23, the play history storage unit 24, and the probability data storage unit 25 will be described with reference to FIGS. 6A to 6C, 7A to 7C, and 8A to 8C.

Each table in FIGS. 6A to 6C is stored in the object storage unit 23. FIG.

An object table (character table) T1 in FIG. 6A stores information about characters provided as game elements. The object table T1 has a character ID column and a name column. The character ID column holds character IDs for uniquely identifying characters. The name column holds the name of each character.

The user table T2 in FIG. 6A stores information about users who use the game. The user table T2 has a user ID column and a name column. The user ID column holds user IDs for uniquely identifying users. The name column holds the name of each user.

The object population table T3 in FIG. 6A stores object populations. The object population table T3 has a population ID column and a name column. An "object population" is a collection of objects. An object population contains one or more objects. The population ID column holds population IDs for uniquely identifying object populations. The name column holds the name of each object population.

Population setting tables T4-1 to T4-9 in FIG. 6B are tables for setting objects included in each object population. The population setting table T4 has a No column and a character ID column. The No column holds serial numbers for uniquely identifying records in the table. The character ID column holds character IDs of characters included in the object population corresponding to the table.

In the embodiment, as an example, the object population table also includes a winning probability sequence for each character at the time of lottery. In other words, the population setting tables T4-1 to T4-9 also function as an "object winning probability table".

In the embodiment, as shown in FIG. 6B, population setting tables T4-1, T4-2, . . . , T4-9 are set for each object population B01, B02, . In each table, the characters included in each object population (and winning probability at lottery) are defined. However, FIG. 6B is just an example, and the number of object populations is not limited, and more object populations can be arbitrarily set.

A variation of the population setting table is illustrated with reference to FIG. 6C. Population setting tables T4-1a, T4-1b, and T4-1c in FIG. 6C respectively define object populations B01a, B01b, and B01c that are partially different from the population setting table T4-1 in FIG. 6B. The differences are differences D1, D2 and D3. The difference D1 is the record number. 050 characters are different between C120 and C150. In this way, a plurality of object population tables may be provided in which some (one or more) characters are different and other characters are common. The difference D2 is the record number. The 050 characters are the same, but the odds of winning are different between 1% and 30%. In this way, the odds of winning may differ for some (one or more) characters in a plurality of object population tables. The difference D3 is that all characters have different winning probabilities. 050 character C120 is given a winning probability of 100%. This means that character C120 always wins the lottery in the population setting table T4-1c. In this way, an object population table may be provided in which some (one or more) characters have high probabilities. The probability is not limited to 100%, and any high probability such as 99% to 90% may be used. Alternatively, 100% probability may be assigned to some characters in the table. For example, it may be distributed to two characters in a ratio of 50%:50% or 30%:70%. It should be noted that each variation illustrated in FIG. 6C may be similarly added to each of the other population setting tables T4-2 to T4-9.

Each table in FIGS. 7A to 7C is stored in the play history storage unit 24. FIG. The play history storage unit 24 accumulates the play history of each user as the game progresses.

Here, the “play history” is history accumulated by the user playing the game provided by the game providing unit 20 . The play history may include various histories according to the progress of the game. To give an example, the play history may specifically include, for example, past object provision results, for example, may include past first selection results, and may include, for example, past second selection results. Alternatively, it may include, for example, "whether or not a specific stage, quest, or event has been played in the past or present, and the number of times it has been played."

A play history table (object provision result table) T5a in FIG. 7A is a table that stores information for specifying an object provided to the user for each user. The play history table T5a includes a No column for uniquely identifying records in the table, a user ID column, a population ID column, and a character ID column. The user ID column holds the user ID of the user who requested the provision of the object. The population ID column holds population IDs of object populations containing characters provided to the user in response to the provision request. The character ID column holds the character ID of the character provided to the user in response to the provision request. In the play history table T5a, each time an object is provided to the user, information about the provided character and the object population including the character is registered.

Note that the play history table T5a may be added with object provision histories in paths other than the object granting of the embodiment (for example, rewards for quests, rewards for limited-time events, and the like). Alternatively, in addition to the play history table T5a, an "other play history table" may be provided, and this other play history table may include paths other than the object grant of the embodiment (for example, quest rewards and limited time Objects provided to the user as rewards for events, etc.) may be stored. This "other play history table" may be added to the play history table T5a.

The play history table (the number of executions of the first selection) T5b1 in FIG. 7B is a table that accumulates the number of executions of the first selection executed for each user. The play history table T5b1 includes a No column for uniquely identifying records in the table, a user ID column, and a first selection execution count column. When each user sends an object provision request from the user terminal 3 to the provision request reception unit 21, the first provision unit 22a executes the first selection. With each execution, the number of executions of the first selection is incremented for each user. Note that the number of executions of the play history table T5b1 may be reset or decremented according to predetermined timing or establishment of a predetermined condition. For example, it may be reset or the like every predetermined constant period.

The play history table (mode selection count) T5b2 in FIG. 7B is a table that accumulates the execution results of the second selection (that is, mode selection results) executed for each user. In the embodiment, as an example, "the number of times the first mode was selected in the second selection" is accumulated. The play history table T5b2 includes a No column for uniquely identifying records in the table, a user ID column, and a first mode selection count column. When a predetermined condition is satisfied at a certain point in time when the first granting unit 22a executes the first selection for each user, the second granting unit 22b performs the second selection (and 3rd choice). Either the first mode or the second mode is selected each time the second selection is performed. Each time the first mode is selected for each user, the numerical value of the play history table T5b2 is incremented. This number of first mode selections may be reset or decremented when the second mode is selected. A specific example will be described later with reference to FIG.

The play history table (quest history) T5c in FIG. 7C is a table that stores the quest achievement degree of each user. The play history table T5c includes a No column for uniquely identifying records in the table, a user ID column, and a clear count column for each quest Q001 to Q009. Each user plays and clears the quests Q001 to Q009 in the game provided by the game providing unit 20. FIG. The play history table T5c is updated according to the number of clears.

Each table in FIGS. 8A to 8C is stored in the probability data storage unit 25. FIG.

Mode selection probability tables T6-1 to T6-3 in FIGS. 8A to 8C are for controlling the probability of the second mode being selected in the second selection (hereinafter also referred to as "selection probability"). As shown in FIGS. 8A to 8C, the selection probability weight of the second mode is the value of the first mode selection number counter cnt_m, the first selection execution number counter cnt_i, and the quest history counter cnt_q. It is determined step by step based on each value. Each table can be used to control the selection probability of the second mode. Since either the first or second mode is selected in the embodiment, the first mode selection probability is a value obtained by subtracting the second mode selection probability from 100%.

Various methods can be set for converting the quest history counter cnt_q of each user from the play history table T5c of FIG. 7C. As an example, the counter cnt_q may be the number of clears of a specific quest (for example, only Q009). As another example, the counter cnt_q may be a statistic about the number of times multiple quests have been cleared. The statistical value may be, for example, the total value, average value, maximum value, minimum value, or the like of the number of clears.

Although various tables have been exhaustively described as an example in the embodiment, the embodiment does not require all of these tables. At least, a necessary table should be provided for each sequence to be described later.

(1.6. Flow of Object Assignment)
The flow of object assignment according to the embodiment will be described with reference to FIGS. 9 and 10. FIG. In some figures, the functional block configuration of FIG. 5 (the operation reception unit 26 includes the object storage unit 23, the play history A storage unit 24 and a probability data storage unit 25) may be illustrated next to the processing steps. However, this is for the sake of convenience, and data can be exchanged with the functional block configuration of FIG. 5 as required even in such processing steps not shown.

FIG. 9 illustrates an overview of the flow of object assignment according to the embodiment. First, the user operates the user terminal 3 to request the information processing apparatus 1 to provide an object (see FIG. 1). Here, as an example, it is assumed that the provision request is a request to execute a lottery. This lottery may be accompanied by charging, but may be one without charging. For the sake of convenience, the case where the user who made the provision request is "user U01" will be described as an example.

In step S110, the provision request receiving unit 21 receives the provision request. The first granting unit 22a confirms the provision request (step S120) and executes the first selection (step S130). As an example, it is assumed that an object is selected by lottery in the first selection. In this case, in the provision request confirmation in step S120, the first granting unit 22a refers to the user table T2 and determines the user U01. Further, the first granting unit 22a selects an object population corresponding to the current provision request from the populations B01 to B09 of the object population table T3. The first provision unit 22a performs a lottery by applying the winning probability of the population setting table corresponding to the selected object population. The object won in this lottery is the object to be given to the user U01 as a result of the first selection this time.

Further, the first provision unit 22a performs result registration in step S140. By registering the result, the winning object can be given to the user U01. Specifically, in the result registration, the play history table T5a of FIG. 7A is updated and a new record number is registered. is added, and the character ID of the winning object is registered together with the user ID (U01 in this example). As a result, in the user terminal 3 of the user U01, the winning object is treated as an object owned by the user U01. In addition, the first granting unit 22a adds 1 to the number of executions of the first selection by the user U01 in the play history table T5b1 of FIG. 7B.

Next, the processing is transferred to the second imparting unit 22b. In step S160, the second granting unit 22b determines whether or not a predetermined condition is satisfied for the user U01. As an example of the predetermined condition, it is determined that the user U01 has satisfied the predetermined condition when the number of executions of the first selection by the user U01 reaches a predetermined number (for example, 10 times). This determination can be made by referring to the record of the user U01 in the play history table T5b1 of the play history storage unit 24 and by comparing the value of the execution count with a predetermined value (eg, 10). If the predetermined condition is not satisfied, the current process is terminated (returned).

When it is determined in step S160 that the predetermined condition is satisfied, the second providing unit 22b performs the second selection (step S170) and the subsequent third selection (step S180). From now on, description will be made with reference to FIG.

In the second selection in step S170, play history is acquired first (step S171). The play history acquired here is the result of the second selection in the past, and specifically, the play history table (the number of executions of the first selection) T5b1 in FIG. 7B is referred to. In the example of FIG. 7B, the user U01 has selected the first mode (cnt_m) three times.

Next, in step S172, the second adding unit 22b performs mode selection processing. Specifically, the second adding unit 22b accesses the mode selection probability table T6-1 (see FIG. 8A) of the probability data storage unit 25 and reads the selection probability weight=50% corresponding to cnt_m=3. As a result, the selection probability of the second mode is set to 50% (that is, the remaining 50% is the selection probability of the first mode), and the two-choice lottery process is executed. Note that cnt_m is "the number of times one mode (first mode) is selected in the second selection from a plurality of modes", and the selection probability weight is "the number of times that another mode (second mode) is selected from a plurality of modes". is the probability of being selected”.

In step S173, the process branches according to the mode selection result in step S172. If the second mode is not selected (that is, if the first mode is selected), the process proceeds to step S174, and 1 is added to the counter value cnt_m of the number of first mode selections. In the case of user U01 this time, the number is updated from 3 to 4. On the other hand, if the second mode is selected, the process proceeds to step S175, and the counter value cnt_m of the number of times the first mode is selected is reset to zero. As a modification, instead of resetting, a process of reducing the winning probability of the mode selection probability table T6 by a predetermined value (for example, minus 1 time, minus 2 times, etc.) may be performed.

A third selection is made depending on the mode selected in the second selection. Each is described below.

If the second selection selects the first mode, processing proceeds from step S170 to step S180a. Step S180a is processing for the third selection in the first mode. In the embodiment, as an example, the first mode is a mode in which an object to be given to the user U01 is selected by lottery (step S181a). In embodiments, the lottery of step S181a in this first mode may differ in several respects from the first selection lottery (step S130). As an example of difference, the object population to which the lottery is applied may be different. To give a preferred example, characters C001 to C120 included in the object population B01 in FIG. 6B are objects that are given relatively frequently in the game provided by the game providing unit 20 (that is, low rarity value objects). and On the other hand, for example, characters C910 to C990 included in the object population B09 in FIG. 6B are objects with relatively low frequency of addition (that is, high rarity value objects) in the game provided by the game providing unit 20. FIG. In this case, the population setting table T4-1 of FIG. 6B is used in the first selection lottery (step S130), and the population setting table T4-9 of FIG. 6B is used in the first mode lottery (step S181a). may be When an object is won by lottery, the object to be given to user U01 is determined in step S182a.

On the other hand, if the second selection selects the second mode, the process proceeds from step S170 to step S180b. Step S180b is processing for the third selection in the second mode. In the embodiment, as an example, the second mode is a mode in which a user's operation from the user terminal 3 is received and an object is selected (specified) by the user himself/herself.

First, in step S181b, the second assigning unit 22b transmits to the user terminal 3 character IDs of a plurality of candidate objects to be displayed as selection candidates for the user. When the user terminal 3 receives the character ID of the candidate object, the user terminal 3 displays the object presentation screen 28 on the display section 224 . A template image for the object presentation screen 28 may be stored in the user terminal 3 in advance. As an example, three candidate objects may be displayed on the object presentation screen 28, and one of these candidate objects can be selected as an example. An arbitrary number (a plurality of objects may be selected) smaller than the number of presented candidate objects may be selected. Note that there are several variations of the method of selecting the predetermined number of objects presented here. For example, it may be a fixed specific object, for example, it may be an object selected based on the play history, for example, a presentation table may be provided in which objects to be presented are set, for example, according to a predetermined presentation selection rule. Extraction may be performed from any population-setting table.

In the embodiment, as an example, when the object display area of each candidate object is tapped on the object presentation screen 28, the candidate object in the display area is specified. When such an operation is performed on the user terminal 3, the user operation is input to the second imparting unit 22b via the operation accepting unit 26 (step S182b). The object specified by the user U01 in step S182b is determined as the object to be given to the user U01 (step S183b).

After that, the second granting unit 22b executes result registration in step S190 in the same way as the first granting unit 22a did in step S140. By this result registration, the object selected by the third selection can be given to the user U01. Specifically, the play history table T5a of FIG. 7A is updated, and new record numbers are added. is added, and the character ID of the object determined in steps S182a and S182b is registered together with the user ID (U01 in this example). As a result, the object selected by the third selection is handled as the owned object of user U01 in user terminal 3 of user U01.

In the sequence example of FIG. 10, in steps S171 and S172, the mode selection probability table T6-1 corresponding to the number of first mode selections (counter value cnt_m) is used. However, it is not limited to this. As another example, a first selection execution count counter cnt_i may be set, and based on this, the probability of selecting the second mode may be determined from the mode selection probability table T6-2 (see FIG. 8B). As still another example, a quest history counter cnt_q may be set, and based on this, the probability of the second mode being selected from the mode selection probability table T6-3 (see FIG. 8C) may be determined.

<2. Variation>
The above embodiment is an example, and various modifications, additions, or omissions can be made. Various modifications will be described below with reference to FIGS. 11 to 21 as well. These modifications may be used in any combination as long as they do not interfere with each other's application.

(2.1. First modification)
In the first modified example illustrated in FIG. 11, in the third selection (second mode) of step S180b, there is provided a process of allowing the user to designate an object population table. First, in step S184b, a population is presented. Specifically, the population setting tables T4-1 to T4-9 are presented to the user as selection candidates.

Population presentation in step S184b may be realized by the following processing as an example. First, the second providing unit 22b transmits to the user terminal 3 presentation table specifying information for specifying a table to be presented this time among the population setting tables T4-1 to T4-9. The user terminal 3 that has received the presentation table specifying information displays the information of the population setting table indicated by the presentation table specifying information on the display unit 224 . As an example, the name of each object population (see object population table T3) may be presented on the display section 224. FIG. As another example, any icon associated with the population ID may be presented as a selection candidate on the display unit 224 .

After presenting the population, the operation accepting unit 26 accepts user operations from the user terminal 3 . Here, as an example, it is assumed that there is a user operation to select the object population B05. The second granting unit 22b determines the object population B05 as the selection source object population for the current third selection based on the user operation (step S185b).

Next, in step S186b, the second granting unit 22b selects objects to be granted to the user from the object population selected in step S185b. In step S186b of FIG. 11, as an example, the second granting unit 22b selects an object by lottery. Specifically, the second granting unit 22b reads the population setting table T4-5 corresponding to the object population B05 from the object storage unit 23, and draws objects in the table. An object to be given to the user U01 is selected based on the lottery result (step S183b).

On the other hand, the first mode (step S180a) is the same as the example of FIG. In this first mode, a lottery is performed from among the object population that is determined without user operation (step S181a), and an object to be given to user U01 is determined (step S182a).

Note that the process of step S186 is not limited to the lottery, and the second providing unit 22b may select an object by any selection method. As another example, after an object population is determined, each object in the object population may be presented to the user as a selection candidate, and as illustrated in steps S181 to S182b in FIG. selection processing may be performed.

The sequences of FIGS. 10 and 11 have the following points in common. In either case, in step S180b (third selection in the second mode), the second imparting unit 22b selects from among "one or more objects designated based on user operations from the operation accepting unit 26" to the user. You can choose which object to give. That is, in FIG. 10, "one object specified based on the user's operation from the operation reception unit 26" among the candidate objects 29a to 29c is determined as the object to be given to the user. Also, in FIG. 11, based on the user's operation from the operation reception unit 26, a "population setting table including one or more objects" is designated, and from among these, by an arbitrary method (lottery, user designation, etc.), An object to give to the user is determined.

(2.2. Second modification)
In the second modification illustrated in FIGS. 12 and 13, a plurality of types of first selections are provided. As an example, it is assumed that there are n first selections (first type to n-th type), where n is an arbitrary integer. For example, these n first selections may have different associated object populations (that is, population setting tables used for lottery). This object population difference may be a difference in one or more of object content, object count, and winning probability.

In the second modification, the user designates a desired first selection from these n first selections and then makes a provision request. As an example, the provision request process may be implemented by the following process. The user terminal 3 stores in advance a list screen of n first selections, and may display this list screen on the display unit 224 when the user attempts to make a provision request. The list screen may be a screen in which, for example, the first to n-th first selections are presented with different icons, banners, name lists, or the like. The user selects a specific first selection from the list on the display section 224 and transmits the request for provision from the user terminal 3 . In addition to the provision request, the user terminal 3 transmits type identification information that identifies the type of the first selection.

For example, when there is a provision request from the user U01 (step S110 in FIG. 10), the provision request receiving unit 21 sends the provision request from the user terminal 3 and the type of the first selection to the first providing unit 22a. introduce. The first granting unit 22a confirms "for which first selection the provision request has been issued" in the provision request confirmation in step S120a. For example, it is assumed that the user U01 issues a provision request by designating "the first selection of the first type" (for example, by tapping the corresponding icon). In this case, the first imparting unit 22a selects a plurality of first selections provided for each type (steps S131-1, S131-2, . · Of S131-n), the process of "first selection of the first type" (step S131-1) is executed. Specifically, the first provision unit 22a performs a lottery using a population setting table that is pre-linked to the first selection of the first type.

In subsequent step S132, the first granting unit 22a adds 1 to the counter value corresponding to the type of the executed first selection. If the first selection of the first kind has been performed, 1 is added to the counter value cnt_i1. For each user, counter values cnt_i1 to cnt_in corresponding to each of the first to n-th first selections are provided. For example, if user U01's provision requests concentrate on the first selection of the first type, only counter value cnt_i1 for user U01 increases significantly.

After that, as in the sequence of FIG. 9, result registration is performed for giving the object selected by lottery to the user (step S140). As in the sequence of FIG. 9, when the predetermined condition is satisfied in step S160, a process specific to the second modification is performed in step S170a (second selection).

In the second selection in step S170a, first, instead of step S171 (play history acquisition) in FIG. 10, the execution type of the first selection is specified. Specifically, in step S131 executed immediately before step S160 this time, it is specified which type of first selection was executed. Although there is no limitation to the specifying method, for example, a process of reading out the type of the first selection last updated (counter value addition) in step S132 may be performed.

Here, as an example, it is assumed that the first selection of the first type (step S131-1) was executed immediately before step S160 this time. In this case, the second adding unit 22b selects the table T8-1 corresponding to the first selection of the first type among the mode selection probability tables T8-1, T8-2, . . . T8-n shown in FIG. See Subsequently, the second imparting unit 22b reads the second mode selection probability weight_i1 from the table T8-1 based on the current counter value cnt_i1 of the user U01. Thereafter, the second imparting unit 22b executes mode selection processing using the second mode selection probability weight_i1, as in step S172 (mode selection processing) in FIG. The processing of subsequent steps S173 to S175 and the subsequent step S180 (third selection) are the same as in the sequence of FIG.

According to this second modification, if there is a difference in the number of executions cnt_i1 to cnt_in of the 1st to n-th first selections, the difference can be reflected in the mode selection probability in the second selection. This has the advantage of being able to adjust the mode selection probability according to the difference in the user's degree of enthusiasm for each of the plurality of first selections. Although FIG. 13 shows specific examples of the selection probabilities of the tables T8-1 to T8-n, the numerical values of the selection probabilities may be the same or different between the tables T8-1 to T8-n. good.

(2.3. Third modification)
The third modification modifies the processing of steps S171 and S172 in FIG. 10 using the play history table T5a in FIG. 7A and the mode selection probability table T9 illustrated in FIG. Thus, the third modification performs mode probability control according to "the number of times a predetermined object has been given in the first selection".

The "predetermined object" in the third modification may be, for example, a "low rarity value object (low rarity object)". This low rarity value object is a predetermined “low rarity value object” in the game provided by the game providing unit 20 . "Rarity value" can be defined from any point of view. As an example, each object may be pre-allocated with multiple levels of “rarity parameters”. This rarity parameter column may be added to tables such as the object table T1 and the population setting tables T4-1 to T4-9. For example, when three levels of rarity parameters are set, objects with rarity levels 1 and 2, excluding objects with the highest rarity level (rarity level 3), may be set as predetermined rarity value objects. As another example, in the population setting tables T4-1 to T4-9 in FIG. 6B, objects with high winning probability (for example, 5% to 10% or more) may be set as low rarity value objects. Alternatively, an object that has been won a number of times in the first selection in the past for a predetermined number of times or more may be regarded as an object that has been won a lot and has a low rarity value, and may be regarded as the low rarity value object. .

Referring to FIG. 10, in the third modified example, the second granting unit 22b refers to the play history table T5a of FIG. 7A as the play history. The second granting unit 22b generates an object list of objects (specifically, characters) provided to the current corresponding user (for example, user U01) from the play history table T5a.

In order to count the number of times the predetermined object is given in the first selection, in the third modification, the second giving unit 22b extracts "only objects given in the past first selection". Create an object list. As an example, a separate dedicated table may be provided to sequentially store the character IDs of the objects given by the first selection together with the user IDs. Alternatively, by providing a later-described play history table T5a1 of FIG. 19, only records to which the first selection (acquisition route Select1) is given may be extracted to the object list.

Next, the second adding unit 22b may search the acquired object list and add 1 to the count counter value cnt_clr each time the predetermined object (low rarity value object) is hit. Thereby, the number of "low rarity value objects" may be counted.

For example, assume that the number of low rarity value objects provided to the user U01 by the first selection is five. In this case, in the mode selection probability table T9 of FIG. 14, a selection probability of 50% corresponding to "cnt_clr=5" is read. After that, the second imparting unit 22b uses the second mode selection probability weight (50%) to execute step S172 (mode selection process) in FIG. The processing of subsequent steps S173 to S175 and the subsequent step S180 (third selection) are the same as the sequence in FIG. 10 and the like.

As another modification, the "predetermined object" may be, for example, a high rarity value object that is given less times than a predetermined number of times. Alternatively, an object arbitrarily specified by the game provider may be the "predetermined object" regardless of rarity.

(2.4. Fourth modification)
A fourth modification will be described with reference to FIGS. 15 and 16. FIG. In the fourth modified example, a plurality of types of first selections are provided as in the second modified example. Referring to FIG. 15, the first imparting unit 22a according to the fourth modification executes one of the n first selections (steps S131-1 to S131-n) as in the sequence of FIG. . Subsequently, in step S132a of FIG. 15, the first imparting unit 22a retains or stores the type of the first selection executed most recently. Here, as a specific example, it is assumed that step S131-1 is executed immediately before step S132a. In this case, the information "first type" is stored in step S132a. Subsequently, steps S140 to S160 are executed in the same manner as in FIG. 12, etc., and it is assumed that a predetermined condition is established in step S160. Furthermore, it is assumed that the second mode is selected in subsequent step S170 (second selection).

Next, refer to FIG. In step S180b (the third selection in the second mode), the second provision unit 22b reads out the type held in step S132a (step S187b). Based on the above specific example, it is assumed that the type read this time is the "first type".

Subsequently, the second provision unit 22b determines and presents designation candidates (step S188b). In this step, the table T10 in FIG. 17 is referenced. Table T10 is an example of a table in which population IDs are associated in advance with first selection types (first to n-th types). It is assumed that the table T10 is set in the object storage unit 23 in advance. For convenience, the first type is denoted as S1A, the second type is denoted as S1B, the third type is denoted as S1C, and the nth type is denoted as S1N. In step S188b, population ID is determined from table T10 based on the type read out in step S187. For example, if the type read this time is the "first type", the population ID associated with the first type S1A is B01. In this case, the second provision unit 22b determines the object population B01 as a user designation candidate, and causes the display unit 224 to display each object of the object population B01. For example, the user terminal 3 may display the object presentation screen 28 on the display section 224 when the user terminal 3 receives a display instruction from the second providing section 22b.

Note that the above processing is an example, and the processing of step S188b can be variously modified. For example, it is possible to use a table in which a predetermined number of character IDs are associated with each type S1A, S1B, . In addition, instead of selecting all objects in each object population as user-designated candidates, only some objects selected from among them may be selected as user-designated candidates (in that case, the selection method is arbitrary. For example, A lottery may be used, or a regular narrowing process other than a lottery may be used).

After that, the second granting unit 22b determines the object specified by the user in step S182b (accepting user operation) as an object to be granted to the user (step S183b).

(2.5. Fifth modification)
A fifth modification selects an object to be given to the user based on a predetermined rule set in advance in the second mode. This point is different from mere lottery or user operation designation. Specifically, in the fifth modification illustrated in FIG. 18, in step S180b (third selection in the second mode), the processing of steps S189b1 to S189b3 (object granting according to the past granting frequency) is provided. It is

In step S180b of the fifth modified example, first, in step S189b1, the second adding unit 22b reads out the population. The example of FIG. 18 describes an example in which the same object population (eg, population B01) is read in the object lottery in the first mode (step S181a) and in the population reading in the second mode (step S189b1). . However, this is only an example, and the object population may be different between steps S181a and S189b1.

Next, the second providing unit 22b reads the play history, and refers to the play history table (object provision result table) T5a in FIG. 19 (step S189b2). The play history table T5a1 has an acquisition route column. In the acquisition path column, acquisition paths of objects are recorded separately for the first selection (Select1), the third selection in the first mode (Select3_m1), and the third selection in the second mode (Select3_m2). be done. The play history table T5a1 is updated at any time during result registration (steps S140 and S190). As a result, for example, when the user who is currently requesting the provision is the user U01, it is possible to refer to the object grant history granted to the user U01 in the first selection. If the same object is granted at different times, its history is recorded in different records. Based on the appearance frequency of each character ID in the table, the number of times each object is given can be easily specified for each user.

Subsequently, the second provision unit 22b performs provision frequency determination (step S189b3). In the granting frequency determination, the granting frequency of each object to each user is determined based on the information obtained in step S189b2. Specifically, for each user, an object whose grant frequency (specifically, the number of grants) is equal to or less than a predetermined reference frequency is extracted. The predetermined reference frequency may be, for example, zero times (never given) or one to several times (rarely given). As another example, the predetermined reference frequency may be the minimum value among the character ID appearance frequencies in the table. In this case, the predetermined reference frequency is the "minimum number of times of application", and the object with the lowest application frequency is extracted by the application frequency determination. When a plurality of objects having the same given frequency are extracted, a lottery may be further conducted therefrom, or the objects may be narrowed down by other narrowing-down rules. Other narrowing-down rules may be arbitrarily determined, but for example, priority may be given to the one with the oldest given time. Note that determination of the application frequency may be limited to, for example, the number of applications within a predetermined period, or, for example, may be limited to the number of applications that go back several months to several years in the past. In that case, the play history table T5a1 may be provided with a "given date and time column" that records the date and time when the object was given.

Next, the second granting unit 22b determines the object extracted by grant frequency determination as an object to be granted to the user (step S183b). The subsequent processing is the same as the sequence in FIG. 10 and the like.

(2.6. Sixth modification)
In the sixth modification, an object lottery is performed as the third selection not only in the first mode but also in the second mode. As illustrated in FIG. 20, in the sixth modification, object lottery processing is performed in step S180b (third selection of second mode) (similar to step S186b in FIG. 11). However, there is a difference in the content of the lottery between the first mode and the second mode.

As an example, in FIG. 20, the population setting table T4-1 (see FIG. 6B) is used in the first mode object lottery (step S181a in FIG. 20). On the other hand, in the second mode object lottery (step S186b in FIG. 20), the population setting table T4-1a (see FIG. 6C) is used. As a result, "objects not to be discharged in the first mode (specifically, the character C150 of the difference D1 in FIG. 6C)" can be included in the discharge target population in the second mode. This character C150 may be, for example, a high rarity value object. For example, in an example where the rarity level is defined by three levels of rarity parameters, the object with the highest rarity level (rarity level 3) may be the high rarity value object.

Various modifications of the example of FIG. 20 are possible. For example, in the first mode object lottery (step S181a), the population setting table T4-1 (see FIG. 6B) may be used. On the other hand, the population setting table T4-1b or T4-1c (see FIG. 6C) may be used in the second mode object lottery (step S186b in FIG. 20). As a result, although the first mode and the second mode are both lotteries, the ejection probability (winning probability) can be made different for at least one predetermined object. The winning probabilities may be different only for some objects (character C120) as in the population setting table T4-1b, or may be different for all objects as in the population setting table T4-1c. good.

(2.7. Mode variations)
As described in the embodiment, the second imparting section 22b performs the second selection of selecting a mode from among a plurality of modes. Each mode defines the selection scheme when the third selection is made. The third selection is that the second granting unit 22b selects an object to be granted to the user in the selected mode.

In the embodiment and some modifications, the third selection in the first mode is standardized as "lottery", but the first mode is not limited to this. A first mode other than the lottery may be used, and for example, a plurality of first modes having the same content as the plurality of second modes 180b exemplified in the embodiment and the first to sixth modifications may be provided. Specifically, for example, one of the processes of step S180b (third selection of the second mode) illustrated in FIGS. , and the other one as the second mode. Even in such a case, the first mode and the second mode may be set so that the contents do not overlap, and the second imparting section 22b may select the mode by the second selection. As a result, special object acquisition opportunities by the second granting unit 22b can be varied.

Stated more exhaustively, modes may differ from one another in one or more of the following aspects. As an example, a plurality of modes may differ from the viewpoint of "selection method", may differ from the viewpoint of "selection target", and may differ from the viewpoint of "external influence (whether or not)". , may be different from the point of view of "population difference" or from the point of view of "selection probability difference". Any combination of two or more of these aspects may be used to differentiate between modes. For example, even if the selection method is the same, there is a difference between modes if there is a difference in selection targets. For example, even if the selection method and the selection target are the same, if there is a difference in terms of external influences, etc., there is a difference between the modes.

The difference in selection method between modes may be, for example, the difference between user selection and non-user selection. User selection is a selection method in which the user actively designates an object by user operation and selects it as an object to be given to the user. Non-user selection is a selection method in which a server, terminal, program, or the like automatically selects an object without user operation. This can be said to be passive object selection for the user. Non-user selections may be further subdivided, e.g. at least lotteries and predetermined rule selections (ie, rule-based selections other than lottery), both of which may be used as differences between modes.

The difference between the selection targets in the modes is whether to select only the objects or to select the objects after selecting the object population. When there is no selection of an object population, the same object population may be selected each time, but the content of the one type of object population may be fixed or changed at any time. Even if the number of objects to be selected differs between modes, it is included in this difference in selection targets.

The difference in external influence in the mode may be, for example, whether or not the influence of "play history" is included. Although it has been described that there are several types of play histories, the difference between modes may be that the types of play histories to be incorporated into the processing within the modes, the history accumulation periods, and the like are different.

Population difference in mode means whether the object population is the same or different between one mode and another mode. If at least some objects are different between the modes, then there is a difference in the object population between the modes. For example, differences in object populations may be differentiated step by step, such as perfect match, partial match, and perfect difference (no overlap).

The difference in object winning probabilities between modes is whether or not there is a difference in object winning probabilities between modes when the selection method is non-user selection. Specifically, it is whether or not there is a difference in the numerical value of the winning probability of the object, and the difference may be graded as complete match, partial match, and complete difference (no duplication).

FIG. 21 is a block diagram showing another specific example of the functional configuration of the information processing device 1. As shown in FIG. As exemplified in FIG. 20, a mode storage unit 27 may be provided in which processing in each mode is stored in advance. As described above, there are a wide variety of modes, and it is possible to provide three or more modes in the second imparting section 22b.

(2.8. Mode advantage/disadvantage)
The second mode in the above-described embodiments and some variations may be treated as the "advantageous mode.""Advantageous" means advantageous for the user in terms of object acquisition. The advantages/disadvantages of the modes referred to here are determined by relative comparison between a plurality of modes that are candidates for selection in the second selection.

As an example, in the embodiment (FIGS. 10 and 11) and the first modified example (FIG. 11), in the second mode, an object or table is selected by a user instruction. Compared to the first mode, such a second mode can be said to be an advantageous mode for the user in that the user can actively participate in the selection of objects and the like.

As another example, when the object populations handled in the first mode and the second mode are different as illustrated in FIG. 20, the object population in the second mode may be advantageous for the user. Here, as an example, the characters C910 to C980 of the object population B09 in FIG. 6B are on average higher in rarity than the characters in the other object populations B01 to B08 (that is, on average the grant frequency is lower). shall be In this case, in the second mode, the population setting table T4-9 may be used to select an object to be given to the user from the characters C910 to C980. Such a second mode can be said to be a relatively advantageous mode for the user in that it is easier to obtain a high rarity value object than in the first mode.

As still another example, when the lottery is performed in the first mode and the second mode as illustrated in FIG. 20, the winning probability may be set such that the second mode is more advantageous for the user. For example, the population setting tables T4-1b and T4-1c in FIG. 6C are set so that the winning probability of the character C120 is high, and the second mode in the sequence example of FIG. 20 may use these tables. Such a second mode can be said to be an advantageous mode for the user in that the possibility of the user acquiring a specific object increases compared to the first mode.

As yet another example, as illustrated in FIG. 18, objects may be selected in the second mode such that they are less likely to overlap with already acquired objects for the user. In terms of the possibility that duplicated objects are unnecessary for the user, the second mode can also be said to be an advantageous mode for the user compared to the first mode.

(2.8. Other Modifications)
In the embodiment and each modified example, the second selection performed by the second granting unit 22b is a lottery using the mode selection probability table as an example, but it is not limited to this. The second selection may be constructed such that the second providing unit 22b selects the mode based on a predetermined selection rule other than lottery. As an example of the predetermined selection rule, for example, the second mode may be selected when the play history satisfies the predetermined selection condition, and the first mode may be selected otherwise. This predetermined selection condition can be set in various ways, but one example is whether or not it is within a predetermined period of time after clearing a specific quest. Whether it is within or not may be acceptable.

The present invention can also be implemented as a program that causes a server that implements the information processing apparatus 1 described above to function.

Furthermore, the present invention can also be implemented as a computer-readable non-temporary recording medium that stores the above-described program.

<3. Features of Embodiments and Modifications>
The features of the embodiments of the present invention and their modifications may be summarized as (1) to (11) below.

(1) According to one aspect of the present invention, an information processing device 1 is provided that includes a first imparting unit 22a and a second imparting unit 22b. The first granting unit 22a makes a first selection (object lottery). The second imparting unit 22b performs a second selection (mode selection) and a third selection (object selection). By providing a plurality of second selection modes (first mode, second mode), it is possible to provide the user with opportunities to receive objects in different modes. Thereby, the special object acquisition opportunity by the 2nd provision part 22b can be enriched with variety.

(2) Based on the user's play history (see FIGS. 7A to 7C, etc.), the probability of each mode being selected in the second selection may be set (see FIGS. 8A to 8C, FIG. 13, etc.). This has the advantage that special object acquisition opportunities are more varied, as mode selection probabilities can be associated with play history. Motivation to play the game can also be enhanced in order to receive object offerings in advantageous modes.

(3) The second imparting unit 22b may set the probability that the second mode is selected according to the number of times the first mode is selected (counter value cnt_m) for each user (see FIG. 8A). This has the advantage that the selection frequency of each mode can be adjusted each time the second selection is made, thereby making the special object acquisition opportunities even more varied.

(4) The second imparting unit 22b may reduce the amount added in setting the stochastic control when the second mode is selected in the second selection. Specifically, as an example, the second mode selection probability in the mode selection probability table may be returned to the lowest probability by resetting the counter value cnt_m in step S175 of FIG. This allows the probability to be adjusted so that the second mode is not chosen too frequently.

(5) The second imparting unit 22b may set the probability that each mode is selected in the second selection according to the number of executions of the first selection (counter value cnt_i) (see FIG. 8B). This has the advantage of making the special object acquisition opportunities even more varied since the selection frequency of each mode can be adjusted each time the first selection is made.

(6) As exemplified in the second modification of the embodiment (see FIGS. 12 and 13), the second imparting unit 22b determines the number of executions of each of the n first selections (the counter value cnti1 in FIG. 12). ˜cnt_in), the probability of each mode being selected in the second selection when the predetermined condition (step S160) is satisfied in the execution of each first selection may be set. If there is a difference in the number of executions of each first selection, the difference can be reflected in the probability of each mode being selected in the second selection. This makes it possible to adjust the probability of each mode being selected according to the difference in the user's degree of enthusiasm for each of the plurality of first selections.

(7) As exemplified in the third modified example of the embodiment (see FIG. 14), the second adding unit 22b selects a to set the probability that each mode is selected in the second selection. This makes it possible to adjust the selection tendency of the mode in the second selection according to the predetermined object grant frequency in the first selection.

(8) As described above in "advantage/disadvantage of mode", in the embodiment and some modifications, the second imparting unit 22b selects a mode that is more advantageous for the user in obtaining an object than the first mode. You may choose as 2 modes. The inclusion of multiple modes of relative disadvantage/advantage has the advantage of making the special object acquisition opportunities even more varied.

(9) In the second mode (see step S180b in FIG. 10 or 11, for example), the second imparting unit 22b selects a third object from among one or more objects specified based on a user operation (operation accepting unit 26). The object to be given to the user may be selected by selecting . In addition, in the first mode (step S180a), the second granting unit 22b may select an object to be granted to the user by the third selection from among one or more predetermined objects regardless of the user's operation. Since the second mode allows the user to participate in the selection of objects, it has the advantage of being distinct from the first mode and offering a greater variety of special object acquisition opportunities.

(10) As exemplified in the fourth modification of the embodiment (see FIGS. 15 to 17), the first adding unit 22a performs n first selections of different selection candidate objects. good too. Further, the second providing unit 22b becomes a designation candidate for the user operation in the second mode according to the first selection executed when the predetermined condition is satisfied (step S160) among the n kinds of first selections. The object may be presented to the user (step S188b). Thus, when the user issues a provision request for a specific type of first selection, it is possible to present designation candidate objects associated with the specific type of first selection. Therefore, there is an advantage that an object that is highly likely to be desired by the user can be easily provided as a designation candidate.

(11) As illustrated in the fifth modification of the embodiment (see FIGS. 18 and 19), in the first mode, the second granting unit 22b selects an object by drawing lots from the object population. It's okay. Furthermore, in the second mode, the second imparting unit 22b selects, as objects to be imparted to the user, objects that belong to the same object population as in the first mode and whose imparting frequency in past first selection is equal to or lower than a predetermined reference. (Steps S189b1 to S189b3 in FIG. 18). As a result, there is an advantage that an object that is difficult for a certain user to acquire by the first selection can be preferentially provided to the user.

(12) Another aspect of the present invention provides a program for causing a computer to select an object. This program causes the computer to execute a first selection to select an object to be given to the user, and selects a mode from a plurality of different modes for the user for whom a predetermined condition is satisfied by executing the first selection. Cause the computer to perform a second selection, and cause the computer to perform a third selection to select an object to be given to the user in the mode selected in the second selection.

(13) Another aspect of the present invention provides an information processing method. In this information processing method, a computer performs a first selection of an object to be given to a user, and selects a mode from among a plurality of different modes for the user who has satisfied a predetermined condition by executing the first selection. A computer makes a second selection to select, and a computer makes a third selection to select an object to be given to the user in the mode selected in the second selection.

While various embodiments of the invention have been described, these have been presented by way of example and are not intended to limit the scope of the invention. The novel embodiment can be embodied in various other forms, and various omissions, replacements, and modifications can be made without departing from the scope of the invention. The embodiment and its modifications are included in the scope and gist of the invention, and are included in the scope of the invention described in the claims and equivalents thereof.

1: information processing device 2: WAN
3: User terminal 11: Control unit 12: Storage unit 13: Communication unit 14: Operation input unit 15: Monitor 16: System bus 20: Game provision unit 20a: Game information storage unit 21: Provision request reception unit 22: Object provision unit 22a: first granting unit 22b: second granting unit 23: object storage unit 24: play history table 24: play history storage unit 25: probability data storage unit 26: operation reception unit 27: mode storage unit 28: object presentation screen 29a , 29b, 29c: candidate object 30: object display area 221: control unit 222: storage unit 223: communication unit 224: display unit 225: speaker 226: microphone 227: camera 228: operation button

Claims (1)

An information processing device comprising a first imparting unit and a second imparting unit,
The first granting unit performs a first selection of an object to be granted to the user,
The second providing unit performs a second selection of a mode from a plurality of different modes for the user who satisfies a predetermined condition in the execution of the first selection,
An information processing apparatus that performs a third selection of selecting an object to be given to the user in the mode selected by the second selection.

Images