JP7553164B2 - Program, information processing method and game system - Google Patents

Description

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

In recent years, so-called social games have become popular as applications executed on social networking services (SNSs). As such social games, digital card games that use cards are known.
There is also known a game in which a user selects a main card and a sub card from among the cards owned by the user, and the main card and the sub card are combined to change the ability parameters of the main card and delete the sub card from the user's cards (Patent Documents 1 and 2).

Patent No. 5086491 Patent No. 5153960

In the compositing process, in order to realize the compositing process of a base object (corresponding to the main card described above), it may be required that the user possesses multiple reference objects (corresponding to the sub-cards described above) that satisfy the combination conditions corresponding to the base object. In such a case,
The user must have all the reference objects that satisfy the combination conditions in order to perform the composition process.

In this case, it may be impossible or difficult for a user to obtain a reference object that the user does not possess. However, a user who does not know the conditions for obtaining the reference object cannot recognize that it is impossible or difficult to obtain the reference object at the time of deciding whether or not to execute a process for obtaining the reference object. In such a case, the user will execute the process for obtaining the reference object while being anxious that it may actually be impossible or difficult to obtain the reference object.

The present invention has been made in consideration of the above-mentioned viewpoints, and its object is to provide an information processing device, program, and information processing system that eliminates the anxiety felt by users in the process of obtaining a reference object required for a process of changing an object, which is executed when a change condition including at least information indicating a plurality of objects is satisfied.

One aspect of the present invention is
An information processing device that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process of changing the object, in association with each other, comprising:
a first display format for displaying 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, which is an object selected based on a user's instruction, in a display format that is identifiable by the user;
An output means for outputting output data;
a receiving means for receiving an instruction to designate one of the plurality of objects based on an instruction from the user in response to the first output data being output by the output means,
The output means further outputs second output data for displaying a condition for acquiring a designated object, the designated object being an object designated by the instruction accepted by the accepting means, when the user does not possess the designated object.
It is an information processing device.

Another aspect of the present invention is a method for producing a
An information processing device that can access a storage device that stores object identification information for identifying an object and a change condition including a plurality of object identification information used in a process for changing the object, the information processing device comprising:
The information processing device includes an output means for outputting output data for displaying, based on a user's instruction, a plurality of objects identified by a plurality of object identification information included in a change condition corresponding to the object identification information of a selected object, which is a selected object, and acquisition conditions for an object among the plurality of objects that the user does not possess, in a display format that can be individually identified by the user.

Another aspect of the present invention is a method for producing a
An information processing device that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process of changing the object, in association with each other, comprising:
a first display format for displaying 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, which is an object selected based on a user's instruction, in a display format that is identifiable by the user;
An output means for outputting output data;
a receiving means for receiving an instruction to designate one of the plurality of objects based on an instruction from the user in response to the first output data being output by the output means,
The output means further outputs second output data for displaying a degree of difficulty in acquiring a designated object, the designated object being an object designated by the instruction accepted by the accepting means, when the user has never possessed the designated object.
It is an information processing device.

Another aspect of the present invention is a method for producing a
An information processing system including a user terminal and a server configured to be able to communicate with the user terminal, the information processing system being able to access a storage device that stores object identification information for identifying an object and a change condition including a plurality of object identification information used in a process for changing the object, in association with each other, the information processing system comprising:
Either the user terminal or the server,
a first display format for displaying 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, which is an object selected based on a user's instruction, in a display format that is identifiable by the user;
An output means for outputting output data;
a receiving means for receiving an instruction to designate one of the plurality of objects based on an instruction from the user in response to the first output data being output by the output means,
The output means further outputs second output data for displaying a condition for acquiring a designated object, the designated object being an object designated by the instruction accepted by the accepting means, when the user does not possess the designated object.
It is an information processing system.

Another aspect of the present invention is a method for producing a
A computer that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process of changing the object, in association with each other.
a first display format for displaying 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, which is an object selected based on a user's instruction, in a display format that is identifiable by the user;
A means for outputting output data;
a means for receiving an instruction to designate one of the plurality of objects based on an instruction from the user in response to the first output data being output;
a second display for displaying a condition for acquiring a designated object, the designated object being an object designated by the received instruction, when the user does not possess the designated object;
A means for outputting output data;
This is a program that functions as a

Another aspect of the present invention is a method for producing a
An information processing device that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process of changing the object, in association with each other, comprising:
a first output means for outputting 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 which is a selected object;
a first receiving means for receiving a request to restrict a first designated object, which is an object designated by a user, from being used in a predetermined process in response to the first output data being output by the first output means;
a first restriction means for restricting the first specified object from being used in the process in response to the request being accepted by the first acceptance means;
The information processing device includes:

Another aspect of the present invention is a method for producing a
An information processing system including a user terminal and a server configured to be able to communicate with the user terminal, the information processing system being able to access a storage device that stores object identification information for identifying an object and a change condition including a plurality of object identification information used in a process for changing the object, in association with each other, the information processing system comprising:
Either the user terminal or the server,
a first output means for outputting 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 which is a selected object;
a first receiving means for receiving a request to restrict a first designated object, which is an object designated by a user, from being used in a predetermined process in response to the first output data being output by the first output means;
a first restriction means for restricting the first specified object from being used in the process in response to the request being accepted by the first acceptance means;
The information processing system includes:

Another aspect of the present invention is a method for producing a
A computer that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process of changing the object, in association with each other.
a means for outputting 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 which is a selected object;
a means for receiving a request for restricting a first designated object, which is an object designated by a user, from being used in a predetermined process in response to the first output data being output;
means for restricting the first specified object from being used in the process in response to the request being accepted;
It is a program that functions as a

FIG. 1 is a diagram showing a basic configuration of a game system according to a first embodiment. FIG. 2 is a block diagram showing a configuration of a user terminal according to the first embodiment. FIG. 2 is a block diagram showing the configuration of a game server according to the first embodiment. 6 is a diagram for conceptually explaining the presentation of conditions for obtaining a reference card in the first embodiment; FIG. FIG. 4 is a diagram showing an example of the configuration of a card data table according to the first embodiment; FIG. 13 is a diagram showing an example of the configuration of an evolutionary synthesis data table according to the first embodiment. FIG. 4 is a diagram showing an example of the configuration of a quest data table according to the first embodiment. FIG. 4 is a diagram showing an example of the configuration of a possessed card data table according to the first embodiment; FIG. 4 is a diagram showing an example of the configuration of a reservation data table according to the first embodiment; FIG. 4 is a diagram showing an example of the configuration of a possession history data table according to the first embodiment. FIG. 4 is a diagram showing an example of the configuration of a card circulation data table according to the first embodiment. FIG. 4 is a diagram showing an example of an image displayed on a user terminal when playing the game of the first embodiment. FIG. 4 is a diagram showing an example of an image displayed on a user terminal when playing the game of the first embodiment. FIG. 4 is a diagram showing an example of an image displayed on a user terminal when playing the game of the first embodiment. FIG. 4 is a diagram showing an example of an image displayed on a user terminal when playing the game of the first embodiment. FIG. 4 is a diagram showing an example of an image displayed on a user terminal when playing the game of the first embodiment. FIG. 2 is a functional block diagram of the game server according to the first embodiment. 6 is a sequence chart showing an example of a process for presenting acquisition conditions according to the first embodiment; 6 is a sequence chart showing an example of a process for presenting acquisition conditions according to the first embodiment; 11 is a sequence chart showing an example of an evolutionary synthesis process according to the first embodiment; FIG. 11 is a diagram showing an example of an image displayed on a user terminal when a game of the second embodiment is being played. 13 is a sequence chart showing an example of a quest process according to the second embodiment; FIG. 13 is a diagram showing an example of an image displayed on a user terminal when a game of the third embodiment is being played. 13 is a sequence chart showing an example of a reservation process for evolutionary synthesis according to the third embodiment; FIG. 13 is a diagram showing an example of an image displayed on a user terminal when a game according to a fourth embodiment is being played. 13 is a sequence chart showing an example of a process for presenting acquisition conditions according to the fourth embodiment; FIG. 13 is a diagram for conceptually explaining reservation registration and favorite registration of a reference card in the fifth embodiment. FIG. 23 is a diagram showing an example of the configuration of a possessed card data table according to the fifth embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal when playing a game according to the fifth embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal when playing a game according to the fifth embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal when playing a game according to the fifth embodiment. FIG. 13 is a diagram showing an example of an image displayed on a user terminal when playing a game according to the fifth embodiment. 13 is a sequence chart showing an example of a registration process according to the fifth embodiment; 23 is a sequence chart showing an example of a process for presenting acquisition conditions according to the sixth embodiment; 23 is a sequence chart showing an example of a process for presenting acquisition conditions according to the sixth embodiment;

(1) First Embodiment (1-1) Configuration of Game System Hereinafter, a game system 1 will be described as one embodiment of an information processing system.

Fig. 1 shows an example of the system configuration of a game system 1 according to an 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 of the user terminals 10a, 10b, 10c via 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 is, for example, a communication terminal such as a feature phone, a smartphone, a tablet terminal, a personal computer, a television receiver with a two-way communication function (including a so-called multi-function smart TV), a portable game machine with a communication function, etc. In the following description, when referring to each of the user terminals 10a, 10b, 10c, ... in common, they will be referred to as the user terminal 10.

The game server 20 is a server that executes a game. A program capable of creating image data that can be interpreted by a web browser (e.g., image data described in a format such as HTML or XML. In the embodiment of the present invention, HTML data will be used as an example for explanation) is installed in the game server 20.
The user terminal 10 is equipped with a web browser that interprets and displays HTML data provided by the game server 20, and transmits requests based on user operations on a web page by the user terminal 10 to the game server 20 via the network, and the game server 20
The game processing is executed by receiving the processing results from the.
The communication network NW includes the Internet, WAN (Wide Area Network), LAN (Local Area Network),
A communications network is an information and communications network that is composed of a private line, a private network, a private line, or a combination of these.

(1-2) Configuration of the 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,
The device is equipped with 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, and is provided with a bus 19 for transmitting control signals or data signals between each unit.

The CPU 11 reads out programs and data stored in the ROM 12, and controls the overall operation of 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 out programs stored in the storage 18 and various data required for executing the programs, expands them in the RAM 13, and performs various processes such as data input/output processing, arithmetic processing, and judgment processing associated with the execution of the programs. The RAM 13 temporarily stores data for arithmetic processing, judgment processing, etc. by the CPU 11.

For example, the CPU 11 may execute a web browser stored in the storage 18 in the RAM 1
Then, the CPU 11 loads the program into the communication interface unit 17 based on a URL (Uniform Resource Locator) input by the user through the operation input unit 15 or the like.
The game server 20 transmits data for displaying a web page, i.e.,
The user terminal 10 acquires data of objects such as ML (HyperText Markup Language) documents and images associated with the documents (hereinafter collectively referred to as "HTML data") via the communication interface unit 17, and executes the web browser to interpret the HTML data. The user terminal 10 may be equipped with various plug-ins for expanding the browser functions of the web browser. One example of such a plug-in is Flash Player by Adobe Systems Incorporated of the United States. Alternatively, the HTML data in this embodiment may be in HTML5 format with video and audio playback functions.

The web browser communicates with the game server 20 according to HTTP (HyperText Transfer Protocol). When a user operates the operation input unit 15 to select a URL (Uniform Resource Locator) or an operation target (for example, a software button (hereinafter simply referred to as "button")) on a web page, the web browser sends an HTTP request including the selection result to the game server 20 in order to update the web page. The web browser obtains HTML data from the game server 20 as an HTTP response,
The web page is interpreted and displayed on the display unit 16 .

The display unit 16 is, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro Luminescence) display.
In the case of a liquid crystal display (LCD) monitor including thin film transistors arranged in a matrix on a pixel basis, the display unit 1
6 drives the thin film transistors to display an image of a web page on a display screen.

When the user terminal 10 is a button input type user terminal, the operation input unit 15 has a plurality of instruction input buttons, such as a direction button, a decision button, and a numeric keypad, for accepting user operation input, and includes an interface circuit for recognizing the press (operation) input of each button 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 input by touching the display screen with a fingertip or a pen.

The storage 18 is a storage device configured, for example, by a flash memory or a hard disk drive (HDD).

(1-3) Configuration of the 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 control signals or data signals between the various units.
The hardware can have the same configuration as a general-purpose network server.

The CPU 21 reads out the programs and data stored in the ROM 22, and controls the overall operation of the game server 20, such as timing processing of control signals and data signals between each unit in the game server 20. The CPU 21 also reads out the programs stored in the storage 25 and various data required for the execution of the programs, expands them in the RAM 23, and performs various processes such as data input/output processing, calculation processing, and judgment processing associated with the execution of the programs.
The reference number 3 temporarily stores data for the CPU 21 to carry out calculations, determinations, and the like.

For example, the storage 25 stores a program for providing a web service by communicating with a web browser of the user terminal 10, which is a client, according to HTTP. The CPU 21 loads the program stored in the storage 25 into the RAM 23 and executes the program. In conjunction with the execution of the program, the CPU 21 acquires an HTTP request from the user terminal 10 via the communication interface unit 24, executes processing according to the HTTP request, and returns HTML data (an example of image data to be described later) including the execution result to the user terminal 10 as an HTTP response.

The storage 25 is an information recording device configured, for example, by a flash memory or a hard disk drive (HDD), and stores the above-mentioned programs as well as a data table group 70. The data table group 70 (described later) includes a card data table, an evolution synthesis data table, a quest data table, a possession card data table, a reservation data table, a possession history data table, and a card circulation data table. Each data table is accessed by the CPU 21 as appropriate to read and write data.

