JP7573064B2 - Program and information processing system - Google Patents

Description

The present invention relates to a program and an information processing system.

Games and other services that allow users to register other users as friends and follow them have been known for some time (see, for example, Patent Document 1).

JP 2013-188456 A

However, in services that allow users to associate themselves with other users, such as by adding friends or following, there is a problem in that it is difficult to make such associations.

The present invention was made in consideration of the above circumstances, and aims to provide a service that makes it easy to associate users with each other.

According to one embodiment shown in the present disclosure,
Computer,
A program is provided that functions as an application means for automatically making an application to a second user regarding association of the second user with the first user after a decision has been made to share a specified experience with a first user within a specified service, during sharing, or after sharing.

The present invention provides a service that makes it easy to associate users with each other.

FIG. 1 is a diagram showing a schematic configuration of a system. FIG. 2 is a block diagram showing a functional configuration of the system. FIG. 13 is a diagram illustrating an example of a related user list display screen. FIG. 13 is a diagram showing an example of a history information input screen. FIG. 13 is a diagram showing an example of a category list display screen. FIG. 13 is a diagram showing an example of a display of a classification list. 11 is a flowchart illustrating an example of a process for automatically associating a user with another user. 11 is a flowchart illustrating an example of a process for automatically canceling an association between a user and another user. 13 is a flowchart showing an example of a process related to input of history information. 10 is a flowchart showing an example of a process for creating and displaying a classification list. 10 is a flowchart showing an example of a process for creating and displaying a classification list.

The following describes an embodiment of the present invention with reference to the drawings.

<System hardware configuration>
As shown in FIG. 1, a system 1 of the present embodiment includes a plurality of terminal devices 10 and a server 20 .

The terminal device 10 and the server 20 are connected via a network 2. The network 2 may be configured, for example, by the Internet, a mobile communication system (e.g., 3G, 4G, 5G, LTE (Long Term Evolution), etc.), WiFi (Wireless Fidelity), Bluetooth (registered trademark), other communication lines, or a combination of these. In addition, the connection between the terminal device 10 and the server 20 may be a wired connection or a wireless connection.

The server 20 (in other words, a computer, an information processing device) may be, for example, a general-purpose computer such as a workstation or a personal computer. The server 20 comprises a processor 21, a memory 22, a storage 23, a communication IF (interface) 24, and an input/output IF 25. These components of the server 20 are connected to each other by a communication bus.

The processor 21 controls the overall operation of the server 20. The processor 21 may include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), etc. The processor 21 reads a program from the storage 23 and expands it in the memory 22. The processor 21 executes the expanded program.

The memory 22 is a main storage device. The memory 22 is composed of storage devices such as a ROM (Read Only Memory) and a RAM (Random Access Memory). The memory 22 provides a working area for the processor 21 by temporarily storing the programs and various data that the processor 21 reads from the storage 23. The memory 22 also temporarily stores various data that the processor 21 generates while it is operating according to the programs.

In this embodiment, the program may be a program that realizes a predetermined service (in other words, an application) such as a game by the terminal device 10. The program may also be a program that realizes the predetermined service through cooperation between the terminal device 10 and the server 20. The predetermined service realized through cooperation between the terminal device 10 and the server 20 may be, for example, a service provided on a browser launched on the terminal device 10. The program may also be a program that realizes the predetermined service through cooperation between multiple terminal devices 10. The various data include, for example, data related to the service, such as user information and service information, and instructions and notifications transmitted and received between the terminal device 10 and the server 20.

Storage 23 is an auxiliary storage device. Storage 23 is configured with a storage device such as a flash memory or a hard disk drive (HDD). Various data related to the service is stored in storage 23.

The communication IF 24 controls the transmission and reception of various data between the server 20 and the terminal device 10 etc. via the network.

The input/output IF 25 is an interface through which the server 20 accepts data input, and is also an interface through which the server 20 outputs data. The input/output IF 25 may include, for example, an input unit that is an information input device such as a mouse or keyboard, and a display unit that is a device that displays and outputs images.

The terminal device 10 (in other words, a computer, an information processing device) may be, for example, a smartphone, a feature phone, a PDA (Personal Digital Assistant), a tablet computer, a personal computer, a wearable terminal, or a game device. The terminal device 10 may be a mobile terminal. The terminal device 10 may be a portable terminal when the user receives a service (for example, when playing a game).

The terminal device 10 includes a processor 11, a memory 12, a storage 13, a communication IF 14, an input/output IF 15, an input unit 17, and a display unit 18. These components of the terminal device 10 are connected to each other via a communication bus.

The processor 11 controls the overall operation of the terminal device 10. The processor 11 may include a CPU, an MPU, a GPU, etc. The processor 11 reads a program from the storage 13 and expands it in the memory 12. The processor 11 executes the expanded program.

Memory 12 is a main storage device. Memory 12 is composed of storage devices such as ROM and RAM. Memory 12 provides a working area for processor 11 by temporarily storing programs and various data that processor 11 reads from storage 13. Memory 12 also temporarily stores various data that processor 11 generates while operating according to a program.

Storage 13 is an auxiliary storage device. Storage 13 is configured with a storage device such as a flash memory or a HDD. Various data related to the service is stored in storage 13.

The communication IF 14 controls the transmission and reception of various data between the terminal device 10 and the server 20 etc. via the network.

The input/output IF 15 is an interface through which the terminal device 10 accepts data input, and is also an interface through which the terminal device 10 outputs data. The input/output IF 15 may input and output data via, for example, a Universal Serial Bus (USB). The input/output IF 15 may include an input unit 17 or a display unit 18, etc.

The input unit 17 accepts input from a user. The input unit 17 may be, for example, a pointing device such as a touchpad. The display unit 18 displays images. The display unit 18 may be, for example, a liquid crystal display or an organic EL (Electro-Luminescence) display. The terminal device 10 includes, for example, a touch screen 16 that is an electronic component that combines the input unit 17 and the display unit 18.

The input unit 17 has a function of detecting a position input on the input surface by a user operation (e.g., a touch operation, a tap operation, a slide operation, a swipe operation, a flick operation, a pinch-in operation, a pinch-out operation, etc.) and transmitting information indicating the detected position as an input signal. The touch panel serving as the input unit 17 may be of a capacitive type or a resistive film type, or may be of another type.

The input unit 17 may be, for example, a keyboard, various physical buttons, various sensors (for example, an acceleration sensor or an angular velocity sensor), an operation stick, a camera, or a microphone. The display unit 18 may be, for example, a projector.

<System Functional Configuration>
2 is a block diagram showing the functional configuration of the server 20 and the terminal device 10. The server 20 in this embodiment has, for example, a function for providing each of the terminal devices 10 with various data and programs necessary for providing a service, a function for collecting and managing data related to the service from each of the terminal devices 10, and a function for performing synchronization processing between the multiple terminal devices 10.

In this embodiment, the server 20 identifies each user and the terminal device 10 using a user account that is registered in advance. The method of registering the account is not particularly limited. For example, the terminal device 10 or another device such as a personal computer may transmit information required for user account registration to the server 20 based on the user's operation, and the server 20 may create and store an account for each user based on the received information. Each user accesses the server 20 from his/her own terminal device 10 and logs in with his/her own account to use the service (in other words, the application) of this embodiment. In the following, a terminal device 10 of a certain user refers to a terminal device 10 into which the certain user is logged in with his/her own account.

As shown in FIG. 2, the server 20 functions as a control unit 210 and a storage unit 220 through cooperation of a processor 21, a memory 22, a storage 23, a communication IF (interface) 24, an input/output IF 25, etc. The storage unit 220 stores various data used by the control unit 210. The various data include, for example, a program 221, service information 222, and user information 223.

Program 221 is a program for realizing a service. Service information 222 and user information 223 are data that the control unit 210 references when executing program 221.

The program 221 may include a program to be executed on the server 20 side, as well as a program (program 121 described later) to be transmitted to the terminal device 10 and executed on the terminal device 10 side. Alternatively, the storage unit 220 may store the program 221 to be executed on the server 20 side and the program to be executed on the terminal device 10 side.

The service information 222 is information common between accounts. The service information 222 includes, for example, information for defining various virtual spaces. A virtual space is a space in which objects such as a user's character are placed. The service information 222 also includes, for example, various setting information related to objects common between accounts, such as background objects such as buildings, trees, and stones placed in the virtual space, and the placement position, size, color, and shape of non-player characters (NPCs). The service information 222 also includes, for example, setting values of various parameters of non-player characters. Hereinafter, a character object placed in a virtual space may simply be referred to as a "character."

User information 223 is information managed for each account of the service. User information 223 includes, for example, information about the user's character, information about related users described below, information about owned assets, and information indicating the progress of a game, etc. Examples of owned assets include currency and items in the virtual space.

The control unit 210 controls various processes related to the service by executing a program 221 stored in the memory unit 220. The control unit 210 has, for example, a transmission/reception unit 211, a server processing unit 212, a synchronization processing unit 214, and a related user management unit 215.

The transmission/reception unit 211 transmits or receives various data. For example, the transmission/reception unit 211 receives requests to transmit various data and programs, requests for synchronization processing to support the multiplay function, data to be subject to synchronization processing, etc. from each terminal device 10, and passes them to the server processing unit 212. The transmission/reception unit 211 also transmits various data and programs, including instructions for achieving synchronization, to each terminal device 10 in accordance with the control of the server processing unit 212.

In this embodiment, the multi-play function is a function that provides services in a synchronized state for multiple accounts. The server 20 and terminal device 10 of the system 1 execute various processes to support the multi-play function when multiple accounts logged in to the system 1 use a certain content together (for example, when playing a game together).

The server processing unit 212 provides services to the terminal device 10 by executing calculation processing described in the program 221 in response to requests from the terminal device 10, etc. For example, when the server processing unit 212 receives a request for synchronization processing to support the multiplay function or data to be subject to synchronization processing from the terminal device 10 via the transmission/reception unit 211, the server processing unit 212 executes synchronization processing to support the multiplay function. In addition, the server processing unit 212 issues a command to the transmission/reception unit 211 to transmit service information 222 or user information 223.

The synchronization processing unit 214 executes synchronization processing to support the multi-play function according to instructions from the server processing unit 212. For example, when the server 20 transmits information to a plurality of terminal devices 10, the synchronization processing unit 214 transmits information to each terminal device 10 simultaneously, thereby synchronizing the games, etc., progressing among the terminal devices 10. Specifically, the synchronization processing unit 214 transmits operation information received from the terminal device 10 corresponding to each account within a predetermined period (for example, one frame) to each terminal device 10 simultaneously for each predetermined period. The operation information is information related to the operation input to the terminal device 10. The timing of synchronization and the information to be synchronized may be received from the server processing unit 212 at any time. By executing the synchronization processing, it becomes possible to simultaneously reflect events in the service caused by an operation input on one terminal device 10 on the other terminal devices 10.

The related user management unit 215 controls the association between users. The related user management unit 215 includes an association unit 216, a release unit 217, a list creation unit 218, and a history information management unit 219. The control by the related user management unit 215 will be described in detail later.

The terminal device 10 in this embodiment has, for example, a function as an input device that accepts user input operations, and a function as an output device that outputs images and sounds related to the service.

The terminal device 10 functions as a control unit 110 and a storage unit 120 through cooperation of the processor 11, memory 12, storage 13, communication IF 14, input/output IF 15, etc. The storage unit 120 stores various data used by the control unit 110. Examples of the various data include a program 121, service information 122, and user information 123.

