JP2020127849A - Information processing device, program, and information processing system - Google Patents

Abstract

To eliminate anxiety felt by a user when acquiring a reference object.SOLUTION: An information processing device acquires a change condition corresponding to a selection object from a storage device, outputs first output data for displaying a plurality of objects to a user in respectively identifiable display formats by using information showing the plurality of objects included in the change condition, receives an instruction to designate one of the plurality of objects through an operation by the user in accordance with the output of the first output data, acquires information showing a designation object in the case where the user does not own the designation object, and outputs second output data for displaying an acquisition condition of the designation object by using the information showing the designation object.SELECTED DRAWING: Figure 15

Description

The present invention relates to information processing technology for processing information about objects.

In recent years, a so-called social game has become widespread as an application executed in a social networking service (SNS). A digital card game using a card is known as such a social game.
Also, the main card and sub card are selected by the user from among the cards owned by the user, and the ability parameter of the main card is changed by combining the main card and the sub card, and the sub card is changed from the card owned by the user. There are known games to be deleted (Patent Documents 1 and 2).

Japanese Patent No. 5086491 Japanese Patent No. 5153960

In the combining process, the user possesses a plurality of reference objects (corresponding to the above sub-cards) satisfying the combination condition corresponding to the base object in order to realize the combining process of the base object (corresponding to the above main card). May be a requirement. In that case,
The user needs to have all the reference objects that satisfy the combination condition in order to execute the combining process.

At this time, it may be impossible or difficult for the user to obtain the reference object that the user does not have. However, a user who does not know the acquisition condition of the reference object recognizes that the acquisition of the reference object is impossible or difficult at the time of deciding whether to execute the process for acquiring the reference object. Can not. In such a case, the user executes the process for acquiring the reference object while having a fear that the reference object may be impossible or difficult to acquire.

The present invention has been made in view of the above-described viewpoint, and an object thereof is to provide a reference object required for a process of changing an object, which is executed when a change condition including information indicating at least a plurality of objects is satisfied. An object is to provide an information processing device, a program, and an information processing system that eliminate the anxiety felt by the user in the process for obtaining.

One aspect of the present invention is
In an information processing device that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for the process of changing the object in association with each other,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Output means for outputting output data,
Receiving means for receiving an instruction for designating one of the plurality of objects based on the instruction of the user in response to the output of the first output data by the output means,
When the user does not have the designated object designated by the instruction received by the receiving unit, the output unit further outputs second output data for displaying the acquisition condition of the designated object. Output,
It is an information processing device.

Another aspect of the invention is
In an information processing device that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for the process of changing the object in association with each other,
A plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object that is the selected object based on the instruction of the user, and the user owns the plurality of objects. The information processing apparatus is provided with an output unit that outputs output data for displaying the acquisition conditions of the objects that have not been displayed and the display conditions in which the user can display the respective display conditions.

Another aspect of the invention is
In an information processing device that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for the process of changing the object in association with each other,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Output means for outputting output data,
Receiving means for receiving an instruction for designating one of the plurality of objects based on the instruction of the user in response to the output of the first output data by the output means,
The output unit further outputs a second output for displaying the degree of difficulty of obtaining the designated object when the user has never owned the designated object that is the object designated by the instruction received by the receiving unit. Output data,
It is an information processing device.

Another aspect of the invention is
A user terminal and a server configured to be communicable with the user terminal, and object identification information for specifying an object, and a change condition including a plurality of object identification information used for a process of changing the object. An information processing system capable of accessing a storage device which is associated and stored,
Either of the user terminal and the server,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Output means for outputting output data,
Receiving means for receiving an instruction for designating one of the plurality of objects based on the instruction of the user in response to the output of the first output data by the output means,
When the user does not have the designated object designated by the instruction received by the receiving unit, the output unit further outputs second output data for displaying the acquisition condition of the designated object. Output,
It is an information processing system.

Another aspect of the invention is
A computer that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used in a process of changing the object in association with each other,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Means for outputting output data,
A unit that receives an instruction to specify any one of the plurality of objects based on an instruction from the user in response to the output of the first output data;
If the user does not have the designated object which is the object designated by the received instruction, the second display for displaying the acquisition condition of the designated object.
Means for outputting output data,
It is a program to function as.

Another aspect of the invention is
In an information processing device that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for the process of changing the object in association with each other,
A first output that outputs first output data for displaying acquisition conditions of a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to object identification information of a selected object that is a selected object Means and
In response to the output of the first output data by the first output means, a request for restricting the first designated object, which is the object designated by the user, from being used for a predetermined process is issued. First receiving means for receiving,
First restricting means for restricting the first designated object from being used for the processing in response to the request being accepted by the first accepting means,
An information processing apparatus including:

Another aspect of the invention is
A user terminal and a server configured to be communicable with the user terminal, and object identification information for specifying an object, and a change condition including a plurality of object identification information used for a process of changing the object. An information processing system capable of accessing a storage device which is associated and stored,
Either of the user terminal and the server,
A first output that outputs first output data for displaying acquisition conditions of a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to object identification information of a selected object that is a selected object Means and
In response to the output of the first output data by the first output means, a request for restricting the first designated object, which is the object designated by the user, from being used for a predetermined process is issued. First receiving means for receiving,
First restricting means for restricting the first designated object from being used for the processing in response to the request being accepted by the first accepting means,
An information processing system including:

Another aspect of the invention is
A computer that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used in a process of changing the object in association with each other,
Means for outputting first output data for displaying the acquisition condition of the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object,
Means for accepting a request for restricting the first designated object, which is the object designated by the user, from being used in a predetermined process in response to the output of the first output data;
Means for restricting the first designated object from being used for the processing in response to the request being accepted,
It is a program that functions as.

The figure which shows the basic composition of the game system of 1st Embodiment. The block diagram which shows the structure of the user terminal of 1st Embodiment. The block diagram which shows the structure of the game server of 1st Embodiment. The figure for notionally explaining the presentation of the acquisition condition of the reference card of the first embodiment. The figure which shows the structural example of the card data table of 1st Embodiment. The figure which shows the structural example of the evolution synthetic|combination data table of 1st Embodiment. The figure which shows the structural example of the quest data table of 1st Embodiment. The figure which shows the structural example of the possession card data table of 1st Embodiment. The figure which shows the structural example of the reservation data table of 1st Embodiment. The figure which shows the structural example of the possession history data table of 1st Embodiment. The figure which shows the structural example of the card distribution data table of 1st Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 1st Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 1st Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 1st Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 1st Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 1st Embodiment. The functional block diagram of the game server of 1st Embodiment. The sequence chart which shows an example of the presentation processing of the acquisition conditions of a 1st embodiment. The sequence chart which shows an example of the presentation processing of the acquisition conditions of a 1st embodiment. 3 is a sequence chart showing an example of evolutionary synthesis processing according to the first embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 2nd Embodiment. The sequence chart which shows an example of the quest process of 2nd Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 3rd Embodiment. The sequence chart which shows an example of the reservation process of the evolutionary synthesis of 3rd Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 4th Embodiment. The sequence chart which shows an example of the presentation processing of the acquisition conditions of a 4th embodiment. FIG. 16 is a diagram conceptually illustrating reservation registration and favorite registration of a reference card according to the fifth embodiment. The figure which shows the structural example of the possession card data table of 5th Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 5th Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 5th Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 5th Embodiment. The figure which shows an example of the image displayed on a user terminal at the time of execution of the game of 5th Embodiment. The sequence chart which shows an example of the processing of registration of a 5th embodiment. The sequence chart which shows an example of the presentation processing of the acquisition conditions of a 6th embodiment. The sequence chart which shows an example of the presentation processing of the acquisition conditions of a 6th embodiment.

(1) First Embodiment (1-1) Configuration of Game System A game system 1 will be described below as an embodiment of an information processing system.

FIG. 1 shows a system configuration example of a game system 1 of the embodiment. As shown in FIG. 1, the game system 1 includes user terminals 10a, 10b, 10c,... And a game server 20. The game server 20 can be accessed from each user terminal 10a, 10b, 10c through a communication network NW such as the Internet. The game server 20 is an example of an information processing device.
Each of the user terminals 10a, 10b, 10c,... Is a terminal operated by an individual user, and includes, for example, a feature phone, a smartphone, a tablet terminal, a personal computer, and a television receiver ( So-called multifunctional smart TVs are also included.), and communication terminals such as portable game machines with communication functions. In the following description, when the user terminals 10a, 10b, 10c,... Are referred to in common, they are referred to as the user terminal 10.

The game server 20 is a server that executes a game. The game server 20 stores image data that can be interpreted by a web browser (for example, image data described in a format such as HTML or XML. In the embodiment of the present invention, HTML data will be described as an example). A program that can be created is implemented.
The user terminal 10 includes a web browser that interprets and displays the HTML data provided by the game server 20, and a request based on a user's operation on a web page by the user terminal 10 is issued via the network to the game server 20. To the game server 20
The game processing is executed by receiving the processing result of.
The communication network NW includes the Internet, WAN (Wide Area Network), and LAN (Local Area).
Network), a leased line, or an information communication network composed of a combination of these.

(1-2) Configuration of User Terminal The user terminal 10 will be described with reference to FIG.
As shown in FIG. 2, the user terminal 10 includes a CPU (Central Processing Unit) 11, R
An OM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an operation input unit 15, a display unit 16, a communication interface unit 17, and a storage 18 are provided, and control signals or data signals between each unit are transmitted. A bus 19 is provided for this purpose.

The CPU 11 reads out programs and data stored in the ROM 12 and controls the entire operation in the user terminal 10, such as timing processing of control signals and data signals with each unit in the user terminal 10. The CPU 11 also reads a program stored in the storage 18 and various data necessary for executing the program, expands the data in the RAM 13, and performs various processing such as data input/output processing, arithmetic processing, and determination processing accompanying the execution of the program. I do. The RAM 13 temporarily stores data for arithmetic processing, determination processing, etc. by the CPU 11.

For example, the CPU 11 loads the web browser stored in the storage 18 into the RAM 1
Load to 3 and run. Then, the CPU 11 uses the operation input unit 15 or the like to specify the URL (Uniform Resource Locator) that is input to the user by the communication interface unit 17.
Data for displaying a web page from the game server 20 via the Internet, that is, HT
Data of an object such as an ML (Hyper Text Markup Language) document or an image associated with the document (hereinafter collectively referred to as "HTML data" as appropriate) is acquired via the communication interface unit 17, and a web browser is used. To interpret the HTML data. Note that various plug-ins for expanding the browser function of the web browser may be mounted on the user terminal 10. One example of such a plug-in is a flash player by Adobe Systems Incorporated in the United States. Alternatively, the HTML data in this embodiment may be in the HTML5 format having a moving image and audio reproducing function.

The web browser communicates with the game server 20 according to HTTP (HyperText Transfer Protocol). When the user selects a URL (Uniform Resource Locator) on the web page or an operation target (for example, a software button (hereinafter, simply referred to as “button”) or the like), the web browser operates the operation input unit 15. , Sends an HTTP request including the selection result to the game server 20 for updating the web page. The web browser acquires the HTML data from the game server 20 as an HTTP response,
Interpret and display the web page on the display unit 16.

The display unit 16 is, for example, an LCD (Liquid Cristal Display) or an organic EL (Electro Lumin).
(escence) display device such as a display. When an LCD (Liquid Cristal Display) monitor including thin film transistors arranged in a matrix in a pixel unit is applied, the display unit 1
6 drives the thin film transistor to display the image of the web page on the display screen.

When the user terminal 10 is a button input type user terminal, the operation input unit 15 includes, for example, a plurality of instruction input buttons such as a direction instruction button for accepting a user's operation input, an enter button, and a numeric keypad. It includes an interface circuit for recognizing a press (operation) input of and outputting it to the CPU 11.
When the user terminal 10 is a touch panel input type user terminal, the operation input unit 15
It mainly accepts touch panel type input by touching the display screen with a fingertip or a pen.

The storage 18 is a storage device including, for example, a flash memory or an HDD (Hard Disk Drive).

(1-3) Configuration of Game Server The configuration of the game server 20 will be described with reference to FIG.
As shown in FIG. 3, the game server 20 includes a CPU 21, a ROM 22, a RAM 23, a communication interface unit 24, and a storage 25, and is provided with a bus 26 for transmitting a control signal or a data signal between the units. ing. The game server 20
The hardware can have the same configuration as a general-purpose network server.

The CPU 21 reads out programs and data stored in the ROM 22 and controls the entire operation in the game server 20, such as timing processing of control signals and data signals with each unit in the game server 20. The CPU 21 also reads the program stored in the storage 25 and various data necessary for executing the program, expands the data in the RAM 23, and performs various processing such as data input/output processing, arithmetic processing, and determination processing accompanying the execution of the program. I do. RAM2
3 temporarily stores data for arithmetic processing, determination processing, etc. by the CPU 21.

For example, the storage 25 stores a program that provides a web service by performing HTTP communication with the web browser of the user terminal 10 that is a client. The CPU 21 expands the program stored in the storage 25 in the RAM 23 and executes the program. With the execution of the program, the CPU 21 acquires the HTTP request from the user terminal 10 via the communication interface unit 24, executes the process according to the HTTP request, and includes the HTML data including the execution result (image data described later). One example) is returned to the user terminal 10 as an HTTP response.

The storage 25 is an information recording device including, for example, a flash memory or an HDD (Hard Disk Drive), and stores a data table group 70 in addition to the above-mentioned program. The data table group 70 (which will be described later) includes a card data table, an evolution combined data table, a quest data table, a possessed card data table, a reservation data table, a possessed history data table, and a card distribution data table. Each data table is appropriately accessed by the CPU 21 for reading and writing data.

(1-4) Presentation of Card Acquisition Conditions for the Game of the Present Embodiment The game executed in the game system 1 of the present embodiment is a game executed by the user using the card as an object. In this game, for example, a user searches an area on the game to obtain cards or items, or uses a card possessed by the user to compete with another user or an NPC (Non-Player Character).
In the game of the present embodiment, the card evolution synthesis process (hereinafter, simply referred to as “evolution synthesis” as appropriate) is a process of evolution of a card possessed by a user when a predetermined condition is satisfied. The card evolution synthesis is a process of changing a card ID as described later in the example of the present embodiment, but may be a process of changing at least a part of card data (described later) corresponding to the card. In this case, the target for changing the card data is not particularly limited, but is, for example, a card parameter such as a card name, a card image, or rarity. Card evolution synthesis is an example of a process for changing an object.
To execute evolutionary synthesis, the user must own a card (hereinafter referred to as "possessed card" as appropriate).
Say. ), select the base card as the card you want to evolve (that is, the card that is the target of the process that changes the card data). The card selected as the base card is an example of a selection object.
In evolutionary synthesis, a combination condition of a plurality of cards (referred to as "reference card") necessary for evolving the base card is determined for each base card. When the evolutionary synthesis is executed, the reference card used for the evolutionary synthesis disappears from the user's possession card.
In the game of the present embodiment, the fact that the user has all of the plurality of reference cards that are the combination conditions corresponding to the card selected as the base card by the user is a condition for evolving the selected card ( It is an example of changing conditions).

