Information processing device, information processing system, and program

The information processing apparatus addresses the issue of users accidentally releasing reference cards by displaying all necessary cards for future evolution synthesis processes, reducing the risk of card loss and the need for re-obtainment.

JP2025089410AActive Publication Date: 2025-06-12KONAMI DIGITAL ENTERTAINMENT CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
JP2025047286
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-03-21
Publication Date
2025-06-12
Estimated Expiration
2034-02-13

AI Technical Summary

Technical Problem

In digital card games, users often release reference cards necessary for future synthesis processes, leading to the unintended loss of these cards, as existing systems only display the reference cards required for the most recent synthesis process.

Method used

An information processing apparatus and system that identifies objects and change processes, allowing users to access a storage device associating change conditions with object identification information. This system displays all necessary reference cards for future evolution synthesis processes, preventing accidental release.

Benefits of technology

The system effectively reduces the likelihood of users losing reference cards by clearly displaying all necessary cards for future evolution synthesis, thereby preventing the need for users to re-obtain released cards.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025089410000001_ABST
    Figure 2025089410000001_ABST
Patent Text Reader

Abstract

To reduce the possibility that an object possessed by a user is used for processing other than a use purpose of the object desired by the user and is dissipated.SOLUTION: An information processing device that can access a storage device for associating and storing object identification information and a change condition including a plurality of pieces of the object identification information includes: first reception means for receiving the designation of a selection object from objects possessed by a user based on user operation; acquisition means for acquiring from the storage device each change condition for executing each change processing of a plurality of stages for the selection object, when the selection object is the object that can change in stages so that the selection object becomes different objects sequentially each time change processing is executed; and output means for outputting output data for causing a plurality of objects specified by the plurality of pieces of the object identification information included in each change condition acquired by the acquisition means to be displayed in a form that can be identified by the user respectively.SELECTED DRAWING: Figure 11
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to information processing technology for processing information about an object.

Background Art

[0002] In recent years, so-called social games have become popular as applications executed in social networking services (SNS). Among such social games, digital card games using cards are known. In addition, a game is known in which a main card and a sub-card are selected by the user from the user's owned cards, and the ability parameters of the main card are changed and the sub-card is deleted from the user's owned cards by performing a synthesis process on the main card and the sub-card (Patent Documents 1 and 2).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the synthesis process, in order to realize the synthesis process of the base object (base object; corresponding to the main card above), a combination condition corresponding to the base object is satisfied and the user has a plurality of objects (reference objects; corresponding to the sub-cards above). ​​​​There are cases where this is a requirement. In such cases, a mechanism is provided to present to the user the reference objects necessary to perform a synthesis process on the object selected as the base object. However, in that case, only the reference objects necessary to perform the most recent synthesis process on the selected card are presented to the user, and the user cannot know the reference objects (i.e., the reference objects necessary for future synthesis processes) necessary to perform further synthesis processes after the execution of that most recent synthesis process. Therefore, for example, in a game where the object changes (evolves) sequentially into a different object each time a synthesis process is performed, there has been a situation where, despite currently possessing the reference objects necessary in the future during the process of evolution, the user releases those reference objects. In such a case, in future synthesis processes, the user has to obtain again the objects that were released in the past and will later regret having released them. There is also a known game equipped with a mechanism for presenting to the user the reference objects necessary to perform a synthesis process on the object selected as the base object. However, in that case, only the reference objects necessary to perform the most recent synthesis process on the selected card are presented to the user, and the user cannot know the reference objects (i.e., the reference objects necessary for future synthesis processes) necessary to perform further synthesis processes after the execution of that most recent synthesis process. Therefore, for example, in a game where the object changes (evolves) sequentially into a different object each time a synthesis process is performed, there has been a situation where, despite currently possessing the reference objects necessary in the future during the process of evolution, the user releases those reference objects. In such a case, in future synthesis processes, the user has to obtain again the objects that were released in the past and will later regret having released them. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user.

[0005] This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user. This invention has been made in view of the above-described viewpoints, and its object is to provide an information processing apparatus, an information processing system, and a program capable of reducing the possibility that the objects possessed by the user disappear due to being used in processes other than the purpose of using the objects desired by the user.

Means for Solving the Problem

[0006] One aspect of the present invention is object identification information for identifying an object, and a condition for performing a change process for changing the object, the condition including a plurality of object identification information. One aspect of the present invention is object identification information for identifying an object, and a condition for performing a change process for changing the object, the condition including a plurality of object identification information. An information processing apparatus that can access a storage device that stores by associating change conditions, and Based on a user operation, it receives a designation of a selected object that is an object held by the user from among the objects held by the user, a first reception unit that receives a designation of a selected object that is an object held by the user from among the objects held by the user, When the selected object is an object that can be changed step by step so as to be a different object each time the change process is performed, acquisition means for acquiring, from the storage device, each change condition for performing a plurality of stages of change processes on the selected object; output means for outputting output data for causing a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means to be displayed in a display format that can be identified by the user; wherein the information processing apparatus is provided with: wherein the information processing apparatus is provided with: output means for outputting output data for causing a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means to be displayed in a display format that can be identified by the user; An information processing apparatus comprising:

[0007] Another aspect of the present invention is an information processing system including a user terminal and a server configured to be communicable with the user terminal, wherein at least one of the user terminal and the server can access a storage device that stores by associating object identification information for identifying an object and change conditions for performing a change process for changing the object and including a plurality of object identification information, wherein at least one of the user terminal and the server can access a storage device that stores by associating object identification information for identifying an object and change conditions for performing a change process for changing the object and including a plurality of object identification information, wherein at least one of the user terminal and the server can access a storage device that stores by associating object identification information for identifying an object and change conditions for performing a change process for changing the object and including a plurality of object identification information, In the information processing system, a first reception unit that receives a designation of a selected object that is an object held by the user from among the objects held by the user based on a user operation, a first reception unit that receives a designation of a selected object that is an object held by the user from among the objects held by the user based on a user operation, When the selected object is an object that can be changed step by step so as to be a different object each time the change process is performed, acquisition means for acquiring, from the storage device, each change condition for performing a plurality of stages of change processes on the selected object; acquisition means for acquiring, from the storage device, each change condition for performing a plurality of stages of change processes on the selected object; Based on the plurality of object identification information included in each change condition acquired by the acquisition means, Output means for outputting output data for causing a plurality of objects specified thereby to be displayed in a display format that can be identified by the user, An information processing system provided by at least one of the user terminal or the server. is.

[0008] Another aspect of the present invention is an object identification information for identifying an object, and a condition for performing a change process for changing the object, the condition including a plurality of object identification information. A storage device that stores the change condition in association with the change condition, and a computer that can access the storage device. Based on a user operation, a first reception means for receiving a designation of a selected object that is an object possessed by the user, When the selected object is an object that can be changed step by step so as to be a different object each time the change process is performed, a plurality of steps for the selected object. An acquisition means for acquiring each change condition for performing each change process, Based on the plurality of object identification information included in each change condition acquired by the acquisition means, Output means for outputting output data for causing a plurality of objects specified thereby to be displayed in a display format that can be identified by the user, A program for functioning as.

Brief Description of Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Mode for Carrying Out the Invention

[0010] (1) First Embodiment (1-1) Configuration of the Game System Hereinafter, as an embodiment of the information processing system, the game system 1 will be described.

[0011] FIG. 1 shows a system configuration example of the game system 1 of the embodiment. As shown in FIG. 1 , this game system 1 includes user terminals 10a, 10b, 10c,... and a game server 20. Each user terminal 10a, 10b, 10c can access the game server 20 through a communication network NW such as the Internet. The game server 20 is an example of an information processing device. Each user terminal 10a, 10b, 10c,... is a terminal operated by an individual user, and is, for example, 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-functional smart TV), a portable game machine with a communication function, or other communication terminals. In the following description, when referring to each of the user terminals 10a, 10b, 10c,... in common, it is denoted as the user terminal 10. The game server 20 is a server that executes games. The game server 20 stores image data interpretable by a web browser (for example, image data described in a format such as HTML or XML. In the embodiments of the present invention, HTML data will be described as an example).

[0012]

[0012] .) A program capable of creating is implemented. Note that the image data is an example of the output data is. The user terminal 10 interprets the HTML data provided by the game server 20 and represents It has a web browser, and requests based on the operations of the user on the web page by the user terminal 10 are sent to the game server 20 via the network, and the game processing is executed by receiving the processing result by the game server 20. The communication network NW is, for example, an information communication network configured by the Internet, WAN (Wide Area Network), LAN (Local Area Network), dedicated line, or a combination thereof.

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

[0014] The CPU 11 reads out the programs and data stored in the ROM 12, and controls the overall operation within the user terminal 10, such as timing processing of control signals and data signals with each unit within the user terminal 10. The CPU 11 also reads out the programs stored in the storage 18 and various data necessary for program execution, expands them in the RAM 13, and ​​​​​Perform various processes such as data input / output processing, arithmetic processing, and determination processing associated with execution. The RAM 13 temporarily stores data for arithmetic processing, determination processing, etc. by the CPU 11.

[0015] For example, the CPU 11 loads the web browser stored in the storage 18 into the RAM 1 3 and executes it. Then, based on the specification of the URL (Uniform Resource Locator) input by the user through the operation input unit 15 etc., the CPU 11 obtains, via the communication interface unit 17, data for displaying a web page from the game server 20, that is, data of objects such as an HT ML (HyperText Markup Language) document and images associated with the document (hereinafter, collectively referred to as "HTML data" as appropriate), via the communication interface unit 17, and executes the web browser to interpret the HTML data. Incidentally, various plugins for extending the browser function of the web browser may be implemented in the user terminal 10. An example of such a plugin is the Flash Player by Adobe Systems in the United States. Alternatively, the HTML data in the present embodiment may be in the HTML5 format having a video and audio playback function. The web browser communicates with the game server 20 in accordance with HTTP (HyperText Transfer Protocol). The web browser, when a URL (Uniform Resource Locator) on the web page or an operation target (for example, a software button hereinafter simply referred to as "button", etc.) is selected by an operation of the operation input unit 15 by the user, updates the web page

[0016] The web browser communicates with the game server 20 in accordance with HTTP (HyperText Transfer Protocol). When a URL (Uniform Resource Locator) on the web page or an operation target (for example, a software button hereinafter simply referred to as "button", etc.) is selected by an operation of the operation input unit 15 by the user, the web browser updates the web page when a URL (Uniform Resource Locator) on the web page or an operation target (for example, a software button hereinafter simply referred to as "button", etc.) is selected. When the web page is updated In order to select the game server 20, the user sends an HTTP request including the selection result to the game server 20. The browser receives HTML data from the game server 20 as an HTTP response, The web page image is interpreted and displayed on the display unit 16. In this embodiment, HTML data is an example of image data.

[0017] The display unit 16 is, for example, a liquid crystal display (LCD) or an organic electroluminescence (EL) display. A display device that displays images in a matrix of thin, pixel-by-pixel arrangement. When a liquid crystal display (LCD) monitor including a thin-film transistor is used, the display part 1 6 displays an image of a web page on a display screen by driving the thin film transistor.

[0018] When the user terminal 10 is a button-input type user terminal, the operation input unit 15 may, for example, Multiple inputs such as directional buttons, a confirmation button, and a numeric keypad to accept user input An interface equipped with buttons to recognize the input of each button press (operation) and output it to the CPU 11. Includes a signal circuit. 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 pen. wear.

[0019] The storage 18 is, for example, a flash memory or a hard disk drive (HDD). The storage device is configured as follows.

[0020] (1-3) Game server configuration 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 a bus 26 is provided for transmitting control signals or data signals between the respective units. Note that the game server 20 can have the same configuration as a general-purpose network server with respect to hardware.

[0021] The CPU 21 reads out programs and data stored in the ROM 22, and performs timing processing of control signals and data signals with each unit in the game server 20, etc., and controls the overall operation within the game server 20. The CPU 21 also reads out programs stored in the storage 25 and various data necessary for program execution, expands them in the RAM 23, and performs various processes such as input / output processing, arithmetic processing, and determination processing of data accompanying program execution. The RAM

[0022] For example, the storage 25 stores a program that provides a web service by performing HTTP-compliant communication with the web browser of the user terminal 10 which is a client. The CPU 21 expands the program stored in the storage 25 in the RAM 23 and executes the program. Along with program execution, the CPU 21 obtains an HTTP request from the user terminal 10 via the communication interface unit 24, executes processing corresponding to the HTTP request, and returns HTML data including the execution result as an HTTP response to the user terminal 10.

[0023] The storage 25 is, for example, a flash memory or an HDD (Hard Disk Drive). It is a storage device configured as described above, and in addition to the program described above, it stores a data table group 70 (described later ). The data table group 70 includes a card data table, an evolution synthesis data table, and an owned card data table. Each data table in the storage 25 is accessed as appropriate by the CPU 21 for reading and writing data.

