Information processing device, program, and information processing method

Abstract

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

Description

Technical Field

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

Background Art

[0002] Patent Document 1 discloses a technique for granting a predetermined privilege when a predetermined object is not granted even after a lottery is conducted a predetermined number of times.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In Patent Document 1, a privilege is only granted in a certain manner when certain conditions are met, and the privilege provided to the user tends to be uniform. As a result, problems such as a decrease in user satisfaction may occur.

[0005] The present invention provides an information processing apparatus, a program, and an information processing method that can suppress the adverse effects of uniform privilege provision.

Means for Solving the Problems

[0006] An information processing apparatus according to an aspect of the present invention is an information processing apparatus including a first granting unit and a second granting unit, wherein the first granting unit makes a first selection to select an object to be granted to a user, and the second granting unit makes a second selection to select a mode from a plurality of different modes for the user for whom a predetermined condition is satisfied by the execution of the first selection, and makes a third selection to select an object to be granted to the user in the mode selected by the second selection.

[0007] When a predetermined condition is satisfied, the second awarding unit provides a privilege (i.e., a special object acquisition opportunity) to the user. According to one aspect of the present invention, a mode is selected by a second selection from a plurality of types of modes, and a third selection of selecting an object is further performed in each mode. Thereby, an opportunity for the user to receive the granting of an object in different ways (modes) can be provided. Therefore, the special object acquisition opportunity can be made rich in variety.

Brief Description of Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Mode for Carrying Out the Invention

[0009] Hereinafter, some embodiments of the present invention will be described with reference to the drawings. Various characteristic matters shown in the following embodiments can be combined with each other. Further, an invention can be established independently for each characteristic matter.

[0010] <1. Embodiment> (1.1. Outline of the information processing apparatus 1) Referring to FIG. 1, the outline of the information processing apparatus 1 according to the embodiment will be described. As shown in FIG. 1, the information processing apparatus 1 is realized by one or a plurality of servers (computers). The information processing apparatus 1 is configured to be able to communicate with the user terminal 3 by being connected to a WAN (Wide Area Network) 2 such as the Internet.

[0011] The user terminal 3 is realized by a mobile terminal (computer) such as a smartphone owned by a game user (hereinafter, also simply referred to as a user). The information processing apparatus 1 receives a request for providing an object (hereinafter, also simply referred to as a provision request) from the user via the user terminal 3. Here, the "object" is a general term for electronic data used by the user for the progress of the game. Specifically, the object may include, for example, a character, an item, a card, or an avatar, etc. In the following embodiments, an example of providing a character as an object will be described.

[0012] When the information processing apparatus 1 receives a request for providing an object from a user, it selects one or more objects from the available objects and provides them to the user. Note that the information processing apparatus 1 may be configured not to provide an object to the user more than a predetermined number of times for the objects that can be provided to the user. Thereby, the user may be able to predict the necessary cost until obtaining a desired object.

[0013] (1.2. Hardware Configuration of Information Processing Apparatus 1) Referring to FIG. 2, the hardware configuration of the information processing apparatus 1 will be described.

[0014] FIG. 2 is a block diagram showing the hardware configuration of the information processing apparatus 1 according to the present embodiment. The information processing apparatus 1 includes a control unit 11 and a storage unit 12. The control unit 11 controls the overall operation of the information processing apparatus 1. 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 the storage unit 12 in advance.

[0015] Furthermore, the information processing apparatus 1 is connected to the user terminal 3 via a communication line and includes a communication unit 13 that transmits and receives various data. The information processing apparatus 1 may also include an operation input unit 14 configured by a keyboard, a mouse, etc. that receives inputs of various operations, and a monitor 15 such as a liquid crystal display device that displays various images.

[0016] The control unit 11, the storage unit 12, the communication unit 13, the operation input unit 14, and the monitor 15 are electrically connected to each other via a system bus 16. Therefore, the control unit 11 can access the storage unit 12, grasp the operation state of the operation input unit 14, display an image on the monitor 15, and transmit and receive various data to and from other information processing apparatuses such as the user terminal 3 via the communication unit 13.

[0017] (1.3. Hardware Configuration of User Terminal 3) Referring to FIG. 3, the hardware configuration of the user terminal 3 will be described. The user terminal 3 includes, as an example, a control unit 221 including a processor or the like, a storage unit 222 including a non-volatile 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 an operation button 228. The specific configuration of the user terminal 3 is not limited, and it may be various types of mobile terminals, smartphones, tablet terminals, or notebook PCs. When the user terminal 3 has a touch panel display, the display unit 224 and the operation button 228 may be integrated into 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.

[0018] (1.4. Functional Configuration of Information Processing Apparatus 1) Using FIG. 4, the functional configuration of the information processing apparatus 1 will be described.

[0019] As shown in FIG. 4, the information processing apparatus 1 includes a first granting unit 22a and a second granting unit 22b. The first granting unit 22a and the second granting unit 22b are realized as functions of the control unit 11. The first granting unit 22a makes a first selection to choose 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, the first granting unit 22a selects an object by lottery, the first granting unit 22a selects an object according to a user operation specification, or the first granting unit 22a selects an object according to a predetermined rule other than lottery. In the embodiment, as an example, the first selection is described as being by lottery.

[0020] The second granting unit 22b makes a second selection and a third selection. The "second selection" is that for the user for whom a predetermined condition is satisfied by the execution of the above first selection, the second granting unit 22b selects a mode from among a plurality of different modes.

[0021] The "predetermined condition" is an arbitrary condition that can be determined in various ways according to the execution of the first selection. An example of the predetermined condition is that when the number of executions of the first selection by the same user reaches a predetermined number (for example, 10 times), it is determined that the predetermined condition is satisfied for that user, and the execution count counter is reset to 0. Here, the execution count may be, for example, the cumulative execution count. The cumulative execution count may be the sum of the execution counts within a predetermined period. Another example of the predetermined condition is that when the number of acquired predetermined objects reaches a predetermined number, it may be determined that the predetermined condition is satisfied for that user. Another example of the predetermined condition is that when there are duplicate objects among the currently held objects, if the number of types of duplicate objects or the number of duplicates of a single object reaches a predetermined threshold, it may be determined that the predetermined condition is satisfied for that user.