In addition, in the game of the present embodiment, for example, a normal combining process and a selling process are provided as processes for the user to lose his or her own card. In order to execute the normal synthesizing process, the user selects a base card as a card to be grown from his or her own cards. In the normal composition process, the change condition that defines the condition for performing the process of changing the card (for example, the evolutionary composition process) is not determined for each base card, and the user appropriately selects the reference card from the possession cards. You can choose. When the normal combining process is executed, the reference card disappears from the user's possession card, instead of changing the card parameter of the base card (for example, increasing the card level or the skill level).
In the sale processing, a card selected from the cards owned by the user (for example, a card that the user does not need) is sold instead of the user obtaining a sale price (for example, points in the game) corresponding to the card. The created card disappears from the user's possession card.

In the game of the present embodiment, consider a case where the user wants to evolve a desired card by evolutionary synthesis, but the user does not possess some or all of the reference cards required to evolve the card. In this case, it is necessary to wait until the user obtains a new card (that is, the remaining reference cards) that satisfies the condition of the combination of the reference cards, and to perform the evolutionary synthesis of the desired card. However, if the user forgets the conditions for obtaining the remaining reference cards (hereinafter referred to as “acquisition conditions”), it becomes difficult to obtain the reference cards. In particular, the greater the number of cards obtained, the higher the possibility of forgetting the acquisition conditions for each card.
Therefore, in the present embodiment, it is possible to present the acquisition condition of a reference card (unowned card or unknown card) that is not possessed by the user among the plurality of reference cards required to evolve the base card. The uncarried card is a card that has been carried by the user and is not owned by the user when the base card is selected. on the other hand,
An unknown card is a card that has never been carried by the user.

The presentation of the reference card acquisition conditions will be specifically described with reference to FIG. FIG. 4 is a diagram for conceptually explaining the presentation of the acquisition condition of the reference card.
In FIG. 4, consider a case where the user wants to evolve the card Q, which is his own card. Here, in order to evolve the card Q, the cards A, B, C as a plurality of reference cards are used.
Assume that a combination of is required. Since the user does not currently have the card B, the evolutionary synthesis cannot be executed on the card Q. Moreover, since the user has forgotten the conditions for obtaining the card B, it is difficult to obtain the card B. In this case, in this embodiment, the acquisition condition of the card B is presented to the user in response to the request to present the acquisition condition of the card B so that the user can easily acquire the card B. As a result, the user can easily obtain the card B.

(1-5) Structure of Data Table Next, a card data table stored in the storage 25 of the game server 20, an evolution combination data table, a quest data table, a possessed card data table, a reservation data table, a possession history data table, and , Card distribution data table, Figure 5
11 will be described in order.

(I) Card Data Table The card data table has recorded therein the data of the cards used in the game of the present embodiment. FIG. 5 shows a configuration example of the card data table. In the example shown in FIG. 5, the card ID
Each includes a card name, a card image, and card parameter data.
The card ID is identification information that identifies a card that is an example of an object. Card I
D is uniquely assigned to each card. One card is specified from the plurality of cards by the card ID. That is, the card ID is an example of object identification information that identifies an object.
The card name is a character string indicating the name of the character displayed on the card. The card image is an image of a character displayed on the card. The card parameter is composed of data of rarity, attribute, cost, skill, sale price, attack power, defense power, and limited flag.
The rarity is an index showing the rarity value of the card, and in the example shown in FIG. 5, the rarity is set high in the order of R1 to R5.
The attribute is the attribute of the character displayed on the card, and is any one of N1 to N3 in the example shown in FIG.
The cost is the value referenced when incorporating the card into the user's card team. For example, when a match is played by a card team, the total cost of the cards included in the card team is limited to a predetermined value or less.
Skills are information indicating advantageous effects when playing a game using cards,
In the example shown in FIG. 4, skills having various effects of SK1 to SK12 are set for each card. Note that not all cards need to have skills.
The selling price is a point in the game that the user can obtain when selling the card that the user owns.
Attack power and defense power are parameters that are referred to when a card is used in a battle.
The limited flag is a flag indicating whether or not the card is issued for a limited period of time. In the example shown in FIG. 4, a card with a limited flag of “1” means that the card is issued for a limited period of time, and a card with a limited flag of “0” means that the card is not a limited period of time. To do.

(Ii) Evolutionary Synthesis Data Table The evolutionary synthesis data table records the conditions for evolutionary synthesis of the cards of the game of this embodiment. FIG. 6 shows a configuration example of the evolutionary synthesis data table. In the example shown in FIG. 6, the pre-evolution card ID (that is, the card ID of the card that is the base card before the evolution) and the post-evolution card ID (of the base card The card ID after the evolution) and the card ID change conditions (5 reference cards in the columns C1 to C5) of the reference card necessary for executing the evolution synthesis are recorded. For example, evolution ID: 000
Under the condition indicated by 2, the user selects the card with the card ID: 0072 from the possessed cards as the base card, and the card ID: 0025, 0060, 00 in the possessed card of the user.
When there is a combination of three cards 70, the card with the card ID: 0072 can be evolved into the card with the card ID: 9072 by executing evolutionary synthesis.
Here, as an example of a process of changing an object, a process of card evolution synthesis, which is an example of an object, will be described. As described above, the card ID is an example of object identification information. That is, FIG. 6 shows that the change condition includes a plurality of pieces of object identification information used in the process of changing the object.
Note that the same card ID may be recorded in at least any two of the columns C1 to C5 indicating the combination of the card IDs of the reference cards. For example, two or more identical reference cards may be included in the combination of reference cards used when the base cards are evolutionarily synthesized. Card I with the same reference card combination conditions for evolving the base card
If a predetermined number of reference cards D are included, the data format may not be the data format as shown in FIG.

(Iii) Quest Data Table In the quest data table, data of a quest, which is one of the events performed in the game of this embodiment, is recorded. The quest is to get cards and items
This is an event in which a user searches an area in the game to achieve a predetermined quest condition. FIG. 7 shows a configuration example of the quest data table. In the example shown in FIG. 7, area name, physical strength, information about available cards (card ID and acquisition rate), information about available items (item ID and acquisition rate), boss ID for each quest ID
, And quest UI data are included.
The area name is a character string indicating the name of the area used in the quest.
The consumed physical strength is a value referred to when performing the quest. In order to carry out the quest, the value of the physical strength, which is one of the parameters of the user, needs to be equal to or more than the value of the consumed physical strength. When the quest is carried out, the physical strength value of the user is consumed by the consumption physical strength value.
The information about the available cards (acquired card data 1, 2...) Is composed of the card ID and the acquisition rate. The card ID is identification information of a card that can be obtained when the quest condition is achieved. The acquisition rate is a numerical value indicating the probability of acquiring a card when the quest condition is achieved.
The information on the available items (acquired item data 1...) Is composed of the item ID and the acquisition rate. The item ID is identification information of an item that can be obtained when the quest condition is achieved. The acquisition rate is a numerical value indicating the probability that an item can be acquired when the quest condition is achieved.
The boss ID is identification information of an NPC (for example, a boss character) that is an opponent in the quest. The quest condition is achieved, for example, by winning the battle with the boss character.
The quest UI data is data of a user interface used in the quest (for example, image data used in the quest).

(Iv) Possession Card Data Table The Possession Card Data Table records the information of the possession card of the user. FIG. 8 shows a configuration example of the possessed card data table. Although the possession card data table for one user is illustrated in FIG. 8, the possession card data table is provided corresponding to all the users registered in the game.
In the possessed card data table shown in FIG. 8, each data of a serial number, a card level, a skill level, and a reservation ID is associated and recorded for each card ID.
The serial number is a unique number determined when the card is given to the user. Different serial numbers are given to cards having the same card ID. When the card has evolved, the serial number may or may not be changed before and after the evolution of the card.
The card level is a parameter indicating the card raising level, and is increased by executing the above-mentioned normal synthesis, for example. The card level value (initial value) at the time when the user obtains the card is 1, and the user can grow the card (that is, increase the card level) by normally performing composition or the like.
The skill level is a parameter indicating the level of raising a card, and particularly a parameter indicating the skill level of the card. The value of the skill level (initial value) at the time when the user obtains a card equipped with the skill is 1, and the skill level of the card is increased by performing a normal synthesis using a card satisfying a predetermined condition as a reference card, for example. Can be made. As the skill level of the card increases, the effect produced by the skill increases.
The reservation ID is identification information for identifying the reservation content for evolutionary synthesis. A reservation ID is associated with the possessed card of the user who is the reserved card. For example, the example shown in FIG. 8 indicates that the five cards with card IDs: 0591,0010 (two), 0033, and 2005 are reserved cards. The reservation ID recorded in the possession card data table corresponds to the reservation ID recorded in the reservation data table described later.

(V) Reserved data table The reserved data table records information on reserved cards for the user's evolutionary synthesis. FIG. 9 shows a configuration example of the reservation data table. Although the reservation data table for one user is illustrated in FIG. 9, the reservation data table is provided for all users registered in the game.
In FIG. 9, the reservation ID is an ID issued in the order in which the evolutionary synthesis reservation is made. Figure 9
In the example shown in, the numbers are recorded in ascending order such as 01, 02,.... The evolution ID corresponds to the evolution ID shown in the evolutionary synthesis data table and identifies the content of the evolutionary synthesis.
Is.
Among the serial numbers of the reserved cards, the serial number of the pre-evolution card is the serial number of the possession card selected by the user as the base card for evolution synthesis. Of the serial numbers of the reserved cards, the columns C1 to C5 of the reference card correspond to the columns C1 to C5 constituting the combination of the reference card IDs of the evolutionary synthesis data table, respectively.
When the reserved reference card is the possession card, the serial number of the possession card data is recorded in the column corresponding to the card ID of the reference card. If the reserved reference card is a non-possession card, a temporary serial number (for example, “00000000”) is recorded in the column corresponding to the card ID of the reference card, and the reference card becomes the possession card (that is, ,
After the possession card data specified by the card ID and serial number of the reference card is added), the temporary serial number is rewritten to the serial number of the reference card. Data indicating "no reservation" (for example, NULL) is recorded in the column corresponding to the card ID of the reference card that has not been reserved.
It should be noted that the case where the reservation data table is provided will be described below, but it is not essential to provide the reservation data table independently. As a reservation management method for evolutionary synthesis,
The data to be recorded in the reservation data table may be recorded in the possession card data table. In that case, in the possessed card data table, the reservation ID, the evolution ID, and any one of the character strings of C1 to C5 (corresponding to the columns of C1 to C5 in the evolution combined data table are associated with the card ID of the reserved card). Any character string that does.) is recorded.

(Vi) Possession history data table In the possession history data table, information on cards that the user has possessed is recorded. FIG. 10 shows a configuration example of the possession history data table. Although the possession history data table for one user is illustrated in FIG. 10, the possession history data table is provided for all users registered in the game.
In the possession history table shown in FIG. 10, the number of acquisitions is associated with each card ID and recorded. The number of acquisitions is a value indicating the number of times the user has acquired a card in the game. A card that has been acquired zero times is an unknown card.

(Vii) Card Distribution Data Table The card distribution data table stores information about cards distributed in the game. FIG. 11 shows a configuration example of the card distribution data table. In the example shown in FIG. 11, the card circulation data table records the number of circulations and the average transaction price for each card ID.
The number of circulations is a value indicating the total number of cards set by the user in the game as cards to be traded (for example, bought and sold). The greater the number of circulations, the lower the difficulty of obtaining the card.
The average transaction price is an average value of prices when trading cards between users. The higher the average transaction price, the higher the difficulty of obtaining the card.

In the following description, information associated with the card ID in the card data table, the quest data table, the possessed card data table, the possessed history data table, and the card distribution data table (for example, card name, card image, card parameter, Quest ID, area name, physical strength, acquisition rate, boss ID, quest UI data, serial number,
The card level, skill level, reservation ID, acquisition count, circulation count, and average transaction price) are collectively referred to as "card data" as appropriate. Card data is an example of information indicating an object.

(1-6) Specific Examples of Acquisition Condition Presentation Process and Evolutionary Synthesis Process Hereinafter, specific examples of the game card acquisition condition presentation process and the evolutionary synthesis process of this embodiment will be described with reference to FIGS. 12A, 12B, and 13A. This will be described with reference to FIGS. 13B and 14. 12A, FIG. 12B, FIG. 13A, FIG. 13B, and FIG. 14 are diagrams each showing an example of a screen displayed on the user terminal 10 when executing the game process of the present embodiment.

(1-6-1) Acquisition condition presentation process (1-6-1-1) Unacquired card acquisition condition presentation process (FIGS. 12A and 12B)
12A and 12B show a series of changes in the display screen of the acquisition condition presentation process for presenting the acquisition conditions of the uncarried card. In FIG. 12A, an image P1 is an image when the user makes a processing request for a monster card (hereinafter, simply referred to as “card”) in the game of the present embodiment. In the image P1, as a user's operation target, a button b1 (“view a possessed monster”), a button b2 (“team formation”), a button b3 (“normal composition”), a button b4 (“evolution composition”), a button b5 (“sale”) is provided.
The button b1 is a button operated when making a request for a process of browsing the possessed card of the user. The button b2 is a button operated when the user selects a card to be used in a battle with another user or an NPC from among his or her own cards. The button b3 is a button operated when the user makes a request for normal combining processing of a card selected as a base card from among possessed cards. The button b4 is a button operated when the user makes a request for evolutionary synthesis processing of a card selected as a base card from among possessed cards. The button b5 is a button operated when the user makes a request for sale processing to a card selected from the possessed cards.

When the button b4 (“evolutionary synthesis”) in the image P1 is operated, the image changes as shown in P2. In the image P2, a plurality of possession cards are displayed in a list in order to select one of the possession cards of the user as a base card. The image is configured so that cards that cannot be evolved (cards TOM, TED, DSG in the illustrated example) cannot be selected as base cards. That is, in the image P2, of the cards possessed by the user, a card that can be evolved and a card that cannot be evolved are shown in a display format in which the user can identify. The method of displaying the evolveable card and the non-evolvable card in a display format in which the user can identify is not limited to the example shown in the image P2 of FIG. 12A. The list of possessed cards may be a list of character strings of the card name of each card, in which case it is possible to distinguish between evolveable cards and non-evolvable cards by the brightness, size, etc. of the strings. May be.
When the card KLM, for example, is selected as one of the evolveable cards in the image P2, the image changes as shown in P3. In the image P3, a button b6 (“select”) for confirming the selected card as the base card for evolutionary synthesis, and a button b7 for returning to the image P2 and selecting another card as the base card (“return”). )) and.
When the button b6 is operated in the image P3, the card K selected as the base card
If the condition of the reference card necessary for the LM to evolve is not satisfied, the image is updated as shown in P4. The image P4 is an image for requesting the presentation of the acquisition conditions of the unowned card among the reference cards necessary for the card KLM selected as the base card to evolve. When the user selects the button b6 in the image P3 and the condition of the reference card necessary for evolution of the card KLM selected as the base card is satisfied, the evolution synthesis of the card KLM is executed. An image (not shown) for requesting is displayed.

In the image P4, a display area 101 showing a pre-evolution card (here, a card KLM that is a base card) and a post-evolution card (for example, a card QRS), a reference card necessary for evolution synthesis, and its state (possessed, not possessed) Display area 102 showing (possessed, reserved, or unknown), and
It includes a button b8 (“display acquisition conditions”) for requesting presentation of the acquisition conditions of the reference card. In the image P4, the reference card (here, the display area 1
When the card DSG) in which the state of “not possessed” is shown in 02 is selected and the button b8 is operated, as shown in FIG. 12B, an image P5 showing the acquisition condition of the reference card selected by the user is displayed. Is displayed.
The reference card selected by the user is also referred to as “reference card specified by the user”. Further, since the reference card is an example of the object, the “reference card designated by the user” is an example of the “designated object” which is the object designated by the user.

