Program, information processing method, terminal, and server

Abstract

To enhance interest in a game.SOLUTION: A program executed by a terminal for communicating with a server and performing processing regarding a game is executed by the terminal so as to display information regarding a first account related to an account of a user of the terminal on a display part of the terminal by a social networking service (SNS), transmit first information for requesting an object that is based on the first account and appears in the game by a communication part of the terminal on the basis of a user's input to information regarding the first account displayed on the display part, receive second information being the object and regarding a first object based on the first account from the server by the communication part on the basis of transmission of the first information, and display the first object on the display part.SELECTED DRAWING: Figure 1-1

Description

[Technical field]

[0001] The present disclosure relates to a program, an information processing method, a terminal, a server, etc. [Background technology]

[0002] There are services (e.g., messaging services) for exchanging content between multiple users (multiple terminals). For example, Patent Literature 1 discloses a technology for distributing advertisements using official accounts. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2016-53929 A Summary of the Invention

[0004] According to a first aspect of the present invention, a program executed by a terminal performing processing related to a game includes the following steps: acquiring, by a control unit of the terminal, a first object that appears in the game based on a first account associated with an account of a user of the terminal on a social networking service (hereinafter referred to as "SNS"); and executing, by the control unit, a first control for displaying, on the SNS, the first object and corresponding information corresponding to the first account. According to a second aspect of the present invention, an information processing method for a terminal performing processing related to a game includes the steps of: acquiring, by a control unit of the terminal, a first object related to the game based on a first account associated with an account of a user of the terminal on an SNS; and executing, by the control unit, a first control for displaying, on the SNS, the first object and corresponding information corresponding to the first account. According to a third aspect of the present invention, a terminal performing processing related to a game includes a control unit that acquires a first object related to the game based on a first account associated with an account of a user of the terminal on an SNS, and the control unit executes a first control for displaying the first object and corresponding information corresponding to the first account on the SNS. [Brief description of the drawings]

[0005] [Figure 1-1] FIG. 1 is a diagram showing an example of a system configuration of a communication system according to a first embodiment. [Figure 1-2] FIG. 2 is a diagram showing an example of functions realized by a control unit of the server according to the first embodiment. [Figure 1-3] FIG. 4 is a diagram showing an example of information stored in a storage unit of the server according to the first embodiment. [Figure 1-4] FIG. 2 is a diagram showing an example of a data configuration of account registration data according to the first embodiment. [Figure 1-5] FIG. 13 is a diagram showing an example of a table configuration of a monster generation table according to the first embodiment. [Figure 1-6] FIG. 2 is a diagram showing an example of functions realized by a control unit of the terminal according to the first embodiment. [Figure 1-7] FIG. 4 is a diagram showing an example of information stored in a storage unit of the terminal according to the first embodiment. [Figure 1-8] FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the terminal according to the first embodiment. [Figure 1-9] FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the terminal according to the first embodiment. [Figure 1-10] FIG. 4 is a diagram showing an example of a screen displayed on a display unit of the terminal according to the first embodiment. [Figure 1-11] 4 is a flowchart showing an example of the flow of processes executed by each device according to the first embodiment. [Figure 1-12] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-13] FIG. 13 is a diagram showing an example of a system configuration of a communication system according to a first modified example. [Figure 1-14]10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-15] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-16] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a first modified example. [Figure 1-17] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-18] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-19] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-20] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-21] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-22] FIG. 13 is a diagram showing an example of a table configuration of a monster generation table according to a first modified example. [Figure 1-23] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a first modified example. [Figure 1-24] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 1-25] 10 is a flowchart showing an example of the flow of processes executed by each device according to a first modified example. [Figure 2-1] FIG. 11 is a diagram showing an example of a data configuration of a formal account management database according to the second embodiment. [Figure 2-2] FIG. 13 is a diagram showing an example of a table configuration of a monster generation table according to the second embodiment. [Figure 2-3] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a second embodiment. [Figure 2-4] 10 is a flowchart showing an example of the flow of processes executed by each device according to the second embodiment. [Figure 2-5] 10 is a flowchart showing an example of the flow of processes executed by each device according to the second embodiment. [Figure 2-6] 10 is a flowchart showing an example of the flow of processes executed by each device according to the second embodiment. [Figure 2-7] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a second modified example. [Figure 3-1] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third embodiment. [Figure 3-2] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third embodiment. [Figure 3-3] FIG. 11 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a third embodiment. [Diagram 3-4] 13 is a flowchart showing an example of the flow of processes executed by each device according to the third embodiment. [Figure 3-5] 13 is a flowchart showing an example of the flow of processes executed by each device according to the third embodiment. [Diagram 3-6] 13 is a flowchart showing an example of the flow of processes executed by each device according to the third embodiment. [Figure 4-1] FIG. 13 is a diagram showing an example of a system configuration of a communication system according to a fourth embodiment. [Figure 4-2] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-3] 13 is a flowchart showing an example of the flow of processes executed by each device according to the fourth embodiment. [Figure 4-4] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-5] 13 is a flowchart showing an example of the flow of processes executed by each device according to the fourth embodiment. [Figure 4-6] 13 is a flowchart showing an example of the flow of processes executed by each device according to the fourth embodiment. [Diagram 4-7] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-8] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-9] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-10] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-11] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-12] 13 is a flowchart showing an example of the flow of processes executed by each device according to the fourth embodiment. [Figure 4-13] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-14] 13 is a flowchart showing an example of the flow of processes executed by each device according to the fourth embodiment. [Figure 4-15] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-16] FIG. 13 is a diagram showing an example of information stored in a game server according to the fourth embodiment. [Figure 4-17] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-18] FIG. 13 is a diagram showing an example of information stored in a game server according to the fourth embodiment. [Figure 4-19] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. [Figure 4-20] FIG. 13 is a diagram showing an example of a screen displayed on a display unit of a terminal according to a fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] <Compliance with legal matters> It should be noted that the disclosures described herein are subject to compliance with the laws of the country of implementation, such as communications secrecy, as necessary for the implementation of the disclosure.

[0007] <Embodiment> In this specification, for ease of understanding, there are some places where the phrase "by way of example and not by way of limitation" is used, but please note that not only these places but also the entire embodiment described below are not limited to the contents of the description.

[0008] An embodiment for implementing a program or the like according to the present disclosure will be described with reference to the drawings.

[0009] A system may be comprised of, for example and not by way of limitation, a number of devices. The multiple devices may be a combination of devices of the same type, a combination of devices of different types, or a combination of devices of the same type and devices of different types. Note that a system can be considered, for example and not by way of limitation, as a plurality of devices working together to perform some kind of processing.

[0010] Furthermore, a system relating to a client (client device) and a server can be considered to be, by way of example and not of limitation, at least one of the following: (1) Terminals and servers (2) Server (3) Terminal

[0011] (1) is, by way of example and not limitation, a system including at least one terminal and at least one server. One example of this is a client-server system.

[0012] The server is configured by the following devices, for example and not by way of limitation, and may be a single device or a combination of multiple devices.

[0013] Specifically, the server is configured to have at least one processor (for example and without limitation, CPU: Central Processing Unit, GPU: Graphics Processing Unit, APU: Accelerated Processing Unit, DSP: Digital Signal Processor (for example and without limitation, ASIC: Application Specific Integrated Circuit, FPGA: Field Programmable Gate Array), etc.), computer device (processor + memory), control device, arithmetic device, processing device, etc., and may be a configuration having multiple of the same type of any one device (for example and without limitation, CPU + CPU, homogeneous multi-core processor, etc.) or a configuration having multiple different types of any one device (for example and without limitation, CPU + DSP, heterogeneous multi-core processor, etc.), or may be a combination of multiple devices (for example and without limitation, processor + computer device, processor + arithmetic device, multiple devices made heterogeneous, etc.). The processor may be a virtual processor.

[0014] Also, when a server executes some processing, if the server is configured with a single device, the processing described in the embodiment is executed by the single device. If the server is configured with multiple devices, one device may execute some processing, and the other device may execute other processing. As a non-limiting example, if the server is configured with a processor and an arithmetic device, the processor may execute a first processing, and the arithmetic device may execute a second processing. Furthermore, when a configuration is made up of a plurality of devices, the devices may be arranged in locations physically separated from one another.

[0015] Furthermore, the functions of the server may be provided in the form of PaaS, IaaS, or SaaS in cloud computing, for example and without limitation.

[0016] The control unit of the system may be at least one of the control unit of the terminal and the control unit of the server. That is, by way of example and not limitation, the control unit of the system may be any of the following: (1A) only the control unit of the terminal, (1B) only the control unit of the server, or (1C) both the control unit of the terminal and the control unit of the server.

[0017] In addition, the control and processing (hereinafter collectively referred to as "control, etc.") performed by the control unit of the system may be performed by (1A) only the control unit of the terminal, (1B) only the control unit of the server, or (1C) both the control unit of the terminal and the control unit of the server. In addition, in (1C), as an example and not a limitation, some of the controls performed by the control unit of the system may be performed by the control unit of the terminal, and the remaining controls may be performed by the control unit of the server. In this case, the allocation (allocation) of the controls may be equal or may be allocated in different proportions.

[0018] Furthermore, when referring to a communication unit of a server, if the server is configured with a single device, it may be the communication unit itself that the single device has, or, if the server is configured with multiple devices, the communication unit of the server may be configured to include each communication unit that each device has. As an example and not by way of limitation, if a server comprises a first device and a second device, the first device having a first communication unit and the second device having a second communication unit, the communication unit of the server may be conceptualized as including the first communication unit and the second communication unit.

[0019] (2) is not limited to, but may be, for example, a system consisting of multiple servers (hereinafter, referred to as a "server system"). In this case, the configuration of each server may be the same as that described above.

[0020] The control etc. performed by the server system may be performed by only one of the multiple servers (2A), by only the other servers (2B), or by both the one server and the other servers (2C). In addition, in (2C), as an example and not a limitation, one server may perform part of the control etc. performed by the server system, and another server may perform the remaining control etc. In this case, the allocation (allocation) of the control etc. may be equal or may be allocated in different proportions.

[0021] (3) By way of example and not limitation, the system may be comprised of multiple terminals. The system may be, by way of example and not limitation, a system such as the following: A system that gives server functions to terminals (distributed system). This can be realized using blockchain technology, for example and not by way of limitation. A system in which terminals communicate wirelessly with each other. This can be realized, for example and without limitation, by communicating in a peer-to-peer (P2P) manner using short-range wireless communication technology such as Bluetooth (registered trademark).

[0022] The above is not limited to the control unit, but also applies to each functional unit such as an input / output unit, a communication unit, a storage unit, and a clock unit that may be components of the system.

[0023] In the following embodiment, a system including a terminal and a server (a client-server system) is illustrated as an example and not as a limitation. It should be noted that the server system described above in (2) can also be used as the server.

[0024] Also, instead of a system including a terminal and a server, a system not including a server, such as the above system (3) as an example and not a limitation, may be applied. In this case, the embodiment can be configured based on the above-mentioned blockchain technology. Specifically, by way of example and not limitation, data stored and managed in a server described in the following embodiment is stored on the blockchain. Then, the terminal generates a transaction to the blockchain, and when the transaction is approved on the blockchain, the data stored on the blockchain can be updated.

[0025] It should be noted that even when the term "terminal" is used, this is not limited to the meaning of a terminal as a client device in a client server. That is, a terminal may include the concept of a device other than in a client-server context.

[0026] Furthermore, in this specification, the expression "through a communication I / F" is used as appropriate. This is not intended to be limiting, but may indicate, by way of example, that a device transmits and receives various types of information and data through a communication I / F (through a communication unit) based on the control of a control unit (such as a processor).

[0027] In addition, in this specification, when the terms "related to" and "associated with" are used, "B related to A" or "B related to A" may mean, by way of example and not limitation, "B" having some kind of relationship with "A." Specific examples of this will be described later.

[0028] In addition, in this specification, when a device performs processing on two or more objects, such as "transmitting A and B" or "receiving A and B," this may include performing "A" and "B" in a synchronized manner (hereinafter referred to as "simultaneous"), and performing "A" and "B" with a different timing (hereinafter referred to as "non-simultaneous"). As an example and not a limitation, when referring to transmitting first information and second information, this may include both concepts of transmitting the first information and the second information in a synchronized manner and transmitting the first information and the second information with a lag in timing. In addition, taking into account the lag (time lag), "simultaneous" may include "almost simultaneously."

[0029] Note that, even if "A" and "B" are performed at different times, this only needs to be the processing targeting "A" and "B," and the purpose does not necessarily have to be the same. As an example and not a limitation, when the first information and the second information are transmitted as described above, it is sufficient to transmit the first information and the second information, and this may include cases where the first information and the second information are transmitted for the same purpose, as well as cases where the first information and the second information are transmitted for different purposes.

[0030] Furthermore, this specification describes, by way of example and not limitation, a technique for obtaining objects that appear in a game based on an account associated with a user's account in a service that associates and manages user accounts (a service that manages user accounts and manages the relationships between them). The account may be the account of the user's terminal 20.

[0031] In the embodiment described below, by way of example and not limitation, an example is shown in which objects appearing in a game are obtained based on an account associated with a user's account on a social networking service (hereinafter referred to as "SNS"). An SNS can be an example of the above-mentioned service that associates and manages user accounts (a service that manages user accounts and manages the relationships between them). An SNS is not limited to a service whose primary purpose is to build and foster relationships and communication between users, but may be a service that has the configuration and functionality to manage accounts as if they have some kind of relationship. In addition, account associations in SNS may include one-way associations (such as, for example and not limitation, one user unilaterally following another user), two-way associations (such as, for example and not limitation, users being associated with each other as friends), or relationships managed by managing multiple users as belonging to a single group.

[0032] In the embodiment described below, a messaging service is taken as an example of an SNS. A messaging service can be an example of a service that allows users to chat (hereinafter referred to as a "chat service"), and an application for realizing a chat service is referred to as a "chat application," and an application for realizing a messaging service is referred to as a "messaging application." By way of example and not limitation, a chat application may enable users to chat in chat rooms.

[0033] The chat room may be, for example and without limitation, a UI (User Interface) or GUI (Graphical User Interface) that allows each user to view content transmitted and received between terminals of multiple users.

[0034] The messaging services may also include instant messaging services. In an instant messaging service, simple messages may be sent and received between multiple devices (for example, but not limited to, terminals) via a server, and for example, but not limited to, users may talk in talk rooms. A talk room may be an example of a chat room.

[0035] In addition, talk rooms can include one-to-one user talk rooms (hereinafter referred to as "one-to-one talk rooms"), talk rooms for groups including multiple users (hereinafter referred to as "group talk rooms"), and talk rooms with OA businesses (as an example, but not limited to, businesses that are affiliated with messaging service providers) (hereinafter referred to as "OA talk rooms").

[0036] In addition, an account of a messaging application that is an account of a business operator and not a general user is referred to as an "Official Account (OA)" and a user of this Official Account is referred to as an "Official User." This may also be referred to as an "Official Account User" or "Official Account Business Operator," etc. In contrast, an account of a messaging application that is a user who is not an OA business is called a "general account," and a user of a general account is called a "general user." This may also be called a "general account user," etc. In other words, messaging application accounts may include general accounts and official accounts.

[0037] A general account may be an example of a first type of account, and an official account may be an example of a second type of account. In addition, a general account may be an example of an account of a first type in a messaging service (messaging application) associated with a terminal 20 or a user of that terminal 20, and an official account may be an example of an account of a second type in a messaging service (messaging application) associated with a terminal 20 or a user of that terminal 20.

[0038] In addition, as a non-limiting example, OA operators may be able to use a terminal similar to that of a user with a general account to send and receive messages with other devices via the server.

[0039] In this specification, a message (message information) may mean, by way of example and not limitation, information that defines a sender and a destination used in a messaging service, and that is composed of identification information (message ID) for identifying the message and message content. Additionally, message content may refer to, by way of example and not limitation, the contents of a message excluding the message ID. Message content may be one or more pieces of content.

[0040] Furthermore, the information set as the identification information for identifying a message may be, for example and without limitation, a "message ID." Message content included in a message with the same message ID can be considered to be identified by this message ID. Therefore, the identification information for identifying a message can be considered to be substantially synonymous with the identification information for identifying message content. Alternatively, individual identification information (message content ID) may be set for each message content, but this is not essential.

[0041] The content may include, by way of example and not limitation, text content in text format, image content in image format (including at least one of still images and / or moving images), audio content in sound format (including voice), and the like. In addition, the content may include operation content such as buttons and icons for user operations, and link content such as URIs (including URLs).

[0042] The text may include, by way of example and not limitation, at least one of national characters, extended characters, machine-dependent characters, numbers, symbols, graphics, and symbols represented by character codes. Note that the text does not have to include at least one of the above characters, extended characters, machine-dependent characters, numbers, symbols, figures, and signs, and may include other text.

[0043] The image may include at least one of various types of image information, such as, for example and without limitation, an icon, a button, a stamp, an emoji, and a banner image.

[0044] Unlike the above definition, the superordinate concept of a message may be content, or content and message may be synonymous, or it is not necessary to define them in this way.

[0045] <Example> An example of an embodiment to which the present invention is applied will be described below. In the embodiment described below, an example is given of a messaging service that allows users to send and receive messages (content) using talk rooms (chat rooms) as an SNS; however, the method described below can also be similarly applied to SNSs other than such messaging services.

[0046] <First Example> The first embodiment is, by way of example and not limitation, an embodiment in which, in a game that a user (player) of terminal 20 can play by executing a game application, a user of a general account using a messaging application obtains an object based on a general account (a general account of a general user) that is registered as a friend in the messaging application.

[0047] The contents described in the first embodiment are applicable to any of the other embodiments and other modified examples. Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

[0048] <System configuration> FIG. 1-1 is a diagram illustrating an example of a system configuration of a communication system 1A according to the present embodiment. In the communication system 1A, as an example and not a limitation, a server 10 and a plurality of terminals 20 (terminal 20A, terminal 20B, terminal 20C, . . . ) are connected via a network 30.

[0049] The server 10 has the function of providing game services (game applications) and chat services (chat applications) including messaging services (messaging applications) to terminals 20 owned by general users (or official users) via a network 30.

[0050] In this embodiment, by way of example and not limitation, the server 10 is described as having a function as a messaging server that manages information related to messaging applications and a function as a game server that manages information related to game applications. In this case, by way of example and not limitation, a messaging service provider (operator) may be a user of the server 10 .

[0051] In addition, a payment service (payment application) provider that enables electronic payment using electronic money (electronic currency) or the like may become a user of server 10 and operate a messaging service or the like. The payment service provider may or may not provide the messaging service as one function of the payment application.

[0052] The number of servers 10 and the number of terminals 20 connected to the network 30 are not limited.

[0053] The terminal 20 (terminal 20A, terminal 20B, terminal 20C, ...) may be any information processing terminal capable of implementing the functions described in each embodiment. The terminal 20 includes, but is not limited to, a smartphone, a mobile phone (feature phone), a computer (such as, but not limited to, a desktop, laptop, tablet, etc.), a media computer platform (such as, but not limited to, a cable or satellite set-top box, digital video recorder), a handheld computer device (such as, but not limited to, a PDA (personal digital assistant), email client, etc.), a wearable device (such as a glasses-type device, a watch-type device, etc.), a VR (Virtual Reality) terminal, a smart speaker (a device for voice recognition), or other types of computers or communication platforms. The terminal 20 may also be expressed as an information processing terminal.

[0054] The configurations of the terminals 20A, 20B, and 20C can be the same as one another, for example and not for limitation. In addition, if necessary, the terminal used by the user X may be expressed as the terminal 20X, and the user information in a predetermined service associated with the user X or the terminal 20X may or may not be expressed as the user information X. The user information is information of a user associated with an account used by the user in a specific service. The user information includes, but is not limited to, information associated with a user, such as the user's name, the user's icon image, the user's age, the user's sex, the user's address, the user's hobbies and interests, and the user's identifier, which is input by the user or given by a specific service, and may be any one of these, or a combination of these, or may not be the same.

[0055] The network 30 plays a role of connecting one or more terminals 20 and one or more servers 10. In other words, the network 30 refers to a communication network that provides a connection path so that the above-mentioned various devices can be connected and then transmit and receive data.

[0056] One or more portions of network 30 may or may not be wired or wireless networks. Network 30 may include, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular network, integrated service digital networks (ISDN), wireless LAN, long term evolution (LTE), code division multiple access (CDMA), Bluetooth, satellite communications, or the like, or a combination of two or more thereof. Network 30 may include one or more networks 30.

[0057] The server 10 (not limited to, but an example of a server, information processing device, or information management device) has a function of providing a predetermined service (messaging service in this embodiment) to the terminal 20. The server 10 may be any device as long as it is an information processing device that can realize the functions described in each embodiment. The server 10 includes, not limited to, a server device, a computer (not limited to, but an example of, a desktop, a laptop, a tablet, etc.), a media computer platform (not limited to, but an example of, a cable, a satellite set-top box, a digital video recorder), a handheld computer device (not limited to, but an example of, a PDA, an email client, etc.), or other types of computers or communication platforms. The server 10 may also be expressed as an information processing device. When it is not necessary to distinguish between the server 10 and the terminal 20, the server 10 and the terminal 20 may or may not be expressed as information processing devices.

[0058] [Hardware (HW) configuration of each device] The hardware configuration of each device included in the communication system 1A will be described.

[0059] (1) Terminal hardware configuration FIG. 1-1 shows an example of the hardware configuration of the terminal 20. In FIG. The terminal 20 includes a control unit 21 (CPU: central processing unit), a storage unit 28, a communication I / F 22 (interface), an input / output unit 23, a clock unit 29A, and a position calculation information detection unit 29B. The HW components of the terminal 20 are connected to each other via a bus B, for example and not for limitation. It is not essential that the HW configuration of the terminal 20 includes all of the components. For example and not for limitation, the terminal 20 may or may not be configured such that individual components or multiple components are removable.

[0060] The communication I / F 22 transmits and receives various data via the network 30. The communication may be performed either wired or wirelessly, and any communication protocol may be used as long as the communication between the two devices is possible. The communication I / F 22 has a function of communicating with various devices such as the server 10 via the network 30. The communication I / F 22 transmits various data to various devices such as the server 10 according to instructions from the control unit 21. The communication I / F 22 also receives various data transmitted from various devices such as the server 10 and transmits it to the control unit 21. The communication I / F 22 may also be simply referred to as a communication unit. When the communication I / F 22 is configured with a physically structured circuit, it may also be referred to as a communication circuit.

[0061] The input / output unit 23 includes a device for inputting various operations to the terminal 20, a device for outputting processing results processed by the terminal 20, etc. The input / output unit 23 may be an integrated input unit and an output unit, or may be separate from the input unit and the output unit, or may not be.

[0062] The input unit is realized by any one or a combination of all kinds of devices that can receive input from a user and transmit information related to the input to the control unit 21. Examples of the input unit include, but are not limited to, a touch panel, a touch display, hardware keys such as a keyboard, a pointing device such as a mouse, a camera (operation input via moving images), and a microphone (operation input by voice).

[0063] The output unit is realized by any one or a combination of all kinds of devices capable of outputting the processing results processed by the control unit 21. Examples of the output unit include, but are not limited to, a touch panel, a touch display, a speaker (audio output), a lens (for example, but not limited to, 3D (three dimensions) output and hologram output), a printer, etc.

[0064] By way of example only, the input / output unit 23 includes, by way of example and not limitation, a display unit 24, a sound input unit 25, a sound output unit 26, and an imaging unit 27.

[0065] The display unit 24 is realized by any one of all kinds of devices capable of displaying according to the display data written in the frame buffer, or a combination thereof. The display unit 24 includes, by way of example and not limitation, a touch panel, a touch display, a monitor (by way of example and not limitation, a liquid crystal display or an organic electroluminescence display (OLED)), a head mounted display (HDM), a projection mapping, a hologram, a device capable of displaying images, text information, and the like in air (which may or may not be a vacuum). Note that these display units 24 may or may not be capable of displaying display data in 3D.

[0066] The sound input unit 25 is used to input sound data (including voice data; the same applies below). The sound input unit 25 includes a microphone and the like. The sound output unit 26 is used to output sound data and includes a speaker and the like. The imaging unit 27 is used to obtain image data (including still image data and moving image data; the same applies below.) The imaging unit 27 includes a camera and the like.

[0067] When the input / output unit 23 is a touch panel, the input / output unit 23 and the display unit 24 may be disposed facing each other and have approximately the same size and shape.

[0068] The clock unit 29A is a built-in clock of the terminal 20, and outputs time information (timekeeping information). The clock unit 29A is configured to include, for example and not limitation, a clock using a crystal oscillator. The clock unit 29A can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.

[0069] The clock unit 29A may or may not have a clock that conforms to the Network Identity and Time Zone (NITZ) standard or the like.

[0070] The position calculation information detection unit 29B is a functional unit that detects (measures) information (hereinafter referred to as "position calculation information") necessary for the control unit 21 to calculate (measure) the position of its own terminal 20. The position calculation information detection unit 29B can also be expressed as a position calculation sensor unit, for example and not by way of limitation.

[0071] The position calculation information detection unit 29B includes, by way of example and not limitation, a satellite positioning sensor (satellite positioning unit) which is a sensor or unit for calculating the position of the terminal 20 using a satellite positioning system such as GPS (Global Positioning System), an inertial measurement sensor (inertial measurement unit (IMU (Inertial Measurement Unit))) which is a sensor or unit for calculating the position of the terminal 20 using an inertial navigation system, a UWB positioning sensor (UWB positioning unit) which is a sensor or unit for calculating the position of the terminal 20 using UWB (Ultra Wide Band), and the like.

[0072] The satellite positioning unit includes, by way of example and not limitation, an RF receiving circuit that converts RF (Radio Frequency) signals, including positioning satellite signals transmitted from positioning satellites and received by an antenna (not shown), into digital signals, and a baseband processing circuit that performs correlation calculation processing or the like on the digital signals output from the RF receiving circuit to capture the positioning satellite signals, and outputs information such as satellite orbit data and time data extracted from the positioning satellite signals as information for position calculation.