[0022] The "multiple different modes" can be any number of modes set in advance to be different from each other. In the embodiment, as an example, two modes (the first mode and the second mode) are set in advance.

[0023] 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, that the second granting unit 22b selects an object by lottery, or for example, the second granting unit 22b selects an object according to a user operation specification, or for example, the second granting unit 22b selects an object according to a predetermined rule other than lottery. The third selection may be a selection method different from the first selection or the same selection method.

[0024] FIG. 5 shows an example in which the functional configuration of the information processing apparatus 1 is embodied. In FIG. 5, its peripheral functional units are illustrated together with the first granting unit 22a and the second granting 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 granting unit 22, an object storage unit 23, a play history storage unit 24, a probability data storage unit 25, and an operation receiving unit 26. The object granting unit 22 includes the first granting unit 22a and the second granting unit 22b described in FIG. 4.

[0025] The game providing unit 20 provides a game to a user by communicating with the user terminal 3 using information such as a program read from the game information storage unit 20a. The play history of the user is stored in the play history storage unit 24 via the game providing unit 20. There is no limitation on the specific content of the game provided by the game providing unit 20. 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. The details of the provided game may be set in various ways. For example, if it is a simulation game, it may be themed on sports as an example, or themed on cultivation or management as another example. Alternatively, it may be a game that combines two or more of the plurality of game systems listed here. The play history also includes the clearance history of each of one or more "quests" set in the game.

[0026] The game providing unit 20, the provision request receiving unit 21, the object granting unit 22, and the operation receiving unit 26 are realized as functions of the control unit 11. The game information storage unit 20a, 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. The specific operations of each functional unit will be described later.

[0027] The above-described functional configuration may be implemented by a CPU (Central Processing Unit) implemented as the control unit 11 executing a program, or may be implemented by hardware.

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

[0029] (1.5. Table Configuration) Using FIGS. 6A to 6C, FIGS. 7A to 7C, and FIGS. 8A to 8C, the tables stored in the object storage unit 23, the play history storage unit 24, and the probability data storage unit 25 will be described.

[0030] Each of the tables in FIGS. 6A to 6C is stored in the object storage unit 23.

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

[0032] The user table T2 in FIG. 6A stores information about users who use the game. The user table T2 includes a user ID column and a surname column. The user ID column holds a user ID for uniquely identifying a user. The surname column holds the surname of each user.

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

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

[0035] In the embodiment, as an example, a winning probability column for each character at the time of lottery is also recorded in the object population table. That is, the population setting tables T4-1 to T4-9 also function as "object winning probability tables".

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

[0037] Referring to FIG. 6C, variations of the population setting table are exemplified. Each of the population setting tables T4-1a, T4-1b, and T4-1c in FIG. 6C defines 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. Difference D1 is that the characters in record No. 050 are different between C120 and C150. Thus, a plurality of object population tables in which some (one or more) characters are different and other characters are common may be provided. Difference D2 is that the characters in record No. 050 are the same, but the selection probabilities are different between 1% and 30%. Thus, in a plurality of object population tables, the selection probabilities may be made different for some (one or more) characters. Difference D3 is that the selection probabilities of all characters are different. As a more specific example, a selection probability of 100% is given to the character C120 in record No. 050. This means that when lottery is performed using the population setting table T4-1c, the character C120 will surely be selected. Thus, an object population table in which some (one or more) characters have a high probability may be provided. Note that it is not limited to 100%, and any high probability such as 99% to 90% may be used. Alternatively, a probability of 100% may be assigned to some characters in the table. For example, it may be distributed to two characters at a ratio of 50%:50% or 30%:70%. For each of the other population setting tables T4-2 to T4-9, each variation exemplified in FIG. 6C may be similarly added.

[0038] Each of the tables in FIGS. 7A to 7C is stored in the play history storage unit 24. The play history storage unit 24 stores the play history of each user as the game progresses.

[0039] Here, the "play history" is the history accumulated by the user playing the games provided by the game providing unit 20. The play history may include various histories according to the game progress. To give an example, specifically, the play history may include, for example, past object provision results, may include, for example, the results of past first selections, may include, for example, the results of past second selections, or may include, for example, "whether a specific stage, quest, or event has been played in the past or currently, and the number of times of play, etc.".

[0040] The play history table (object provision result table) T5a in FIG. 7A is a table that stores information for identifying the objects provided to the user for each user. The play history table T5a includes a No column for uniquely identifying the 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 made the object provision request. The population ID column holds the population ID of the object population that includes the character 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, the provided character and information on the object population that includes the character are registered.

[0041] Note that the object provision history in other routes (such as quest rewards or limited-time event rewards, etc.) other than the object granting in the embodiment may be added to the play history table T5a. Alternatively, in addition to the play history table T5a, another "other play history table" may be provided, and the objects provided to the user through other routes (such as quest rewards or limited-time event rewards, etc.) other than the object granting in the embodiment may be stored in this other play history table. This "other play history table" may be added to the play history table T5a.