In the image P5 of FIG. 12B, the reference card selected by the user (here, the card D
SG), a card image of the reference card, a card name, and a display area 103 showing the rarity, and a display area 104 showing the acquisition condition of the reference card. In the display area 104, information 104a on the degree of difficulty of acquisition (here, the number of acquisitions, the number of distributions, and the average transaction price) and information 104b on the acquisition route (here, the available area) are displayed.

(1-6-1-2) Processing for presenting unknown card acquisition conditions (FIGS. 13A and 13B)
13A and 13B show changes in a series of display screens in the acquisition condition presentation process for presenting the acquisition condition of an unknown card. The images P1 to P3 in FIG. 13A are shown in FIG.
It is similar to the images P1 to P3 of A.
The image P4 of FIG. 13A is shown in FIG. 1 in that an unknown card is shown in the display area 102.
It is different from the image P4 of 2A. The unknown card is a card that the user has never owned (for example, the value of “acquisition count” in the possession history data table is 0) among the uncarried cards. In the image P4, when the reference card (here, the card in which the “unknown” state is displayed in the display area 102) whose acquisition conditions are to be displayed is selected and the button b8 is operated, as shown in FIG. 13B. An image P5 indicating the acquisition condition of the reference card selected by the user is displayed on the screen.

In the image P5 of FIG. 13B, an image indicating that the reference card selected by the user is an unknown card to the user is displayed in the display area 103, and the display area 10
4 shows only information 104b (here, the number of acquisitions and the number of distributions) regarding the difficulty of acquisition of the acquisition conditions of the reference card (that is, the information 104a regarding the acquisition route in the image P5 of FIG. 12B is masked. 12B is different from the image P5 of FIG. 12B.

(1-6-2) Evolutionary synthesis process (FIG. 14)
FIG. 14 shows a series of changes in the display screen when the evolutionary synthesis process is executed based on the user's operation. In FIG. 14, an image P10 is an example of an image displayed when the user obtains a new card DSG while executing the game.
If the change condition of the reserved evolutionary synthesis comes to be satisfied by the acquisition of this new card DSG, the user is informed that the change condition is satisfied by the acquisition of the new card. Is preferably notified. More preferably, it is preferable to display an image for executing evolutionary synthesis as shown in P11.
The image P11 includes a display area 101 showing a pre-evolution card (card KLM) and a post-evolution card (card QRS), a display area 102 showing a reference card necessary for evolutionary composition and its state (here, possession), and Button b2 for accepting a request whether to execute evolutionary synthesis
0 (“Yes”) and button b21 (“No”) are displayed.
When the button b20 is operated in the image P11, the image changes as shown in P12. In the example of the image P12, at least a part of the card image of the post-evolution card, the card name, and the parameter is displayed.

(1-7) Overview of Functions Included in Information Processing Device Next, functions included in the game server 20 for implementing the game according to the present embodiment described above will be described. FIG. 15 is a functional block diagram for explaining functions that play a major role in the game server 20 of this embodiment. In FIG. 15, as described above, the data table group 70 includes a card data table, an evolved combined data table, a quest data table, a possessed card data table, a reservation data table, a possessed history data table, and
Includes card distribution data table. Note that not all of the means included in the functional block diagram shown in FIG. 15 are essential to the present invention.

The accepting unit 51 has a function of accepting various requests from the user based on the information regarding the operation input by the user. As the request from the user in the game of the present embodiment, for example, a request for presenting conditions for obtaining cards, a request for evolutionary synthesis processing, a request for quest processing, a request for reservation processing for evolutionary synthesis, an execution request for evolutionary synthesis, Request to view the possession card of the user,
There is a request for sale processing of the user's possession card.
The request for the acquisition condition presenting process is a request for presenting the acquisition condition of the reference card necessary for the evolution synthesis of the base card in response to the output of the image data by the output unit 56.
The request for the reservation process of the evolutionary synthesis is based on the output of the image data by the output unit 56, and the evolutionary synthesis of the base card in the evolutionary synthesis and at least one of the plurality of reference cards corresponding to the base card. Reserved for the card and erasing the card from the user's possession card.
For example, it is a request to restrict the use of the card for sale or the process of transferring the card to another user). The request for the reservation process for evolutionary synthesis includes the card ID of the reference card to be reserved.
In order to realize the function of the reception unit 51, the game server 20 has the communication interface unit 2
4, the request corresponding to the operation input of the button by the user in the web page which is the image is received from the user terminal 10. The CPU 21 of the game server 20 determines the content of the request based on the information included in the received request, and performs the request receiving process. In the reception process, the request is recorded in the RAM 13. The CPU 21 sequentially executes the processing according to the received request.

The game processing means 52 has a function of executing processing of various games other than evolutionary synthesis based on requests and instructions from the user accepted by the acceptance means 51. The processing of the game of the present embodiment may be appropriately provided, but for example, battle processing between users, battle processing between users and NPCs, quest processing by users, processing of normal combining of possession cards of users, possession cards of users. Is the sale process.
Although the battle process will not be described in detail, for example, the user composes a team composed of a plurality of possession cards in advance so that the total cost becomes equal to or less than a predetermined upper limit value, and the team competes with other users or NPCs. The battle result is determined by parameters such as offensive power, defensive power, and skill of each card that constitutes the team.

The function of the game processing means 52 when executing the quest process is realized as follows. When the CPU 21 of the game server 20 receives the request for the quest process including the quest ID, the quest data (area name, physical strength, acquisition card data (card ID and acquisition rate) associated with the quest ID is acquired from the quest data table. ), acquisition item data (item ID and acquisition rate), boss ID, and quest UI data) are read and expanded in the RAM 23. Next, the CPU 21 displays the quest execution screen based on the quest UI data and advances the quest according to the user's operation.
When the quest progresses to a predetermined level, the CPU 21 executes a battle between the boss character associated with the boss ID and the user. When the user satisfies the victory condition in the match,
The CPU 21 executes a process of giving a card according to the value of the “acquisition rate” associated with the quest ID. In the process of giving a card, the CPU 21 writes the card ID associated with the quest ID in the possession card data table and increases the value of the “acquisition count” associated with the card ID in the possession history data table. ..
It should be noted that when the user satisfies the victory condition in the match, the process of giving the item is executed in the same manner as the process of giving the card.

The function of the game processing means 52 in the case of executing the processing of the normal composition of the card owned by the user is as follows.
It is realized as follows. When the CPU 21 of the game server 20 receives an execution request for normal composition including the user's selection results for the base card and the reference card, it reads the card data of the base card and the reference card from the possessed card data table and RA
Expand to M23. Next, the CPU 21 changes the parameters of the base card (for example, the card level and the skill level) based on the parameters of the base card and the reference card,
The parameter of the changed base card is written in the possession card data table, and the card data of the possession card used as the reference card is deleted from the possession card data table. Note that the card level and skill level of the base card do not always increase every time normal synthesis is executed. For example, every time a normal synthesis is executed, the value of the breeding parameter associated with the card is increased, and when the value of the breeding parameter reaches a predetermined value, the card level is increased by 1 and the value of the breeding parameter is set to zero. It may be reset to.

The function of the game processing means 52 in the case of executing the sale processing of the possessed card of the user is realized as follows. The CPU 21 of the game server 20 receives the request for sale processing,
When the selection result of the card to be sold is accepted, the card data of the card to be sold is deleted from the possessed card data table. Next, the CPU 21 reads the value (points) of the selling price of the card to be sold from the card data table, and performs a process of giving the read point to the user. The process of giving points to a user is performed by, for example, a user database (
This is a process of updating the value of the possession point of the user recorded in (not shown).

The card data changing unit 54 has a function of executing evolutionary synthesis for changing the card data of the base card when all of the plurality of reference cards satisfying the changing conditions are included in the possessed cards of the user.
In the example of the present embodiment, in order to realize the function of the card data changing unit 54, when the CPU 21 of the game server 20 receives an execution request for evolutionary composition, the pre-evolution card (that is, evolutionary composition) is displayed in the possessed card data table. Erase the card data on the
Newly write the card data of the post-evolution card. As a result, the base card of the user's possession card will evolve. As shown in the evolutionary synthesis data table, since the card IDs before and after the evolution are different, at least one of the card name, the card image, and the card parameter will be changed by the evolutionary synthesis.

The acquisition unit 55 is a base card selected by the user (an example of a selected object).
A plurality of reference card IDs which are combination conditions (an example of changing conditions) of reference cards corresponding to
It has a function to acquire from the evolutionary synthesis data table. Further, when the reference card selected by the user is not a possessed card (for example, an uncarried card or an unknown card), the acquisition unit 55 uses the card data of the reference card as a quest data table, a possession history data table, It also has a function of acquiring from the card distribution data table. Also,
The acquisition unit 55 acquires the serial number (an example of information indicating an object) of any of the cards owned by the user, based on the operation input of the user when reserving the card for evolutionary synthesis. It has a function.
When the acquisition unit 55 acquires a plurality of reference card IDs, which are reference card combination conditions,
The CPU 21 of the game server 20 refers to the evolutionary synthesis data table in response to the acquisition of the base card selection result from the user terminal 10, and reads out a plurality of reference card IDs that form the combination condition corresponding to the base card. ..
When the acquisition unit 55 acquires the card data of the reference card selected by the user,
The CPU 21 of the game server 20 refers to the quest data table, the possession history data table, and the card distribution data table in response to obtaining the reference card selection result from the user terminal 10, and refers to the card data of the reference card. Read out.
When the acquisition unit 55 acquires the serial number of the card, the CPU 21 of the game server 20
When receiving a request for evolutionary synthesis reservation processing from the user terminal 10, the possession card that is not reserved is possessed from among the base card to be evolved and synthesized and a plurality of reference cards corresponding to the base card. It is specified by referring to the card data table, and the serial number of the specified card is read.

The output unit 56 uses the card data of the plurality of reference cards included in the change condition acquired by the acquisition unit 55 to display the plurality of reference cards in a display format that can be identified by the user. It has a function of outputting data (for example, image data) (hereinafter referred to as “first output function”).
In the example of the present embodiment, in order to realize the first output function of the output means 56, the game server 2
For example, when the user selects a base card, the CPU 21 of 0 reads a combination of a plurality of reference card IDs required to evolve the base card from the evolution combination data table, and for each reference card, possession card Based on the information stored in the data table, reservation data table, and possession history data table, the card status (
"Reserved", "possessed", "not possessed", or "unknown") is specified.
Further, the CPU 21 generates first output data for displaying the state of each reference card in a display format that can be identified by the user.
For example, in the reservation data table of FIG. 9, when the serial numbers or temporary serial numbers included in the possessed card data are recorded in the columns C1 to C5 associated with the evolution ID corresponding to the base card, The state of the reference card identified by the card ID corresponding to the corresponding column is identified as "reserved".
For example, regarding the cards whose card status is other than "reserved", the card IDs in the columns C1 to C5 associated with the evolution ID corresponding to the base card in the evolution composite data table of FIG. 6 are the possessed cards of FIG. When included in the "card ID" column of the data table, the state of the reference card specified by the card ID is specified as "possessed".
For example, in the possession history data table of FIG. 10 for cards other than “reserved” and “possessed”, if the “acquisition count” column corresponding to the card ID is not 0, the card ID If the status of the reference card specified by is identified as “not possessed” and the “number of acquisitions” column corresponding to the card ID is 0, the card ID
The state of the reference card identified by is identified as "unknown".
The state of the specified reference card is shown in the first output data.

Further, the output unit 56 outputs the second output data (for example, image data) for presenting the acquisition condition of the reference card (unowned card or the unknown card) corresponding to the reference card ID acquired by the acquisition unit 55. It has a function of outputting (hereinafter referred to as "second output function").
In the example of the present embodiment, in order to realize the second output function of the output means 56, the game server 2
The CPU 21 of 0, for example, when the reference card ID is acquired by the acquisition unit 55, based on the acquired reference card ID, the quest data table, the possession history data table,
Further, the card distribution data table is referred to, the acquisition condition of the reference card corresponding to the reference card ID is specified, and the second output data for presenting the acquisition condition is generated.
For example, in the quest data table of FIG. 7, the information in the “area name” column corresponding to the quest ID including the reference card ID acquired in the “card ID” column of the “acquisition card” is the available area. Specified.
In the possession history table of FIG. 10, the value in the “number of acquisitions” column corresponding to the acquired reference card ID is specified as the number of acquisitions.
In the card distribution data table of FIG. 11, “corresponding to the acquired reference card ID”
The values in the columns "Distribution number" and "Average transaction price" are specified as the circulation number and average transaction price, respectively.
At least one of the specified available area, the number of times of acquisition, the number of distributions, and the average transaction price is shown in the second output data.

The recording unit 57 receives the request for the reservation process for evolutionary synthesis, and then acquires the acquisition unit 55.
It has a function of recording the serial number acquired by the above in the reservation data table in the storage 25 as a reserved card. In the example of the present embodiment, the reservation target card is a card that is restricted from being used for processing other than evolutionary synthesis of the selected base card.

In order to realize the function of the recording means 57, when the CPU 21 of the game server 20 receives a request for a reservation process for evolutionary synthesis, it accesses the reservation data table and writes the serial number of the reservation target card. More specifically, if the serial number of the card selected as the base card among the reservation target cards is not recorded in the reservation data table, a new reservation ID is issued. The CPU 21 writes the serial number of the card selected as the base card in the “pre-evolution card” field in association with the issued reservation ID. Further, among the reservation target cards, the “reference card I” having the same card ID as the serial number of the reference card is used.
The column "D" (any of the columns C1 to C5) is specified, and the serial number of the reference card among the reservation target cards is written in the specified column.
On the other hand, when the reservation ID has been issued, the serial number is already recorded in the “pre-evolution card” field, so the CPU 21 only writes the serial number of the reference card among the reservation target cards. ..

The limiting means 58 uses a card recorded as a reserved card in the reservation data table,
It is equipped with a function that limits its use in processes other than the target evolutionary synthesis. "Used for processing other than the target evolutionary synthesis" means that the card recorded as a reserved card in association with the target evolutionary synthesis is an evolutionary synthesis or normal synthesis other than the target evolutionary synthesis. It is also included when used for.
Various methods can be considered as the restriction method by the restriction means 58. For example, when a card to be restricted is selected for a process other than the target evolutionary synthesis, or when the card to be restricted is selected for a process other than the desired evolutionary synthesis, On the other hand, there is a method of performing processing for confirming the continuation of the processing.
Note that "restricting the use of a reserved card for processing" is not limited to prohibiting the processing itself other than the intended evolutionary synthesis using the reserved card, but using the reserved card Although a process other than the target evolutionary synthesis can be executed, the procedure of executing the process may be difficult or the process execution procedure may be complicated. "Processing other than evolutionary synthesis" for reserved cards is executed on condition that the reserved card is deleted from the user's possessed card (that is, executed on condition that the reserved card is an unowned card) It is particularly preferable that the treatment is restricted.

For example, when the CPU 21 of the game server 20 receives an execution request for any one of the various processes of the game of the present embodiment, when the possessed card of the user is selected as the processing target card, the possessed card data table With reference to, it is determined whether or not the reservation ID is associated with the card ID of the selected card. In the CPU 21, the reservation ID is associated with the card ID of the selected card, and the process related to the execution request is the reservation ID.
If it is not the evolutionary synthesis process corresponding to, the process may be prohibited, or the user may be notified that the selected card is a reserved card. Alternatively, the user may be notified that the selected card is a reserved card, and the user may be confirmed whether or not to continue the process. Since the evolution ID and the serial number of the reserved card are associated with each other in the reservation data table, the CPU 21 of the game server 20 performs the target evolutionary synthesis corresponding to the reserved card (that is, corresponds to a specific evolution ID). Evolutionary synthesis) can be specified. Therefore, it is possible to determine whether or not the process that the user intends to execute using the specific possession card is the target evolutionary synthesis process.