(1-4) Presentation of Conditions for Acquiring Cards in the Game of the Present Embodiment The game executed in the game system 1 of the present embodiment is a game executed by a user using cards as objects. In this game, for example, a user explores an area in the game to acquire cards or items, or plays against other users or NPCs (Non-Player Characters) using cards owned by the user.
In the game of this embodiment, the card evolution synthesis process (hereinafter simply referred to as "evolution synthesis") is a process of evolving a card owned by a user when a certain condition is satisfied. In the example of this embodiment, the card evolution synthesis is a process of changing the card ID as described later, but it may also be a process of changing at least a part of the card data (described later) corresponding to the card. In this case, there is no particular restriction on what the card data is to be changed, but it may be, for example, card parameters such as the card name, card image, and rarity. The card evolution synthesis is an example of a process of changing an object.
To perform evolution synthesis, the user must use a card they own (hereinafter referred to as "possessed card" as appropriate).
From the list of cards, a base card is selected as the card to be evolved (i.e., the card to be subjected to the process of changing the card data). The card selected as the base card is an example of a selected object.
In evolution synthesis, the conditions for combining multiple cards (called "reference cards") required to evolve the base card are determined for each base card. When evolution synthesis is performed, the reference cards used in the evolution synthesis are removed from the user's possession of cards.
In the game of this embodiment, a condition (an example of a change condition) for evolving a selected card is that the user possesses all of the multiple reference cards that are combination conditions corresponding to a card selected by the user as a base card.

In the game of this embodiment, for example, a normal synthesis process and a selling process are provided as processes in which the user loses his/her own cards. To execute the normal synthesis process, the user selects a base card as a card to be grown from among the cards he/she owns. In the normal synthesis process, a change condition that defines the conditions for performing a process to change a card (e.g., an evolution synthesis process) is not determined for each base card, and the user can appropriately select a reference card from among the cards he/she owns. When the normal synthesis process is executed, the card parameters of the base card change (e.g., the card level or skill level increases), and instead the reference card disappears from the cards he/she owns.
In the selling process, a card (e.g., a card that the user does not need) is selected from the user's possession, and the user receives the selling price (e.g., game points) corresponding to that card, and in return, the sold card disappears from the user's possession.

In the game of this embodiment, consider a case where a user wants to evolve a desired card through evolutionary synthesis, but does not have some or all of the reference cards required to evolve the card. In this case, it is necessary to wait to execute the evolutionary synthesis of the desired card until the user can obtain a new card (i.e., the remaining reference card) that satisfies the conditions of the combination of the reference cards. However, if the user forgets the conditions for obtaining the remaining reference cards (hereinafter referred to as "obtainment conditions"), it becomes difficult to obtain the reference cards. In particular, the more cards obtained, the higher the possibility of forgetting the acquisition conditions for each card.
Therefore, in this embodiment, among the multiple reference cards required to evolve a base card, it is possible to present the conditions for obtaining a reference card that the user does not possess (an unowned card or an unknown card). Note that an unowned card is a card that has been possessed by the user in the past, but is not possessed by the user at the time of selecting the base card. On the other hand,
An unknown card is a card that has never been owned by the user.

The presentation of the conditions for obtaining the reference card will be specifically described with reference to Fig. 4. Fig. 4 is a diagram for conceptually explaining the presentation of the conditions for obtaining the reference card.
In FIG. 4, consider a case where a user wants to evolve a card Q that is a card owned by the user. In this case, in order to evolve card Q, cards A, B, and C are used as reference cards.
Assume that a combination of the above is required. Since the user does not currently possess card B, evolutionary synthesis cannot be performed on card Q. Furthermore, since the user has forgotten the conditions for obtaining card B, it is difficult for the user to obtain card B. In this case, in this embodiment, in order to allow the user to easily obtain card B, the conditions for obtaining card B are presented to the user in response to a request for presentation of the conditions for obtaining card B. As a result, the user can easily obtain card B.

(1-5) Data Table Configuration Next, the card data table, evolution synthesis data table, quest data table, possession card data table, reservation data table, possession history data table, and card circulation data table stored in the storage 25 of the game server 20 will be described with reference to FIGS.
11 will be referred to for further explanation.

(i) Card Data Table The card data table records data of cards used in the game of this embodiment. An example of the configuration of the card data table is shown in Fig. 5. In the example shown in Fig. 5, the card ID
Each card includes a card name, a card image, and card parameter data.
The card ID is identification information for identifying a card, which is an example of an object.
D is uniquely assigned to each card. A card ID identifies one card from among a plurality of cards. In other words, the card ID is an example of object identification information that identifies an object.
The card name is a character string that indicates the name of the character that is displayed on the card. The card image is an image of the character that is displayed on the card. The card parameters are composed of the following data: rarity, attributes, cost, skills, selling price, attack power, defense power, and limited flag.
Rarity is an index that indicates the rarity of a card, and in the example shown in FIG. 5, rarity is set in the order of increasing rarity from R1 to R5.
The attribute is the attribute of the character displayed on the card, and in the example shown in FIG. 5, it is one of N1 to N3.
The cost is a value that is referenced when a card is incorporated into a user's card team. For example, when a battle is to be played using card teams, the sum of the costs of the cards included in the card team is limited to a predetermined value or less.
The skill is information indicating an advantageous effect when playing a game using a card,
4, skills with various effects, SK1 to SK12, are set for each card. Note that it is not necessary for all cards to have skills.
The selling price is the game points that a user can obtain when selling a card that the user owns.
Attack power and defense power are parameters that are referenced when using a card in a battle.
The limited flag is a flag that indicates whether or not the card is issued for a limited time. In the example shown in Fig. 4, a card with a limited flag of "1" indicates that the card is issued for a limited time, and a card with a limited flag of "0" indicates that the card is not issued for a limited time.

(ii) Evolution Synthesis Data Table The evolution synthesis data table records the conditions for evolution synthesis of cards in the game of this embodiment. FIG. 6 shows an example of the configuration of an evolution synthesis data table. In the example shown in FIG. 6, for each evolution ID for identifying the contents of evolution synthesis, the pre-evolution card ID (i.e., the card ID of the card that will be the base card before evolution), the evolved card ID (the card ID of the evolved base card), and the change conditions of the card ID of the reference card required to perform evolution synthesis (the five reference cards in columns C1 to C5) are recorded. For example, Evolution ID: 000
In the condition shown in 2, the user selects the card with card ID: 0072 as the base card from among the cards he possesses, and the card with card IDs: 0025, 0060, 00
If there is a combination of 70 three cards, the card with card ID: 0072 can be evolved into the card with card ID: 9072 by performing evolutionary synthesis.
Here, as an example of a process for changing an object, a process for evolutionary synthesis of a card, which is an example of an object, will be described. As described above, a card ID is an example of object identification information. In other words, FIG. 6 shows that a plurality of object identification information used in a process for changing an object is included in the change conditions.
In addition, the same card ID may be recorded in at least two of the columns C1 to C5, which indicate the combination of card IDs of the reference cards. For example, the combination of reference cards used to evolve and synthesize a base card may contain two or more identical reference cards. If the combination condition of the reference cards for evolving a base card is that the same card ID is not recorded in any of the columns C1 to C5.
In the case where a predetermined number of reference cards, which are D, are included, the data format may be one consisting of the card IDs of the reference cards and the number of the reference cards, instead of the data format shown in FIG.

(iii) Quest Data Table The quest data table records data on quests, which are events carried out in the game of this embodiment. A quest is a process in which a player completes a quest to obtain a card or item.
This is an event in which the user explores an area within the game and aims to achieve certain quest conditions. An example of the configuration of a quest data table is shown in Fig. 7. In the example shown in Fig. 7, for each quest ID, the area name, consumed stamina, information about available cards (card ID and acquisition rate), information about available items (item ID and acquisition rate), boss ID, and so on are stored.
, and quest UI data.
The area name is a string indicating the name of the area used in the quest.
The consumed stamina is a value that is referenced when performing a quest. To perform a quest, the value of stamina, which is one of the user's parameters, must be equal to or greater than the consumed stamina value. When performing a quest, the user's stamina value is consumed by the consumed stamina value.
Information about available cards (acquired card data 1, 2, ...) consists of a card ID and an acquisition rate. The card ID is identification information of a card that can be acquired when the quest conditions are met. The acquisition rate is a numerical value indicating the probability of acquiring a card when the quest conditions are met.
Information about available items (obtained item data 1...) consists of an item ID and an acquisition rate. The item ID is identification information of an item that can be obtained when the quest conditions are met. The acquisition rate is a numerical value indicating the probability of obtaining the item when the quest conditions are met.
The boss ID is identification information of an NPC (e.g., a boss character) that will be an opponent in a quest. The quest condition is achieved, for example, by winning a battle against the boss character.
Quest UI data is user interface data used in a quest (e.g., image data used in a quest).

(iv) Possessive card data table The possessive card data table records information on the possessive cards of the user. An example of the configuration of the possessive card data table is shown in Fig. 8. Fig. 8 shows an example of the possessive card data table for one user, but possessive card data tables are provided for all users registered in the game.
In the possessed card data table shown in FIG. 8, the following data are recorded in association with each card ID: serial number, card level, skill level, and reservation ID.
The serial number is a unique number that is determined when the card is given to the user. Different serial numbers are assigned to cards with the same card ID. When a card evolves, the serial number of the card may or may not change before and after the card evolves.
The card level is a parameter that indicates the development level of a card, and is increased, for example, by performing the above-mentioned normal synthesis. When a user acquires a card, the card level has a value (initial value) of 1, and the user can grow the card (i.e., increase the card level) by performing normal synthesis or the like.
The skill level is a parameter that indicates the level of development of a card, and in particular, the level of the skill that the card has. When a user acquires a card with a skill, the value (initial value) of the skill level is 1, and the skill level of the card can be increased by, for example, performing normal synthesis using a card that satisfies a certain condition as a reference card. As the skill level of a card increases, the effect generated by the skill increases.
The reservation ID is identification information for identifying the reservation contents for evolution synthesis. A reservation ID is associated with a user's owned card that is a reserved card. For example, the example shown in FIG. 8 indicates that five cards with card IDs: 0591, 0010 (2 cards), 0033, and 2005 are reserved cards. The reservation IDs recorded in the owned card data table correspond to the reservation IDs recorded in the reservation data table described later.

(v) Reservation Data Table The reservation data table records information on reserved cards for evolution synthesis by the user. An example of the configuration of a reservation data table is shown in Fig. 9. Fig. 9 shows an example of a reservation data table for one user, but a reservation data table is provided for all users registered in the game.
In FIG. 9, the reservation ID is an ID that is issued in the order in which the reservation for evolution synthesis is made.
In the example shown in FIG. 1, numbers are recorded in ascending order, such as 01, 02, .... The evolution ID corresponds to the evolution ID shown in the evolution synthesis data table, and is an ID that specifies the content of the evolution synthesis.
It is.
Among the serial numbers of the reserved cards, the serial number of the pre-evolved card is the serial number of the card owned by the user selected as the base card for evolution synthesis. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference cards correspond to the columns C1 to C5 that respectively constitute the combination of the reference card IDs in the evolution synthesis data table.
If the reserved reference card is a possessed card, the serial number of the possessed card data is recorded in the field corresponding to the card ID of the reference card. If the reserved reference card is an unpossessed card, a temporary serial number (e.g., "00000000") is recorded in the field corresponding to the card ID of the reference card, and the reference card becomes a possessed card (i.e.,
After the possessed 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. In the field corresponding to the card ID of the reference card that has not been reserved, data indicating "no reservation" (for example, NULL) is recorded.
In the following, a case where a reservation data table is provided will be described, but it is not essential to provide a separate reservation data table.
The data to be recorded in the reservation data table may be recorded in the possession card data table. In that case, the reservation ID, evolution ID, and any character string from C1 to C5 (any character string that corresponds to the C1 to C5 columns of the evolution synthesis data table) are recorded in association with the card ID of the reserved card in the possession card data table.

(vi) Possession History Data Table The possession history data table records information about cards that a user has possessed. An example of the configuration of a possession history data table is shown in Fig. 10. Fig. 10 shows an example of a possession history data table for one user, but a 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 times of acquisition is associated with each card ID and recorded. The number of times of acquisition is a value indicating the number of times a card has been acquired by a user in a game. A card that has been acquired 0 times is an unknown card.

(vii) Card Distribution Data Table The card distribution data table stores information about cards in circulation within the game. An example of the configuration of the card distribution data table is shown in Fig. 11. In the example shown in Fig. 11, the card distribution data table records the number of cards in circulation and the average transaction price for each card ID.
The number in circulation is a value indicating the total number of cards that users have set as cards to be traded (e.g., bought and sold) in the game. The higher the number in circulation, the lower the difficulty of obtaining the card.
The average transaction price is the average price paid when trading cards between users. The higher the average transaction price, the more difficult it is to obtain the card.

In the following description, information associated with a card ID in the card data table, quest data table, possession card data table, possession history data table, and card circulation data table (e.g., card name, card image, card parameters, quest ID, area name, consumed stamina, acquisition rate, boss ID, quest UI data, serial number,
The information on the card level, skill level, reservation ID, number of times acquired, number in circulation, and average transaction price) will be collectively referred to as "card data" as appropriate. Card data is an example of information indicating an object.

(1-6) Specific examples of the presentation process of acquisition conditions and the evolution synthesis process Specific examples of the presentation process of acquisition conditions and the evolution synthesis process of the game of this embodiment will be described below with reference to Figures 12A, 12B, 13A, 13B, and 14. Figures 12A, 12B, 13A, 13B, and 14 are each a diagram showing an example of a screen displayed on the user terminal 10 when the game process of this embodiment is being executed.

(1-6-1) Processing for Presenting Acquisition Conditions (1-6-1-1) Processing for Presenting Acquisition Conditions for Unowned Cards (FIGS. 12A and 12B)
12A and 12B show a series of changes in the display screen in the acquisition condition presentation process for presenting the acquisition condition of an unowned card. In FIG. 12A, image P1 is an image when a user requests processing of a monster card (hereinafter, simply referred to as a "card") in the game of this embodiment. In image P1, button b1 ("View owned monsters"), button b2 ("Team composition"), button b3 ("Normal synthesis"), button b4 ("Evolution synthesis"), and button b5 ("Sell") are provided as the user's operation objects.
Button b1 is a button operated when making a request to view cards owned by the user. Button b2 is a button operated when the user selects a card from the cards owned by the user to use in a battle with another user or an NPC. Button b3 is a button operated when making a request for normal synthesis processing of a card selected as a base card from the cards owned by the user. Button b4 is a button operated when making a request for evolution synthesis processing of a card selected as a base card from the cards owned by the user. Button b5 is a button operated when making a request for selling processing of a card selected from the cards owned by the user.

When the button b4 ("Evolution Synthesis") is operated in the image P1, the image changes as shown in P2. In the image P2, a list of a plurality of owned cards is displayed so that one of the cards owned by the user can be selected as a base card. The image is configured so that cards that cannot be evolved (in the illustrated example, cards TOM, TED, and DSG) cannot be selected as a base card. That is, in the image P2, cards that can be evolved and cards that cannot be evolved are displayed in a display format that can be distinguished by the user. The method of displaying cards that can be evolved and cards that cannot be evolved in a display format that can be distinguished by the user is not limited to the example shown in the image P2 of FIG. 12A. The list of owned cards may be a list of character strings of the card names of each card, and in that case, cards that can be evolved and cards that cannot be evolved may be distinguished by the brightness, size, etc. of the character strings.
When, for example, card KLM is selected as one of the cards that can be evolved in image P2, the image changes to that shown in P3. Image P3 includes a button b6 ("Select") for confirming the selected card as the base card for evolution synthesis, and a button b7 ("Back") for returning to image P2 and selecting another card as the base card.
When the button b6 is operated in the image P3, the card K selected as the base card is
If the condition of the reference card required for the evolution of the card KLM is not met, the image is updated as shown in P4. The image P4 is an image for requesting the presentation of the acquisition condition of the unowned card among the reference cards required for the evolution of the card KLM selected as the base card. Note that, when the user selects the button b6 in the image P3, if the condition of the reference card required for the evolution of the card KLM selected as the base card is met, an image (not shown) for requesting the execution of the evolution synthesis of the card KLM is displayed.

The image P4 includes a display area 101 showing a pre-evolution card (here, card KLM, which is a base card) and an evolved card (for example, card QRS), a display area 102 showing reference cards required for evolution synthesis and their status (either owned, not owned, reserved, or unknown), and
The image P4 includes a button b8 ("Display acquisition conditions") for requesting the presentation of acquisition conditions for the reference card.
When a card DSG) with a status of “not possessed” shown in FIG. 02 is selected and button b8 is operated, an image P5 is displayed showing the acquisition conditions for the reference card selected by the user, as shown in FIG. 12B.
The reference card selected by the user is also called a "reference card designated by the user." Also, since a reference card is an example of an object, the "reference card designated by the user" is an example of a "designated object," which is an object designated by the user.