[0042] The play history table (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 column for the number of executions of the first selection. Each time a user sends an object provision request from the user terminal 3 to the provision request reception unit 21, the first granting unit 22a executes the first selection. Each time the execution is performed, the numerical value in the column for the number of executions of the first selection is incremented for each user. Note that the number of executions in the play history table T5b1 may be reset or decremented according to a predetermined timing or the satisfaction of a predetermined condition. For example, it may be reset at predetermined regular intervals or the like.

[0043] The play history table (number of mode selections) T5b2 in FIG. 7B is a table that accumulates the execution results (that is, mode selection results) of the second selection executed for each user. In the embodiment, as an example, "the number of times the first mode is 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 column for the number of first mode selections. 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 further executes the second selection (and the third selection) for the user for whom the predetermined condition is satisfied. Each time the second selection is executed, either the first mode or the second mode is selected. Each time the first mode is selected for each user, the numerical value in the play history table T5b2 is incremented. The numerical value of the 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. 10.

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

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

[0046] The mode selection probability tables T6-1 to T6-3 in FIGS. 8A to 8C are for controlling the probability (hereinafter also referred to as "selection probability") of selecting the second mode in the second selection. As shown in each of FIGS. 8A to 8C, the selection probability weight of the second mode is determined step by step based on the value of the selection count counter cnt_m of the first mode, the value of the execution count counter cnt_i of the first selection, and the value of the quest history counter cnt_q. The selection probability of the second mode can be controlled using each table. In the embodiment, since either the first or second mode is selected, the first mode selection probability is the value obtained by subtracting the second mode selection probability from 100%.

[0047] Note that the method of converting the quest history counter cnt_q of each user from the play history table T5c in FIG. 7C can be set in various ways. As an example, the counter cnt_q may be the number of clear times of a specific quest (for example, only Q009). As another example, the counter cnt_q may be a statistical value for the number of clear times of a plurality of quests. The statistical value may be, for example, the total value, average value, maximum value, or minimum value of the number of clear times.

[0048] Note that in the embodiment, various tables are comprehensively described as an example, but the embodiment does not necessarily require all these tables. At least, a necessary table may be provided for each sequence described later.

[0049] (1.6. Flow of Object Assignment) Referring to FIGS. 9 and 10, the flow of object assignment according to the embodiment will be described. In some figures, together with the processing flows of the provision request reception unit 21, the first assignment unit 22a, and the second assignment unit 22b, the functional block configuration of FIG. 5 (the operation reception unit 26, the object storage unit 23, the play history storage unit 24, the probability data storage unit 25) may be illustrated next to the processing steps. However, this is for convenience, and data transfer with the functional block configuration of FIG. 5 can also be performed as necessary for processing steps without such illustration.

[0050] FIG. 9 illustrates an overall view of the flow of object assignment according to the embodiment. First, the user operates the user terminal 3 to make a request for providing an object to the information processing apparatus 1 (see FIG. 1). Here, as an example, it is assumed that the provision request is a request for executing a lottery. This lottery may or may not involve charging. Also, for convenience, the case where the user who made the provision request is "User U01" may be described as an example.

[0051] In step S110, the provision request reception unit 21 receives the provision request. The first assignment unit 22a confirms the provision request (step S120) and executes the first selection (step S130). As an example, in the first selection, it is described that an object is selected by lottery. In this case, in the provision request confirmation in step S120, the first assignment unit 22a refers to the user table T2 to identify the corresponding user U01. Further, the first assignment unit 22a selects an object population corresponding to the current provision request from among the populations B01 to B09 of the object population table T3. The first assignment unit 22a performs a lottery by applying the winning probability of the population setting table corresponding to the selected object population. The object that wins in this lottery is the object to be assigned to the user U01 as the result of the current first selection.

[0052] Furthermore, the first awarding unit 22a executes result registration in step S140. Through result registration, the selected object can be awarded to the user U01. Specifically, in result registration, the play history table T5a in FIG. 7A is updated, a new record No. is added, and the character ID of the selected object is registered together with the user ID (U01 in this example). As a result, on the user terminal 3 of the user U01, the selected object is treated as an object held by the user U01. In addition to this, the first awarding unit 22a adds 1 to the execution count of the first selection of the user U01 in the play history table T5b1 in FIG. 7B.

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

[0054] If it is determined in step S160 that the predetermined condition is satisfied, the second awarding unit 22b makes a second selection (step S170) and a subsequent third selection (step S180). The following will be described with reference to FIG. 10.

[0055] In the second selection in step S170, first, the play history is acquired (step S171). The play history acquired here is the result of the past second selection. Specifically, the play history table (execution count of the first selection) T5b1 in FIG. 7B is referred to. In the example of FIG. 7B, the first mode selection count (cnt_m) of the user U01 is 3 times.

[0056] Next, in step S172, the second imparting unit 22b performs mode selection processing. Specifically, the second imparting unit 22b accesses the mode selection probability table T6-1 (see FIG. 8A) in the probability data storage unit 25, and reads out the selection probability weight = 50% corresponding to cnt_m = 3. Thereby, 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 a binary lottery process is executed. Note that cnt_m is "the number of times one mode (the first mode) among a plurality of modes is selected in the second selection", and the selection probability weight is "the probability of selecting another mode (the second mode) among a plurality of modes".

[0057] In step S173, the process branches according to the mode selection result in step S172. When the second mode is not selected (that is, when the first mode is selected), the process proceeds to step S174, and 1 is added to the counter value cnt_m of the first mode selection count. In the case of the current user U01, it is updated from 3 to 4. On the other hand, when the second mode is selected, the process proceeds to step S175, and the counter value cnt_m of the first mode selection count 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 subtracting a predetermined value (for example, minus 1 time or minus 2 times, etc.) may be used.

[0058] The third selection is performed according to the mode selected in the second selection. Each of them will be described below.

[0059] When the first mode is selected in the second selection, the process proceeds from step S170 to step S180a. Step S180a is the process of 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 user U01 is selected by lottery (step S181a). In the embodiment, the lottery in step S181a in this first mode may be different from the lottery in the first selection (step S130) in some respects. As an example of the difference, the object population to which the lottery is applied may be different. To give a preferred example, for example, characters C001 to C120 included in object population B01 in FIG. 6B are objects with relatively high awarding frequencies (i.e., low-scarce-value objects) in the game provided by game providing unit 20. On the other hand, for example, characters C910 to C990 included in object population B09 in FIG. 6B are objects with relatively low awarding frequencies (i.e., high-scarce-value objects) in the game provided by game providing unit 20. In this case, population setting table T4-1 in FIG. 6B may be used in the lottery of the first selection (step S130), and population setting table T4-9 in FIG. 6B may be used in the lottery of the first mode (step S181a). When an object is selected by lottery, the object to be given to user U01 is determined in step S182a.

[0060] On the other hand, when the second mode is selected in the second selection, the process proceeds from step S170 to step S180b. Step S180b is the process of the third selection in the second mode. In the embodiment, as an example, the second mode is a mode in which a user operation from user terminal 3 is received and the user is allowed to select (designate) an object himself / herself.

[0061] First, in step S181b, the second granting unit 22b transmits the character IDs of a plurality of candidate objects to be displayed as user selection candidates to the user terminal 3. When the user terminal 3 receives the character IDs of the candidate objects, the user terminal 3 displays an object presentation screen 28 on the display unit 224. The template image of 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 as an example, one of these candidate objects can be selected. It may be possible to select any number (which may be a plurality) less than the number of candidate objects presented. Note that there are several variations in the method of selecting a predetermined number of objects presented here. For example, it may be a fixed specific object, for example, an object selected based on the play history, for example, a presentation table for setting the objects to be presented may be provided, or for example, extraction may be performed from an arbitrary population setting table according to a predetermined presentation selection rule.

[0062] In the embodiment, as an example, when the object display area of each candidate object in the object presentation screen 28 is tapped, it is assumed that the candidate object in the display area is designated. When such an operation is performed on the user terminal 3, the user operation is input to the second granting unit 22b via the operation reception unit 26 (step S182b). The object designated by the user U01 in step S182b is determined as the object to be granted to the user U01 (step S183b).

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

[0064] In the sequence example of FIG. 10, in steps S171 and S172, the mode selection probability table T6-1 corresponding to the first mode selection count (counter value cnt_m) is used. However, it is not limited to this. As another example, a counter cnt_i for the number of executions of the first selection 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 selecting the second mode may be determined from the mode selection probability table T6-3 (see FIG. 8C).

[0065] <2. Variation Example> The above embodiment is an example, and various modifications, additions, or omissions can be made. Hereinafter, various variation examples will be described with reference to FIGS. 11 to 21 as well. These variation examples may be arbitrarily combined and used as long as they do not inhibit each other's application.

[0066] (2.1. First Variation Example) In the first variation example illustrated in FIG. 11, in the third selection (second mode) in step S180b, a process is provided to allow the user to specify an object population table. First, in step S184b, the population is presented. Specifically, some of the population setting tables T4-1 to T4-9 are presented to the user as selection candidates.

[0067] The population presentation in step S184b may be realized by the following process as an example. First, the second granting unit 22b transmits presentation table identification information for identifying the table to be presented this time among the population setting tables T4-1 to T4-9 to the user terminal 3. The user terminal 3 that has received the presentation table identification information displays the information of the population setting table indicated by the presentation table identification information on the display unit 224. As an example, the names of the respective object populations (see the object population table T3) may be presented on the display unit 224. As another example, arbitrary icons associated with the population ID may be presented as selection candidates on the display unit 224.

[0068] After the population presentation, the operation reception unit 26 receives a user operation from the user terminal 3. Here, as an example, it is assumed that there is a user operation to select the object population B05. Based on the user operation, the second granting unit 22b determines the object population B05 as the source object population in the third selection this time (step S185b).

[0069] Next, in step S186b, the second granting unit 22b selects an object 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 out the population setting table T4-5 corresponding to the object population B05 from the object storage unit 23 and performs a lottery on the objects in the table. Based on the lottery result, an object to be granted to the user U01 is selected (step S183b).

[0070] On the other hand, the first mode (step S180a) is the same as the example in FIG. 10. In this first mode, a lottery is performed from among the object populations determined without depending on a user operation (step S181a), and an object to be granted to the user U01 is determined (step S182a).

[0071] Note that the process of step S186 is not limited to lottery, and the second awarding unit 22b may select an object by any selection method. As another example, after the object population is determined, each object in the object population may be presented to the user as a selection candidate, and the selection process of the object based on the user instruction operation may be performed as exemplified in steps S181 to S182b of FIG. 10.

[0072] The sequences of FIGS. 10 and 11 are common in the following points. In both cases, in step S180b (the third selection in the second mode), the second awarding unit 22b can select an object to be awarded to the user from among "one or more objects specified based on the user operation from the operation receiving unit 26". That is, in FIG. 10, "one object specified based on the user operation from the operation receiving unit 26" among the candidate objects 29a to 29c is determined as the object to be awarded to the user. Also, in FIG. 11, based on the user operation from the operation receiving unit 26, a "population setting table including one or more objects" is specified, and an object to be awarded to the user is determined by an arbitrary method (such as lottery or user designation) from among them.

[0073] (2.2. Second Modification Example) In the second modification example illustrated in FIGS. 12 and 13, a plurality of types of first selections are provided. As an example, it is assumed that n (from the first type to the nth type) first selections are provided, where n is an arbitrary integer. These n first selections may, for example, have different corresponding object populations (that is, population setting tables used for lottery). The difference in this object population may be a difference in one or more of the object content, the number of objects, and the winning probability.

[0074] In the second modification example, after the user designates a desired first selection from these n first selections, a provision request is made. 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 the n first selections, and may display this list screen on the display unit 224 when the user is about to make a provision request. The list screen may be, for example, a screen in which the first selections of the first type to the nth type are presented by different icons, banners, name lists, etc. The user selects a specific first selection from the list on the display unit 224 and transmits a provision request from the user terminal 3. The user terminal 3 transmits, in addition to the provision request, type identification information for identifying the type of the first selection.

[0075] For example, when there is a provision request from user U01 (step S110 in FIG. 10), the provision request reception unit 21 transmits the provision request from the user terminal 3 and the type of the first selection to the first assignment unit 22a. The first assignment unit 22a confirms "for which first selection the provision request was issued" in the provision request confirmation in step S120a. For example, assume that user U01 designates "the first selection of the first type" (e.g., taps the corresponding icon, etc.) and issues a provision request. In this case, the first assignment unit 22a executes the process of "the first selection of the first type" (step S131-1) among the plurality of first selections provided for each type (steps S131-1, S131-2... S131-n corresponding to the first type, the second type... the nth type respectively). Specifically, the first assignment unit 22a performs a lottery using the population setting table pre-associated with the first selection of the first type.

[0076] In the subsequent step S132, the first assignment unit 22a adds 1 to the counter value corresponding to the type of the executed first selection. If the first selection of the first type is executed, 1 is added to the counter value cnt_i1. For each user, counter values cnt_i1 to cnt_in corresponding to the first selections of the first type to the nth type are provided. For example, if the provision requests of user U01 are concentrated on the first selection of the first type, only the counter value cnt_i1 of user U01 will become significantly large.

[0077] Thereafter, in the same manner as the sequence of FIG. 9, result registration for awarding the object selected by lottery to the user is performed (step S140). When the predetermined condition is satisfied in step S160 in the same manner as the sequence of FIG. 9, the process specific to the second modification example is performed in step S170a (second selection).

[0078] 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 the current step S160, it is specified which type of first selection was executed. Although there is no limitation on the specifying method, for example, a process of reading out the type of the first selection in which the last update (counter value addition) occurred in step S132 may be used.

[0079] Here, as an example, it is assumed that the first type of first selection (step S131-1) was executed immediately before the current step S160. In this case, the second awarding unit 22b refers to the table T8-1 corresponding to the first type of first selection among the mode selection probability tables T8-1, T8-2 ··· T8-n shown in FIG. 13. Subsequently, the second awarding unit 22b reads out 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 awarding unit 22b executes the mode selection process using the second mode selection probability weight_i1 in the same manner as step S172 (mode selection process) in FIG. 10. The processes of subsequent steps S173 to S175 and the subsequent step S180 (third selection) are the same as the sequence of FIG. 10.

[0080] According to this second modification example, when there are differences in the execution counts cnt_i1 to cnt_in of the first selections of the first type to the nth type, the differences can be reflected in the mode selection probability in the second selection. Thereby, there is an advantage that the mode selection probability can be adjusted according to the difference in the degree of user enthusiasm for each of the plurality of first selections. Although specific examples of the selection probabilities of the tables T8-1 to T8-n are shown in FIG. 13, the numerical values of the selection probabilities may be the same or different among the tables T8-1 to T8-n.

[0081] (2.3. Third Modification Example) The third modification example modifies the processes 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. 14. Thereby, the third modification example implements mode probability control according to "the number of times an object predetermined in the first selection is given".

[0082] The "predetermined object" in the third modification example may be, for example, a "low rarity object (low rarity object)". This low rarity object is a "low rarity object" predetermined in the game provided by the game providing unit 20. The "rarity" can be defined from any perspective. As an example, multiple levels of "rarity parameters" may be assigned to each object in advance. The column of this rarity parameter may be added to tables such as the object table T1 and the population setting tables T4-1 to T4-9. For example, when a three-level rarity parameter is set, objects with a rarity of 1 to 2 excluding the object with the highest rarity (rarity 3) may be set as the predetermined rarity objects. As another example, in the population setting tables T4-1 to T4-9 in FIG. 6B, objects with a high winning probability (for example, 5% to 10% or more) may be set as low rarity objects. Or, an object whose number of past wins in the first selection is equal to or more than a predetermined number may be regarded as an object that has won many times and has a low rarity value, and this may be used as the above-mentioned low rarity object.

[0083] Referring to FIG. 10, in the third modification, 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.

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

[0085] Next, the second granting 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. Thus, the number of the "low rarity value objects" may be counted.

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

[0087] In addition, as another modification example, the above "predetermined object" may be a high-rare-value object with a smaller number of grant times than a predetermined number of times, for example. Alternatively, regardless of rarity, an object arbitrarily specified by the game provider may be the "predetermined object".

[0088] (2.4. Fourth Modification Example) The fourth modification example will be described with reference to FIGS. 15 and 16. In the fourth modification example, similar to the second modification example, a plurality of types of first selections are provided. Referring to FIG. 15, the first granting unit 22a according to the fourth modification example executes one of n first selections (steps S131-1 to S131-n) in the same sequence as in FIG. 12. Subsequently, in step S132a of FIG. 15, the first granting unit 22a holds, that is, stores, the type of the most recently executed first selection. Here, as a specific example, it is assumed that step S131-1 was executed immediately before step S132a this time. In this case, the information "first type" is stored in step S132a. Subsequently, the processes of steps S140 to S160 are executed in the same manner as in FIG. 12 and the like, and it is assumed that a predetermined condition is satisfied in step S160. Further, in step S170 (second selection) after that, it is assumed that the second mode is selected.

[0089] Subsequently, referring to FIG. 16. In step S180b (third selection in the second mode), the second granting 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 out this time is "first type".

[0090] Subsequently, the second granting unit 22b determines and presents designated candidates (step S188b). In this step, the table T10 in FIG. 17 is referred to. The table T10 is an example of a table in which population IDs are pre-associated with the types of the first selection (type 1 to type n). Assume that the table T10 is preset in the object storage unit 23. For convenience, type 1 is denoted as S1A, type 2 is denoted as S1B, type 3 is denoted as S1C, ··· type n is denoted as S1N. In step S188b, the population ID is determined from the table T10 based on the type read in step S187. For example, if the type read this time is "type 1", the population ID associated with type 1 S1A is B01. In this case, the second granting unit 22b determines the object population B01 as the user designated candidate, and causes the display unit 224 to display each object of the object population B01. For example, when the user terminal 3 receives a display instruction from the second granting unit 22b, the user terminal 3 may display the object presentation screen 28 on the display unit 224.

[0091] Note that the above processing is an example, and the processing in step S188b can be variously modified. For example, it is not necessary to associate population IDs like the table T10. For example, a table in which a predetermined number of character IDs are associated with each type S1A, S1B ··· S1N may be used. Also, instead of making all the objects of each object population the user designated candidates, only some selected objects may be made the user designated candidates (the selection method in that case is also arbitrary, for example, it may be a lottery, or a regular narrowing-down process other than a lottery).

[0092] Thereafter, the second granting unit 22b determines the object designated by the user in step S182b (user operation reception) as the object to be granted to the user (step S183b).

[0093] (2.5. Fifth Modification Example) In the fifth modification example, in the second mode, an object to be given to the user is selected based on a preset rule. This is different from simple lottery or user operation specification. Specifically, in the fifth modification example illustrated in FIG. 18, in step S180b (the third selection in the second mode), processes of steps S189b1 to S189b3 (object giving according to the past giving frequency) are provided.

[0094] In step S180b of the fifth modification example, first, in step S189b1, the second giving unit 22b performs population reading. In the example of FIG. 18, an example is described in which the same object population (population B01 as an example) is read out in the object lottery in the first mode (step S181a) and the population reading in the second mode (step S189b1). However, this is just an example, and the object populations may be made different between step S181a and step S189b1.

[0095] Next, the second giving unit 22b performs play history reading and refers to the play history table (object providing result table) T5a in FIG. 19 (step S189b2). The play history table T5a1 includes an acquisition path column. In the acquisition path column, the acquisition paths of objects are separately recorded for the first selection (Select1), the third selection in the first mode (Select3_m1), and the third selection in the second mode (Select3_m2). The play history table T5a1 is updated at any time in result registration (steps S140, S190). Thereby, for example, when the current user of the providing source is user U01, the object giving history given to this user U01 by the first selection can be referred to. When the same object is given at different times, the 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.

[0096] Subsequently, the second awarding unit 22b performs awarding frequency determination (step S189b3). In the awarding frequency determination, based on the information obtained in step S189b2, the awarding frequency of each object to each user is determined. Specifically, for each user, objects with an awarding frequency (specifically, the number of awards) equal to or less than a predetermined reference frequency are extracted. The predetermined reference frequency may be, for example, zero times (never awarded) or 1 to several times (hardly awarded). 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 becomes the "minimum number of awards", and the object with the lowest awarding frequency is extracted by the awarding frequency determination. When a plurality of objects with the same awarding frequency are extracted, a further lottery may be conducted, or they may be narrowed down by other narrowing rules. The other narrowing rules may be arbitrarily determined. For example, it may be to preferentially extract the object with an earlier awarding time. Note that the awarding frequency determination may be limited to, for example, the number of awards within a predetermined period, or may be limited to the number of awards going back several months to several years in the past as an example. In that case, a "date and time of awarding column" for recording the date and time when the object was awarded may be provided in the play history table T5a1.

[0097] Next, the second awarding unit 22b determines the object extracted by the awarding frequency determination as the object to be awarded to the user (step S183b). The subsequent processing is the same as the sequence in FIG. 10 and the like.

[0098] (2.6. Sixth Modification Example) In the sixth modification example, a lottery for objects 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 example, in step S180b (the third selection in the second mode), a process of object lottery is performed (similar to step S186b in FIG. 11). However, there are differences in the lottery content between the first mode and the second mode.

[0099] As an example, in FIG. 20, in the object extraction of the first mode (step S181a in FIG. 20), the population setting table T4-1 (see FIG. 6B) is used. On the other hand, in the object extraction of the second mode (step S186b in FIG. 20), the population setting table T4-1a (see FIG. 6C) is used. Thereby, for the population to be discharged in the second mode, "objects that are not objects to be discharged in the first mode (specifically, the character C150 of the difference D1 in FIG. 6C)" can be included. This character C150 may be, for example, a highly rare and low-value object. For example, in the case of defining the rarity by a three-level rarity parameter, an object with the highest rarity (rarity 3) may be regarded as a highly rare and high-value object.

[0100] The example of FIG. 20 can be further variously modified. For example, in the object extraction of the first mode (step S181a), the population setting table T4-1 (see FIG. 6B) may be used. On the other hand, in the object extraction of the second mode (step S186b in FIG. 20), the population setting table T4-1b or T4-1c (see FIG. 6C) may be used. Thereby, both the first mode and the second mode perform extraction, but the discharge probability (winning probability) can be made different with at least one predetermined object. The winning probability may be made different only for some objects (character C120) as in the population setting table T4-1b, or the winning probability may be made different for all objects as in the population setting table T4-1c.

[0101] (2.7. Regarding mode variations) As described in the embodiment, in the second granting unit 22b, a second selection for selecting a mode from among a plurality of modes is performed. Each individual mode defines a selection method when the third selection is performed. The third selection is that the second granting unit 22b selects an object to be granted to the user in the selected mode.

[0102] In the embodiment and some modified examples, the third selection in the first mode is unified as "lottery", but the first mode is not limited to this. The first mode may be other than lottery, and for example, a plurality of first modes constructed to have the same contents as the plurality of second modes 180b exemplified in the embodiment and the first to sixth modified examples may be provided. Specifically, for example, among the plurality of processes of step S180b exemplified in Figs. 10, 11, 16, 18, and 20 (third selection of the second mode), one may be the first mode and the other may be 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 granting unit 22b may select the mode by the second selection. This can enrich the opportunities for acquiring special objects by the second granting unit 22b.

[0103] More comprehensively, the multiple modes may be differentiated from one another in one or more of the following respects. As an example, the multiple modes may be differentiated from one another in terms of "selection method", "selection target", "external influence (or absence)", "population difference", or "selection probability difference". Two or more of these respects may be arbitrarily combined to differentiate between the modes. For example, even if the selection method is the same, if the selection target is different, there is a difference between the modes. For example, even if the selection method and selection target are the same, there is a difference between the modes if there is a difference in terms of external influences, etc.

[0104] The difference in the selection method in the 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 specifies an object through user operation and selects it as the object to be given to the user. Non-user selection is a selection method in which a server, terminal, program, etc. automatically selects an object without user operation. From the user's perspective, this can be said to be passive object selection. Non-user selection may be further subdivided, and may be distinguished, for example, at least into lottery and selection by predetermined rules (i.e., rule-based selection other than lottery), and both may be used as differences between modes.

[0105] The difference in the selection target in the mode is whether only an object is selected, or whether an object is selected after selecting an object population. When there is no selection of the object population, the selection may be made from the same object population each time, but the content of that type of object population may be fixed or may be changed at any time. Even when the number of selected objects differs between modes, it is included in this difference in the selection target.

[0106] The difference in the external influence in the mode may be, for example, the difference in whether the influence of "play history" is included. Although it has been stated that there are several types of play history, the difference in the type of play history incorporated into the processing within the mode and the history accumulation period, etc., may also be regarded as a difference between modes.

[0107] The difference in the identity of the population in the mode is whether the object population is the same or different between a certain mode and other modes. If at least some of the objects are different between modes, it can be said that there is a difference in the object population between modes. For example, the identity of the object population may be distinguished step by step such as complete coincidence, partial coincidence, and complete difference (without duplication).

[0108] The difference in the winning probability of an object in the mode is whether there is a difference in the winning probability of the object between modes when the selection method is non-user selection. Specifically, it is whether there is a difference in the numerical value of the winning probability of the object, and the difference may be distinguished step by step such as complete coincidence, partial coincidence, and complete difference (without duplication).

[0109] FIG. 21 is a block diagram showing another specific example of the functional configuration of the information processing apparatus 1. As illustrated in FIG. 20, a mode storage unit 27 that stores in advance the processing of each mode may be provided. As described above, there are a wide variety of mode variations, and since three or more modes can be provided to the second granting unit 22b, in this case, the convenience is likely to be enhanced by separately providing the mode storage unit 27.

[0110] (2.8. Advantages / Disadvantages of Modes) The second mode in the above-described embodiments and some modifications may be treated as an "advantageous mode". "Advantageous" means advantageous for the user in terms of object acquisition. The advantages and disadvantages of the mode here are determined by the relative comparison between a plurality of modes that become selection candidates in the second selection.

[0111] As an example, in the embodiment (FIGS. 10 and 11) and the first modification (FIG. 11), in the second mode, an object or a table is selected according to a user instruction. 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 an object or the like as compared with the first mode.

[0112] As another example, when the object population handled in the first mode and the second mode is different as illustrated in FIG. 20, the object population of the second mode may be made advantageous for the user. Here, as an example, it is assumed that the characters C910 to C980 of the object population B09 in FIG. 6B are, on average, rarer (that is, the average granting frequency is lower) than the characters of the other object populations B01 to B08. In this case, in the second mode, the object population setting table T4-9 may be used to select an object to be granted 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 acquire high-scarce-value objects as compared with the first mode.

[0113] As yet another example, when performing a lottery in the first mode and the second mode as illustrated in FIG. 20, a winning probability that is more advantageous to the user may be set for the second mode. For example, in the population setting tables T4-1b and T4-1c of FIG. 6C, the winning probability of the character C120 is set to be 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 a mode that is advantageous to the user in that the possibility for the user to acquire a specific object is increased as compared with the first mode.

[0114] As yet another example, as illustrated in FIG. 18, in the second mode, objects may be selected so as to be less likely to overlap with objects that have already been acquired by the user. Such a second mode can also be said to be a mode that is advantageous to the user as compared with the first mode in that there is a high possibility that overlapping objects are unnecessary for the user.

[0115] (2.8. Other Modifications) In the embodiment and each modification, the second selection performed by the second granting unit 22b is, as an example, a lottery using a mode selection probability table, but is not limited thereto. The second selection may be configured such that the second granting unit 22b selects a mode based on a predetermined selection rule other than lottery. As an example of the predetermined selection rule, for example, when the play history satisfies a predetermined selection condition, the second mode may be selected, and when not, the first mode may be selected. This predetermined selection condition can be set in various ways. As an example, it may be whether or not it is within a predetermined period after clearing a certain specific quest, or as another example, whether or not it is within the holding period of a certain specific event.

[0116] The present invention can also be realized as a program that causes a server to function to realize the above-described information processing apparatus 1.

[0117] Furthermore, the present invention can also be realized as a computer-readable non-transitory recording medium that stores the above-described program.

[0118] <3. Features of Embodiments and Variations> The features of the embodiments and variations of the present invention may be summarized as follows (1) to (11).

[0119] (1) In one aspect of the present invention, an information processing apparatus 1 including a first granting unit 22a and a second granting unit 22b is provided. The first granting unit 22a makes a first selection (object extraction). The second granting unit 22b makes a second selection (mode selection) and a third selection (object selection). By providing a plurality of types of modes (first mode, second mode) for the second selection, it is possible to provide the user with an opportunity to receive an object in different modes. As a result, the special object acquisition opportunity by the second granting unit 22b can be made more diverse.

[0120] (2) Based on the user's play history (see FIGS. 7A to 7C, etc.), the selection probability of each mode in the second selection may be set (see FIGS. 8A to 8C, FIG. 13, etc.). As a result, the selection probability of the mode can be associated with the play history, so there is an advantage that the special object acquisition opportunity becomes even more diverse. In order to receive an object in an advantageous mode, the motivation to play the game can also be enhanced.

[0121] (3) The second granting 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). As a result, each time the second selection is made, the selection frequency of each mode can be adjusted, so there is an advantage that the special object acquisition opportunity becomes even more diverse.