It is not essential to provide the recording means 57 and the limiting means 58, but by providing the recording means 57 and the limiting means 58, for example, some reference cards out of a plurality of reference cards necessary for evolutionary synthesis are evolutionarily synthesized. It is possible to prevent a user who reserves the card before executing the above and waits for the evolutionary synthesis until obtaining the remaining reference cards from accidentally using the possessed card for a process other than the evolutionary synthesis.

(1-8) Processing Flow of Game of Present Embodiment Next, an example of the processing flow of the game of the present embodiment will be described with reference to the sequence charts of FIGS. 16A, 16B, and 17.
16A and 16B are sequence charts showing the acquisition condition presentation processing. FIG. 17 is a sequence chart showing the evolutionary synthesis process.
12A, 12B, 13A, 13B, and each image P1 to P5 and P10 to P12 shown in FIG. is there.

(1-8-1) Acquisition condition presentation processing (FIGS. 16A and 16B)
In the acquisition condition presentation process described below, as an example, when the user has a base card and a part of a plurality of reference cards for evolution-synthesizing the base card, the user does not have or does not know. Assume a case where the presentation of the conditions for obtaining the reference card of is required.

16A, a predetermined button (for example, FIG. 1) is displayed on the image displayed on the user terminal 10.
2A or the button b4) of the image P1 of FIG. 13A is operated by the user, the CPU 11 of the user terminal 10 accepts the request for the evolutionary synthesis process (S10) and transmits the request to the game server 20 (S12).
When the CPU 21 of the game server 20 receives the request for the presentation process of the acquisition condition from the user terminal 10, the CPU 21 refers to the evolution combination data table and the possession card data table, and reads out the evolutionary possession card of the user (S14). That is, the CPU 21 reads the card data of the possessed card of the user from the possessed card data table, and reads all the pre-evolution card IDs (that is, the card IDs of the evolveable cards) of the evolution combined data table. Next, the CPU 21 identifies a card that can be evolved (that is, a base card candidate) from among the cards possessed by the user, and generates image data including the card data of the base card candidate (S
16), the image data is transmitted to the user terminal 10 (S18).
Note that the image data generated in S16 has a display mode in which an image of a card that can be evolved and an image of a card that cannot be evolved are different among the cards owned by the user, as shown in the image P2 of FIG. 12A or 13A. Is preferably generated as follows.

Upon receiving the image data transmitted in S18, the CPU 11 of the user terminal 10 displays an image on the display unit 16 based on the image data (S20). The image displayed in S20 includes images of a plurality of base card candidates, as illustrated in image P2 of FIG. 12A or FIG. 13A. By operating the image of each card, the serial number of each card is changed. The numbers are configured to be selectable. When the user performs an operation of selecting one of the plurality of base card candidates displayed in S20 as a base card,
The CPU 11 receives the selection result (serial number) of the base card (S22) and transmits the selection result to the game server 20 (S24).

Upon receiving the selection result (serial number) transmitted in S24, the CPU 21 of the game server 20 refers to the evolutionary synthesis data table, and matches the card ID associated with the serial number of the base card selected by the user. A plurality of reference card IDs (card IDs in the columns C1 to C5) corresponding to the pre-evolution card ID are read (S26). Then the CPU
21 refers to the possessed card data table and the reserved data table to identify the state of the card corresponding to each reference card ID read in S26 (either uncarried, possessed, reserved, or unknown), Image data is generated based on the identification result (S28).

In S28, the CPU 21 of the game server 20 identifies the state of the card corresponding to each reference card ID as follows.
The CPU 21 reads out the serial number recorded in the "reserved card serial number" column of the reservation data table, refers to the possessed card data table, and identifies the card ID associated with the serial number. If the reference card ID read in S26 and the specified card ID match, or if the serial number is a provisional serial number, the state of the card specified by the card ID is set as "reserved". Identify.
When the reference card ID of the reference card is included in the card IDs recorded in the possession card data table for the reference card other than the card specified as “reserved”, the CPU 21 selects the reference card. "Own" status of card specified by ID
Specify as.
When the value associated with the reference card ID in the “acquisition count” column of the possession history data table for the cards other than “reserved” and “possessed” is not 0, the CPU 21 identifies the card identified by the reference card ID. If the value associated with the reference card ID in the “acquisition count” column of the possession history data table is 0, the status of the card identified by the reference card ID is “unowned”. Unknown”.

In S28, the CPU 21 of the game server 20 instructs the user whether or not to perform evolutionary synthesis of the card KLM, when the states of all the reference cards read in S26 are "possessed" or "reserved". Generate image data for performing. When the state of at least one of the reference cards read in S26 is "uncarried" or "unknown", the CPU 21 presents the acquisition condition of the reference card in the "uncarried" or "unknown" state. Image data is generated. Here, it is assumed that the original image data of the image P4 of FIG. 12A or FIG. 13A is generated.

Next, the CPU 21 of the game server 20 sends the image data generated in S28 to the user terminal 1
It is transmitted to 0 (S30). Upon receiving the image data transmitted in S30, the CPU 11 of the user terminal 10 displays an image based on the image data on the display unit 16 (S32).

The image displayed in S32 is S2 as shown in the image P4 of FIG. 12A or 13A.
It is displayed so that the user can identify a plurality of reference cards required for evolutionary synthesis of the base card selected in 2. The image P4 of FIG. 12A or FIG. 13A is configured such that the status of each reference card is displayed in association with the reference card, and a request for presenting the acquisition condition of an uncarried card or an unknown card can be accepted. .. Here, after the image P4 of FIG. 12A or FIG. 13A is displayed, the user performs an operation for requesting the acquisition condition presentation processing (for example, the operation of the button b8 of the image P4 of FIG. 12A or 13A). Then, the CPU 11 of the user terminal 10 accepts a request for acquisition condition presentation processing based on a user instruction corresponding to the operation (S34), and transmits the request to the game server 20 (
S36). The request transmitted from the user terminal 10 to the game server 20 in S36 includes the card ID of the uncarried card or the unknown card (that is, the card for which the acquisition condition should be presented in the acquisition condition presentation process) selected by the user. Be done.
As described above, the reference card selected by the user is an example of the designated object that is the object designated by the user. That is, the processes of S34 and S36 are an example of a process of receiving an instruction to specify any one of the plurality of objects based on the user's instruction.

When the CPU 21 of the game server 20 receives the request for the presentation process of the acquisition condition transmitted in S36, the CPU 21 retrieves the card data of the reference card selected by the user from the card data table, the quest data table, and the card distribution data table. Get (S3
8). The card name, card image, and rarity are acquired from the card data table. The quest ID and the area name of the available area are acquired from the quest data table. The number of acquisitions is acquired from the possession history table. The number of distributions and the average transaction price are
Obtained from the card distribution data table.

If the state of the card specified in S28 is "unknown" (S40: YES), S4
If the state of the card specified in S28 is not "unknown", proceed to 2 (S40: NO).
, S44.
Here, as an example when the card status is not "unknown" (that is, unknown card),
An example of the case where the card state is “uncarried card” (that is, an uncarried card) will be described. In addition,
Both "unknown" and "not possessed" are common in that they indicate a state in which the user does not possess the card (that is, the card ID is not included in the possessed card data table).

In S42, the CPU 21 of the game server 20 includes information regarding the difficulty level of the acquisition (here, the number of acquisitions, among the information regarding the card indicated by the card data acquired in S38).
Masking is applied to the image so that information (here, card name, card image, rarity, and available area) other than the number of circulations and the average transaction price is not displayed.
In addition, in the present embodiment, the purpose of preventing information other than the information regarding the difficulty of obtaining an unknown card from being displayed is to give the user an expectation for the game (in particular, to obtain the unknown card), and It is to improve the taste.

In S44, the CPU 21 determines, based on the card data of the reference card acquired in S38,
Image data (FIG. 12B or FIG. 1) for presenting the user with the acquisition condition of the reference card (however, information about the acquisition difficulty when it is determined to be “unknown” in S40).
The original image data of the image P5 of 3B) is generated and the image data is transmitted to the user terminal 10 (S46).

Upon receiving the image data transmitted in S46, the CPU 11 of the user terminal 10 displays an image based on the image data on the display unit 16 (S48).
When it is determined in S40 that it is not "unknown" (for example, "un possessed"), as shown in image P5 of FIG. 12B, card image, card name, rarity, number of acquisitions, number of distributions, average transaction price, Also, the available area is displayed.
On the other hand, when it is determined in S40 that it is “unknown”, as shown in the image P5 of FIG. 13B,
The number of acquisitions, the number of distributions, and the average transaction price are displayed, but the card image, card name, rarity, and available area are not displayed.
In other words, the information displayed as the acquisition condition of the unknown card is more limited than the information displayed as the acquisition condition of the uncarried card. That is, in S48, when the designated object is an unknown object that the user has never possessed, the information displayed as the acquisition condition is limited as compared with the case where the designated object is an uncarried object. Is an example.

As described above, in the present embodiment, when the user does not carry the reference card selected by the user (when the reference card is an unknown card or an uncarried card), an example of displaying the acquisition conditions of the reference card is displayed. explained. This is an example of a process of displaying the acquisition condition of the designated object when the user does not own the designated object which is the designated object.

(1-8-2) Evolutionary synthesis processing (FIG. 17)
For example, when the user newly obtains a card that satisfies the change condition of the reference card in evolutionary synthesis, the evolutionary synthesis process can be executed.
17, a predetermined button (for example, FIG. 14) is displayed on the image displayed on the user terminal 10.
When the user operates the button b20) of the image P11 of the
U11 accepts the evolutionary synthesis execution request (S150) and transmits the request to the game server 20 (S152).

When the CPU 21 of the game server 20 accepts the request transmitted in S152, it erases the card data of the pre-evolution card (that is, the base card of evolution combination) in the possessed card data table (S154), and the card of the post-evolution card. Write new data (S15
6).
Next, the CPU 21 of the game server 20 erases the card data of the reference card used for evolutionary synthesis in the possessed card data table (S158).

Next, the CPU 21 of the game server 20 generates image data including the card data of the post-evolution card (image data that is the source of the image P12 of FIG. 14) (S160), and transmits the image data to the user terminal 10 ( S162). When receiving the image data transmitted in S162, the CPU 11 of the user terminal 10 displays an image based on the image data (for example, the image P12 in FIG. 14) on the display unit 16 (S164).

As described above, in the game system according to the present embodiment, in order to execute the evolutionary synthesis of a card, which is an example of a process of changing an object, a base card to be evolved and a plurality of references corresponding thereto are executed. It is a requirement that the user has all of the cards. Therefore, for example, when some of the plurality of reference cards are not possessed, evolutionary synthesis of the base card cannot be executed. At this time, it may be impossible or difficult for the user to obtain the reference card that the user does not have.
However, whether or not the user who does not know the acquisition condition of the reference card performs the process (for example, the quest process) for acquiring the reference card because the acquisition of the reference card is impossible or difficult. I can't recognize it when I make a decision. In such a case, the user executes the process for obtaining the reference card while having a fear that the reference object may be impossible or difficult to obtain.
The game server 20 of the present embodiment presents the acquisition conditions of the reference card that the user does not have in response to the request from the user. Therefore, even if there is a reference card that is not available or difficult for the user among the plurality of reference cards corresponding to the base card subject to evolutionary synthesis, the user cannot obtain the reference card or After recognizing that it is difficult, it is possible to decide whether or not to execute the process for obtaining the reference card. As a result, it is possible to give a sense of security to the user who executes the process for obtaining the reference card.

Further, it is preferable that at least one of the acquisition route and the acquisition difficulty level is presented as the acquisition condition of the uncarried card. In this case, the user can give a sense of security to the user who executes a process (for example, a quest process) for obtaining the uncarried card.

Also, as the acquisition condition of the unknown card, the acquisition difficulty is displayed, but the acquisition route is not presented (that is, the information displayed as the acquisition condition of the unknown card is the information displayed as the acquisition condition of the unowned card. It is more limited than the above). In this case, it is possible to give a sense of security to the user who executes the process for obtaining the unknown card (for example, the quest process) while keeping the difficulty level of the game at an appropriate level.

(1-9) Modified Example of Present Embodiment A modified example of the present embodiment will be described below. The following modifications can be combined as appropriate.

(1-9-1) First Modification The image P4 of FIG. 12A or FIG. 13A shows a display format in which only the card image of the reference card is displayed. It is not limited.
For example, instead of the display format in which only the card image is displayed, a display format in which only the card name is displayed or a display format in which a combination of the card image and the card name is displayed may be used.
That is, the display format of the present embodiment may be any format as long as the reference card is displayed so as to be distinguishable to the user.

(1-9-2) Second Modification In the above-described embodiment, in S42 of FIG. 16B, in order to prevent information other than information regarding the difficulty of acquisition from being displayed in the card data acquired in S38, the image is displayed. Although the example of applying the masking process to the above has been described, the process for preventing the information from being displayed is not limited to this.
For example, instead of applying the masking process, information other than the information about the difficulty of acquisition may be deleted, or the information may be replaced with a predetermined symbol.

(1-9-3) Third Modification In the above embodiment, an example in which the card name, the card image, the rarity, and the available area are not displayed in S42 of FIG. 16B has been described. The embodiment is not limited to this.
For example, the card image and the available area may not be displayed, and the card name and the rarity may be displayed.
Further, the information not to be displayed may be arbitrarily set by the user.

(1-9-4) Fourth Modified Example In the above-described embodiment, in S42 of FIG. 16B, information other than the information regarding the difficulty of acquisition is not displayed among the information regarding the card indicated by the card data acquired in S38. Although the example of doing so has been described, S42 can be omitted.
If S42 is omitted, all of the card data (that is, information regarding the reference card for which the acquisition condition is presented) acquired in S38 is displayed, so the reference card may be available to the user. It can give a sense of expectation.

(1-9-5) Fifth Modified Example A user has possessed a card in the past, and an uncarried card, which is a reference card that the user does not currently possess, is selected as a card for which the acquisition conditions should be presented. In this case, it is desirable to display at least one of the available area and the difficulty level of the card as the acquisition condition.
This is the acquisition condition when the designated object is an uncarried object that the user has possessed in the past and the user does not currently possess.
It is an example of a process of displaying at least one of an acquisition route and an acquisition difficulty level of a designated object.
According to this modification, the user can easily know the difficulty level of obtaining the card.

(1-9-6) Sixth Modification In the above-described embodiment, an example of displaying the acquisition condition of the uncarried card is shown, but the acquisition condition of a card other than the uncarried card may be displayed.
As an example, the conditions for obtaining the possession card may be displayed. For example, when there are many possession cards, the user may forget the acquisition condition of a certain possession card. In this case, by displaying the acquisition conditions of the possessed card, the user can re-recognize the degree of difficulty of acquiring the possessed card. If the user recognizes that the possession card is difficult to obtain, the purpose of the possession card (for example, which base card should be used as a reference card for the process of evolutionary synthesis)
Can give you an opportunity to think carefully. On the other hand, if the user recognizes that the possession card is difficult to obtain, the user can be given an opportunity to easily use the possession card.