Program 121 is a program for realizing a service on the terminal device 10 side. Service information 122 and user information 123 are data that the control unit 110 references when executing program 121.

The service information 122 includes information similar to the service information 222 of the server 20 described above. Therefore, a description of the service information 122 will be omitted here.

The user information 123 is data related to the account of the user who uses the terminal device 10, and includes information similar to the user information 223 of the server 20 described above. Therefore, a description of the user information 123 will be omitted here.

The control unit 110 executes a program 121 stored in the memory unit 120 to control various processes related to the services executed in the terminal device 10. The control unit 110 has, for example, an operation reception unit 111, a transmission/reception unit 112, a progress unit 113, and a display control unit 114.

The operation reception unit 111 receives an operation (hereinafter, also referred to as an "input operation") input by the user via the input unit 17. Specifically, when an input operation is performed on the input unit 17, the operation reception unit 111 detects the coordinates of the input position and the type of input operation. Examples of the types of input operations include various operations using fingers, such as a touch operation, a tap operation, a slide operation, a swipe operation, a flick operation, a pinch-in operation, and a pinch-out operation. The input operation is not limited to an operation of physically contacting the input unit 17 (e.g., the touch screen 16), but may also include a non-contact operation. Note that an operation of terminating an input operation that has been performed, such as a touch-off operation of terminating contact with the touch screen 16, can also be considered as one form of input operation.

Here, the operation reception unit 111 can also receive input operations performed using an operation device connected via the input/output IF 15 in the same way as input operations performed on the input unit 17.

The transmitter/receiver 112 transmits and receives various types of data. Specific examples are given below.

The transmission/reception unit 112 transmits service information 122 or user information 123, a synchronization request for supporting the multiplay function, and the like to the server 20. The transmission/reception unit 112 receives various data, programs, data for synchronization for supporting the multiplay function, and the like from the server 20. The data for synchronization includes, for example, synchronization instruction data for instructing each terminal device 10 participating in the multiplay to synchronize. The synchronization instruction data includes, for example, the data to be synchronized, the type of that data, and data for specifying the time to synchronize.

The transmission/reception unit 112 transmits operation information related to the input operation accepted by the operation acceptance unit 111 to the server 20. The transmission/reception unit 112 receives operation information related to the operation input by another user on another terminal device 10 from the server 20.

The progression unit 113 executes various processes related to the progress of the service (e.g., the progress of a game, etc.). A specific example is given below.

The progression unit 113 defines the virtual space based on information for defining the virtual space included in the service information 122. The progression unit 113 places objects in the virtual space based on object setting information included in the service information 122. The progression unit 113 controls the objects placed in the virtual space. Specifically, the progression unit 113 changes the position, orientation, shape, color, etc. of the objects in the virtual space, and controls the objects to perform a specified action.

The progression unit 113 defines a virtual camera for specifying an area of the virtual space to be presented to the user. The progression unit 113 places the virtual camera in the virtual space by defining the position and orientation of the virtual camera in the virtual space. The progression unit 113 instructs the display control unit 114 to generate an image that depicts the viewing area defined by the virtual camera and the objects placed in this viewing area.

The position and orientation of the virtual camera can be determined appropriately for each virtual space. For example, the progression unit 113 uses the position and orientation of a specific object as a reference and positions the virtual camera so that the specific object is located in the center of the field of view in a specific orientation. At that time, the progression unit 113 adjusts the position and orientation of the virtual camera using the direction, distance, and angle relative to the specific object. The specific object may be, for example, a dynamic object such as a user's character or a non-player character, or a static object such as a building, tree, or stone. Dynamic objects include characters that act based on the operation of each user and characters that act based on the programs 121 and 221 (for example, non-player characters, etc.).

The progression unit 113 interprets the user's instructions based on the coordinates of the input position and the type of input operation detected by the operation reception unit 111. The progression unit 113 executes various determination processes related to the progress of the service based on the interpreted instructions. The progression unit 113 progresses the service while controlling objects, a virtual camera, etc. based on the results of the determination processes. The progression unit 113 updates, adds, or deletes service information 122 and user information 123 according to the progress of the service.

The display control unit 114 causes the display unit 18 to display an image. A specific example is given below.

The display control unit 114 generates an image that depicts the area of the virtual camera's field of view defined by the progression unit 113 in the virtual space and the objects present in that area, and displays the image on the display unit 18. The display control unit 114 can superimpose and draw objects related to the UI (User Interface) required for various operations of the service, such as icons, buttons, and menus showing various parameters, on the image to be displayed on the display unit 18.

The functions of the terminal device 10 and the server 20 shown in FIG. 2 are merely an example. Each of the terminal device 10 and the server 20 may have at least a part of the functions of the other device. In other words, the server 20 may have some or all of the functional blocks of the terminal device 10 in this embodiment, and the terminal device 10 may have some or all of the functional blocks of the server 20. In addition, each device such as the terminal device 10 and the server 20 does not have to be realized by an integrated device, and may be realized by, for example, multiple devices connected via a network or the like. In addition, the system 1 may be composed of, for example, only the terminal device 10 or the server 20. In other words, the system 1 does not have to be realized by multiple devices connected via a network.

<Processing according to this embodiment>
Next, the processing according to this embodiment will be described. In this embodiment, the processor 11 of the terminal device 10 or the processor 21 of the server 20 executes a program stored in the system 1 to perform each processing described later. However, at least a part of the processing described later that is performed by the processor 11 may be executed by a processor other than the processor 11. Also, at least a part of the processing described later that is performed by the processor 21 may be executed by a processor other than the processor 21. In other words, the computer that executes the program in this embodiment may be either the terminal device 10 or the server 20, or may be realized by a combination of multiple devices.

The services provided by system 1 in this embodiment (in other words, the applications executed by system 1) may be, for example, games, SNS (Social Networking Service), or anything related to the metaverse.

In the service of this embodiment, a user can register other users as friends. A friend refers to a relationship in which a certain user and another user are associated with each other. In other words, a friend refers to a relationship in which one user is associated with another user, and the other user is associated with one user. In other words, if a second user is a friend from the perspective of a first user, the first user is a friend from the perspective of the second user. A friend may be a relationship that is established based on mutual consent between a certain user and another user.

In the service of this embodiment, a user can follow other users. Following refers to a user registering another user in association with the user. In other words, when a first user follows a second user, this does not necessarily mean that the second user is following the first user. Following may be a relationship that can be established based on the will of one party.

Information indicating other users associated with each user is stored in the storage unit 220 as user information 223. The information may be stored in the storage unit 120 as user information 123. The information may be any information that can identify users associated with each user (for example, friends or users followed by each user). Specifically, for example, a user ID (in other words, identification information) that can uniquely identify each user may be used, and the user ID of each user may be linked to the user ID of the other user associated with each user and stored, thereby managing the friends or users followed by each user. In other words, when a user registers another user as a friend or a friend who follows another user, the user ID of the other user may be linked to the user ID of the user and stored in the storage unit 220.