[0024] (1-4) Card presentation required for card evolution synthesis The game executed in the game system 1 of this embodiment is a game in which the user uses a card as an object. The type of the game of this embodiment is not particularly limited. For example, the user explores an area in the game to obtain cards and items, or uses the cards held by the user to play against other users or NPCs (Non-Player Characters). In the following description, "owning" a card means that the user has the card in a state where it can be used for processing using the card. "Not owning" a card means that the user has the card in a state where it cannot be used for processing using the card. "Obtaining" a card means that the card has changed from a state of not being owned to a state of being owned. In the game of this embodiment, the card evolution synthesis process (hereinafter, simply referred to as "evolution synthesis" or "evolution" as appropriate) is a process of evolving the cards held by the user when a predetermined condition is satisfied. The evolution synthesis of the card is a process of changing the card ID as described later in the example of this embodiment, but it may be a process of changing at least a part of the card data (described later) corresponding to the card. In that case, the object of change of the card data is not particularly limited. For example, it is a card parameter such as the card name, card image, rarity, etc. The Evolution synthesis is an example of object change processing. To perform evolution synthesis, the user selects, from the cards the user possesses (hereinafter, appropriately referred to as "possessed cards" as appropriate), the card to be evolved as the base card. The card selected as the base card is an example of a selected object. In evolution synthesis, for each card ID of the base card, a combination condition (an example of a change condition) of the card IDs of a plurality of cards (referred to as "reference cards") required to evolve the base card is determined. When evolution synthesis is executed, the reference cards used in that evolution synthesis disappear from the user's possessed cards. In this embodiment, the possessed cards and the reference cards are each an example of a possessed object and a reference object, respectively. In the game of this embodiment, it is a condition for evolving the selected card that the user possesses a plurality of reference cards included in the combination condition corresponding to the card selected as the base card by the user.

[0025] Regarding the card presentation required for the evolution synthesis of the card, it will be specifically described with reference to FIG. 4. FIG. 4 is a diagram for conceptually explaining the card presentation required for the evolution synthesis of the card. In FIG. 4, assume a case where the user possesses cards A, D, G, Q1, M2, … and wants to evolve card Q1. In this example, assume that card Q1 is an object that can change to a different card (Q1 → Q2 → Q3) each time evolution synthesis is performed. In this example, the reference cards required to evolve card Q1 to card Q2 are cards A, - Card B and Card C, and the reference cards necessary to evolve Card Q2 into Card Q3 are Card E, Card F, Card G, and Card H.

[0026] In this embodiment, not only the reference cards (Card A, Card B, and Card C) necessary for Card Q1 selected as the base card, but also the cards (Card A, B, C, E, F, G, H) necessary when Card Q1 evolves into different cards sequentially and step by step are presented to the user. Therefore, the user can recognize in advance that the presented multiple cards (Card A, B, C, E, F, G, H) are the cards necessary for the future evolution synthesis of Card Q1, which is the card selected as the base card. Thus, the user is prevented from accidentally releasing the presented multiple cards. For example, in FIG. 4, if only the cards (Card A, Card B, and Card C) necessary for one evolution synthesis of Card Q1 selected as the base card are presented to the user, even though the user's owned Card G is a card necessary for the future evolution of Card Q1 (in this example, the evolution of Card Q2 → Q3), there is a risk that the user will release (for example, dispose of) Card G. In contrast, in this embodiment, when Card Q1 selected as the base card evolves into different cards sequentially and step by step, the cards (Card A, B, C, E, F, G, H) necessary for the evolution are presented to the user. Therefore, for example, a situation where the user accidentally releases Card G is avoided.

[0027] (1 - 5) Configuration of the data table Next, regarding the card data table, evolution synthesis data table, and owned card data table stored in the storage 25 of the game server 20, refer to FIGS. 5 to 8 and describe them in sequence. ​ This will be described in . The storage 25 of the game server 20 is an example of a storage device.

[0028] (i) Card Data Table The card data table records the data of the cards used in the game of this embodiment. A configuration example of the card data table is shown in FIG. 5. In the example shown in FIG. 5, for each card ID, the card name, card image, and card parameter data are included. The card ID is an example of object identification information. The card name is a character string indicating the name of the character displayed on the card. The card image is the image of the character displayed on the card. The card parameters are composed of data such as rarity, attribute, cost, skill, selling price, attack power, defense power, and limited flag. The rarity is an index indicating the rarity value of the card. In the example shown in FIG. 5, the rarity is set in descending order from R1 to R5. The attribute is the attribute of the character displayed on the card. In the example shown in FIG. 5, it is any one of N1 to N3. The cost is a value referred to when incorporating a card into the user's card team. For example, when conducting a battle with a card team, the total cost of the cards included in the card team is limited to a predetermined value or less. The skill is information indicating an effect that is advantageous when executing the game using the card. In the example shown in FIG. 4, skills with various effects from SK1 to SK12 are set for each card. Note that not all cards need to have skills. The selling price is the in-game points that the user obtains when selling a card that the user owns. The rarity is an index indicating the rarity value of the card. In the example shown in FIG. 5, the rarity is set in descending order from R1 to R5. The attribute is the attribute of the character displayed on the card. In the example shown in FIG. 5, it is any one of N1 to N3. The cost is a value referred to when incorporating a card into the user's card team. For example, when conducting a battle with a card team, the total cost of the cards included in the card team is limited to a predetermined value or less. The skill is information indicating an effect that is advantageous when executing the game using the card. In the example shown in FIG. 4, skills with various effects from SK1 to SK12 are set for each card. Note that not all cards need to have skills. The selling price is the in-game points that the user obtains when selling a card that the user owns. The cost is a value referred to when incorporating a card into the user's card team. For example, when conducting a battle with a card team, the total cost of the cards included in the card team is limited to a predetermined value or less. The skill is information indicating an effect that is advantageous when executing the game using the card. In the example shown in FIG. 4, skills with various effects from SK1 to SK12 are set for each card. Note that not all cards need to have skills. The selling price is the in-game points that the user obtains when selling a card that the user owns. The cost is a value referred to when incorporating a card into the user's card team. For example, when conducting a battle with a card team, the total cost of the cards included in the card team is limited to a predetermined value or less. The skill is information indicating an effect that is advantageous when executing the game using the card. In the example shown in FIG. 4, skills with various effects from SK1 to SK12 are set for each card. Note that not all cards need to have skills. The selling price is the in-game points that the user obtains when selling a card that the user owns. The selling price is the in-game points that the user obtains when selling a card that the user owns. The attack power and defense power are parameters that are referred to when using cards in battles. The limited flag is a flag indicating whether the card is issued for a limited period. As shown in FIG. 4 In the example shown, a card with a limited flag of "1" means that the card is issued for a limited period, and a card with a limited flag of "0" means that the card is not issued for a limited period.

[0029] (ii) Evolution synthesis data table The evolution synthesis data table records the conditions for evolving and synthesizing the cards in the game of this embodiment. FIG. 6 shows a configuration example of the evolution synthesis data table. In the example shown in FIG. 6, for each evolution ID for identifying the content of the evolution synthesis, the pre-evolution card ID (that is, the card ID of the card that becomes the base card before evolution), the post-evolution card ID (the card ID of the card after the evolution of the base card), and the combination conditions of the card IDs of the reference cards required to perform the evolution synthesis (five reference cards in columns C1 to C5) are recorded. For example, under the conditions indicated by evolution ID: 0002 if the user selects the card with card ID: 0072 as the base card from among the cards in their possession, and there is a combination of three cards with card IDs: 0025, 0060, and 0070 among the cards in the user's possession, then by performing the evolution synthesis, the card with card ID: 0072 can be evolved into the card with card ID: 9072. That is, the combination conditions of the reference card IDs in the evolution synthesis data table are an example of the change conditions for changing the card corresponding to the pre-evolution card ID. Note that in columns C1 to C5 indicating the combination conditions of the card IDs of the reference cards, the same card ID may be recorded in at least any two columns. For example, for the base card it is also possible that the same card ID is recorded in at least any two columns.​ When performing evolutionary synthesis, it may contain two or more identical reference cards in the combination conditions of the reference cards used. Even if it is rare. When the combination condition of the reference cards for evolving the base card is that a predetermined number of reference cards with the same card ID are included, instead of the data format shown in FIG. 6, it may be a data format consisting of the card ID of the reference card and the number of copies thereof. It may be.

[0030] (iii) Owned Card Data Table The owned card data table records information on the user's owned cards. FIG. 7 shows a configuration example of the owned card data table. FIG. 7 illustrates the owned card data table for one user, but the owned card data table is provided for each user registered in the game. Although the owned card data table for one user is exemplified, the owned card data table is provided for each user registered in the game. In the owned card data table shown in FIG. 7, for each card ID, data such as the serial number, card level, and skill level are recorded in association. The serial number is a unique number determined when the card is given to the user. Different serial numbers are assigned to cards with the same card ID. When the card evolves, the serial number may or may not be changed before and after the evolution of the card. The card level is a parameter indicating the cultivation level of the card and increases, for example, by performing normal synthesis. The value of the card level (initial value) at the time when the user acquires the card is 1, and the user can grow the card (that is, increase the card level) by performing normal synthesis. The skill level is a parameter indicating the cultivation level of the card, especially the skill that the card has. The skill level is a parameter indicating the cultivation level of the card, and in particular, the skill that the card has. ​​​​​​​​It is a parameter indicating the level of the loop. When the user obtains a card with skills, the value of the skill level (initial value) is 1. For example, by performing normal synthesis with a card that satisfies a predetermined condition as a reference card the skill level of the card can be increased. As the skill level of the card increases, the effect generated by the skill increases.

[0031] In the following description, the card name, card image, serial number, and card parameters associated with the card ID are collectively referred to as "card data" as appropriate. The card parameters that make up the card data include each card parameter recorded in the card data table and the card level and skill level recorded in the owned card data table. That is, any one of the card name, card image, serial number, and each card parameter corresponds to the card data. The card ID, card name, and card image are each an example of object identification information.

[0032] (1-6) Specific example of processing related to evolutionary synthesis of cards Hereinafter, a specific example of the processing related to the evolutionary synthesis of the cards in the game of this embodiment will be described with reference to FIGS. 8 to 10. FIGS. 8 to 10 are diagrams each showing an example of a screen displayed on the user terminal 10 when the processing of the game of this embodiment is being executed.

[0033] FIG. 8 shows a series of display screen changes when executing the processing related to the evolutionary synthesis of the user's owned cards. In FIG. 8, the image P1 is an image including the main menu of the game of this embodiment. In the image P1, as an operation target for the user, a button b1 ("owned mon Button b1 ("View Stars"), button b2 ("Team Formation"), button b3 ("Normal Synthesis"), button b4 ("Evolution Synthesis"), and button b5 ("Sell") are provided. Button b1 is the button designated when making a request for browsing the user's owned cards. Button b2 is the button designated when the user selects a card to use in a battle against other users or NPCs from among the user's owned cards. Button b3 is the button designated when the user makes a request to execute the normal synthesis of a card selected as the base card from among the user's owned cards. Button b4 is the button designated when the user makes a request for the evolution synthesis process of a card selected as the base card from among the user's owned cards. Button b5 is the button designated when the user makes a request for the sell process for a card selected from among the user's owned cards. When button b4 ("Evolution Synthesis") is designated in image P1, the image changes as shown in P2. In image P2, a list of multiple owned cards is displayed in order for the user to select any one of the user's owned cards as the base card. It is preferable that the card images of cards that cannot evolve are displayed in a display format that allows the user to recognize that they cannot be selected as the base card. In image P2, for example, when card Q01 is selected, the image changes as shown in P3. Image P3 shows text indicating that card Q01 has been selected as the base card, along with button b11 ("Confirm") for confirming the reference cards required at each stage of the evolution of the selected card Q01, and a button to return to image P2 to change the owned card used as the base card.

[0034] When button b4 ("Evolution Synthesis") is designated in image P1, the image changes as shown in P2. In image P2, a list of multiple owned cards is displayed so that the user can select any one of the user's owned cards as the base card. For cards that cannot evolve, it is preferable that the card images are displayed in a display format that allows the user to recognize that they cannot be selected as the base card. In image P2, if, for example, card Q01 is selected, the image changes as shown in P3. Image P3 shows text indicating that card Q01 has been selected as the base card, along with button b11 ("Confirm") for confirming the reference cards required at each stage of the evolution of the selected card Q01, and a button to return to image P2 to change the owned card used as the base card. and a button b12 ("Reselect Card") for reselecting the card. When "Confirm" is selected, the image changes as shown in P4 (Figure 9).

[0035] In FIG. 9, image P4 shows card Q0 selected as the base card by the user. 1's first stage evolution (card Q01 → R01) and the reference cards required for that evolution (card Card A01, B03, C12) and the second stage evolution (card R01 → S01) and the corresponding evolution The reference cards required for the evolution (cards A01, K14, M03, R05) and the final stage evolution ( Card S01 → T01) and the reference cards required for that evolution (cards M03, C12) In other words, multiple levels are displayed for the card Q01 selected as the base card. The user is provided with multiple reference cards included in each combination condition for each evolution synthesis. The final stage of evolution is also called the "final evolution." In FIG. 9 and subsequent figures, the display of the card image of the reference card is omitted as appropriate.

[0036] Card Q01's first stage evolution synthesis combination conditions include cards A01, B03, and C 12 (i.e., the reference cards for evolving card Q01) If all the cards are in the same place (if all the cards are in the same place), image P4 of FIG. 10 is displayed instead of image P4 of FIG. a is displayed. In image P4a, all the cards are ready to perform the first stage of evolution synthesis. A text notifying the user ("Everything is here") and running the first stage of evolutionary synthesis. In image P4a, the button b21 ("evolve") is included. When b21 is specified, the image changes as shown in P5. That is, from card Q01 to Evolution synthesis of card R01 is executed, and as shown in P5, at least part of the card image, card name, and parameters of the evolved card are displayed. When the first-stage evolution synthesis is executed, cards A01, B03, and C12, which are reference cards for evolution synthesis, disappear from the user's owned cards.