[0122] (4) When the second mode is selected in the second selection, the second granting unit 22b may reduce the added amount in the probability control setting. Specifically, as an example, by resetting the counter value cnt_m in step S175 of FIG. 10, the second mode selection probability in the mode selection probability table may be returned to the minimum probability. As a result, the probability can be adjusted so that the second mode is not selected too frequently.

[0123] (5) The second imparting unit 22b may set the probability of each mode being selected in the second selection according to the number of executions of the first selection (counter value cnt_i) (see FIG. 8B). Thereby, since the selection frequency of each mode can be adjusted every time the first selection is made, there is an advantage that the special object acquisition opportunity becomes more diverse.

[0124] (6) As illustrated in the second modification of the embodiment (see FIGS. 12 and 13), the second imparting unit 22b may set the probability of each mode being selected in the second selection when a predetermined condition (step S160) is satisfied in the execution of each of the n types of first selections according to the number of executions of each of the n types of first selections (counter values cnti1 to cnt_in in FIG. 12). When there are differences in the number of executions of each of the first selections, the differences can be reflected in the probability of each mode being selected in the second selection. Thereby, the probability of each mode being selected can be adjusted according to the difference in the degree of user enthusiasm for each of the plurality of first selections.

[0125] (7) As illustrated in the third modification of the embodiment (see FIG. 14), the second imparting unit 22b may set the probability of each mode being selected in the second selection according to the number of times (counter value cnt_clr) that a predetermined object is imparted in the first selection. Thereby, the selection tendency of the mode in the second selection can be adjusted according to the imparting frequency of the predetermined object in the first selection.