In addition, each user may be able to easily view (in other words, check) information about a friend (e.g., information indicating whether the user is logged in, information issued by the user, information about the user's rank, etc., described later) on his/her terminal device 10 compared to users who are not friends. In other words, when a user is a friend of another user, the user may be at an advantage in viewing information about the other user compared to when the user is not a friend of the other user. In addition, being at an advantage in viewing information includes cases where the number of operations required for viewing on the terminal device 10 is small, such as when the user requires less effort to view information, cases where there are few time restrictions on viewing, and cases where specific information that cannot be viewed in other cases can be viewed. In addition, the service may include, for example, functions that can only be used with one's friends. Specifically, the service may include specific functions or games that can only be performed with one's friends. In addition, the service may be configured such that a specific message can only be sent or received between one's friends. Also, within the service, exchange of owned assets (e.g., delivery of items) may only be possible with one's friends. In other words, a friend may be a user who can use a specific function within the service that cannot be used with users who are not friends (e.g., a function that cannot be used with users who are followed). Note that this function may be a function that facilitates matching with friends (in other words, using specific content together (e.g., participating in the same match, event, etc.)).

In addition, each user may be able to easily view (check) information about a user that he or she follows on his or her own terminal device 10, compared to a user that he or she does not follow (and is not a friend). In other words, when a user follows another user, the user may have an advantage in viewing information about the other user, compared to a user that does not follow the other user. In addition, the service may include, for example, a function that can only be used with a user that the user follows. In other words, a followed user may be a user who can use a specific function in the service that cannot be used with a user that the user does not follow (and is not a friend). Note that there may be a case where one user follows another user, and the other user does not follow the one user. In this case, the one user may have an advantage in viewing information about the other user, compared to the other user. Specifically, for example, the one user may be able to view specific information about the other user, but the other user may not be able to view specific information about the one user.

(Automatic association)
The association unit 216 identifies other users who share a predetermined experience with a certain user (hereinafter also referred to as a "first user") in the service. The association unit 216 also automatically registers the identified other user as a friend of the user. In other words, the association unit 216 automatically associates the identified other user with the user. In other words, the association unit 216 performs the association process of associating the identified other user with the user without the user's operation of instructing the association and the other user's operation of instructing the association. In the following, any user among a plurality of users who use the service may be referred to as a first user. In addition, a user other than the first user, such as a user who is automatically registered as a friend of the first user and identified by the association unit 216, may be referred to as a second user.

Examples of sharing experiences within a service include the following. That is, sharing a specific experience may be, for example, "performing the same quest in a game." Sharing a specific experience may be, for example, "participating in the same event in a virtual space." Sharing a specific experience may be, for example, "having a conversation in a virtual space (including, for example, a conversation by text message, etc.)." Sharing a specific experience may be, for example, "watching the same video (for example, live video or a specific scene in a game)." Sharing a specific experience may be, for example, "using content of the same category (for example, an event or video)." Sharing a specific experience may be, for example, "visiting (or staying at) the same place in a virtual space." Note that the user's position in the virtual space may be linked (or in other words, corresponding) to the user's position in the real world (for example, the position of the user's terminal device 10).

Other users who share a given experience with a user within the service may be, for example, other users who are currently sharing the given experience, other users after sharing, or other users after sharing has been decided. Here, other users after it has been decided to share the given experience refer to other users who the association unit 216 can determine as to whether or not they are other users with whom it has been decided to share the given experience (for example, other users with whom a schedule for sharing a given experience has been scheduled within the service), such as other users who have been matched within the game, other users who have booked participation in a given event within the service, or other users who are in a place waiting for a given event in the virtual space (for example, a so-called lobby, etc.), and do not include users who have merely promised to play a game together in the real world.

Furthermore, other users who share a given experience with the user within the service may be, for example, other users who use given content together with the user within the service. In other words, other users who share a given experience with the user within the service may be, for example, other users who are using the given content together, other users who have used it together, or other users after the user has decided to use it together.

Examples of using specific content together within a service include the following. That is, using specific content together may mean, for example, "participating together in a specific match or quest in a game (for example, participating as an ally or enemy)." Using specific content together may mean, for example, "participating together in a specific event in a virtual space." Using specific content together may mean, for example, "participating in the same group chat on SNS or in a game, etc." Using specific content together may mean, for example, "watching specific video together (for example, live video or a specific scene in a game)."

The association unit 216 identifies other users who share a predetermined experience with the first user as other users to be automatically registered as friends, and at this time, specifically, other users who share a predetermined experience with the first user and have a predetermined relationship with the first user within the service may be identified as other users to be automatically registered. In other words, when automatically registering other users who share a predetermined experience with the first user as friends, the association unit 216 may automatically register the other users as friends on the condition that the other users have a predetermined relationship with the first user. An example of the predetermined relationship is described below.

The specified relationship may be, for example, "a relationship in which the relationship within the service is a specific relationship." Specifically, the specified relationship may be, for example, "a relationship in which both parties belong to a group (such as a team, party, guild, etc.) that cooperates for a specific purpose." In addition, the specified relationship may be, for example, "a relationship in which both parties are enemies."

The predetermined relationship may be, for example, a relationship in which the relationship is determined based on the attributes of at least one of the users. Examples of user attributes include rank, gender, play time, behavioral tendency, or the character used (in other words, owned). The rank can be said to indicate the user's proficiency, or the relative positioning between users. The rank includes what is called a level in a general game. The rank of a user may be the rank of the user himself or the rank of the character used by the user. The character includes the user's avatar, etc. In other words, the predetermined relationship may be, for example, a relationship in which the rank is higher than that of the first user. The predetermined relationship may be, for example, a relationship in which the genders in the service are the same (or different). The predetermined relationship may be, for example, a relationship in which the probability of a nuisance being committed is low (in other words, the user is not a nuisance user). Whether or not the probability of a nuisance being committed is low may be determined by, for example, storing the number of times that the network connection was cut off in the past while using the content (for example, during a match or quest with another user (here, the other user may be the first user or may be another user including a user other than the first user)) as user information 223 for each user in the storage unit 220 of the server 20, and the association unit 216 may determine based on the number of times. Whether or not the probability of a nuisance being committed is low may be determined by, for example, storing the number of times that a preset prohibited word (in other words, a monitored word) was used in chat within the service as user information 223 for each user in the storage unit 220 of the server 20, and the association unit 216 may determine based on the number of times.

In addition, examples of relationships determined based on the characters used as the attributes of the users include the following. That is, the predetermined relationship may be, for example, a relationship in which the types of characters used do not overlap (in other words, different characters are used). In addition, the predetermined relationship may be, for example, a relationship in which a predetermined group (for example, a party) is formed and the predetermined group is well-balanced in consideration of the attributes of the characters (in other words, the attributes of the users). Specifically, the predetermined relationship may be, for example, a relationship in which characters with different attributes (in other words, strengths, etc.) are used (for example, in a role-playing game or FPS (First Person Shooter), a first user uses a character that is good at attacking, and a second user uses a character that is good at healing) are used). In addition, the predetermined relationship may be, for example, a relationship in which characters with common attributes (for example, the same) are used.

In other words, a predetermined relationship (e.g., a relationship that improves the balance of a predetermined group) may be, for example, a relationship in which the attributes of one user (e.g., attributes such as "good at attacking" or "good at healing" or attributes of a character used by the user) are complemented by the attributes of the other user (specifically, for example, a relationship such as "good at attacking" and "good at healing." In other words, a relationship in which the attributes of one user and the attributes of the other user are complementary). More specifically, a predetermined relationship may be, for example, a relationship in which the attributes of one user that affect the content of the game (in other words, the achievement of a predetermined objective in the game (e.g., defeating a predetermined enemy character, clearing a predetermined stage, team victory, etc.)) are complemented by the attributes of the other user that affect the content of the game.

The predetermined relationship may be, for example, a relationship in which a predetermined attribute of one user is common to a predetermined attribute of the other user. Specifically, the predetermined relationship may be, for example, a relationship in which a character with a common attribute is used. The predetermined relationship may be, for example, a relationship in which ranks match. The predetermined relationship may be, for example, a relationship in which genders match. The predetermined relationship may be, for example, a relationship in which behavioral tendencies are similar. In other words, the predetermined relationship may be, for example, a relationship in which an attribute of one user that affects the content of the game (in other words, the achievement of a predetermined objective in the game (for example, defeating a predetermined enemy character, clearing a predetermined stage, or the team winning)) is common to an attribute of the other user that affects the content of the game.

The predetermined relationship may be, for example, "a relationship in which the relationship is determined based on an action performed by at least one of the users in the content being used or used together". Specifically, the predetermined relationship may be, for example, "a relationship in which the other user performs a beneficial action (in other words, an assist action) in the content being used together" or "a relationship in which the other user performs a beneficial action in the content being used together". Examples of beneficial actions include, for example, an action of recovering the first user's character in a role-playing game or FPS (including, for example, an action of reviving), or an action of attacking an enemy character that the first user is trying to defeat (in other words, an assist attack). The predetermined relationship may be, for example, "a relationship in which the network connection is cut off (disconnected or has been disconnected) in the content being used together". Furthermore, the specified relationship may be, for example, "a relationship in which a comment was made (specifically, a comment made by one or both of the people) in a group chat in which the people participate together" or "a relationship in which the people mentioned each other (or one person mentioned the other) in a group chat in which the people participate together."

The predetermined relationship may be, for example, "a relationship in which the relationship is determined based on the results of using content used together and is a specific relationship." Specifically, the predetermined relationship may be, for example, "a relationship in which the two users have won or lost as friends in a game played together," or "a relationship in which the two users have won or lost as enemies in a game played together." The predetermined relationship may be, for example, "a relationship in which the two users have a better predetermined performance in a game played together than the first user." The predetermined relationship may be, for example, "a relationship in which the two users have a higher chance of winning (in other words, higher than a predetermined value) when they team up in a predetermined situation (for example, a predetermined stage (in other words, a map) in various games), determined based on the results of playing games together multiple times. Here, the predetermined value does not have to be a fixed value)."

The predetermined relationship may be, for example, "a relationship in which the intimacy level is high (in other words, a predetermined level or higher) determined based on an action performed by at least one user." Here, the association unit 216 may, for example, determine the level of intimacy based on a favorable action performed by one user toward the other user. Specifically, for example, when a second user revives a character of a first user in a game, the association unit 216 may determine that the intimacy level is high (in other words, a predetermined level or higher) on the assumption that the second user has performed an action with high intimacy level (an action with high intimacy level compared to the case where the second user is left alone without reviving the character). In addition, in a service in which a fixed message can be selected from a plurality of fixed messages (for example, fixed sentences or so-called stamps, etc., specifically, for example, "Hello," "Nice play," "Let's do our best," etc.) and sent to the other party, the association unit 216 may determine that the intimacy level is high (in other words, a predetermined level or higher) on the assumption that the one user has performed an action with high intimacy level when the one user sends a specific fixed message (for example, "Nice play") to the other party. The method by which the associating unit 216 determines whether the intimacy level is high may be, for example, a method in which information indicating whether each action performed by the user (e.g., reviving another user's character, sending a specific standard message, etc.) is assigned with information indicating whether the action is a high level of intimacy, and the determination is made based on the information. Also, the method may be, for example, a numerical value related to the intimacy level is assigned to each action performed by the user, the storage unit 220 stores a cumulative value of the numerical value, the associating unit 216 increases or decreases the cumulative value based on the user's actions within the service, and when the cumulative value reaches or exceeds a predetermined value, the association unit 216 determines that the intimacy level is high (in other words, is at or above a predetermined level).

The predetermined relationship may be, for example, "a relationship in which the duration of use of content used together is a predetermined period or longer." Specifically, the predetermined relationship may be, for example, "a relationship in which both parties participate in a group chat together for a period of time that is longer than a predetermined period."

When identifying other users who have a predetermined relationship with the first user in the service as other users to be automatically registered as friends, the association unit 216 may identify other users who satisfy multiple relationships, rather than identifying other users who satisfy one of the relationships exemplified above. In other words, for example, in the case of "the association unit 216 automatically registers users whose status relationship in the service is a specific relationship with the first user as friends," this merely indicates one of the conditions for users to be automatically registered as friends, and may include a configuration in which, for example, a user who has a specific relationship determined based on the attributes of at least one of the users is automatically registered, and a user who does not have a specific relationship determined based on the attributes of the users is not automatically registered.

The association unit 216 may identify other users who satisfy conditions (hereinafter referred to as "registration conditions") that can be set arbitrarily by the user as other users to be automatically registered as friends. In other words, the predetermined relationship may be, for example, "a relationship that satisfies the registration conditions set by the first user." In other words, the predetermined relationship (what kind of relationship other users have to be automatically registered as friends) may be arbitrarily set by each user. In further other words, whether or not to automatically register a user as a friend when each of the above-mentioned relationships is satisfied may change depending on the setting of the registration conditions.

Specifically, the association unit 216 may automatically register, as a friend of the first user, other users who share a certain experience with the first user and have attributes (e.g., rank, gender, play time, behavioral tendency, or character (e.g., character attributes)) that the first user has specified as a registration condition.

In this way, when a user who satisfies a registration condition that can be arbitrarily set by the user is automatically registered as a friend, the association unit 216 may automatically register one user and the other user as friends when the one user satisfies the registration condition set by the other user and when the one user satisfies the registration condition set by the other user. In other words, when the association unit 216 automatically registers a user who has a predetermined relationship from the perspective of one user as a friend of the one user, the association unit 216 may register both users as friends on the condition that the one user is a user who has a predetermined relationship from the perspective of the other user.

When the registration conditions can be arbitrarily set by the user, the setting method is not particularly limited, but may be, for example, as follows. Specifically, each user may set the conditions of users who want to become friends as the registration conditions from their own terminal device 10. In other words, it may be possible to set a whitelist that specifies the conditions of users who want to become friends. Furthermore, each user may set the conditions of users who do not want to become friends as the registration conditions from their own terminal device 10. In other words, it may be possible to set a blacklist that specifies the conditions of users who do not want to become friends. In yet other words, a user who satisfies the registration conditions may be a user who does not satisfy the conditions set as the conditions of users who are not wanted to become friends.

Whether or not a user has a predetermined relationship with a first user may vary depending on the attributes of the first user. Specifically, for example, in an FPS, if the first user uses a character that is good at attacking, a user with a predetermined relationship may be a user who uses a character that is good at healing, and if the first user uses a character that is good at healing, a user with a predetermined relationship may be a user who uses a character that is good at attacking, etc.

In addition, the establishment of a predetermined relationship may have a condition regarding the number of times. Specifically, for example, when the association unit 216 automatically registers other users who share a predetermined experience with the first user in the service, specifically other users who participated in an event of the same category, as friends, the other users who participated in an event of the same category N times (here, N is an integer of 1 or more) may be automatically registered as friends. In addition, for example, when the association unit 216 automatically registers other users who use a predetermined content together with the first user, specifically other users who participated in the same match in a game, as friends, the other users who participated in the same match N times (for example, participated N times in a row) may be automatically registered as friends. In addition, for example, when the association unit 216 automatically registers other users who performed beneficial actions in content used together, as friends, the other users who performed beneficial actions N times may be automatically registered as friends. Also, for example, when the association unit 216 automatically registers as friends other users who have mutually mentioned each other (or one user has mentioned the other) in a group chat in which the users participate together, the association unit 216 may automatically register as a friend another user who has been mentioned N times. Note that the conditions regarding the number of times (specifically, what number N should be, etc.) may be arbitrarily set by the user as a registration condition (specifically, at least a part of the registration condition).

The timing when the association unit 216 automatically registers a user who shares a specific experience (e.g., uses specific content together) as a friend may be, for example, while the specific experience is being shared, after sharing, or when it is decided to share.

That is, for example, when a second user who is using a certain content together with a first user is automatically registered, a second user who meets a specific condition while using the content may be automatically registered at the timing when the specific condition is met. The second user who meets the specific condition may be, for example, a second user who performs an action that benefits the first user during a game (in other words, an assist action). The second user who meets the specific condition may be, for example, a user whose network connection is cut off during a game. The user who meets the specific condition may be, for example, a second user who participates in the same group chat as the first user and who makes a statement in the group chat, or a second user who mentions each other (or one of them mentions the other) in the group chat, etc. The second user who meets the specific condition may be a second user who performs the action exemplified here multiple times (for example, a second user who performs an action that benefits the first user multiple times, a second user who mentions each other (or who mentions) multiple times, etc.). Note that satisfying a specific condition may mean satisfying a condition that results in a specific relationship being established, or may mean satisfying a condition other than the condition that results in a specific relationship being established.

For example, when automatically registering a second user who has used a certain content together with a first user, a second user who meets a specific condition while using the content, or a second user who meets a specific condition regarding the results of using the content, may be automatically registered at the timing when the use of the content ends. Note that a second user who meets a specific condition regarding the results of using the content may be, for example, a user who has achieved a result of victory or defeat as a friend or enemy in a game, or a user who has achieved a result of victory or defeat and has achieved a certain performance. Note that the timing of automatic registration may be, for example, after the game ends, while the results (in other words, the performance) are being displayed (for example, when the results are being displayed on the display unit 18 of the terminal device 10 of the first user), etc.

In addition, for example, when a second user who used a predetermined content together with a first user is automatically registered, a second user who satisfied a specific condition while using the content, a second user who satisfied a specific condition regarding the result of using the content, or a second user who satisfied a specific condition after using the content may be automatically registered at a timing when a predetermined period has passed since the end of the use of the content. Specifically, for example, in the case of a second user who will establish a predetermined relationship when the second user reaches level 10 or higher, if the second user's level was level 1 at the end of a match they played together but then reached level 10 after a period of time, the second user may be automatically registered as a friend based on the second user reaching level 10. In this case, the association unit 216 may store the second user as a friend candidate in the storage unit 220 of the server 20 from the end of the match until the second user reaches level 10, and continue to monitor whether the second user has reached level 10 (whether the second user has reached a state where a predetermined relationship is established).

In addition, for example, when a second user who is determined to use a certain content together with a first user is automatically registered as a friend, the second user may be automatically registered immediately after matching is established, or the second user may be automatically registered when a game or event in which they will participate together begins, or the second user may be automatically registered when both the first user and the second user join a group chat.

Note that the timing of automatic friend registration described here may also be interpreted as the timing of making a friend registration or follow request (described below) (in other words, the timing of displaying the acceptance screen for that request, described below).

The timing at which the association unit 216 identifies the second user to be automatically registered as a friend of the first user may be different from the timing at which the second user is automatically registered as a friend of the first user.

In addition, when an upper limit is set on the number of users that can be associated with each user (e.g., the number of friends of each user), the association unit 216 may, for example, perform automatic association when the number of other users associated with the first user is less than a predetermined ratio of the upper limit, and may not perform automatic association when the number is equal to or greater than the predetermined ratio. In other words, the conditions under which the association unit 216 automatically associates other users may be relaxed or stricter depending on the number of other users associated.

Here, the association unit 216 has been described as automatically registering the identified second user as a friend of the first user, but the association unit 216 may automatically register the identified second user as a user followed by the first user. In other words, the association unit 216 may automatically associate the identified second user with the first user. In further other words, the association unit 216 may perform the process of associating the identified second user with the first user without the first user performing an operation to instruct the association. In addition, the association unit 216 may automatically make a friend registration application or a follow application from the first user to the identified second user. In other words, the association unit 216 may automatically make an application to the identified second user for association of the second user with the first user. In other words, the association unit 216 may function as an application unit that makes an application to the identified second user to associate the second user with the first user without the first user performing an operation to instruct the application. When an application to associate the second user with the first user (specifically, an application to register as a friend or an application to follow) is made to the second user, the second user is associated with the first user when, for example, the second user performs a predetermined input operation to accept the application on his/her own terminal device 10 (in other words, the first user and the second user become friends, or the first user follows the second user).

In addition, each user may be able to set from their own terminal device 10 whether or not to automatically register other users as friends or users to be followed, or whether or not to automatically request friend registration or follow from other users.

In this embodiment, when various processes are "performed without user operation", it is sufficient that the process does not require user operation, and the user may perform a pre-setting operation such as setting conditions for performing the process in advance or enabling automatic execution of the process. Specifically, when "a request for association of the second user with the first user is performed without the first user performing an operation to instruct the request", it is sufficient that the request is performed without the need for an operation such as tapping a button to request friend registration in a conventional game, and the pre-setting operation for automatically performing the request may be performed.

The service of this embodiment may not have either the function of registering other users as friends or the function of registering users to be followed. In addition, when the service has both the function of registering other users as friends and the function of registering users to be followed, automatic registration or an application for registration may be made for one of them, but automatic registration or an application for registration may not be made for the other. In addition, the service may have both the function of registering other users as friends and the function of registering users to be followed, and automatic registration or an application for registration may be made for both, but the conditions for automatic registration for each may be different.

(Disconnection)
Up to this point, the automatic registration of the second user identified by the association unit 216 as a friend, the automatic following, and the automatic friend registration or follow application have been described. In other words, the automatic processing of the association between users has been described for the second user identified by the association unit 216. In the following, the operation of disassociating the second user associated with the first user based on the automatic processing of the association and the first user (i.e., the friend or following user of the first user. Hereinafter, also referred to as "related user") with the first user will be described. In addition to automatically associated users, the related users may include, for example, a user who became a friend or a following user when the first user applied for friend registration or follow from his/her own terminal device 10 and the other user accepted the application on his/her own terminal device 10. In other words, the related users may include manually associated users (specifically, a user who was associated based on the application when the friend registration or follow application was made based on the input operation of the first user). Here, when a friend registration or follow request is made based on an input operation of a first user, the second user may be registered as a friend or following user of the first user without the consent of the second user, or the registration may be made with the consent of the second user. Note that, hereinafter, a user who is automatically registered as a friend or follow, or an application for these, and associated with the second user, is also referred to as an "automatically associated user."

The storage unit 220 stores conditions for canceling an association between users (hereinafter referred to as "cancellation conditions"). The canceling unit 217 identifies, from among related users associated with each user, users who satisfy the cancellation conditions as users whose associations are to be cancelled (hereinafter referred to as "cancellation users"). In addition, the canceling unit 217 cancels the association with the identified cancellation users.

The release condition may be, for example, "not using content together for a predetermined period of time (in other words, not playing together for a predetermined period of time)." The release condition may be, for example, "the related user (or the first user) has not logged in for a predetermined period of time (in other words, not using the service)." The release condition may be, for example, "message transmission frequency is low (for example, the number of messages transmitted from one of the first user and the related user to the other (or the total number of messages transmitted from both) within a predetermined period of time is less than a predetermined number)." The release condition may be, for example, "the rank of the related user has not changed for a predetermined period of time." The release condition may be, for example, "the chat in the service has been disrupted by the related user." Note that whether or not the chat has been disrupted may be determined based on, for example, whether or not the number of times a preset prohibited word (in other words, a monitored word) has been used is greater than or equal to a predetermined number, or based on whether or not the number of messages transmitted from the related user to the first user is excessive compared to the number of messages transmitted from the first user to the related user.

The release conditions may be arbitrarily set by each user from his/her own terminal device 10. For example, the above-mentioned release conditions may be displayed as selection items on the display unit 18 of the terminal device 10, and the user may set the release conditions by performing an input operation to select the release condition that he/she wishes to apply (or the release condition that he/she wishes to stop applying).

The cancellation conditions may be such that the user cannot change them at will. In other words, at least some of the cancellation conditions may be such that the user cannot change them at will and they apply to all users.

In addition, when multiple conditions are set as the release conditions, the release unit 217 may release the association with related users who satisfy one of the multiple conditions, or may release the association with related users who satisfy multiple (e.g., all) of the conditions.

The cancellation conditions for automatic cancellation of related users may be applied to automatically associated users, but not to manually associated users. Here, "applied to automatically associated users, but not to manually associated users" includes, for example, (1) a configuration in which the system does not automatically cancel association based on the cancellation conditions for manually associated users, and (2) a configuration in which automatic cancellation of association is performed for manually associated users based on a second cancellation condition different from the cancellation conditions for automatic cancellation of automatically associated users. Note that the configuration of (2) also includes a configuration in which automatic cancellation of association is possible for both manually associated users and automatically associated users based on the same cancellation conditions, depending on the user's selection. With such a configuration, manual associated users who are other users that the user has proactively associated and who are more likely to wish to maintain the association are not automatically cancelled (or are made difficult to cancel), and automatically associated users who are less likely to wish to maintain the association compared to manually associated users are automatically cancelled.

The release condition may be relaxed or tightened depending on the number of related users associated with the user. In other words, the release unit 217 may change the release condition depending on the number of related users associated with the user. Specifically, the release unit 217 may, for example, relax the release condition (in other words, make it easier to release) as the number of related users increases. Here, relaxing the release condition as the number of related users increases means that there are at least two states, a state in which the release condition is stricter and a state in which the release condition is relaxed, with a certain predetermined number as a boundary. Here, the predetermined number may be a fixed number. The predetermined number may also be one that can be arbitrarily set by the user. The predetermined number may also be one that varies depending on the situation. The predetermined number may be, for example, a number whose ratio to the upper limit is equal to or greater than a predetermined ratio when an upper limit is set for the number of related users that can be associated with one user. In other words, the release unit 217 may, for example, relax the release condition (in other words, make it easier to release) as the number of related users associated with a certain user approaches the upper limit. The upper limit may be set separately for automatically associated users and manually associated users, or may be set for the combined number of automatically associated users and manually associated users. A state in which the release conditions are strict may be a state in which automatic release is not performed. In other words, the release unit 217 may not automatically release automatically associated users when, for example, the number of related users associated with a certain user is greater than the upper limit.

Relaxing the release conditions may mean, for example, reducing the number of conditions required to automatically release an association with a related user. Relaxing the release conditions may mean, for example, changing parameters related to each release condition. For example, when automatically releasing an association with a related user who meets a condition that specifies a period, such as "not using content together for a specified period," the parameter that specifies the period may be changed to shorten the period.

As described above, the release unit 217 identifies an associated user who satisfies the release condition as a release user, and releases the association with the identified release user. Furthermore, the release unit 217 automatically identifies the release user. In other words, when identifying a release user whose association with the first user is to be released, the release unit 217 identifies the release user without the first user performing an operation to instruct the identification.

The release unit 217 also automatically releases the association with the identified release user. In other words, when releasing the association of the release user with the first user, the release unit 217 releases the association of the release user without the first user performing an operation to instruct the release.

For example, the release user identified by the release unit 217 as a related user whose association with the first user is to be released may be presented to the first user before the association is released. Specifically, for example, when the release unit 217 identifies a release user, the identified release user may be displayed on the display unit 18 of the terminal device 10 of the first user before the association is released. Here, the identified release user may be displayed in a pop-up on the display unit 18 when the first user uses a service (in other words, starts an application) for the first time after the release user is identified. Also, the identified release user may be displayed in a list on the display unit 18. The list may be a list of related users whose association is to be released, and is created by, for example, the list creation unit 218. In addition, on the screen presenting the release users to the first user by such a pop-up display or list display, a display prompting the user to select whether or not to release the association of the release user is displayed, and the release unit 217 may release the association of the release user when the first user performs an input operation to select the release (in other words, an operation to instruct the release of the association). In other words, when releasing the association of the identified release user with the first user, the release unit 217 may release the association of the release user through an operation by the first user to instruct the release.

In addition, when the release unit 217 identifies the release user and automatically releases the association with the first user, the release user whose association has been released may be displayed on the display unit 18 of the terminal device 10 of the first user. Here, the release user may be displayed in a pop-up on the display unit 18 when, for example, the first user uses a service (in other words, starts an application) for the first time after the association of the release user is released. The display unit 18 may also display the release user whose association has been released in a list. The list may be a list of related users whose association has been released, and is created by, for example, the list creation unit 218. In addition, on a screen that presents the release user whose association has been released to the first user by such a pop-up display or list display, a display that prompts the user to select whether or not to restore the association with the release user whose association has been released (re-associate), and the release unit 217 may re-associate the release user whose association has been released with the first user when the first user performs an input operation to select the restoration (in other words, an operation to instruct re-association).

In addition, in the list of users to be released from the association, a time limit may be set for the period of listing each user on the list, and when a predetermined period has elapsed, the association of the user with the first user is released and the display of the user on the list may be terminated. In addition, in the list of users whose association has been released, a time limit may be set for the period of listing each user on the list, and when a predetermined period has elapsed, the display of the user on the list may be terminated. In other words, the list creation unit 218 may delete from the list a user who has been included in these lists for a predetermined period of time. In addition, each of these periods of listing may change depending on the number of related users associated with the user (for example, a percentage of the upper limit number, etc.).

The list of users who are scheduled to have their associations cancelled or the list of users whose associations have been cancelled may be created by the list creation unit 218 and stored in a predetermined storage unit such as the storage unit 220, and may be transmitted to the terminal device 10 when the list is displayed on the display unit 18.

The first user may be able to set from his/her own terminal device 10 whether or not to present to the first user the release user identified by the release unit 217 as an associated user whose association with the first user is to be released before the association is released (whether to release after the presentation or without the presentation). Also, the first user may be able to set from his/her own terminal device 10 whether or not to present to the first user the release user whose association has been released.

It should be noted that it may be possible to exclude related users who are not to be automatically released from the association by the release unit 217 from the targets of automatic association release. Specifically, for example, a list of related users associated with the first user is displayed on the display unit 18 of the terminal device 10 of the first user, and the input unit 17 accepts an input operation (e.g., a touch operation, etc.) for selecting a related user to be excluded from the targets of release from among the related users included in the list, and the release unit 217 may register the selected user in the storage unit 220 as a user to be excluded from the targets of release based on the input operation. The release unit 217 does not automatically specify a related user excluded from the targets of release as a user to be released or automatically release the association, even if the related user is a related user that satisfies the release condition. In other words, the related user management unit 215 may register a related user designated by the first user among the related users associated with the first user as a special related user to be excluded from the targets of release. In this case, the special related user is subject to restrictions regarding disassociation compared to related users who are not special related users (in other words, related users who are not designated by the first user) (e.g., they are not automatically identified as users to be disassociated or disassociated).

(List of related users)
A list of related users associated with each user (hereinafter referred to as a "related user list") can be viewed from the terminal device 10 of each user. The display control unit 114 of the terminal device 10 of each user causes the display unit 18 to display the related user list of related users associated with the user. An example of a related user list display screen 50 on which the related user list is displayed is shown in Fig. 3.

The related user list display screen 50 shown in FIG. 3 displays, for each related user, the user name and information on the history of the association (hereinafter referred to as "history information 51") as information on each related user, a history information input button 52 that is operated when inputting the history information 51, and various buttons for making settings related to the association. Each user can check the history of how each related user was associated with them by looking at the related user list display screen 50 (specifically, the history information 51).

For example, the history information 51 is input as follows. First, when the first user inputs the history information 51 for a specific related user, the first user performs an input operation to select the history information input button 52. When this input operation is performed, the display control unit 114 causes the display unit 18 to display the history information input screen 60. An example of the history information input screen 60 is shown in FIG. 4.

On the history information input screen 60, for example, multiple tags 61 related to the history of the association are displayed. The history information management unit 219 assigns a tag 61 selected by an input operation of the first user from the multiple tags 61 displayed on the history information input screen 60 to the specific related user as history information 51 of the specific related user and stores the tag 61 in the storage unit 220. Note that it may be possible to assign multiple tags 61 to one related user.

Here, the tag 61 may be, for example, something related to an event in an experience shared by the first user and the specific related user (for example, a game played together that triggered the association between the two) (for example, something related to the behavior of the first user or the specific related user, or something related to the performance of the first user or the specific related user, etc.), or something related to the relationship between the first user and the specific related user. Furthermore, the tag 61 may be, for example, something related to an event that caused the related users to be automatically associated. Specifically, the tag 61 may be, for example, "healed me," "healed me for someone," "gave me an assist attack," "gave me an assist attack," "gave me an item (including, for example, using a consumable item, etc.)," "gave me an item," "did well (in other words, performed well)," "did poorly (in other words, performed poorly)," "fought together," "played against each other," "won," "lost," "participated in a specific live show together," or "had a conversation in chat more than once."

In addition, the history information input screen 60 may provide assistance in selecting tags 61 related to events that actually occurred in the experience shared between the first user and the specific related user. Specifically, for example, the history information input screen 60 may preferentially display tags 61 related to events that actually occurred. Here, preferentially may mean, for example, that only tags 61 related to events that actually occurred are displayed, or that tags 61 related to events that actually occurred have a higher display priority (for example, the more tags 61 related to events that actually occurred are displayed at the top). In addition, for example, when the display of the history information input screen 60 is started, the display may start with the tag 61 related to the event that actually occurred selected (for example, with a check mark added in the example shown in FIG. 4).

The historical information input screen 60 may be displayed on the display unit 18 of the terminal device 10 of the first user (and the second user) at the time when the second user is automatically associated with the first user (at the time when the user is automatically registered as a friend, when the user is automatically followed, or when the second user accepts the automatic friend registration or follow request). The historical information input screen 60 may be displayed on the display unit 18 of the terminal device 10 of the first user (and the second user) at the time when the game in which it was decided to automatically associate the second user with the first user ends (for example, while the result is being displayed). In other words, when the historical information management unit 219 automatically associates the second user with the first user, the historical information management unit 219 may transmit information to the terminal device 10 for displaying the historical information input screen 60 as a display that prompts the user to input the historical information 51, and the display control unit 114 may display the historical information input screen 60 on the display unit 18 based on the information. Furthermore, in this manner, when the input of the history information 51 is prompted by displaying the history information input screen 60 at a predetermined timing, if the second user is automatically associated with the first user, a display prompting the input of the history information 51 is displayed on the terminal device 10 of the first user (and the second user), whereas if the second user is manually associated with the first user, a display prompting the input of the history information 51 is not displayed on the terminal device 10 of the first user (and the second user) (in other words, the history information management unit 219 may not transmit information for displaying the history information input screen 60 to the terminal device 10).

Note that tagging of the second user may be executable during the sharing of experiences (for example, during a game that triggers the association of the two users). Specifically, when the first user and the second user are playing a game together, and the second user revives the character of the first user, the first user can perform an input operation on his/her own terminal device 10 to tag the second user with the tag 61 "revived me" (for example, the tag 61 is displayed on the display unit 18, and an input operation to select the tag 61 is possible), and the association unit 216 may assign the tag 61 to the second user as the history information 51 of the second user based on the input operation and store it in the storage unit 220. Note that in this case, the tag 61 may be able to be assigned to the second user during the sharing of experiences and before it is determined to associate the second user with the first user. Furthermore, the association unit 216 may associate the second user with the first user (in other words, register as a friend, follow, or apply for these) based on the tag 61 being added.

Note that, here, the historical information 51 is input on the historical information input screen 60 based on the selection of the tag 61, but the historical information 51 may also be input by text input on the historical information input screen 60.

In addition, the history information 51 may be automatically input without user operation, for example. For example, an event that caused the related user to be automatically associated may be automatically input as the history information 51. Specifically, for example, when the second user automatically registers the second user as a related user of the first user based on the second user performing an action of recovering the character of the first user (specifically, an action of reviving) three times in a certain match X during the game, the history information management unit 219 may automatically (in other words, without the operation of the first user) attach history information 51 of "revived three times in match X" to the second user and store it in the storage unit 220 as information on the related user. In other words, for example, an event during a play (for example, a match) that triggered the automatic association of the second user, or the relationship between the first user and the second user, may be automatically input as the history information 51. Furthermore, the history information 51 automatically stored in the storage unit 220 may be editable based on an input operation by the user on the terminal device 10. In this case, for example, the history information management unit 219 edits the history information 51 based on the input operation.

When the history information input screen 60 is displayed at a predetermined timing, the history information 51 may be displayed in an automatically input state, and the history information input screen 60 may be configured to accept an input operation by the user to edit the automatically input history information 51. The input operation may be, for example, a text input operation to edit the automatically input history information 51, or an input operation to delete an automatically added tag 61 (including, for example, a case where a check mark is automatically added in the example shown in FIG. 4) or to add another tag 61.

The various buttons displayed on the related user list display screen 50 for configuring settings related to associations include, for example, a release button 53 operated to release an association with a related user, a favorite button 54 operated to register a related user as a favorite, a condition edit button 55 operated to edit the registration conditions of a related user, a condition release button 56 operated to release the condition settings, and a condition setting object 57 operated to set registration conditions based on the history information 51.

When an input operation is performed on the release button 53, the release unit 217 releases the association with the target related user. In other words, the user can manually release the association with the related user by operating the release button 53. Note that when the release button 53 is operated, the display control unit 114 may display on the display unit 18 a confirmation screen or the like for confirming whether or not the association should really be released.

When an input operation is performed on the favorite button 54, the related user management unit 215 registers the target related user (in other words, the related user related to the operated favorite button 54) as a favorite. For related users registered as favorites, even if the related users satisfy the cancellation conditions, the related users are not automatically identified as cancellation users or automatically cancelled. In addition, for related users registered as favorites, when cancelling the association based on an operation on the cancel button 53, the number of steps required for cancellation (for example, the number of times to confirm whether or not to cancel) may be increased compared to related users not registered as favorites. In other words, the related user management unit 215 registers the related users designated by the first user among the related users associated with the first user as special related users (in other words, favorites). Here, the special related user may be subject to restrictions regarding disassociation compared to related users that are not special related users (in other words, related users not designated by the first user) (for example, they may not be automatically identified as a user to be disassociated or may be subject to more steps by the first user when disassociating).

Note that the registration of a related user as a favorite does not have to be based on an operation on the favorite button 54. For example, the related user management unit 215 may automatically register as a favorite a related user whose history information 51 has been entered by a user's input operation (e.g., input by text input or input by selecting a tag 61, etc.).

When an input operation is performed on the condition edit button 55, the display control unit 114 causes the display unit 18 to display an edit screen (not shown) for editing the registration conditions. When the registration conditions are edited (in other words, set) on the edit screen, the association unit 216 automatically associates users who satisfy the edited registration conditions. In other words, in this embodiment, by editing the registration conditions on the edit screen, it is possible to change the conditions of users to be automatically associated. In further other words, in this embodiment, the registration conditions of related users can be edited based on an input operation on the condition edit button 55.

On the editing screen, for example, it may be possible to set detailed conditions for the registration conditions corresponding to the historical information 51 of the target related user. Specifically, when the condition editing button 55 for a related user to which historical information 51 "resuscitated me three times in game X" is attached, i.e., the historical information 51 "performed resuscitation" is operated, the editing screen may set, as a detailed condition for the registration condition "performed resuscitation", "how many times" the user who performed the resuscitation must have performed resuscitation before being automatically registered as a related user. In other words, the editing screen may be capable of accepting input operations for setting the detailed conditions.

In addition, the edit screen may allow the setting of registration conditions that are unrelated to the historical information 51 of the target related user. Specifically, when the condition edit button 55 for a related user to which the historical information 51 of "revived" is attached is operated, the edit screen may allow the setting of a registration condition of "gave an item" or a registration condition of "fought together" in place of or in addition to the registration condition of "revived."

In addition, in this embodiment, when an input operation is performed on the condition setting object 57, the association unit 216 sets a condition (i.e., a registration condition) that other users should satisfy in order to automatically associate in the future based on the history information 51 of the target related user. Specifically, on the related user list display screen 50, the registration condition extracted based on the history information 51 of each related user is displayed as a condition setting object 57. More specifically, for example, if the related user has history information 51 such as "resuscitated me three times in game X," the condition setting object 57 related to the registration condition "resuscitated me" is displayed on the related user list display screen 50 as a registration condition extracted based on the history information 51. Then, when the user performs an input operation on the condition setting object 57, the association unit 216 sets (in other words, activates) the registration condition "resuscitated me" so that other users who resuscitated me will be automatically associated in the future. That is, in this embodiment, the registration conditions related to the history information 51 are displayed on the related user list display screen 50 as candidates for the registration conditions to be set (in other words, enabled), and the setting of the registration conditions is proposed to the user. The display of the condition setting object 57 can be realized, for example, as follows. That is, a table showing the correspondence between the keywords (for example, "resuscitation" in the above example) that may be included in the history information 51 and the registration conditions is stored in the storage unit 220, and when the history information 51 includes a specific keyword, the related user management unit 215 may extract the registration conditions corresponding to the specific keyword and transmit information to the terminal device 10 for displaying the condition setting object 57 related to the extracted registration condition on the display unit 18.

The condition release button 56 is a button that is operated when canceling (in other words, invalidating) the setting of the registration condition displayed as the condition setting object 57. When an input operation is performed on the condition release button 56, the association unit 216 excludes the registration condition related to the condition setting object 57 of the target related user from the conditions that other users must satisfy in order to automatically associate in the future. In other words, when an input operation is performed on the condition release button 56, the association unit 216 excludes the registration condition extracted based on the history information 51 of the target related user from the conditions that other users must satisfy in order to automatically associate in the future. Note that when an input operation is performed on the condition release button 56, the association unit 216 may exclude the registration condition that the related user satisfied when automatically associating the target related user from the conditions that other users must satisfy in order to automatically associate in the future. When an input operation is performed on the condition release button 56 and the setting of the registration condition is released, the condition release button 56 changes to a condition setting button (not shown), and when an input operation is performed on the condition setting button, the registration condition that was released (in other words, disabled) based on the input operation on the condition release button 56 may be set again (in other words, enabled). In other words, the condition setting object 57 may not be an object that accepts an operation to set (in other words, enable) the registration condition, but may simply be an object that displays the specified registration condition.

In addition, information necessary for displaying the related user list, such as the history information 51, is stored, for example, in the memory unit 220 of the server 20, and is transmitted from the related user management unit 215 to the terminal device 10 when the related user list is displayed (for example, based on a request from the terminal device 10 to the server 20 based on a predetermined input operation to the operation reception unit 111).In addition, information necessary for displaying the related user list may be stored in the memory unit 120.

(Classification list)
The list creation unit 218 creates a number of lists (hereinafter referred to as "category lists") in which a number of related users associated with the user are classified according to the attributes of the related users. Furthermore, the display control unit 114 of each user's terminal device 10 causes the display unit 18 to display the category list of the related users associated with the user. An example of a category list display screen 70 on which the category lists are displayed is shown in FIG. 5.

The list creation unit 218 may create multiple category lists that classify related users associated with the first user according to their compatibility with the first user, for example. Note that one related user may be assigned to multiple category lists. Also, one related user may not be assigned to multiple category lists (in other words, not included in duplicate). Also, each related user may always be assigned to one of the category lists, and there may be no related users that are not assigned to any category list. Also, there may be related users that are not assigned to any category list.

Specifically, for example, assuming a predetermined game (specifically, a role-playing game, FPS, etc.), the list creation unit 218 may create a classification list in which related users are classified according to their compatibility with the first user, such as a classification list that brings together related users with the attribute "good at recovery" (see FIG. 5(a)) and a classification list that brings together related users with the attribute "good at attack" (see FIG. 5(b)). Here, whether a user is good at recovery or attack may be determined, for example, based on the attribute (e.g., occupation) of the character used by each related user, or based on items owned by each related user. For example, related users whose characters are occupations such as "recovery magician" and "medicine" may be included in the classification list of related users who are good at recovery. Also, for example, related users whose characters are occupations such as "attack magician" and "swordsman" may be included in the classification list of related users who are good at attack. Here, the character used may be, for example, the character used most frequently (in other words, the most) by the user, a character set as the main character in a game in which each user can select a main character, a character registered as a favorite in a game in which each user can register a frequently used character as a favorite, a character that has been used more than a predetermined number of times, or a character that has been used more than a predetermined number of times. Also, for example, a related user who owns a predetermined number or more of recovery items may be included in the classification list of related users who are good at recovery. Also, for example, a related user who owns a weapon with higher attack performance than weapons owned by other users (in other words, other weapons existing in the game), such as the strongest gun in the game, may be included in the classification list of related users who are good at attack.

In other words, the list creation unit 218 may create a classification list in which related users are classified according to the attributes of the characters used by the related users as a classification list in which related users are classified according to their compatibility with the first user. The list creation unit 218 may create a classification list in which related users are classified according to the character's occupation, etc., as described above, or may create a classification list in which related users are classified according to the character's rank, etc. In addition, the list creation unit 218 may create a classification list that brings together related users who use characters that do not overlap with the characters used by the user, for example. Such a classification list, etc., classified according to the character's attributes makes it easier for the first user to find related users who are easy to play with (for example, related users who have characters with attributes that the first user finds easy to play with, related users in a rank range that the first user finds easy to play with, etc.) and related users who are difficult to play with, and can be said to be a classification list classified according to compatibility with the first user.

The list creation unit 218 may also create a classification list in which related users are classified according to their compatibility with the first user, the classification list being based on the past play history between the first user and each related user. Specifically, for example, assuming a predetermined game (specifically, a game aiming to achieve a predetermined objective (e.g., a battle game), etc.), the list creation unit 218 may create a classification list in which related users are classified according to the number of times or the probability (in other words, the winning rate in a battle game, etc.) that the related user and the first user have played together in the past (here, together may mean either playing as friends or playing as enemies) to achieve the predetermined objective. In addition, the list creation unit 218 may create a classification list in which related users are classified according to, for example, the number of times that one of the first user and the related user has given a favorable reaction to the other (e.g., the number of so-called "likes"). In addition, the list creation unit 218 may create a classification list in which related users are classified according to, for example, the number of times that one of the first user and the related user has performed an action that is beneficial to the other.

For example, the list creation unit 218 may create a classification list in which related users are classified according to their compatibility with the first user, and the related users are classified according to their compatibility with each stage. Specifically, for example, in an FPS where a plurality of stages (in other words, maps) including a first stage and a second stage are prepared, the list creation unit 218 may create a classification list that brings together related users who have good compatibility with the first stage and a classification list that brings together related users who have good compatibility with the second stage. Here, the compatibility of each related user with each stage may be determined based on, for example, the win rate of each related user in past matches at each stage (e.g., a win rate of 70% or more means good compatibility, etc.), the number of wins (e.g., a good compatibility if the cumulative number of wins reaches 100, etc.), or whether or not the user performed well in the previous match (e.g., a good compatibility if the user won the match, etc.).

The list creation unit 218 may also create multiple classification lists that classify related users associated with the first user according to the frequency with which they play together. Specifically, the list creation unit 218 may create multiple classification lists that classify related users according to the number of times they play together within a predetermined period of time.

The list creation unit 218 may also create multiple classification lists in which related users associated with the first user are classified according to the history information 51 attached to the related users. Specifically, the list creation unit 218 may create multiple classification lists in which related users are classified according to the tags 61 attached to the related users.

In addition, the list creation unit 218 may create multiple classification lists in which related users associated with the first user are classified according to attributes based on the actions of the related users in the service. Specifically, the list creation unit 218 may create multiple classification lists in which related users associated with the first user are classified according to attributes based on the actions of the related users in content (e.g., a game) used together with the first user. The attributes based on the actions include attributes related to the results of the actions. Specifically, the list creation unit 218 may create multiple classification lists in which related users are classified according to the type of action performed by the related user (e.g., healed the first user, performed an assist attack, gave an item, defeated an enemy character), the number of times a specific action was performed, the number of times a specific result (e.g., won a match) was obtained (in other words, achieved) as a result of the action, the type of result obtained, or the probability of obtaining a specific result (e.g., win rate, etc.). In addition, the list creation unit 218 may create multiple classification lists in which related users associated with the first user are classified according to attributes based on actions of the related users within the service that are beneficial to the first user. Specifically, the list creation unit 218 may create multiple classification lists in which related users are classified according to, for example, the type of action that the related users performed that is beneficial to the first user, the number of times that the related users performed a specific beneficial action, the number of times that a specific result was obtained as a result of a beneficial action, the type of result obtained by a beneficial action, etc.

The multiple category lists created by the list creation unit 218 are stored in the memory unit 220 of the server 20, which functions as a category list storage unit. In addition, each category list stored in the memory unit 220 can be presented to the first user at a predetermined timing (can be displayed on the terminal device 10 of the first user at a predetermined timing).

The conditions for the related users to be included in each classification list may be set by each user from his/her own terminal device 10. In other words, how to classify the related users and what kind of classification list to create may be set by each user from his/her own terminal device 10.

As described above, the association unit 216 automatically associates other users who share a certain experience with the first user with the first user, but the list creation unit 218 may automatically sort the related users who are automatically associated in this way into a category list according to the attributes of the related users. Also, each user may be able to manually select from his/her own terminal device 10 which category list to sort the related users who are automatically associated in this way.

The association unit 216 also automatically associates with the first user other users who share a predetermined experience with the first user and have a predetermined relationship with the first user within the service, where the predetermined relationship may be "a relationship that falls under any of the classification lists." That is, for example, when a classification list of related users who are compatible with the first stage in an FPS is prepared as the classification list of the first user, users who participated in the same match as the first user and who are compatible with the first stage may be automatically registered as friends of the first user, etc. In other words, when multiple classifications are stored in the storage unit 220 as classifications of friends, the association unit 216 may automatically associate users who fall under any of the multiple classifications.

The list creation unit 218 creates multiple category lists and stores them in the storage unit 220, but the multiple category lists do not have to classify multiple related users according to the attributes of the related users. For example, the list creation unit 218 may create a category list in which multiple related users associated with the first user are simply classified into multiple lists. Also, the first user may be able to select which related users to include in each category list on his/her own terminal device 10. In other words, the list creation unit 218 may determine the related users to be included in each category list based on the user's operation. In other words, the storage unit 220 may be able to store multiple category lists created based on the user's operation.

The display of the category list on the display unit 18 may be, for example, as follows. That is, for example, as shown in FIG. 5, an object (e.g., tab 71) that accepts an operation to select a category list to be displayed from among multiple category lists may be displayed on the category list display screen 70 displayed on the display unit 18 and that displays the category list. The display control unit 114 may display the category list selected by the user's input operation on the object on the display unit 18. Note that the category list information required for displaying the category list may be sent from the server 20 to the terminal device 10 based on a request from the terminal device 10, for example, when the display of the category list display screen 70 starts, or may be requested from the terminal device 10 to the server 20 based on a user's input operation to select the category list to be displayed, and may be sent from the server 20 to the terminal device 10. Note that the multiple category lists may be stored in the storage unit 120 of the terminal device 10, and the display control unit 114 may display the category list stored in the storage unit 120 on the display unit 18. The control unit 110 of the terminal device 10 may also be provided with a list creation unit 218.

As described above, in this embodiment, the list creation unit 218 stores multiple category lists in the storage unit, and each of the multiple category lists stored in the storage unit is displayed on the terminal device 10. In other words, the configuration according to this embodiment is different from a configuration that simply displays a result of narrowing down multiple related users associated with a user based on a predetermined search condition input by the user, or a configuration that simply displays a result of sorting the multiple related users based on a predetermined condition input by the user, and is configured such that multiple category lists are created and stored in advance at a point in time before the list of related users is displayed.

In addition, when the display control unit 114 displays the classification list on the display unit 18, the display control unit 114 may preferentially display a classification list suitable for a predetermined situation in the service determined based on the user's selection. In addition, preferentially may mean that only the classification list suitable for the predetermined situation is displayed, or that the classification list suitable for the predetermined situation has a high display priority (for example, a classification list suitable for the predetermined situation is displayed first, and other classification lists are displayed based on an input operation (for example, an operation to select the above-mentioned tab) that changes the classification list to be displayed, or a classification list suitable for the predetermined situation is displayed larger than other classification lists). Here, as a specific example, as shown in FIG. 6(a), a case will be described in which a stage selection screen 75 that allows the selection of various stages (in other words, maps) such as a first stage and a second stage in an FPS is displayed on the display unit 18. In addition, the stage selection screen 75 may be, for example, a screen on which a battle at a stage is started by selecting a stage, or a screen on which information about a stage can be confirmed by selecting a stage. When an input operation to select the first stage is performed on the stage selection screen 75, the display control unit 114 displays on the display unit 18 a category list display screen 70 in which a category list of related users who have good compatibility with the first stage is displayed, as shown in FIG. 6B. On the other hand, when an input operation to select the second stage is performed on the stage selection screen 75, the display control unit 114 displays on the display unit 18 a category list display screen 70 in which a category list of related users who have good compatibility with the second stage is displayed. That is, the display control unit 114 displays on the display unit 18 a category list of related users who have attributes suitable for a predetermined situation (in other words, the stage that the user is going to play) determined based on the user's selection from among a plurality of category lists. As described above, the stage selection screen 75 may be a screen in which a battle on a stage is started by selecting the stage. For example, when an input operation to select a stage is performed on the stage selection screen 75 and an operation to select one or more related users from the displayed classification list is performed, an invitation to participate in play is sent from the terminal device 10 of the selected user to the terminal device 10 of the selected related user via the server 20, and when the related user performs an operation to accept the invitation, play on that stage may begin with both users participating.

The situation determined based on the user's selection may be, for example, an event in which the user wishes to participate. For example, when the user performs an input operation to select a live show in which the user wishes to participate, the display control unit 114 may preferentially display a categorized list of related users who have attributes suitable for participating in the live show together (for example, a categorized list of related users who are determined to be highly likely to be interested in the live show based on the history of events they have attended).

The situation determined based on the user's selection may be related to the user's attributes, for example. Specifically, for example, in a role-playing game, when a user selects a character that is good at recovery as the character to be used, and the user performs a predetermined input operation to display a list of related users, the display control unit 114 may preferentially display a classification list of related users who use characters that are good at attacking (in other words, a classification list of related users who have attributes that complement the user's attributes) as a classification list of related users who have attributes suitable for the situation of playing with a character that is good at recovery.

Here, it has been described that the list creation unit 218 creates multiple category lists in advance and stores them in the storage unit, and the display control unit 114 displays a category list selected from the multiple category lists when displaying the category lists on the display unit 18. However, the list creation unit 218 may create a category list when displaying on the display unit 18. Specifically, for example, when an input operation to select the first stage is performed on the stage selection screen 75 shown in FIG. 6(a), the list creation unit 218 may create a category list of related users who are compatible with the first stage (in other words, a list of related users who have attributes suitable for a situation determined based on the user's selection), and the display control unit 114 may display the category list on the display unit 18.

Next, the flow of the process executed by the system 1 will be described with reference to Figures 7 to 11. Note that the description here will be given taking as an example a case where the system 1 according to this embodiment is applied to a game (specifically, an FPS).

(Processing related to association)
The process of automatically associating a second user with a first user, who is a predetermined user using the system 1, will be described with reference to FIG.

First, the association unit 216 of the server 20 identifies users who share an experience with the first user (step S101). Specifically, the association unit 216 identifies, for example, users who are participating in the same match as the first user.

Next, the association unit 216 determines whether or not there is a user who satisfies the registration condition for automatically associating the first user with the first user among the users participating in the same match as the first user (step S102). Here, it is assumed that the registration condition is input in advance by the first user from his/her own terminal device 10 and stored in the storage unit 220 of the server 20 as a registration condition storage unit. It is also assumed here that the registration condition input and set by the first user is "revived three or more times during one match."

If there is no user who satisfies the registration condition among the users participating in the same match as the first user (NO in step S102), the association unit 216 does not perform the process of automatically associating another user with the first user. Specifically, if there is no second user who has revived the first user three or more times before the end of one match, the association unit 216 does not perform the process of automatically associating another user with the first user.

On the other hand, if there is a user who satisfies the registration condition among the users participating in the same match as the first user (YES in step S102), the association unit 216 automatically performs a predetermined process to associate the other user with the first user. Specifically, if there is a second user who has revived the first user three or more times before the end of one match (YES in step S102), the association unit 216 makes a friend registration request from the first user to the second user (step S103). At this time, the association unit 216 automatically makes the request without requiring an input operation by the first user. Specifically, the association unit 216 transmits data related to the friend registration request to the terminal device 10 of the second user (step S103). When the transmission/reception unit 112 of the terminal device 10 of the second user receives the data, the display control unit 114 of the terminal device 10 of the second user causes the display unit 18 to display a screen (hereinafter referred to as an "acceptance screen") that prompts the second user to respond to the friend registration request from the first user (step S104). The acceptance screen displays a message asking the second user whether or not to accept the friend registration request from the first user. In other words, while the acceptance screen is displayed, the operation acceptance unit 111 of the terminal device 10 of the second user accepts an operation to accept or reject the friend registration request as an operation related to the response to the friend registration request.

When the second user's terminal device 10 receives an operation to accept or reject the friend registration request, data indicating whether or not to accept the friend registration request (in other words, a response to the friend registration request) is sent from the transceiver unit 112 of the terminal device 10 to the association unit 216 (step S105).

When the association unit 216 receives data indicating whether or not to accept the friend registration request sent from the terminal device 10 of the second user, the association unit 216 determines whether or not the friend registration request has been accepted based on the data (step S106). That is, if the second user performs an operation to accept the friend registration request, the association unit 216 determines that the friend registration request has been accepted (YES in step S106). On the other hand, if the second user performs an operation to reject the friend registration request, the association unit 216 determines that the friend registration request has been rejected (NO in step S106). If the association unit 216 determines that the friend registration request has been rejected (NO in step S106), the association unit 216 does not associate the second user with the first user.

When it is determined that the friend registration request has been accepted (YES in step S106), the association unit 216 associates the first user with the second user (step S107). In other words, when it is determined that the friend registration request has been accepted, the association unit 216 registers the second user as a friend of the first user. In further other words, when it is determined that the friend registration request has been accepted, the association unit 216 stores information indicating that the second user is a friend of the first user in the storage unit 220.

Furthermore, when the association unit 216 associates the first user with the second user, it transmits data to the terminal device 10 of the first user indicating that the second user has been registered as a friend of the first user (step S108). In other words, the server 20 notifies the terminal device 10 of the first user that the second user has been registered as a friend of the first user. When the transmission/reception unit 112 of the terminal device 10 of the first user receives the data, the display control unit 114 of the terminal device 10 of the first user causes the display unit 18 to display a registration notification screen notifying the first user that the second user has been registered as a friend of the first user (step S109).

In addition, in the terminal device 10 of the second user, when a friend registration request is received from another user, it may be possible to set in advance whether or not to receive the request (in other words, whether or not to display an acceptance screen). Also, if the setting is set to reject the reception of the request, the association unit 216 may determine that the friend registration request has been rejected (NO in step S106). Also, for example, in the terminal device 10 of the second user, it may be possible to set a whitelist that specifies the conditions of users who want to become friends, or a blacklist that specifies the conditions of users who do not want to become friends. Then, requests from users who satisfy the conditions set in the whitelist may be received. Also, it may be possible to reject requests from users who satisfy the conditions set in the blacklist.

Note that, although the association unit 216 has been described here as making a friend registration request when the registration conditions are met, it may also make a follow request instead of a friend request. Also, for example, when the registration conditions are met, friend registration or following may be performed automatically without making a request. In other words, for example, when the answer is YES in step S102, the configuration may be such that the processing of step S107 is performed without going through the processing of steps S103 to S106.

(Processing for Cancellation of Association)
Next, a process of automatically canceling the association of a related user associated with a first user with the first user will be described with reference to FIG.

First, the release unit 217 of the server 20 determines whether or not there is a related user who satisfies the release condition among the related users associated with the first user (step S201). Here, it is assumed that the release condition is input in advance by the first user from his/her terminal device 10 and stored in the storage unit 220 of the server 20, which serves as a release condition storage unit.

If there is an associated user who satisfies the release condition (YES in step S201), the release unit 217 identifies the associated user as the release user and transmits data informing the identified release user to the terminal device 10 of the first user (step S202). When the transmission/reception unit 112 of the terminal device 10 of the first user receives the data, the display control unit 114 of the terminal device 10 of the first user causes the display unit 18 to display a release confirmation screen prompting the user to answer whether or not to release the association with the release user (step S203). While the release confirmation screen is displayed, the operation acceptance unit 111 of the terminal device 10 of the first user accepts operations to accept and reject the release of the association with the release user.

When the terminal device 10 of the first user receives an operation to accept or reject the cancellation of the association with the canceling user, data indicating whether or not the cancellation of the association with the canceling user is accepted (in other words, a response regarding the cancellation of the association with the canceling user) is sent from the transceiver unit 112 of the terminal device 10 to the cancellation unit 217 (step S204).

When the release unit 217 receives data indicating whether or not the release of the association with the release user is accepted from the terminal device 10 of the first user, the release unit 217 determines whether or not the release of the association with the release user is accepted based on the data (step S205). That is, if the first user performs an operation to accept the release, it is determined that the release of the association with the release user is accepted (YES in step S205). On the other hand, if the first user performs an operation to reject the release, it is determined that the release of the association with the release user is rejected (NO in step S205). If it is determined that the release is rejected (NO in step S205), the release unit 217 does not release the association of the release user with the first user.

If it is determined that the cancellation of the association with the release user has been approved (YES in step S205), the cancellation unit 217 cancels the association of the release user with the first user (step S206).

(Processing relating to input of historical information)
Next, a process of inputting the history information 51 about a second user as a related user associated with a first user will be described with reference to FIG.

First, the history information management unit 219 determines the tag 61 to be displayed on the history information input screen 60 (step S301). Here, the history information management unit 219 determines the tag 61 to be displayed on the history information input screen 60 based on an event in a match that triggered the association of the first user with the second user (in other words, a match in which the second user satisfied the registration condition set by the first user (here, the registration condition is "revived three or more times during one match"). Specifically, for example, the history information management unit 219 determines the tag 61 to be displayed as "revived" based on the fact that the character of the second user revived the character of the first user in this match. Also, for example, if the character of the second user attacks the opponent that the character of the first user is attacking together with the opponent, the tag 61 to be displayed as "assisted attack" is determined. Also, for example, if the first user and the second user work together to win the match, the tag 61 "worked together" and the tag 61 "won" are determined as tags 61 to be displayed. Note that, in the process of step S301, a table showing the correspondence between events that may occur in the match and the tags 61 to be displayed is stored in the storage unit 220, and the history information management unit 219 may use the table to extract tags 61 corresponding to events that actually occurred in the match, and determine them as tags 61 to be displayed on the history information input screen 60.

Next, the history information management unit 219 transmits information necessary for displaying the history information input screen 60, including information about the tag 61 to be displayed, to the terminal device 10 of the first user (step S302).

When the transmitting/receiving unit 112 of the terminal device 10 of the first user receives the information, the display control unit 114 of the terminal device 10 of the first user displays the history information input screen 60 (step S303). This history information input screen 60 displays the tag 61 that was determined to be displayed in step S301.

Next, the operation reception unit 111 of the terminal device 10 of the first user receives an input operation to select a tag 61 to be added as the historical information 51 for the second user from among the tags 61 displayed on the historical information input screen 60 (step S304). In other words, while the historical information input screen 60 is displayed, an input operation to input the historical information 51 is received.

When an input operation to select a tag 61 is received on the terminal device 10 of the first user, data indicating the selected tag 61 (in other words, data related to the input history information) is sent from the transceiver unit 112 of the terminal device 10 to the related user management unit 215 (step S305).

When the history information management unit 219 receives the data indicating the selected tag 61, it assigns the selected tag 61 to the second user as the history information 51 of the second user and stores it in the storage unit 220 (step S306). In other words, the history information management unit 219 registers the history information 51 of the second user based on the input operation on the terminal device 10.

Note that here, the tag 61 selected may be one or multiple.

(Processing related to display of classification list)
Next, a process for creating and displaying a classification list in which a plurality of related users associated with a first user are classified according to the attributes of the related users will be described with reference to FIG.

First, the list creation unit 218 classifies multiple related users associated with the first user according to the attributes of the related users, and creates a classification list (step S401). Specifically, the list creation unit 218 references the user information 223 of each related user to classify the related users and create a classification list. For example, the list creation unit 218 classifies related users who use characters that are good at attacking into related users who are good at attacking, and creates a classification list that brings together related users who are good at attacking. In addition, the list creation unit 218 classifies related users who use characters that are good at healing into related users who are good at healing, and creates a classification list that brings together related users who are good at healing.

The list creation unit 218 also stores the created classification lists in the memory unit 220, which functions as a classification list storage unit (step S402).

To display the category list, first, the terminal device 10 of the first user requests the server 20 to transmit the category list (step S403). Based on the request, the related user management unit 215 transmits the category list to the terminal device 10 of the first user (step S404). In this example, it is assumed that a category list of related users who are good at attacking and a category list of related users who are good at recovering are transmitted.

Next, the display control unit 114 of the terminal device 10 of the first user causes the display unit 18 to display a screen (e.g., the category list display screen 70 shown in FIG. 5) that prompts the user to select a category list to display (e.g., whether to display a category list of related users who are good at attacking or a category list of related users who are good at recovering) (step S405). While the screen is being displayed, the operation reception unit 111 also receives an input operation to select the category list to display.

When an input operation is performed to select the category list to be displayed, the display control unit 114 causes the display unit 18 to display the selected category list (step S406).

The list creation unit 218 may be included in the terminal device 10. Also, the terminal device 10 may have a category list storage unit (e.g., storage unit 120) that stores the category list. In this case, the display control unit 114 may cause the display unit 18 to display the category list selected by the user from among multiple category lists stored in the terminal device 10 (steps S405 and S406).

(Modification of Processing Related to Display of Category List)
Next, a modified example of the process for creating and displaying a classification list in which a plurality of related users associated with a first user are classified according to the attributes of the related users will be described with reference to FIG.

First, the display control unit 114 of the terminal device 10 of the first user causes the display unit 18 to display a screen that prompts the user to select a situation (e.g., a situation of a game that the first user intends to play) (step S501). While the screen is being displayed, the operation acceptance unit 111 accepts an input operation to select a situation. Specifically, the operation acceptance unit 111 accepts an input operation to select a stage (in other words, a map) as the situation.

Next, the terminal device 10 of the first user requests the server 20 to transmit a classification list suitable for the selected situation (specifically, the stage) (step S502). In addition, the related user management unit 215 transmits a classification list of related users having attributes suitable for the selected situation to the terminal device 10 of the first user based on the request (step S503). Specifically, for example, when the first user performs an input operation to select the first stage from a plurality of stages including the first stage and the second stage, the related user management unit 215 transmits to the terminal device 10 of the first user a classification list that summarizes related users who have a high win rate in past matches in the first stage among a plurality of related users associated with the first user. Note that the classification list transmitted from the related user management unit 215 to the terminal device 10 here may be one created by the list creation unit 218 based on the request, or may be one extracted based on the request from a plurality of classification lists created in advance by the list creation unit 218 and stored in the storage unit 220. The list creation unit 218 may be included in the terminal device 10. Also, the category list storage unit (e.g., the storage unit 120) that stores the category list may be included in the terminal device 10.

Next, the display control unit 114 of the terminal device 10 of the first user causes the display unit 18 to display the categorized list of related users having attributes suitable for the selected situation, which was sent from the server 20 (step S504).

The present invention is not limited to the above-described embodiment, and can be modified in various ways without departing from the spirit of the invention. Within the scope of the invention, the components can be freely combined, any component can be modified, or any component can be omitted. The process flow described in this specification is merely an example, and the order and configuration of each process can be different.

<Additional Notes>
The matters described in the above embodiment can also be described as follows.

(Appendix 1)
Computer,
A program that functions as an application means (e.g., an association unit 216) that automatically makes an application to a second user regarding association of the second user with the first user after a decision has been made to share a specified experience with a first user within a specified service, and to the second user during or after the experience has been shared.
With this configuration, when registering another user as a friend or following another user in a specific service such as a game, it is not necessary to make an application to the other user. This makes it easier to associate users. In addition, the other user can reject the application, which prevents the number of unnecessary friends from increasing.

(Appendix 2)
The program according to claim 1, wherein the second user is a user who has decided to use, is currently using, or has used the specified content in the specified service together with the first user.
According to such a configuration, it becomes easy to associate with users who have used the content together.

(Appendix 3)
The computer further comprises:
The program described in Appendix 1 functions as an associating means (e.g., an associating unit 216) that associates the second user with the first user based on an operation by the second user to approve the application.

(Appendix 4)
The program according to any one of appendixes 1 to 3, wherein the second user is a user who has a predetermined relationship with the first user within the predetermined service.
According to such a configuration, it is possible to limit the parties to whom an association request is automatically made to those users who have a predetermined relationship among users who share a predetermined experience.

(Appendix 5)
The program described in Appendix 4, wherein the specified relationship is a relationship that satisfies a condition set by the first user as a partner to which the application is to be automatically made.
According to such a configuration, each user can set conditions for a party to whom an association request is automatically made.

(Appendix 6)
An information processing device comprising an application means (e.g., an association unit 216) that automatically makes an application to a second user regarding association of the second user with the first user after deciding to share a specified experience with a first user within a specified service, during sharing, or after sharing.
With this configuration, the same effects as those of the program described in Supplementary Note 1 can be achieved.

1 System, 10 Terminal device, 11 Processor, 12 Memory, 13 Storage, 16 Touch screen, 17 Input unit, 18 Display unit, 20 Server, 21 Processor, 22 Memory, 23 Storage, 50 Related user list display screen, 51 History information, 60 History information input screen, 61 Tag, 70 Classification list display screen, 75 Stage selection screen, 110 Control unit, 111 Operation reception unit, 112 Transmission and reception unit, 113 Progression unit, 114 Display control unit, 120 Storage unit, 210 Control unit, 211 Transmission and reception unit, 212 Server processing unit, 214 Synchronization processing unit, 215 Related user management unit, 216 Association unit, 217 Release unit, 218 List creation unit, 219 History information management unit, 220 Storage unit

Claims (4)

Computer,
an application means for automatically making an application for associating a first user with a second user who has decided to share a predetermined experience with a first user in a predetermined service, the second user being shared with the second user, or the second user having shared the experience with the first user;
an association means for associating the second user with the first user based on an operation by the second user to approve the application;
a setting unit that can set conditions related to the transmission or reception of the application based on an operation of the first user or the second user;
The setting means is
Setting a condition regarding a relationship between the first user and a party to which an association request is automatically sent in the predetermined service as a condition for automatically sending the request from the first user to the second user based on an operation by the first user; or
A condition regarding a relationship between the second user and a party capable of automatically transmitting an application for association to the second user within the predetermined service as a condition regarding reception of the application automatically transmitted from the first user to the second user, based on an operation by the second user.
program. The setting means is
Setting conditions regarding a relationship between the first user and a party to which an application for association is automatically sent within the predetermined service based on an operation by the first user to specify conditions for a user with whom the first user wishes to be associated ; or
The second user is capable of at least one of setting conditions regarding a relationship within the predetermined service between the second user and a party capable of automatically transmitting an application for association to the second user based on an operation by the second user to specify conditions of a user with whom the second user wishes to associate.
The program according to claim 1. The setting means is
Setting conditions regarding a relationship between the first user and a party to which an application for association is automatically sent within the specified service based on an operation by the first user to specify conditions for a user with whom the first user does not want to be associated ; or
The second user is capable of at least one of setting conditions regarding a relationship within the predetermined service between the second user and a party capable of automatically transmitting an application for association to the second user based on an operation by the second user to specify conditions of a user with whom the second user does not want to be associated.
The program according to claim 1. an application means for automatically making an application for associating a first user with a second user who has decided to share a predetermined experience with a first user in a predetermined service, the second user being shared with the second user, or the second user having shared the experience with the first user;
an association means for associating the second user with the first user based on an operation by the second user to approve the application;
a setting means for setting a condition related to the transmission or reception of the application based on an operation of the first user or the second user;
The setting means is
Setting a condition regarding a relationship between the first user and a party to which an association request is automatically sent in the predetermined service as a condition for automatically sending the request from the first user to the second user based on an operation by the first user; or
A condition regarding a relationship between the second user and a party capable of automatically transmitting an application for association to the second user within the predetermined service as a condition regarding reception of the application automatically transmitted from the first user to the second user, based on an operation by the second user.
Information processing system.

Images