[0037] (1-7) Outline of functions provided by the information processing apparatus Next, the functions provided by the game server 20 to implement the game of the present embodiment will be described. FIG. 11 is a functional block diagram for explaining the functions that play a major role in the game server 20 of the present embodiment. In FIG. 11, the data table group 70 includes a card data table, an evolution synthesis data table, and an owned card data table as described above. Note that not all of the means included in the functional block diagram shown in FIG. 11 are essential elements of the present invention. For example, in one aspect of the present invention, it is sufficient to include a reception means 51, an acquisition means 53, and an output means 54. Also,

[0038] The reception means 51 has a function of receiving various requests from the user based on information regarding the user's operation input. In the game of the present embodiment, examples of requests from the user include a request for card evolution synthesis processing, a request for execution of evolution synthesis, a request for execution of normal synthesis, and a request for selling processing. Also, the reception means 51, as a first reception means, has a function of receiving specification of a card selected as a base card from among the owned cards of the user To implement the function of the reception means 51, the game server 20 uses the communication interface unit 2 4 to receive requests corresponding to button operations by the user within the web page, which is an image, from the user terminal 10, or information on the card selected as the base card (e.g., serial number). The CPU 21 of the game server 20 discriminates the content of the request based on the information contained in the received request and performs the reception process of the request. In the reception process, the request is recorded in the RAM 13. The CPU 21 sequentially executes the processes corresponding to the received requests. Also, the CPU 21 records the serial number of the received card in the RAM 23.

[0039] The game execution means 52 has a function of executing processes of various games other than evolution synthesis based on the requests from the user terminal 10 received by the reception means 51. The game processes in this embodiment may be provided as appropriate. For example, they include user - to - user battle processes, user - to - NPC battle processes, quest processes by the user, and normal synthesis processes of the user's possessed cards. Although the battle process will not be described in detail, for example, the user forms a team consisting of a plurality of possessed cards in advance so that the total cost is equal to or less than a predetermined upper limit value, and the team battles against other users or NPCs. The battle result is determined by parameters such as the attack power, defense power, and skills of each card constituting the team. The quest process is a process for obtaining cards and items by the user exploring areas within the game.

[0040] The function of the game execution means 52 when executing the normal synthesis process of the user's possessed cards is realized as follows. The CPU 21 of the game server 20 uses the base card and the reference When receiving a request to execute normal synthesis that includes the user's selection result for the photo card, the card data of the base card and the reference card is read from the card data table and expanded to RAM23. Next, the CPU21 of the game server 20 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, writes the changed parameters of the base card into the card data table, and deletes the card data of the held card that has become the reference card from the card data table. Note that the card level and skill level of the base card do not always increase every time normal synthesis is executed. For example, the value of the growth parameter associated with the card may be increased every time normal synthesis is executed, and when the value of the growth parameter reaches a predetermined value, the card level may be increased by one and the value of the growth parameter may be reset to zero. - Read the card data of the base card and the reference card from the card data table and expand it to RAM23. Next, the CPU21 of the game server 20 - Based on the parameters of the base card and the reference card, change the parameters of the base card (e.g., card level and skill level), write the changed parameters of the base card into the card data table, and - Delete the card data of the held card that has become the reference card from the card data table. Note that the card level and skill level of the base card do not always increase every time normal synthesis is executed. For example, the value of the growth parameter associated with the card may be increased every time normal synthesis is executed, and when the value of the growth parameter reaches a predetermined value, the card level may be increased by one and the value of the growth parameter may be reset to zero. - Write the changed parameters of the base card into the card data table and delete the card data of the held card that has become the reference card from the card data table. Note that the card level and skill level of the base card do not always increase every time normal synthesis is executed. For example, the value of the growth parameter associated with the card may be increased every time normal synthesis is executed, and when the value of the growth parameter reaches a predetermined value, the card level may be increased by one and the value of the growth parameter may be reset to zero. For example, the value of the growth parameter associated with the card may be increased every time normal synthesis is executed, and when the value of the growth parameter reaches a predetermined value, the card level may be increased by one and the value of the growth parameter may be reset to zero. - Increase the value of the growth parameter associated with the card every time normal synthesis is executed, and when the value of the growth parameter reaches a predetermined value, increase the card level by one and reset the value of the growth parameter to zero. It may be like this.

[0041] The function of the game execution means 52 when executing the selling process of the user's held card is realized as follows. Although not shown in FIG. 5, in the card data table, a selling price (points) is associated with each card ID. Then, when the CPU21 of the game server 20 receives a request for the selling process and obtains the selection result of the card to be sold, it deletes the card data of the card to be sold from the held card data table. Further, the CPU21 of the game server 20 reads the value of the selling price (points) of the card to be sold from the card data table and performs a process of awarding the read points to the user. The process of awarding points to the user is, for example, recorded in a user database (not shown). Although not shown in FIG. 5, in the card data table, a selling price (points) is associated with each card ID. Then, when the CPU21 of the game server 20 - Receives a request for the selling process and obtains the selection result of the card to be sold, it deletes the card data of the card to be sold from the held card data table. - Further, the CPU21 of the game server 20 - Reads the value of the selling price (points) of the card to be sold from the card data table and - Performs a process of awarding the read points to the user. The process of awarding points to the user is, for example, recorded in a user database (not shown). This is a process for updating the value of the user's points held.

[0042] The acquisition means 53 is such that when the card selected as the base card (an example of a selection object) is a card that can evolve step by step so as to be a different card each time an evolution synthesis is performed it has a function of acquiring, from the evolution synthesis data table, each combination condition for performing each of the multiple stages of evolution synthesis on the selected card. The function of the acquisition means 53 can be realized by the CPU 21 of the game server 20 executing the following procedures. (Procedure 1) Identify, with reference to the owned card data table, the card ID corresponding to the serial number of the card selected as the base card. (Procedure 2) In the evolution synthesis data table, identify the evolution ID in which the same "pre-evolution card ID" as the card ID identified in Procedure 1 is recorded. Then, read out the "post-evolution card ID" corresponding to the identified evolution ID and the reference card ID included in the combination condition. (Procedure 3) Identify the evolution ID in which the same "pre-evolution card ID" as the "post-evolution card ID" read out is recorded. Then, read out the "post-evolution card ID" corresponding to the identified evolution ID and the reference card ID included in the combination condition. After that, repeat Procedure 3 until the evolution ID can no longer be identified.

[0043] The output means 54 has a function of outputting, as image data (an example of output data), for displaying to the user in a distinguishable display format, the multiple cards specified by the card IDs of the multiple reference cards included in each combination condition acquired by the acquisition means 53. To realize the function of the output means 54, the CPU 21 of the game server 20 uses the base card When the user's selected card as the base card evolves sequentially every time an evolution synthesis is performed, for each evolution in the evolution synthesis, the pre-evolution card ID, the post-evolution card ID, and the reference card ID included in the combination conditions corresponding to the evolution ID are obtained. When the card data (e.g., card name, card image, etc.) corresponding to these card IDs is read from the card data table, then the CPU 21 of the game server 20 generates image data for presenting to the user based on the read card data and transmits it to the user terminal 10. An example of the image displayed on the user terminal 10 based on this image data is the image P4 in FIG. 9.

[0044] The determination means 55 has a function of determining whether or not a condition that a plurality of reference cards, which are combination conditions corresponding to the card selected as the base card, are included in the user's possessed cards is satisfied. To realize the function of the determination means 55, for example, the CPU 21 of the game server 20 refers to the possessed card data table to determine whether or not the user possesses the cards specified by the plurality of reference card IDs included in the combination conditions corresponding to the card ID of the card selected as the base card.

[0045] The change means 56 has a function of executing an evolution synthesis that changes the card data of the base card when it is determined by the determination means 55 that the condition is satisfied. The evolution synthesis is an example of the change process of the card as an object. In the example of this embodiment, to realize the function of the change means 56, when the CPU 21 of the game server 20 receives a request to execute an evolution synthesis, in the possessed card data table, the evolution ​​​​​​​​​Delete the card data of the pre-evolution card (i.e., the base card for evolution synthesis), and newly write the card data of the post-evolution card . As a result, the base card of the user's owned card will evolve. As shown in the evolution synthesis data table, since the card IDs are different before and after evolution, at least one of the card name, card image, and card parameters will be changed by evolution synthesis .

[0046] (1-8) Processing flow of evolution synthesis in the game of this embodiment Next, an example of the processing flow of evolution synthesis in the game of this embodiment will be described with reference to the sequence charts of FIGS. 12A, 12B, and 13. FIGS. 12A and 1 2B are sequence charts showing an example of the confirmation process of evolution synthesis. FIG. 13 is a sequence chart showing an example of the execution process of evolution synthesis. In each figure, the symbols of each image are attached to the timing of the process in which each image shown in FIGS. 8 to 10 is displayed .

[0047] (A) Confirmation process of evolution synthesis (FIGS. 12A, 12B) When button b4 ("Evolution Synthesis" ) is specified in the main menu of the game of this embodiment (see FIG. 8), the CPU 11 of the user terminal 10 receives a request for evolution synthesis processing (S 10) and sends the request to the game server 20 (S12). When the CPU 21 of the game server 20 receives a request for evolution synthesis processing from the user terminal 10, it identifies the card ID of the user's owned card requested from the owned card data table, reads the card data of the owned card from the card data table and the owned card data table, generates image data including a list of the owned cards (S14), and sends the image data to the user terminal 10 . .​​​ and the CPU 11 of the user terminal 10 acquires the image data received in S16 and displays an image (for example, the image P2 in FIG. 8) on the display unit 16 based on the image data (S18). In S14, the CPU 21 of the game server 20 determines whether the card ID of each user's held card is recorded in the evolution synthesis data table as the pre-evolution card ID to determine whether each user's held card is an evolvable card, and for a held card that cannot evolve, it is preferable to generate image data in a display format recognizable by the user indicating that it cannot be selected as a base card and generates image data in a display format recognizable by the user and cannot be selected as a base card It is preferable to generate image data in a display format recognizable by the user

[0048] The image displayed in S18 includes the images and names of the user's held cards arranged as exemplified by the image P2 in FIG. 8, and the serial number of each card can be selected by selecting the image of each card It is configured such that the serial number of each card can be selected by selecting the image of each card. When an operation of selecting any one of the plurality of held cards displayed in S18 as a base card is performed, the CPU 11 of the user terminal 10 accepts the selection result (serial number) of the base card (S20) and transmits the selection result to the game server 20 (S22). The CPU 21 of the game server 20 generates confirmation image data for finalizing the selection result of the base card based on the received selection result of the base card (S24) and transmits the image data to the user terminal 10 (S26). When the CPU 11 of the user terminal 10 acquires the image data received in S26 it displays an image (for example, the image P3 in FIG. 8) on the display unit 16 based on the image data (S28) The CPU 21 finalizes the selection result of the base card and transmits the image data to the user terminal 10 The CPU 11 of the user terminal 10 acquires the image data received in S26 and displays an image (for example, the image P3 in FIG. 8) on the display unit 16 based on the image data (S28). The image displayed in S28 is the selection result of the base card, as exemplified by the image P3 in FIG. 8​ Buttons (b11, b12) are provided for confirming the fruits. The CPU U11 of the user terminal 10 accepts a response regarding whether to confirm the selection result of the base card transmitted in S22 based on the operation of this button by the user, and transmits the response to the game server 20. Here, it is assumed that the CPU 11 accepts a response (base card confirmation response) for confirming the selection result of the base card transmitted in S22 and transmits the confirmation response to the game server 20 (S30). When the CPU 21 of the game server 20 acquires the base card confirmation response, it refers to the owned card data table based on the serial number of the card selected as the base card, and specifies the card ID of the selected card (S32). Then, in the evolution synthesis data table, the CPU 21 determines whether an evolution ID in which the same "pre-evolution card ID" as the card ID specified in S32 is recorded is specified (S 34). When the evolution ID is specified (S34: YES), the CPU 21 reads out the post-evolution card ID corresponding to the specified evolution ID and the reference card ID included in the combination condition (S36). In addition, when the image displayed in S18 is displayed in a display format such that the owned card that cannot evolve cannot be selected as the base card, the card selected as the base card in S20 is an evolvable card, so the evolution ID will surely be specified in S34. Next, the CPU 21 determines whether an evolution ID in which the same pre-evolution card ID as the post-evolution card ID read out in S36 is recorded is specified (S38). When the evolution ID is specified (S38).