[0126] (8) As described in the above "Advantage / Disadvantage of the Mode", in the embodiment and some modifications, the second imparting unit 22b may select the second mode as a mode that is more advantageous for the user in obtaining an object than the first mode. By including a plurality of relatively disadvantageous / advantageous modes, there is an advantage that the special object acquisition opportunity becomes more diverse.

[0127] (9) In the second giving unit 22b, in the second mode (see, for example, step S180b in FIG. 10 or FIG. 11), an object to be given to the user by a third selection may be selected from among one or more objects specified based on a user operation (operation receiving unit 26). Further, in the first mode (step S180a), the second giving unit 22b may select an object to be given to the user by a third selection from among one or more objects determined without depending on a user operation. Since the user can participate in the selection of an object in the second mode, the difference from the first mode becomes clear, and there is an advantage that a special object acquisition opportunity becomes more diverse.

[0128] (10) As illustrated in the fourth modification example of the embodiment (see FIGS. 15 to 17), the first giving unit 22a may execute n types of first selections in which the candidate objects for selection are different from each other. Further, the second giving unit 22b may present an object that becomes a designation candidate for a user operation in the second mode to the user according to the first selection executed when a predetermined condition is satisfied (step S160) among the n types of first selections (step S188b). Thereby, when the user issues a provision request for a specific type of first selection, a designation candidate object associated with the specific type of first selection can be presented. Therefore, there is an advantage that it becomes easy to provide an object that the user is likely to want as a designation candidate.