Image P5 of FIG. 12B shows a reference card selected by the user (here, card D
SG), a display area 103 showing the card image, card name, and rarity of the reference card, and a display area 104 showing the acquisition conditions of the reference card. The display area 104 shows information 104a on the difficulty of acquisition (here, the number of times acquired, the number in circulation, and the average trading price), and information 104b on the acquisition route (here, the area where it can be acquired).

(1-6-1-2) Processing for Presenting Conditions for Obtaining Unknown Cards (FIGS. 13A and 13B)
13A and 13B show a series of changes in the display screen during the process of presenting the conditions for obtaining an unknown card.
A is similar to images P1 to P3.
Image P4 in FIG. 13A is similar to the image in FIG. 1 in that an unknown card is shown in the display area 102.
13B. An unknown card is a card that the user has never possessed (for example, the value of "number of times acquired" in the possession history data table is 0) among cards that are not possessed by the user. When a reference card (here, a card whose status is "unknown" in the display area 102) for which acquisition conditions should be displayed is selected in image P4 and button b8 is operated, image P5 showing the acquisition conditions of the reference card selected by the user is displayed as shown in FIG. 13B.

In the image P5 of FIG. 13B, an image is displayed in the display area 103 indicating that the reference card selected by the user is an unknown card to the user.
Image P5 of FIG. 12B differs in that only information 104b relating to the difficulty of obtaining the reference card (here, the number of times it has been obtained and the number in circulation) is shown among the conditions for obtaining the reference card (i.e., information 104a relating to the route of obtaining the reference card in image P5 of FIG. 12B is masked).

(1-6-2) Evolutionary synthesis process (Figure 14)
14 shows a series of changes in the display screen when the evolution 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 playing the game.
In the case where the change condition of the reserved evolution synthesis is satisfied by obtaining this new card DSG, it is preferable to notify the user that the change condition is satisfied by obtaining the new card. More preferably, it is preferable to display an image for executing the evolution synthesis as shown in P11.
The image P11 includes a display area 101 showing a pre-evolution card (card KLM) and an evolved card (card QRS), a display area 102 showing reference cards required for evolution synthesis and their status (here, possession), and a button b2 for accepting a request as to whether or not to execute evolution synthesis.
0 ("Yes") and button b21 ("No") are displayed.
When the button b20 is operated in the image P11, the image changes to that shown in P12. In the example of the image P12, the card image, card name, and at least some of the parameters of the evolved card are displayed.

(1-7) Overview of Functions of Information Processing Device Next, functions of the game server 20 for implementing the game of this embodiment described above will be described. FIG. 15 is a functional block diagram for explaining the main functions of the game server 20 of this embodiment. In FIG. 15, the data table group 70 includes, as described above, a card data table, an evolution synthesis data table, a quest data table, a possession card data table, a reservation data table, a possession history data table, and
Incidentally, all of the means included in the functional block diagram shown in Fig. 15 are not necessarily essential elements for the present invention.

The reception unit 51 has a function of receiving various requests from the user based on information regarding the user's operation input. In the game of this embodiment, the requests from the user include, for example, a request for a process to present conditions for obtaining a card, a request for an evolution synthesis process, a request for a quest process, a request for a reservation process for an evolution synthesis, a request for the execution of an evolution synthesis, a request for a process to view cards owned by the user,
There is a request to sell a card owned by the user.
The request for the process of presenting acquisition conditions is a request to present the acquisition conditions of the reference card necessary for the evolution synthesis of the base card in response to image data being output by the output means 56.
The request for the reservation process of the evolutionary synthesis is made in response to the output of image data by the output means 56, and is made to reserve at least one of the base card in the evolutionary synthesis and a plurality of reference cards corresponding to the base card for the evolutionary synthesis, and to erase the card from the user's possession of the card, among the processes other than the evolutionary synthesis (
For example, it is a request to restrict the use of the card in a process of selling the card or a process of transferring the card to another user. The request for the reservation process of evolution synthesis includes the card ID of the reference card to be reserved.
In order to realize the function of the reception means 51, the game server 20 includes a communication interface unit 2
The game server 20 receives a request corresponding to a user's button operation input in a web page, which is an image, from the user terminal 10 via the game server 20. 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 a request reception process. In the reception process, the request is recorded in the RAM 13. The CPU 21 sequentially executes processes according to the received request.

The game processing means 52 has a function of executing various game processes other than evolution synthesis based on requests and instructions from the user received by the reception means 51. The game processes of this embodiment may be provided as appropriate, and include, for example, a battle process between users, a battle process between a user and an NPC, a quest process by a user, a normal synthesis process of cards owned by a user, and a sale process of cards owned by a user.
Although the battle process will not be described in detail, for example, a user may organize a team of cards owned in advance so that the total cost is equal to or less than a predetermined upper limit, and the team may battle against other users or NPCs. The outcome of the battle is determined by parameters such as the attack power, defense power, and skills of each card in the team.

The function of the game processing means 52 when executing quest processing is realized as follows: When the CPU 21 of the game server 20 receives a request for quest processing including a quest ID, it reads out the quest data (area name, consumed stamina, acquired card data (card ID and acquisition rate), acquired item data (item ID and acquisition rate), boss ID, and quest UI data) associated with the quest ID from the quest data table, and loads it into the RAM 23. Next, the CPU 21 displays a quest execution screen based on the quest UI data, and progresses the quest in response to user operations.
When the quest progresses to a predetermined level, the CPU 21 executes a battle between the user and the boss character associated with the boss ID. When the user fulfills the victory condition in the battle,
The CPU 21 executes a process of granting a card according to the value of the "acquisition rate" associated with the quest ID. In the process of granting a card, the CPU 21 writes the card ID associated with the quest ID into the possessed card data table, and increases the value of the "acquisition count" associated with the card ID in the possessed card data table.
In addition, when the user fulfills the victory conditions in the match, the process of granting an item is executed in the same manner as the process of granting a card.

The functions of the game processing means 52 when executing the normal synthesis process of the user's owned cards are as follows:
This is realized as follows. When the CPU 21 of the game server 20 receives a request to execute a normal synthesis including the user's selection results for the base card and the reference card, the CPU 21 reads the card data of the base card and the reference card from the possession card data table and executes the RA.
Next, the CPU 21 changes the parameters of the base card (e.g., card level and skill level) based on the parameters of the base card and the reference card,
The changed parameters of the base card are written to the owned card data table, and the card data of the owned card that was used as the reference card is deleted from the owned card data table. Note that the card level and skill level of the base card do not always increase each time normal synthesis is performed. For example, the value of the development parameter associated with the card may be increased each time normal synthesis is performed, and when the value of the development parameter reaches a predetermined value, the card level may be increased by one and the value of the development parameter may be reset to zero.