[0049] Then, the CPU 21 determines whether an evolution ID in which the same "pre-evolution card ID" as the card ID specified in S32 is recorded is specified in the evolution synthesis data table (S 34). If the evolution ID is specified (S34: YES), the CPU 21 reads out the post-evolution card ID corresponding to the specified evolution ID and the reference card ID included in the combination condition (S36). When the evolution ID is specified (S34: YES), the CPU 21 reads out the post-evolution card ID corresponding to the specified evolution ID and the reference card ID included in the combination condition (S36). When the evolution ID is specified (S34: YES), the CPU 21 reads out the post-evolution card ID corresponding to the specified evolution ID and the reference card ID included in the combination condition (S36). In addition, when the image displayed in S18 is displayed in a display format such that the owned card that cannot evolve cannot be selected as the base card, the card selected as the base card in S20 is an evolvable card, so the evolution ID will surely be specified in S34. When the image displayed in S18 is displayed in a display format such that the owned card that cannot evolve cannot be selected as the base card, the card selected as the base card in S20 is an evolvable card, so the evolution ID will surely be specified in S34. Since the card selected as the base card in S20 is an evolvable card, the evolution ID will surely be specified in S34. Since the card selected as the base card in S20 is an evolvable card, the evolution ID will surely be specified in S34. Next, the CPU 21 determines whether an evolution ID in which the same pre-evolution card ID as the post-evolution card ID read out in S36 is recorded is specified (S38). When the evolution ID is specified When the evolution ID is specified (S38), If so (S38: YES), the process returns to S36, and reads out the post - evolution card ID corresponding to the evolution ID specified in S38 and the reference card ID included in the combination condition. The CPU 21 repeats the processes of S36 and S38 until the evolution ID is no longer specified. By doing so, for the owned card selected as the base card, each combination condition (that is, each reference card ID required for each evolution) for performing evolution synthesis at multiple stages is read out. Note that although the processing flow in the present embodiment is described by a method using the "pre - evolution card ID" and the "post - evolution card ID" in the evolution synthesis data table, it is not limited to this method. For example, in the evolution synthesis data table, for each card ID, all stages of evolution and the reference card IDs required for the evolution are defined, and each combination condition for performing evolution synthesis at multiple stages for the owned card selected as the base card is read out. Or other methods may be used. That is, any method may be used as long as it is a method for reading out each combination condition for performing evolution synthesis at multiple stages for the owned card selected as the base card. When the evolution ID is no longer specified (S38: NO), the CPU 21 proceeds to S40. In S40, it is confirmed with reference to the owned card data table whether the user owns all the cards specified by the reference card ID included in the combination condition corresponding to the evolution ID specified in S34. That is, it is confirmed whether the user owns all the reference cards necessary to evolve the card selected as the base card by the user.

[0050]

[0051] Next, based on the post-evolution card ID and the reference card ID in each evolution read in S36 and the confirmation result in S40, the CPU 21 generates image data for presenting to the user (S42) and transmits the image data to the user terminal 10 (S44). When the CPU 11 of the user terminal 10 acquires the image data received in S44, it displays an image on the display unit 16 based on the image data (S46). If it is confirmed that the user has all the reference cards necessary to evolve the card selected as the base card in S40, for example, as illustrated in the image P4a of FIG. 10, an image including a button for evolving the card selected as the base card is displayed. If not confirmed, as illustrated in the image P4 of FIG. 9, an image not including a button for evolving the card selected as the base card is displayed. In addition to the user having all the reference cards, an image including a button for evolving the card may be displayed when it is confirmed that other conditions are satisfied (for example, the base card has reached the maximum level). That is, it may be a condition for evolving the selected card that the card selected as the base card has reached the maximum level and the user has all the reference cards. In any case, the generated image data is image data for displaying a plurality of cards specified by the card IDs of the plurality of reference cards included in the combination conditions of each evolution in a display format that allows the user to identify each of them. Note that if the evolution ID is not specified in S34 (S34: NO), it means that the card selected as the base card by the user is a non-evolvable card. Therefore, S ​​​​​​​​​​​​​​​​​ The image data generated at 42 is data for displaying an image (not shown) including a text such as "The selected card cannot evolve".

[0052] (B) Execution process of evolution synthesis (Fig. 13) The sequence chart shown in Fig. 13 shows the flow of processing when an image including a button for evolving the card selected as the base card, as exemplified in the image P4a of Fig. 10, is displayed at S46 in Fig. 12B. For example, in the image P4a of Fig. 10, there is a button b21 ("Evolve") for confirming whether to request the execution of evolution synthesis. In Fig. 13, based on the operation of the user who designates this button, when the CPU 11 of the user terminal 10 receives a request for executing evolution synthesis (S50), the request is transmitted to the game server 20 (S52). When the CPU 21 of the game server 20 receives a request for executing evolution synthesis received from the user terminal 10, in the possessed card data table, it deletes the card data of the pre-evolution card (that is, the base card for evolution synthesis) (S54), and newly writes the card data of the post-evolution card (S56). At this time, the card data includes, for example, a serial number issued corresponding to the post-evolution card ID. Next, the CPU 21 of the game server 20 deletes the card data of the reference card used for evolution synthesis from the possessed card data table (S58).

[0053] After executing the evolution synthesis, the CPU 21 generates image data including the card data of the post-evolution card (S60), and transmits the image data to the user terminal 10 (S62). The user terminal When the CPU 11 of the last 10 acquires the image data transmitted in S62, it displays an image (for example, the image P5 in FIG. 10) on the display unit 16 based on the image data (S64).

[0054] As described above, in the game system of the present embodiment, each time the owned card (an example of a selection object) selected by the user as the base card undergoes evolution synthesis, it becomes a different card in sequence. When it is a card that can be evolved step by step so that it becomes a different card each time evolution synthesis is performed, for that user, not only the combination condition (an example of a change condition) required for one-step evolution of the selected owned card but also a plurality of cards specified by a plurality of reference card IDs included in the combination conditions for multi-step evolution synthesis in the future are presented. Therefore, the user can recognize in advance that the plurality of presented cards are reference cards required for the future evolution of the selected owned card, so that it is possible to prevent accidentally releasing any of the plurality of presented owned cards.

[0055] In the above-described embodiment, the case where the output means 54 outputs image data by distinguishing and displaying a plurality of cards specified by a plurality of reference card IDs included in each combination condition acquired by the acquisition means 53 for each corresponding combination condition has been described. When outputting such image data, there are the following advantages. That is, as shown in the image P4 in FIG. 9, a plurality of reference cards included in the combination conditions for first-stage evolution synthesis, second-stage evolution synthesis, and the like are displayed for each combination condition. Therefore, the user can distinguish between the cards required for evolution synthesis in the relatively near future and the cards required in the relatively distant future. ​​​​​​​​​It can be recognized. Therefore, for example, for other purposes, the user can also choose to use the card that will be required in the relatively distant future for processing other than evolutionary synthesis. For example, for other purposes, the user can also choose to use the card that will be required in the relatively distant future for processing other than evolutionary synthesis.

[0056] (2) Second Embodiment In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the game image is displayed by interpreting the HTML document obtained by the user terminal 10 from the game server 20. The case where the present invention is realized in a so-called browser format has been described, but it is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the transmission and reception process between the user terminal 10 and the game server 20 is suppressed. It may be realized in a so-called native application format. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser. In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the game image is displayed by interpreting the HTML document obtained by the user terminal 10 from the game server 20. The case where the present invention is realized in a so-called browser format has been described, but it is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the transmission and reception process between the user terminal 10 and the game server 20 is suppressed. It may be realized in a so-called native application format. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser. In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the game image is displayed by interpreting the HTML document obtained by the user terminal 10 from the game server 20. The case where the present invention is realized in a so-called browser format has been described, but it is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the transmission and reception process between the user terminal 10 and the game server 20 is suppressed. It may be realized in a so-called native application format. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser. In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the game image is displayed by interpreting the HTML document obtained by the user terminal 10 from the game server 20. The case where the present invention is realized in a so-called browser format has been described, but it is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the transmission and reception process between the user terminal 10 and the game server 20 is suppressed. It may be realized in a so-called native application format. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser. In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the game image is displayed by interpreting the HTML document obtained by the user terminal 10 from the game server 20. The case where the present invention is realized in a so-called browser format has been described, but it is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the transmission and reception process between the user terminal 10 and the game server 20 is suppressed. It may be realized in a so-called native application format. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser. In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the game image is displayed by interpreting the HTML document obtained by the user terminal 10 from the game server 20. The case where the present invention is realized in a so-called browser format has been described, but it is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the transmission and reception process between the user terminal 10 and the game server 20 is suppressed. It may be realized in a so-called native application format. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser. In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the game image is displayed by interpreting the HTML document obtained by the user terminal 10 from the game server 20. The case where the present invention is realized in a so-called browser format has been described, but it is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the transmission and reception process between the user terminal 10 and the game server 20 is suppressed. It may be realized in a so-called native application format. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser. In the first embodiment, communication according to HTTP is performed between the user terminal 10 and the game server 20, and the game image is displayed by interpreting the HTML document obtained by the user terminal 10 from the game server 20. The case where the present invention is realized in a so-called browser format has been described, but it is not limited to this case. By executing the game program downloaded by the user terminal 10, the user terminal 10 mainly executes the game process, and the transmission and reception process between the user terminal 10 and the game server 20 is suppressed. It may be realized in a so-called native application format. In the native application format, image data is generated and displayed in the user terminal 10 without using a web browser. In the second embodiment, an example of realizing the game of the first embodiment in the 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, most of the processing is assumed to be performed on the user terminal 10 side. However, for a part of the game processing that will not be described below (for example, the lottery processing given to the user by lottery, or the present processing in which the game operator gives a card to the user), the processing may be performed on the game server 20 side, and the processing result by the game server 20 may be transmitted to the user terminal 10. In the second embodiment, an example of realizing the game of the first embodiment in the 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, most of the processing is assumed to be performed on the user terminal 10 side. However, for a part of the game processing that will not be described below (for example, the lottery processing given to the user by lottery, or the present processing in which the game operator gives a card to the user), the processing may be performed on the game server 20 side, and the processing result by the game server 20 may be transmitted to the user terminal 10. In the second embodiment, an example of realizing the game of the first embodiment in the 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, most of the processing is assumed to be performed on the user terminal 10 side. However, for a part of the game processing that will not be described below (for example, the lottery processing given to the user by lottery, or the present processing in which the game operator gives a card to the user), the processing may be performed on the game server 20 side, and the processing result by the game server 20 may be transmitted to the user terminal 10. In the second embodiment, an example of realizing the game of the first embodiment in the 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, most of the processing is assumed to be performed on the user terminal 10 side. However, for a part of the game processing that will not be described below (for example, the lottery processing given to the user by lottery, or the present processing in which the game operator gives a card to the user), the processing may be performed on the game server 20 side, and the processing result by the game server 20 may be transmitted to the user terminal 10. In the second embodiment, an example of realizing the game of the first embodiment in the 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, most of the processing is assumed to be performed on the user terminal 10 side. However, for a part of the game processing that will not be described below (for example, the lottery processing given to the user by lottery, or the present processing in which the game operator gives a card to the user), the processing may be performed on the game server 20 side, and the processing result by the game server 20 may be transmitted to the user terminal 10. In the second embodiment, an example of realizing the game of the first embodiment in the 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, most of the processing is assumed to be performed on the user terminal 10 side. However, for a part of the game processing that will not be described below (for example, the lottery processing given to the user by lottery, or the present processing in which the game operator gives a card to the user), the processing may be performed on the game server 20 side, and the processing result by the game server 20 may be transmitted to the user terminal 10. In the second embodiment, an example of realizing the game of the first embodiment in the 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, most of the processing is assumed to be performed on the user terminal 10 side. However, for a part of the game processing that will not be described below (for example, the lottery processing given to the user by lottery, or the present processing in which the game operator gives a card to the user), the processing may be performed on the game server 20 side, and the processing result by the game server 20 may be transmitted to the user terminal 10. In the second embodiment, an example of realizing the game of the first embodiment in the 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, most of the processing is assumed to be performed on the user terminal 10 side. However, for a part of the game processing that will not be described below (for example, the lottery processing given to the user by lottery, or the present processing in which the game operator gives a card to the user), the processing may be performed on the game server 20 side, and the processing result by the game server 20 may be transmitted to the user terminal 10. In this embodiment, the user terminal 10 is an example of an information processing device.