[0129] (11) As illustrated in the fifth modification example of the embodiment (see FIGS. 18 and 19), the second giving unit 22b may select an object by performing a lottery from among an object population in the first mode. Further, in the second mode, the second giving unit 22b may select an object to be given to the user that belongs to the same object population as in the first mode and whose giving frequency in the past first selection is equal to or lower than a predetermined criterion (steps S189b1 to S189b3 in FIG. 18). Thereby, there is an advantage that it becomes easy to preferentially provide an object that is difficult to acquire by a first selection to a certain user.

[0130] (12) In another aspect of the present invention, a program is provided that causes a computer to select an object. This program causes the computer to execute a first selection for selecting an object to be given to the user, causes the computer to execute a second selection for selecting a mode from a plurality of different modes for the user for whom a predetermined condition is satisfied by the execution of the first selection, and causes the computer to execute a third selection for selecting an object to be given to the user in the mode selected by the second selection.

[0131] (13) In another aspect of the present invention, an information processing method is provided. In this information processing method, the computer makes a first selection for selecting an object to be given to the user, the computer makes a second selection for selecting a mode from a plurality of different modes for the user for whom a predetermined condition is satisfied by the execution of the first selection, and the computer makes a third selection for selecting an object to be given to the user in the mode selected by the second selection.

[0132] Although various embodiments of the present invention have been described, these are presented as examples and are not intended to limit the scope of the invention. The novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. The embodiments and their modifications are included in the scope and gist of the invention and are included in the invention described in the claims and its equivalent scope.

Explanation of Reference Numerals

[0133] 1: Information processing apparatus 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 providing unit 20a: Game information storage unit 21: Provision request reception unit 22: Object Assignment Unit 22a: First Assignment Unit 22b: Second Assignment Unit 23: Object Memory Unit 24: Play History Table 24: Play History Memory Unit 25: Probability Data Memory Unit 26: Operation Reception Unit 27: Mode Memory Unit 28: Object Presentation Screen 29a, 29b, 29c: Candidate Objects 30: Object Display Area 221: Control Unit 222: Memory Unit 223: Communication Unit 224: Display Unit 225: Speaker 226: Microphone 227: Camera 228: Operation Button

Claims

[Claim 1] An information processing device including a first assigning unit and a second assigning unit, The first assignment unit performs a first selection to select an object to be assigned to a user; the second granting unit performs a second selection of selecting a mode from a plurality of different modes for the user for whom a predetermined condition is satisfied in the execution of the first selection, The information processing device performs a third selection to select an object to be given to the user in the mode selected in the second selection.

Images