[0073] The inertial measurement unit has an inertial sensor that is a sensor that detects information required for calculating the position of the terminal 20 by inertial navigation calculation. The inertial sensor includes, but is not limited to, a three-axis acceleration sensor and a three-axis gyro sensor, and outputs the acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor as information for position calculation.

[0074] The UWB positioning unit includes, by way of example and not limitation, an ultra-wideband RF receiving circuit that converts an ultra-wideband RF (Radio Frequency) signal, including an ultra-wideband pulse signal for positioning transmitted from a positioning beacon and received by an antenna not shown, into a digital signal, and a relative position calculation processing circuit that calculates the relative position between the terminal 20 and the positioning beacon based on the digital signal output from the ultra-wideband RF receiving circuit. As an example and not by way of limitation, the UWB positioning unit may or may not cause the terminal 20 to function as a positioning beacon by transmitting an ultra-wideband RF signal including an ultra-wideband pulse signal for positioning from an antenna not shown.

[0075] As an example and not a limitation, the control unit 21 calculates the position of its own terminal 20 at regular timing or specific timing based on the position calculation information detected by the position calculation information detection unit 29B. The terminal position is referred to as the "terminal position", and the calculated terminal position is referred to as the "calculated terminal position". The control unit 21 may, but may not, associate the calculated terminal position with the date and time when the calculated terminal position is calculated and store it in the storage unit 28 as calculated terminal position history data.

[0076] The control unit 21 has a circuit physically structured to execute the functions realized by the code or instructions contained in the program, and is realized by a data processing device built into hardware, for example and not by way of limitation. Therefore, the control unit 21 may or may not be expressed as a control circuit.

[0077] The control unit 21 includes, by way of example and not limitation, a central processing unit (CPU), a microprocessor, a processor core, a multiprocessor, an application-specific integrated circuit (ASIC), and a field programmable gate array (FPGA).

[0078] The storage unit 28 has a function of storing various programs and various data required for the operation of the terminal 20. The storage unit 28 includes, by way of example and not limitation, various storage media such as a hard disk drive (HDD), a solid state drive (SSD), a flash memory, a random access memory (RAM), and a read only memory (ROM). In addition, the storage unit 28 may or may not be expressed as a memory.

[0079] Terminal 20 stores program P in storage unit 28, and executes this program P, causing control unit 21 to execute processing as each unit included in control unit 21. In other words, program P stored in storage unit 28 causes terminal 20 to realize each function executed by control unit 21. Also, this program P may or may not be expressed as a program module.

[0080] (2) Server hardware configuration FIG. 1-1 shows an example of the HW configuration of the server 10. In FIG. The server 10 includes a control unit 11 (CPU), a storage unit 15, a communication I / F 14 (interface), an input / output unit 12, and a clock unit 19. The components of the HW of the server 10 are connected to each other via a bus B, for example and not for limitation. It is not essential that the HW of the server 10 includes all the components as the configuration of the HW of the server 10. For example and not for limitation, the HW of the server 10 may or may not be configured such that individual components or multiple components are removable.

[0081] The control unit 11 has circuits physically structured to execute functions realized by codes or instructions contained in a program, and is realized, for example and not by way of limitation, by a data processing device embedded in hardware.

[0082] The control unit 11 is typically a central processing unit (CPU), but may also be a microprocessor, a processor core, a multiprocessor, an ASIC, or an FPGA, but is not limited to these in the present disclosure.

[0083] The storage unit 15 has a function of storing various programs and various data required for the operation of the server 10. The storage unit 15 is realized by various storage media such as an HDD, an SSD, and a flash memory. However, in the present disclosure, the storage unit 15 is not limited to these. Furthermore, the storage unit 15 may or may not be expressed as a memory.

[0084] The communication I / F 14 transmits and receives various data via the network 30. The communication may be performed either wired or wirelessly, and any communication protocol may be used as long as the communication between the two devices is possible. The communication I / F 14 has a function of communicating with various devices such as the terminal 20 via the network 30. The communication I / F 14 transmits various data to various devices such as the terminal 20 according to instructions from the control unit 11. The communication I / F 14 also receives various data transmitted from various devices such as the terminal 20 and transmits it to the control unit 11. The communication I / F 14 may also be simply referred to as a communication unit. When the communication I / F 14 is configured with a physically structured circuit, it may also be referred to as a communication circuit.

[0085] The input / output unit 12 includes a device for inputting various operations to the server 10, a device for outputting the results of processing by the server 10, etc. The input / output unit 12 may be an integrated input unit and an output unit, or may be separate input unit and output unit, or may not be the same.

[0086] The input unit is realized by any one or a combination of all kinds of devices capable of receiving input from a user and transmitting information related to the input to the control unit 11. The input unit is typically realized by hardware keys such as a keyboard or a pointing device such as a mouse. Note that the input unit may or may not include a touch panel, a camera (operation input via moving images), or a microphone (operation input by voice), as examples and without limitation.

[0087] The output unit is realized by any one or a combination of all kinds of devices capable of outputting the processing results processed by the control unit 11. Examples of the output unit include, but are not limited to, a touch panel, a touch display, a speaker (sound output), a lens (for example, but not limited to, 3D (three dimensions) output and hologram output), a printer, etc.

[0088] By way of example only, the input / output unit 12 includes a display unit 13, by way of example and not by way of limitation.

[0089] The display unit 13 is realized by a display or the like. The display is typically realized by a monitor (for example, but not limited to, a liquid crystal display or an organic electroluminescence display (OLED)). The display may or may not be a head mounted display (HDM) or the like. These displays may or may not be capable of displaying display data in 3D. In the present disclosure, the display is not limited to these.

[0090] The clock unit 19 is a built-in clock of the server 10, and outputs time information (timekeeping information). The clock unit 19 is configured to include, for example and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, etc. The clock unit 19 can also be expressed as a timekeeping unit or a time information detection unit, for example and not limitation.

[0091] (3)Other The server 10 stores a program P in the storage unit 15, and by executing this program P, the control unit 11 executes the processes of each unit included in the control unit 11. In other words, the program P stored in the storage unit 15 causes the server 10 to realize each function executed by the control unit 11. This program P may or may not be expressed as a program module. The same applies to other devices.

[0092] In each embodiment of the present disclosure, the description will be given assuming that the CPU of the terminal 20 and / or the server 10 executes the program P to realize the present invention.

[0093] The control unit 21 of the terminal 20 and / or the control unit 11 of the server 10 may or may not realize each process by a CPU having a control circuit, but may also realize each process by a logic circuit (hardware) formed in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or a dedicated circuit. These circuits may or may not be realized by one or more integrated circuits, and the multiple processes shown in each embodiment may or may not be realized by one integrated circuit. Furthermore, an LSI may be called a VLSI, a super LSI, an ultra LSI, or the like, depending on the degree of integration. Therefore, the control unit 21 may or may not be expressed as a control circuit.

[0094] In addition, the program P (as an example, but not limited to, a software program, a computer program, or a program module) of each embodiment of the present disclosure may or may not be provided in a state stored in a computer-readable storage medium. The storage medium can store the program P in a "non-transitory tangible medium." In addition, the program P may or may not be for realizing part of the functions of each embodiment of the present disclosure. Furthermore, the program P may or may not be a so-called difference file (difference program) that can realize the functions of each embodiment of the present disclosure in combination with a program P already recorded in a storage medium.

[0095] The storage medium may include one or more semiconductor-based or other integrated circuits (ICs) (such as, by way of example and not limitation, a field programmable gate array (FPGA) or an application specific IC (ASIC)), a hard disk drive (HDD), a hybrid hard drive (HHD), an optical disk, an optical disk drive (ODD), a magneto-optical disk, a magneto-optical drive, a floppy diskette, a floppy disk drive (FDD), a magnetic tape, a solid state drive (SSD), a RAM drive, a secure digital card, or a drive, any other suitable storage medium, or a suitable combination of two or more of these. The storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate. It should be noted that the storage medium is not limited to these examples and may be any device or medium capable of storing the program P. In addition, the storage medium may or may not be referred to as a memory.

[0096] The server 10 and / or the terminal 20 can realize the functions of the multiple functional units shown in each embodiment by reading out the program P stored in a storage medium and executing the read out program P.

[0097] Furthermore, the program P of the present disclosure may or may not be provided to the server 10 and / or the terminal 20 via any transmission medium capable of transmitting a program (such as a communication network or broadcast waves). The server 10 and / or the terminal 20 executes the program P downloaded via the Internet or the like, for example and not for limitation, to realize the functions of the multiple functional units shown in each embodiment.

[0098] In addition, each embodiment of the present disclosure may also be realized in the form of a data signal in which the program P is embodied by electronic transmission. At least a part of the processing in the server 10 and / or the terminal 20 may or may not be realized by cloud computing configured with one or more computers. At least a part or all of the processing in the terminal 20 may or may not be performed by the server 10. In this case, at least a part or all of the processing of each functional unit of the control unit 21 of the terminal 20 may or may not be performed by the server 10. At least a part or all of the processing in the server 10 may or may not be performed by the terminal 20. In this case, at least a part or all of the processing of each functional unit of the control unit 11 of the server 10 may or may not be performed by the terminal 20.

[0099] Unless explicitly stated, the judgment configuration in the embodiments of the present disclosure is not essential, and a specified process may or may not be executed when the judgment condition is satisfied, or a specified process may or may not be executed when the judgment condition is not satisfied.

[0100] Note that the programs of the present disclosure are implemented using, by way of example and not limitation, scripting languages ​​such as ActionScript and JavaScript (registered trademark), compiler languages ​​such as Objective-C and Java (registered trademark), and markup languages ​​such as HTML Living Standard.

[0101] [Functional configuration of each device] (1) Server FIG. 1-2 is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment. The control unit 11 includes, as a functional unit, an application management processing unit 111 for executing application processing according to an application management processing program 151 stored in the storage unit 15, for example and not for limitation.

[0102] FIG. 1-3 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment. The storage unit 15 stores, by way of example and not limitation, an application management processing program 151, general account registration data 153, a general account management database 154, a player management database 156, and a monster generation table 157.

[0103] The application management processing program 151 is executed by the control unit 11 as application management processing. Note that, for simplicity, a single application management processing program 151 is illustrated here, but it may include a program executed as management processing for a messaging application and a program executed as management processing for a game application.

[0104] The general account registration data 153 is, by way of example and not by way of limitation, registration data relating to a general account of a messaging application, an example of which data configuration is shown in FIG. 1-4. In the general account registration data 153, for example and not for limitation, a general user name, a general messaging application ID (hereinafter referred to as a "general MAID"), and other registration information are stored in association with each other.

[0105] The general user name is the name of the general account of the terminal 20 that uses the messaging application, and by way of example and not limitation, the name that the user of the terminal 20 registers when using the messaging application is stored.

[0106] A general MAID is information used to identify a messaging application account, or the account itself. This general MAID is preferably a value unique to each account, and as a non-limiting example, a unique value (proper value) is set and stored by the server 10 for each account. The general MAID is information associated with the terminal 20 or the user of the terminal 20, and is an example of information about the terminal or information about the user of the terminal.

[0107] Other registration information may include, by way of example and not limitation, various types of information such as identification information for identifying terminal 20, contact information such as the telephone number and email address of terminal 20, authentication information such as passwords (login password, authentication password, etc.) used for various authentications in applications, and an icon image of the general user registered in the messaging application (hereinafter referred to as a "general user icon image").

[0108] The identification information for identifying the terminal 20 may be, for example and not for limitation, a terminal ID (for example and not for limitation, an International Mobile Equipment Identity (IMEI)).

[0109] The general MAID can be an example of identification information for identifying the user of the terminal 20. The general MAID may or may not be replaced by a "general user ID." Furthermore, contact information may also be an example of identification information for identifying a user of the terminal 20.

[0110] Furthermore, if the application allows only one account to be registered per terminal 20, then as a non-limiting example, "identification information for identifying terminal 20 = identification information for identifying the user of terminal 20 = general MAID" may be used.

[0111] Also, by way of example and not limitation, it may or may not be possible to assign multiple terminal IDs to one general MAID.

[0112] Also, instead of various IDs such as a general MAID, it is possible to apply a method of managing accounts using contact information such as a telephone number. In this case, instead of storing ID information such as a general MAID in the general account registration data 153, contact information such as a telephone number may be stored in the general account registration data 153.

[0113] The general account management database 154 is, by way of example and not limitation, a database for managing information on general users of each general MAID stored in the general account registration data 153.

[0114] In the general account management database 154, general account management data can be stored as management data for each general MAID, for example and not by way of limitation. Each general account management data may store, by way of example and not limitation, friend registration data that stores the general MAIDs of general users that a general user of that general MAID has registered as friends in a messaging application, and data such as talk history data in a messaging application.

[0115] The player management database 156 is, by way of example and not limitation, a database for managing information on general users who are registered as players of the game in this embodiment.

[0116] In this player management database 156, as a non-limiting example, player management data can be stored as management data for each player ID set by the server 10 for a general user registered as a player. Each player management data may include, by way of example and not limitation, data such as a player name and password, game save data, and game play history data, which are optionally registered by the player.

[0117] The save data may include, by way of example and not limitation, information on whether the player owns any monsters, information on the monsters that the player owns, and parameter values ​​such as ability values ​​of the monsters that the player owns.

[0118] The play history data may include, by way of example and not limitation, information such as the player's history of monster creation, the history of raising monsters owned, and the history of battles (combat) between monsters.

[0119] The general MAID may be used as a player ID to manage the player's game data.

[0120] Monster generation table 157 is a table used for generating monsters for the game, and an example of the table configuration of monster generation table 157A is shown in FIG. 1-5. Here, a relatively simple method for generating a monster is illustrated, but the present invention is not limited to this. Also, the following description assumes that at least the last digit of a general MAID is a number, but the present invention is not limited to this.

[0121] In the monster generation table 157A, as a non-limiting example, the last digit of the MAID, the monster type, and the monster appearance characteristics are defined in association with each other.

[0122] The last digit of the MAID is set to a numerical range that includes the last digit of the MAID from which the monster is generated, in this example.

[0123] The monster type is set to the type of monster that will be generated based on the last digit of the corresponding MAID.

[0124] The monster appearance characteristics are set to the appearance characteristics of the monster of the corresponding monster type.

[0125] Specifically, in this table, the last digit of the MAID is set to a numerical range of "0 to 3," "4 to 6," and "7 to 9," by way of example and not limitation. The last digit "0~3" represents the monster type "MA (Monster A)" and the monster appearance characteristic "Cool". The last digit "4~6" is set as the monster type "MB (Monster B)" and the monster appearance characteristic is "Scary". The last digits "7~9" are set as the monster type "MC (Monster C)" and the monster appearance characteristic "cute".

[0126] The control unit 11 of the server 10 specifies, by way of example and not limitation, the last digit of the general MAID based on the general MAID included in the general MAID monster generation request information received from the player's terminal 20. Then, by way of example and not limitation, a monster of the monster type associated with the specified digit and having the monster appearance characteristic associated with the specified digit is generated by a monster generation program.

[0127] In addition to the appearance characteristics of the monsters, information on the color of the monsters may be set in the same manner to generate monsters of different colors. Also, information on the ability values ​​(parameter values) of the monsters, which will be described later, may be set in the same manner to generate monsters of different ability values. Even if the monsters are of the same monster type, they may be generated with different appearance characteristics, colors, ability values, and the like.

[0128] Furthermore, instead of generating a monster based on the last digit of the MAID, a monster may be generated based on a set number of digits either above or below the MAID. Furthermore, instead of being limited to numbers, alphabets may be used in the MAID, and similar processing may be performed based on the alphabets contained in the MAID.

[0129] The above monster generation table 157A may or may not be applied to the official messaging application ID (hereinafter referred to as the "official MAID") when generating a monster based on the official account described in the second embodiment.

[0130] (2) Terminal FIG. 1-6 is a diagram showing an example of functions realized by a control unit 21 of a terminal 20 in this embodiment. The control unit 21 includes, as a functional unit, an application processing unit 211 for executing game application processing according to an application processing program 281 stored in the storage unit 28, for example and not for limitation.

[0131] FIG. 1-7 is a diagram showing an example of information stored in the storage unit 28 of the terminal 20 in this embodiment. In the storage unit 28, for example and not for limitation, an application processing program 281 executed as game application processing, and a general MAID 283 of the user's own terminal 20 or the user's own terminal 20 are stored.

[0132] It should be noted that the general MAID 283 may or may not be able to store a plurality of general MAIDs.

[0133] <Game Description / Game Application> Here, the game in the game application of this specification will be described. This game is primarily composed of the elements shown in (1) to (3) below, by way of example and not limitation. (1) Generate in-game content (2) Developing in-game content (3) Battles using in-game content

[0134] In-game content is content used within a game, and may include, by way of example and not limitation, objects that appear in the game. In this embodiment, a monster is used as an example of an object, by way of example and not limitation. Basically, the object can include anything that appears in the game, and can include anything that appears in the game other than monsters. Specific examples of this will be described later.

[0135] The game in this specification is, by way of example and not by way of limitation, a game in which a player generates a monster, which is a type of in-game content (object), and trains the generated monster to engage in battle. It should be noted that a user who plays a game using a game application may be referred to as a "player."

[0136] (1) Spawning monsters In this game, monsters are generated based on the general MAID of general users who are playing the game (and have linked their accounts in the game application) and who have general accounts and are registered as friends in the messaging application (see Figures 1-12 and 1-8).

[0137] It is also possible to generate a monster based on the official MAID of an official user of an official account that is registered as a friend in the messaging application, which will be described in a second embodiment.

[0138] (2) Raise monsters In this game, parameter values ​​(hereinafter referred to as "ability values") are set for each generated monster (see Figure 1-9). Specifically, as non-limiting examples of parameter values, "stamina" indicates the monster's physical strength (HP), "strength" indicates the monster's attacking power, "protection" indicates the monster's defensive power, and "speed" indicates the monster's speed.

[0139] Moreover, by training the monsters, the parameter values ​​of these monsters can be increased. Specifically, a training menu (hereinafter referred to as "training") for increasing each parameter value is provided, and "stamina UP training" for increasing stamina, "strength UP training" for increasing strength (attack power), "protection UP training" for increasing defense (defense power), and "speed UP training" for increasing speed (quickness) are provided. The player can increase the parameter values ​​of the monsters by training the monsters as desired.

[0140] In addition, the training in this game has, as examples and not limitations, a success pattern in which the training is successful and a failure pattern in which the training is unsuccessful. A training in a success pattern is a training in which the training is successful and the parameter values ​​corresponding to the training increase. A training in a failure pattern is a training in which the training fails and none of the parameter values ​​increase.

[0141] As a non-limiting example, whether the training will be a successful pattern or a failed pattern (hereinafter referred to as "training success or failure") is determined by lottery at the time when it is decided to carry out the training. However, the timing is not limited to this, and the success or failure of the training may be determined at other timings. As a non-limiting example, a player-participation type (requiring player operation) mini-game may be included during the training performance, and the success or failure of the training may be determined according to the result of the mini-game at the end of the mini-game.

[0142] In addition, in this game, the player can improve the effect of training by using support cards when training the monster. Specifically, there are support cards such as support cards that increase the probability of training being successful and support cards that increase the increase in parameter values ​​that increase when training is successful, and the effect of training can be further improved by using one or more of these support cards to train the monster.

[0143] By way of example and not limitation, this support card may be one that can be purchased using currency that can only be used within the game (hereinafter referred to as "in-game currency"), one that can be acquired based on the user's general MAID, etc., in the same way as when generating monsters, or one that can be acquired as a prize when winning a battle, as described below.

[0144] (3) Monster battles In this game, it is possible to have a battle between the monster you have raised (hereinafter referred to as "your monster" or "my monster") and another user's monster (hereinafter referred to as "enemy monster"). In this game, if your monster wins a battle against an enemy monster, a victory performance is executed (see Figure 1-10(4A)), and if your monster loses a battle against an enemy monster, a defeat performance is executed (see Figure 1-10(4B)).

[0145] For example and not by way of limitation, in a battle, the outcome may be determined based on the parameter values ​​of the monsters, or the battle may progress as the player controls the monster, and the outcome may be determined. In addition, when a battle is won, in-game value may be awarded, for example and not by way of limitation. Examples of in-game value include parameter values, in-game currency, support cards, and objects related to other monsters (for example and not by way of limitation, other monsters themselves, and eggs from which other monsters will be hatched in the future).

[0146] In this game, one player can own multiple monsters. In this case, one of the monsters owned by the player that is displayed on the home screen described below is called the "main monster," and one of the monsters owned by the player that is not displayed on the home screen and is different from the main monster is called a "sub-monster." As a non-limiting example, the main monster can be switched to another monster on the home screen or battle screen.

[0147] The elements (1) to (3) listed above are only a part of the elements that make up this game, and elements other than the elements (1) to (3) listed above may also make up this game. By way of example and not limitation, elements of the Game include: - Display of settings-related information (notifications, menus (volume, BGM, language settings, etc.), player information) -Lotteries that give out in-game content (gacha, etc.) Mini-games other than battles that use in-game content (quests, etc.) may be provided.

[0148] <Display screen> An example of a display screen in this embodiment will be described below. First, an example will be given of a case in which a monster is generated from a general user's friends in a game application.

[0149] In the following, as an example and not a limitation, a case will be illustrated in which the terminal 20A is positioned so that the display unit 24 of the display provided in the terminal 20A has a landscape display screen.

[0150] The transition of the display screens described below is merely an example of the transition of the display screens for realizing the method of the present disclosure. In the transition of the display screens illustrated below, some of the display screens may be omitted, or other display screens may be added.

[0151] 1-8 is a diagram showing an example of a screen of a game application displayed on the display unit 24 of the terminal 20A in this embodiment. Here, a screen (home screen, generated screen) displayed on the display unit 24 of the terminal 20A of the user AA is shown as an example.

[0152] FIG. 1-8(1) is the home screen of a game application, and the words "Game App" are displayed in the top left corner of the screen as the name of the game application. Also, in this example, to the left of the words "Game App" is an icon containing the words "MS (Messaging Service)," indicating that this game is related to a messaging service (messaging application).

[0153] Also displayed on the top right of the screen are a home button HBT for returning to the home screen in the game application, a notification button NBT for checking notifications in the game application, a menu button MBT for displaying a menu in the game application, and an icon image for the game application of the user of this terminal 20A (in this example, "User AA").

[0154] Below that is an area showing the page currently being displayed within the game application (hereinafter referred to as the "in-app position display area"), and as this screen is the home screen, it displays "Home."

[0155] Below that, a game information display area is configured in which various information in the game application (hereinafter referred to as "game information") is displayed. Here, the game information is, by way of example and not limitation, information related to a home screen, a generation screen, a training screen, and a battle screen (monsters, ability value information, various buttons, etc., by way of example and not limitation) described below. In this example, the game information display area displays a monster (in this example, Monster A), parameter value information related to the parameter value of this monster (in this example, the name of the monster is "Monster A", and each ability value is "Stamina|50", "Strength|40", "Protection|30", and "Speed|40"), a monster change button CBT for switching the monster (main monster) displayed on the home screen, a training button TBT for training the monster, a battle button BBT for battling the monster, and a generation button GBT for generating a monster.

[0156] For example and not for limitation, when the generate button GBT is touched by the user as shown in FIG. 1-8(1), a display as shown in FIG. 1-8(2) is displayed as an example and not for limitation. This screen is the first of the generation screens for generating monsters, and the words "Generation Stage" are displayed in the in-app position display area.

[0157] Below that is a generation information display area in which information regarding monster generation is displayed. In this example, 1A generation confirmation information (as an example, and not as a limitation, the text "Do you want to generate a monster from your friend?") is displayed, along with a YES button BT1 (in this example, a button containing the text "YES") for answering [YES] to the above information, and a NO button BT2 (in this example, a button containing the text "NO") for answering [NO] to the above information.

[0158] As a non-limiting example, when the YES button BT1 is touched by the user as in FIG. 1-8(2), a display as in FIG. 1-8(3) is displayed as a non-limiting example. This screen is the second generation screen among the generation screens for generating monsters, and the words "Generation Stage" are continuously displayed in the in-app position display area.