[0057] In this embodiment, the user terminal 10 receives a notification from the game operator based on a predetermined operation by the user. The game program is received from the server, and the received game program is stored in the storage 18. When the game is started by the user terminal 10, the user terminal 10 and the game server Communication is established between the game server 20 and the user, and login processing is performed. Data table group (card data table, evolution synthesis data table, possession card data table, The data table group transmitted to the user terminal 10 is The data is stored in the storage 18 of the user terminal 10. In this case, the data in the storage 18 The tables are updated every time you log 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 At this point, the possessed card data table in the user terminal 10 is transmitted to the game server 20. The game server 20 receives the owned card data table and checks the owned card data in the storage 25. The card data table is compared to confirm that the data has not been tampered with, and then the The possessed card data table in storage 25 is updated to the received data.

[0058] Although not shown in the figure, in this embodiment, the user terminal 10 is The process flow of evolutionary synthesis shown in is executed by referring to the data tables in storage 18. do. In this embodiment, the card data table, the evolution synthesis data table, the possession card data Although the case where the table is held in the game server 20 has been described, This is not possible. In the case of a game in the native application format, the sharing of the retention of each data table can be set as appropriate, and the user terminal 10, the game server 20, and at least one of the other devices accessible from the user terminal 10 or the game server 20 should hold each data table, and it is not limited to a specific holding mode.

[0059] (3) Variation Hereinafter, a variation common to each of the above-described embodiments will be described.

[0060] (3-1) Variation 1 In this variation, the output means 54 displays a plurality of reference cards specified by a plurality of reference card IDs included in each combination condition acquired by the acquisition means 53 in a distinguished manner for each reference card ID, and outputs image data. To realize the function of the output means 54 of this variation, the CPU 21 of the game server 20 When acquiring the pre-evolution card ID, the post-evolution card ID, and the reference card ID included in the combination condition corresponding to the evolution ID in each evolution synthesis, the card data corresponding to these card IDs is read from the card data table, and image data for displaying them in a distinguished manner for each reference card ID is generated. An example of the image displayed based on the generated image data is shown in FIG. 14. The image P4b shown in FIG. 14 is an example of the image displayed according to this variation of the image P4 in FIG. 9. In this configuration, since the plurality of cards included in each combination condition are presented to the user in a distinguished manner for each card ID, the user can quantitatively recognize how many of each card are required. Therefore, the user can surely evolve the selected card into different cards sequentially in order to​​​​ It is possible to overview the overall cards that are essential, and it is also easy to recognize the number of types of cards to be obtained. Furthermore, it may be displayed so that the user can know whether the user has the card with each card ID or not. Also, even if the user has the card, it may be displayed so that it can be known whether all the cards of all numbers are held or not all the cards of all numbers are held. Also, when not all the cards of all numbers are held, it may be displayed so that the number of cards held and the number of cards that are essential to hold can be known respectively. By displaying in this way, the user can check the current possession status of the cards to be obtained. For example, when the number of reference cards held is N and the number of reference cards that need to be held is M, information in the form of N / M may be displayed in association with each card.

[0061] (3-2) Modification Example 2 In this modification example, the output means 54 causes the cards specified by the reference card IDs that are repeatedly included in at least two or more levels of combination conditions among the plurality of reference card IDs included in each combination condition acquired by the acquisition means 53 to be displayed in a display format different from the cards specified by the card IDs other than the repeatedly included card IDs, and image data may be output. To realize the function of the output means 54 of this modification example, the CPU 21 of the game server 20, when acquiring the pre-evolution card ID, the post-evolution card ID, and the reference card ID included in the combination condition corresponding to the evolution ID in each evolution synthesis, specifies the reference card IDs (duplicate reference card IDs) that are repeatedly included in at least two or more levels of combination conditions. And , the pre-evolution card ID, the post-evolution card ID, and the reference card IDs included in the combination conditions Read the corresponding card data from the card data table, and make the above duplicate reference card I D and the reference card ID that is not a duplicate reference card ID have different display formats Generate image data. An example of the image displayed based on the generated image data is shown in Fig. 15 Shown. The image P4c shown in Fig. 15 is an example of the image displayed according to this modified example for the image P4 in Fig. 9 Yes, and cards A01, C12, and M03 are the cards corresponding to the duplicate reference card IDs respectively respectively. In this configuration, among the multiple reference card IDs included in the combination conditions for the multi-stage evolution synthesis of the card selected as the base card, the cards with duplicate reference card IDs are different They are presented to the user in different display formats. Therefore, the user can overview all the cards required to sequentially evolve the selected card into different cards, and in particular, can easily recognize the cards that need to be obtained more abundantly. Furthermore, it may be displayed so that the user can know whether the user has the card corresponding to the duplicate reference card ID or not. Also, even if the user has it, It may be displayed so that it can be known whether all the duplicate reference cards are held or not all the duplicate reference cards are held. Also, when not all the duplicate reference cards are held, it may be displayed so that the number of duplicate reference cards held and the number of duplicate reference cards required to be held can be known respectively. By displaying in this way, the user can check the current possession status of the cards that need to be obtained. For example, when the number of duplicate reference cards held is N and the number of duplicate reference cards required to be held is M, each card respectively. respectively. respectively. If not all the duplicate reference cards are held, it may be displayed so that the number of duplicate reference cards held and the number of duplicate reference cards required to be held can be known respectively. By displaying in this way, the user can check the current possession status of the cards that need to be obtained. For example, when the number of duplicate reference cards held is N and the number of duplicate reference cards required to be held is M, each card respectively. respectively. Information in the form of N / M may be displayed in association therewith.

[0062] (3-3) Variant Example 3 In this variant example, the card ID is associated with information indicating the conditions for obtaining the card by the user. The information indicating the conditions for obtaining the card may be, for example, the rarity of the card or a limited flag as shown in FIG. 5, or may be a level corresponding to the number of circulated cards. The level corresponding to the number of circulated cards is not shown in FIG. 5 but is recorded in the card data table. The game server 20 periodically (e.g., daily) totals the owned cards of all users registered in the game for each card ID, determines the level based on the total value, and updates the value of the level in the card data table. In this example, the output means 54 displays, in a display format different from that of the reference cards specified by the reference card IDs whose acquisition conditions do not satisfy the predetermined conditions, the cards specified by the reference card IDs whose acquisition conditions satisfy the predetermined conditions among the plurality of reference card IDs included in each combination condition acquired by the acquisition means 53, and may output image data. To realize the function of the output means 54 of this variant example, the CPU 21 of the game server 20, when acquiring the pre-evolution card ID, the post-evolution card ID, and the reference card ID included in the combination condition corresponding to the evolution ID in each evolution synthesis, reads out the card data corresponding to these card IDs from the card data table and generates image data for displaying them separately for each piece of information indicating the acquisition conditions of the card. An example of the image displayed based on the generated image data is shown in FIG. 16. The image P4d shown in FIG. 16 is the image P4 of FIG. 9 in this variant example. In this example, the output means 54 may output image data by displaying, in a different display format, the cards specified by the reference card IDs whose acquisition conditions satisfy a predetermined condition among the plurality of reference card IDs included in each combination condition acquired by the acquisition means 53, as compared with the reference cards specified by the reference card IDs whose acquisition conditions do not satisfy the predetermined condition. Among the plurality of reference card IDs included in each combination condition acquired by the acquisition means 53, the cards specified by the reference card IDs whose acquisition conditions satisfy the predetermined condition are displayed in a different display format from the reference cards specified by the reference card IDs whose acquisition conditions do not satisfy the predetermined condition. Specifically, the cards specified by the reference card IDs whose acquisition conditions satisfy the predetermined condition are displayed in a different display format from the reference cards specified by the reference card IDs whose acquisition conditions do not satisfy the predetermined condition. Thus, image data may be output. To realize the function of the output means 54 of this variant example, the CPU 21 of the game server 20 When acquiring the pre-evolution card ID, the post-evolution card ID, and the reference card ID included in the combination condition corresponding to the evolution ID in each evolution synthesis, reads out the card data corresponding to these card IDs from the card data table and generates image data for displaying them separately for each piece of information indicating the acquisition conditions of the card. An example of the image displayed based on the generated image data is shown in FIG. 16. The image P4d shown in FIG. 16 is the image P4 of FIG. 9 in this variant example. Based on the generated image data, an example of the displayed image is shown in FIG. 16. The image P4d shown in FIG. 16 is the image P4 of FIG. 9 in this variant example. An example of the image shown in FIG. 16 is the image P4 in FIG. 9 in this variant example. ​Therefore, it is an example of an image to be displayed. In the example of the image P4d, information indicating the acquisition conditions of the card is the arity, and it exemplifies the case where the rarity of the card is R5 as a predetermined condition. The reference card with rarity R5 is displayed in a different display format from the reference cards with rarity R4 or less. In this configuration, for example, when the acquisition condition is a condition related to the difficulty of acquiring the card, since the difficulty of acquiring the cards with a plurality of card IDs included in the combination conditions of the multi-stage evolution synthesis for the card selected as the base card is known, the user can consider the difficulty of acquisition and determine up to which stage to perform the evolution synthesis for the selected card. Furthermore, it may be displayed so that it can be seen whether the user has a card with a high acquisition difficulty or does not have it. Also, even if the user has it, it may be displayed so that it can be seen whether all the cards are held or not all the cards are held. Also, when not all the cards are held, it may be displayed so that the number of cards held and the number of cards required to be held can be seen respectively. By displaying in this way, the user can check the current possession status of the cards to be acquired. For example, when the number of reference cards held is N and the number of reference cards required to be held is M, information in the form of N / M may be displayed in association with each card.

[0063] (3-4) Modification Example 4 In this modification example, the receiving means 51 as the second receiving means is a card that can be evolved step by step so that the card selected as the base card becomes a different card each time evolution synthesis is performed. In some cases, the selected card is gradually evolved step by step to become a different card, and information regarding the number of times of evolutionary synthesis is received. Also, in this modification, when the receiving means 51 receives the designation of information regarding the number of times of evolutionary synthesis, the acquisition means 53 acquires each combination condition for performing the evolutionary synthesis of the selected card as the base card for the number of times. An example of a series of images displayed on the user terminal 10 in this modification is shown in FIG. 17. When the button b11 (“confirm”) is designated in the image P3 of FIG. 17 (the same as the image P3 of FIG. 8), the image changes as shown in P10. In the image P10, buttons b31 to b33 are provided as options for the number of evolutions of the card Q01 selected as the base card. The designation of any of the buttons b31 to b33 corresponds to the designation of information regarding the number of times of evolutionary synthesis. In the image P10, for example, when the button b32 (“evolution to the second stage”) is designated, the image changes as shown in P11. As designated by the button b32, the reference cards necessary for the evolution of the card Q01 to the second stage are displayed in the image P11.

[0064] To implement this modification, when the CPU 11 of the user terminal 10 receives an operation for designating information regarding the number of times of evolutionary synthesis (for example, the designation operation of any of the buttons b31 to b33 in FIG. 17), the information regarding the number of times of evolutionary synthesis is transmitted to the game server 20. The CPU 21 of the game server 20 acquires the information regarding the number of times of evolutionary synthesis from the user terminal 10, and from the evolutionary synthesis data table, the pre-evolution card ID, the post-evolution card ID, and the combination conditions corresponding to the evolution ID in each evolutionary synthesis of the card selected as the base card. Obtain the reference card ID included therein. Then, from the obtained information, extract the card ID corresponding to the information regarding the number of evolution syntheses specified by the user, and read the card data corresponding to the extracted card ID from the card data table, and generate image data for displaying separately for each stage of evolution. An example of the image to be displayed based on the generated image data is the image P11 illustrated in FIG. 17. Extract the card ID corresponding to the information regarding the number of evolution syntheses specified by the user, and read the card data corresponding to the extracted card ID from the card data table. Read the card data corresponding to the extracted card ID from the card data table, and generate image data for displaying separately for each stage of evolution. An example of the image to be displayed based on the generated image data is the image P11 illustrated in FIG. 17. An example of the image to be displayed based on the generated image data is the image P11 illustrated in FIG. 17. Note that the information obtained by the CPU 21 from the evolution synthesis data table does not have to be information corresponding to all evolutions until the selected card finally evolves, and may be information corresponding to the number of evolution syntheses specified by the information regarding the number of evolution syntheses. Note that the information obtained by the CPU 21 from the evolution synthesis data table does not have to be information corresponding to all evolutions until the selected card finally evolves, and may be information corresponding to the number of evolution syntheses specified by the information regarding the number of evolution syntheses. As long as it is information corresponding to the number of evolution syntheses specified by the information regarding the number of evolution syntheses. That's fine.

[0065] In this configuration, according to the number of evolution syntheses specified by the user, the reference cards required for the number of evolution syntheses for the selected card are presented to the user. Therefore, the user can avoid a situation that becomes troublesome for the user, such as when all the types and numbers of reference cards required for all evolution syntheses for the selected card are presented to the user when they are very large. Since the user can specify the number of evolution syntheses, for example, by specifying a relatively small number of times (for example, 2 to 3 times) for evolution synthesis, in the near future, only the reference cards required for the selected card can be extracted and confirmed, or all the reference cards required for all evolution syntheses for the selected card can be confirmed at once. That is, the presentation mode desired by the user can be realized according to the user's specification. In this configuration, according to the number of evolution syntheses specified by the user, the reference cards required for the number of evolution syntheses for the selected card are presented to the user. Therefore, the user can avoid a situation that becomes troublesome for the user, such as when all the types and numbers of reference cards required for all evolution syntheses for the selected card are presented to the user when they are very large. Since the user can specify the number of evolution syntheses, for example, by specifying a relatively small number of times (for example, 2 to 3 times) for evolution synthesis, in the near future, only the reference cards required for the selected card can be extracted and confirmed, or all the reference cards required for all evolution syntheses for the selected card can be confirmed at once. That is, the presentation mode desired by the user can be realized according to the user's specification. In this configuration, according to the number of evolution syntheses specified by the user, the reference cards required for the number of evolution syntheses for the selected card are presented to the user. Therefore, the user can avoid a situation that becomes troublesome for the user, such as when all the types and numbers of reference cards required for all evolution syntheses for the selected card are presented to the user when they are very large. Since the user can specify the number of evolution syntheses, for example, by specifying a relatively small number of times (for example, 2 to 3 times) for evolution synthesis, in the near future, only the reference cards required for the selected card can be extracted and confirmed, or all the reference cards required for all evolution syntheses for the selected card can be confirmed at once. That is, the presentation mode desired by the user can be realized according to the user's specification. In this configuration, according to the number of evolution syntheses specified by the user, the reference cards required for the number of evolution syntheses for the selected card are presented to the user. Therefore, the user can avoid a situation that becomes troublesome for the user, such as when all the types and numbers of reference cards required for all evolution syntheses for the selected card are presented to the user when they are very large. Since the user can specify the number of evolution syntheses, for example, by specifying a relatively small number of times (for example, 2 to 3 times) for evolution synthesis, in the near future, only the reference cards required for the selected card can be extracted and confirmed, or all the reference cards required for all evolution syntheses for the selected card can be confirmed at once. That is, the presentation mode desired by the user can be realized according to the user's specification. Furthermore, display so that it can be seen whether each card is in the possession of the user or not. It is also acceptable. Even if the user has cards, it may be displayed whether the user has all the cards of all numbers or does not have all the cards of all numbers. Also, if the user does not have all the cards of all numbers, the number of cards the user has and the number of cards required for evolution may be displayed so that the user can understand them respectively. By displaying in this way, the user can check the current possession status of the cards that should be obtained to perform evolution synthesis a specified number of times. For example, when the number of reference cards the user has is N and the number of reference cards required is M, information in the form of N / M may be displayed in association with each card .

[0066] (3-5) Variant Example 5 In this variant example, when the card selected as the base card evolves over multiple stages, the cards required for evolution at each stage of that card can be reserved so that the user does not accidentally dispose of them. For the reserved cards (hereinafter also referred to as "reserved cards"), their use for processing other than the evolution synthesis of the target card is restricted. More specifically, in this variant example, the above-mentioned reception means 51 serves as a request reception means and receives a restriction request based on an operation by the user in response to the output of image data by the determination means 54, in order to restrict the processing for at least any one of the multiple cards. And in this variant example, when a restriction request is received by the reception means 51, the change means 58, based on the multiple reference card IDs included in the combination conditions obtained by the acquisition means 53, among the user's possessed cards that are the source of the restriction request, those used for processing different from evolution synthesis For a card identified as a restricted card whose use should be restricted, it has a function of restricting its use for a process different from the evolution synthesis. It has a function of restricting its use for a process different from the evolution synthesis.

[0067] An example of the method for reserving the card of this modified example will be described with reference to the image P4e in FIG. 18. The image P4e in FIG. 18 is a modified example of the display mode of the image P4 in FIG. 9. In the image P4e, reference cards required for evolution at each stage are displayed, and the status of the card corresponding to the displayed reference card is also displayed. The status of the card is one of the following: "not possessed" indicating that the user does not possess the card, "reserved" indicating that the user possesses the card and has reserved it, or "not reserved" indicating that the user possesses the card but has not reserved it (in this case, buttons b41, b42 ("Reserve") etc. are displayed.). In the image P4e, when any one of the buttons b41, b42 is specified, the status of the reference card corresponding to the button changes from the "not reserved" state to the "reserved" state. As an example of the case where a reserved card is used for a process other than the target evolution synthesis, the selling process of the reserved card will be described. FIG. 19 shows a series of changes in the display screens when the user executes the process of selling a reserved card. In FIG. 19, the image P1 is the same as that shown in FIG. 8. When the button b5 ("Sell") is specified in the image P1, the image changes as shown in P20. In the image P20, a list of the user's possessed cards is displayed. Select the card that the user wishes to sell from the list of possessed cards in the image P20. At this time, the place In the image P4e, when any one of the buttons b41, b42 is specified, the status of the reference card corresponding to the button changes from the "not reserved" state to the "reserved" state. In the image P4e, when any one of the buttons b41, b42 is specified, the status of the reference card corresponding to the button changes from the "not reserved" state to the "reserved" state.

[0068] As an example of the case where a reserved card is used for a process other than the target evolution synthesis, the selling process of the reserved card will be described. As an example of the case where a reserved card is used for a process other than the target evolution synthesis, the selling process of the reserved card will be described. FIG. 19 shows a series of changes in the display screens when the user executes the process of selling a reserved card. In FIG. 19, the image P1 is the same as that shown in FIG. 8. When the button b5 ("Sell") is specified in the image P1, the image changes as shown in P20. In the image P20, a list of the user's possessed cards is displayed. Select the card that the user wishes to sell from the list of possessed cards in the image P20. At this time, the place When a reserved card is selected as a sell target from the cards in hand, as shown in P21, the image changes. Image P21 includes text for notifying that the card selected by the user is a reserved card, and buttons b50 ("Continue") and b51 ("Return") for allowing the user to select whether to continue the sell process. When button b50 is specified in image P21, even a reserved card is sold, and thereby the user obtains points of the sell price corresponding to the card and loses the reserved card. As shown in image P21, complicating the execution procedure of the sell process for reserved cards is an example of restricting the use of reserved cards for processes other than evolution synthesis. Also, although not shown in FIG. 19, in image P20, the list of the user's cards in hand may be displayed in such a manner that reserved cards cannot be selected. That is, in order to more surely prevent reserved cards from being used for processes other than evolution synthesis,

[0069] the execution of the sell process for reserved cards may be prohibited. In the game of this embodiment, in addition to the sell process described above, the user may lose cards in hand by executing a normal synthesis process. In the normal synthesis process, the user selects a base card as the card to be grown from the cards in hand. In the normal synthesis process, the combination conditions of reference cards may not be determined for each base card, and the user can appropriately select reference cards from the cards in hand. When the normal synthesis process is executed, the card parameters of the base card change (for example, the card level and skill level increase). Moreover, although not shown in FIG. 19, in image P20, the list of the user's cards in hand may be displayed in such a manner that reserved cards cannot be selected. That is, in order to more surely prevent reserved cards from being used for processes other than evolution synthesis, the execution of the sell process for reserved cards may be prohibited. In addition, in the game of this embodiment, in addition to the sell process described above, the user may lose cards in hand by executing a normal synthesis process.

[0070] Note that in the game of this embodiment, in addition to the sell process described above, when executing a normal synthesis process, the user may lose cards in hand. In the normal synthesis process, the user selects a base card as the card to be grown from the cards in hand. In the normal synthesis process, the combination conditions of reference cards may not be determined for each base card, and the user can appropriately select reference cards from the cards in hand. When the normal synthesis process is executed, the card parameters of the base card change (for example, the card level and skill level increase). For example, the card level and skill level increase. When the normal synthesis process is executed, the card parameters of the base card change (for example, the card level and skill level increase). Instead, the reference card disappears from the user's possession card. Even in the case of normal synthesis processing, as in the above-described selling process, when performing normal synthesis, if the reference card used for the normal synthesis is a reserved card, the execution of the normal synthesis is restricted.

[0071] A method for realizing this modified example will be described. In this modified example, a reservation data table is provided in the storage 25 of the game server 20 The reservation data table is a data table for managing card reservations for each evolution synthesis, and an example thereof is shown in FIG. 20. The reservation data table records information on reserved cards for the user's evolution synthesis. In FIG. 20, a reservation data table for one user is illustrated, but the reservation data table is provided for each user registered in the game. In FIG. 20, the reservation ID is an ID issued in the order in which the evolution synthesis reservation was made. The evolution ID corresponds to the evolution ID shown in the evolution synthesis data table and is an ID for specifying the content of the evolution synthesis. Among the serial numbers of the reserved cards, the serial number of the pre-evolution card corresponds to the serial number of the possession card selected by the user as the base card for the evolution synthesis. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference card each correspond to the columns C1 to C5 that constitute the combination condition of the reference card ID in the evolution synthesis data table. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. In the example of the reservation data table shown in FIG. 20, an example of the case shown in the image P4e of FIG. 18 is shown. The evolution ID corresponds to the evolution ID shown in the evolution synthesis data table and is an ID for specifying the content of the evolution synthesis. Among the serial numbers of the reserved cards, the serial number of the pre-evolution card corresponds to the serial number of the possession card selected by the user as the base card for the evolution synthesis. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference card each correspond to the columns C1 to C5 that constitute the combination condition of the reference card ID in the evolution synthesis data table. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. The evolution ID corresponds to the evolution ID shown in the evolution synthesis data table and is an ID for specifying the content of the evolution synthesis. Among the serial numbers of the reserved cards, the serial number of the pre-evolution card corresponds to the serial number of the possession card selected by the user as the base card for the evolution synthesis. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference card each correspond to the columns C1 to C5 that constitute the combination condition of the reference card ID in the evolution synthesis data table. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. The evolution ID corresponds to the evolution ID shown in the evolution synthesis data table and is an ID for specifying the content of the evolution synthesis. Among the serial numbers of the reserved cards, the serial number of the pre-evolution card corresponds to the serial number of the possession card selected by the user as the base card for the evolution synthesis. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference card each correspond to the columns C1 to C5 that constitute the combination condition of the reference card ID in the evolution synthesis data table. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. Among the serial numbers of the reserved cards, the serial number of the pre-evolution card corresponds to the serial number of the possession card selected by the user as the base card for the evolution synthesis. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference card each correspond to the columns C1 to C5 that constitute the combination condition of the reference card ID in the evolution synthesis data table. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. Among the serial numbers of the reserved cards, the serial number of the pre-evolution card corresponds to the serial number of the possession card selected by the user as the base card for the evolution synthesis. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference card each correspond to the columns C1 to C5 that constitute the combination condition of the reference card ID in the evolution synthesis data table. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference card each correspond to the columns C1 to C5 that constitute the combination condition of the reference card ID in the evolution synthesis data table. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. Among the serial numbers of the reserved cards, the columns C1 to C5 of the reference card each correspond to the columns C1 to C5 that constitute the combination condition of the reference card ID in the evolution synthesis data table. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. When the reference card corresponding to each column is a reserved card, the serial number of that card is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. When the reference card corresponding to each column is not reserved, data indicating "no reservation" (for example, NULL) is recorded. In the example of the reservation data table shown in FIG. 20, an example of the case shown in the image P4e of FIG. 18 is shown. That is, Evolution ID: 0033 corresponds to the evolution of Card Q01 → R01, and Evolution ID : 0044 corresponds to the evolution of Card R01 → S01, and Evolution ID: 0020 corresponds to the evolution of Card S01 → T01. Here, when the button b41 ("Reserve") in the image P4e of FIG. 18 is selected, the CPU 21 of the game server 20 writes the serial number of the card K14 held by the user in the column C 2 instead of the data indicating "No reservation". At this time, the CPU 21 obtains the serial number of the card K14 and refers to the user's held card data table. When generating the image data on which the image P4e of FIG. 18 is based, the CPU 21 of the game server 20 refers to the reservation data table and the held card data table to determine the state of the user's held cards. The CPU 21 refers to the reservation data table and determines that the reference card with the serial number written in it is in the "Reserved" state. For the cards that are not written with the serial number in the reservation data table but are held by the user, it is determined that they are in the "Not reserved" state, and for the cards that the user does not hold, it is determined that they are in the "Not held" state.

[0072] When generating the image data on which the image P4e of FIG. 18 is based, the CPU 21 of the game server 20 refers to the reservation data table and the held card data table to determine the state of the user's held cards. The CPU 21 refers to the reservation data table and determines that the reference card with the serial number written in it is in the "Reserved" state. For the cards that are not written with the serial number in the reservation data table but are held by the user, it is determined that they are in the "Not reserved" state, and for the cards that the user does not hold, it is determined that they are in the "Not held" state. When generating the image data on which the image P4e of FIG. 18 is based, the CPU 21 of the game server 20 refers to the reservation data table and the held card data table to determine the state of the user's held cards. The CPU 21 refers to the reservation data table and determines that the reference card with the serial number written in it is in the "Reserved" state. For the cards that are not written with the serial number in the reservation data table but are held by the user, it is determined that they are in the "Not reserved" state, and for the cards that the user does not hold, it is determined that they are in the "Not held" state. For the cards whose serial numbers are written in the reservation data table, the CPU 21 determines that they are in the "Reserved" state. For the cards that are not written with the serial number in the reservation data table but are held by the user, it is determined that they are in the "Not reserved" state, and for the cards that the user does not hold, it is determined that they are in the "Not held" state. For the cards whose serial numbers are written in the reservation data table, the CPU 21 determines that they are in the "Reserved" state. For the cards that are not written with the serial number in the reservation data table but are held by the user, it is determined that they are in the "Not reserved" state, and for the cards that the user does not hold, it is determined that they are in the "Not held" state. For the cards that are not written with the serial number in the reservation data table but are held by the user, it is determined that they are in the "Not reserved" state, and for the cards that the user does not hold, it is determined that they are in the "Not held" state. For the cards that are not written with the serial number in the reservation data table but are held by the user, it is determined that they are in the "Not reserved" state, and for the cards that the user does not hold, it is determined that they are in the "Not held" state. For the cards that the user does not hold, it is determined that they are in the "Not held" state. In addition, when the CPU 21 of the game server 20 restricts reserved cards, it performs the following processing. When a reserved card is selected as the card to be used in the processing, the CPU 21 refers to the reservation data table to determine whether the processing is the evolution synthesis corresponding to the reserved card (that is, the target evolution synthesis). That is, since the content of the evolution synthesis is specified by the evolution ID corresponding to the reserved card, it is determined whether the above processing is the target evolution synthesis. When a reserved card is selected as the card to be used in the processing, the CPU 21 refers to the reservation data table to determine whether the processing is the evolution synthesis corresponding to the reserved card (that is, the target evolution synthesis). That is, since the content of the evolution synthesis is specified by the evolution ID corresponding to the reserved card, it is determined whether the above processing is the target evolution synthesis. When a reserved card is selected as the card to be used in the processing, the CPU 21 refers to the reservation data table to determine whether the processing is the evolution synthesis corresponding to the reserved card (that is, the target evolution synthesis). That is, since the content of the evolution synthesis is specified by the evolution ID corresponding to the reserved card, it is determined whether the above processing is the target evolution synthesis. When a reserved card is selected as the card to be used in the processing, the CPU 21 refers to the reservation data table to determine whether the processing is the evolution synthesis corresponding to the reserved card (that is, the target evolution synthesis). That is, since the content of the evolution synthesis is specified by the evolution ID corresponding to the reserved card, it is determined whether the above processing is the target evolution synthesis. Since the content of the evolution synthesis is specified by the evolution ID corresponding to the reserved card, it is determined whether the above processing is the target evolution synthesis. If it is determined that the desired evolutionary synthesis is not possible, e.g. Generate data for an image (e.g., image P21 in FIG. 19) to warn the user and transmits it to the user terminal 10.

[0073] According to this modification, in response to a request from a user, a base card among the cards possessed by the user is selected. At least some of the reference cards required to evolve the card selected as the base or all of the selected cards can be used for any process other than the evolution synthesis of each stage. Therefore, before the combination conditions are met, the user may mistakenly select a card and use it in the future. A reference card required for evolution over a period of time is mistakenly used for a process other than that evolution. This can reliably prevent the above-mentioned problems from occurring.

[0074] (3-6) Variation 6 In this modification, a registration means 59 is provided. The registration means 59 is a registration means for registering a card selected as a base card. A plurality of cards included in each combination condition acquired by the acquisition means 53 for the acquired card. When the card ID of a user's card is included in the card ID of the user's card, the card The instruction cards selected based on the user's operation can be saved as favorites (bookmarks). In other words, in this modification, the user's card has the following function: If the card selected as the base card contains cards necessary for future evolution You can register the card as a favorite.

[0075] FIG. 21 shows an example of a method for registering a card as a favorite in this modified example. The image P4f in FIG. 21 is a modified example of the display mode of the image P4 in FIG. In P4f, while displaying the reference cards necessary for the evolution of each stage, the state of the card is displayed corresponding to the displayed reference card. The state of the card is either the "not possessed" state indicating that the user does not possess the card or the "possessed" state indicating that the user possesses the card. When selecting a card in either possessed state (K14 in this example) in image P4f, for example, as shown in image P15, the selected card is displayed as the target for favorite registration. Image P15 includes a button b50 ("favorite registration") for registering the selected card as a favorite. Designating the button b50 ("favorite registration") registers the selected card (K14) as the user's favorite. Note that the method of separately displaying the "possessed" and "not possessed" states is not limited to the method using character strings as shown in image P4f, and it may be displayed so as to be distinguishable using images. For example, in the case of a possessed card, the card image corresponding to the possessed card is displayed, and in the case of a non-possessed card, it is displayed as an image different from the card image corresponding to the non-possessed card. As the different image, any image that can be understood to be different from the normal card image may be used, for example, an image with the brightness of the normal card image darkened, an image such as a "?" mark, etc. Also, the favorite registration may be immediately registered as the user's favorite without displaying image P15 when a possessed card is selected in image P4f. Also, in image P4f, after allowing the user to select a plurality of possessed cards, the selected plurality of possessed cards may be registered collectively by having the user press a confirmation button. In image P4f, when selecting a card in either possessed state (in this example, K14), for example, as shown in image P15, the selected card is displayed as the target for favorite registration. Image P15 includes a button b50 ("favorite registration") for registering the selected card as a favorite. Designating the button b50 ("favorite registration") registers the selected card (K14) as the user's favorite. Note that the method of separately displaying the "possessed" and "not possessed" states is not limited to the method using character strings as shown in image P4f, and it may be displayed so as to be distinguishable using images. For example, in the case of a possessed card, the card image corresponding to the possessed card is displayed, and in the case of a non-possessed card, it is displayed as an image different from the card image corresponding to the non-possessed card. As the different image, any image that can be understood to be different from the normal card image may be used, for example, an image with the brightness of the normal card image darkened, an image such as a "?" mark, etc. Also, the favorite registration may be immediately registered as the user's favorite without displaying image P15 when a possessed card is selected in image P4f. Also, in image P4f, after allowing the user to select a plurality of possessed cards, the selected plurality of possessed cards may be registered collectively by having the user press a confirmation button. In image P4f, when selecting a card in either possessed state (in this example, K14), for example, as shown in image P15, the selected card is displayed as the target for favorite registration. Image P15 includes a button b50 ("favorite registration") for registering the selected card as a favorite. Designating the button b50 ("favorite registration") registers the selected card (K14) as the user's favorite. Note that the method of separately displaying the "possessed" and "not possessed" states is not limited to the method using character strings as shown in image P4f, and it may be displayed so as to be distinguishable using images. For example, in the case of a possessed card, the card image corresponding to the possessed card is displayed, and in the case of a non-possessed card, it is displayed as an image different from the card image corresponding to the non-possessed card. As the different image, any image that can be understood to be different from the normal card image may be used, for example, an image with the brightness of the normal card image darkened, an image such as a "?" mark, etc. Also, the favorite registration may be immediately registered as the user's favorite without displaying image P15 when a possessed card is selected in image P4f. Also, in image P4f, after allowing the user to select a plurality of possessed cards, the selected plurality of possessed cards may be registered collectively by having the user press a confirmation button. In image P4f, when selecting a card in either possessed state (in this example, K14), for example, as shown in image P15, the selected card is displayed as the target for favorite registration. Image P15 includes a button b50 ("favorite registration") for registering the selected card as a favorite. Designating the button b50 ("favorite registration") registers the selected card (K14) as the user's favorite. Note that although not shown in the figures, when registered as a favorite, in response to a user's viewing request, a list of the user's owned cards registered as favorites is displayed. Also, the image in FIG. 8 when the button b1 ("View Owned Monsters") is specified at P1 Among the list of owned cards, the favorite cards and the non-favorite owned cards may be displayed in a distinguishable manner so that the favorite cards can be identified. For example, the owned cards registered as favorites can be displayed with a mark indicating that they are registered as favorites, so that they can be distinguished from the non-favorite owned cards. Note that the favorite registration may not only attach a mark, but also restrict the process of the owned cards registered as favorites from becoming non-owned cards. This can prevent the user from accidentally selling or otherwise disposing of the favorite-owned cards. Note that, in the same way as the method described in Modification Example 6, a reservation button may be provided for the desired card in the list of the owned cards registered as favorites, and the reservation can be made by specifying the reservation button. To implement this modification example, in the owned card data table (see FIG. 7), a flag (1: favorite registered, 0: not favorite registered) may be provided corresponding to the card ID of the owned card. When the CPU 21 of the game server 20 receives a viewing request for the cards registered as favorites, it reads out the card data with the flag of "1" in the owned card data table and generates image data including a list of cards based on the read card data. According to this modification example, the cards necessary for the future evolution of the card selected as the base card If it can be confirmed that the user has it, it can be immediately registered as a favorite, so that the user can surely mark the possession card necessary for future evolution without relying on their own memory. Thus, the user can mark the possession card necessary for future evolution without relying on their own memory. Also, for example, when the user has a large number of cards, the user can quickly check the important cards necessary for evolution.

[0076] (4) Application to Applications Other Than Games In the above-described embodiments and modifications, the case where the present invention is applied to a game has been described, but it may also be applied to other applications. For example, when multiple types of electronic coupon tickets are distributed each time a product is purchased at an online shopping mall, those electronic coupon tickets may be used as an example of the object of the present invention. In this case, for example, in order to upgrade (an example of a change process) the privilege content of coupon ticket Q as a base coupon ticket, it is conceivable that the user possesses and uses coupon tickets A to C as reference coupon tickets corresponding to coupon ticket Q. In this example, it is assumed that coupon ticket Q changes to different coupon tickets through a multi-stage change process. At this time, the shopping server identifies the reference coupon tickets necessary for the evolution of each stage of coupon ticket Q as the base coupon ticket, generates image data for the user to present the reference coupon tickets, and transmits the image data to the user terminal. The present invention can also be appropriately applied to other applications other than the above-described examples.

[0077] As described above in detail for the embodiments and modifications of the present invention, the present invention is not limited to the above embodiments. It is not limited to this. Also, the embodiments may be variously modified or changed without departing from the gist of the present invention. Of course, the technical matters described in the above embodiments and each modification example may be applied in appropriate combination. Note that the method of receiving requests is not limited to the case described above. For example, the method of receiving requests may be a method of receiving by instruction input by shaking a user terminal equipped with an acceleration sensor, or instruction input by gesture (gesture input). In the case of gesture input the user terminal recognizes the gesture as an image by performing a predetermined gesture on the user terminal equipped with an imaging function, and recognizes an operation input associated with the gesture in advance. Also, in the case of a user terminal capable of executing a voice recognition program, the method of receiving requests may be a method of receiving by a predetermined voice instruction input.

[0078] [Summary of the Invention] The present invention can be understood as follows from the above description.

[0079] One aspect of the present invention is an information processing device (10 or 20) accessible to a storage device (25) that stores in association an object identification information for identifying an object and a change condition for performing a change process for changing the object, the change condition including a plurality of object identification informations, wherein a first reception means (51) for receiving a designation of a selected object that is an object selected from among the objects possessed by the user based on a user operation; when the selected object is an object that can be gradually changed so as to be sequentially different objects every time the change process is performed, a plurality of steps with respect to the selected object It is an object that can be changed step by step so that it becomes a different object each time acquisition means for acquiring, from the storage device (25), each change condition for performing each change process 53), and output means (54) for outputting output data (for example, image data) for causing a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) to be displayed in a display format distinguishable by the user respectively; An information processing apparatus comprising:

[0080] The "information processing apparatus" may be a stand-alone game machine, a user terminal (for example, a portable terminal, a personal computer, etc.), a server on a network, or the like. The entity of the information processing apparatus can be defined as appropriate according to the implementation form of the game. For example, when the functions of each part of the information processing apparatus are realized by the user operating a game machine or a user terminal, the game machine or the user terminal corresponds to the information processing apparatus of the present invention. Or, when the user terminal, which is a client, has functions of receiving operation inputs from the user and displaying images, and the functions of each part of the information processing apparatus are substantially realized by a server capable of communicating with the user terminal, the server corresponds to the information processing apparatus of the present invention. The "object" may be any display object as long as it can be visually recognized by the user, and can be set as appropriate according to the processing content by the information processing apparatus of the present invention. For example, when the information processing apparatus of the present invention processes information related to a game, the object may include characters, items, etc. on the game. The character is, for example, a virtual person, creature, or monster on the game, and also includes those displayed on a card. The "object" may be any display object as long as it can be visually recognized by the user, and can be set as appropriate according to the processing content by the information processing apparatus of the present invention. For example, when the information processing apparatus of the present invention processes information related to a game, the object may include characters, items, etc. on the game. The character is, for example, a virtual person, creature, or monster on the game, and also includes those displayed on a card. person, creature, or monster on the game, and also includes those displayed on a card. person, creature, or monster on the game, and also includes those displayed on a card. including. "Object identification information" is identification information that enables a user to identify an object, as well as information associated with the identification information. Identification information that enables a user to identify an object is, for example, an object name, an object image, or the like. As information associated with the object name or the object image, an object ID (for example, a card ID if the object is a card) is also an example of "object identification information". The "storage device" may be a memory device of any configuration, such as a flash memory or an HDD (Hard Disk Drive). Further, the storage device may be built into the information processing device, or may be an external device configured to be accessible to the information processing device by wire or wirelessly. "Possession" of an object means that the user has the object in a state where it can be used for processing using the object. "Non-possession" of an object means that the user does not have the object in a state where it can be used for processing using the object. "Obtaining" an object means that the object has changed from a non-possessed state to a possessed state.