(1-9-7) Seventh Modification In the above-described embodiment, an example in which the change condition is satisfied when all the reference cards corresponding to the base card are possessed has been described. In addition to possession, the change condition may be satisfied when a predetermined additional condition is satisfied.
For example, the additional condition may be satisfied when the card levels of all the reference cards have reached the maximum level, or may be satisfied when the user owns a predetermined amount of game points. ..

(2) Second Embodiment In the first embodiment, a case has been described in which an image showing the acquisition condition of an unowned card is displayed. However, in the second embodiment, in addition to the acquisition condition, an unowned card An example of displaying an image including an operation target for guiding the user to the acquisition route of will be described. The description similar to that of the first embodiment is omitted as appropriate.

(2-1) Specific Example of Acquisition Condition Presentation Process and Quest Process Hereinafter, a specific example of the acquisition condition presentation process of the game card of the present embodiment will be described with reference to FIG. FIG. 18 is a diagram showing an example of a screen displayed on the user terminal 10 when executing the game process of the present embodiment.

(2-1-1) Acquisition condition presentation processing (FIG. 18)
In the image P4 of FIG. 12A of the first embodiment, the reference card (here, the card DSG in which the “unowned” state is displayed in the display area 102) whose display conditions are to be displayed is selected, and the button b8 is selected. When is operated, as shown in FIG. 18, an image P5 showing the acquisition condition of the reference card selected by the user is displayed.

The image P5 of FIG. 18 differs from the first embodiment (image P5 of FIG. 12B) in that it includes a button b9 (“go to available area”) in addition to the display areas 103 and 104.
The button b9 is a button operated when the user requests a quest process for obtaining an uncarried card.
The button b9 is an example of an operation target for guiding the user to the acquisition route.

(2-1-2) Quest processing (Fig. 18)
When the button b9 (“go to available area”) is operated in the image P5, the image changes as shown in P6. The image P6 shows a quest execution screen. The user can search the area (here, area 1) used in the quest by performing a predetermined operation on the image P6. When the quest condition is achieved, the user can obtain an uncarried card based on the probability according to the value of “acquisition rate” in the quest data table.

(2-2) Process Flow of Game of Present Embodiment Next, an example of the process flow of the game of the present embodiment will be described with reference to the sequence chart of FIG.
FIG. 19 is a sequence chart showing the quest process. Note that, in FIG. 19, the steps of displaying the images P5 to P6 shown in FIG. 18 are denoted by reference numerals of the images.

(2-2-1) Acquisition condition presentation processing In the present embodiment, in S44 (FIG. 16A), the CPU 21 of the game server 20 adds the card data of the reference card acquired in S38 to the acquisition route of the reference card. Image data for presenting an operation target for guiding the user to (here, the available area) (see FIG. 18).
The image data that is the source of the image P5) is different from the first embodiment.

(2-2-2) Quest processing (Fig. 19)
19, a predetermined button (for example, FIG. 18) is displayed on the image displayed on the user terminal 10.
When the button b9) of the image P5 is operated, the CPU 11 of the user terminal 10 accepts the request for the quest process (S70) and transmits the request to the game server 20 (S72).

When the CPU 21 of the game server 20 receives the request transmitted in S72, the quest data associated with the quest ID acquired in S38 from the quest data table (
Image data of the quest process (see FIG. 18) based on the area name, physical strength, acquisition card data (card ID and acquisition rate), acquisition item data (item ID and acquisition rate), boss ID, and quest UI data) Image data which is the source of the image P6) is generated (S7
4), the image data is transmitted to the user terminal 10 (S76).

When the CPU 11 of the user terminal 10 receives the image data transmitted in S76, the image based on the image data (for example, the image P6 in FIG. 18) is displayed on the display unit 16 (S78).
).

After that, the CPU 11 of the user terminal 10 issues an instruction according to the user's operation to the game server 2
Send to 0. The CPU 21 of the game server 20 advances the quest based on the transmitted instruction. When the quest progresses to a predetermined level, the CPU 21 executes a battle between the boss character associated with the boss ID and the user. When the user satisfies the victory condition in the match, the CPU 21 executes a process of giving a card according to the value of “acquisition rate” associated with the quest ID. In the process of giving a card, the CPU 21 makes the quest I
The card ID associated with D is written in the possession card data table, and the value of the “acquisition count” associated with the card ID in the possession history data table is increased. As a result, the user can obtain the card selected in the image P4 of FIG. 12A of the first embodiment (reference card whose acquisition conditions should be displayed).

As described above, the game server 20 according to the present embodiment presents the operation condition for guiding the user to the acquisition route of the reference card together with the acquisition condition of the reference card that the user does not possess, thereby Since it is possible to request execution of a process for obtaining an object simply by operating the operation target, it is possible to improve operability when requesting execution of the process.

(3) Third Embodiment In the second embodiment, a case has been described in which an image including an operation target for guiding the user to the acquisition route of an uncarried card is displayed. However, in the third embodiment, In addition to the operation target for guiding the user to the acquisition route of the possessed card, guide the user to the acquisition route of the unowned card, and execute the reservation process of evolutionary synthesis after the user acquires the unowned card An example of displaying an image including an operation target for performing will be described. Note that description similar to that of the above-described embodiment will be appropriately omitted.

(3-1) Specific Example of Acquisition Condition Presentation Process, Quest Process, and Evolutionary Synthesis Reservation Process Hereinafter, a card acquisition condition presentation process, a quest process, and an evolutionary synthesis reservation process of the game according to the present embodiment will be described. A specific example of the above will be described with reference to FIG. FIG. 20 is a diagram showing an example of a screen displayed on the user terminal 10 when executing the game process of the present embodiment.

(3-1-1) Acquisition condition presentation processing (FIG. 20)
In the image P4 of FIG. 12A of the first embodiment, the reference card (here, the card DSG in which the “unowned” state is displayed in the display area 102) whose display conditions are to be displayed is selected, and the button b8 is selected. When is operated, an image P5 showing the acquisition condition of the reference card selected by the user is displayed as shown in FIG.
The image P5 in FIG. 20 includes a button b10 (“do not reserve/go to available area”) and a button b11 (“book/go to available area”) in addition to the display areas 103 and 104. It differs from the first embodiment (image P5 in FIG. 12B) in the point. Button b
Reference numeral 10 is a button operated when the user requests a quest process for obtaining an uncarried card. The button b11 is a button operated when requesting both the quest process and the evolutionary synthesis reservation process.

(3-1-2) Quest processing (Fig. 20)
When the button b10 (“No reservation/go to available area”) is operated in the image P5, the image changes as shown in P6. The image P6 corresponds to the second embodiment (the image P6 in FIG. 18).
) Is the same.

(3-1-3) Evolutionary synthesis reservation processing (FIG. 20)
When the button b11 (“reserve/go to the available area”) is operated in the image P5, the reservation process is executed for the reference card owned by the user along with the quest process, indicating that the reservation process is completed. The image P7 is displayed.

(3-2) Processing Flow of Game of Present Embodiment (FIG. 21)
Next, an example of the process flow of the game of this embodiment will be described with reference to the sequence chart of FIG. It should be noted that the acquisition condition presentation process and the quest process of the present embodiment are executed in the same manner as in the second embodiment.
FIG. 21 is a sequence chart showing a reservation process for evolutionary synthesis. Note that in FIG. 21, the steps of displaying the images P5 to P7 shown in FIG. 20 are denoted by the reference symbols of the images.

In the reservation process described below, as an example, it is assumed that the user reserves a reference card that is not possessed for evolutionary synthesis of the base card among the plurality of reference cards for evolutionary synthesis of the base card.

21, a predetermined button (for example, FIG. 20) is displayed on the image displayed on the user terminal 10.
When the user operates the button b11) of the image P5 of the
11 receives the request for the evolutionary composition reservation process (S50), and sends the request to the game server 20.
To (S52). The request includes a card ID that identifies the reference card that is not possessed and that is displayed in the display area 103 of FIG.
Note that S<b>52 is an example of a process of accepting a request for restricting the designated object from being used for a process other than the process of changing the selected object, based on the operation by the user.

When the CPU 21 of the game server 20 receives the request for the reservation process of the evolutionary synthesis, the CPU 21 accesses the reservation data table, and has the reservation ID corresponding to the serial number of the base card acquired in S24 (FIG. 16A) already issued? That is, it is determined whether or not the same serial number is recorded in the "pre-evolution card" field (S54).
If the reservation ID has been issued (S54: YES), the process proceeds to S58, and if the reservation ID has not been issued (S54: NO), after the reservation ID has been issued (S56), the process proceeds to S58. In S58, the CPU 21 writes a temporary serial number in the reservation data table in association with the reservation ID. At this time, when the reservation ID is newly issued, the CPU 21 writes the serial number of the base card among the reservation target cards in the “pre-evolution card” field, and the C1 to C5 corresponding to the reservation ID. Data indicating that the card is not a reservation target card (for example, N
ULL) is written.

Next, the CPU 21 of the game server 20 writes the reservation ID targeted for writing in S58 in the "reservation ID" column corresponding to the card ID of the reservation target card in the possessed card data table (S60).
Note that S60 is an example of a process of restricting the designated object from being used for processes other than the process of changing the selected object.

Next, the CPU 21 generates image data indicating that the reservation is completed (S62), and transmits the image data to the user terminal 10 (S64). CPU11 of the user terminal 10, S
When the image data transmitted in 66 is acquired, an image (for example, image P7 in FIG. 20) is displayed on the display unit 16 based on the image data (S66).

After that, when the user obtains the reservation target card (that is, when the card ID and serial number of the reservation target card are recorded in association with the possessed card data of the user), the CP
The U21 rewrites the temporary serial number written in the reservation data table in S58 with the serial number included in the possessed card data.

Note that in FIG. 21, a predetermined button (for example, a button on the image displayed on the user terminal 10
When the button b10) of the image P5 of FIG. 20 is operated, the same quest processing (FIG. 19) as in the second embodiment is performed.

As described above, the game server 20 of the present embodiment guides the user to the acquisition route of the reference card and reserves the reference card together with the acquisition condition of the reference card not owned by the user. By presenting the operation target for requesting, it is possible to limit the use of the reserved card for processing other than the intended evolutionary synthesis. Therefore, it is possible to prevent the card owned by the user from being accidentally used for another process other than the intended evolutionary synthesis during the waiting period until the user obtains the remaining reference cards not owned by the user. ..

(4) Fourth Embodiment In the above-described embodiment, a case has been described in which an image showing the acquisition condition is displayed when the user operates the button for requesting the presentation of the acquisition condition of the reference card. In the fourth embodiment, when the user operates the button for confirming the selected card as the evolutionary synthesis base card, an image showing the acquisition condition of the reference card for satisfying the change condition of the evolutionary synthesis of the base card is displayed. An example of displaying will be described. Note that description similar to that of the above-described embodiment will be appropriately omitted.

(4-1) Specific Example of Acquisition Condition Presentation Processing A specific example of the game card acquisition condition presentation processing of the present embodiment will be described below with reference to FIG. FIG. 22 is a diagram showing an example of a screen displayed on the user terminal 10 when the game process of this embodiment is being executed.

・Process of presenting acquisition conditions (Fig. 22)
FIG. 22 shows a series of changes in the display screen of the acquisition condition presentation processing for presenting the acquisition conditions of the uncarried card. Images P1 to P3 in FIG. 22 are the same as those in the first embodiment shown in FIG.
It is similar to the images P1 to P3 of A.

When the button b6 is operated in the image P3, the card K selected as the base card
If the condition of the reference card necessary for the LM to evolve is not satisfied, the image is updated as shown in P4. The image P4 is an image for presenting the acquisition conditions of the card that the user does not possess among the reference cards necessary for the card KLM selected as the base card to evolve. When the user selects the button b6 in the image P3 and the condition of the reference card necessary for evolution of the card KLM selected as the base card is satisfied, evolution synthesis of the card KLM is executed. An image (not shown) for the user to indicate whether or not is displayed.

In the image P4 of FIG. 22, in the display area 102, in addition to the reference card necessary for evolutionary synthesis and its state (either possessed, not possessed, reserved, unknown) The point shown is that the first to third embodiments (FIG. 12A, FIG. 13A, and
It differs from the image P4) of FIG. 21A. In the display area 102, as an example, information indicating the acquisition route of an unowned card (here, area name “area 1”) is displayed.

(4-2) Process flow of game of this embodiment (FIG. 23)
Next, an example of the process flow of the game of this embodiment will be described with reference to the sequence chart of FIG. FIG. 23 is a sequence chart showing a presentation process of acquisition conditions.
Note that, in FIG. 23, the step of displaying each of the images P1 to P4 shown in FIG. 22 is denoted by the reference numeral of each image. Also, in FIG. 23, the same processes as those in FIGS. 16A and 16B are denoted by the same reference numerals.

In the acquisition condition presentation process described below, as an example, when the user possesses a base card and a part of a plurality of reference cards for evolution-synthesizing the base card, a reference not possessed is given. Assume a case where the presentation of conditions for obtaining a card is required.

After S26 (FIG. 16A) of the first embodiment is executed, the CPU 21 of the game server 20
Is the card data (card name, card image, rarity, quest ID, available) of the reference card from the card data table, quest data table, and card distribution data table based on the plurality of reference card IDs read in S26. The area name of the area, the number of acquisitions, the number of distributions, and the average transaction price) are acquired (S38). The card name, card image, and rarity are acquired from the card data table. The quest ID and the area name of the available area are acquired from the quest data table. The number of acquisitions is acquired from the possession history table. The circulation number and the average transaction price are acquired from the card circulation data table.

Next, the CPU 21 of the game server 20 executes S40 to S42 in the same manner as S40 to S42 (FIG. 16B) of the first embodiment, and then based on the card data of the reference card acquired in S38. Image data (image data that is the source of the image P4 in FIG. 22) for presenting the acquisition condition of the reference card to the user is generated (S44), and the image data is transmitted to the user terminal 10 (S46).

Upon receiving the image data transmitted in S46, the CPU 11 of the user terminal 10 displays an image (for example, the image P4 in FIG. 22) on the display unit 16 based on the image data (S4).
8).

As described above, the game server 20 according to the present embodiment selects the base card to be the target of the evolutionary synthesis as the acquisition condition of the reference card which is not possessed by the user and is necessary for the target evolutionary synthesis. It is possible to improve the operability of the operation for presenting the acquisition condition of the reference card necessary for the evolutionary synthesis of the base card by presenting it according to the user's operation.

(5) Fifth Embodiment In the above-described embodiment, an example of displaying a screen showing the acquisition conditions of an unowned card has been described, but in the present embodiment, a screen showing the acquisition conditions of an owned card is displayed. Also, an example of processing for preventing the card specified by the user from disappearing due to being used for some processing on the screen will be described.

(5-1) Reservation registration and favorite registration of the game card of this embodiment (FIG. 24)
In the game of the present embodiment, consider a case where the user wants to evolve a desired base card by evolutionary synthesis, but the user does not possess some or all of the reference cards required to evolve the base card. In this case, it is necessary to wait until the user obtains a new card (that is, the remaining reference cards) that satisfies the condition of the combination of the reference cards, until the evolution synthesis of the base card is executed. However, the user loses the reference card possessed before obtaining the remaining reference cards by using it for a different purpose from the evolution of the base card, and the conditions for obtaining the reference card If it is difficult to meet, it will be difficult to evolve the base card. For example, in the case where the user accidentally erases the reference card before executing evolutionary synthesis (for example, sells it), if the probability that the reference card can be obtained is low, or if the reference card is obtained. If the time period available is limited, it becomes difficult for the user to evolve the desired base card.
Therefore, in the present embodiment, it is possible to surely prevent the reference card, which is necessary to evolve the desired base card, from being erased against the user's intention.