The function of the game processing means 52 when executing the process of selling the user's owned cards is realized as follows. The CPU 21 of the game server 20 accepts a request for the selling process,
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 owned card data table. Next, the CPU 21 reads the selling price value (points) of the card to be sold from the card data table, and performs a process of granting the read points to the user. The process of granting points to the user may be performed, for example, by searching the user database (
This is a process of updating the value of the user's owned points recorded in the user account (not shown).

The card data modification means 54 has a function of performing evolutionary synthesis to modify the card data of the base card when all of a plurality of reference cards that satisfy the modification conditions are included in the cards owned by the user.
In the example of this embodiment, in order to realize the function of the card data change means 54, when the CPU 21 of the game server 20 accepts a request to execute evolution synthesis, it erases the card data of the pre-evolution card (i.e., the base card of the evolution synthesis) in the possession card data table,
Write new card data for the evolved card. This will evolve the base card of the user's possession. As shown in the evolution synthesis data table, the card IDs before and after evolution are different, so at least one of the card name, card image, and card parameters will be changed by the evolution synthesis.

The acquisition means 55 acquires a base card (an example of a selected object) selected by a user.
A plurality of reference card IDs, which are combination conditions (an example of a change condition) of the reference card corresponding to
The acquisition means 55 has a function of acquiring the card data of the reference card from the evolution synthesis data table. In addition, when the reference card selected by the user is not a possessed card (for example, it is an unpossessed card or an unknown card), the acquisition means 55 has a function of acquiring the card data of the reference card from the quest data table, the possession history data table, and the card circulation data table.
The acquisition means 55 has a function of acquiring the serial number (an example of information indicating an object) of one of the cards owned by the user based on the user's operational input when reserving a card for evolutionary synthesis.
When the acquisition means 55 acquires a plurality of reference card IDs that are the combination conditions of the reference card,
In response to obtaining the base card selection result from the user terminal 10, the CPU 21 of the game server 20 refers to the evolution synthesis data table and reads out a plurality of reference card IDs that constitute the combination conditions corresponding to the base card.
When the acquisition means 55 acquires card data of a reference card selected by a user,
In response to obtaining the selection result of the reference card from the user terminal 10, the CPU 21 of the game server 20 refers to the quest data table, the possession history data table, and the card circulation data table to read out the card data of the reference card.
When the acquiring means 55 acquires the serial number of the card, the CPU 21 of the game server 20
When a request for reservation processing of evolutionary synthesis is received from a user terminal 10, the device identifies an unreserved owned card from among the base card to be the subject of evolutionary synthesis and a plurality of reference cards corresponding to the base card by referring to the owned card data table, and reads out the serial number of the identified card.

The output means 56 has a function (hereinafter referred to as the “first output function”) of outputting first output data (e.g., image data) for displaying the multiple reference cards in a display format that is individually identifiable to the user, using the card data of the multiple reference cards included in the change conditions acquired by the acquisition means 55.
In the present embodiment, in order to realize the first output function of the output means 56, the game server 2
For example, when a base card is selected by a user, the CPU 21 of the game 0 reads out a combination of multiple reference card IDs required to evolve the base card from the evolution synthesis data table, and for each reference card, calculates the card status (
The status of the item (one of the following states: “reserved,” “owned,” “not owned,” or “unknown”) is identified.
Furthermore, the CPU 21 generates first output data for displaying the state of each reference card in a display format that is recognizable to the user.
For example, in the reservation data table of Figure 9, if a serial number or temporary serial number included in the possessed card data is recorded in columns C1 to C5 associated with the evolution ID corresponding to the base card, the status of the reference card identified by the card ID corresponding to the corresponding column is identified as "reserved."
For example, for cards whose card status is other than "reserved," if the card ID in the C1 to C5 columns associated with the evolution ID corresponding to the base card in the evolution synthesis data table of Figure 6 is included in the "Card ID" column of the possessed card data table of Figure 8, the status of the reference card identified by that card ID is identified as "possessed."
For example, for cards whose card status is other than "reserved" and "owned", if the "number of times acquired" column corresponding to the card ID in the possession history data table of FIG. 10 is not 0, the status of the reference card identified by the card ID is specified as "not owned", and if the "number of times acquired" column corresponding to the card ID is 0,
The state of the reference card identified by is identified as "unknown."
The first output data indicates a state of the identified reference card.

In addition, the output means 56 has a function (hereinafter referred to as the “second output function”) of outputting second output data (e.g., image data) for presenting conditions for obtaining a reference card (an unowned card or the unknown card) corresponding to the reference card ID obtained by the acquisition means 55.
In the example of this embodiment, in order to realize the second output function of the output means 56,
For example, when the reference card ID is acquired by the acquisition means 55, the CPU 21 of the number 0 may acquire the quest data table, the possession history data table, the
Then, the card circulation data table is referenced to identify the acquisition conditions for the reference card corresponding to the reference card ID, and second output data is generated for presenting the acquisition conditions.
For example, in the quest data table of FIG. 7, the information in the "Area Name" column corresponding to the quest ID that includes the reference card ID acquired in the "Card ID" column of "Acquired Card" is identified as the available area.
In the possession history table of FIG. 10, the value in the "Number of times acquired" column corresponding to the acquired reference card ID is specified as the number of times acquired.
In the card circulation data table of FIG. 11, the "
The values in the "Number in circulation" and "Average transaction price" columns are identified as the number in circulation and average transaction price, respectively.
The second output data indicates at least one of the identified available area, the number of times of acquisition, the number of times of circulation, and the average transaction price.

In response to receiving a request for reservation processing of evolution synthesis, the recording means 57
and recording the serial number acquired by the above as a reserved card in a reservation data table in the storage 25. In the example of this embodiment, the reserved card is a card that is restricted from being used in any process other than the evolution 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 reservation processing of evolution synthesis, it accesses the reservation data table and writes the serial number of the card to be reserved. More specifically, if the serial number of the card selected as the base card among the cards to be reserved 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" column in association with the issued reservation ID. Furthermore, it writes the "reference card ID" which is the same as the card ID corresponding to the serial number of the reference card among the cards to be reserved.
D" column (any of columns C1 to C5), and write the serial number of the reference card among the cards to be reserved in the specified column.
On the other hand, if the reservation ID has already been issued, the serial number has already been recorded in the "pre-evolved card" field, so the CPU 21 only writes the serial number of the reference card among the cards to be reserved.

The limiting means 58 determines whether or not a card recorded in the reservation data table as a reserved card is
It has a function to restrict the card from being used for processes other than the intended evolutionary synthesis. "Used for processes other than the intended evolutionary synthesis" includes cases where a card that is associated with the intended evolutionary synthesis and recorded as a reserved card is used for evolutionary synthesis other than the intended evolutionary synthesis or for normal synthesis.
There are various possible methods for the restriction by the restriction means 58. For example, there is a method for prohibiting the processing of the restricted card other than the evolution synthesis that the user intended, or a method for confirming the continuation of the processing when the restricted card is selected for the processing other than the evolution synthesis that the user intended.
In addition, "restricting the use of reserved cards in processing" does not necessarily mean that processing other than the intended evolutionary synthesis using the reserved card is prohibited, but may mean that processing other than the intended evolutionary synthesis using the reserved card is possible, but the procedure for executing the processing is made difficult or complicated. When the "processing other than evolutionary synthesis" for the reserved card is a process that is executed on the condition that the reserved card is eliminated from the user's possession cards (i.e., a process that is executed on the condition that the reserved card becomes an unpossessed card), it is particularly preferable that the processing is restricted.

For example, when the CPU 21 of the game server 20 receives a request to execute any one of various processes of the game of this embodiment, and when a card owned by the user is selected as a card to be processed, the CPU 21 refers to the owned card data table to determine whether or not a reservation ID is associated with the card ID of the selected card.
If the selected card is not an evolution synthesis process corresponding to the card, 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 asked whether or not to continue the process. Since the reservation data table associates the evolution ID with the serial number of the reserved card, the CPU 21 of the game server 20 can specify the desired evolution synthesis corresponding to the reserved card (i.e., the evolution synthesis corresponding to a specific evolution ID). Therefore, it is possible to determine whether the process that the user is about to execute using a specific owned card is the desired evolution synthesis process.

Although it is not essential to provide the recording means 57 and the restriction means 58, providing the recording means 57 and the restriction means 58 can prevent, for example, a user who reserves some of the multiple reference cards required for evolutionary synthesis before performing the evolutionary synthesis, and is waiting to perform the evolutionary synthesis until he or she obtains the remaining reference cards, from mistakenly using the cards he or she possesses for processes other than the evolutionary synthesis.

(1-8) Processing Flow of the Game of this Embodiment Next, an example of the processing flow of the game of this embodiment will be described with reference to the sequence charts of FIGS. 16A, 16B, and 17.
16A and 16B are sequence charts showing the process of presenting acquisition conditions, and Fig. 17 is a sequence chart showing the evolution synthesis process.
In each figure, the steps at which the images P1 to P5 and P10 to P12 shown in Figures 12A, 12B, 13A, 13B, and 14 are displayed are given the reference numerals of the images.

(1-8-1) Processing for Presenting Acquisition Conditions (FIGS. 16A to 16B)
In the process of presenting acquisition conditions described below, as an example, assume that a user possesses a base card and some of multiple reference cards for evolving and synthesizing the base card, and requests the presentation of acquisition conditions for an unowned or unknown reference card.

In FIG. 16A, a predetermined button (e.g., FIG. 1
When the user operates button b4 of image P1 in FIG. 2A or FIG. 13A, the CPU 11 of the user terminal 10 accepts a request for evolutionary synthesis processing (S10) and transmits the request to the game server 20 (S12).
When the CPU 21 of the game server 20 receives a request for the acquisition condition presentation process from the user terminal 10, it refers to the evolution synthesis data table and the owned card data table to read the user's owned cards that can be evolved (S14). That is, the CPU 21 reads the card data of the user's owned cards from the owned card data table, and reads all pre-evolution card IDs (i.e., card IDs of cards that can be evolved) in the evolution synthesis data table. Next, the CPU 21 identifies cards that can be evolved (i.e., base card candidates) from the user's owned cards, generates image data including the card data of the base card candidates (S
16), and transmits the image data to the user terminal 10 (S18).
It is preferable that the image data generated in S16 is generated so that images of cards that can be evolved and images of cards that cannot be evolved among the cards owned by the user are displayed in different ways, as shown in image P2 in Figure 12A or Figure 13A.

When the CPU 11 of the user terminal 10 receives the image data transmitted in S18, it displays an image on the display unit 16 based on the image data (S20). The image displayed in S20 includes images of multiple cards that are base card candidates, as exemplified by image P2 in Fig. 12A or 13A, and is configured so that the serial number of each card can be selected by operating the image of each card. When the user operates to select one of the multiple base card candidates displayed in S20 as the base card,
The CPU 11 receives the base card selection result (serial number) (S22), and transmits the selection result to the game server 20 (S24).

When the CPU 21 of the game server 20 receives the selection result (serial number) transmitted in S24, it refers to the evolution synthesis data table and reads out a plurality of reference card IDs (card IDs in columns C1 to C5) corresponding to the pre-evolution card ID that matches the card ID associated with the serial number of the base card selected by the user (S26). Next, the CPU
21 refers to the possessed card data table and the reservation data table to identify the status (either not possessed, possessed, reserved, or unknown) of the card corresponding to each reference card ID read in S26, and generates image data 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 in the following manner.
The CPU 21 reads the serial number recorded in the "serial number of reserved card" column of the reservation data table, and identifies the card ID associated with the serial number by referring to the possessed card data table. If the reference card ID read in S26 matches the identified card ID, or if the serial number is a temporary serial number, the status of the card identified by the card ID is identified as "reserved."
When the reference card ID of a reference card other than the card specified as "reserved" is included in the card IDs recorded in the possessed card data table, the CPU 21 changes the status of the card specified by the reference card ID to "possessed."
Identify as:
For cards other than "reserved" and "owned," if the value associated with the reference card ID in the "Number of times acquired" column of the possession history data table is not 0, the CPU 21 identifies the status of the card identified by the reference card ID as "not owned," and if the value associated with the reference card ID in the "Number of times acquired" column of the possession history data table is 0, the CPU 21 identifies the status of the card identified by the reference card ID as "unknown."

In S28, if the states of all the reference cards read in S26 are "owned" or "reserved", the CPU 21 of the game server 20 generates image data for the user to instruct whether or not to execute evolutionary synthesis of the card KLM. If the state of at least any of the reference cards read in S26 is "not owned" or "unknown", the CPU 21 generates image data for presenting the acquisition conditions for the reference card in the "not owned" or "unknown" state. Here, it is assumed that the image data that is the basis of the image P4 in FIG. 12A or FIG. 13A has been generated.

Next, the CPU 21 of the game server 20 transmits the image data generated in S28 to the user terminal 1.
0 (S30). When the CPU 11 of the user terminal 10 receives the image data transmitted in S30, it displays an image based on the image data on the display unit 16 (S32).

The image displayed in S32 is, as shown in image P4 in FIG. 12A or FIG. 13A, S2
12A or 13A is configured to be able to accept a request for the presentation process of acquisition conditions for an unowned card or an unknown card. Here, after image P4 of FIG. 12A or 13A is displayed, if the user performs an operation to request the presentation process of acquisition conditions (for example, an operation of button b8 of image P4 of FIG. 12A or 13A), the CPU 11 of the user terminal 10 accepts the request for the presentation process of acquisition conditions based on the user's instruction corresponding to the operation (S34), and transmits the request to the game server 20 (
The request sent from the user terminal 10 to the game server 20 in S36 includes the card ID of the unowned card or unknown card selected by the user (i.e., the card for which acquisition conditions should be presented in the acquisition condition presentation process).
As described above, the reference card selected by the user is an example of a designated object that is an object designated by the user. In other words, the processes of S34 and S36 are an example of a process of accepting an instruction to designate one of a plurality of objects based on an instruction from the user.

When the CPU 21 of the game server 20 receives the request for the acquisition condition presentation process transmitted in S36, it obtains the card data of the reference card selected by the user from the card data table, the quest data table, and the card circulation data table (S3
8). The card name, card image, and rarity are obtained from the card data table. The quest ID and the area name of the area where the card can be used are obtained from the quest data table. The number of times the card has been obtained is obtained from the possession history table. The number of cards in circulation and the average transaction price are
Obtained from the card distribution data table.

If the status of the card specified in S28 is "unknown" (S40: YES),
2, and if the status of the card identified in S28 is not “unknown” (S40: NO),
, proceed to S44.
Here is an example of a card whose status is not "unknown" (i.e., an unknown card):
An example will be described in which the card status is "not owned" (i.e., an unowned card).
"Unknown" and "Not possessed" have in common that they both indicate a state in which the user does not possess the card (i.e., the card ID is not included in the possessed card data table).

In S42, the CPU 21 of the game server 20 selects information on the difficulty of obtaining the card (here, the number of times the card has been obtained,
A masking process is applied to the image so that information other than the number of cards in circulation and average trading price (here, the card name, card image, rarity, and available area) is not displayed.
In this embodiment, the purpose of not displaying any information other than information regarding the difficulty of obtaining unknown cards is to give the user a sense of anticipation for the game (especially obtaining unknown cards) and to improve the entertainment value of the game.

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 conditions for the reference card (however, if it is determined to be “unknown” in S40, information regarding the difficulty of acquisition)
The image data (image data that is the basis for image P5 of 3B) is generated and transmitted to user terminal 10 (S46).

When the CPU 11 of the user terminal 10 receives the image data transmitted in S46, it displays an image based on the image data on the display unit 16 (S48).
If it is determined in S40 that the card is not “unknown” (for example, “not owned”), then the card image, card name, rarity, number of times acquired, number in circulation, average trading price, and available area are displayed, as shown in image P5 of FIG. 12B.
On the other hand, if it is determined to be “unknown” in S40, as shown in image P5 of FIG. 13B,
The number of times acquired, number in circulation, and average trading 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 conditions for an unknown card is more limited than the information displayed as the acquisition conditions for a card not possessed. In other words, S48 is an example of a process in which the information displayed as the acquisition conditions when the designated object is an unknown object that is an object that the user has never possessed is more limited than when the designated object is an object not possessed.

As described above, in this embodiment, when the user does not possess the reference card selected by the user (when the reference card is an unknown card or an unowned card), an example of displaying the acquisition conditions of the reference card has been described. This is an example of a process of displaying the acquisition conditions of a designated object when the user does not possess the designated object.

(1-8-2) Evolutionary synthesis process (Figure 17)
For example, if a new card obtained by the user satisfies the change conditions of a reference card in evolutionary synthesis, the evolutionary synthesis process can be executed.
In FIG. 17, a predetermined button (e.g., FIG. 14) is pressed on the image displayed on the user terminal 17.
When the user operates the button b20 of the image P11 of the user terminal 10,
U11 accepts a request to execute evolutionary synthesis (S150) and transmits the request to the game server 20 (S152).

When the CPU 21 of the game server 20 receives the request sent in S152, it erases the card data of the pre-evolution card (i.e., the base card of the evolution synthesis) from the possessed card data table (S154), and writes new card data of the evolved card (S155).
6).
Next, the CPU 21 of the game server 20 erases the card data of the reference card used for evolution synthesis in the possessed card data table (S158).

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

As described above, in the game system of this embodiment, in order to execute the evolution synthesis of cards, which is an example of a process of changing an object, it is required that the user possesses the base card to be the subject of the evolution synthesis and all of the multiple reference cards corresponding to it. Therefore, for example, if the user does not possess some of the multiple reference cards, the evolution synthesis of the base card cannot be executed. In this case, it may be impossible or difficult for the user to obtain the reference card that the user does not possess.
However, a user who does not know the conditions for obtaining the reference card cannot recognize that it is impossible or difficult to obtain the reference card at the time of deciding whether or not to perform a process (e.g., a quest process) for obtaining the reference card. In such a case, the user will perform the process for obtaining the reference card while being anxious that it may actually be impossible or difficult to obtain the reference object.
In this embodiment, the game server 20 presents the conditions for obtaining a reference card that the user does not possess in response to a request from the user. Therefore, even if a reference card that is impossible or difficult for the user to obtain is among the multiple reference cards corresponding to the base cards to be subjected to evolutionary synthesis, the user can decide whether or not to execute a process to obtain the reference card after recognizing that the reference card is impossible or difficult to obtain. As a result, the user who executes the process to obtain the reference card can be given a sense of security.

In addition, it is preferable that at least one of the acquisition route and the acquisition difficulty is presented as a condition for acquiring the card not yet possessed. In this case, the user can feel at ease when performing a process (e.g., a quest process) for acquiring the card not yet possessed.

As for the conditions for obtaining an unknown card, it is preferable that the difficulty of obtaining the card is displayed, but the route for obtaining the card is not presented (i.e., the information displayed as the conditions for obtaining an unknown card is more limited than the information displayed as the conditions for obtaining a card that the user does not own.) In this case, the difficulty of the game can be kept at an appropriate level, while providing a sense of security to the user who is performing the process for obtaining the unknown card (e.g., the quest process).

(1-9) Modifications of this embodiment Modifications of this embodiment will be described below. Note that the following modifications can be combined as appropriate.

(1-9-1) First Modification Image P4 in FIG. 12A or FIG. 13A shows a display format in which only the card image of the reference card is displayed, but the display format of this embodiment is not limited to this.
For example, instead of a display format that displays only the card image, a display format that displays only the card name may be used, or a display format that displays a combination of the card image and the card name may be used.
In other words, the display format of this embodiment may be any format that displays the reference cards in a manner that allows each user to identify them.

(1-9-2) Second Variation Example In the above embodiment, an example was described in which masking processing is applied to an image in S42 of FIG. 16B so as to prevent information from being displayed other than information relating to the difficulty of acquisition among the card data acquired in S38. However, the processing for preventing the display of such information is not limited to this.
For example, instead of applying the masking process, information other than information regarding the degree of difficulty of obtaining the item may be deleted, or the information may be replaced with a predetermined symbol.

(1-9-3) Third Variation Example In the embodiment described above, an example was described in which the card name, card image, rarity, and available area are not displayed in S42 of FIG. 16B, but this embodiment is not limited to this.
For example, the card image and available area may not be displayed, but the card name and rarity may be displayed.
Moreover, the information that is not to be displayed may be set by the user at his/her discretion.

(1-9-4) Fourth Variation Example In the above embodiment, an example was described in which in S42 of FIG. 16B, among the information about the card represented by the card data acquired in S38, no information other than information about the difficulty of acquisition is displayed, but S42 can be omitted.
If S42 is omitted, all of the card data obtained in S38 (i.e., information regarding the reference card for which acquisition conditions have been presented) will be displayed, giving the user a sense of hope that there is a possibility that the reference card may be acquired.

(1-9-5) Fifth Variation Example When an unowned card, which is a reference card that the user has owned in the past but does not currently own, is selected as a card for which acquisition conditions should be presented, it is desirable to display at least one of information regarding the area in which the card can be used and the difficulty of acquiring it as the acquisition conditions.
In this case, if the specified object is an object that the user has possessed in the past but does not currently possess, the acquisition conditions are as follows:
This is an example of a process for displaying at least one of the acquisition route and the acquisition difficulty of a designated object.
According to this modified example, the user can easily know the difficulty of obtaining the card.

(1-9-6) Sixth Modification In the above embodiment, an example was shown in which the acquisition conditions for unpossessed cards were displayed, but acquisition conditions for cards other than unpossessed cards may also be displayed.
As an example, the acquisition conditions of the owned cards may be displayed. For example, when a user has many owned cards, the user may forget the acquisition conditions of a certain owned card. In this case, by displaying the acquisition conditions of the owned card, the user can reconfirm the difficulty of acquiring the owned card. If the user recognizes that the owned card is difficult to acquire, the user may decide the purpose of the owned card (for example, to use it as a reference card for the evolution synthesis process of a base card) and the like.
On the other hand, if the user recognizes that the card in question is not difficult to obtain, this can provide an opportunity for the user to use the card in question without hesitation.

(1-9-7) Seventh Variation Example In the above embodiment, an example was described in which the change condition is satisfied when all reference cards corresponding to a base card are possessed. However, the change condition may also be satisfied when, in addition to possessing all the reference cards, a specified additional condition is met.
For example, the additional condition may be met when the card levels of all reference cards have reached a maximum level, or when the user possesses a predetermined amount of game points.

(2) Second embodiment In the first embodiment, a case where an image showing the acquisition conditions for the unowned card is displayed is described, but in the second embodiment, an example of a case where an image including an operation target for guiding the user to a route for acquiring the unowned card in addition to the acquisition conditions is displayed is described. Note that the same description as in the first embodiment will be omitted as appropriate.

(2-1) Specific Examples of Processing for Presenting Acquisition Conditions and Quest Processing A specific example of processing for presenting acquisition conditions for cards in the game of this embodiment will now be described with reference to Fig. 18. Fig. 18 is a diagram showing an example of a screen displayed on the user terminal 10 when the processing of the game of this embodiment is being executed.

(2-1-1) Processing for Presenting Acquisition Conditions (FIG. 18)
In image P4 of Figure 12A in the first embodiment, when a reference card for which the acquisition conditions are to be displayed (here, card DSG showing the "not possessed" status in display area 102) is selected and button b8 is operated, image P5 showing the acquisition conditions of the reference card selected by the user is displayed, as shown in Figure 18.

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

(2-1-2) Quest Processing (Figure 18)
When button b9 ("Go to available area") is operated in image P5, the image changes to that shown in P6. Image P6 shows a quest execution screen. By performing a predetermined operation in image P6, the user can explore the area used in the quest (here, area 1). When the quest conditions are met, the user can obtain an unowned card based on a probability according to the value of the "acquisition rate" in the quest data table.

(2-2) Processing Flow of the Game of this Embodiment Next, an example of the processing flow of the game of this embodiment will be described with reference to the sequence chart of FIG.
Fig. 19 is a sequence chart showing the quest process. In Fig. 19, the steps in which the images P5 to P6 shown in Fig. 18 are displayed are given the reference numerals of the images.

(2-2-1) Processing for Presenting Acquisition Conditions In this embodiment, in S44 (FIG. 16A), the CPU 21 of the game server 20 acquires image data (FIG. 18A) for presenting an operation target for guiding the user to a route for acquiring the reference card (here, an area where the reference card can be acquired) in addition to the card data of the reference card acquired in S38.
The second embodiment differs from the first embodiment in that the second embodiment generates image data that is the basis of image P5.

(2-2-2) Quest Processing (Figure 19)
In FIG. 19, a predetermined button (e.g., FIG. 18) is pressed on the image displayed on the user terminal 19.
When the button b9 of the image P5 is operated, the CPU 11 of the user terminal 10 accepts a request for quest processing (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 CPU 21 retrieves the quest data (
Based on the area name, consumed stamina, acquired card data (card ID and acquisition rate), acquired item data (item ID and acquisition rate), boss ID, and quest UI data, image data for the quest process (image data that is the basis of image P6 in FIG. 18) 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 CPU 11 displays an image based on the image data (for example, image P6 in FIG. 18) on the display unit 16 (S78
).

After that, the CPU 11 of the user terminal 10 transmits an instruction according to the user's operation to the game server 2.
0. The CPU 21 of the game server 20 progresses the quest based on the transmitted instructions. When the quest progresses to a predetermined level, the CPU 21 executes a battle between the user and a boss character associated with the boss ID. When the user meets the victory conditions in the battle, the CPU 21 executes a process of granting a card according to the value of the "acquisition rate" associated with the quest ID. In the process of granting a card, the CPU 21 executes
The card ID corresponding to D is written into the possessed card data table, and the value of "number of acquisitions" corresponding to the card ID in the possession history data table is incremented. This allows the user to obtain the card selected in image P4 of Fig. 12A in the first embodiment (the reference card for which the acquisition conditions should be displayed).

As described above, the game server 20 of this embodiment presents the conditions for obtaining a reference card that the user does not possess, along with an operation object for guiding the user to a route for obtaining the reference card, so that the user can request the execution of a process for obtaining an object simply by operating the operation object, thereby improving operability when requesting the execution of the process.

(3) Third embodiment In the second embodiment, a case where an image including an operation object for guiding the user to the acquisition route of the unowned card is displayed is described, but in the third embodiment, in addition to the operation object for guiding the user to the acquisition route of the unowned card, an example of a case where an image including an operation object for guiding the user to the acquisition route of the unowned card and executing the reservation process of evolution synthesis after the user obtains the unowned card is displayed will be described. Note that the same explanation as the above embodiment will be omitted as appropriate.

(3-1) Specific examples of the process of presenting acquisition conditions, the process of quests, and the process of reserving evolutionary synthesis Specific examples of the process of presenting acquisition conditions, the process of quests, and the process of reserving evolutionary synthesis in the game of this embodiment will be described below with reference to Fig. 20. Fig. 20 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.

(3-1-1) Processing for Presenting Acquisition Conditions (FIG. 20)
In image P4 of Figure 12A in the first embodiment, when a reference card for which the acquisition conditions are to be displayed (here, card DSG showing the "not possessed" status in display area 102) is selected and button b8 is operated, image P5 showing the acquisition conditions of the reference card selected by the user is displayed, as shown in Figure 20.
Image P5 in FIG. 20 differs from the first embodiment (image P5 in FIG. 12B) in that it includes a button b10 ("Do not reserve/Go to available area") and a button b11 ("Make a reservation/Go to available area") in addition to the display areas 103 and 104.
A button b10 is operated when the user requests a quest process to obtain a card that the user does not own. A button b11 is operated when the user requests both the quest process and the reservation process for evolution synthesis.

(3-1-2) Quest Processing (Figure 20)
When the button b10 ("No reservation/Go to available area") is operated in the image P5, the image changes to that shown in P6. The image P6 is the same as the image P6 in the second embodiment (FIG. 18).
) is the same as

(3-1-3) Evolution synthesis reservation process (Figure 20)
When button b11 ("Reserve/Go to available area") is operated in image P5, the quest process is performed and a reservation process is carried out for the reference card held by the user, and image P7 is displayed indicating that the reservation process has been completed.

(3-2) Processing flow of the game according to this embodiment (FIG. 21)
Next, an example of the processing flow of the game of this embodiment will be described with reference to the sequence chart of Fig. 21. Note that the acquisition condition presentation processing and quest processing of this embodiment are executed in the same manner as in the second embodiment.
Fig. 21 is a sequence chart showing the reservation process for evolutionary synthesis. In Fig. 21, the step in which each of the images P5 to P7 shown in Fig. 20 is displayed is assigned the reference number of each image.

In the reservation process described below, as an example, we will assume that a user reserves a reference card that they do not currently own for the evolutionary synthesis of a base card, out of multiple reference cards for the evolutionary synthesis of a base card.

In FIG. 21, a predetermined button (e.g., FIG. 20) is pressed on the image displayed on the user terminal 10.
When the user operates the button b11 of the image P5, the CPU of the user terminal 10
The game server 11 receives a request for reservation processing of evolution synthesis (S50) and transmits the request to the game server 20.
(S52). The request includes a card ID that identifies the unowned reference card displayed in the display area 103 of FIG.
S52 is an example of a process for accepting a request for restricting the use of the designated object in processes other than the process of changing the selected object, based on an operation by the user.

When the CPU 21 of the game server 20 receives a request for the evolution synthesis reservation process, it accesses the reservation data table and determines whether a reservation ID corresponding to the serial number of the base card obtained in S24 (Figure 16A) has already been issued (i.e., whether the same serial number is recorded in the ``pre-evolution card'' column) (S54).
If a reservation ID has already been issued (S54: YES), proceed to S58; if a reservation ID has not already been issued (S54: NO), proceed to S58 after issuing a reservation ID (S56). In S58, the CPU 21 writes a temporary serial number in association with the reservation ID into the reservation data table. At this time, if the CPU 21 has issued a new reservation ID, it writes the serial number of a base card among the cards to be reserved in the "pre-evolved card" column, and writes data indicating that the card is not a card to be reserved (for example, N
Write the .ULL.

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

Next, the CPU 21 generates image data indicating that the reservation has been completed (S62), and transmits the image data to the user terminal 10 (S64).
When the image data transmitted at 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).

Thereafter, when the user obtains the reserved card (i.e., when the card ID and serial number of the reserved card are recorded in association with the user's card data), the CP
U21 rewrites the temporary serial number written in the reservation data table in S58 to the serial number included in the possessed card data.

In FIG. 21, when a predetermined button (e.g.,
When the button b10 in the image P5 in FIG. 20 is operated, a quest process (FIG. 19) similar to that in the second embodiment is performed.

As described above, the game server 20 of this embodiment guides the user to a route for obtaining a reference card that the user does not possess, together with the conditions for obtaining the reference card, and presents an operation object for requesting a process for reserving the reference card, thereby making it possible to restrict the reserved card from being used for processes other than the desired evolution synthesis. Therefore, during the waiting period until the remaining reference cards that the user does not possess are obtained, it is possible to prevent the user from mistakenly using the card that the user possesses for processes other than the desired evolution synthesis.

(4) Fourth embodiment In the above embodiment, an image showing the acquisition conditions of a reference card is displayed when a user operates a button to request the presentation of the acquisition conditions of the reference card. In the fourth embodiment, an example of a case where an image showing the acquisition conditions of a reference card to satisfy the change conditions of evolution synthesis of the base card is displayed when a user operates a button to confirm the selected card as the base card of evolution synthesis is described. Note that the same explanation as the above embodiment will be omitted as appropriate.

(4-1) Specific Example of Processing for Presenting Acquisition Conditions A specific example of processing for presenting acquisition conditions for cards in the game of this embodiment will be described below with reference to Fig. 22. Fig. 22 is a diagram showing an example of a screen displayed on the user terminal 10 when the processing of the game of this embodiment is being executed.

- Processing for presenting acquisition conditions (Fig. 22)
22 shows a series of changes in the display screen in the acquisition condition presentation process for presenting the acquisition conditions for the card not yet possessed. Images P1 to P3 in FIG. 22 are the same as those in FIG. 12 of the first embodiment.
A is similar to images P1 to P3.

When the button b6 is operated in the image P3, the card K selected as the base card is
If the condition of the reference card required for the evolution of the card KLM is not met, the image is updated as shown in P4. The image P4 is an image for presenting the acquisition condition of the card that the user does not possess among the reference cards required for the evolution of the card KLM selected as the base card. Note that, when the user selects the button b6 in the image P3, if the condition of the reference card required for the evolution of the card KLM selected as the base card is met, an image (not shown) is displayed for the user to instruct whether or not to execute the evolution synthesis of the card KLM.

Image P4 in FIG. 22 shows, in the display area 102, reference cards required for evolutionary synthesis and their status (either owned, not owned, reserved, or unknown), as well as the acquisition conditions for not owned cards or unknown cards, which is different from the first to third embodiments (FIGS. 12A, 13A, and
21A) In the display area 102, as an example, information indicating a route to obtain a card that is not yet possessed (here, the area name "Area 1") is displayed.

(4-2) Game Processing Flow of the Present 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. 23. Fig. 23 is a sequence chart showing the process of presenting acquisition conditions.
In Fig. 23, the steps in which the images P1 to P4 shown in Fig. 22 are displayed are given the same reference numerals as those of the images. Also, in Fig. 23, the same processes as those in Fig. 16A and Fig. 16B are given the same reference numerals.

In the process of presenting acquisition conditions described below, as an example, assume that a user possesses a base card and some of multiple reference cards for evolving and synthesizing the base card, and requests the presentation of acquisition conditions for a reference card that the user does not possess.

After S26 (FIG. 16A) of the first embodiment is executed, the CPU 21 of the game server 20
Based on the multiple reference card IDs read out in S26, obtains the card data of the reference card (card name, card image, rarity, quest ID, area name of area where the card can be used, number of times acquired, number in circulation, and average trading price) from the card data table, quest data table, and card circulation data table (S38). The card name, card image, and rarity are obtained from the card data table. The quest ID and area name of area where the card can be used are obtained from the quest data table. The number of times acquired is obtained from the possession history table. The number in circulation and average trading price are obtained 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 (Figure 16B) of the first embodiment, and then generates image data (image data that is the basis of image P4 in Figure 22) for presenting the user with the conditions for obtaining the reference card based on the card data of the reference card obtained in S38 (S44), and transmits the image data to the user terminal 10 (S46).

When the CPU 11 of the user terminal 10 receives the image data transmitted in S46, the CPU 11 displays an image (e.g., image P4 in FIG. 22) on the display unit 16 based on the image data (S4
8).

As described above, the game server 20 of this embodiment presents the conditions for obtaining reference cards that the user does not possess and that are necessary for the desired evolutionary synthesis in response to the user's operation of selecting a base card to be the target of evolutionary synthesis, thereby improving the operability of the operation of presenting the conditions for obtaining reference cards necessary for the evolutionary synthesis of a base card.

(5) Fifth embodiment In the above-described embodiment, an example of displaying a screen presenting the conditions for obtaining a card that is not owned is described. In the present embodiment, however, an example of processing is described in which a screen presenting the conditions for obtaining a card that is owned is displayed, and a card specified by the user on the screen is used for some processing and thereby prevented from being lost.

(5-1) Pre-ordering and favorites registration of game cards in this embodiment (FIG. 24)
In the game of this embodiment, consider a case where a user wants to evolve a desired base card by evolution synthesis, but does not have some or all of the reference cards required to evolve the base card. In this case, it is necessary to wait to execute the evolution synthesis of the base card until the user can obtain a new card (i.e., the remaining reference card) that satisfies the conditions of the combination of the reference cards. However, if the user loses the reference card he or she owns by using it for a purpose other than the evolution of the base card before obtaining the remaining reference card, and it is difficult to satisfy the conditions for obtaining the reference card, it becomes difficult to evolve the base card. For example, in a case where the user mistakenly loses the reference card (for example, by selling it) before executing the evolution synthesis, if the probability of obtaining the reference card is low or the period during which the reference card can be obtained is limited, it becomes difficult for the user to evolve the desired base card.
Therefore, in this embodiment, it is possible to reliably prevent the reference cards required to evolve a desired base card from being lost against the user's will.

The reservation registration and favorites registration of a reference card will be specifically described with reference to Fig. 24. Fig. 24 is a diagram for conceptually explaining the reservation registration and favorites registration of a reference card.
In FIG. 24, consider a case where a user wants to evolve a card Q that is a card that the user owns. In this case, in order to evolve card Q, cards A, B, and C are used as multiple reference cards.
Assuming that a combination of the following is required. Since the user does not currently possess card B, evolution synthesis cannot be performed on card Q. Furthermore, if it is difficult to fulfill the conditions for obtaining card A, and the user loses card A from their possessed cards by using it for a purpose other than evolving card Q, it becomes difficult to evolve card Q. Therefore, in this embodiment, in order to prevent the user from unintentionally losing card A from their possessed cards, the conditions for obtaining card A are presented, and then the following is performed on card A:
Accept reservation registration or favorite registration.
Reservation registration means putting card A into a state in which it is restricted from being used in any process other than the evolutionary synthesis of card Q selected as a base card, among the processes that are executed on the condition that card A is eliminated from the owned cards.
Registering as a favorite means putting card A into a state where it is restricted from being used in processes (including evolutionary synthesis of card Q selected as a base card) that are executed on the condition that card A is removed from the cards in hand.
Reservation registration and favorite registration are examples of processing that restricts a designated object, which is an object designated by a user, from being used in a predetermined process. The "predetermined process" is processing that is executed on the condition that the designated object is removed from the owned objects. In other words, an object designated from among the owned objects, which are objects that the user possesses, becomes an object that is subject to the restriction by reservation registration and favorite registration.

In this way, by presenting the acquisition conditions for card A and then accepting reservation registration or favorite registration for card A, the user can make a request to restrict the use of card A in a process to eliminate card A from the cards in his possession immediately after recognizing that card A is difficult to obtain based on the presented acquisition conditions. Therefore, unintentional loss of card A can be reliably prevented.

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

The owned card data table records information about the cards owned by the user. An example of the configuration of the owned card data table is shown in Fig. 25. Fig. 25 shows an example of the owned card data table for one user, but the owned card data table is provided for all users registered in the game.
The possessed card data table of FIG. 25 differs from the possessed card data table of FIG. 8 in that data of the registration type is recorded in association with each card ID.
The registration information is data indicating a combination of the type of registration (reservation registration or favorite registration) made for the possessed card data and the type of screen on which the registration request was made (a screen presenting the acquisition conditions (hereinafter referred to as the "acquisition condition presentation screen") or a "reference card list screen required for evolution synthesis for each base card"). In the example of FIG. 25, for cards that have been reserved and registered via the acquisition condition presentation screen, "1" is recorded in the registration information, for cards that have been registered as favorites via the acquisition condition presentation screen, "2" is recorded in the registration information, for cards that have been registered as favorites via the card list screen, "4" is recorded in the registration information, and for cards that have not been reserved or registered as favorites, "N/A" is recorded.

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

Image P5 in FIG. 26 differs from the first embodiment (image P5 in FIG. 12B) in that it includes a button b12 ("Reservation registration") and a button b13 ("Favorite registration").
The button b12 ("reservation registration") is operated when the user requests the reservation registration of a card he or she owns.
The button b13 ("Add to favorites") is operated when the user requests to add a card he or she owns to the favorites list.

When the button b12 ("Reservation registration") is operated in the image P5, the image changes to that shown in P21. In the image P21, the result of the reservation registration process is shown.
When the button b13 ("Add to favorites") is operated in image P5, the image changes to that shown in P22. Image P22 shows the result of executing the add to favorites process.

(5-3-2) Specific Example of Display Process of the Game Change Condition List Screen of the Present Embodiment (FIG. 27A
~ Figure 27C)
In the image P1 of FIG. 12A of the first embodiment, when the button b4 ("Evolutionary Synthesis") is operated, an image P23a corresponding to the change condition list screen of this embodiment is displayed as shown in FIG. 27A.
is displayed. The image P23a is also called a change condition list screen.

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.
The display area 105 displays the card images and card names of the base card and the reference card for each combination of the base card and the reference card. In other words, the reference card for each base card is displayed in the display area 105. 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, the reference cards are displayed in such a manner that the owned cards and the unowned cards can be distinguished from each other. In the example of Fig. 27A, the cards VIC, DSG, MIT, and KAY are displayed with solid lines indicating that they are owned cards, and the card TED is displayed with dashed lines indicating that it is an unowned card.
In addition, in the display area 105, a mark m1 is displayed on the card image of the card that is the subject of reservation registration performed via the acquisition condition presentation screen. The mark m1 is a mark (also called a "symbol" or "mark") displayed on the card image of the card that is in a state in which it is restricted from being used for processing other than the evolution synthesis of the base card among the processing executed on the condition that the card DSG is erased from the owned cards. 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. In other words, FIG. 27A shows that the card DSG is in a state in which it is restricted from being used for processing other than the evolution synthesis of the card KLM among the processing executed on the condition that the card DSG is erased from the owned cards.
In addition, 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 the card that is in a state in which it is restricted from being used in a process (including evolution synthesis of a base card) that is executed on the condition that the card KAY is erased from the owned cards. In the example of FIG. 27A, the mark m2 is displayed on the card image of the card KAY. In other words, FIG. 27A shows that the card KAY is in a state in which it is restricted from being used in all processes that are executed on the condition that the card KAY is erased from the owned cards (for example, the evolution synthesis process of a card SAM and the sale process of the card KAY).
By selecting a card image, the user can select the card corresponding to the card image. In the example of Fig. 27A, when card image b14 is selected, card MIT is selected as a reference card required for the evolution synthesis of card KLM, and when card image b15 is selected, card MIT is selected as a reference card required for the evolution synthesis of card SAM.
When the user selects a card and operates the button b12 ("reserve") or the button b13 ("favorite"), the user can request reservation or favorite registration for the selected card. In the example of Fig. 27A, when the user selects the card image b14 and operates the button b12 ("reserve") or the button b13 ("favorite"), reservation or favorite registration for the card MIT, which is a reference card required for the evolution synthesis of the card KLM, is requested.

When the user selects the card image b14 in the image P23a and operates the button b12 ("reservation registration"), the image changes to image P23b. Image P23b differs from image P23a in that a mark m3 is displayed on the card image of card MIT, which is a reference card required for the evolutionary synthesis of card KLM. Mark m3 is a mark indicating the reference card that is the subject of reservation registration performed via the change condition list screen.
A mark m4 is displayed on the card image of the card MIT as a reference card required for the evolutionary synthesis of the card SAM. The mark m4 is a mark indicating that the card MIT has been pre-registered as a reference card required for the evolutionary synthesis of another base card (card KLM).
In the example of FIG. 27B, the card MIT is used as a reference card for the evolutionary synthesis of the card KLM.
A mark m3 is displayed on the card image of the card MIT, which is a reference card required for the evolutionary synthesis of the card SAM, and a mark m4 is displayed on the card image of the card MIT. In this case, the card MIT is restricted from being used for processes other than the evolutionary synthesis of the card KLM among the processes executed on the condition that the card MIT is eliminated from the owned cards. In other words, the card MIT can be used for the evolutionary synthesis of the card KLM, but cannot be used for the evolutionary synthesis of the card SA.
It will no longer be possible to use it in the evolution synthesis or sale process of M.

When the user selects the card image b14 in the image P23a and operates the button b13 ("Add to favorites"), the image changes to an image P23c.
is displayed on the card image of the card MIT. The mark m5 is a mark indicating a reference card that has been registered as a favorite via the change condition list screen.
In the example of FIG. 27B, the card MIT is used as a reference card for the evolutionary synthesis of the card KLM.
Card images of the cards and Card MI as a reference card necessary for the evolutionary synthesis of Card SAM
The mark m5 is displayed on the image of the T card. In this case, for the MIT card,
Card MIT is restricted from being used in all processes that are executed under the condition that Card MIT is eliminated from the owned cards. In other words, Card MIT is restricted from being used in the evolution synthesis process of Card KLM, Card SA
It will no longer be possible to use it in either the evolution synthesis process of M or the sale process.

In images P23a to P23c, marks m1 to m5 are displayed in mutually distinguishable shapes, patterns, or combinations thereof, allowing the user to easily distinguish between the reference card that is the subject of reservation registration made via the acquisition condition presentation screen, the reference card that is the subject of favorite registration made via the acquisition condition presentation screen, the reference card that is the subject of reservation registration made via the change condition list screen, and the reference card that is the subject of favorite registration made via the change condition list screen.
Specifically, for marks m1 to m5, the type of registration (reservation registration or favorite registration) is identified by the shape of the mark, and the screen on which the registration request was made (acquisition condition presentation screen or change condition list screen) is identified by the pattern of the mark.

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

In the registration process described below, a case where a reservation registration process or a favorite registration process is requested is assumed as an example of a process for restricting a specified object, which is an object designated by a user, from being used for a specific process.

After S48 (FIG. 16B) of the first embodiment is executed, the CPU 21 of the game server 20
button b12 ("Reservation registration") or button b13 displayed on image P5 of FIG.
Based on a user operation on "Register as favorites," the game server 20 receives a request for reservation registration processing or a request for favorite registration processing (S170), and transmits the request to the game server 20 (S171).
Note that image P5 in Figure 26 is an example of output data for displaying the acquisition conditions of multiple objects specified by multiple object identification information included in the change conditions corresponding to the object identification information of the selected object, which is the selected object.
The reservation registration processing request includes a user ID, a base card serial number, a reference card serial number, and information for identifying the type of image (e.g., image P5 in FIG. 26 or image P23a in FIG. 27A) that was displayed when the reservation registration processing request was made (i.e.,
The reservation registration processing request includes information for identifying the type of screen passed through to make the reservation registration processing request, and information for identifying that it is a reservation registration processing request.
The request for favorites registration processing includes the user ID, the serial number of the reference card, information identifying the type of image that was being displayed when the request for favorites registration processing was made (e.g., image P5 in FIG. 26 or image P23a in FIG. 27A) (i.e., information identifying the type of screen passed through to make the request for favorites registration processing), and information identifying that it is a request for favorites registration processing.
The reservation registration processing request and the favorites registration processing request are examples of requests for restricting the use of a specified object, which is an object specified by a user, in a predetermined process.

When the CPU 21 of the game server 20 receives the request from the user terminal 10, the CPU 21 executes a registration process (reservation registration or favorites registration) in response to the request (S172).
The process of S172 is an example of a process for restricting the designated object from being used in a predetermined process.

If the request accepted in S170 is a request for reservation registration processing, the CPU 21 records, for the owned card data specified by the serial number of the reference card included in the request, registration information indicating that the card is the subject of reservation registration performed via the acquisition condition presentation screen (registration information "1" in FIG. 25). Also, for the reservation data specified by the serial number of the base card included in the request, the CPU 21 records the serial number of the reference card in the field C1 to C5 corresponding to the card ID of the reference card. As a result, the serial number of the reference card subject to 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 (i.e., the reference card is reserved for evolution synthesis of base cards other than the base card), and is deleted from the owned card data (i.e., the reference card is erased from the owned cards (e.g., a selling process is executed)).
is restricted.
On the other hand, if the request accepted in S170 is a request for favorites registration processing,
U21 records registration information (registration information "2" in FIG. 25) indicating that the card is the subject of favorite registration via the acquisition condition presentation screen, for the possessed card data specified by the serial number of the reference card included in the request. As a result, for the serial number of the reference card subject to favorite registration, the serial number is recorded in the reservation data table and deleted from the possessed card data (i.e.,
The ability to remove the reference card from the cards in hand is restricted.

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

When the CPU 11 of the user terminal 10 receives 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).
26 is displayed on the display unit 16 of the number 0.
S174 is an example of a process for outputting data for displaying objects that are subject to restrictions due to reservation registration and objects that are subject to restrictions due to favorite registration in a display format that is distinguishable from each other by the user.

By using the registration information in FIG. 25, marks m1 to m
5, the type of registration and the type of screen displayed when the registration request was made can be displayed so that the user can identify them. For example, when the user operates the button b4 ("Evolutionary Synthesis") of the image P1 of Fig. 12A, the display unit 16 displays the image P23b of Fig. 27B when the reservation registration process is executed in S172, and displays the image P23c of Fig. 27C when the favorites registration process is executed in S172.

As described above, the game server 20 of this embodiment displays the following on the acquisition condition presentation screen:
The system accepts requests for reservation registration processing to restrict the use of a reference card in possession for processes other than the evolutionary synthesis of a base card, or requests for favorite registration processing to restrict the use of a reference card in processes (including the evolutionary synthesis of a base card) that are executed on the condition that the card is deleted from the cards in possession.
This allows the user to prevent the reference card from disappearing unintentionally immediately after recognizing on the acquisition condition presentation screen that it is difficult to obtain the reference card he or she possesses.
In particular, the more base cards and reference cards used in the evolutionary synthesis of the base cards a user owns, the more difficult it becomes for the user to manage which reference cards should be used in which base cards. As a result, the user may lose a reference card unintentionally due to an operational error or forgetting the purpose of the reference card.
In contrast, in this embodiment, immediately after the user recognizes from the acquisition condition presentation screen that the reference card is difficult to obtain, a request can be made to restrict the reference card from being used in a process that is executed on the condition that the reference card is lost, thereby reliably preventing the reference card from being lost against the user's intention.

Furthermore, in this embodiment, the user can make two types of registration requests (reservation registration and favorite registration). Therefore, the user can use different registrations depending on the purpose (i.e., select the range of restrictions to be placed on the reference card). For example, a user who wants to use a reference card in the evolution synthesis of a specific base card can prevent the reference card from being lost due to performing processes other than the evolution synthesis of the specific base card by making a reservation registration request. Also, a user can use the reference card to evolve without deciding which base card to evolve,
A user who wishes to prevent the reference card from being lost can reliably prevent the reference card from being lost by requesting to register the reference card as a favorite. Thus, the user can flexibly manage the use of the reference card.

In addition, the game server 20 of this embodiment displays, in a distinguishable manner, on the change condition list screen, reference cards that have been the subject of reservation registration made via the change condition list screen and reference cards that have been the subject of favorite registration made via the acquisition condition presentation screen.
Furthermore, the game server 20 of this embodiment displays the combination of base cards and reference cards that are the subject of reservation registration in an identifiable manner.
Furthermore, the game server 20 of this embodiment displays reference cards that are the subject of reservation registration and reference cards that are the subject of favorite registration in a distinguishable manner.
This allows the user to visually understand the purpose of the cards they own (specifically, to use them in the evolutionary synthesis of a specific base card, or to keep them without deciding what their purpose is).

(5-5) Modifications of this embodiment Modifications of this embodiment will be described below. The following modifications can be combined as appropriate.
(5-5-1) First Modification In the present embodiment, a case has been described in which the reference card to be registered (reservation registration or favorite registration) is a possessed card. However, in the present embodiment, the reference card to be registered may be a non-possessed card.
For example, the change condition list screen is configured to be able to accept 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 that is the subject of the request (i.e., the card ID and serial number of the card are recorded in the possessed card data table), the reservation registration process or the favorite registration process is executed for the card.

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

As an example, a screen showing acquisition conditions (e.g., an image P showing the execution result of the reservation registration process)
21, or an image P22 showing the result of the favorites registration process) is marked with marks m1 to m2.
m5 may be displayed.

As another example, marks m1 to m5 may be displayed on a screen showing a list of owned cards (hereinafter referred to as "owned card list screen").
Specifically, when button b1 ("View Owned Monsters") is operated on image P1, a possessed card list screen is displayed. On the possessed card list screen, information about possessed cards (e.g., card images and card names) is displayed as a list, as in the change condition list screens of Figures 27A to 27C. Among the possessed cards, any of marks m1 to m5 is displayed on the card image of a card that has been reserved or registered as a favorite.

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

For example, when a card image on which any of the marks m1 to m5 in FIG. 27A to FIG. 27C is displayed is selected by the user, the card corresponding to the selected card image (i.e.,
A request to cancel reservation registration or favorite registration for a card that is in a reserved or favorites state is accepted. Specifically, in FIG. 27A, when a card image with a mark m1 is selected, the reserved card DSG is selected, and a button that is specified when requesting cancellation of registration is displayed. At this time,
When the user operates the button, the reservation registration made for the card DSG is cancelled, and the mark m1 displayed on the card image disappears.
G is in a state where no registration has been made (that is, it is in a state where it can be used for all processes).

According to this modified example, for a reference card that was registered as a favorite when the use has not been decided, the registration as a favorite can be cancelled and a reservation can be registered.
In addition, when a reference card is reserved for evolutionary synthesis of a specific base card, the user can cancel the reservation and register the card as a favorite. This allows the user to flexibly manage the use of the reference card and the range of restrictions placed on the reference card.

(5-5-4) Fourth Modification In this embodiment, as shown in FIG. 26 and FIG. 27A to FIG. 27C,
Although an example in which the button b13 ("Add to favorites") and the button b14 ("Add to favorites") are displayed side by side has been described, it is also possible to display only one of these two buttons.

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

Specifically, when the user operates button b12 ("Reservation registration") or button b13 ("Favorite registration") while card image b14 of image P23a is selected, the CPU 11 of the user terminal 10 accepts a request for reservation registration processing or a request for favorite registration processing based on the operation (S170), and transmits the request to the game server 20 (S171).

When the CPU 21 of the game server 20 receives a request from the user terminal 10, it executes the registration process (reservation registration or favorite registration) according to the request (S172), and transmits the result of the registration process to the user terminal 10 (S173).

When the CPU 11 of the user terminal 10 receives 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).
On the display unit 16 of the number 0, the image P23b of FIG. 27B or the image P23c of FIG. 27C is displayed.

As described above, the registration process in this modified example includes four types of registration (reservation registration made via the acquisition condition presentation screen, favorite registration made via the acquisition condition presentation screen, reservation registration made via the change condition list screen, and favorite registration made via the change condition list screen). Each screen displays information about the card in a display format that allows the user to distinguish between the four types of registration.

(6) Sixth embodiment In the above embodiment, communication is performed between the user terminal 10 and the game server 20 according to HTTP, and the user terminal 10 displays game images by interpreting HTML documents acquired from the game server 20. In this case, the present invention is realized in a so-called browser format. However, the present invention is not limited to this. The user terminal 10 executes a game program downloaded by the user terminal 10, thereby independently executing game processing.
The game may be realized in a so-called native application format, which suppresses the transmission and reception processing between the game server 20 and the user terminal 10. In the native application format, the CPU 11 of the user terminal 10 generates image data and displays the image data on the display unit 16 without using a web browser.
Display the image in.
In this embodiment, an example of the case where the game of the above-mentioned 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 this embodiment, it is assumed that most of the processing is performed on the user terminal 10 side, but some of the processing of the game not described below (for example, a lottery processing in which a prize is awarded to a user by lottery, and a gift processing in which a game operator awards a card to a user, etc.) is performed on the game server 20 side,
The game server 20 may be configured to transmit the processing results to the user terminal 10.

In this embodiment, the user terminal 10 receives a game program from the game operator's server 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, a login process is performed, and a group of data tables (a card data table, an evolution synthesis data table, a possessed card data table, a possessed history data table, and a card circulation data table) is transmitted from the game server 20 to the user terminal 10. The group of data tables transmitted to the user terminal 10 is held in the storage 18 of the user terminal 10. In this case, the group of data tables in the storage 18 is updated every time a user logs in.
In order to prevent the possessed card data table from being tampered with in the user terminal 10,
Each time a predetermined process is completed by the user terminal 10, or when the user logs out of the game, the possessed card data table in the user terminal 10 is transmitted to the game server 20.
The game server 20 compares the received possessed card data table with the possessed card data table in the storage 25, and after confirming that the data has not been tampered with,
The possessed card data table in the storage 25 is updated based on the received possessed card data table.

29A and 29B are sequence charts showing the process of presenting acquisition conditions according to this embodiment. In each of Figs. 29A and 29B, the same processes as those in Figs. 16A and 16B are denoted by the same reference numerals.
In the evolution synthesis reservation process of this embodiment (FIGS. 29A and 29B), for example, at the time of login, the game server 20 transmits the data tables in the storage 25 (card data table, evolution synthesis data table, possession card data table, possession history data table, and card circulation data table) to the user terminal 10 (S8).
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 to execute S14.
Execute the process of -S48.
Although not shown in the figure, in this embodiment, the evolution synthesis process, quest process, and evolution synthesis reservation process are also similarly executed by the user terminal 10 independently.
In this embodiment, the card data table, the evolution synthesis data table, the quest data table, the possession card data table, the possession history data table, and the card circulation data table are held in the game server 20, and the reservation data table is stored in the user terminal 10.
In the above description, the data tables are stored in the user terminal 10, but the present invention is not limited to this case. In a game in the native application format, the storage allocation of each data table can be appropriately set, and it is sufficient that the data tables are stored in at least one of the user terminal 10 and the game server 20, and the storage mode is not limited to a specific one. When any of the data tables is stored in the game server 20, the data table stored in the game server 20 is transmitted to the user terminal 10 when the game is executed, and is used for processing the game executed in the user terminal 10.

(7) Modifications common to all embodiments (7-1) Modifications related to application to applications other than games In the above-mentioned embodiment and modification, the present invention has been described as being applied to games, but it may also be applied to other applications. For example, if multiple types of electronic coupons are distributed each time a product is purchased at an online shopping mall, the electronic coupons may be an example of an object of the present invention. In this case, for example, in order to upgrade the benefit content of coupon Q as a base object (an example of a process of changing an object), coupons A to H as reference objects corresponding to coupon Q may be used.
In this example, the purpose is to upgrade coupon Q, and among coupons A to C required for that purpose, the conditions for obtaining a coupon that the user does not possess (e.g., coupon B) are presented.
The present invention can also be applied to other applications besides the above-mentioned examples.

(7-2) Modifications Related to Operation Input Method In the above-described embodiment, the predetermined operation input to the user terminal is the input of pressing a predetermined instruction button on the user terminal, or the input of a touch operation on the display screen of a user terminal equipped with a touch panel function, but the operation input is not limited to this. The operation input may be an operation input by shaking a user terminal equipped with an acceleration sensor, or an operation input by a gesture (gesture input). In gesture input, a predetermined gesture is made on a user terminal equipped with an imaging function, and the user terminal recognizes the gesture as an image,
The operation input that is associated with the gesture in advance is recognized. In addition, in the case of a user terminal capable of executing a voice recognition program, the operation input may be performed by inputting a voice.

(7-3) Modifications Regarding Handling of User ID In the above-described embodiment, it is assumed that the request sent from the user terminal 10 to the game server 20 includes a user ID (i.e., the game server 20 can identify the user who has made the processing request based on the request sent from the user terminal 10), but the method by which the game server 20 identifies the user who has made the processing request is not limited to this.
For example, when a session based on a user ID is established between the user terminal 10 and the game server 20, the game server 20 may identify the user making a request for processing after the session by the user ID. In this case, the request sent from the user terminal 10 to the game server 20 does not need to include the user ID (i.e., the user ID does not need to be sent from the user terminal 10 to the game server 20).

(7-4) Modifications Related to the Object to be Operated In the above-described embodiment, a button displayed on an image is shown as an example of an object to be operated by a user, but any form that can be operated by a user may be used.

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

One aspect of the present invention is
An information processing device that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process of changing the object, in association with each other, comprising:
a first display format for displaying 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, which is an object selected based on a user's instruction, in a display format that is identifiable by the user;
An output means (56) for outputting output data;
a receiving means (51) for receiving an instruction to designate one of the plurality of objects based on an instruction from the user in response to the first output data being output by the output means (56),
The output means (56) further outputs second output data for displaying a condition for acquiring a designated object, the designated object being an object designated by the instruction accepted by the accepting means (51), when the user does not possess the designated object.
Information processing device.

The "information processing device" may be a stand-alone game machine, a user terminal (e.g., a mobile terminal, a personal computer, etc.), or a server on a network. The entity of the information processing device can be defined appropriately depending on the implementation form of the game. For example, when the functions of each part of the information processing device are realized by a user operating a game machine or a user terminal, the game machine or the user terminal corresponds to the information processing device of the present invention. Alternatively, when a user terminal, which is a client, has a function of receiving operation input from a user and displaying images, and the functions of each part of the information processing device are realized by a server that can substantially 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, a hard disk drive (HDD), etc. The storage device may be a device built into the information processing device, or may be an external device that can be accessed from the information processing device via a wired or wireless connection.
The "acquisition conditions" may be subjective conditions (e.g., information about the user who possesses the object), time conditions (e.g., the period during which the object is available), content conditions (e.g., the average trading price, a second object (e.g., an item) required to acquire a first object (e.g., a card), or a combination thereof), location conditions (e.g., the area in which it is available), or a combination thereof.

In the information processing device, the process of changing the selected object is executed based on the change condition including at least information indicating a plurality of objects and the user's possession information. Therefore, for example, if the change condition is not satisfied, the process of changing the selected object cannot be executed. In this case, it may be impossible or difficult for the user to obtain the designated object that the user does not possess. However, a user who does not know the conditions for obtaining the designated object cannot recognize that it is impossible or difficult to obtain the designated object at the time of deciding whether or not to perform the process (e.g., quest process) for obtaining the designated object. In such a case, the user will execute the process for obtaining the designated object while feeling anxious that it may actually be impossible or difficult to obtain the reference object.
In the information processing device, in response to a request from a user, the conditions for obtaining a reference object that the user does not possess are presented. Therefore, even if a designated object that is impossible or difficult for the user to obtain is included in the multiple reference cards corresponding to the selected object, the user can determine whether or not to execute a process to obtain the designated object after recognizing that it is impossible or difficult to obtain the designated object. As a result, a sense of security can be given to the user who executes the process to obtain the designated object.

The receiving means (51) further receives, in response to the second output data being output by the output means (56), a request for restricting the designated object from being used for processes other than a process for changing the selected object, based on an operation by the user;
The device may further include a restriction means (58) for restricting the designated object from being used for processes other than processes for changing the selected object in response to the request being accepted by the acceptance means (51).
"Restricting use for processes other than the process of changing the selected object" does not necessarily mean that processes other than the process of changing the selected object are prohibited, but may mean that the process of changing the selected object is executable, but the requirements necessary to request the execution of that process are increased, or the operations necessary to request the execution of the process are made more complicated.
This restricts the use of the designated object in processes other than the process of changing the selected object in response to a request from the user, thereby preventing the user from erroneously using the designated object in processes other than the process of changing the selected object before the change condition is satisfied.

The acquisition condition may be an acquisition route for the designated object.
The "acquisition route" may be, for example, an area where the specified object is available, or an area where objects can be traded between users (for example, an in-game shop).
Furthermore, the "acquisition route" may be a combination of time conditions and location conditions (for example, information indicating whether the specified object was issued for a limited time (one example is a limited flag), the period during which an area in which it is available for a limited time is open (one example is the day of the week when a limited-time quest is held), or a combination thereof).
This provides a sense of security to the user who is executing the process to obtain the designated object. In particular, when the "obtaining route" is a combination of a time condition and a location condition, when the user requests the execution of a process to change the selected object, information for more accurately judging whether or not it is impossible or difficult to obtain the designated object is presented, which is particularly beneficial.

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

The second output data may include at least one of a route for acquiring the designated object and a degree of difficulty in acquiring the designated object, if the designated object is an unacquired object that has been possessed by the user but is not possessed by the user at the time when information indicating the designated object is acquired by the acquisition means (55).
This provides a sense of security to the user who is executing a process to obtain an object that he or she does not possess.

The information displayed as the acquisition conditions may be more limited when the designated object is an unknown object that has never been possessed by the user than when the designated object is an object that the user does not possess.
This allows the user to feel at ease when carrying out the process to obtain an unknown object while maintaining the game difficulty at an appropriate level.

Another aspect of the present invention is a method for producing a
An information processing system including a user terminal and a server configured to be able to communicate with the user terminal, the information processing system being able to access a storage device that stores object identification information for identifying an object and a change condition including a plurality of object identification information used in a process for changing the object, in association with each other, the information processing system comprising:
Either the user terminal or the server,
a first display format for displaying 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, which is an object selected based on a user's instruction, in a display format that is identifiable by the user;
An output means (56) for outputting output data;
a receiving means (51) for receiving an instruction to designate one of the plurality of objects based on an instruction from the user in response to the first output data being output by the output means (56),
The output means (56) further outputs second output data for displaying a condition for acquiring a designated object, the designated object being an object designated by the instruction accepted by the accepting means (51), when the user does not possess the designated object.
It is an information processing system.

Another aspect of the present invention is a method for producing a
A computer that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process of changing the object, in association with each other.
a first display format for displaying 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, which is an object selected based on a user's instruction, in a display format that is identifiable by the user;
A means (56) for outputting output data;
a means (51) for receiving an instruction to designate one of the plurality of objects based on an instruction from the user in response to the first output data being output;
a second display for displaying a condition for acquiring a designated object, the designated object being an object designated by the received instruction, when the user does not possess the designated object;
A means (56) for outputting output data;
This is a program that functions as a

Another aspect of the present invention is a method for producing a
An information processing device that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process of changing the object, in association with each other, comprising:
a first output means for outputting 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 which is a selected object;
a first receiving means for receiving a request to restrict a first designated object, which is an object designated by a user, from being used in a predetermined process in response to the first output data being output by the first output means;
a first restriction means for restricting the first specified object from being used in the process in response to the request being accepted by the first acceptance means;
The information processing device includes:

This allows the user to put the reference card into a state where it will not disappear immediately after recognizing that it is difficult to obtain the reference card on the screen presenting the acquisition conditions, thereby reliably preventing the reference card from disappearing unintentionally.

a second output means for outputting second output data for displaying the plurality of objects in a display format that allows the user to distinguish each of the objects;
a second receiving means for receiving a request to restrict a second designated object, which is an object designated by a user among the plurality of objects, from being used in a predetermined process in response to the second output data being output by the second output means;
a second restriction means for restricting the second specified object from being used in the process in response to the request being accepted by the second acceptance means,
At least one of the first output data and the second output data may be data for displaying an object that is subject to restriction by the first restriction means and an object that is subject to restriction by the second restriction means in a display format that is respectively identifiable to a user.

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

"A process that is executed on the condition that the specified object is removed from the possessed objects" means that, when the process is executed, the specified object is removed from the possessed objects (i.e., the specified object becomes an unpossessed object).
, processing.

Furthermore, at least one of the request accepted by the first accepting means or the request accepted by the second accepting means may include a first request for restricting the object to be restricted from being used in a process executed on the condition that it is disappeared from the possessed object, and a second request for restricting the object to be restricted from being used in a process other than a process that changes the selected object, among the processes executed on the condition that it is disappeared from the possessed object.

The "process of changing the selected object" and the "process other than the process of changing the selected object" are both aspects of the "process executed on the condition that the object is to be erased from the possessed objects".
The "first request" is a request for restriction on all processes that are executed on the condition that the first designated object is made to disappear from the possessed objects.
The "second request" is a request to restrict all processes other than processes that change the selected object among the processes that are executed on the condition that the first designated object disappears from the possessed objects (in other words, to permit only processes that change the selected object).

The second output data may be data for displaying an object that is the subject of the first request and an object that is the subject of the second request in a display format that is respectively distinguishable to a user.

The "object that is the subject of the first request" is an object whose use is restricted for all processes that are executed on the condition that it be erased from the possessed object (i.e., an object that is placed in a state in which it cannot be erased from the possessed object).
The "object that is the subject of the second request" is an object whose use for processes other than processes that change the selected object is restricted (i.e., its use is permitted only for processes that change the selected object).

Another aspect of the present invention is a method for producing a
An information processing system including a user terminal and a server configured to be able to communicate with the user terminal, the information processing system being able to access a storage device that stores object identification information for identifying an object and a change condition including a plurality of object identification information used in a process for changing the object, in association with each other, the information processing system comprising:
Either the user terminal or the server,
a first output means for outputting 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 which is a selected object;
a first receiving means for receiving a request to restrict a first designated object, which is an object designated by a user, from being used in a predetermined process in response to the first output data being output by the first output means;
a first restriction means for restricting the first specified object from being used in the process in response to the request being accepted by the first acceptance means;
The information processing system includes:

Another aspect of the present invention is a method for producing a
A computer that can access a storage device that stores object identification information that identifies an object and a change condition including a plurality of object identification information used in a process that changes the object, in association with each other.
a means for outputting 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 which is a selected object;
a means for receiving a request for restricting a first designated object, which is an object designated by a user, from being used in a predetermined process in response to the first output data being output;
a means for restricting the first specified object from being used in the process in response to the request being accepted;
It is a program that functions as a

In the above, in order to facilitate understanding of the present invention, the symbols shown in the drawings are written in parentheses as appropriate, but this does not mean that the information processing device etc. related to the present invention is limited to the form shown in the drawings.

1... Game system 10... User terminal 11... CPU
12...ROM
13...RAM
Reference Signs List 15: Operation input unit 16: Display unit 17: Communication interface unit 18: Storage 19: Bus 20: Game server 21: CPU
22...ROM
23...RAM
24: Communication interface unit 25: Storage 26: Bus 51: Acceptance means 52: Game processing means 54: Card data change means 55: Acquisition means 56: Output means 57: Recording means 58: Restriction means 70: Data table group

Claims (4)

A game program for operating a processor of a game device that plays a game using a base object via a game server, the game including executing a process of changing the base object, the game program comprising:
an output means for displaying a list image for allowing a user to select a base object from among base objects possessed by the user in a manner that enables the user to identify whether or not a process for changing each base object is possible;
an acquisition means for acquiring information on a reference object that is associated with a selected base object selected from the base objects displayed in the list image and is consumed in exchange for execution of a process that changes the selected base object;
a receiving means for receiving, as a designated object, a reference object designated based on an operation of the user on the presentation image output by the output means;
Equipped with
the game includes a plurality of locations at which the reference objects can be obtained, and an available reference object is set in each of the plurality of locations;
the output means performs control to display an operation object for guiding the user to any one of the plurality of locations, and performs control to display only the operation object for guiding the user to a location where the designated object is set to be available in an operable manner,
the control by the output means is executed by the reception means receiving, as a designated object, a reference object designated based on an operation by the user on the presentation image;
the presentation image includes information about the base object after a process that changes the selected base object is executed;
displaying information relating to the reference object in association with the reference object, the information relating to the possession of the reference object;
A program characterized by:
2. The program according to claim 1, wherein the designated object can be obtained by the user fulfilling a predetermined condition.
1. An information processing method for a game device that uses a base object and executes a process of changing the base object via a game server, comprising:
displaying a list image for a user to select a base object from among base objects possessed by the user in such a manner that it is possible to distinguish whether or not a process for changing each base object is possible;
acquiring information on a reference object that is associated with a selected base object selected from the base objects displayed in the list image and that is consumed in exchange for execution of a process that changes the selected base object;
outputting a presentation image including an image of the acquired reference object, and accepting, as a designated object, a reference object designated based on an operation of the user on the output presentation image ;
the game includes a plurality of locations at which the reference objects can be obtained, and an available reference object is set in each of the plurality of locations;
performing control to display, in an operable manner, only an operation object for guiding the user to any one of the plurality of locations, the operation object being for guiding the user to a location where the designated object is set to be available;
the control is executed by accepting, as a designated object, a reference object designated based on an operation of the user on the presentation image;
the presentation image includes information about the base object after a process that changes the selected base object is executed;
displaying information relating to the reference object in association with the reference object, the information relating to the possession of the reference object;
1. An information processing method comprising:
A game system for playing a game using a base object through a game server, the game system including executing a process for changing the base object,
an output means for displaying a list image for allowing a user to select a base object from among base objects possessed by the user in a manner that enables the user to identify whether or not a process for changing each base object is possible;
an acquisition means for acquiring information on a reference object that is associated with a selected base object selected from the base objects displayed in the list image and is consumed in exchange for execution of a process that changes the selected base object;
a receiving means for receiving, as a designated object, a reference object designated based on an operation of the user on the presentation image output by the output means;
Equipped with
the game includes a plurality of locations at which the reference objects can be obtained, and an available reference object is set in each of the plurality of locations;
the output means performs control to display an operation object for guiding the user to any one of the plurality of locations, and performs control to display only the operation object for guiding the user to a location where the designated object is set to be available in an operable manner,
the control by the output means is executed by the reception means receiving, as a designated object, a reference object designated based on an operation by the user on the presentation image;
the presentation image includes information about the base object after a process that changes the selected base object is executed;
displaying information relating to the reference object in association with the reference object, the information relating to the possession of the reference object;
A game system characterized by:

Images