[0081] In the above information processing device, when the selected object selected by the user is an object that can be gradually changed so as to be a different object each time a change process is performed, for that user, not only the change conditions necessary for one-step change processing of the selected object, but also a plurality of objects specified by a plurality of object identification information included in the change conditions for future multi-step change processing are presented. Therefore, the user is presented with Since it is possible to recognize in advance that a plurality of presented objects are objects necessary for future change processing of the selected object, it is possible to prevent accidentally releasing any of the plurality of presented objects. Since it is possible to recognize in advance that a plurality of presented objects are objects necessary for future change processing of the selected object, it is possible to prevent accidentally releasing any of the plurality of presented objects. Since it is possible to recognize in advance that a plurality of presented objects are objects necessary for future change processing of the selected object, it is possible to prevent accidentally releasing any of the plurality of presented objects.

[0082] The output means (54) may output the output data by displaying the plurality of objects specified by the plurality of object identification information included in each change condition acquired by the acquisition means (53) separately for each corresponding change condition. The output means (54) may output the output data by displaying the plurality of objects specified by the plurality of object identification information included in each change condition acquired by the acquisition means (53) separately for each corresponding change condition. The output means (54) may output the output data by displaying the plurality of objects specified by the plurality of object identification information included in each change condition acquired by the acquisition means (53) separately for each corresponding change condition. In this configuration, since the plurality of objects included in the change conditions for the first-stage change processing, the second-stage change processing, etc. are displayed for each change condition, the user can distinguish and recognize the objects necessary for change processing in the relatively near future and the objects necessary in the relatively distant future. Therefore, the user can make a choice, for example, for other purposes, to use the objects necessary in the relatively distant future for processing other than change processing. In this configuration, since the plurality of objects included in the change conditions for the first-stage change processing, the second-stage change processing, etc. are displayed for each change condition, the user can distinguish and recognize the objects necessary for change processing in the relatively near future and the objects necessary in the relatively distant future. Therefore, the user can make a choice, for example, for other purposes, to use the objects necessary in the relatively distant future for processing other than change processing. In this configuration, since the plurality of objects included in the change conditions for the first-stage change processing, the second-stage change processing, etc. are displayed for each change condition, the user can distinguish and recognize the objects necessary for change processing in the relatively near future and the objects necessary in the relatively distant future. Therefore, the user can make a choice, for example, for other purposes, to use the objects necessary in the relatively distant future for processing other than change processing. In this configuration, since the plurality of objects included in the change conditions for the first-stage change processing, the second-stage change processing, etc. are displayed for each change condition, the user can distinguish and recognize the objects necessary for change processing in the relatively near future and the objects necessary in the relatively distant future. Therefore, the user can make a choice, for example, for other purposes, to use the objects necessary in the relatively distant future for processing other than change processing. In this configuration, since the plurality of objects included in the change conditions for the first-stage change processing, the second-stage change processing, etc. are displayed for each change condition, the user can distinguish and recognize the objects necessary for change processing in the relatively near future and the objects necessary in the relatively distant future. Therefore, the user can make a choice, for example, for other purposes, to use the objects necessary in the relatively distant future for processing other than change processing. In this configuration, since the plurality of objects included in the change conditions for the first-stage change processing, the second-stage change processing, etc. are displayed for each change condition, the user can distinguish and recognize the objects necessary for change processing in the relatively near future and the objects necessary in the relatively distant future. Therefore, the user can make a choice, for example, for other purposes, to use the objects necessary in the relatively distant future for processing other than change processing.