Reservation registration and favorite registration of the reference card will be specifically described with reference to FIG. FIG. 24 is a diagram for conceptually explaining reservation registration and favorite registration of a reference card.
In FIG. 24, consider a case where the user wants to evolve the card Q, which is his own card. Here, in order to evolve the card Q, cards A, B, C are used as a plurality of reference cards.
Assume that a combination of is required. Since the user does not have the card B at this time, the evolutionary synthesis cannot be executed for the card Q. Further, when it is difficult to satisfy the acquisition condition of the card A, if the user erases the card A from the possession card by using the card A for a purpose other than the evolution of the card Q, the card Q can be evolved. It gets harder. Therefore, in the present embodiment, in order to prevent the user from unintentionally erasing the card A from the possession card, the acquisition condition of the card A is presented, and then the card A is
Reservation registration or favorite registration is accepted.
Reservation registration is to place the card A in a state of being restricted from being used for processes other than the evolutionary synthesis of the card Q selected as the base card among the processes executed on condition that the card A is deleted from the possession card. is there.
The favorite registration is to put the card A into a state of being restricted from being used for the processing (including the evolutionary synthesis of the card Q selected as the base card) executed on the condition that the card A is deleted from the possession card.
Note that the reservation registration and the favorite registration are an example of a process of restricting a specified object, which is an object specified by a user, from being used for a predetermined process. The “predetermined process” is a process executed on condition that the designated object disappears from the possessed object. That is, the object designated from the possessed objects which are the objects possessed by the user are the objects to be restricted by the reservation registration and the favorite registration.

In this way, by presenting the acquisition conditions of the card A and then accepting the reservation registration or the favorite registration for the card A, the user immediately recognizes that the card A is a difficult-to-obtain card based on the presented acquisition conditions. In addition, it becomes possible to make a request for limiting the use of the card A from the possession card. Therefore, it is possible to surely prevent the card A from disappearing against the intention.

(5-2) Structure of Data Table Next, the possession card data table stored in the storage 25 of the game server 20 will be sequentially described with reference to FIG.

The possession card data table records information on the possession card of the user. FIG. 25 shows a configuration example of the possessed card data table. Although the possessed card data table for one user is illustrated in FIG. 25, the possessed card data table is provided corresponding to all the users registered in the game.
The possessed card data table of FIG. 25 is different from the possessed card data table of FIG. 8 in that registration type data is recorded in association with each card ID.
The registration information includes the type of registration (reservation registration or favorite registration) performed on the possessed card data, and the type of screen for which the registration request has been made (screen that presents acquisition conditions (hereinafter "acquisition condition presentation screen"")) or a reference card list screen necessary for evolutionary synthesis for each base card")). In the example of FIG. 25, “1” is recorded in the registration information for the card that has been reserved and registered via the acquisition condition presentation screen, and for the card that has been registered as a favorite via the acquisition condition presentation screen. "2" is recorded in the registration information,
"4" is recorded in the registration information for the card that has been registered as a favorite via the browsing screen, and "N/A" is recorded for the card for which neither reservation registration nor favorite registration has been performed.

(5-3) Specific Example of Display Processing of Game of Present Embodiment (5-3-1) Specific Example of Display Processing of Acquisition Condition Presentation Screen of Game of Present Embodiment (FIG. 26)
In the image P4 of FIG. 12A of the first embodiment, when the reference card for which the acquisition condition is to be displayed is selected and the button b8 is operated, as shown in FIG. 26, the reference card selected by the user is displayed. An image P5 corresponding to the acquisition condition presentation screen is displayed.

The image P5 of FIG. 26 differs from the first embodiment (image P5 of FIG. 12B) in that it includes a button b12 (“reservation registration”) and a button b13 (“favorite registration”).
The button b12 (“reservation registration”) is a button operated when the user requests reservation registration of the possession card.
The button b13 (“favorite registration”) is a button operated when the user requests favorite registration of the possessed card.

When the button b12 (“reservation registration”) is operated in the image P5, the image changes as shown in P21. The image P21 shows the execution result of the reservation registration process.
When the button b13 ("favorite registration") is operated in the image P5, the image changes as shown in P22. The image P22 shows the execution result of the favorite registration process.

(5-3-2) A specific example of the display process of the game change condition list screen of the present embodiment (FIG. 27A).
(Fig. 27C)
When the button b4 (“evolutionary synthesis”) in the image P1 of FIG. 12A of the first embodiment is operated, as shown in FIG. 27A, an image P23a corresponding to the change condition list screen of the present embodiment.
Is displayed. The image P23a is also referred to as a change condition list screen.

The image P23a includes a display area 105, a button b12 (“reservation registration”), and a button b13.
(“Favorite registration”). Button b12 ("reservation registration") and button b13 (
"Favorite registration") is the same as the image P5 in FIG.
In the display area 105, card images and card names of the base card and the reference card are displayed.
Displayed for each combination of base card and reference card. In other words, in the display area 105,
A reference card for each base card is displayed. In the example of FIG. 27A, the reference cards required for the evolutionary synthesis of the card KLM are the cards VIC, DSG, and MIT, and the reference cards required for the evolutionary synthesis of the card SAM are the cards MIT, KAY, and TED.
In the display area 105, possessed cards and uncarried cards of the reference cards are displayed in a distinguishable manner. In the example of FIG. 27A, the cards VIC, DSG, MIT, and KAY are displayed by solid lines indicating that they are possessed cards, and the card TED is displayed by a broken line that indicates that they are unowned cards.
Further, in the display area 105, a mark m1 is displayed on the card image of the card for which the reservation registration has been performed via the acquisition condition presentation screen. The mark m1 is a mark ("" displayed on the card image of a card that is restricted to be used for processes other than the evolution synthesis of the base card among the processes executed on the condition that the card is erased from the possession card. symbol"
, Also called "mark". ). In the example of FIG. 27A, the mark m1 is displayed on the card image of the card KLM and the card image of the card DSG. That is, FIG. 27A shows that the card DSG is in a state of being restricted from being used for processes other than the evolutionary synthesis of the card KLM among the processes executed on condition that the card DSG is deleted from the possessed card. ing.
Further, in the display area 105, a mark m2 is displayed on the card image of the card that is the target of the favorite registration performed via the browsing screen. The mark m2 is a mark displayed on the card image of a card that is restricted in use in processing (including evolutionary synthesis of the base card) executed on condition that the card is erased from the possessed card. In the example of FIG. 27A, the mark m2 is displayed on the card image of the card KAY. That is, FIG. 27A shows
The card KAY is restricted to be used for all the processes executed on condition that the card KAY is deleted from the possessed card (for example, the process of the evolution synthesis of the card SAM and the process of selling the card KAY). It shows that there is.
By selecting the card image, the user can select the card corresponding to the card image. In the example of FIG. 27A, when the card image b14 is selected, the card K
When the card MIT as the reference card required for the LM evolution synthesis is selected and the card image b15 is selected, the card M as the reference card required for the evolution synthesis of the card SAM.
IT is selected.
The user selects the card and then presses button b12 (“reservation registration”) or button b.
By operating 13 (“favorite registration”), reservation registration or favorite registration for the selected card can be requested. In the example of FIG. 27A, when the card image b14 is selected and the button b12 (“reservation registration”) or the button b13 (“favorite registration”) is operated,
Reservation registration or favorite registration for the card MIT as a reference card necessary for evolutionary synthesis of the card KLM is required.

In the image P23a, when the user selects the card image b14 and operates the button b12 (“reservation registration”), the image P23b is displayed. The image P23b is different from the image P23a in that the mark m3 is displayed on the card image of the card MIT as a reference card necessary for the evolutionary synthesis of the card KLM. The mark m3 is a mark indicating the reference card that is the target of the reservation registration performed via the change condition list screen.
The mark m4 is displayed on the card image of the card MIT as a reference card necessary for the evolutionary synthesis of the card SAM. The mark m4 is a mark indicating that reservation registration has been performed as a reference card required for evolutionary synthesis of another base card (card KLM).
In the example of FIG. 27B, the card MIT as a reference card necessary for the evolutionary synthesis of the card KLM.
The mark m3 is displayed on the card image of, and the mark m4 is displayed on the card image of the card MIT as a reference card necessary for the evolutionary synthesis of the card SAM. In this case, for the card MIT, of the processing executed on the condition that the card MIT is deleted from the possessed card, it is limited to be used for the processing other than the evolution synthesis of the card KLM. In other words, the card MIT can be used for the process of evolutionary synthesis of the card KLM, but the card SA
It cannot be used for the process of evolutionary synthesis or sale of M.

In the image P23a, when the user selects the card image b14 and operates the button b13 (“favorite registration”), the image P23c is displayed. The image P23c has the mark m5
Is displayed on the card image of the card MIT, which is different from the image P23a. The mark m5 is a mark indicating a reference card that is a target of favorite registration performed via the change condition list screen.
In the example of FIG. 27B, the card MIT as a reference card necessary for the evolutionary synthesis of the card KLM.
Card image and card MI as a reference card necessary for evolutionary synthesis of card SAM
The mark m5 is displayed on the T card image. In this case, for the card MIT,
Use of the card MIT for all the processes executed on condition that the card MIT is erased from the possession card is restricted. In other words, the card MIT is a card KLM evolution synthesis process, and the card SA
It cannot be used for either the evolutionary synthesis process of M or the sale process.

In the images P23a to P23c, the marks m1 to m5 are displayed in mutually distinguishable shapes, patterns, or a combination thereof. As a result, the user can refer to the reference card targeted for the reservation registration performed via the acquisition condition presentation screen, the reference card targeted for the favorite registration performed via the acquisition condition presentation screen, and the change condition. It becomes possible to easily identify the reference card that is the target of the reservation registration performed via the list screen and the reference card that is the target of the favorite registration performed via the change condition list screen.
Specifically, for the marks m1 to m5, the type of registration (reservation registration or favorite registration) is identified by the shape of the mark, and a screen for requesting registration (acquisition condition presentation screen or change condition) The list screen) is identified by the mark pattern.

(5-4) Processing flow of registration processing of this embodiment (FIG. 28)
Next, an example of the process flow of the game of this embodiment will be described with reference to the sequence chart of FIG. FIG. 28 is a sequence chart showing the registration process.
Note that, in FIG. 28, the reference numerals of the images are attached to the steps in which the images P5, P21, and P22 shown in FIG. 26 are displayed. Also, in FIG. 28, the same processing as that in FIG. 16B is denoted by the same reference numeral.

In the registration process described below, a reservation registration process or a favorite registration process is performed as an example of a process for restricting use of a specified object, which is an object specified by a user, in a predetermined process. Suppose you request it.

After S48 (FIG. 16B) of the first embodiment is executed, the CPU 21 of the game server 20
Is the button b12 (“reservation registration”) or the button b13 displayed on the image P5 of FIG.
Based on the user's operation for (“favorite registration”), the request for the reservation registration process or the request for the favorite registration process is accepted (S170), and the request is transmitted to the game server 20 (S171).
The image P5 of FIG. 26 is an output for displaying the acquisition conditions of the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object. It is an example of data.
The reservation registration processing request includes the user ID, the base card serial number, the reference card serial number, and the type of image displayed when the reservation registration processing request is made (for example, FIG. Information identifying the image P5 of 26 or the image P23a of FIG. 27A (ie,
Information for identifying the type of screen that has been passed through to request the reservation registration process) and information for identifying the request for the reservation registration process.
The request for the favorite registration process includes the user ID, the serial number of the reference card, and the type of image displayed when the request for the favorite registration process is made (for example, image P5 in FIG. 26 or FIG. 27A). Image P23a) (that is, information that identifies the type of screen through which a request for favorite registration processing has been made) and information that specifies a request for favorite registration processing are included. ..
The request for the reservation registration process and the request for the favorite registration process are examples of requests for restricting the specified object, which is the object specified by the user, from being used for the predetermined process.

Upon receiving the request from the user terminal 10, the CPU 21 of the game server 20 executes the registration (reservation registration or favorite registration) processing according to the request (S172).
The process of S172 is an example of a process of restricting the designated object from being used for a predetermined process.