[0159] In this example, the generated information display area is configured to display a “friends list” that lists information about friends of user AA of this terminal 20A (accounts registered as friends of user AA's account) in the messaging service (messaging application). On this screen, the friend list items are displayed in a list, such as an icon and user name corresponding to user BB, an icon and user name corresponding to user CC, etc. Also, to the right of each of these friend list items, a generation execution button MGBT (in this example, a button containing the words "Monster Generation") is displayed for generating a monster using the friend corresponding to that friend list item.

[0160] As a non-limiting example, when the generation execution button MGBT is touched by the user as shown in FIG. 1-8(3), a display as shown in FIG. 1-8(4) is displayed as a non-limiting example. On this screen, a generation confirmation area MGR for confirming whether or not to generate a monster is displayed superimposed on the second generation screen of FIG. 1-8(3).

[0161] The generation confirmation area MGR displays 2A generation confirmation information (in this example, the text "Do you want to generate a monster from BB?"), a YES button BT1 for answering [YES] to the above information, and a NO button BT2 for answering [NO] to the above information.

[0162] As a non-limiting example, when the YES button BT1 is touched by the user as in FIG. 1-8(4), a display as in FIG. 1-8(5) is displayed as a non-limiting example. This screen is the third generation screen among the generation screens for generating monsters, and the words "Generation Stage" are continuously displayed in the in-app position display area.

[0163] On this screen, an effect is executed in which a monster is generated from the friend selected on the second generation screen (hereinafter referred to as a "generation effect"). Specifically, when the generation performance is executed, generation effect information (in this example, a smoke-type effect image) is displayed in the center of the screen. By displaying this generation effect information, the user can anticipate which monster will be generated.

[0164] By way of example and not limitation, when the generation presentation is completed, a display such as that shown in FIG. 1-8(6) may be displayed. This screen is the fourth generation screen among the generation screens for generating monsters, and the words "Generation Stage" are continuously displayed in the in-app position display area.

[0165] The game information display area displays game information (as an example and not a limitation, information about a newly generated monster (in this example, Monster B), and parameter value information of this monster (in this example, the monster's name is "Monster B", and each ability value is "Stamina|10", "Strength|10", "Defense|20", and "Speed|5").

[0166] In this way, monsters can be generated from friends selected by the player, allowing various types of monsters to be generated, and by associating friends in the messaging application with monsters, the interest of the game, which has gameplay involving monsters, can be enhanced.

[0167] Next, an example of raising a monster in a game application will be described.

[0168] 1-9 is a diagram showing an example of a screen of a game application displayed on the display unit 24 of the terminal 20A in this embodiment. Here, the screen (home screen, training screen) displayed on the display unit 24 of the terminal 20A of the user AA is shown as an example.

[0169] The display screen in FIG. 1-9(1) is similar to that in FIG. 1-8(1) described above, and therefore the description thereof will be omitted.

[0170] As a non-limiting example, when the training button TBT is touched by the user as shown in FIG. 1-9(1), a display as shown in FIG. 1-9(2) is displayed as a non-limiting example. This screen is the first of several screens for raising monsters, and the words "Raising Stage" are displayed in the in-app position display area.

[0171] Below that is a breeding information display area in which information regarding the breeding of monsters is displayed. In this example, the training information display area displays the first training information (as an example and not as a limitation, the text "Which training would you like?", a first training icon corresponding to stamina UP training (in this example, an icon containing the text "Stamina UP"), a second training icon corresponding to strength UP training (in this example, an icon containing the text "Strength UP"), a third training icon corresponding to protection UP training (in this example, an icon containing the text "Protection UP"), a fourth training icon corresponding to speed UP training (in this example, an icon containing the text "Speed ​​UP"), a rest icon for letting the monster rest without doing any training (in this example, an icon containing the text "Rest"), and an icon for stopping training the monster (in this example, an icon containing the text "Stop Training")).

[0172] For example and not for limitation, when the first training icon TIC1 is touched by the user as shown in FIG. 1-9(2), a display as shown in FIG. 1-9(3) is displayed as an example and not for limitation. This screen is the second training screen among the training screens for training monsters, and the words "Training Stage" are continuously displayed in the in-app position display area.

[0173] In this example, the training information display area displays second training information (by way of example and not limitation, information corresponding to the training content selected by the user on the first training screen (in this example, the text "<Stamina UP training>"), the text "Which support card would you like to use?", support card information (in this example, images of support cards such as support card SC1 containing the text "Success rate UP" and support card SC2 containing the text "Increase in gain value UP"), and information for training without using any support card (in this example, an icon containing the text "Do not use support card")).

[0174] For example and not for limitation, when the support card SC1 is touched by a user as in FIG. 1-9(3), a display as in FIG. 1-9(4) is displayed as an example and not for limitation. This screen is the third training screen among the training screens for training monsters, and the words "Training Stage" are continuously displayed in the in-app position display area.

[0175] In this example, the training information display area displays third training information (as an example and not by way of limitation, the words "Do you want to start this training?", information corresponding to the training content and support card selected by the user on the first training screen and second training screen (in this example, the first training icon TIC1 and support card SC1), a YES button BT1 for answering [YES] to the above information, and a NO button BT2 for answering [NO] to the above information).

[0176] As a non-limiting example, when the YES button BT1 is touched by the user as shown in FIG. 1-9(4), a display as shown in FIG. 1-9(5) is displayed as a non-limiting example. This screen is the fourth training screen among the training screens for training monsters, and the words "Training Stage" are continuously displayed in the in-app position display area.

[0177] In this example, the training information display area displays fourth training information (as an example and not a limitation, the words "Start training" and information corresponding to the training content and support card selected by the user on the first training screen and second training screen (in this example, the first training icon TIC1 and support card SC1)).

[0178] As a non-limiting example, when it is time to notify the success or failure of the training, a display such as that shown in FIG. 1-9(6A) or (6B) is displayed, as a non-limiting example. As a non-limiting example, if the pattern is a success pattern, a display like that in FIG. 1-9(6A) is made, and if the pattern is a failure pattern, a display like that in FIG. 1-9(6B) is made.

[0179] (Success pattern) The screen in FIG. 1-9 (6A) is a 5Ath breeding screen among the breeding screens for breeding monsters, and the words "Breeding Stage" are continuously displayed in the in-app position display area. In this example, the training information display area displays 5A training information (as an example and not a limitation, the words "Training successful", Monster A with a happy expression, and information on the increase in parameter value from this training (in this example, the words "Stamina | +3")).

[0180] (Failure pattern) The screen in Figure 1-9 (6B) is the 5Bth training screen among the training screens for training monsters, and the words "Training Stage" are continuously displayed in the in-app position display area. In this example, the training information display area displays the 5B training information (as an example, but not limited to, the words "Training failed" and Monster A with a sad expression).

[0181] Next, an example of battling monsters in a game application will be described.

[0182] 1-10 is a diagram showing an example of a screen of a game application displayed on the display unit 24 of the terminal 20A in this embodiment. Here, a screen (home screen, battle screen) displayed on the display unit 24 of the terminal 20A of the user AA is shown as an example.

[0183] The display screen in FIG. 1-10(1) is similar to that in FIG. 1-8(1) described above, and therefore the description thereof will be omitted.

[0184] As a non-limiting example, when the battle button BBT is touched by the user as shown in FIG. 1-10(1), a display as shown in FIG. 1-10(2) is displayed as shown in FIG. This screen is the first battle screen among the battle screens for battling using monsters, and the words "Battle Stage" are displayed in the in-app position display area.

[0185] Below that is a battle information display area in which information regarding monster battles is displayed. In this example, the battle information display area displays the first battle information (as an example and not a limitation, the text "Do you want to challenge a battle with this monster?", the monster set as the main monster (Monster A in this example), parameter value information (in this example, the monster's name is "Monster A" and the ability values ​​are "Stamina | 50", "Strength | 40", "Defense | 30", and "Speed ​​| 40"), a YES button BT1 for answering [YES] to the above information, and a monster change button CBT).

[0186] As a non-limiting example, when the YES button BT1 is touched by the user as in FIG. 1-10(2), a display as in FIG. 1-10(3) is displayed as a non-limiting example. This screen is the second battle screen among the battle screens for battling using monsters, and the words "Battle Stage" are continuously displayed in the in-app position display area.

[0187] In this example, the battle information display area displays second battle information (as an example and not a limitation, the player's side monster information (in this example, monster A and the name and icon image of user AA), the letters "VS", and the enemy player's side monster information (in this example, monster B and the name and icon image of user BB)).

[0188] As a non-limiting example, when a battle begins and the time comes for the outcome to be announced, a display such as that shown in FIG. 1-10(4A) or (4B) is displayed, as a non-limiting example. As a non-limiting example, if your monster defeats an enemy monster, the display shown in Figure 1-10(4A) will be shown, and if your monster is defeated by an enemy monster, the display shown in Figure 1-10(4B) will be shown.

[0189] (Victory performance) The screen in Figure 1-10 (4A) is a 3A battle screen among the battle screens for battling using monsters, and the words "Battle Stage" are continuously displayed in the in-app position display area. In this example, a victory effect is being executed, and the battle information display area displays the 3A battle information (as a non-limiting example, the word "WIN" and Monster A with a delighted expression).

[0190] (Defeat performance) The screen in Figure 1-10 (4B) is the 3B battle screen among the battle screens for battling using monsters, and the words "Battle Stage" are continuously displayed in the in-app position display area. In this example, a defeat effect is being executed, and the battle information display area displays the third B battle information (as an example, but not limited to, the word "LOSE" and Monster A with a disappointed expression).

[0191] <Processing> 1-11 and 1-12 are flowcharts showing an example of the flow of processes executed by each device in this embodiment. In this figure, from the left, an example of a process executed by the control unit 21 of the terminal 20A (terminal 20 of a general user AA) and an example of a process executed by the control unit 11 of the server 10 are shown.

[0192] Note that this process is merely an example of a process for implementing the method of the present disclosure, and is not limited to this process. Another step may be added to this process, or some steps may be omitted (deleted) from this process. This also applies to each of the flowcharts (processes) described below.

[0193] First, control unit 21 of terminal 20A launches a game application based on, for example and not limitation, a user's input to input / output unit 23 of terminal 20A (hereinafter referred to as "user input." For example and not limitation, this includes input by operation, input by sound, input by vibration, etc. The same applies below.) Then, it is determined whether the launch is the first launch of the game application (A110).

[0194] If it is determined that this is the first startup (A110: YES), the control unit 21 of the terminal 20A sends account linking request information including, by way of example and not limitation, the general MAID 283 stored in the memory unit 28 to the server 10 via the communication I / F 22 (A120).

[0195] On the other hand, if it is determined that this is not the first startup (A110: NO), the control unit 21 of the terminal 20A skips step A120 and advances the process to step A130.

[0196] When the account linking request information is received from the terminal 20A via the communication I / F 14, the control unit 11 of the server 10 performs an account linking process (S110). Specifically, by way of example and not limitation, the control unit 11 generates an ID for a game (hereinafter referred to as a "game ID") corresponding to the general MAID 283 (in this example, the general MAID of user AA) included in the received account linking request information. Although details will be described later, it is also possible to choose not to generate a game ID at this point.

[0197] For example and not for limitation, the game ID can be generated from the general MAID as an ID that is unique for each user but cannot identify the individual user (for example and not for limitation, an irreversible ID). For example and not for limitation, the game ID can be generated by hashing the general MAID. Then, the control unit 11 of the server 10 stores the generated game ID (in this example, the game ID of user AA) in association with the general MAID in the general account management data in the general account management database 155, in which the general MAID of user AA is stored, by way of example and not limitation.

[0198] In addition, the control unit 11 of the server 10 generates a random ID as the player ID of user AA, as an example and not as a limitation, generates player management data that associates and stores the player ID (in this example, the player ID of user AA) and the game ID (in this example, the game ID of user AA), and stores the data in the player management database 156 of the memory unit 15.

[0199] Next, the control unit 11 of the server 10 transmits, by way of example and not limitation, account linking information indicating that the account linking has been completed to the terminal 20A via the communication I / F 14 (S120).

[0200] After step A120, when account linking information is received by the communication I / F 22, the control unit 21 of the terminal 20A stores the received account linking information in the storage unit .

[0201] Next, the control unit 21 of the terminal 20A sends friend list request information, which requests a list of information about the general accounts of general users who are registered as friends of the user AA's general MAID, to the server 10 via the communication I / F 22 in the messaging application (A130).

[0202] After step S120, when the communication I / F 14 receives friend list request information from the terminal 20A, the control unit 11 of the server 10 identifies the general MAID of the friend of the user AA based on the friend registration data included in the general account management data in which the general MAID of the user AA is stored, from the general account management database 155 stored in the storage unit 15. Then, the control unit 11 refers to the general account registration data 153 and reads out information such as the general user name and general user icon image stored in association with the general MAID of the identified friend. Then, by way of example and not limitation, the communication I / F 14 transmits friend list information including information such as the friend's general MAID, general user name, and general user icon image to the terminal 20A (S130).

[0203] After step A130, when the friend list information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20A stores the received friend list information in the storage unit .

[0204] Thereafter, game processing is started between the terminal 20A and the server 10 (A140, S140). The game processing described in this specification includes, by way of example and not limitation, processing for realizing the generation of monsters, the raising of monsters, battles between monsters, and the like, as described above. For the sake of convenience, the steps relating to the generation of monsters are illustrated and described in FIG. 1-12 as steps that occur after the game processing has started, but the steps relating to the generation of monsters may also be included in the steps of the game processing (or may be part of the game processing).

[0205] In the game processing, the control unit 11 of the server 10 updates the player management data of this player in the player management database 156 of the storage unit 15 in accordance with the progress of the game.

[0206] After the game processing has started, the control unit 21 of the terminal 20A determines whether or not to generate a monster, for example by determining whether or not a user input for generating a monster has been made via the input / output unit 23 (A150).

[0207] If it is determined that a monster should be generated (A150: YES), the control unit 21 of the terminal 20A reads out from the storage unit 28 the friend list information previously obtained from the server 10 and stored in the storage unit 28. Then, the control unit 21 of the terminal 20A causes the display unit 24 to display the friend list including, by way of example and not limitation, the general user name and general user icon image of each friend, a monster generation button, and the like (A160).

[0208] Next, the control unit 21 of the terminal 20A determines whether or not a user input has been made to select a friend from the displayed list of friends, and so on, to determine whether or not a monster is to be generated based on a general MAID (A170).

[0209] If it is determined that a monster is to be generated based on a general MAID (A170: YES), the control unit 21 of the terminal 20A transmits general MAID monster generation request information, including, by way of example and not limitation, the general MAID of a friend selected by the user AA, to the server 10 via the communication I / F 22 (A180).

[0210] After step S140, when general MAID monster generation request information is received from terminal 20A via communication I / F 14, control unit 11 of server 10 performs general MAID monster generation processing (S180). Specifically, as an example and not a limitation, based on the above-mentioned monster generation table 157A, a monster corresponding to the general MAID (general MAID of a friend selected by user AA) included in the general MAID monster generation request information received from terminal 20A is generated according to a monster generation program. Then, information about the generated monster is stored in player management data in which user AA's player ID is stored.

[0211] Returning to FIG. 1-11, after step S180, the control unit 11 of the server 10 transmits general MAID monster generation result information including information on the monster generated in step S180 to the terminal 20A via the communication I / F 14 (S190).

[0212] After step A180, when general MAID monster generation result information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the general MAID monster generation result information based on the received general MAID monster generation result information (A190).

[0213] Next, the control unit 21 of the terminal 20A determines whether or not to end the processing of the game application (A195). If it is determined that the process should be continued (A195: NO), then, by way of example and not limitation, the control unit 21 of the terminal 20A returns the process to A150. On the other hand, if it is determined that the processing should be ended (A195: YES), the control unit 21 of the terminal 20A ends the game processing being executed, and ends the processing of the game application.

[0214] After step S190, control unit 11 of server 10 determines whether or not to end the management process of the game application (S195). If it is determined that the processing should be continued (S195: NO), the control unit 11 of the server 10 waits to receive general MAID monster generation request information from the terminal 20A, for example and not limitation, and if received, executes the processing of S180 again. On the other hand, if it is determined that the processing should be ended (S195: YES), control unit 11 of server 10 ends the game processing being executed, and ends the management processing of the game application.

[0215] <Regarding game ID> The general MAID used by messaging applications may be considered personal information for some users and may be considered important information for both users and messaging service providers. For this reason, it is necessary to avoid the risk of the general MAID of a messaging application being identified. When generating a monster using a general MAID as described above, there is a risk that a third party may be able to infer the general MAID from the monster by, for example and not by way of limitation, referring to a large number of monsters and deciphering the regularity (generation rules) of monster generation.

[0216] Therefore, as a non-limiting example, the control unit 11 of the server 10 may generate a monster corresponding to the general MAID (the general MAID of the friend selected by user AA) included in the general MAID monster generation request information received from terminal 20A in step S180, based on the game ID corresponding to that general MAID. In this case, as a non-limiting example, a monster can be generated in a similar manner using the "last digit of ID" in the monster generation table 157A shown in Fig. 1-5 as the last digit of the game ID. Specifically, the control unit 11 of the server 10 can generate a game ID from the general MAID (or read out the game ID if it has already been generated), and generate a monster based on the game ID.

[0217] Also, as a non-limiting example, the control unit 11 of the server 10 may transmit the friend list information to the terminal 20A including the friend's game ID instead of the friend's general MAID in step S130. In this case, as an example and not a limitation, the control unit 21 of the terminal 20A may include the game ID corresponding to the friend selected by the user AA in the general MAID monster generation request information and send it to the server 10 in step S130.

[0218] Furthermore, the control unit 11 of the server 10 may be configured not to generate a game ID for each terminal 20 in the account linking process in step S110. A game ID for the friend will also not be generated, but in this case, the control unit 11 of the server 10 may generate a game ID from the general MAID (the general MAID of the friend selected by user AA) included in the general MAID monster generation request information received from the terminal 20A in step S180, and generate a monster based on the generated game ID. In other words, when a monster generation request is made from the terminal 20, the control unit 11 of the server 10 may generate a game ID for the friend and generate a monster.

[0219] Moreover, instead of the game ID, a player ID may be used to carry out the same processing as above.

[0220] <About the friend list> In the above process, the control unit 11 of the server 10 may include information about some of the general accounts in the friend list information and send it to the terminal 20A, rather than information about all of the general accounts registered as friends in the messaging application.

[0221] Not all users with general accounts who are registered as friends in the messaging application necessarily play the game, so it may not be desirable to use the general accounts of users who do not play the game to generate monsters. Therefore, as a non-limiting example, in step S130, the control unit 11 of the server 10 may include information regarding the general accounts of user AA's friends that have completed the account linking process for this game, i.e., only friends that have been registered as players of this game, in the friend list information and send it to terminal 20A.

[0222] Also, as a non-limiting example, the control unit 11 of the server 10 may transmit to the terminal 20 of each general user in a messaging application license confirmation information for confirming whether or not friends registered by the general user consent (agree) to the use of the general user's account in a game application, and may receive a response to the license confirmation information from the terminal 20. Then, as a non-limiting example, in step S130, the control unit 11 of the server 10 may transmit to the terminal 20A information on the general accounts of only those friends of the user AA whose permission response to the use permission is "OK" by including the information on the friends in the friend list information.

[0223] The control unit 11 of the server 10 may also identify friends with whom the user AA of the terminal 20A frequently or frequently exchanges messages in a messaging application. Then, for only the identified friends, information about the general accounts of the friends may be included in the friend list information and transmitted to the terminal 20A.

[0224] In addition, user AA of terminal 20A may be able to pre-select and set friends as candidates for use in generating monsters in a messaging application or game application, and the control unit 11 of server 10 may include information about the general accounts of only the friends set by user AA in the friend list information and send it to terminal 20A.

[0225] In the above process, the control unit 21 of the terminal 20A performs the step (A130) of transmitting friend list request information to the server 10 after step A120, but the present invention is not limited to this. As a non-limiting example, if it is determined in step A150 that a monster is to be generated (A150: YES), control unit 21 of terminal 20A may transmit friend list request information to server 10. Then, control unit 11 of server 10 may transmit friend list information to terminal 20A based on the received friend list request information, and control unit 21 of terminal 20A may perform step A160 based on the received friend list information.

[0226] <Regarding monster generation> In addition, after the control unit 11 of the server 10 generates a monster based on one general account, the control unit 11 may be configured not to generate a monster even if a request to generate a monster based on the same general account is made from the terminal 20A.

[0227] Furthermore, when the control unit 21 of the terminal 20A displays the friend list in step A160, the monster generation button for a friend who has once generated a monster may be displayed grayed out so that user input to the monster generation button is not accepted. In this case, the monster generation request information is not transmitted to the server 10, and as a result, the server 10 does not generate a monster.

[0228] Furthermore, when the control unit 11 of the server 10 generates a monster based on one general account and then a request to generate a monster based on the same general account is made from the terminal 20A, a different monster may be generated by the server 10, for example and not by way of limitation. As one method, the control unit 11 of the server 10 may generate a monster based on information such as time information and attribute information of friends in addition to or instead of the general MAID (game ID). Note that there may be cases where the same monster happens to be generated, and this may be allowed.

[0229] <Effects of the First Embodiment> In this embodiment, a terminal 20 (not limited to this, but an example of a terminal) that communicates with a server 10 (not limited to this, but an example of a server) and performs processing related to a game such as game processing displays information on a messaging service (not limited to this, but an example of an SNS) on a display unit 24 about an account (not limited to this, but a first account associated with the account of the user of the terminal) that is registered as a friend of the account of the user of the terminal 20. Then, based on an input by the user of the terminal 20 to the information on the one account displayed on the display unit 24, the terminal 20 transmits information such as monster generation request information based on the one account (not limited to this, but an example of first information for requesting an object that appears in the game) via the communication I / F 22 to the server 10. Then, based on the transmission of the monster generation request information, the terminal 20 receives information (not limited to this, but an example of second information) on a monster that appears in the game and is based on the one account (not limited to this, but an example of a first object based on the first account) via the communication I / F 22. The terminal 20 then displays a monster (not limited to this, but an example of a first object) on the display unit 24 based on the received information. As an example of an effect of an embodiment obtained by such a configuration, the terminal can receive information about a first object based on a first account associated with the terminal user's account on the SNS from the server, and then display the first object on the display unit. This makes it possible, by way of example and not limitation, to obtain a monster based on another account associated with the terminal user's account on the SNS in a game and use it in the game, thereby increasing the interest of the game.

[0230] In this case, the terminal 20 displays information on the display unit 24 about another account (not limited to, an example of a second account) different from the one account (not limited to, an example of a first account) that is registered as a friend of the account of the user of the terminal 20 in a messaging service (not limited to, an example of an SNS). Then, the terminal 20 transmits information (not limited to, an example of the first information) such as the above monster generation request information based on the other account to the server 10 through the communication I / F 22 based on an input by the user of the terminal 20 to the information about the other account displayed on the display unit 24. Then, based on the transmission of the monster generation request information, the terminal 20 receives information (not limited to, an example of the second information) about a monster that appears in the game and that is generated based on the other account (not limited to, an example of a second object based on the second account) through the communication I / F 22. Then, the terminal 20 may display the monster (not limited to, an example of a second object) on the display unit 24 based on the received information. As an example of an effect of an embodiment obtained by such a configuration, the terminal can receive information about a second object based on a second account different from a first account associated with the terminal user's account on the SNS from the server, and then display the second object on the display unit. This makes it possible, by way of example and not by way of limitation, to obtain monsters based on multiple other accounts associated with the user's account on the SNS in a game and use them in the game, thereby increasing the interest of the game.

[0231] In this case, the first account and the second account may be accounts registered as friends of the user's account of the terminal 20 as general accounts (not limited to, but an example of the first type) in the messaging service. As an example of an effect of an embodiment obtained by such a configuration, it becomes possible to use a first object and a second object in a game based on a first account and a second account associated with a terminal user's account as a first type on a social networking site.

[0232] In this case, the terminal may be able to receive information about a first object based on a first account from the server and display the first object, but may not be able to receive information about a second object based on a second account from the server and display the second object.

[0233] In this case, the first account and second account may be a general account (not limited to, an example of the first type) in the messaging service, an account of the user of his / her terminal 20, and an account registered as a friend, and may be an account of the friend registered as a player of the game. As an example of an effect of an embodiment obtained by such a configuration, the terminal can use objects in a game based on the account of a user who is registered as a player of the game, among accounts associated with the terminal's user account as a first type on the SNS.

[0234] In this case, the first account may be an account associated with the terminal user's account as a first type on the SNS and is an account of a user who is registered as a game player, while the second account may be an account associated with the terminal user's account as a first type on the SNS but is not registered as a game player.

[0235] In addition, in this embodiment, the server 10 may include a game server (not limited to, but an example of a first server that manages information related to the game), and the above-mentioned first information may be transmitted to the game server by the communication I / F 22 of the terminal 20, and the above-mentioned second information may be received from the game server by the communication I / F 22 of the terminal 20. As an example of an effect of an embodiment obtained by such a configuration, the terminal can transmit first information to a first server that manages information related to a game, and then receive second information from the first server.

[0236] In this embodiment, the server 10, which communicates with the terminal 20 that performs processing related to the game, performs a monster generation process for generating monsters that appear in the game using the control unit 21. The communication I / F 14 of the server 10 receives, from the terminal 20, monster generation request information based on one account associated with the account of the user of the terminal 20 by the messaging service, and transmits information about the monster based on the one account to the terminal 20 based on the received monster generation request information. As an example of an effect of an embodiment obtained by such a configuration, the server can send to the terminal second information regarding a first object based on the first account, based on receiving from the terminal first information for requesting an object based on a first account associated with the terminal's user account on the SNS.

[0237] <First Modification (1)> In the above embodiment, the server included in the communication system is illustrated and described as one server (server 10), but this is not limiting. For example and without limitation, the server included in the communication system may be multiple physically separated servers.

[0238] FIG. 1-13 is a diagram showing an example of a system configuration of a communication system 1B in this modified example. In the communication system 1B, by way of example and not limitation, a messaging server 40, a game server 50, and a plurality of terminals 20 (terminal 20A, terminal 20B, terminal 20C, . . . ) are connected via a network 30.

[0239] The messaging server 40 is a server that manages information related to messaging applications (a server that provides messaging services), and may be, for example and without limitation, a server managed by a messaging service provider. The messaging server 40 includes, for example and not for limitation, a control unit 41 (CPU), a storage unit 45, a communication I / F 44 (interface), an input / output unit 42, and a clock unit 49. The input / output unit 42 also includes a display unit 43, for example and not by way of limitation.

[0240] The game server 50 is a server that manages information related to game applications (a server that provides game services), and can be, for example and without limitation, a server managed by a game service provider (such as a game maker). The game server 50 includes, by way of example and not limitation, a control unit 51 (CPU), a storage unit 55, a communication I / F 54 (interface), an input / output unit 52, and a clock unit 59. The input / output unit 52 also includes a display unit 53, for example and not by way of limitation.

[0241] Note that the HW configuration of each functional unit of these servers can be similar to the HW configuration of each functional unit of the server 10 described above, by way of example and not limitation, and therefore a description thereof will be omitted.

[0242] The storage unit 45 of the messaging server 40 may be configured to store, as data, for example and not by way of limitation, general account registration data 153 and general account management database 154 shown in FIG. 1-3.

[0243] The storage unit 55 of the game server 50 may be configured to store, as data, for example but not limited to, a player management database 156 and a monster generation table 157A shown in FIG. 1-3. In this case, as an example and not a limitation, a table in which the "last digit of MAID" in the monster generation table 157A shown in FIG. 1-5 is changed to the "last digit of game ID" may be stored in the memory unit 55 of the game server 50, and the game server 50 may generate a monster based on the game ID.

[0244] 1-14 and 1-15 are flowcharts showing an example of the flow of processes executed by each device in this modified example. In this figure, from the left, a process executed by the control unit 21 of the terminal 20A, a process executed by the control unit 41 of the messaging server 40, and a process executed by the control unit 51 of the game server 50 are shown, respectively.

[0245] When the control unit 41 of the messaging server 40 receives account linking request information from the terminal 20A via the communication I / F 44, it generates a game ID from a general MAID (in this example, the general MAID of user AA) included in the received account linking request information, by way of example and not limitation. Then, the control unit 41 of the messaging server 40 stores the generated game ID (in this example, the game ID of user AA) in association with the general MAID in the general account management data in the above-mentioned general account management database 155 in which the general MAID (in this example, the general MAID of user AA) is stored, by way of example and not limitation.

[0246] Next, the control unit 41 of the messaging server 40 transmits, by way of example and not limitation, account link request information including the generated game ID to the game server 50 via the communication I / F 44 (M110).

[0247] When the communication I / F 54 receives the account linking request information from the messaging server 40, the control unit 51 of the game server 50 performs the account linking process (G110). Specifically, by way of example and not limitation, the control unit 51 generates a player ID corresponding to the game ID included in the received account linking request information, generates player management data in which the player ID and the game ID are associated and stored, and stores the data in the player management database 156 of the storage unit 55.

[0248] In this modification, the game server 50 may be, by way of example and not limitation, a server managed by a game application provider (such as a game manufacturer). As described above, the general MAID of a messaging application is important information. Therefore, in this process, as an example and not a limitation, the messaging server 40 does not directly send the general MAID managed by the messaging server 40 to the game server 50, but instead sends a game ID generated from the general MAID to the game server 50.

[0249] Alternatively, the messaging server 40 may transmit the general MAID to the game server 50.

[0250] Thereafter, the control unit 51 of the game server 50 sends account linking completion information, which includes, by way of example and not limitation, information indicating that account linking has been completed and the player ID, to the messaging server 40 via the communication I / F 54 (G120).

[0251] After step M110, when account link information is received from the game server 50 via the communication I / F 44, the control unit 41 of the messaging server 40 transmits the received account link information to the terminal 20A via the communication I / F 44 (M120).

[0252] In this case, the control unit 41 of the messaging server 40 may associate the player ID included in the received account link information with the above-mentioned general MAID and store it in the general account management data of user AA.

[0253] Thereafter, when the control unit 41 of the messaging server 40 receives friend list request information from the terminal 20A via the communication I / F 44, the control unit 41 transmits the friend list information to the terminal 20A via the communication I / F 44 (M130). The processing of this step can be, for example and not limited to, the same as the processing of step S130 performed by the control unit 11 of the server 10 in FIG. 1-11.

[0254] Thereafter, by way of example and not limitation, game processing is carried out between the terminal 20A, the messaging server 40, and the game server 50 (A140, M140, G140).

[0255] In reality, the game progresses on terminal 20A under the control of control unit 51 of game server 50. For this reason, in this modification, messaging server 40 may be considered to fulfill the function of relaying between terminal 20A and game server 50.

[0256] When the control unit 41 of the messaging server 40 receives the general MAID monster generation request information from the terminal 20A via the communication I / F 44, the control unit 41 of the messaging server 40 refers to the general account management database 155 and determines whether or not a game ID is stored in association with the general MAID of the friend selected by the user AA included in the received general MAID monster generation request information. If it is determined that the game ID is stored, the control unit 41 of the messaging server 40 transmits the general MAID monster generation request information including the game ID to the game server 50 via the communication I / F 44 (M180), by way of example and not limitation.

[0257] If the friend selected by user AA is a player of this game, the general account management data of this friend stores the game ID in association with the general MAID of this friend. The above process includes a case where the control unit 41 of the messaging server 40 transmits friend list information to only those friends of user AA who are registered as players of this game in step M130.

[0258] On the other hand, if it is determined that a game ID is not stored in association with the general MAID of the friend selected by user AA, the control unit 41 of the messaging server 40 generates a game ID from the general MAID of the friend. Then, by way of example and not limitation, the control unit 41 of the messaging server 40 transmits general MAID monster generation request information including the generated game ID to the game server 50 via the communication I / F 44 (M180). If the friend selected by user AA is not a player of this game, the general account management data of this friend does not store a game ID in association with the general MAID of this friend (the game ID has not yet been generated). The above process includes a case where the control unit 41 of the messaging server 40 transmits friend list information to all friends of user AA in step M130.

[0259] When the communication I / F 54 receives the general MAID monster generation request information from the messaging server 40, the control unit 51 of the game server 50 performs a general MAID monster generation process (G180). Specifically, as a non-limiting example, a monster corresponding to the game ID included in the received general MAID monster generation request information is generated according to a monster generation program based on the monster generation table 157A stored in the storage unit 55. Then, information about the generated monster is stored in the player management data in which the player ID associated with that game ID is stored.

[0260] Alternatively, the messaging server 40 may transmit a general MAID to the game server 50, and the game server 50 may generate a monster based on the general MAID.

[0261] Next, the control unit 51 of the game server 50 transmits, by way of example and not limitation, general MAID monster generation result information to the terminal 20A via the communication I / F 54 (G190).

[0262] After step A180, when general MAID monster generation result information is received from the game server 50 via the communication I / F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the received general MAID monster generation result information (A190).

[0263] The game server 50 may transmit general MAID monster generation result information to the terminal 20A via the messaging server 40.

[0264] In addition, the messaging server 40 transmits in advance to the game server 50 the ID of the friend from which the monster will be generated (a general MAID if a general MAID is to be used for monster generation, or a game ID if a game ID is to be used for monster generation). Then, in step A180 of FIG. 1-15, the control unit 21 of the terminal 20A may transmit monster generation request information including the ID of the friend selected by the user AA (a general MAID if a general MAID is used, or a game ID if a game ID is used) to the game server 50 via the communication I / F 22, and the control unit 51 of the game server 50 may perform step G180.

[0265] In this modified example, the server includes a game server 50 (not limited to this, but an example of a first server that manages information related to a game) and a messaging server 40 (not limited to this, but an example of a second server that manages information related to an SNS). The first information described above is transmitted to the messaging server 40 by the communication I / F 22 of the terminal 20, and transmitted from the messaging server 40 to the game server 50, and the second information described above is received from the game server 50 by the communication I / F 22 of the terminal 20. As an example of the effect of the modified example obtained by such a configuration, when the terminal transmits the first information to the second server that manages information related to the SNS, the first information can be transmitted from the second server to the first server that manages information related to the game, and the terminal can receive the second information from the first server.

[0266] <First Modification (2)> In the above embodiment and modified example, the server performs the monster generation process when a request to generate a monster is received from the player's terminal 20, but this is not limited to the above. The server may perform the monster generation process at a different timing.

[0267] 1-16 is a diagram showing an example of a screen of a game application displayed on the display unit 24 of the terminal 20A in this modified example. Here, the screen displayed on the display unit 24 of the terminal 20A of the user AA is shown as an example.

[0268] In this example, by way of example and not limitation, before the game process is executed, the terminal 20A receives from the server a monster generation result (general MAID monster generation result information) based on all or some of the friends of the user AA of the terminal 20A. This makes it possible to display information related to this monster generation result (information based on the monster generation result) on the second generation screen.

[0269] Specifically, as a non-limiting example, a list item corresponding to a friend who is treated as having already generated a monster will display a generated icon GIC1 (in this example, an icon including a thumbnail of the generated monster), and a list item corresponding to a friend who is treated as having not yet generated a monster will display an ungenerated icon GIC2 (in this example, an icon including the character "?").

[0270] As a non-generated icon, for example and without limitation, an icon including information suggesting the monster to be generated may be displayed. The information suggesting the monster to be generated may include, for example and without limitation, a silhouette of the monster to be generated (different shape) or the character "?" (displayed in a different color).

[0271] As a non-limiting example, when displaying icons including silhouettes of monsters, icons including a silhouette that resembles part or all of each monster may be displayed.

[0272] As a non-limiting example, when an icon including the character "?" is displayed, the character "?" may be displayed in a different color depending on the appearance characteristics of each monster. Specifically, as a non-limiting example, when the display color of the character "?" is red, the rate at which monsters with the monster appearance characteristic of "cool" are generated is high; when the display color of the character "?" is blue, the rate at which monsters with the monster appearance characteristic of "scary" are generated is high; and when the display color of the character "?" is pink, the rate at which monsters with the monster appearance characteristic of "cute" are generated is high.

[0273] In the second generation screen of Figure 1-16, an ungenerated icon GIC2 (in this example, an icon containing the character "?") is displayed in the center of the friend list item corresponding to user BB, and a generated icon GIC1 (in this example, an icon containing a thumbnail of monster C) is displayed in the center of the friend list item corresponding to user CC.

[0274] In this way, in the list item of the second generation screen for selecting friends to use in monster generation, different icons (generated icon GIC1, ungenerated icon GIC2) are displayed depending on whether a monster has been generated or not, so that the user can easily distinguish between friends who have already generated a monster and friends who have not yet generated a monster. Also, by displaying a generated icon including a thumbnail of the already generated monster in the list item of a friend who has already generated a monster, the user can easily recognize which friend to start the monster generation from when he or she wants to generate the same monster as a monster that has already been generated.

[0275] 1-17 and 1-18 are flow charts showing an example of the flow of processes executed by each device in this modified example, which are diagrams showing an example of processes applied to the processes shown in FIGS. 1-11 and 1-12. After step S120, when the communication I / F 14 receives friend list request information from the terminal 20A, the control unit 11 of the server 10 performs general MAID monster generation processing (S181). Specifically, as an example and not a limitation, based on the above-mentioned monster generation table 157A, according to a monster generation program, monsters corresponding to the respective general MAIDs of all friends of the user AA are generated. Then, information on the generated monsters is stored in the player management data in which the player ID of the user AA is stored.

[0276] In this process, the control unit 11 of the server 10 may generate monsters corresponding to the respective general MAIDs for some of the general accounts of the friends of the user AA. The some of the general accounts are as described above.

[0277] Thereafter, the control unit 11 of the server 10 transmits the friend list information to the terminal 20A via the communication I / F 14 (S131). Also, the control unit 11 of the server 10 transmits general MAID monster generation result information to the terminal 20A via the communication I / F 14 (S151). In this case, the control unit 11 of the server 10 can transmit friend list information regarding the friends (all or some of the friends) for which a monster was generated in step S181 to the terminal 20A in step S131, and transmit monster generation result information regarding the monster generated in step S181 (monster generation result information corresponding to all or some of the friends) to the terminal 20A in step S151.

[0278] After step A130, when the friend list information and the general MAID monster generation result information are received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20A stores this information in the storage unit .

[0279] If it is determined in step A150 that a monster is to be generated (A150: YES), the control unit 21 of the terminal 20A causes the display unit 24 to display a list of friends (A161).

[0280] In this case, for friends for whom user input to generate a monster (such as, for example and not limitation, an operation on the monster generation button) has not yet been made (friends for whom the monster generation result information has not yet been displayed on the display unit 24 in step A190), the control unit 21 of terminal 20A can, for example and not limitation, display an ungenerated icon such as that shown in FIG. 1-16 in the friend list displayed on the display unit 24 in association with the friend's user icon image, user name, monster generation button, etc.

[0281] On the other hand, for friends for whom user input to generate a monster (such as, for example and not limitation, an operation on the monster generation button) has been performed (friends for whom the monster generation result information has already been displayed on the display unit 24 in step A190), it is possible to display, in the friend list displayed on the display unit 24, a generated icon of the corresponding monster (an icon including a thumbnail of the corresponding monster, etc.) as shown in Figure 1-16, for example and not limitation, in association with the friend's user icon image, user name, monster generation button, etc.

[0282] In addition, the generated icon and the thumbnail of the monster displayed on the generated icon may be generated by the control unit 21 of the terminal 20A based on the image of the monster included in the general MAID monster generation result information transmitted from the server 10 in step S151, received by the terminal 20A, and stored in the memory unit 28. Also, the control unit 11 of the server 10 may transmit, in step S131, the thumbnail of the monster generated in step S181 and the generated icon in the friend list information to the terminal 20A. Also, the control unit 11 of the server 10 may transmit, in step S151, the general MAID monster generation result information in the friend list information to the terminal 20A.

[0283] If it is determined in step A170 that a monster is to be generated based on general MAID (A170: YES), the control unit 21 of the terminal 20A causes the display unit 24 to display monster generation result information corresponding to the friend selected by the user AA based on the general MAID monster generation result information stored in the memory unit 28 (A190).

[0284] 1-19 and 1-20 are flow charts showing another example of the flow of the processes executed by each device in this modified example, which are diagrams showing a processing example when applied to the processes shown in FIGS. 1-11 and 1-12. In this process, the control unit 11 of the server 10 performs the process of step S131 after step S181, and then proceeds to the process of step S140. That is, in this process, after step S131, the control unit 11 of the server 10 does not transmit monster generation result information regarding the monster generated in step S181 (monster generation result information corresponding to all or some of the friends) to the terminal 20A.

[0285] If it is determined in step A170 that a monster is to be generated based on a general MAID (A170: YES), the control unit 21 of the terminal 20A sends general MAID monster acquisition request information to the server 10 via the communication I / F 22 for the friend selected by the user AA (A182).

[0286] After step S140, when general MAID monster acquisition request information is received from terminal 20A via communication I / F 14, the control unit 11 of the server 10 transmits general MAID monster generation result information including information about the monster generated in step S181 that corresponds to the general MAID (the general MAID of the friend selected by user AA) included in the received general MAID monster acquisition request information to terminal 20A via communication I / F 14 (S190).

[0287] Fig. 1-21 is a flowchart showing another example of the flow of the processes executed by each device in this modified example. This shows an example of the process following Fig. 1-17. If it is determined in step A170 that a monster is to be generated based on general MAID (A170: YES), the control unit 21 of the terminal 20A sends general MAID monster activation request information to the server 10 via the communication I / F 22 for the friends selected by the user AA (A184).

[0288] Here, activation can mean, for example and not by way of limitation, changing a state in which the monster (object) cannot be played in the game to a state in which it can be played, or it can be understood as changing a state in which the monster cannot be used in the game to a state in which it can be used.

[0289] After step S140, when general MAID monster activation request information is received from terminal 20A via communication I / F 14, the control unit 11 of the server 10 determines whether or not to activate the monster generated in step S181 that corresponds to the general MAID included in the received general MAID monster activation request information (the general MAID of the friend selected by user AA) (S185).

[0290] Specifically, the control unit 11 of the server 10 may determine whether or not to activate a monster based on at least one of the following conditions, by way of example and not limitation, as activation conditions: (A) The daily monster generation limit has not been reached. (B) The user owns certain in-game content, items, or consideration for monster generation (for example, but not limited to, consuming one coin to generate a monster).

[0291] If it is determined that this monster should be activated (S185: YES), the control unit 11 of the server 10 performs a monster activation process (S187). Specifically, as a non-limiting example, when condition (A) is used, the number of times the monster is generated is incremented in association with the account of user AA, and when condition (B) is used, a process of subtracting a specific item stored in association with the account of user AA (as a non-limiting example, a process of subtracting one coin) is performed. Then, among the monsters generated in step S181, a monster corresponding to the general MAID (general MAID of the friend selected by user AA) included in the received general MAID monster activation request information is activated. More specifically, as a non-limiting example, in step S181, an activation flag (default is "OFF") is set in association with each monster (monster identification information, etc.) generated based on the account of user AA's friend, and the activation flag is stored in the player management data in which the player ID of user AA is stored. Then, the activation flag of the monster corresponding to the general MAID (general MAID of the friend selected by user AA) included in the received general MAID monster activation request information is set to "ON". In this way, it is possible to make the monster that corresponds to the friend selected by the user, from among the monsters that have been generated in advance, available for use in the game.

[0292] Next, the control unit 11 of the server 10 transmits general MAID monster activation information indicating that the monster has been activated to the terminal 20A via the communication I / F 14 (S191). This general MAID monster activation information may be regarded as information for enabling the user to use the monster, by way of example and not limitation, and may be an example of second information (information relating to an object that is based on an account). The control unit 11 of the server 10 may also transmit information on the generation result of the activated monster to the terminal 20A.

[0293] When general MAID monster activation information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20A performs step A190. Specifically, by way of example and not limitation, the control unit 21 causes the display unit 24 to display activated general MAID monster generation result information based on the monster generation result information previously received and stored from the server 10 (or the monster generation result information received from the server 10). The control unit 21 of the terminal 20A may also cause the display unit 24 to display the general MAID monster activation information received from the server 10.

[0294] In this case, the control unit 21 of the terminal 20A, by way of example and not limitation, sets to "ON" the flag of a monster identified from the received general MAID monster activation information among the monsters previously received and stored from the server 10, thereby making it possible to distinguish between active and inactive monsters and to display them in the friend list as described above.

[0295] The activation conditions may include, by way of example and not limitation, the following conditions: (C) The monster information included in the general MAID monster activation request information received from the terminal matches the monster information stored in the server.

[0296] Specifically, in step A184, the control unit 21 of the terminal 20A transmits general MAID monster activation request information including, by way of example and not limitation, information on the monster requesting activation (information on the monster's parameter values, an image of the monster, etc.) to the server 10. Then, in step S187, the control unit 11 of the server 10 can compare the monster information included in the received general MAID monster activation request information with information on the corresponding monster among the monsters generated and stored in step S181, and if these pieces of information match, determine to activate the monster.

[0297] In this way, even if a monster managed by the server 10 has been modified by an illegal method (so-called cheating) (for example and not limitation, modification of parameter values, modification of appearance, etc.), it is possible to prevent the monster from being activated. In other words, even if information such as a monster's parameter values ​​has been illegally modified based on the information of the monster stored internally in the terminal 20, it is possible to prevent the monster from being activated on the server 10.

[0298] In addition, in step S151 of FIG. 1-17 of this process, the control unit 11 of the server 10 may be configured to not transmit at least information on the parameter values ​​of the monster to the terminal 20A (information on the monster's appearance may also not be transmitted), and may transmit information for display in the friend list (such as the generated icon GIC1 and the thumbnail of the monster, as examples and not limitations) to the terminal 20A. In this case, in step S191 of FIG. 1-21, the control unit 11 of the server 10 may be configured to transmit information on the generation result of the activated monster to the terminal 20A, and the control unit 21 of the terminal 20A may perform step A190 based on the received information on the generation result of the monster. This also makes it possible to prevent information such as the parameter values ​​of the monster from being altered.

[0299] In the above process, the control unit 21 of the terminal 20A may determine whether or not to activate the selected monster. Also, the control unit 21 of the terminal 20A may transmit the result of the determination to the server 10, and the server 10 may activate the monster.

[0300] Moreover, the above-mentioned process may be similarly applied to the processes shown in FIGS. 1-15 to 1-17, which are executed in the communication system 1B shown in FIG. 1-13.

[0301] In this modification, the terminal 20 displays on the display unit 24 a friend list (not limited to, an example of a list) including information on one friend's account (not limited to, an example of a first account) of the user of the terminal 20 and information on another friend's account (not limited to, an example of a fifth account). The terminal 20 shows a configuration in which, when the monster generation request information based on the one friend's account has not been transmitted and the monster generation request information based on the other friend's account has not been transmitted, the information on the one friend's account and the information on the other friend's account are displayed in the same manner in the friend list if the monster generation request information based on the one friend's account has been transmitted, and when the monster generation request information based on the one friend's account has been transmitted and the monster generation request information based on the other friend's account has not been transmitted, the information on the one friend's account and the information on the other friend's account are displayed in different manners in the friend list. As an example of the effect of the modified example obtained by such a configuration, when the first information based on the first account has not been transmitted and the first information based on the fifth account has not been transmitted, if the first information based on the first account is transmitted, the information on the first account and the information on the fifth account are displayed in the same manner in the list, thereby notifying the user of the terminal that the first information based on none of the accounts has been transmitted. On the other hand, when the first information based on the first account has been transmitted and the first information based on the fifth account has not been transmitted, the information on the first account and the information on the fifth account are displayed in different manners in the list, thereby notifying the user of the terminal that the first information based on the first account has been transmitted.

[0302] In this case, the monster based on the first account (not limited to, but an example of a first object) may be associated with the first account by server 10, for example by being generated by server 10 before the monster generation request information based on the first account is sent. As an example of an effect of a modified example obtained by such a configuration, the first object may be associated with the first account by the server before the first information based on the first account is transmitted.

[0303] The terminal 20 stores information about a monster that has been generated in advance (such as, but not limited to, information about the monster's behavior, parameter values, etc.) in the storage unit 28 based on all or some of the accounts of the user of the terminal 20's friends in the messaging service. The monster may be generated by the terminal 20 or by the server 10. Then, the terminal 20 displays on the display unit 24 information related to one or more of the friend accounts from which the monster was generated (for example, but not limited to, a user name, a user icon image, a monster generation button, etc.). Then, based on input by the user of terminal 20 regarding information about at least one of the one or more accounts displayed on display unit 24, terminal 20 may use information about the monster stored in memory unit 28 to display a monster based on that account on display unit 24.

[0304] In addition, when generating a monster on terminal 20, a monster based on an account may be generated based on input by the user of terminal 20 regarding information about at least one of the one or more accounts displayed on display unit 24, and the generated monster may be displayed on display unit 24.

[0305] Also, sending information to request an object can include, by way of example and not limitation, - Sending information from the device to the server so that the server can obtain objects that have already been generated based on the account - Sending information from the terminal to the server to activate an object that the terminal has already obtained from the server may also be included.

[0306] <First Modification (3)> In the above embodiment and modified examples, the generated monsters may be refreshed at regular intervals or with a time limit. In a managed game rather than a one-time purchase game as described in this specification, there may be cases where the manager adds new types of monsters while operating the game.

[0307] FIG. 1-22 is a diagram showing an example of a table configuration of a monster generation table 157B, which is an example of the monster generation table 157 in this modified example. The table configuration of this monster generation table 157B is similar to that of monster generation table 157A in FIG. 1-5, but the contents are different.

[0308] Specifically, in this table, the last digit of the MAID is set to a numerical range of, for example but not limited to, "0-1," "2-3," "4-5," "6-7," and "8-9." The last digit "0~1" represents the monster type "ME (Monster E)" and the monster appearance characteristic "cute". The last digit "2~3" represents the monster type "MD (Monster D)" and the monster appearance characteristic "Cool". The last digit "4~5" is set as the monster type "MC (Monster C)" and the monster appearance characteristic is "cute". The last digit "6~7" is set to "MB (Monster B)" as the monster type and "scary" as the monster appearance characteristic. The last digit "8~9" is set as the monster type "MA (Monster A)" and the monster appearance characteristic is "Cool".

[0309] The control unit 11 of the server 10 can generate monsters based on the above-mentioned monster generation table 157B, for example and not for limitation. In this case, the control unit 11 of the server 10 generates a monster based on the above-mentioned monster generation table 157A at the start of game distribution, for example and not by way of limitation. Then, when it is time to refresh the monster thereafter, the control unit 11 of the server 10 can generate a monster based on the above-mentioned monster generation table 157B. By doing this, even when monsters are generated based on the same general MAID, different monsters can be generated.

[0310] The same may be true when the control unit 51 of the game server 50 generates a monster.

[0311] However, without being limited to this example, even after refreshing, monsters may be generated based on the monster generation table before refreshing, according to the user's request. Also, as a non-limiting example, if a first monster generation table is set before refreshing, and a second monster generation table is additionally set in addition to the first monster generation table after refreshing, the user may select any monster generation table and a monster may be generated based on that monster generation table.

[0312] Moreover, the above-mentioned monster generation table 157B may or may not be applied to the official MAID in the case where a monster is generated based on the official account described in the second embodiment.

[0313] In this modified example, the terminal 20 displays information on the first account of a friend of the user of the terminal 20 on the display unit 24 of the terminal 20 after the second information on the monster (not limited, but a first object) based on the first account of the friend is displayed on the display unit 24 of the terminal 20. Then, the terminal 20 transmits monster generation request information based on the friend's account to the server 10 via the communication I / F 22 based on the information on the friend's account displayed on the display unit 24 based on an input by the user of the terminal 20. Then, based on the transmission of the monster generation request information, the terminal 20 receives from the server 10 via the communication I / F 22 second information on the monster based on the friend's account (not limited, but an example of a fifth object) to be displayed on the display unit 24 in place of the monster (not limited, but an example of a first object) previously acquired from the server 10 based on the friend's account, and displays the monster (fifth object) on the display unit 24 based on the received second information. As an example of the effect of the modified example obtained by such a configuration, the terminal can receive second information from the server about a fifth object based on the first account, which is to be displayed on the display unit of the terminal in place of the first object based on the first account, and then display the fifth object on the display unit.

[0314] <First Modification (4)> In the above embodiment and modified examples, a virtual account different from the general account registered as a friend in the messaging application may be registered as a friend in the game application, and a monster may be generated based on this virtual account. In the games described herein, monsters are generated based on general accounts that are registered as friends in a messaging application, but some players may have a small number of general accounts registered as friends in a messaging application.

[0315] 1-23 is a diagram showing an example of a screen of a game application displayed on the display unit 24 of the terminal 20A in this modified example. Here, the screen displayed on the display unit 24 of the terminal 20A of the user AA is shown as an example.

[0316] In this example, by way of example and not limitation, an add button for registering a virtual account as a friend in a game is displayed, and when this add button is touched by a player, the virtual account is registered as a friend. This virtual account is different from an actual human (user) and may be, by way of example and not limitation, a character (person, monster, etc.) in the game.

[0317] Regarding the display screen in FIG. 1-23(1), the description of the parts that are similar to those in FIG. 1-8(3) described above will be omitted.

[0318] In the screen of FIG. 1-23(1), to the left of the home button at the top of the screen, an add button FBT (in this example, a button containing a "+" symbol) for adding a virtual account as a friend is displayed. Below that, only the icon and user name corresponding to user BB are displayed (in a list) as items in the friend list.

[0319] For example, but not by way of limitation, when the add button FBT is touched by the user as shown in FIG. 1-23(1), a display as shown in FIG. 1-23(2) is displayed as an example, but not by way of limitation. On this screen, a confirmation area MGR2 (addition confirmation area) for confirming that the virtual account is to be added as a friend is displayed superimposed on the screen of FIG. 1-23(1).

[0320] The confirmation area MGR2 displays additional confirmation information (in this example, the text "Do you want to add a friend to create monsters?"), a YES button BT1 for answering [YES] to the above information, and a NO button BT2 for answering [NO] to the above information.

[0321] As a non-limiting example, when the YES button BT1 is touched by the user as shown in FIG. 1-23(2), a display as shown in FIG. 1-23(3) is displayed as a non-limiting example. On this screen, the area below the friend list item (in this example, the icon and username corresponding to user BB) is configured to display a "virtual friend list" that lists information about friends of the virtual account of user AA of this terminal 20A in the game.

[0322] In this example, the virtual friend list items include an icon and a user name corresponding to the character X. Also, to the right of each of these friend list items, a generation execution button MGBT (a button containing the words "Generate Monster" in this example) is displayed. It should be noted that the icons of characters, etc. displayed in the virtual friend list may be displayed in a manner that makes them distinguishable from the icons of friends displayed in the friend list.

[0323] Here, when the generation execution button MGBT corresponding to the character X is touched by the player, a monster is generated from the character X, which is a virtual account that does not actually exist (not shown).

[0324] In this case, by way of example and not limitation, based on a user's input to the generate execution button MGBT, information requesting virtual accounts (virtual friends) may be sent from terminal 20 to server 10, and a set number of virtual accounts may be generated by server 10, or a set number of virtual accounts may be read from a virtual account database, and the information may be sent to terminal 20.

[0325] As a non-limiting example, the set number may be different based on the number of friends in the friend list. As a non-limiting example, the server 10 may determine the number of virtual accounts based on a table that associates the number of friends with the set number. In this case, as a non-limiting example, the smaller the number of friends, the larger the set number may be set (the larger the number of friends, the smaller the set number). Also, the user of the terminal 20 may be able to set the set number.

[0326] Also, by way of example and not limitation, a virtual account may only be added if the number of friends is equal to or less than a predetermined number.

[0327] In this way, players who have a small number of general accounts registered as friends in the messaging application can be prevented from being at a disadvantage in progressing through the game due to the number of general accounts they have registered as friends, and a game with sound gameplay can be provided.

[0328] Furthermore, by using the above method, it is possible to generate more monsters than there are friends (excluding virtual friends). As a non-limiting example, it is possible to generate monsters even if there are "0" friends.

[0329] Also, as a non-limiting example, when a game is played on the terminal 20 of a first user who has a predetermined number of friends or less, the server 10 may introduce at least some of the second users (other users) registered in the messaging application to the first user as friend candidates. As a non-limiting example, a list of second users who are friend candidates (which may include profiles, etc.) is displayed on the terminal 20 of the first user, and based on an input by the first user to select a second user who wants to become a friend, the terminal 20 transmits information about the selected second user to the server 10. Then, the server 10 may register the selected second user as a friend of the first user in the messaging application.

[0330] Also, in this case, by way of example and not limitation, the server 10 may introduce at least some of the users who are registered in the messaging application and who are registered as players of the game to the user of the terminal 20 as potential friends. Furthermore, in this case, the server 10 may also introduce users who also have a predetermined number of friends or less.

[0331] <First Modification (5)> In the above embodiment, the server generates monsters for friends selected by the user from the friend list, but this is not limiting. As a non-limiting example, the user may not select friends that generate monsters. In other words, the requirement that the user selects friends that generate monsters may be removed.

[0332] 1-24 and 1-25 are flow charts showing another example of the flow of the processes executed by each device in this modified example, which are diagrams showing a processing example when applied to the processes shown in FIGS. 1-11 and 1-12. First, in this process, steps A130 and S130 in FIG. 1-11 are excluded.

[0333] In FIG. 1-25, when it is determined in step A150 that a monster is to be generated (A150: YES), the control unit 21 of the terminal 20A transmits monster generation request information to the server 10 via the communication I / F 22 (A181). Then, the control unit 21 of the terminal 20A advances the process to step A190.

[0334] After step S120, when the communication I / F 14 receives monster generation request information from the terminal 20A, the control unit 11 of the server 10 performs a general account selection process (S175). Specifically, as a non-limiting example, at least one general account is randomly selected from the user AA's account and general accounts registered as friends. It may be thought of as a lottery to select the general account that will generate the monster. Then, the control unit 11 of the server 10 advances the process to step S180.

[0335] In the above, the control unit 11 of the server 10 may randomly select a set number of general accounts, and the set number may be "1" or may be two or more.

[0336] In addition, the selection of the general account may be made from all general accounts registered as friends, or may be made from a portion of the general accounts registered as friends. The portion of the general accounts is as described above.

[0337] In this modified example, a terminal 20 (not limited to this, an example of a terminal) that communicates with a server 10 (not limited to this, an example of a server) and performs processing related to a game such as game processing receives, from the server 10 via the communication I / F 22, information regarding a monster (not limited to this, an object) that appears in the game and that is generated based on one of a plurality of general accounts that are registered as friends with the general account of the user of the terminal 20 in a messaging service (not limited to this, an example of an SNS).Then, the terminal 20 shows a configuration in which the generated monster (not limited to this, an example of the first object) is displayed on the display unit 24 based on the received information. As an example of an effect of an embodiment obtained by such a configuration, the terminal can receive information about a first object based on a first account among a plurality of accounts associated with the terminal user's account on the SNS from the server, and then display the first object on the display unit. This makes it possible, by way of example and not limitation, to obtain a monster based on another account associated with the terminal user's account on the SNS in a game and use it in the game, thereby increasing the interest of the game.

[0338] In this embodiment, the server 10, which communicates with the terminal 20 that performs processing related to the game, performs a monster generation process for generating monsters that appear in the game using the control unit 21. The communication I / F 14 of the server 10 is configured to transmit to the terminal 20 information about the monster, which is based on one of a plurality of accounts associated with the account of the user of the terminal 20 in the messaging service. As an example of an effect of an embodiment obtained by such a configuration, the server can send to the terminal second information about a first object based on a first account of a plurality of accounts associated with the account of the user of the terminal on the SNS.

[0339] <Second Example> In the first embodiment, an example has been described in which a user of a general account who uses a messaging application acquires an object based on a general account registered as a friend in the messaging application. A second embodiment may additionally or alternatively relate to, by way of example and not limitation, a user of a general account using a messaging application obtaining an object based on an official account.

[0340] The contents described in the second embodiment are applicable to any of the other embodiments and other modified examples. Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

[0341] <Data Structure> FIG. 2-1 is a diagram showing an example of a data configuration of the official account management database 159 stored in the storage unit 15 of the server 10 in this embodiment. The official account management database 159 is a management database for managing official accounts in a messaging application, and by way of example and not limitation, official account management data is stored as management data for each official account.

[0342] Each official account management data stores, by way of example and not limitation, an official MAID (official messaging application ID), an official username, other registration information, and official account friend data.

[0343] The official user name is the name of an official account that uses a messaging application, and by way of example and not limitation, the name that an official user registers when using the messaging application via the terminal 20 is stored. In addition, an official user may be allowed to use messaging applications and the like through the terminal 20 in the same manner as a general user.

[0344] The official MAID is information used to identify an official user's account in a messaging application, or the account itself. This official MAID is preferably a value that is unique for each account, and as a non-limiting example, a unique value (proper value) is set and stored by the server 10 for each account. The official MAID is information associated with the terminal 20 used by the official user or the official user, and is an example of information related to the terminal or information related to the user of the terminal.

[0345] Other registration information may include, by way of example and not limitation, various types of information such as identification information for identifying terminal 20, contact information such as the telephone number and email address of terminal 20, authentication information such as passwords (login password, authentication password, etc.) used for various authentications in the application, and the official user's own icon image (official user icon image) registered by this official user in the messaging application.

[0346] The identification information for identifying the terminal 20 may be, for example and not limited to, a terminal ID (for example and not limited to, an IMEI).

[0347] The official MAID can be an example of identification information for identifying the user of the terminal 20. An "official user ID" may be used instead of the official MAID. Also, when there is no need to distinguish between a general MAID and an official MAID, it may or may not simply be called a "user ID." Furthermore, contact information may also be an example of identification information for identifying a user of the terminal 20.

[0348] Furthermore, if the application allows only one account to be registered per terminal 20, then, as a non-limiting example, "identification information for identifying terminal 20 = identification information for identifying the user of terminal 20 = official MAID" may be used.

[0349] Also, by way of example and not limitation, it may or may not be possible to assign multiple terminal IDs to one official MAID.

[0350] It is also possible to apply a method of managing accounts using information such as telephone numbers, etc. In this case, by way of example and not limitation, information such as telephone numbers may be stored in the official account management data.

[0351] Official account friend data is data about general users who have registered the official account of this official username as a friend in a messaging application, and by way of example and not limitation, the general username is stored in association with the general MAID of the general user with that general username.

[0352] 2-2 is a diagram showing an example of a data configuration of a monster generation table 157C, which is an example of a monster generation table stored in the storage unit 15 of the server 10 in this embodiment. Here, as an example and not a limitation, this is shown and described as a table different from the monster generation table 157A (157B) described above. In the monster generation table 157C, as a non-limiting example, an official MAID, a monster type, and a monster appearance characteristic are stored in association with each other.

[0353] As the official MAID, by way of example and not limitation, the official MAIDs of some of the official accounts included in the official account management database 159 are stored.

[0354] The meanings of the monster types and monster appearance characteristics are the same as those in the monster generation table 157A described above.

[0355] Specifically, in this table, the official MAIDs are set to, for example but not limited to, "C001", "C0015", and so on. The official MAID "C001" has a monster type of "MC (Monster C)" and a monster appearance characteristic of "cute." The official MAID "C015" has a monster type of "MD (Monster D)" and a monster appearance characteristic of "cool."

[0356] As a non-limiting example, the official user of the official account of the official MAID "C001" is an official user with the official username "XX Sweets" as shown in Figure 2-1. This official user may be, as a non-limiting example, an official user who runs a business that provides and sells sweets.

[0357] For example, but not exclusively, if a monster with the appearance characteristic "scary" is generated from the official account of an official user who provides and sells sweets, this could damage the corporate image of this official user. Therefore, by setting the monster appearance characteristic to "cute" as an example, but not exclusively, it is possible to generate a monster with a "cute" appearance, thereby preventing damage to the corporate image. In addition, the same can be done for other businesses such as those selling stuffed toys, by way of example and not limitation.

[0358] Also, in this example, for the official user of the official account of the official MAID "C015", a monster with a "cool" appearance is generated based on the business of the official user.

[0359] The control unit 11 of the server 10 determines, by way of example and not limitation, whether or not the official MAID is included in the monster generation table 157C based on the official MAID included in the official MAID monster generation request information received from the player's terminal 20. If it is determined that the official MAID is included, a monster of the corresponding official MAID can be generated based on the monster type and monster appearance characteristics set in the monster generation table 157C.

[0360] In addition, when a request for generating a monster is made from the player's terminal 20 for an official account for which the official MAID is not stored in the monster generation table 157C, the control unit 11 of the server 10 may generate a monster based on the above-mentioned monster generation table 157A, for example and not by way of limitation.

[0361] Also, for the official MAID, a game ID may be generated in the same manner as in the first embodiment, and a monster may be generated based on the game ID.

[0362] <Display screen> The display screen in FIG. 2-3(1) is similar to that in FIG. 1-8(1) described above, and therefore a description thereof will be omitted.

[0363] For example and not for limitation, when the generate button GBT is touched by the user as shown in FIG. 2-3(1), a display as shown in FIG. 2-3(2) is displayed as an example and not for limitation. This screen is the 1Bth generation screen among the generation screens for generating monsters, and the words "Generation Stage" are displayed in the in-app position display area.

[0364] In this example, the generation information display area displays 1B generation confirmation information (as an example, but not limited to, the text "From which user would you like to generate a monster?"), a friend button UBT1 (in this example, a button containing the text "Friend") for generating a monster from a general friend (general account), and an OA button UBT2 (in this example, a button containing the text "Official Account") for generating a monster from an official account.

[0365] As a non-limiting example, when the friend button UBT1 is touched by the user (i.e., when the type of user generating the monster is set to general friend (general account)), the display shown in Figure 2-3 (3A) is shown, and when the OA button UBT2 is touched by the user (i.e., when the type of user generating the monster is set to official account), the display shown in Figure 2-3 (3B) is shown.

[0366] (Generating monsters from regular friends) The display screen in FIG. 2-3(3A) is similar to that in FIG. 1-8(3) described above, and therefore the description thereof will be omitted.

[0367] (Monster generation from official account) The screen in Figure 2-3 (3B) is the 2Bth generation screen among the generation screens for generating monsters, and the words "Generation Stage" are continuously displayed in the in-app position display area.

[0368] In this example, the creation information display area displays a list of friend list items, such as an icon and user name corresponding to an official account (XX Sweets), an icon and user name corresponding to an official account (YY Travel), etc. Also, to the right of each of these friend list items, a creation execution button MGBT (a button containing the words "Monster Creation" in this example) for creating a monster using the friend corresponding to that friend list item is displayed.

[0369] Next, in Figures 2-3 (3A) and (3B), when the user touches the generation execution button MGBT corresponding to any friend list item, a monster is generated based on the friends (general friends, official accounts) selected by the user, as shown in Figure 1-8 (4) and subsequent figures.

[0370] In this way, by allowing users to generate monsters not only from general friends (general accounts) but also from official accounts, users can be provided with the opportunity to generate monsters from more friends than if they could only generate monsters from general friends, thereby increasing the interest of the game, which has the game-like aspect of monster generation.

[0371] <Processing> Fig. 2-4 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. Here, a processing example in the case where the communication system 1A shown in Fig. 1-1 is applied is shown, and the processing part corresponding to Fig. 1-12 is shown.

[0372] After step A190, the control unit 21 of the terminal 20A determines whether or not to generate a monster based on the official MAID, for example by determining whether or not a user input has been made to select an official account from the displayed friend list (B200).

[0373] If it is determined that a monster is to be generated based on the official MAID (B200: YES), the control unit 21 of the terminal 20A transmits official MAID monster generation request information, including, by way of example and not limitation, the official MAID of the friend selected by the user AA, to the server 10 via the communication I / F 22 (B210).

[0374] After step S190, when official MAID monster generation request information is received from terminal 20A via communication I / F 14, control unit 11 of server 10 performs official MAID monster generation processing (S200). Specifically, as an example and not a limitation, based on the monster generation table 157A and monster generation table 157C described above, a monster corresponding to the official MAID (official MAID of the friend selected by user AA) included in the official MAID monster generation request information received from terminal 20A is generated according to a monster generation program. Then, information about the generated monster is stored in player management data in which user AA's player ID is stored.

[0375] Thereafter, the control unit 11 of the server 10 transmits official MAID monster generation result information, including information about the monster generated in step S200, to the terminal 20A via the communication I / F 14 (S210).

[0376] After step B210, when official MAID monster generation result information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the official MAID monster generation result information based on the received official MAID monster generation result information (B220).

[0377] 2-5 to 2-6 are flowcharts showing another example of the flow of the process executed by each device in this embodiment. Here, a process example in the case of applying the communication system 1B shown in FIG. 1-13 is shown, and the process part corresponding to FIG. 1-15 is shown.

[0378] When official MAID monster generation request information including the official MAID is received from terminal 20A via communication I / F 44, the control unit 41 of the messaging server 40 generates a game ID from the official MAID of the friend selected by user AA included in the received official MAID monster generation request information, and transmits the official MAID monster generation request information including the generated game ID to the game server 50 via communication I / F 44 (M185).

[0379] When the official MAID monster generation request information is received from the messaging server 40 via the communication I / F 54, the control unit 51 of the game server 50 performs an official MAID monster generation process (G192). Specifically, as a non-limiting example, a monster corresponding to the game ID included in the received official MAID monster generation request information is generated according to a monster generation program based on the monster generation table 157A and the monster generation table 157C stored in the storage unit 55. Then, information about the generated monster is stored in the player management data in which the player ID of the user AA is stored.

[0380] Next, the control unit 51 of the game server 50 transmits, by way of example and not limitation, the official MAID monster generation result information to the terminal 20A via the communication I / F 54 (G194).

[0381] After step B210, when official MAID monster generation result information is received from the game server 50 via the communication I / F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the received official MAID monster generation result information (B220).

[0382] The game server 50 may transmit the official MAID monster generation result information to the terminal 20A via the messaging server 40.

[0383] <Effects of the second embodiment> In this embodiment, the first account is an account registered as a friend of the account of the user of the terminal 20 as a general account type (not limited to, an example of the first type) in the messaging service, and the terminal 20 displays information on the display unit 24 about an account (not limited to, an example of a third account) registered as a friend of the account of the user of the terminal 20 as an official account type (not limited to, an example of the second type). Then, based on an input by the user of the terminal 20 about the information about the official account displayed on the display unit 24, the terminal 20 transmits information such as a monster generation request information based on the official account to the server 10 via the communication I / F 22. Then, based on the transmission of the information such as the monster generation request information, the terminal 20 receives information about a monster based on the official account (not limited to, an example of a third object) from the server 10 via the communication I / F 22, and displays the monster on the display unit 24 based on the received information. As an example of the effect of the embodiment obtained by such a configuration, the terminal displays information on a third account associated with the account of the user of the terminal as a second type different from the first type on the SNS, and transmits first information based on the third account to the server through the communication unit based on an input by the user of the terminal to the displayed information on the third account. Then, based on the transmission of the first information, the terminal can receive second information on a third object, which is an object based on the third account, from the server through the communication unit, and display the third object on the display unit. This makes it possible, for example and not by way of limitation, to use an object based on an account of the second type different from the first type in a game.

[0384] In this case, a monster based on a general account (not limited to, but an example of a first object) may be a monster corresponding to the type of general account, and a monster based on a official account (not limited to, but an example of a third object) may be a monster corresponding to the type of official account. As an example of an effect of an embodiment obtained by such a configuration, for an account associated with the account of a user of the terminal as a first type, an object corresponding to the first type can be obtained, and for an account associated with the account of the user of the terminal as a second type, an object corresponding to the second type can be obtained.

[0385] <Second Modification Example (1)> In the above embodiment, by way of example and not limitation, it may be possible to register a new official account as a friend or generate a monster from a notification or the like in a game application.

[0386] FIG. 2-7 is a diagram showing an example of a screen displayed on the display unit 24 of the terminal 20A in this modified example. The display screen in FIG. 2-7(1) is similar to that in FIG. 1-8(1) described above, and therefore a description thereof will be omitted.

[0387] By way of example and not limitation, when the notification button NBT is touched by the user as shown in FIG. 2-7(1), a display as shown in FIG. 2-7(2) is displayed, by way of example and not limitation. This screen is the first notification screen among notification screens for displaying notifications, and the word "Notification" is displayed in the in-app location display area.

[0388] Below that, a notice information display area is configured in which information relating to notices in the game application (hereinafter referred to as "notice information") is displayed. In this example, the notification information display area is configured to display a notification list for displaying a list of notifications received by this account (in this example, "user AA"). On this screen, notification title information related to the notification title (in this example, the text "Get a limited edition monster by becoming friends with the official ZZ Drink account!" and the text "About currently confirmed bugs") are displayed as a list of notification list items.

[0389] The "limited monster" is a monster that is not generated by the normal monster generation in the game, where monsters are generated from friends, and can be made to be rare and valuable to the player. As the "limited monster", one type of monster may be provided, or multiple types of monsters may be provided.

[0390] As an example, and not as a limitation, when a user touches an item in the notification list, such as in FIG. 2-7(2), which includes notification title information such as “Get a limited edition monster by becoming friends with the official ZZ Drink account!”, a display such as in FIG. 2-7(3A) or FIG. 2-7(3B) will be displayed, and is not a limitation, as an example. As a non-limiting example, if you are not yet friends with the official ZZ Drink account, you will see the display shown in Figure 2-7(3A), and if you are already friends with the official ZZ Drink account, you will see the display shown in Figure 2-7(3B).

[0391] (If you are not friends with the official ZZ Drink account) The screen in FIG. 2-7(3A) is a 2A notification screen among notification screens for displaying notifications, and the word "Notice" is continuously displayed in the in-app position display area.

[0392] In this example, the notification information display area displays, by way of example and not limitation, detailed information of the notification related to the touched notification title information (hereinafter referred to as "notification detail information" as appropriate). In this example, the detailed notification information includes the text and image of "Get [ungenerated icon GIC2 and the text 'Limited Monster'] by being friends with [icon and user name corresponding to ZZ Drink]!!", a registration button RBT (in this example, a button containing the text "Become a Friend") for registering this official account as a friend, and a back button (in this example, a button containing the text "Back") for returning from the second notification screen to the first notification screen. When the registration button RBT is touched, information for requesting to register the official account of ZZ Drink as a friend is transmitted from terminal 20A to server 10, and the friend is registered by server 10.

[0393] (If you are friends with the official ZZ Drink account) The screen in FIG. 2-7(3B) is a 2B notification screen among notification screens for displaying notifications, and the word “Notification” is continuously displayed in the in-app location display area.

[0394] In this example, the notice information display area displays notice detail information in an expanded state, by way of example and not by way of limitation. In this example, the notification details information includes the text and image of “GET [ungenerated icon GIC2 and the words ‘Limited Monster’] with [icon and user name corresponding to ZZ drink] and friends!!”, a generation execution button MGBT, and a back button. When the generation execution button MGBT is touched, as described above, official MAID monster generation request information is transmitted from the terminal 20A to the server 10, and a monster is generated.

[0395] In this example, the above information is displayed on the notification screen, but it may be displayed on a screen other than the notification screen.

[0396] In this way, by informing the player on a notification screen or the like that a rare monster can be obtained by registering a specific official account, the player can be motivated to register the official account as a friend. Also, if the player is not friends with the official account, a path to register as a friend is provided, while if the player is already friends with the official account, a path to generate a monster from the official account is provided instead of a path to register an unnecessary friend, so that a suitable screen can be provided according to the player's situation.

[0397] For the official account, the user may be allowed to obtain a time-limited monster. Specifically, as a non-limiting example, when official MAID monster generation request information is transmitted from the terminal 20 to the server 10 within a set period (as a non-limiting example, a collaboration campaign period with the official account, etc.), the control unit 11 of the server 10 may generate a time-limited special monster. In this case, as a non-limiting example, the control unit 11 of the server 10 may generate a time-limited special monster by a method similar to the above-mentioned method based on a time-limited special monster generation table.

[0398] This modified example shows a configuration in which information such as monster generation result information related to an official account (not limited to this, an example of second information) is transmitted from server 10 to terminal 20 when monster generation request information based on that official account is transmitted from terminal 20 to server 10 via communication I / F 22 within a set period of time. As an example of an effect of the modified example obtained by such a configuration, when first information based on a third account is transmitted to a server by a communication unit within a set period, the terminal can obtain second information related to a third object from the server.

[0399] In addition, in this modification, the terminal 20 receives information about an account (not limited to this, but an example of a fourth account) that is not registered as a friend of the account of the user of the terminal 20 as an official account type in the messaging service from the server 10 via the communication I / F 22. Then, the terminal 20 shows a configuration in which the received information about the account is displayed on the display unit 24. As an example of the effect of the modified example obtained by such a configuration, the terminal can obtain information on a fourth account of a second type on the SNS that is not associated with the terminal user's account from the server, and then display the obtained information on the fourth account to inform the terminal user.

[0400] In this case, the information about the fourth account may include information that prompts the user of the terminal to register the fourth account as a friend on the messaging service as a type of official account. As an example of the effect of this modified example obtained by such a configuration, the user of the terminal can be prompted to associate a fourth account of the second type with his / her own account on the SNS.

[0401] In this case, the terminal 20 may perform processing related to associating the account of the user of the terminal 20 with the above-mentioned fourth account as an official account, based on input by the user of the terminal 20 into information such as a friend registration button (not limited to this, an example of information related to the fourth account). As an example of the effect of the modified example obtained by such a configuration, the account of the user of the terminal can be associated with the fourth account as the second type based on an input by the user of the terminal regarding information related to the fourth account.

[0402] In this case, the terminal 20 displays information about the fourth account on the display unit 24 after processing is performed to associate the account of the user of the terminal 20 as an official account with the fourth account. Then, the terminal 20 transmits monster generation request information (not limited to, an example of first information) based on the fourth account to the server 10 via the communication I / F 22 based on an input by the user of the terminal 20 to the information about the fourth account displayed on the display unit 24. Then, based on the transmission of the monster generation request information, the terminal 20 may receive information (not limited to, an example of second information) about a monster that is based on the fourth object (not limited to, an example of the fourth object) from the server 10 via the communication I / F 22, and display the monster on the display unit 24. As an example of an effect of the modified example obtained by such a configuration, after processing has been performed to associate the terminal's account with a fourth account as the second type, the terminal can receive second information regarding an object based on the fourth account from the server and display the fourth object on the display unit.

[0403] <Third Example> The third embodiment is an embodiment relating to setting the friend from whom the monster was generated as a parent, and other related content.

[0404] The contents described in the third embodiment are applicable to any of the other embodiments and other modified examples. Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

[0405] <Display screen> In the following, as an example and not a limitation, a screen diagram is illustrated in which terminal 20A is positioned so that display unit 24 of the display provided in terminal 20A has a horizontally long display screen, and terminal 20B is positioned so that display unit 24 of the display provided in terminal 20B has a vertically long display screen. Also, here, an example is illustrated in which a friend who is the source of a monster generated in a game application is set as the parent of this monster.

[0406] FIG. 3-1 is a diagram showing an example of a screen of a game application displayed on the display unit 24 of the terminal 20A and a screen of a messaging application displayed on the display unit 24 of the terminal 20B in this embodiment. Here, the left side of Figure 3-1: (1A) to (4A) shows examples of screens (home screen, generated screen) displayed on the display unit 24 of terminal 20A of user AA, and the right side of Figure 3-1: (1B) shows examples of a screen (talk room screen) displayed on the display unit 24 of terminal 20B of user BB.

[0407] (Display screen of terminal 20A) Regarding the display screens in FIGS. 3-1(1A) to (4A), the explanation of the parts that are similar to those in FIGS. 1-8(4) to (6) described above will be omitted.

[0408] In the lower left corner of the screen in Figure 3-1 (3A), a notification button PBT (in this example, a button containing the words "Tell the friend who created the monster the result") is displayed for notifying the friend who created the monster of the results.

[0409] (Display screen of terminal 20A → Display screen of terminal 20B) As an example and not a limitation, when a user touches a notification button PBT on the display unit 24 of the terminal 20A as shown in FIG. 3-1(3A), a display as shown in FIG. 3-1(1B) is displayed on the display unit 24B of the terminal 20B. This screen is a chat room screen in a messaging application, and the words "Messaging App" are displayed in the top center of the screen as the name of the messaging application, and an icon image and user name (in this example, "User BB") in the messaging application of the user of terminal 20B are displayed in the top right corner of the screen.

[0410] On this talk room screen, below the area at the top of the screen where the name of the messaging application and the like are displayed, a talk room name display area including the name of the talk room (hereinafter referred to as the "talk room name") is provided as a type of area indicating which page (in this example, the talk room) in the messaging application is currently displayed, for example and not by way of limitation. The talk room name display area can also be considered an area indicating the page (in this example, the talk room) in the messaging application where the user is currently located. In this example, the talk room name display area displays, by way of example and not limitation, a back button "<" to return to the previous screen, and text (in this example, "AA") indicating that this is a talk room for user BB to talk with user AA.

[0411] Below that is a talk area where users BB and AA can talk in an interactive format, with messages from the other user, user AA, displayed on the left side of the screen and messages from user BB, displayed on the right side of the screen. In this example, a message MS1 (in this example, the text "When I generated a monster with you, this monster was born", a generated icon GIC1B corresponding to monster B and the name of the monster, and a details button DBT (in this example, a button containing the text "Click here for details") containing link information to the game application for checking detailed information related to the monster generation in the game application) are displayed in the talk area in association with the icon of user AA.

[0412] Here, as an example and not as a limitation, when the details button DBT is touched by the user BB, as an example and not as a limitation, a game application may be launched on the terminal 20B, and a screen including detailed information related to the monster generation shown in the message MS1 (as an example and not as a limitation, the parameter values ​​of monster B, a monster generation screen, etc.) may be displayed (not shown).

[0413] (Display screen of terminal 20A) As an example and not by way of limitation, when a user touches notification button PBT on display unit 24 of terminal 20A as shown in FIG. 3-1(3A), and then monster parent setting information is received by terminal 20A, a display as shown in FIG. 3-1(4A) is displayed as an example and not by way of limitation. On this screen, the notification button PBT (in this example, a button containing the text "Tell the friend who created the result") has disappeared from the bottom left of the screen in Figure 3-1 (3A), and the monster parent setting completion information PSIC (in this example, an icon containing the text "BB has been set as parent") is displayed in the top left of the screen, and a parent icon (in this example, an icon containing the text "<Parent: BB>") is displayed below monster B.

[0414] In this way, by notifying the friend who generated the monster in the game application of the monster generation result using a messaging application, the game can be promoted to users other than the player user. Also, by configuring the monster to be set as a parent when the condition of notifying the friend who generated the monster of the monster generation result using a messaging application is met, the player can freely select whether or not to set a parent for the monster.

[0415] Next, an example will be given of notifying a parent that a monster has won a battle in a game application.

[0416] Like Figure 3-1, Figure 3-2 shows examples of screens (battle screens) displayed on the display 24 of terminal 20A of user AA on the left side of Figure 3-2: (1A) to (3A), and a screen (talk room screen) displayed on the display 24 of terminal 20B of user BB on the right side of Figure 3-1: (1B).

[0417] (Display screen of terminal 20A) The screen in Figure 3-2 (1A) is a 3C battle screen among the battle screens for battling using monsters, and the words "Battle Stage" are displayed in the in-app position display area. In this example, a victory performance is being executed, and the battle information display area displays 3C battle information (as an example and not a limitation, the word "WIN", Monster B with a happy expression, and a parent icon below Monster B (in this example, an icon containing the words "<Parent: BB>")).

[0418] By way of example and not limitation, when the victory presentation ends, a display such as that shown in FIG. 3-2(2A) may be displayed. This screen is the fourth battle screen among the battle screens for battling monsters, and the words "Battle Stage" are continuously displayed in the in-app position display area.

[0419] In this example, the battle information display area displays fourth battle information (as an example, but not limited to, the text "Do you want Monster B to defeat its parent?" and "Would you like to report this to them?"), the main monster that won the battle (in this example, Monster B with a pleased expression), a YES button BT1 for answering [YES] to the above information, and a NO button BT2 for answering [NO] to the above information).

[0420] (Display screen of terminal 20A → Display screen of terminal 20B) As an example, not a limitation, when the YES button BT1 on the display unit 24 of the terminal 20A is touched by the user as shown in Fig. 3-2(2A), a display as shown in Fig. 3-2(1B) is displayed on the display unit 24 of the terminal 20B as an example, not a limitation. Regarding the display screen in Fig. 3-2(1B), the description of the parts that are similar to those in Fig. 3-1(1B) described above will be omitted.

[0421] In this example, a message MS2 (in this example, the text "The monster born from you has achieved a splendid victory!"), a generated icon GIC1B corresponding to monster B, information related to the monster battle (in this example, the text "VS", "Monster C", and "WIN"), and a details button DBT (in this example, a button containing the text "Click here for details") containing link information to the game application for checking detailed information related to the battle in the game application are displayed in the talk area in association with the icon of user AA.

[0422] Here, as an example and not as a limitation, when the details button DBT is touched by the user BB, a game application may be launched on the terminal 20B, and a screen including detailed information related to the battle shown in the message MS2 (as an example and not as a limitation, a thumbnail screen (video) related to the state of the battle, a screen similar to the 3C battle screen displayed on the display unit 24 of the terminal 20A, etc.) may be displayed (not shown).

[0423] (Display screen of terminal 20A) As an example, but not limited to, as shown in FIG. 3-2(2A), when a user touches the YES button BT1 on the display unit 24 of the terminal 20A, a display as shown in FIG. 3-2(3A) is displayed on the display unit 24 of the terminal 20A. This screen is the fifth battle screen among the battle screens for battling monsters, and the words "Battle Stage" are continuously displayed in the in-app position display area.

[0424] In this example, the battle information display area displays the fifth battle information (as an example, and not a limitation, the words "Monster B is happy" and the main monster who won the battle (in this example, Monster B with an embarrassed expression)).

[0425] As an example and not a limitation, even if the NO button BT2 on the display unit 24 of the terminal 20A in FIG. 3-2(2A) is touched by the user, the display unit 24 of the terminal 20A may be made to display the same as that in FIG. 3-2(3A), by way of example and not by way of limitation. In this case, the battle information display area can display the fifth battle information (as an example, but not limited to, the text "When I told Monster B I'd let him know the next time we met, he seemed pleased" and the main monster that won the battle (in this example, Monster B has an embarrassed expression)).

[0426] In this way, when any event related to a monster occurs (for example and not limitation, when a battle is won, when a monster's training is completed (when a parameter value reaches its maximum value), etc.), the occurrence of this event can be notified to the parent of the monster (the friend who generated it) using a messaging application, thereby advertising and promoting the game to other users other than the player user.

[0427] In addition, by displaying the same battle information regardless of whether the occurrence of an event has been notified to the parent of the monster (the friend who generated the monster), it is possible to prevent the parent from feeling annoyed by being notified every time an event occurs. Also, by not neglecting the monster, the player can prevent a decrease in the interest of the game, which has the gameplay of raising monsters.

[0428] Next, an example will be given in which the parent of one's monster and the parent of the enemy monster are the same in a battle in a game application.

[0429] In this embodiment, in a battle in a game application, if the parent of one's monster and the parent of an enemy monster match, a bond effect can be executed in which the parameter value of one's monster increases. In this bond performance, in a scene where it is recognizable that the parent of one's monster and the parent of the enemy monster are the same (as a non-limiting example, when one's monster, the enemy monster, and the letters "VS" are displayed), bond effect information (as a non-limiting example, an image of a flame, an image containing the letters "UP", an image containing the letters "bond", etc.) is displayed near one's monster, and commentary information to explain the situation (as a non-limiting example, an image resembling a speaker and a speech bubble image containing the letters "Monster B is excited!") is displayed. Also, in the bond performance, the parameter value of one's monster increases internally, so the parameter value that has increased internally in relation to the bond performance may be visualized by displaying information related to the increased value of the parameter value (as a non-limiting example, the letters "Strength | +5" and the letters "ALL | +3" ("ALL" refers to all parameter values).

[0430] 3-3 is a diagram showing an example of a screen of a game application displayed on the display unit 24 of the terminal 20A in this embodiment. Here, a screen (battle screen) displayed on the display unit 24 of the terminal 20A of the user AA is shown as an example.

[0431] Regarding the display screens in FIGS. 3-3(1) and (2), explanations of the parts that are similar to those in FIG. 1-10(3) described above will be omitted.

[0432] In the 2C battle screen of Figure 3-3 (1), the battle information display area displays 2C battle information (as an example and not a limitation, the player's side monster information (in this example, monster B, a parent icon (in this example, an icon containing the letters "<Parent: BB>"), and the name and icon image of user AA), the letters "VS", and the enemy player's side monster information (in this example, monster C, a parent icon (in this example, an icon containing the letters "<Parent: BB>"), and the name and icon image of user BB)).

[0433] By way of example, and not by way of limitation, when the conditions for executing a bond effect are met, a display such as that shown in FIG. 3-3(2) may be displayed. In this screen, a bond performance is being performed, with bond effect information EF1 (as an example, not a limitation, a flame image) being displayed in the background of Monster B, and commentary information (as an example, not a limitation, a speaker image and a speech bubble image containing the words "Monster B is excited!") being displayed above Monster B.

[0434] In this way, in a battle in the game application, if the parent of your monster and the parent of the enemy monster match, a bond effect is executed in which the parameter value of your monster is increased, thereby increasing the interest of the game, which has the gameplay of being able to set the parent of a monster.

[0435] <Processing> 3-4 to 3-5 are flowcharts showing an example of the flow of processing executed by each device in this embodiment. Here, a processing example in the case of applying the communication system 1A shown in FIG. 1-1 is shown, and the processing part corresponding to FIG. 1-12 is shown. In the following diagram, from the left, there are shown a process executed by the control unit 21 of the terminal 20A, a process executed by the control unit 11 of the server 10, and a process executed by the control unit 21 of the terminal 20B.

[0436] After step A190, the control unit 21 of the terminal 20A determines whether or not to notify the source friend of the monster generation result, for example by determining whether or not a user input has been made to the notification button in the displayed general MAID monster generation result information (C200).

[0437] If it is determined that the monster generation result should be notified to the source friend (C200: YES), the control unit 21 of the terminal 20A sends monster generation result notification information including, by way of example and not limitation, general MAID monster generation result information to the server 10 via the communication I / F 22 (C210).

[0438] When the monster generation result notification information is received from terminal 20A via communication I / F 14, control unit 11 of server 10 transmits the monster generation result notification information to terminal 20B via communication I / F 14, for example and not limitation (S192).

[0439] When the monster generation result notification information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20B causes the display unit 24 to display the monster generation result notification information based on the received monster generation result notification information (D210). In this case, the control unit 21 of the terminal 20B can, by way of example and not limitation, cause the monster generation result notification information to be displayed on the display unit 24 (such as a chat room displayed on the display unit 24) by a messaging application.

[0440] After step S192, the control unit 11 of the server 10 performs a monster parent setting process (S194), for example and not for limitation. Specifically, for example and not for limitation, the control unit 11 sets the original user (user BB) as the parent of the monster included in the monster generation result notification information (monster generated based on user BB) according to the monster parent setting program. Then, information about the monster that has been set as the parent is stored in the player management data in which the player ID of user AA is stored.

[0441] After S194, the control unit 11 of the server 10 transmits, by way of example and not limitation, monster parent setting information to the terminal 20A via the communication I / F 14 (S196).

[0442] When the monster parent setting information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20A causes the display unit 24 to display the monster parent setting information based on the received monster parent setting information (C220).

[0443] Note that, as an example and not a limitation, the control unit 21 of the terminal 20B may be able to send a message to the terminal 20A by a messaging application via the server 10 based on a user input to the monster generation result notification information displayed on the display unit 24. Then, the control unit 21 of the terminal 20A may be able to display the received message by the messaging application.

[0444] 3-6 is a flow chart showing an example of the flow of the monster battle victory process executed by each device in this embodiment. Here, a processing example is shown in which the communication system 1A shown in FIG. 1-1 is applied.

[0445] First, the control unit 21 of the terminal 20A determines whether or not the monster will win the battle by, for example and not by way of limitation, determining whether or not it has been determined that the monster will win the monster battle (for example, "the enemy monster's vitality has been reduced to 0 in the battle," "the battle time limit has elapsed with the monster's remaining vitality being greater than that of the enemy monster," etc.) (C310).

[0446] If it is determined that the monster battle has been won (C310: YES), the control unit 21 of the terminal 20A causes the display unit 24 to display battle victory information including, by way of example and not limitation, information that the player's monster has won the battle (C320).

[0447] Thereafter, the control unit 21 of the terminal 20A determines whether or not to notify the source friend (parent) of the battle victory, for example by determining whether or not the user has input the YES button on the displayed battle victory information (fourth battle screen) (C330).

[0448] If it is determined that the source friend (parent) should be notified of the battle victory (C330: YES), the control unit 21 of the terminal 20A sends battle victory notification information including the battle victory information to the server 10 via the communication I / F 22, for example and not limitation (C340).

[0449] When the battle victory notification information is received from the terminal 20A via the communication I / F 14, the control unit 11 of the server 10 transmits the battle victory notification information to the terminal 20B via the communication I / F 14, for example and not for limitation (S310).

[0450] When the battle victory notification information is received from the server 10 via the communication I / F 22, the control unit 21 of the terminal 20B causes the battle victory notification information to be displayed on the display unit 24 based on the received battle victory notification information (D310). In this case, the control unit 21 of the terminal 20B can, by way of example and not limitation, cause the battle victory notification information to be displayed on the display unit 24 (such as a talk room displayed on the display unit 24) by a messaging application.

[0451] Note that, as an example and not a limitation, the control unit 21 of the terminal 20B may be able to transmit a message to the terminal 20A by a messaging application via the server 10 based on a user input for the battle victory notification information displayed on the display unit 24. Then, the control unit 21 of the terminal 20A may be able to display the received message by the messaging application.

[0452] After steps C330: NO or C340, when a user inputs either the NO button or the YES button on the displayed battle victory information (fourth battle screen), the control unit 21 of the terminal 20A causes the display unit 24 to display battle victory notification completion information (C350).

[0453] Next, the control unit 21 of the terminal 20A determines whether or not to end the monster battle victory process (C360). If it is determined that the process should be continued (C360: NO), then, by way of example and not limitation, the control unit 21 of the terminal 20A returns the process to C310. On the other hand, if it is determined that the process should be ended (C360: YES), the control unit 21 of the terminal 20A ends the monster battle victory process.

[0454] After step S310, the control unit 11 of the server 10 determines whether or not to end the monster battle victory process (S360). If it is determined to continue the process (S360: NO), the control unit 11 of the server 10 waits to receive battle victory notification information from the terminal 20A, for example and not for limitation, and if received, executes the process of S310 again. On the other hand, if it is determined that the process should be ended (S360: YES), the control unit 11 of the server 10 ends the monster battle victory process.

[0455] Next, the control unit 21 of the terminal 20B determines whether or not to end the monster battle victory process (D360). If it is determined to continue the processing (D360: NO), the control unit 21 of the terminal 20B waits to receive battle victory notification information from the server 10, for example and not limitation, and if received, executes the processing of D310 again. On the other hand, if it is determined that the process is to be ended (D360: YES), the control unit 21 of the terminal 20B ends the monster battle victory process.

[0456] <Effects of the third embodiment> In this embodiment, the terminal 20 is configured to perform processing via the control unit 21 to send a message regarding a monster to the first account via a messaging application based on the satisfaction of a set condition (not limited to, but an example of a first condition) regarding a monster (not limited to, but an example of a first object) based on the first account. As an example of an effect of an embodiment obtained by such a configuration, based on the satisfaction of a first condition regarding the first object, a process is performed to send a message regarding the first object to a first account via a SNS, thereby enabling the message regarding the first object to be delivered to a user of the first account.

[0457] In this case, after performing the process related to sending the message, the terminal 20 receives the message (not limited to this, but an example of the first message) sent from the first account by the messaging service through the communication I / F 22. Then, the terminal 20 may display the message on the display unit 24 by the messaging service. As an example of an effect of an embodiment obtained by such a configuration, after performing processing related to sending a message, the first message sent from the first account via the SNS is received by the communication unit and the first message is displayed on the display unit via the SNS, thereby making it possible to inform the user of the terminal 20 of the first message sent from the first account.

[0458] In addition, in this embodiment, the game processing includes a battle processing in which monsters are pitted against each other, and the battle processing includes a process in which a predetermined event is generated in relation to the battle when the opponent's account is the first account. As an example of an effect of an embodiment obtained by such a configuration, when the opponent's account is the account from which the object was generated, by way of example and not limitation, it becomes possible to generate a special event related to the battle, thereby increasing the interest of the game.

[0459] <Other Examples> (1) The generation of objects (in-game content) is not limited to being performed by the server 10, but may be performed by the terminal 20.

[0460] (2) As an example of identification information for identifying a user, by way of example and not limitation, an object may be acquired based on contact information stored in the terminal 20 (or a cloud server). In other words, contact information stored in the terminal 20 or the like may be used, not limited to an account for a service such as an SNS, and by way of example and not limitation, an object may be generated based on contact information stored in the terminal 20 or the like, such as by using telephone number information instead of the above-mentioned MAID. In this way, even if a user has a small number of accounts associated with them on SNS, as long as a certain amount of contact information is registered in the terminal 20, it becomes possible to play the game using a certain number of objects. This may be thought of, by way of example and not limitation, as objects appearing in the game being obtained based on the identity information of other users associated with the user, and contact information may be one example of a user's identity information.

[0461] In this case, the control unit 21 of the terminal 20 may display a list of contact information (by way of example and not limitation, registered telephone numbers) stored on the terminal 20, etc. as an option for obtaining an object, and the object may be determined based on the contact information selected from the list.

[0462] Additionally, objects may be obtained based on one's contact information.

[0463] (3) In the above embodiment, an example was shown in which an object appearing in a game was obtained based on an account associated with the user's account, but the account associated with the user's account is not limited to another person's account and may be the user's own account. As a non-limiting example, in a service in which sub-accounts can be registered, objects may be obtained based on a sub-account associated with a main account.

[0464] In addition, in a service where only one account can be registered, it may be possible to obtain objects based on one's own account, and in a service where sub-accounts can be registered, it may be possible to obtain objects based on the main account.

[0465] (4) In the above embodiment, an object is generated based on an account in one SNS, but this is not limiting. For example and not for limitation, the account linking process in the above embodiment may link accounts in multiple SNSs.

[0466] In this case, when displaying the list for acquiring objects, or at an earlier timing, the control unit 21 of the terminal 20 causes the display unit 24 to display a screen for allowing the user to select (or set) which SNS account to use. Then, a list of SNS accounts selected (set) by the user may be displayed on the display unit 24, and a monster may be generated based on an account selected from the list.

[0467] In addition, this list may display information indicating which SNS the list corresponds to (as an example, and not a limitation, an icon indicating the type of SNS) in association with each list item, thereby allowing the user to distinguish between each list.

[0468] (5) In the above embodiment, an example of a game in which monsters appear as in-game content is shown, but the invention is not limited to such an example and may be a game in which content other than monsters appears as in-game content.

[0469] For example and not for limitation, the game may be a game in which a vehicle appears as in-game content. In this case, the game may be a game in which a vehicle, which is a type of in-game content (object), is generated from a friend, and the generated vehicle is modified to battle (race).

[0470] For example and not limitation, the game may be one in which a human (humanoid character) appears as in-game content. In this case, the game may be one in which a humanoid character, which is a type of in-game content (object), is generated from a friend, and the generated humanoid character is trained to progress through battles and a story.

[0471] (6) In the above embodiment, an example was shown in which the main in-game content (monsters, etc.) in the game was generated from friends, but this is not limited to such an example, and in-game content other than the main in-game content (monsters, etc.) in the game may be generated from friends.

[0472] As a non-limiting example, weapons and armor equipped by monsters, which are sub-in-game content different from the main in-game content (monsters, etc.) in the game, may be generated from friends.

[0473] (7) In the above embodiment, when in-game content (monsters, etc.) is generated multiple times from a single friend, monsters with a common appearance and parameter values ​​are generated. However, this is not limited to this example, and when in-game content (monsters, etc.) is generated multiple times from a single friend, monsters with different appearances and parameter values ​​may be generated.

[0474] As an example and not as a limitation, if a monster is generated twice from a single friend, a monster A with the same appearance may be generated both times, and as an example and not as a limitation, the parameter values ​​of the monster A generated the first time may be different from the parameter values ​​of the monster A generated the second time.

[0475] Also, as a non-limiting example, if a monster is generated twice from a single friend, a monster A may be generated both times with the same parameter values, and as a non-limiting example, the monsters may have different appearances, such as the first monster A generated being a white monster A and the second monster A generated being a red monster A.

[0476] (8) In the above embodiment, an example is shown in which a player battles monsters (enemy monsters) of other players in the game, but the invention is not limited to such an example. A player may battle enemy monsters together with (cooperate with) the monsters of other players in the game, or may battle monsters (enemy monsters) of a virtual player (CPU) in the game.

[0477] Furthermore, battles are not essential, and as a non-limiting example, the above embodiment may be a game in which only monsters are raised (a game in which the player can enjoy raising monsters).

[0478] (9) In the above embodiment, an example was shown in which in-game content (limited edition monster) is generated when one official account (ZZ Drink) is registered as a friend, but this is not limited to such an example, and the type of in-game content generated may differ depending on the official account registered as a friend.

[0479] As a non-limiting example, when a first official account is registered as a friend, in-game content (a first limited monster) may be generated, and when a second official account is registered as a friend, in-game content (a second limited monster) may be generated.

[0480] (10) In the above embodiment, an example was shown in which no upper limit was placed on the number of times that a monster could be generated from friends. However, the present invention is not limited to this example, and an upper limit may be placed on the number of times that a monster can be generated from friends.

[0481] This also relates to the first variant example (2), but by way of example and not limitation, monster generation may be performed when at least one of the following conditions (a) to (c) is met: (a) If you have not spawned monsters more than 10 times in a day (b) When using in-game content (such as one coin for generating monsters) (c) When you clear an in-game event (winning five battles in a row).

[0482] (7) In the above embodiment, when choosing whether or not to notify the parent that the monster has won a battle, the player selects from the options of [YES] or [NO]. However, the present invention is not limited to this example, and when choosing whether or not to notify the parent that the monster has won a battle, the player may select from options other than the options of [YES] or [NO].

[0483] As a non-limiting example, when choosing whether or not to notify a parent that a monster has won a battle, the player may select from an option that corresponds to [YES], which includes the words "I'll send a message," or an option that corresponds to [NO], which includes the words "I'll let them know the next time we meet."

[0484] (11) In the above embodiment, an example was shown in which the characteristics of a monster type were expressed by varying the monster's external appearance characteristics. However, the present invention is not limited to this example, and the characteristics of a monster type may be expressed by varying an element other than the monster's external appearance characteristics.

[0485] For example and not for limitation, a monster personality trait may be set for each monster. The monster personality trait is set to a personality trait of a monster of a corresponding monster type, and for example and not for limitation, a monster personality trait such as "hot-blooded," "violent," "serious," "impatient," etc. may be set for each monster type.

[0486] Also, by way of example and not limitation, this monster personality trait may affect the raising and battling of the monster. By way of example and not limitation, in raising a monster, a monster having a "hot-blooded" monster personality trait may be good at "stamina-up training" (high success rate, high increase value), a monster having a "violent" monster personality trait may be good at "strength-up training", a monster having a "serious" monster personality trait may be good at "protection-up training", and a monster having a "impatient" monster personality trait may be good at "speed-up training".

[0487] Also, by way of example and not limitation, a monster individual value characteristic may be set for each monster. The monster individual value characteristic is set to a characteristic of the individual value of a monster of a corresponding monster type, and by way of example and not limitation, parameter values ​​having different initial values ​​may be set for each monster type.

[0488] (12) In the above embodiment, when a monster is generated from a general friend, the type of monster (including the monster's type, personality traits, individual value traits, etc.) is determined based on a general MAID. However, the present invention is not limited to this example, and when a monster is generated from a general friend, the type of monster to be generated may be determined based on information other than the general MAID.

[0489] As a non-limiting example, when a monster is generated from a general friend, the type of monster generated may be determined based on attribute information of the general friend (for example, but not limited to, gender, age, nationality, etc.). However, when generating a monster using the attribute information of this general friend, it is necessary to obtain approval from this general friend before actually performing the monster generation process on the server 10.

[0490] Also, by way of example and not limitation, when a monster is generated from a general friend, the type of monster to be generated may be determined based on the time, date, time period, etc. at which the monster is generated. Specifically, monsters generated between 0:00 and 11:00 may be more likely to be a first type of monster (by way of example and not limitation, Monster A, Monster B, "Hot-blooded," "Earnest," etc.), while monsters generated between 12:00 and 23:00 may be more likely to be a second type of monster (by way of example and not limitation, Monster C, Monster D, "Violent," "Impatient," etc.).

[0491] Furthermore, the type of monster to be generated may be determined by a combination of the various types of information described above, including the general MAID.

[0492] (13) In the above embodiment, when a monster that a player already possesses is generated, an example was shown in which there was no provision for an effective use of this common monster. However, the present invention is not limited to this example, and when a monster that a player already possesses is generated, there may be provided an effective use of this common monster.

[0493] By way of example and not limitation, the following method may be provided as an effective way of utilizing common monsters. (A) It is converted into a material (strengthening item) for monster strengthening and given to the player. (Monster strengthening is a game element in which the monster's parameter value etc. increases by synthesizing the monster with the strengthening item.) (B) Converted into a support card and given to the player

[0494] <Fourth Example> The fourth embodiment is an embodiment in which a player shares the generated monster on a social networking site and other related content.

[0495] The contents described in the fourth embodiment are applicable to the other embodiments and other modified examples. Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

[0496] <System configuration> FIG. 4-1 is a diagram showing an example of a system configuration of a communication system 1C in this embodiment. In the communication system 1C, by way of example and not limitation, multiple SNS servers 40 (SNS server 40X, SNS server 40Y, ...) (the aforementioned messaging server 40 may be applied as a type of SNS server 40, so for convenience it is referred to as "40", but it may also be a server of an SNS other than the messaging server 40), a game server 50, and multiple terminals 20 (terminal 20A, terminal 20B, ..., terminal 20M, ...) are connected via a network 30. The HW configuration of each device may be the same as in the above-described embodiment, and therefore a description thereof will be omitted.

[0497] The SNS server 40X may be, for example and without limitation, a server (first SNS server) that manages information related to a first SNS among the SNSs.

[0498] The SNS server 40Y may be, for example and without limitation, a server (second SNS server) that manages information related to a second SNS among the SNSs.

[0499] The first SNS and the second SNS may be different SNSs, and the type and form of the SNSs are not important. The operator of the first SNS and the operator of the second SNS may be different operators or may be the same operator.

[0500] In the following, by way of example and not limitation, the first SNS may be described as the messaging service described above, and the second SNS may be described as a business SNS, which is an example of an SNS different from the messaging service. In addition, a first SNS application (hereinafter referred to as the "first SNS application") may be illustrated and described as a "Messaging App", and a second SNS application (hereinafter referred to as the "second SNS application") may be illustrated and described as a "Business App".

[0501] In the following description, the timeline may be described as a screen that displays user comments, events, and the like in chronological order in the SNS application (a screen that displays events in chronological order).

[0502] <Display screen> Below, examples are described regarding the display screen of terminal 20A of user AA, who is a player, and the display screen of terminal 20 of user MM, who is friends with user AA on the SNS (user AA's account is associated with his / her own account).

[0503] FIG. 4-2 is a diagram showing an example of sharing the results of monster generation on a social networking site. The screens shown in (1A) to (3A) are displayed on the display unit 24 of the terminal 20A of the user AA, who is a game player, during the process of generating a monster. The explanation of these is the same as that given with reference to Figures 1-8, so explanation will be omitted except for the different characteristic parts.

[0504] As mentioned above, the generation of a monster may be executed by the game server 50 based on a request from the player's terminal 20A, and the control unit 21 of the terminal 20A may receive the generation result via the communication I / F 22 (an example of obtaining a first object), or the control unit 21 may execute the generation by a game application in the terminal 20A (an example of obtaining a first object).

[0505] Unlike the example shown in FIG. 1-8(6), the screen shown in FIG. 4-2(3A) includes a share button SBT, which displays "Share generation results on SNS." When user A (player) taps the share button SBT, information about the generated monster and information about the user who generated the monster are shared on an SNS where user AA has an account (e.g., a first SNS).

[0506] (1M) in Fig. 4-2 is a diagram showing an example of content posted to the account of user AA in a first SNS (messaging application) by user AA tapping the share button SBT. This terminal 20M is a terminal of user MM (e.g., a user different from the player and different from the user who generated the content) who has an account in the first SNS, and the content posted to the first SNS (information shared within the first SNS) is displayed via an application of the first SNS (e.g., an application that provides a user interface displayed as "Messaging App").

[0507] In the example of (1M), information shared by user AA is displayed as timeline information on the first SNS. Corresponding to the profile image used by user AA on the first SNS and the registered name (AA) of user A on the first SNS, a message saying "Monster B was born when a monster was generated from BB (@bb1234)" and an image of the generated monster are displayed. This message includes the account ID (@bb1234) of user BB, who generated monster B, and the registered name (BB) of user BB on the SNS that includes that account ID.

[0508] In addition, below the content posted by user A, a message from user CC (a user different from the player and different from the user who generated the post) who has an account on the first SNS is displayed corresponding to the icon image and registered name (CC) on the first SNS.

[0509] (1M) When user MM taps the button OBT labeled "Open Game" displayed to the right of the monster image, if the game is already installed on terminal 20M, the screen will transition to a game screen (e.g., a monster generation screen) based on user MM's game account, and if the game is not installed, the screen will transition to a game installation screen. In this way, the generated monsters can be shared on social networking sites, making it possible to increase the number of game players.

[0510] In (1M), a link is set to the account ID (@bb1234) of user B, from which the monster was generated, and when user MM taps on that account ID, the user is taken to a page on the SNS containing that account ID, which discloses information about user BB, as shown in (2M).

[0511] In the example of (2M), based on the fact that the account ID (@bb1234) is the account ID of the first SNS, the screen transitions to one in which the profile of user BB on the first SNS is disclosed. In this example, the profile of user BB includes an icon image of user BB on the first SNS, the registered name (BB) of user BB on the first SNS, and the account ID (@bb1234) of user BB on the first SNS, and a message from user BB regarding a game is also displayed. Along with this information, a friend button FOBT that reads "Become a Friend" is displayed.

[0512] When user MM taps the friend button FOBT, a friend registration request for the user BB who generated the request is sent from terminal 20M to the SNS server 40X of the first SNS, and the SNS server 40X, upon receiving this, sends a confirmation message to user BB's account (terminal 20B) to confirm whether or not to allow the user MM to be registered as a friend.

[0513] When user BB sees the confirmation message (e.g., "MM has requested to register as a friend. Would you like to become friends with MM?") received by terminal 20B and displayed on display 24, and makes an input to permit the friend registration (e.g., operates a button labeled "Become a friend" that is displayed along with the confirmation message), a friend registration permission is sent to SNS server 40X, and in SNS server 40X, the account ID of user BB is linked to the account ID of user MM (they are registered as friends). In this way, the fun of making more friends on SNS can be provided to people other than game players.

[0514] Furthermore, if user BB becomes a game player as a result of user MM becoming a friend on the first SNS, user BB will thereafter be able to generate monsters with user MM as the generator (for example, based on user MM's general MAID, as described above).In this way, user BB, who is both the generator and the player, can enjoy a cycle of gaining more friends by sharing the monsters he or she generated, and then generating monsters from those friends.

[0515] In the example of (2M), a post button POBT displaying "Post" and a like button FABT displaying "Like" are provided at the bottom of the screen. When the post button POBT is tapped by user MM, a list of information posted by user BB in the past is displayed. When the like button FABT is tapped by user MM, a list of information posted by users other than user B that user BB has given high ratings to (user BB tapped the like button) is displayed.

[0516] <Processing> FIG. 4-3 is a flowchart showing an example of the flow of processes executed by each device in this embodiment. In this figure, from the left, there are shown a process executed by the control unit 51 of the game server 50, a process executed by the control unit of the SNS server 40X, and a process executed by the control unit 21 of the terminal 20M of the user MM. This process may be, for example and not by way of limitation, executed by each device including the control unit 21 of the terminal 20A of the user AA after the terminal 20A performs step A190 described above. The processing of the control unit 21 of the terminal 20A is omitted in the drawing.

[0517] In addition, in this process, as an example and not a limitation, the terminal 20 that displays the timeline in the first SNS application is the terminal 20M, and its user is the user MM.

[0518] After step A190, the control unit 51 of the game server 50 determines whether or not SNS sharing request information has been received from the terminal 20A of user AA via the communication I / F 14 (G410). The SNS sharing request information may be, for example and not limitation, information requested by user AA to share the monster generated by the above-mentioned monster generation and the user who generated (parent) the monster (hereinafter referred to as the "generator user") on the timeline of the first SNS in this example (an example of information for displaying the generated object and corresponding information corresponding to the generator user on the SNS). The SNS sharing request information may include, for example and not limitation, information that can identify the monster and information that can identify the generator user, in addition to information such as the application ID of user AA.

[0519] If it is determined that the SNS sharing request information has been received from the terminal 20A (G410: YES), the control unit 51 of the game server 50 transmits the SNS sharing request information to the SNS server 40X via the communication I / F 14 (G430).

[0520] The control unit 41 of the SNS server 40X determines whether or not SNS sharing request information has been received from the terminal 20A via the communication I / F 14, and if it is determined that it has been received, performs an SNS update process (X410). Specifically, as an example and not a limitation, based on the information contained in the received SNS sharing request information, processing is performed to share the generated monster and information regarding the user who generated the monster on the first SNS.

[0521] Note that the control unit 41 of the SNS server 40X may determine whether or not to include information about the generating user included in the SNS sharing request information in the timeline update information in step X410. The information about the generating user may be displayed, or may be kept secret without being displayed.

[0522] Next, the control unit 41 of the SNS server 40X transmits the timeline update information to the terminal 20M via the communication I / F 14 (X430). The timeline update information may be, for example and without limitation, information for updating and displaying information based on the results of step X410 with respect to the latest timeline information.

[0523] When the timeline update information is received from the SNS server 40X via the communications I / F 22, the control unit 21 of the terminal 20M causes the display unit 24 to display a timeline based on the received timeline update information (M430).

[0524] After step G430, the control unit 51 of the game server 50 proceeds to determine whether to end the processing (G195), and if it determines to continue the processing (G195: NO), then, by way of example and not limitation, the processing returns to the beginning and waits to receive SNS sharing request information from terminal 20A. If it is determined that the processing should be ended (G195; YES), the processing is ended.

[0525] After step X430, the control unit 41 of the SNS server 40X proceeds to determine whether to end the processing (X195), and if it determines that the processing should continue (X195: NO), then, by way of example and not limitation, the processing returns to the beginning and waits to receive SNS sharing request information from the game server 50. If it is determined that the processing should be terminated (X195; YES), the processing is terminated.

[0526] After M430, the control unit 21 of the terminal 20M proceeds to determine whether to end the processing (M195), and if it determines to continue the processing (M195: NO), then, by way of example and not limitation, the processing returns to the beginning and waits to receive timeline update information from the SNS server 40X. If it is determined that the processing should be ended (M195; YES), the processing is ended.

[0527] In this process, the SNS sharing request information is transmitted from the terminal 20A to the game server 50, but the present invention is not limited to this. As a non-limiting example, the terminal 20A may transmit SNS sharing request information to the SNS server 40X.

[0528] (Control of each device in the flowchart) (F-1) In the above embodiment, the control by terminal 20A to send SNS share request information to game server 50 (or SNS server 40X via game server 50) based on input by user AA (operation of share button SBT) is control (not limiting, an example of a first control) executed on terminal 20 for displaying, on the SNS, the generated monster (not limiting, an example of a first object) and information about the user who generated the monster (not limiting, an example of corresponding information corresponding to the first account).

[0529] Displaying the first object and the corresponding information on the SNS (or sharing the first object and the corresponding information on the SNS) may include, by way of example and not limitation, displaying the first object and the corresponding information based on information received from the SNS server 40 on terminal 20M of user MM (a user different from the player and different from the generation source) who has an account on the SNS (for example, M430 in Figure 4-3, M432 in Figure 4-12 described below, and M434 and M474 in Figure 4-14).

[0530] In addition, displaying the first object and the corresponding information on the SNS (or sharing the first object and the corresponding information on the SNS) may include, by way of example and without limitation, displaying the first object and the corresponding information based on information received from the SNS server 40 on terminal 20B of user BB, who is the originating user and has an account on the SNS (for example, processing equivalent to M430 in Figure 4-3, M432 in Figure 4-12 described below, and M434 and M474 in Figure 4-14).

[0531] In addition, displaying the first object and the corresponding information on the SNS (or sharing the first object and the corresponding information on the SNS) may include, by way of example and not limitation, displaying the first object and the corresponding information based on information received from the SNS server 40 on terminal 20A of user AA (the player who operated the share button SBT), who is a player who has an account on the SNS (for example, processing equivalent to M430 in Figure 4-3, M432 in Figure 4-12 described below, and M434 and M474 in Figure 4-14).

[0532] The above-mentioned first control may include control to request the server to share information (control to transmit sharing request information), regardless of the presence or absence of a user input to the terminal 20. Furthermore, the first control may include, for example and not for limitation, control for setting manual sharing / automatic sharing of information based on a user input to the terminal 20. For example and not for limitation, a user may set automatic sharing to "Yes" in advance, and the setting information may be transmitted from the terminal 20 to the server, and the server may store "Yes" for automatic sharing in association with the user's account, so that information is automatically shared from the server. Also, instead of being set by the user, sharing may be automatically set to "Yes" on the server side.

[0533] (F-2) When a game application is running on terminal 20, for example and not by way of limitation, an SNS application may be launched (including deploying the SNS application on the game application) based on an input to share information, and the user of terminal 20 may be able to instruct the SNS server 40 to post information from the SNS application.

[0534] FIG. 4-4 is a screen diagram showing an example in which sharing is performed by an SNS application linked to a game application on the terminal 20A of a player who wishes to share the created monster. (1) is a diagram similar to the diagram shown in (3A) of Figure 4-2.

[0535] In (1), when the player taps the share button SBT, the SNS application of the first SNS linked to the game application is started based on the input operation, and the user interface (UI) of the SNS application is displayed together with the user interface (UI) of the game application, as shown in (2). Note that the UI of the SNS application may be displayed after the UI of the game application is hidden.

[0536] In (2), within the UI of the SNS application, the registered name (BB) and account ID (@bb1234) of the original user on the first SNS, as well as an image of Monster B generated from the original user, are displayed in association with the player's icon image and registered name (AA) on the first SNS (the SNS to which the share is made) (i.e., as the player's post content).

[0537] Furthermore, a post button POBT and a cancel button CABT are displayed within the UI of the SNS application, and when the player taps the post button POBT, the information within the UI of the SNS application (the registered name (BB) and account ID (@bb1234) of the original user on the first SNS, and an image of monster B generated from the original user) is shared on the first SNS as the player's post (along with the player's icon image and registered name (AA)).

[0538] Then, as shown in (3), the UI of the SNS application notifies the user that posting has been completed (that the information has been shared on the first SNS). On the other hand, if the cancel button CABT is tapped in (2), the information in the UI of the SNS application is not shared.

[0539] FIG. 4-5 is a flowchart showing an example of the flow of processes executed by each device in this modified example. In this figure, the left side shows the processing executed by the control unit 21 of the terminal 20A, and the right side shows the processing executed by the control unit 41 of the SNS server 40X of the first SNS.

[0540] The control unit 21 of the terminal 20A determines whether or not an input for sharing information on an SNS has been made in the game application via the input / output unit 23 (A510). If it is determined that the transfer has not been performed (A510: NO), the control unit 21 of the terminal 20A advances the process to the termination determination of A590.

[0541] If it is determined that input has been made (A510: YES), the control unit 21 of the terminal 20A deploys an SNS application (in this example, a first SNS application) on the running game application based on the processing program of the SNS application stored in the memory unit 28, and starts communication with the SNS server 40X (A520). In this case, by way of example and not limitation, the SNS application may be controlled to a foreground state and the gaming application may be controlled to a background state.

[0542] The control unit 41 of the SNS server 40X acquires information to be shared on the SNS (SNS shared information) (X510). In this case, by way of example and not limitation, the control unit 41 of the SNS server 40X may obtain the SNS shared information in any of the following ways. Acquired from the game server 50 (information sent from the game server 50 to the SNS server 40X) Acquired from the terminal 20A (information sent from the terminal 20A to the SNS server 40X)

[0543] Next, the control unit 41 of the SNS server 40X transmits posting confirmation information based on the acquired SNS shared information to the terminal 20A via the communication I / F 14 (X520). This posting confirmation information may include, by way of example and not limitation, the information shown in FIG. 4-4(2). It should be noted that the monster's generation source information does not need to be included in the posting confirmation information.

[0544] After A520, when the communication I / F 22 receives posting confirmation information from the SNS server 40X, the control unit 21 of the terminal 20A displays the posting confirmation information in the developed SNS application (A530). In this case, as an example and not a limitation, as shown in FIG. 4-4, an area for the SNS application may be displayed so as to be superimposed on at least a portion of the screen of the game application, and the posting confirmation information may be displayed in this area.

[0545] Next, the control unit 21 of the terminal 20A determines whether or not an input for editing the posting confirmation information has been made via the input / output unit 23 (A540). Note that this input may include an input of a comment to be posted in addition to the posting confirmation information. If it is determined that no input has been made (A540: NO), the control unit 21 of the terminal 20A skips step A550.

[0546] If it is determined that an input has been made (A540: YES), the control unit 21 of the terminal 20A updates (updates storage, updates display) the posting confirmation information based on the input content (A550).

[0547] It should be noted that steps A540 and A550 may not be performed.

[0548] Next, the control unit 21 of the terminal 20A transmits posting request information to the SNS server 40X via the communication I / F 22 based on the input of the posting via the input / output unit 23 (as an example, and not limited to, the operational input to the posting button POBT in FIG. 4-4) (A560). In this case, when step A550 is performed, the updated posting confirmation information may be included in the posting request information and transmitted to the SNS server 40X. Then, the control unit 21 of the terminal 20A advances the process to the end determination of A590.

[0549] When the communication I / F 44 receives the posting request information from the terminal 20A, the control unit 41 of the SNS server 40X performs the SNS update process (X410) and transmits timeline update information to the terminal 20M (X430) described above based on the received posting request information. Then, the control unit 41 of the SNS server 40X advances the process to the end determination of X590.

[0550] In step A510, the user AA may be able to select which SNS to share the information with from among a plurality of SNSs. In this case, the control unit 21 of the terminal 20A may deploy an SNS application corresponding to the SNS selected by the user (a first SNS application if the first SNS is selected, or a second SNS application if the second SNS is selected), communicate with an SNS server 40 corresponding to that SNS (SNS server 40X if the first SNS is selected, or SNS server 40Y if the second SNS is selected), and perform processing similar to that described above.

[0551] In the processing of Figure 4-5, an example has been described in which the control unit 41 of the SNS server 40X acquires (X510) information to be shared on the SNS (SNS shared information) from the game server 50 or terminal 20A, and then executes (X410) the SNS update processing based on receiving post request information from terminal 20A. However, this is not limited to the above form, and the control unit 41 of the SNS server 40X may execute the SNS update processing based on the SNS shared information being output from the game application to the SNS application of the sharing destination SNS in terminal 20A.

[0552] 4-6 are flowcharts showing an example of the flow of processes executed by each device in this modified example.

[0553] The control unit 21 of the terminal 20A determines whether or not an input for sharing information on an SNS has been made in the game application via the input / output unit 23 (A610). If it is determined that the processing has not been performed (A610: NO), the control unit 21 of the terminal 20A advances the processing to the end determination of A690.

[0554] If it is determined that an input has been made (A610: YES), the control unit 21 of the terminal 20A generates posting information to be shared on the SNS by the running game application (A620). The posting information may include, by way of example and not limitation, the registered name (BB) and account ID (@bb1234) of the user who generated the information in the first SNS, and an image of the monster B generated by the user who generated the information, as shown in FIG. 4-4(2). It should be noted that the monster's origin information does not need to be included in the posting information.

[0555] The control unit 21 of the terminal 20A causes the display unit 24 to display the generated posting information in the game application (A630). At this time, together with the posting information, a posting button POBT as shown in FIG. 4-4(2) for sharing the posting information on the SNS is also displayed on the display unit 24. In this example, since the SNS application has not been launched at this point, the UI of the SNS application as shown in FIG. 4-4(2) is not displayed; however, the game application may be configured to display an SNS UI image (as an example, and not a limitation, an image that imitates the UI of the SNS application) that has been pre-stored in memory unit 28 together with the posting information.

[0556] The control unit 21 of the terminal 20A determines whether or not the user AA has operated the post button POBT (whether or not an input for sharing the information to be posted on the SNS has been made via the input / output unit 23) (A640). If it is determined that the processing has not been performed (A640: NO), the control unit 21 of the terminal 20A advances the processing to the end determination of A690.

[0557] If the control unit 21 of the terminal 20A determines that an input has been made (YES in A640), it launches an SNS application linked to the game application (stored in the storage unit 28 in association with the game application) (A650). In this example, based on the fact that the SNS application linked to the game application is the SNS application of the first SNS, the SNS application of the first SNS is started by the processing of the A650.

[0558] The control unit 21 of the terminal 20A outputs the posting information (information of the area in which the posting information is stored (which may be, for example and not limited to, a URI (URL, etc.)) generated by the game application to the SNS application of the launched first SNS (A660). Thus, in this embodiment, the posting information generated by the game application on terminal 20A is acquired by the SNS application of the first SNS on terminal 20A, and is stored in SNS server 40X via the SNS application of the first SNS.

[0559] Based on receiving the posting information via the SNS application of the first SNS, the control unit 41 of the SNS server 40X identifies, by way of example and not limitation, the profile picture and registered name (AA) associated with the application ID (identification information that can uniquely identify user AA, who is both the player and the poster (sharer)) of the SNS application that sent the posting information.

[0560] The control unit 41 of the SNS server 40X performs an SNS update process (X410) and transmits timeline update information to the terminal 20M (X430) in order to associate the identified information with the acquired posting information and share them on the first SNS. Then, the control unit 41 of the SNS server 40X advances the process to the end determination of X690.

[0561] In step A650, the user AA may be able to select which SNS to share the information with from among a plurality of SNSs. In this case, the control unit 21 of the terminal 20A launches an SNS application corresponding to the SNS selected by the user (the first SNS application if the first SNS is selected, or the second SNS application if the second SNS is selected), and the posting information generated by the game application is output from the game application to the SNS application corresponding to the selected SNS, and is shared on that SNS.

[0562] In this way, on terminal 20A, when a game application obtains a monster (an example of a first object) generated based on the account (an example of a first account) of a user who is friends with the player (an example of a user of the terminal) on an SNS, the game application may output the generated monster and source information (an example of corresponding information corresponding to the first account) to an SNS application of the SNS with which the monster is to be shared (an example of a first control for displaying on the SNS).

[0563] In addition, the game application may store the generated monster and the source information in a memory area that can be read by the SNS application of the SNS with which the monster is to be shared (for example, and not limited to, this may be a memory area of ​​the terminal 20, a memory area of ​​the game server 50, or a memory area of ​​the SNS server 40), and then the SNS application may start up, read the information from the memory area, and share it on the SNS.

[0564] (F-3) As an example and not as a limitation, the above-mentioned first control by the player's terminal 20 may be possible only when a specific monster (as an example and not a limitation, a monster that is eligible for a bonus, such as Monster Z) is generated. In addition, the default setting is that the above-mentioned first control is performed by terminal 20, but when the above-mentioned specific monster is generated, information regarding the specific monster may be automatically shared from the server to the terminal, regardless of the above-mentioned first control.

[0565] (F-4) Sending information such as monster images and source information from the terminal 20 or the game server 50 to the SNS server 40 may include, by way of example and not limitation, sending the data of this information itself, or may include sending information regarding the storage location of this information (by way of example and not limitation, a URI). Furthermore, sharing information such as monster images and source information with terminal 20 may include, by way of example and not limitation, sending the data of this information itself to terminal 20, or may include sending information regarding the storage location of this information (by way of example and not limitation, a URI) to terminal 20.

[0566] In this embodiment, the control unit 21 of the terminal 20A of the user AA acquires a monster (an example of a first object) generated based on a user's account (an example of a first account) associated with the user AA's (player's) account (an example of a terminal user's account) in an SNS (at least one of the first SNS and the second SNS), and executes control (an example of a first control) for displaying the generated monster and information corresponding to the user's account from which the monster was generated (an example of information corresponding to the first account, for example, an account ID or SNS name) on the SNS (for example, at least one of the first SNS and the second SNS) based on an input to the terminal 20A of the user AA. This allows information about the first object to be shared between users of the SNS, thereby making it possible to stimulate communication about the game within the SNS.

[0567] (Modification (1) regarding origin information) FIG. 4-7 shows a modified example in which the generated monster is shared on a social networking site. Unlike the example shown in (1M) of Figure 4-2, a message stating "Monster B was born when I generated a monster from a friend on Messaging" (i.e., information informing the name of the SNS from which the monster was generated) is displayed, and the registered name (BB) and account ID (@bb1234) of the user who generated the monster on the SNS from which the monster was generated are displayed at the bottom of the monster image.

[0568] Furthermore, as an image of Monster B, an image is displayed in which the icon image of the original user BB (for example, the icon image used as the profile image of user BB on the original SNS) has been processed (for example, the display angle is changed by image processing) and fused with Monster B. In this way, by processing the information of the original user and reflecting it in the generated monster image, we can expect a variety of reactions when the image is shared on social media.

[0569] (Modification (2) regarding origin information) FIG. 4-8 is a diagram showing a modified example (an example different from (1M) in FIG. 4-2 and FIG. 4-7) in which the generated monster is shared on a social networking site. When user AA (player) taps the share button SBT on the screen shown in (3A), the information shared by user A is displayed as timeline information of the first SNS on terminal 20M as shown in (1M). Unlike the examples shown in (1M) of FIG. 4-2 and FIG. 4-7, the registered name and account ID of the user who generated the monster are not displayed, and only the message "Monster B was born when I generated a monster from a friend on Messaging" (i.e., information informing the name of the SNS to which the user who generated the monster belongs) is displayed.

[0570] In this way, when sharing a generated monster, it is possible to avoid disclosing information that could uniquely identify the user who generated the monster. In the following description, as in Figure 4-2(1M) and Figure 4-7 described above, if the information of the generating user shared on the SNS along with the image of the generated monster includes an account ID (when the generating user is highly identifiable), the information will be referred to as first-type generating user information (an example of first-type corresponding information), and if it does not include an account ID (when the generating user is low identifiable), the information will be referred to as second-type generating user information (an example of second-type corresponding information).

[0571] (Modification (3) regarding origin information) FIG. 4-9 and FIG. 4-10 are specific examples of the generation origin information according to the second aspect. In Fig. 4-9, only the message "Monster B was born when I generated a monster from a friend on Messaging" (i.e., information informing the name of the SNS to which the user who generated the monster belongs) is displayed, while in Fig. 4-10, in addition to the message, an image of the user who generated the monster and the registered name (BB) in the SNS of the user who generated the monster are disclosed. The form of the second form of the generation source information may be set by the player user or the generation source user.

[0572] <Fourth modified example (1)> FIG. 4-11 shows an example in which a game player has his / her own account in a first SNS (for example, but not limited to, a Messaging App) and a second SNS (for example, but not limited to, a Business App). In this case, as shown in (1), the terminal 20A of the player (user AA) can obtain, via the game application (Game App), friend list information (information regarding candidate accounts for generation) linked to the player's account in the first SNS from the SNS server 40X that has been subject to account linking processing with the game server 50 (see FIG. 1-14), and can also obtain friend list information (information regarding candidate accounts for generation) linked to the player's account in the second SNS from the SNS server 40Y that has also been subject to account linking processing with the game server 50 (see FIG. 1-14).

[0573] As shown in (1), a list of friends (Messaging Friends) based on friend list information of the first SNS and a list of friends (Business Friends) based on friend list information of the second SNS are displayed on the display unit 24 of the terminal 20A. A generation execution button MGBT is provided corresponding to each friend icon in the first SNS, and a generation execution button MGBT is provided corresponding to each friend icon in the second SNS, so that the player (user AA) can be provided with the option of choosing whether to use a friend in the first SNS or a friend in the second SNS as the generation source.

[0574] Next, if the friend selected by the player (user AA) as the source of generation is a friend on the first SNS (if the generation execution button MGBT displayed corresponding to the friend on the first SNS is selected), as shown in (2A), a monster based on the friend's account on the first SNS (as an example, not limited to, a general MAID) is generated and displayed on the display unit 24 of terminal 20A together with the share button SBT. On the other hand, if the friend selected by the player (user AA) as the source of generation is a friend on the second SNS (if the generation execution button MGBT displayed corresponding to the friend on the second SNS is selected), as shown in (2B), a monster based on the friend's account on the second SNS (as an example, not limited to, a general MAID) is generated and displayed on the display unit 24 of terminal 20A together with the share button SBT.

[0575] In (2A), based on the operation of the share button SBT, the generation source information of the first mode is shared on the first SNS as shown in (1MA). That is, based on the fact that the player's account and the generation source user's account are associated on the first SNS, the generation source information of the first mode (with account ID) is shared on the SNS (in this example, the messaging app of the first SNS) together with the generated monster. (1MA) is a display screen on the terminal 20M of the user MM who has an account on the first SNS.

[0576] Meanwhile, in (2B), based on the operation of the share button SBT, the second mode of the origin information is shared on the first SNS as shown in (1MB). That is, based on the fact that the player's account and the origin user's account are associated on the second SNS, the origin information of the second mode (without account ID) is shared on the SNS (in this example, the messaging app of the first SNS) together with the generated monster. (1MB) is a display screen on the terminal 20M of user M who has an account on the first SNS.

[0577] <Processing> Fig. 4-12 is a flow chart showing an example of the flow of processing executed by each device in this embodiment. The diagram can be read in the same way as Fig. 4-3. If it is determined in step G410 that SNS sharing request information has been received from terminal 20A (G410: YES), control unit 51 of game server 50 performs settings related to the form of information to be updated and displayed on the timeline (G420). Specifically, as an example and not a limitation, when the SNS from which a monster is generated in a game application is a first SNS, as a first behavior setting (hereinafter referred to as the "first behavior setting"), by way of example and not a limitation, the display of the generating user's account is set to "on," whereas when the SNS from which a monster is generated in a game application is a second SNS, as a second behavior setting different from the first behavior (hereinafter referred to as the "second behavior setting"), by way of example and not a limitation, the display of the generating user's account is set to "off."

[0578] In this case, the first and second manner settings may be reversed. Moreover, all of the mode settings may be the first mode settings, or all of the mode settings may be the second mode settings.

[0579] Next, the control unit 51 of the game server 50 transmits SNS sharing request information including the mode setting information in step G420 (hereinafter referred to as "mode setting information") to the SNS server 40X via the communication I / F 54 (G432).

[0580] If the SNS server 40X determines that it has received the SNS sharing request information from the game server 50 via the communication I / F 44, it performs the above-mentioned SNS update process based on the SNS sharing request information received from the game server 50 (X412). In this case, the control unit 41 of the SNS server 40X may determine the mode of information to be displayed on the timeline based on the mode setting information included in the SNS sharing request information received from the game server 50. Then, the control unit 41 of the SNS server 40X advances the process to step X430.

[0581] In this case, when the control unit 21 of the terminal 20M displays a timeline based on the timeline update information in the first SNS application in step M432, if the SNS from which the monster was generated is the first SNS, the updated and displayed timeline information is displayed in a first manner, and if the SNS from which the monster was generated is the second SNS, the updated and displayed timeline information is displayed in a second manner.

[0582] In this process, the SNS sharing request information is transmitted from the terminal 20A to the game server 50, but the present invention is not limited to this. As a non-limiting example, SNS sharing request information may be transmitted from the terminal 20A to the SNS server 40X. Then, the control unit 41 of the SNS server 40X may perform settings related to the aspect of information (information related to the generating user) to be updated and displayed on the timeline, similar to step G420.

[0583] In addition, mode selection information to allow the user to select whether the information is to be displayed in the first mode or the second mode may be displayed on the display unit 24 of the terminal 20A, and SNS sharing request information including information in the mode selected based on input by the user may be transmitted from the terminal 20A.

[0584] Furthermore, the sharing destination SNS does not necessarily have to be the first SNS, but may be the second SNS, or may be a third SNS different from the first and second SNS.

[0585] (Interoperability between applications) In addition, the processes corresponding to G420 and G432 in FIG. 4-12 may be executed in the player's terminal 20A. As a non-limiting example, when the player taps the share button SBT in Fig. 4-4(1), an SNS application linked to the game application is launched based on the input operation. If the source of the generation is a friend of the first SNS, a first mode may be set by the control unit 21 of the terminal 20A, and if the source of the generation is a friend of the second SNS, a second mode may be set by the control unit 21 of the terminal 20A, and SNS share request information including the mode setting information may be transmitted to the SNS server via the linked SNS application.

[0586] In this embodiment, when the SNS associated with the account of user AA (player) and his / her friend's account (an example of a first account) is the first SNS, the account ID of the generating user (an example of the correspondence information of the first embodiment) is displayed together with the generated monster as a post by user A on the SNS (at least one of the first SNS and the second SNS, as an example and not a limitation), thereby providing an opportunity to increase the number of users who wish to communicate with the generating user (users who wish to send a friend request, as an example and not a limitation), which is beneficial to the generating user who has an account on the first SNS. The account ID of the user who generated the content is an example of information that can identify the user who generated the content.

[0587] In this embodiment, when the SNS associated with the account of user AA (player) and his / her friend's account (an example of a first account) is the second SNS, the name of the SNS where the account of the user who generated the monster exists (an example of the corresponding information of the second embodiment) is displayed together with the generated monster as a post by user A on the SNS (at least one of the first SNS and the second SNS, as an example and not limited to the first SNS and the second SNS), so it is possible to know which SNS the user who generated the monster belongs to, but it is not possible to identify the user. Therefore, it is possible to share with a third party what kind of monster was generated from the second SNS, while preventing disadvantages caused by clearly disclosing the user of the second SNS that generated the monster.

[0588] <Fourth Modification (2)> In the example of Figure 4-11, the origin information is shared on the first SNS in both cases where the originating friend is the first SNS and where the originating friend is the second SNS. However, regardless of this form, the origin information may be shared on the first SNS based on the fact that the originating friend is the first SNS, and the origin information may be shared on the second SNS based on the fact that the originating friend is the second SNS.

[0589] By way of example and not limitation, in the example of FIG. 4-13, the origin information is shared on a second SNS (Business App) based on the fact that the origin friend is on the second SNS.

[0590] That is, in the example of FIG. 4-13, based on the operation of the share button SBT at (2A), the generation source information is shared on the first SNS as shown at (1MA). That is, based on the fact that the player's account and the generation source user's account are associated on the first SNS, the generation source information is shared on the first SNS (Messaging App) together with the generated monster.

[0591] On the other hand, in (2B), when the share button SBT is operated, the generation source information is shared on the second SNS as shown in (1MB). That is, based on the fact that the player's account and the generation source user's account are associated on the second SNS, the generation source information is shared on the second SNS (Business App) together with the generated monster.

[0592] In the example of FIG. 4-13, when the share button SBT is operated at (2A), the generation source information of the "first mode (with account ID)" is shared on the first SNS as shown at (1MA). That is, based on the fact that the player's account and the generation source user's account are associated on the first SNS, the generation source information of the "first mode" is shared on the first SNS (Messaging App) together with the generated monster.

[0593] On the other hand, in (2B), based on the operation of the share button SBT, the generation source information of the "second mode (without account ID)" is shared on the second SNS as shown in (1MB). That is, based on the fact that the player's account and the generation source user's account are associated on the second SNS, the generation source information of the "second mode" is shared on the second SNS (Business App) together with the generated monster.

[0594] In the example of Fig. 4-13, since the user MM has his / her own accounts in both the first SNS and the second SNS, the image of the same monster created by the player can be viewed in both the first SNS and the second SNS on the terminal 20M. And, by displaying the image of the same monster via different SNS applications, the display mode of the generation source information is different.

[0595] For example, if user MM has an account in the first SNS but not in the second SNS, he / she can view the first aspect of the origin information on terminal 20M (the first aspect of the origin information is displayed on display unit 24 of terminal 20M), but cannot view the second aspect of the origin information (the second aspect of the origin information is not displayed on display unit 24 of terminal 20M). On the other hand, if user MM has an account in the second SNS but not in the first SNS, he / she can view the second aspect of the origin information on terminal 20M (the second aspect of the origin information is displayed on display unit 24 of terminal 20M), but cannot view the first aspect of the origin information (the first aspect of the origin information is not displayed on display unit 24 of terminal 20M).

[0596] <Processing> In this way, when the source information is shared on the first SNS based on the fact that the friend who generated the information is the first SNS, and the source information is shared on the second SNS based on the fact that the friend who generated the information is the second SNS, as an example and not a limitation, in step G432 in FIG. 4-12, if the source is the first SNS, SNS sharing request information including behavior setting information regarding the first behavior may be sent to the SNS server 40X of the first SNS, and if the source is the second SNS, SNS sharing request information including behavior setting information regarding the second behavior may be sent to the SNS server 40Y of the second SNS.

[0597] In this case, the SNS server 40X may execute processes from X412 onwards, which will be described later, and the SNS server 40Y may execute processes from Y412 onwards, which will be described later (FIG. 4-14).

[0598] (Interoperability between applications) In this way, when there are multiple SNSs that are candidates for sharing destinations, the game application may be linked to the SNS application for each SNS.

[0599] As a non-limiting example, in FIG. 4-4(1), when the player taps the share button SBT, an SNS application is launched in cooperation with the game application based on the input operation. For example, an SNS application for the first SNS is launched based on the fact that the user who generated the SNS is the first SNS, and an SNS application for the second SNS is launched based on the fact that the user who generated the SNS is the second SNS.

[0600] When the application of the first SNS is started, the first mode is set by the control unit 21 of the terminal 20A, and SNS sharing request information including mode setting information regarding the first mode is transmitted to the SNS server 40X of the first SNS as the sharing destination. When the application of the second SNS is started, the control unit 21 of the terminal 20A sets the second mode, and SNS sharing request information including mode setting information regarding the second mode is transmitted to the SNS server 40Y of the second SNS as the sharing destination.

[0601] In this embodiment, which of multiple SNSs the results (the generated monster and corresponding information) are displayed in is controlled depending on which of multiple SNSs was used as the account of the user who generated the monster, making it easier for third parties to understand the relationship between the user who generated the monster and the SNS in which that user's account exists.

[0602] In this embodiment, which of the multiple SNSs the results (the generated monster and corresponding information) are displayed in is controlled depending on which of the multiple SNSs was used as the account of the user from which the results were generated, and the display manner of the corresponding information is made different depending on which of the multiple SNSs the results (the generated monster and corresponding information) are displayed in. This makes it easier for a third party to understand the relationship between the user who generated the result and the SNS in which the user's account exists, making it easier for a third party to communicate with the user who generated the result. Also, by adopting a display format that corresponds to the SNS in which the result is displayed, it is possible to avoid impairing the characteristics of each SNS.

[0603] In the fourth variant (1) and the fourth variant (2), the manner of the corresponding information is varied depending on at least one of which of the multiple SNS accounts was used as the account of the user who generated the monster and which of the multiple SNS accounts the result (the generated monster and corresponding information) is to be displayed in. Since the identifiability of the account of the user who generated the monster differs between the first and second variants, the level of disclosure of information regarding the user who generated the monster can be appropriately controlled.

[0604] <Fourth modified example (3)> The example of Figure 4-13 is an example in which the generation source information is shared on a first SNS based on the fact that the friend from which the monster was generated is a first SNS, and the generation source information is shared on a second SNS based on the fact that the friend from which the monster was generated is a second SNS, but as an example and not a limitation, the generated monster and the generation source information may be shared on an SNS that the player has set as a sharing destination.

[0605] <Processing> FIG. 4-14 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. In this figure, the left side shows the processing performed by the control unit 51 of the game server 50, the center shows the processing performed by the control unit 41 of the SNS server 40X and the processing performed by the control unit 41 of the SNS server 40Y, and the right side shows the processing performed by the control unit 21 of the terminal 20M.

[0606] In this process, the terminal 20A can include information regarding the SNS with which the information is to be shared, selected by the user AA (for example and not limitation, identification information of the SNS), in the SNS sharing request information and send it to the game server 50.

[0607] If it is determined in step G410 that SNS sharing request information has been received from terminal 20A (G410: YES), control unit 51 of game server 50 performs settings related to the form of information to be updated and displayed on the timeline (G422). In this case, the control unit 51 of the game server 50 can determine the SNS with which the information is to be shared, based on information on the SNS with which the information is to be shared, which is included in the received SNS sharing request information. As a non-limiting example, when the SNS with which the information is to be shared is the first SNS, the display of the source user's account is set to "Yes" as the first behavior setting. On the other hand, when the SNS with which the information is to be shared is the second SNS, the display of the source user's account is set to "No" as the second behavior setting.

[0608] Incidentally, these may be reversed. Also, for both the first manner setting and the second manner setting, the display of the source user's account may be set to "Yes" or "No."

[0609] Next, based on the settings made in step G422, the control unit 51 of the game server 50 sends SNS sharing request information including behavior setting information corresponding to the SNS of the sharing destination via the communication I / F 54 to the SNS server 40 of the SNS of the sharing destination (G434). Specifically, if the sharing destination is the first SNS, SNS sharing request information including the behavior setting information of the first aspect is sent to the SNS server 40X, and if the sharing destination is the second SNS, SNS sharing request information including the behavior setting information of the second aspect is sent to the SNS server 40Y.

[0610] When the mode setting information is transmitted to the SNS server 40X, the control unit 41 of the SNS server 40X performs an SNS update process (in this example, a process for displaying information about the source user on the timeline in the first mode) similar to the step X410 described above (X412). Then, the control unit 41 of the SNS server 40X transmits the timeline update information to the terminal 20M via the communication I / F 44 (X430).

[0611] Similarly, when the manner setting information is transmitted to the SNS server 40Y, the control unit 41 of the SNS server 40Y performs an SNS update process (in this example, a process for displaying information about the source user on the timeline in the second manner) (Y412). Then, the control unit 41 of the SNS server 40Y transmits the timeline update information to the terminal 20M via the communication I / F 44 (Y430).

[0612] The control unit 21 of the terminal 20M determines whether or not timeline update information has been received from the SNS server 40X (M410), and if it determines that it has not been received (M410: NO), proceeds to step M450. If it is determined that the timeline update information has been received (M410: YES), the control unit 21 of the terminal 20M causes the display unit 24 to display a timeline based on the received timeline update information in the first SNS application (M434). In this example, the updated timeline information displayed in the first SNS application is displayed in a first manner.

[0613] Next, the control unit 21 of the terminal 20M determines whether or not timeline update information has been received from the SNS server 40Y (M450), and if it determines that it has not been received (M450: NO), proceeds to step M195. If it is determined that the timeline update information has been received (M450: YES), the control unit 21 of the terminal 20M causes the display unit 24 to display a timeline based on the timeline update information received from the SNS server 40Y (M474). In this example, the updated timeline information is displayed in the second manner in the second SNS application.

[0614] In this process, the SNS sharing request information is transmitted from the terminal 20A to the game server 50, but the present invention is not limited to this. As a non-limiting example, the terminal 20A may transmit SNS sharing request information to the SNS server 40 corresponding to the SNS selected as the sharing destination of the information. Specifically, as a non-limiting example, when the sharing destination SNS selected by the user AA is the first SNS, the SNS sharing request information is transmitted to the SNS server 40X. Then, the control unit 41 of the SNS server 40X may perform settings regarding the mode of information (information about the generating user) to be updated and displayed on the timeline of the first SNS application.

[0615] Also, as a non-limiting example, when the sharing destination SNS selected by user AA is the second SNS, the SNS sharing request information is sent to the SNS server 40Y. Then, the control unit 41 of the SNS server 40Y may set the aspect of the information (information about the generating user) to be updated and displayed on the timeline of the second SNS application.

[0616] In addition, mode selection information to allow the user to select whether the information is to be displayed in the first mode or the second mode on the SNS to which the information is to be shared may be displayed on the display unit 24 of the terminal 20A, and SNS sharing request information including information in the mode selected based on input by the user may be transmitted from the terminal 20A.

[0617] Furthermore, the sharing destination SNS does not necessarily have to be any of the SNSs in the combination of the first SNS and the second SNS, but may be any of the SNSs in the combination including a third SNS different from the first SNS and the second SNS.

[0618] (Interoperability between applications) In this way, when the player selects an SNS to share with, the game application may be linked to the SNS application of the selected SNS.

[0619] As a non-limiting example, in FIG. 4-4(1), when the player taps the share button SBT, an SNS application for the SNS selected by the player is launched in cooperation with the game application based on the input operation. For example, if the selected SNS is the first SNS, an SNS application for the first SNS is launched, and if the selected SNS is the second SNS, an SNS application for the second SNS is launched.

[0620] When the application of the first SNS is launched, the first mode is set by the control unit 21 of the terminal 20A, and SNS sharing request information including mode setting information regarding the first mode is sent to the SNS server 40X of the first SNS to be shared (G422, G434, X412). When the application of the second SNS is launched, the second mode is set by the control unit 21 of the terminal 20A, and SNS sharing request information including mode setting information regarding the second mode is sent to the SNS server 40Y of the second SNS to be shared (G422, G434, Y412).

[0621] In this embodiment, in the first SNS among the SNSs in which user A has an account, the account ID (an example of the correspondence information of the first embodiment) of the user who generated the monster (a user who has an account in at least one of the first SNS and the second SNS) is displayed as a post by user A along with the generated monster, thereby providing an opportunity to increase the number of users who wish to communicate with the user who generated the monster (users who wish to send a friend request, as an example and not a limitation), which is beneficial to the user who generated the monster.

[0622] In this embodiment, the name of the SNS where the user who generated the monster has an account (at least one of the first SNS and the second SNS, which is an example of the correspondence information of the second embodiment) is displayed as a post by user A in the second SNS among the SNSs where user A has an account, together with the generated monster, so it is possible to know which SNS the user who generated the monster belongs to, but it is not possible to identify the user. Therefore, it is possible to share with a third party what kind of monster has been generated, while preventing the disadvantage of the user who generated the monster being clearly disclosed on the second SNS.

[0623] <Fourth Modification (4)> As shown in the fourth modified example (3), a game player may be allowed to select and set an SNS with which the generated monster and the generation source information are shared. In this case, the SNS may be selected and set by the following method, which is not limiting but is an example.

[0624] FIG. 4-15 is a diagram showing an example of selecting an SNS for sharing the results of monster generation. The screen shown in (1) is a screen displayed on the display unit 24 of the terminal 20A of a user AA who is a player of the game, and is the same screen as that shown in FIG. 4-8(3A) described above.

[0625] When user AA (player) taps the share button SBT on the screen shown in (1), a screen is displayed for selecting an SNS with which to share the generated monster and its source information, as shown in (2). This screen displays the words "Please select the SNS to share with", sharing SNS selection information for selecting the SNS to share with (the name of each SNS where the player's account exists and check boxes corresponding to each SNS), a decision button DEBT that is operated to confirm the SNS checked in the check box as the sharing destination, and a back button to return to the previous screen.

[0626] (If you select the first SNS) On the screen shown in (2), when user AA (player) selects the first SNS as the destination SNS for sharing (checks the checkbox corresponding to “Messaging App”) and taps the confirm button DEBT, information about the generated monster and information about the user who generated it will be shared on the first SNS for which user AA (player) has an account.

[0627] (1MA) in FIG. 4-15 is a screen similar to (1MA) in FIG. 4-13 described above. In the example of (1MA) in FIG. 4-15, the origin information of the first mode (with account ID) is shared on the first SNS. That is, the player's account and the origin user's account are associated with each other on the first SNS, and based on the player's selection of the first SNS as the sharing destination SNS, the origin information of the first mode is shared on the first SNS (Messaging App) together with the generated monster.

[0628] (If you select the second SNS) On the screen shown in (2), when user AA (player) selects the second SNS as the destination SNS for sharing (checks the checkbox corresponding to "Business App") and taps the decision button DEBT, information about the generated monster and information about the user who generated it will be shared on the second SNS where user AA (player) has an account.

[0629] FIG. 4-15 (1MB) is a screen similar to FIG. 4-13 (1MB) described above. In the example of FIG. 4-15 (1MB), the generation source information of the second mode (without account ID) is shared on the second SNS. That is, the player's account and the generation source user's account are associated with each other on the second SNS, and based on the player's selection of the second SNS as the sharing destination SNS, the generation source information of the second mode is shared on the second SNS (Business App) together with the generated monster.

[0630] The SNS identification information relating to the sharing destination SNS set by the player's terminal 20A in this manner may be included in the SNS sharing request information transmitted from the terminal 20A to the game server 50. The game server 50 may determine, based on the SNS sharing request information (SNS identification information), on which SNS the generated monster (and the generation source information) should be shared, and may share the monster on the SNS based on the determination result.

[0631] Furthermore, information regarding the sharing destination SNS set by the player's terminal 20A may be stored in the storage unit 55 of the game server 50. As a non-limiting example, SNS identification information capable of identifying the sharing destination SNS may be stored in association with the account ID of the player who performed the setting operation, and upon receiving SNS sharing request information including the account ID, the control unit 51 may determine the SNS to be the sharing destination based on the SNS identification information associated with the account ID, ...

Claims

1. A program executed by a terminal that processes games, acquiring, by a control unit of the terminal, a first object appearing in the game, the first object being generated based on a first account associated with an account of a user of the terminal in a social networking service (hereinafter referred to as "SNS"); and executing, by the control unit, a first control for displaying, on a social networking site, the first object and first correspondence information corresponding to the first account. program.

2. The program according to claim 1, acquiring, by the control unit, a second object that appears in the game and that is generated based on a second account associated with the account; and executing, by the control unit, a second control for displaying, on a social networking site, the second object and second correspondence information corresponding to the second account. program.

3. The program according to claim 2, The first object is generated based on first identification information of the first account; The second object is generated based on second identification information of the second account. program.

4. The program according to claim 2 or 3, displaying the first account and the second account on a display unit of the terminal; acquiring the first object by the control unit based on the first account being selected based on the user's input, and acquiring the second object by the control unit based on the second account being selected based on the user's input; executing the first control by the control unit based on acquisition of the first object, and executing the second control by the control unit based on acquisition of the second object. program.

5. The program according to claim 4, the first control is executed by the control unit based on an input from the user for notifying the first account of the first object; The second control is executed by the control unit based on an input from the user for notifying the second account of the second object. program.

6. The program according to claim 2 or 3, the game is a game in which the first object and the second object appear simultaneously; program.

7. The program according to claim 2 or 3, executing, by the control unit, control for setting one or more SNSs in which the first correspondence information is to be displayed, based on an input from the user; and executing, by the control unit, control for setting, by the control unit, one or more SNSs in which the second correspondence information is to be displayed, based on an input from the user. program.

8. The program according to claim 7, executing, by the control unit, control for setting an aspect of the first correspondence information in each of one or more SNSs in which the first correspondence information is displayed, based on an input from the user; and executing, by the control unit, control for setting an aspect of the second correspondence information in each of one or more SNSs in which the second correspondence information is displayed, based on an input from the user. program.

9. The program according to claim 2 or 3, displaying, on a display unit of the terminal, a benefit based on a first predetermined condition being satisfied regarding the first object, and displaying, on the display unit, a benefit based on a second predetermined condition being satisfied regarding the second object. program.

10. The program according to claim 2 or 3, the one or more SNSs for which the first correspondence information is displayed are SNSs set based on an input to a first terminal of a first user of the first account, The one or more SNSs for which the second correspondence information is displayed are SNSs set based on an input to a second terminal of a second user of the second account.

11. The program according to claim 10, A mode of the first correspondence information in each of the one or more SNSs in which the first correspondence information is displayed is a mode set based on an input of the first user to the first terminal, and a mode of the second correspondence information in each of the one or more SNSs in which the second correspondence information is displayed is a mode set based on an input of the second user to the second terminal. program.

12. The program according to claim 2 or 3, a reward based on the first predetermined condition being satisfied regarding the first object is associated with the first account; A benefit based on the satisfaction of a second predetermined condition related to the second object is associated with the second account. program.

13. An information processing method for a terminal that processes games, acquiring, by a control unit of the terminal, a first object related to the game, the first object being generated based on a first account associated with an account of the user of the terminal in an SNS; and executing, by the control unit, a first control for displaying, on a social networking site, the first object and first correspondence information corresponding to the first account. Information processing methods.

14. A terminal that processes games, a control unit that acquires a first object related to the game, the first object being generated based on a first account associated with an account of a user of the terminal in an SNS; the control unit executes a first control for displaying the first object and first correspondence information corresponding to the first account on a social networking site. Terminal.

Images