[0083] The information processing apparatus may further include a registration means (59) for registering the possessed object selected based on the user's operation among the possessed objects when the object identification information corresponding to the user's possessed object is included in the plurality of object identification information included in each change condition acquired by the acquisition means. The information processing apparatus may further include a registration means (59) for registering the possessed object selected based on the user's operation among the possessed objects when the object identification information corresponding to the user's possessed object is included in the plurality of object identification information included in each change condition acquired by the acquisition means. The information processing apparatus may further include a registration means (59) for registering the possessed object selected based on the user's operation among the possessed objects when the object identification information corresponding to the user's possessed object is included in the plurality of object identification information included in each change condition acquired by the acquisition means. The information processing apparatus may further include a registration means (59) for registering the possessed object selected based on the user's operation among the possessed objects when the object identification information corresponding to the user's possessed object is included in the plurality of object identification information included in each change condition acquired by the acquisition means. In this configuration, since it is possible to register the possessed objects necessary for future change processing of the selected object, the user can quickly confirm the important objects necessary for the user for change processing, for example, when possessing a large number of objects. In this configuration, since it is possible to register the possessed objects necessary for future change processing of the selected object, the user can quickly confirm the important objects necessary for the user for change processing, for example, when possessing a large number of objects. In this configuration, since it is possible to register the possessed objects necessary for future change processing of the selected object, the user can quickly confirm the important objects necessary for the user for change processing, for example, when possessing a large number of objects. In this configuration, since it is possible to register the possessed objects necessary for future change processing of the selected object, the user can quickly confirm the important objects necessary for the user for change processing, for example, when possessing a large number of objects.

[0084] In response to the output data being output by the output means (54), to the user a request based on an operation by, among the plurality of objects, at least one object a request receiving means (51) for receiving a request for restricting processing for the object; when the request is received by the request receiving means (51), based on a plurality of object identification information included in the change condition acquired by the acquisition means (53 ), among the owned objects held by the user who is the source of the request, for an object identified as a restricted object to be restricted from being used for a process different from the change process, a restricting means (58) for restricting the object from being used for a process different from the change process, may be further provided. "Restricting from being used for a process different from the change process" is not limited to the process itself other than the change process of the selected object being prohibited, and the change process of the selected object may be executable but may make it difficult to execute the procedure for executing the change process or make the execution procedure of the change process complicated. In the example of the above-described embodiment, the restriction on being used for a process different from the change process of the object is realized by reserving the object. For example, in the above embodiment, "reserved card" is restricted from being used for a process different from the evolution reservation for the purpose of the card. In the above configuration, in response to a request from the user, at least a part or all of the objects necessary for changing the selected object among the user's owned objects are restricted from being used for a process other than the change process of the selected object. Therefore, it is possible to make it difficult to execute the procedure for executing the change process or make the execution procedure of the change process complicated. In the example of the above-described embodiment, the restriction on being used for a process different from the change process of the object is realized by reserving the object. For example, in the above embodiment, "reserved card" is restricted from being used for a process different from the evolution reservation for the purpose of the card. is realized by reserving the object. For example, in the above embodiment, "reserved card" is restricted from being used for a process different from the evolution reservation for the purpose of the card. For example, in the above embodiment, "reserved card" is restricted from being used for a process different from the evolution reservation for the purpose of the card. is restricted from being used for a process different from the evolution reservation for the purpose of the card. In the above configuration, in response to a request from the user, at least a part or all of the objects necessary for changing the selected object among the user's owned objects are restricted from being used for a process other than the change process of the selected object. Therefore, Before meeting the change conditions, it is possible to reliably prevent the user from mistakenly using the objects required to change the selection object for processes other than the process of changing the selection object.

[0085] The output means (54) may output the output data by displaying a plurality of objects specified by a plurality of object identification information included in each change condition acquired by the acquisition means (53) while distinguishing them for each object identification information. In this configuration, since a plurality of objects included in each change condition are presented to the user while being distinguished for each object identification information, the user can quantitatively recognize how many of each object are required. Therefore, the user can overview the entire objects required to sequentially change the selection object to different objects, and can also easily recognize the number of types of objects that should be obtained in large quantities.

[0086] The output means (54) may output the output data by displaying, in a display format different from that of the objects specified by the object identification information other than the object identification information that is repeatedly included in at least two or more levels of change conditions among the plurality of object identification information included in each change condition acquired by the acquisition means (53), the objects specified by the object identification information that is repeatedly included. In this configuration, among the plurality of object identification information included in the change conditions of the multi-stage change process for the selection object, the objects of the overlapping object identification information are different ​​​​​​​​​​​​The selected object is presented to the user in a visual form so that the user can move it around to different objects. It gives you an overview of all the objects that need to be transformed into a single object, especially It is easy to recognize objects that should be acquired more frequently.

[0087] The object identification information is associated with information indicating the conditions under which the object may be obtained by the user. It has been The output means (54) outputs the change conditions included in each change condition acquired by the acquisition means (53). Among the plurality of object identification information, object identification information that satisfies a predetermined condition is selected. The object specified by the information is an object whose acquisition condition does not satisfy the predetermined condition. The object is displayed in a different display format from the object identified by the object identification information. The output data may be output. In this configuration, for example, the acquisition condition is a condition related to the difficulty of acquiring the object. In this case, multiple objects included in the change condition of the multi-stage change process for the selected object are Since the degree of difficulty of obtaining the object of object identification information is known, the user can consider the degree of difficulty of obtaining the object. It is possible to determine to what extent to carry out the transformation of the selected object, taking into account the Cut.

[0088] The selected object is changed to a different object each time the change process is performed. If the selected object is a gradually changeable object, the selected object is sequentially changed to a different object. It accepts information on the number of times to gradually change the object. and a second receiving means (51) for receiving the The acquisition means (53) receives information regarding the number of times the change process has been performed by the second reception means (51). When the specification of information is received, change processing for the selected object may be performed according to the number of times. Each change condition for performing the change processing may be acquired. In this configuration, according to the number of times of multi-stage change processing specified by the user, the objects required for the change processing of the selection object corresponding to the number of times are presented to the user. Therefore, the user can avoid a situation that becomes complicated for the user, such as when all the types and the number of objects required for all change processes for the selection object are presented to the user when the number is very large. Since the user can specify the number of times of multi-stage change processing, for example, by specifying a relatively small number of times (for example, 2 to 3 times) for the change processing, only the objects required for the selection object in the near future can be extracted and confirmed. Alternatively, all the objects required for all change processes for the selection object can be confirmed at once. That is, the presentation mode desired by the user can be realized according to the user's specification. For the user, when the number is very large and all of them are presented to the user, etc., a situation that becomes complicated for the user can be avoided. The user can specify the number of times of multi-stage change processing. For example, by specifying a relatively small number of times (for example, 2 to 3 times) for the change processing, only the objects required for the selection object in the near future can be extracted and confirmed. For the user, when the number is very large and all of them are presented to the user, etc., a situation that becomes complicated for the user can be avoided. For the user, when the number is very large and all of them are presented to the user, etc., a situation that becomes complicated for the user can be avoided. For the user, when the number is very large and all of them are presented to the user, etc., a situation that becomes complicated for the user can be avoided. For the user, when the number is very large and all of them are presented to the user, etc., a situation that becomes complicated for the user can be avoided. For the user, when the number is very large and all of them are presented to the user, etc., a situation that becomes complicated for the user can be avoided.

[0089] Another aspect of the present invention is an information processing system (1) including a user terminal (10) and a server (20) configured to be communicable with the user terminal (10). In the information processing system accessible to a storage device (25) that stores, in association with each other, object identification information for identifying an object and change conditions for performing change processing for changing the object, the change conditions including a plurality of pieces of object identification information, based on a user operation, from among the objects possessed by the user, a selected object is selected. Based on a user operation, from among the objects possessed by the user, a selected object is selected. Based on a user operation, from among the objects possessed by the user, a selected object is selected. In the information processing system accessible to a storage device (25) that stores, in association with each other, object identification information for identifying an object and change conditions for performing change processing for changing the object, the change conditions including a plurality of pieces of object identification information, Based on a user operation, from among the objects possessed by the user, a selected object is selected. First receiving means (51) for receiving designation of a selected object that is an object When the selected object is an object that can be gradually changed so as to be sequentially different objects each time the change process is performed a plurality of change conditions for performing each change process on the selected object are obtained from the storage device (25) by obtaining means ( 53), 53), Output means (54) for outputting output data for displaying a plurality of objects specified by a plurality of object identification information included in each change condition obtained by the obtaining means (53) in a display format that can be identified by the user respectively is an information processing system provided in at least one of the user terminal (10) or the server (20).

[0090] Another aspect of the present invention is a computer accessible to a storage device (25) that stores, in association with each other, object identification information for identifying an object and a change condition for performing a change process for changing the object, the change condition including a plurality of object identification information, First receiving means (51) for receiving designation of a selected object that is an object selected from among the objects possessed by the user based on a user operation, When the selected object is an object that can be gradually changed so as to be sequentially different objects each time the change process is performed a plurality of change conditions for performing each change process on the selected object are obtained from the storage device (25) by obtaining means ( 53), When the selected object is an object that can be gradually changed so as to be sequentially different objects each time the change process is performed a plurality of change conditions for performing each change process on the selected object are obtained from the storage device (25) by obtaining means ( 53), 53), a plurality of object identifications included in each change condition obtained by the obtaining means (53) ​​​A plurality of objects identified by the information are displayed in a form that can be individually identified by the user. output means (54) for outputting output data to be displayed; This is a program that functions as a

[0091] Another aspect of the present invention is a computer, such as an optical disk or a magnetic disk, that stores the above program. The information may be a computer-readable storage medium.

[0092] In the above description, in order to facilitate understanding of the present invention, the reference numerals in the drawings are written in parentheses. However, this does not limit the information processing device and the like according to the present invention to the embodiment shown in the drawings. It's not something like that. [Explanation of symbols]

[0093] 1. Game System 10...User terminal 11...CPU 12...ROM 13…RAM 15...Operation input section 16…Display section 17...Communication interface section 18…Storage 19…Bus 20…Game server 21…CPU 22...ROM 23…RAM 24...Communication interface section 25…Storage 26…Bus 51...Means of reception 52...Game execution means 53…Acquisition means 54...Output means 55...Judgment means 56...Change method 57...Recording means 58...Restrictive measures 59…Means of registration 70...Data tables

Claims

1. Object identification information for identifying an object and a change for changing the object A change condition, which is a condition for performing processing and includes a plurality of object identification information, is associated with the change condition. An information processing device capable of accessing a storage device that stores information in a Receives the selection object, which is the object selected based on the user's operation. A first receiving means for attaching The selected object is changed to a different object each time the change process is performed. If the selected object is a gradual changeable object, multiple gradations are applied to the selected object. An acquisition means for acquiring each change condition for performing each change process from the storage device; According to the plurality of object identification information included in each change condition acquired by the acquisition means and displaying a plurality of objects identified by the above in a form that is identifiable by the user. an output means for outputting output data for Equipped with The output data includes the user inputting a set of the plurality of objects to be identified. Whether or not the object is owned by the user is displayed in a display format that can be identified by the user. An information processing device that processes data for this purpose.

2. The output means outputs a plurality of objects included in each of the change conditions acquired by the acquisition means. The multiple objects identified by the object identification information are distinguished according to the corresponding change conditions. and outputting the output data so as to display the output data in the form of a 2. An information processing device according to claim 1.

3. Among the plurality of object identification information included in each change condition acquired by the acquisition means, includes object identification information corresponding to an object possessed by the user, A possessed object selected from the possessed objects based on a user operation is registered. and a registration means for registering the 3. An information processing device according to claim 1 or 2.

4. In response to the output of the output data by the output means, A request based on at least one of the plurality of objects. a request receiving means for receiving a request for restricting processing by the client; When the request is accepted by the request accepting means, The requesting user is provided with a plurality of object identification information included in the change condition. Restrict the use of the possessed objects held by the user in a process other than the change process. For objects identified as limited objects, the change process is different from the change process. and a limiting means for limiting the use of the information in processing.

4. An information processing device according to claim 1.

5. An information processing system including a user terminal and a server configured to be able to communicate with the user terminal. At least one of the user terminal and the server is and object identification information for performing a change process for changing the object. A change condition including a plurality of object identification information items is stored in association with the change condition. In the information processing system capable of accessing a storage device, The information processing device according to any one of claims 1 to 4 is provided on the user terminal or An information processing system including at least one of the above servers.

6. Object identification information for identifying an object and a change for changing the object A change condition, which is a condition for performing processing and includes a plurality of object identification information, is associated with the change condition. A computer that can access a storage device that stores the information in a file according to any one of claims 1 to 4 is provided. A program for causing each of the means of the information processing device mounted thereon to function.

Citation Information

Patent Citations

  • Methods for obtaining items in a game and the game system for executing those methods.

    JP5256380B1

  • JP1975086491A

  • Kagutotsutekanaguno toritsukehohoto tokushupenchi

    JP1976053960A