If the request accepted in S170 is a request for reservation registration processing, the CPU 21 executes the acquisition condition presentation screen for the possessed card data specified by the serial number of the reference card included in the request. The registration information (registration information “1” in FIG. 25) indicating that the card is the target of the reserved registration that has been opened is recorded. Further, the CPU 21 records the serial number of the reference card in the column corresponding to the card ID of the reference card of C1 to C5 with respect to the reservation data specified by the serial number of the base card included in the request. To do. As a result, the serial number of the reference card subject to the reservation registration is recorded in the reservation data specified by the serial number other than the serial number of the base card subject to the reservation registration (that is, the reference card Reserve for evolutionary synthesis of base cards other than the base card, and delete from the possessed card data (that is, erase the reference card from the possessed card (for example, execute sale processing)).
Is limited.
On the other hand, if the request accepted in S170 is a request for favorite registration processing, CP
U21 is registration information indicating that the card is the target of favorite registration performed via the acquisition condition presentation screen for the possessed card data specified by the serial number of the reference card included in the request ( The registration information “2” in FIG. 25 is recorded. As a result, the serial number of the reference card to be registered as a favorite can be recorded in the reservation data table and deleted from the possessed card data (that is,
(Deleting the reference card from the possession card) is restricted.

Next, the CPU 21 transmits the execution result of the registration process to the user terminal 10 (S173).
).

Upon receiving the execution result of the registration process from the game server 20, the CPU 11 of the user terminal 10 displays a screen based on the execution result (S174). Thereby, the user terminal 1
The image P21 or P22 of FIG. 26 is displayed on the display unit 16 of 0.
It should be noted that S174 is a process of outputting data for displaying an object which is a target of restriction by reservation registration and an object which is a target of restriction by favorite registration in a display format in which the user can identify each. Is an example.

By using the registration information of FIG. 25, as shown in FIGS. 27A to 27C, marks m1 to m
5, it is possible to display the type of registration and the type of screen displayed when the registration request is made so that the user can identify the type. For example, when the user operates the button b4 (“evolutionary synthesis”) of the image P1 of FIG. 12A, when the reservation registration process is executed in S172, the image P23b of FIG. 27B is displayed on the display unit 16. When the favorite registration process is executed in S172, the image P23c of FIG. 27C is displayed.

As described above, the game server 20 of the present embodiment is
A request for a reservation registration process to restrict that the reference card in possession is used for processes other than the evolution synthesis of the base card, or a process executed on the condition that the reference card is deleted from the possession card ( A request for a favorite registration process for restricting the use of the base card (including the process of evolutionary synthesis) is accepted.
This allows the user to make the reference card unintentionally disappear immediately after recognizing that it is difficult to obtain the reference card that the user has on the acquisition condition presentation screen. ..
In particular, the greater the number of base cards and the number of reference cards used for evolutionary synthesis of the base card, the more difficult it is for a user to manage which reference card should be used for evolutionary synthesis of which base card. Become. As a result, the user may lose the reference card against the user's intention due to an operation error or forgetting the purpose of the reference card.
On the other hand, in the present embodiment, immediately after the user recognizes that the reference card is difficult to obtain from the acquisition condition presentation screen, the reference card is executed on the condition that the reference card disappears. A request can be made to limit what is used for the processing performed. Therefore, it is possible to reliably prevent the reference card from disappearing contrary to the user's intention.

Further, in this embodiment, the user can request two types of registration (reservation registration and favorite registration). Therefore, the user can properly use the registration depending on the purpose (that is, select the range of restriction to be applied to the reference card). For example, a user who wants to use the reference card in the evolutionary synthesis of a specific base card can prevent the reference card from being lost by executing a process other than the evolutionary synthesis of the specific base card by making a reservation registration request. You can Also, without deciding the base card to evolve using the reference card,
A user who wants to prevent the reference card from disappearing can surely prevent the reference card from disappearing by making a request for favorite registration. Therefore, the user can flexibly manage the usage of the reference card.

Further, the game server 20 of the present embodiment is performed on the change condition list screen via the reference card that is the target of the reservation registration performed via the change condition list screen and the acquisition condition presentation screen. The reference card that is the target of favorite registration is displayed in a distinguishable manner.
Furthermore, the game server 20 of the present embodiment displays the combination of the base card and the reference card for which the reservation registration has been made in a distinguishable manner.
Further, the game server 20 of the present embodiment displays the reference card that is the target of the reservation registration and the reference card that is the target of the favorite registration in a distinguishable manner.
This allows the user to visually understand the purpose of the possessed card (specifically, it is used for evolutionary synthesis of a specific base card, or is retained although the purpose is undecided). Become.

(5-5) Modified Example of Present Embodiment A modified example of the present embodiment will be described below. The following modifications can be combined as appropriate.
(5-5-1) First Modification In this embodiment, the case where the reference card to be registered (reservation registration or favorite registration) is a possession card has been described. However, in this embodiment, the reference card to be registered may be an uncarried card.
For example, the change condition list screen is configured to be able to receive a reservation registration request or a favorite registration request. When the request is accepted via the change condition list screen, after the user obtains the card to be requested (that is, the card ID and serial number of the card are recorded in the possessed card data table). , Reservation registration processing or favorite registration processing is executed for the card.

(5-5-2) Second Modification In the present embodiment, an example in which the marks m1 to m5 are displayed on the change condition list screen has been described. However, the marks m1 to m5 are displayed on a screen other than the change condition list screen. May be.

As an example, an acquisition condition presentation screen (for example, an image P showing the execution result of the reservation registration process) is displayed.
21 or the mark m1 to the image P22) showing the execution result of the favorite registration process.
You may display m5.

As another example, the marks m1 to m5 may be displayed on a screen showing a list of possessed cards (hereinafter referred to as “owned card list screen”).
Specifically, when the button b1 (“view possessed monster”) in the image P1 is operated, a possessed card list screen is displayed. On the possessed card list screen, information about the possessed card (for example, a card image and a card name) is displayed in a list, as in the change condition list screens of FIGS. 27A to 27C. Of the possessed cards, any of the marks m1 to m5 is displayed on the card image of the card that is the target of the reservation registration or the favorite registration.

(5-5-3) Third Modification In the present embodiment, an example has been described in which a request for reservation registration or favorite registration for a selected card is received, but a request for canceling registration for the card is also received. Good.

For example, when the user selects a card image on which any of the marks m1 to m5 of FIGS. 27A to 27C is displayed, the card corresponding to the selected card image (that is,
A request for canceling reservation registration or favorite registration for a card which is in the state of reservation registration or favorite registration is accepted. Specifically, in FIG. 27A, when the card image on which the mark m1 is displayed is selected, the card DSG for which the reservation registration has been made is in the selected state and is specified when the registration cancellation request is issued. Button is displayed. At this time,
When the user operates the button, the reservation registration made for the card DSG is canceled, and the mark m1 displayed on the card image disappears. As a result, the card DS
G is in a state where no registration is made (that is, a state in which it can be used for all processes).

According to this modification, it is possible to cancel the favorite registration and make the reservation registration for the reference card that is the target of the favorite registration performed when the use is not decided.
Further, the reservation registration can be canceled and the favorite registration can be performed with respect to the reference card which is the target of the reservation registration performed when the use for the evolutionary synthesis for the specific base card is determined. Therefore, the user can flexibly manage the use of the reference card and the range of the restrictions imposed on the reference card.

(5-5-4) Fourth Modification In the present embodiment, as shown in FIGS. 26 and 27A to 27C, the button b12 (
The example in which "reservation registration") and the button b13 ("favorite registration") are displayed side by side has been described, but only one of these two buttons may be displayed.

(5-5-5) Fifth Modification In this embodiment, an example in which a request for reservation registration or favorite registration processing is made via the acquisition condition presentation screen as shown in the image P5 of FIG. 26 has been described. However, the image P2 in FIG.
The request may be made via the change condition list screen as shown in 3a. Hereinafter, an example of registration processing when the request is made via the change condition list screen will be described with reference to FIG. 28.

Specifically, when the user operates the button b12 (“reservation registration”) or the button b13 (“favorite registration”) while the card image b14 of the image P23a is selected, the CPU 11 of the user terminal 10 Based on the operation, the request for the reservation registration process or the request for the favorite registration process is accepted (S170), and the request is transmitted to the game server 20 (S171).

Upon receiving the request from the user terminal 10, the CPU 21 of the game server 20 executes the registration (reservation registration or favorite registration) processing according to the request (S172), and displays the execution result of the registration processing as the user terminal 10 (S173).

Upon receiving the execution result of the registration process from the game server 20, the CPU 11 of the user terminal 10 displays a screen based on the execution result (S174). Thereby, the user terminal 1
The image P23b of FIG. 27B or the image P23c of FIG. 27C is displayed on the display unit 16 of 0.

As described above, the registration process in this modification is performed by four types of registration (reservation registration performed via the acquisition condition presentation screen, favorite registration performed via the acquisition condition presentation screen, and change condition list screen). Processing of reservation registration performed via the, and favorite registration performed via the change condition list screen. On each screen, information about the card is displayed in a display format that allows the user to identify the four types of registration.

(6) Sixth Embodiment In the above-described embodiment, HTTP communication is performed between the user terminal 10 and the game server 20, and the user terminal 10 interprets the HTML document acquired from the game server 20. The case where the present invention is realized by a so-called browser format in which a game image is displayed in is explained, but the present invention is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the user terminal 1
It may be realized by a so-called native application format in which transmission/reception processing between 0 and the game server 20 is suppressed. In the native application format, the CPU 11 of the user terminal 10 generates image data without using a web browser, and the display unit 16
Display the image on.
In the present embodiment, an example in which the game according to the above-described embodiment is realized in a native application format will be described. The hardware configuration of this embodiment may be the same as that of the first embodiment. In the native application format of the present embodiment, it is assumed that most of the processing is performed on the user terminal 10 side, but a part of the game processing not described below (for example, a lottery processing to be given to the user by lottery, For the present process in which the game operator gives a card to the user), the process is executed on the game server 20 side,
The processing result by the game server 20 may be transmitted to the user terminal 10.

In the present embodiment, the user terminal 10 receives the game program from the server of the game operator based on a predetermined operation by the user, and the received game program is stored in the storage 18. When the game is started by the user terminal 10, communication is established between the user terminal 10 and the game server 20 and a login process is performed, and a data table group (card data table, evolution) is transmitted from the game server 20 to the user terminal 10. The combined data table, possessed card data table, possessed history data table, and card distribution data table) are transmitted. The data table group transmitted to the user terminal 10 is held in the storage 18 of the user terminal 10. In this case, the data table group in the storage 18 is updated each time login is performed.
In order to prevent the possession card data table from being tampered with in the user terminal 10,
The possessed card data table in the user terminal 10 is transmitted to the game server 20 every time a predetermined process is completed by the user terminal 10 or when the user logs out from the game.
The game server 20 compares the received possession card data table with the possession card data table in the storage 25, and after confirming that the data has not been tampered with,
The possession card data table in the storage 25 is updated based on the received possession card data table.

29A and 29B are sequence charts showing the acquisition condition presentation processing of this embodiment. 29A and 29B, the same processes as those in FIGS. 16A and 16B are designated by the same reference numerals.
In the evolutionary synthesis reservation process (FIGS. 29A and 29B) of the present embodiment, for example, at the time of login, the game server 20 sends the user terminal 10 a data table group (card data table, evolutionary synthesis data table, possessed card) in the storage 25. The data table, the possession history data table, and the card distribution data table) are transmitted (S8). User terminal 10
The CPU 11 stores the received data table group in the storage 18, and based on the operation input from the operation input unit 15, cooperates with the RAM 13 and the display unit 16 and the like in S14.
~ The process of S48 is executed.
Although not shown, in the present embodiment, the evolutionary synthesis process, the quest process, and the evolutionary synthesis reservation process are also executed by the user terminal 10 in the same manner.
In the present embodiment, the card data table, the evolutionary synthesis data table, the quest data table, the possession card data table, the possession history data table, and the card distribution data table are held in the game server 20, and the reservation data table is the user terminal 10.
In the above description, the case of being held is described, but it is not limited to this case. In the game in the native application format, the sharing of each data table can be set as appropriate, and may be held in at least one of the user terminal 10 and the game server 20. It is not limited to. When any of the data tables is held in the game server 20, the data table held in the game server 20 is transmitted to the user terminal 10 when the game is executed, and is used for the processing of the game performed in the user terminal 10. To be done.

(7) Modifications Common to All Embodiments (7-1) Modifications Related to Application to Applications Other than Games In the above-described embodiments and modifications, the case where the present invention is applied to games has been described. It may be applied to other applications. For example, when a plurality of types of electronic coupons are distributed every time a product is purchased at a shopping mall on the Internet, the electronic coupons may be an example of the object of the present invention. In this case, for example, in order to upgrade the privilege content of the coupon ticket Q as the base object (an example of a process of changing the object), the coupon ticket A as the reference object corresponding to the coupon ticket Q.
It is conceivable that the user possesses and uses C. In this example, for the purpose of upgrading the coupon ticket Q, of the coupon tickets A to C necessary for upgrading the coupon ticket Q, the acquisition condition of the coupon ticket (for example, coupon ticket B) that the user does not possess is presented.
The present invention can be appropriately applied to applications other than the examples described above.

(7-2) Modification of Operation Input Method In the above-described embodiment, the predetermined operation input to the user terminal is a pressing operation of a predetermined instruction button on the user terminal, or a display on the user terminal having a touch panel function. Although the input is a touch operation on the screen, the operation input is not limited to this. The operation input may be an operation input by shaking a user terminal including an acceleration sensor or an operation input by a gesture (gesture input). In the gesture input, the user terminal performs image recognition of the gesture by performing a predetermined gesture on the user terminal having an imaging function,
The operation input previously associated with the gesture is recognized. Further, in the case of a user terminal capable of executing the voice recognition program, the operation input may be performed by inputting voice.

(7-3) Modified Example Regarding Handling of User ID In the above-described embodiment, the user ID is included in the request transmitted from the user terminal 10 to the game server 20 (that is, the game server 20 receives from the user terminal 10). However, the method by which the game server 20 specifies the user who has made the processing request is not limited to this.
For example, when a session based on the user ID is established between the user terminal 10 and the game server 20, the game server 20 may identify the user who requests the processing after the session by the user ID. .. In this case, the user ID does not have to be included in the request transmitted from the user terminal 10 to the game server 20 (that is, the user ID does not have to be transmitted from the user terminal 10 to the game server 20).

(7-4) Modified Example Concerning Operation Target In the above-described embodiment, the button displayed on the image is shown as an example of the operation target by the user, but in any format that can be operated by the user It may be.

[Summary of Invention]
From the above description, the present invention is understood as follows, for example.

One aspect of the present invention is
In an information processing device that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for the process of changing the object in association with each other,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Output means (56) for outputting output data,
Receiving means (51) for receiving an instruction for designating any one of the plurality of objects based on the user's instruction, in response to the output means (56) outputting the first output data. ,,
The output means (56) further displays the acquisition condition of the designated object when the user does not have the designated object which is the object designated by the instruction accepted by the acceptance means (51). Output the second output data of
Information processing device.

The “information processing device” may be a stand-alone game machine, a user terminal (for example, a mobile terminal or a personal computer), a server on a network, or the like. The substance of the information processing device can be appropriately defined depending on the game implementation mode. For example, when the functions of the respective units of the information processing apparatus are realized by the user operating the game machine or the user terminal, the game machine and the user terminal correspond to the information processing apparatus of the present invention. Alternatively, when the user terminal, which is a client, has a function of receiving an operation input from a user and displaying an image, and the functions of each unit of the information processing apparatus are substantially realized by a server that can communicate with the user terminal, The server corresponds to the information processing device of the present invention.
The “storage device” may be a memory device of any configuration, such as a flash memory or an HDD (Hard Disk Drive). Further, the storage device may be a device built in the information processing device, or an external device configured to be accessible from the information processing device in a wired or wireless manner.
The “acquisition condition” is a subjective condition (for example, information about a user who owns an object), a temporal condition (for example, an object availability period), a content condition (for example, an average transaction price, the first object). It may be a second object (for example, an item) necessary for obtaining (for example, a card) or a combination thereof, a positional condition (for example, an available area), or a combination thereof.

In the information processing apparatus, the process of changing the selected object is performed based on the change condition including information indicating at least a plurality of objects and the possession information of the user. Therefore, for example, when the change condition is not satisfied, the process of changing the selected object cannot be executed. At this time, it may be impossible or difficult for the user to obtain the designated object that the user does not own. However, the user who does not know the acquisition condition of the specified object determines whether the acquisition of the specified object is impossible or difficult, and determines whether or not to execute a process for acquiring the specified object (for example, a quest process). Unrecognizable at the time. In such a case, the user executes the process for obtaining the designated object while having a fear that the reference object may be impossible or difficult to obtain in practice.
In the information processing apparatus, the acquisition condition of the reference object that the user does not possess is presented in response to the request from the user. Therefore, even if there is a designated object that is not available or difficult for the user among the reference cards corresponding to the selected object, the user recognizes that the designated object is not available or difficult. Above, it is possible to decide whether or not to execute the process for obtaining the designated object. As a result, it is possible to give a sense of security to the user who executes the process for obtaining the designated object.

The reception means (51) further outputs the selected object to the designated object based on the operation by the user in response to the output of the second output data by the output means (56). Accepts a request to restrict the use of other processes than changing,
In response to the request being received by the receiving unit (51), a limiting unit (58) for limiting the specified object from being used for a process other than a process for changing the selected object is further provided. May be.
"Restricting the use of processing that is different from the processing that changes the selected object" is not limited to the prohibition of processing itself other than the processing that changes the selected object, and the processing that changes the selected object can be executed. However, it is also possible to increase the requirements required for the execution request of the processing, or to complicate the operation required for the execution request of the processing.
This restricts the designated object from being used in processes other than the process of changing the selected object in response to a request from the user. Therefore, it is possible to prevent the user from accidentally using the designated object for a process other than the process of changing the selected object before the change condition is satisfied.

The acquisition condition may be an acquisition route of the designated object.
The “obtaining route” may be, for example, an area where the designated object can be obtained, or an area where the object can be traded between users (for example, a shop in the game).
The “acquisition route” is a combination of a time condition and a location condition (for example, information indicating whether or not a specified object is issued for a limited time period (for example, a limited flag), a limited time available area. (For example, the day of the week on which the limited-time quest is held), or a combination thereof.
As a result, it is possible to give a sense of security to the user who executes the process for obtaining the designated object. In particular, if the "acquisition path" is a combination of a temporal condition and a locational condition, is it difficult or difficult for the specified object to be acquired when the user makes a request to execute a process that changes the selected object? It is particularly useful because it provides information to more accurately determine whether or not.

The second output data may include an operation target for guiding the user to the acquisition route.
As a result, it is possible to improve the operability when requesting the execution of the process for obtaining the designated object.

The second output data has not been possessed by the user when the designated object has been possessed by the user and the information indicating the designated object has been acquired by the acquisition means (55). When the object is an uncarried object, it may include at least one of an acquisition route and an acquisition difficulty level of the designated object.
As a result, it is possible to give a sense of security to the user who executes the process for obtaining the uncarried object.

The information displayed as the acquisition condition may be limited when the designated object is an unknown object that has not been possessed by the user compared to when the designated object is the uncarried object.
As a result, it is possible to give a feeling of security to the user who executes the process for obtaining the unknown object while keeping the difficulty level of the game at an appropriate level.

Another aspect of the invention is
A user terminal and a server configured to be communicable with the user terminal, and object identification information for specifying an object, and a change condition including a plurality of object identification information used for a process of changing the object. An information processing system capable of accessing a storage device which is associated and stored,
Either of the user terminal and the server,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Output means (56) for outputting output data,
Receiving means (51) for receiving an instruction for designating any one of the plurality of objects based on the user's instruction, in response to the output means (56) outputting the first output data. ,,
The output means (56) further displays the acquisition condition of the designated object when the user does not have the designated object which is the object designated by the instruction accepted by the acceptance means (51). Output the second output data of
It is an information processing system.

Another aspect of the invention is
A computer that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used in a process of changing the object in association with each other,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Means for outputting output data (56),
A unit (51) for receiving an instruction for designating any one of the plurality of objects based on the instruction of the user in response to the output of the first output data;
If the user does not have the designated object which is the object designated by the received instruction, the second display for displaying the acquisition condition of the designated object.
Means for outputting output data (56),
It is a program to function as.

Another aspect of the invention is
In an information processing device that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for the process of changing the object in association with each other,
A first output that outputs first output data for displaying acquisition conditions of a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to object identification information of a selected object that is a selected object Means and
In response to the output of the first output data by the first output means, a request for restricting the first designated object, which is the object designated by the user, from being used for a predetermined process is issued. First receiving means for receiving,
First restricting means for restricting the first designated object from being used for the processing in response to the request being accepted by the first accepting means,
An information processing apparatus including:

As a result, the user can put the reference card into a state where the reference card is not lost immediately after recognizing that the reference card is difficult to obtain on the screen showing the acquisition conditions. Therefore, it is possible to reliably prevent the reference card from disappearing against the intention.

A second output means for outputting second output data for displaying a plurality of objects in a display format that can be identified by the user;
In response to the output of the second output data by the second output means, the second specified object, which is an object specified by the user among the plurality of objects, is used for a predetermined process. Second accepting means for accepting a request for limiting,
A second limiting unit configured to limit the second designated object from being used for the processing in response to the request being received by the second receiving unit,
At least one of the first output data and the second output data includes an object that is a target of restriction by the first restriction unit and an object that is a target of restriction by the second restriction unit. The data may be data to be displayed in a display format that can be identified by the user.

Further, the object to be restricted is an object designated from among possessed objects which are objects possessed by the user,
The predetermined process may be a process executed on condition that the designated object disappears from the possession object.

"Processing executed on condition that the specified object disappears from the possessed object" means that the specified object disappears from the possessed object when the process is executed (that is, the specified object disappears). It becomes an unowned object)
, Processing.

Further, at least one of the request accepted by the first accepting unit and the request accepted by the second accepting unit must be deleted from the possessed object for the object to be restricted. A first request for restricting the use of the selected object in the process executed as a request, and a process other than the process of changing the selected object among the processes executed on the condition that the object is deleted from the possessed object. A second request for limiting may be included.

Each of the “processing for changing the selected object” and the “processing other than the processing for changing the selected object” is one aspect of the “processing executed on condition that the selected object disappears”.
The “first request” is a request for restriction on all processes executed on condition that the first designated object is deleted from the possessed object.
The “second request” is a restriction on all of the processes executed on condition that the first designated object disappears from the possessed object, except the process of changing the selected object (in other words, changing the selected object). It is a request to permit only the processing to be performed).

In addition, the second output data is data for displaying an object that is the target of the first request and an object that is the target of the second request in a display format that allows the user to identify each of them. May be

The "object that is the target of the first request" is an object whose use is restricted for all the processes executed on condition that the object is deleted from the possessed object (that is, a state in which the object cannot be deleted from the possessed object). Object placed in).
The "object which is the target of the second request" is restricted from being used for processes other than the process for changing the selected object (that is, only the use for the process for changing the selected object is permitted). ) Is an object.

Another aspect of the invention is
A user terminal and a server configured to be communicable with the user terminal, and object identification information for specifying an object, and a change condition including a plurality of object identification information used for a process of changing the object. An information processing system capable of accessing a storage device which is associated and stored,
Either of the user terminal and the server,
A first output that outputs first output data for displaying acquisition conditions of a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to object identification information of a selected object that is a selected object Means and
In response to the output of the first output data by the first output means, a request for restricting the first designated object, which is the object designated by the user, from being used for a predetermined process is issued. First receiving means for receiving,
First restricting means for restricting the first designated object from being used for the processing in response to the request being accepted by the first accepting means,
An information processing system including:

Another aspect of the invention is
A computer that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used in a process of changing the object in association with each other,
Means for outputting first output data for displaying the acquisition condition of the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object,
Means for accepting a request for restricting the first designated object, which is the object designated by the user, from being used in a predetermined process in response to the output of the first output data;
Means for restricting the first designated object from being used for the processing in response to the request being accepted,
It is a program that functions as.

In the above description, in order to facilitate understanding of the present invention, the reference numerals shown in the drawings are appropriately written in parentheses, but the information processing apparatus and the like according to the present invention are limited to the illustrated modes. Not a thing.

1... Game System 10... User Terminal 11... CPU
12...ROM
13... RAM
15... Operation input section 16... Display section 17... Communication interface section 18... Storage 19... Bus 20... Game server 21... CPU
22...ROM
23... RAM
24... Communication interface section 25... Storage 26... Bus 51... Receiving means 52... Game processing means 54... Card data changing means 55... Acquisition means 56... Output means 57... Recording means 58... Limiting means 70... Data table group

The possession card data table records information on the possession card of the user. FIG. 25 shows a configuration example of the possessed card data table. Although the possessed card data table for one user is illustrated in FIG. 25, the possessed card data table is provided corresponding to all the users registered in the game.
The possessed card data table of FIG. 25 is different from the possessed card data table of FIG. 8 in that registration type data is recorded in association with each card ID.
The registration information includes the type of registration (reservation registration or favorite registration) performed on the possessed card data, and the type of screen for which the registration request has been made (screen that presents acquisition conditions (hereinafter "acquisition condition presentation screen ")) or a reference card list screen necessary for evolutionary synthesis for each base card")). In the example of FIG. 25, “1” is recorded in the registration information for the card that has been reserved and registered via the acquisition condition presentation screen, and for the card that has been registered as a favorite via the acquisition condition presentation screen. the registration information "2" is recorded, for information about the card favorite registration via the card the list screen has been performed is recorded "4" in the registration information, not carried out any of the reservation registration and favorite registration card “N/A” is recorded in.

The image P23a includes a display area 105, a button b12 (“reservation registration”), and a button b13 (“favorite registration”). The button b12 (“reservation registration”) and the button b13 (“favorite registration”) are the same as those of the image P5 in FIG.
In the display area 105, card images and card names of the base card and the reference card are displayed for each combination of the base card and the reference card. In other words, the display area 105 displays the reference card for each base card. In the example of FIG. 27A, the reference cards required for the evolutionary synthesis of the card KLM are the cards VIC, DSG, and MIT, and the reference cards required for the evolutionary synthesis of the card SAM are the cards MIT, KAY, and TED.
In the display area 105, possessed cards and uncarried cards of the reference cards are displayed in a distinguishable manner. In the example of FIG. 27A, the cards VIC, DSG, MIT, and KAY are displayed by solid lines indicating that they are possessed cards, and the card TED is displayed by a broken line that indicates that they are unowned cards.
Further, in the display area 105, a mark m1 is displayed on the card image of the card for which the reservation registration is performed via the acquisition condition presentation screen. The mark m1 is a mark ("" displayed on the card image of a card that is restricted to be used for processes other than the evolution synthesis of the base card among the processes executed on the condition that the card is erased from the possession card. It is also referred to as "symbol", "mark", etc.). In the example of FIG. 27A, the mark m1 is displayed on the card image of the card KLM and on the card image of the card DSG. That is, FIG. 27A shows that the card DSG is in a state of being restricted from being used for processes other than the evolutionary synthesis of the card KLM among the processes executed on condition that the card DSG is deleted from the possessed card. ing.
Further, in the display area 105, a mark m2 is displayed on the card image of the card that is the target of favorite registration performed via the acquisition condition presentation screen. The mark m2 is a mark displayed on the card image of a card that is restricted in use in processing (including evolutionary synthesis of the base card) executed on condition that the card is erased from the possessed card. In the example of FIG. 27A, the mark m2 is displayed on the card image of the card KAY. That is, FIG. 27A is used for all the processes executed on the condition that the card KAY disappears from the possession card (for example, the process of the evolution synthesis of the card SAM and the process of selling the card KAY). Indicates that it is in a restricted state.
By selecting the card image, the user can select the card corresponding to the card image. In the example of FIG. 27A, when the card image b14 is selected, the card MIT as the reference card necessary for the evolutionary synthesis of the card KLM is in the selected state, and when the card image b15 is selected, the evolutionary synthesis of the card SAM is performed. The card MIT as a required reference card is selected.
The user can request reservation registration or favorite registration for the selected card by operating the button b12 ("reservation registration") or the button b13 ("favorite registration") after selecting the card. In the example of FIG. 27A, when the card image b14 is selected and the button b12 (“reservation registration”) or the button b13 (“favorite registration”) is operated, the card MIT as the reference card necessary for the evolutionary synthesis of the card KLM is displayed. Reservation registration or favorite registration is required.

Claims (15)

In an information processing device that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for the process of changing the object in association with each other,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Output means for outputting output data,
Receiving means for receiving an instruction for designating one of the plurality of objects based on the instruction of the user in response to the output of the first output data by the output means,
When the user does not have the designated object designated by the instruction received by the receiving unit, the output unit further outputs second output data for displaying the acquisition condition of the designated object. Output,
Information processing device. The reception unit further performs a process other than a process of changing the selected object with respect to the designated object based on an operation by the user in response to the output of the second output data by the output unit. Accept requests to limit what is used for
In response to the request being accepted by the accepting unit, a limiting unit that limits the specified object from being used in a process other than the process of changing the selected object is further provided.
The information processing apparatus according to claim 1. The acquisition condition is an acquisition route of the designated object,
The information processing apparatus according to claim 1. The second output data includes an operation target for guiding the user to the acquisition route.
The information processing apparatus according to claim 3. When the specified object is an uncarried object that the user has possessed in the past and the user does not currently possess, the second output data is the acquisition route of the specified object and At least one of the acquisition difficulty levels is included as the acquisition condition,
The information processing device according to claim 1. The information displayed as the acquisition condition is limited when the designated object is an unknown object which is an object that the user has never possessed, as compared with the case where the designated object is the uncarried object,
The information processing apparatus according to claim 5. A user terminal and a server configured to be communicable with the user terminal, and object identification information for specifying an object, and a change condition including a plurality of object identification information used for a process of changing the object. An information processing system capable of accessing a storage device which is associated and stored,
Either of the user terminal and the server,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Output means for outputting output data,
Receiving means for receiving an instruction for designating one of the plurality of objects based on the instruction of the user in response to the output of the first output data by the output means,
When the user does not have the designated object designated by the instruction received by the receiving unit, the output unit further outputs second output data for displaying the acquisition condition of the designated object. Output,
Information processing system. A computer that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used in a process of changing the object in association with each other,
Based on the user's instruction, the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object is displayed in a display format in which the user can respectively identify First to let
Means for outputting output data,
A unit that receives an instruction to specify any one of the plurality of objects based on an instruction from the user in response to the output of the first output data;
If the user does not have the designated object which is the object designated by the received instruction, the second display for displaying the acquisition condition of the designated object.
Means for outputting output data,
Program to function as. In an information processing device that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used for the process of changing the object in association with each other,
A first output that outputs first output data for displaying acquisition conditions of a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to object identification information of a selected object that is a selected object Means and
In response to the output of the first output data by the first output means, a request for restricting the first designated object, which is the object designated by the user, from being used for a predetermined process is issued. First receiving means for receiving,
First restricting means for restricting the first designated object from being used for the processing in response to the request being accepted by the first accepting means,
An information processing device comprising: Second output means for outputting second output data for displaying a plurality of objects in a display format that can be identified by the user,
In response to the output of the second output data by the second output means, the second specified object, which is an object specified by the user among the plurality of objects, is used for a predetermined process. Second accepting means for accepting a request for limiting,
A second limiting unit configured to limit the second designated object from being used for the processing in response to the request being received by the second receiving unit,
At least one of the first output data and the second output data includes an object that is a target of restriction by the first restriction unit and an object that is a target of restriction by the second restriction unit. The information processing apparatus according to claim 9, which is data for displaying in a display format that can be identified by a user. The object to be restricted is an object specified from among possessed objects which are objects possessed by the user,
The information processing apparatus according to claim 9, wherein the predetermined process is a process executed on condition that the designated object is deleted from the possessed object. At least one of the request accepted by the first accepting unit and the request accepted by the second accepting unit is executed on condition that the object to be restricted is deleted from the possessed object. A first request for limiting the use of the selected object, or limiting the use of a process other than the process of changing the selected object among the processes executed on the condition that the object is deleted from the possessed object. The information processing apparatus according to claim 11, which is a second request for causing the request. The second output data is data for displaying the object that is the target of the first request and the object that is the target of the second request in a display format that allows the user to identify each. The information processing apparatus according to claim 12. A user terminal and a server configured to be communicable with the user terminal, and object identification information for specifying an object, and a change condition including a plurality of object identification information used for a process of changing the object. An information processing system capable of accessing a storage device which is associated and stored,
Either of the user terminal and the server,
A first output that outputs first output data for displaying acquisition conditions of a plurality of objects specified by a plurality of object identification information included in a change condition corresponding to object identification information of a selected object that is a selected object Means and
In response to the output of the first output data by the first output means, a request for restricting the first designated object, which is the object designated by the user, from being used for a predetermined process is issued. First receiving means for receiving,
First restricting means for restricting the first designated object from being used for the processing in response to the request being accepted by the first accepting means,
An information processing system including: A computer that is accessible to a storage device that stores object identification information that identifies an object and a change condition that includes a plurality of object identification information used in a process of changing the object in association with each other,
Means for outputting first output data for displaying the acquisition condition of the plurality of objects specified by the plurality of object identification information included in the change condition corresponding to the object identification information of the selected object which is the selected object,
Means for accepting a request for restricting the first designated object, which is the object designated by the user, from being used in a predetermined process in response to the output of the first output data;
Means for restricting the first designated object from being used for the processing in response to the request being accepted,
A program that functions as a.

Images