JP2006279814A - Communication system, server, program and communication method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a communication system with which a user can easily search for a party easy to apply for communication. <P>SOLUTION: If a communication terminal 1 communicates with another communication terminal, the communication terminal 1 receives a user ID from the communication terminal and creates a communicator list 52 including that user ID. When the communication terminal connects to a server, the communicator list is transmitted to the server together with the user ID. The server stores the communicator list and the user ID received from the communication terminal in association with each other, on the other hand, collects the user ID on the communicator list and user IDs on other communicator lists related to the user ID on the communicator list to create a candidate list 60 and sends it to the communication terminal. If any user ID is selected out of the candidate list, the communication terminal communicates with another communication terminal using the user ID via the server. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to communication between communication terminals via a server, such as a network game or online chat.

  2. Description of the Related Art Conventionally, portable game machines that can play a battle game by connecting to each other via a communication cable or the like are known. Recently, a portable game machine having a short-range wireless communication function is also commercially available. By using this, a friend game can be easily enjoyed between friends. However, playing such a battle game tends to be the same opponent and is easily bored.

In recent years, with the spread of the Internet, network games that are played by a large number of users by communicating with each other's communication terminals (game machines, mobile phones, personal computers, etc.) via a common server have also spread. Yes. The network game has an advantage not found in the direct battle type game, in which an opponent can be searched from an unspecified number of users. However, there are not a few users who feel resistance to playing a game against a stranger. If such a user has a friend who fights by directly connecting each other's communication terminal without going through the server, even when the communication terminal is connected to the server, the user often contacts the friend first. . A network game information management system that reflects such friendship in the contents of a network game is disclosed (see Patent Document 1).
JP 2003-93745 A

  However, when the friend user is not connected to the server, the game cannot be played unless the user is still contacted by a stranger, and the threshold remains high. Such a problem may occur not only in an online game but also in any other system (for example, an online chat system or a file exchange system) in which communication terminals of an unspecified number of users communicate with each other via a server. In such a communication system, there is a need for a device that makes it easy for a user to apply for communication with a user other than a friend and expands the range of friendships.

  Accordingly, an object of the present invention is to provide a communication system, a server, a program, and a communication method that enable a user to easily find a partner who can easily apply for communication.

  In one aspect, the present invention provides a server, a first storage device accessible by the server, and a plurality of communication terminals connected to the server via a communication network and capable of communicating with each other via the server. A communication system comprising: When one communication terminal connects to the server, the server transmits a candidate list including one or more user IDs to the one communication terminal, and the one communication terminal specifies a user ID in the candidate list. When an input is received, it communicates with another communication terminal using the designated user ID via the server. Each of the communication terminals has a second storage device. When communicating with another communication terminal, the communication terminal receives a user ID from the other communication terminal, creates a communication person list including the user ID, 2 storage device. An example of the communication list is a friend list in the following embodiment. Each of the communication terminals, when connected to the server, reads the communication person list from the second storage device and transmits it to the server together with the user ID used by the communication terminal. When the server receives one communicator list and one user ID from one communication terminal, the server associates the one communicator list with the one user ID and stores it in the first storage device. A candidate list is created by collecting user IDs in the communication list and user IDs in other communication lists stored in the first storage device in association with the user ID in one communication list. .

  Since the user ID in the communication person list created by the communication terminal of the user who desires communication is the ID of the user who has communicated in the past, it is easy for the user to apply for communication. In addition, a user who uses a user ID in another communication list associated with a user ID in the communication list is a partner who can talk about having communicated with a common user, so it is compared with a user who has no connection at all. Thus, it is easy for a user who desires communication to apply for communication. Since a candidate list in which such user IDs are collected is provided to a communication terminal of a user who desires communication, the user can easily find a partner who can easily apply for communication. Thereby, the convenience of the user who uses a communication system increases.

  The server reads one user ID from one communicator list, determines whether or not a communication terminal that uses the one user ID is connected to the server, and determines that the communication terminal is connected. One user ID is selected as a candidate ID, the user IDs are sequentially read from other communication person lists associated with the one user ID and stored in the first storage device, and each read user ID is used. It is determined whether or not the communication terminal to be connected is connected to the server. When it is determined that the communication terminal is connected, the user ID is selected as a candidate ID, and the next user ID is read from the one communication person list. The candidate list may be created by collecting candidate IDs selected by repeating the process.

  In this configuration, only the ID of the user connecting the communication terminal to the server is registered in the candidate list, so that the user's time is wasted by providing the user with the offline user ID as the candidate ID. There is nothing.

  In the communicator list created by one communication terminal, each of the user IDs may be stored in association with the number of communications between the other communication terminal using the user ID and the one communication terminal. The server may read the user ID associated with a larger number of communication times from the one communication person list earlier.

  User IDs with a large number of communications and user IDs in a list of correspondents associated with such user IDs are preferentially selected as candidates, so that the selected candidate ID is actually communicated to the user. Is likely to represent a partner that is easy to apply for.

  Each of the communication terminals may be able to directly communicate with other communication terminals without going through a server. The number of communications may be the number of direct communications.

  Users who have performed direct communication without going through a server are actually familiar with each other, and are therefore considered to be in a relationship where it is easy to apply for communication. In the above configuration, since the candidate IDs are selected in the order in which the number of direct communication is emphasized, there is a higher possibility that the selected candidate ID represents a partner that is actually easy for the user to apply for communication.

  In the communicator list created by one communication terminal, each user ID in the communicator list is further associated with the latest communication date and time between the other communication terminal using the user ID and the one communication terminal. May be. The server may read the user ID associated with the newest latest communication date from the plurality of user IDs associated with the same communication count first from the one communicator list.

  If the number of times of communication is the same, a user who is communicating at a newer date and time is considered to be an easier partner to apply for communication. In the above configuration, since the new user ID with the latest communication date and time is preferentially selected as the candidate ID, the possibility that the selected candidate ID represents the other party who is actually easy to apply for communication is further increased. .

  The server may end the creation of the candidate list when the number of user IDs in the candidate list reaches a predetermined upper limit. By appropriately limiting the number of candidate IDs in the candidate list, it becomes easier to browse the candidate list, and the processing burden on both the server and the communication terminal is reduced.

  In the candidate list, the candidate IDs may be arranged in the order in which the candidate IDs are selected. By storing the candidate ID in the candidate list in the order in which the candidate IDs are selected, the storage capacity for temporarily storing the candidate ID can be suppressed, and the candidate list can be efficiently stored. Can be created. Further, since the order of arrangement of the candidate IDs directly represents the priority order of the candidate IDs, it is not necessary to prepare special data to express the priority order. Therefore, the storage capacity for storing the candidate list can be reduced.

  Each of the communication terminals may have a display device. When the communication terminal receives the candidate list from the server, the communication terminal reads the candidate IDs from the candidate list in the order in which the candidate IDs are arranged, and arranges the notation corresponding to the candidate IDs in the order in order on the display device. May be displayed. An example of the notation corresponding to the candidate ID is a user name corresponding to the candidate ID.

  In this configuration, since the candidate IDs are read in the arrangement order and the corresponding notations are displayed in the arrangement order, the storage capacity for temporarily storing the candidate IDs and the notation data can be reduced. Can be executed efficiently.

  The arrangement order of the notation corresponding to the candidate IDs may be arranged in any order. Thereby, even when the number of candidate IDs is large, a desired communication partner can be easily searched.

  In another aspect, the present invention relates to a server that is connected to a plurality of communication terminals via a communication network and can access a first storage device. The plurality of communication terminals can communicate with each other via the server. Each of the communication terminals has a second storage device. When communicating with another communication terminal, the communication terminal receives a user ID from the other communication terminal, creates a communication person list including the user ID, 2 storage device. Each of the communication terminals, when connected to the server, reads a communicator list from the second storage device, transmits it to the server together with the user ID used by the communication terminal, and includes one or more user IDs from the server. When the list is received and an input designating a user ID in the candidate list is received, communication is made with another communication terminal using the designated user ID via the server. When the server receives one communicator list and one user ID from one communication terminal, the server associates the one communicator list with the one user ID and stores the first communicator list in the first storage device; The candidate list is collected by collecting the user IDs in the other communication list and the user IDs in the other communication list stored in the first storage device in association with the user ID in the one communication list. Means for creating, and means for transmitting the candidate list to the one communication terminal.

  In still another aspect, the present invention relates to a program for controlling a server to which a plurality of communication terminals are connected via a communication network and can access a first storage device. The plurality of communication terminals can communicate with each other via a server. Each of the communication terminals has a second storage device. When communicating with another communication terminal, the communication terminal receives a user ID from the other communication terminal, creates a communication person list including the user ID, 2 storage device. Each of the communication terminals, when connected to the server, reads a communicator list from the second storage device, transmits it to the server together with the user ID used by the communication terminal, and includes one or more user IDs from the server. When the list is received and an input designating a user ID in the candidate list is received, communication is made with another communication terminal using the designated user ID via the server. When this program receives one communicator list and one user ID from one communication terminal, the one program associates the one communicator list with the one user ID and stores it in the first storage device. Candidate list by collecting user IDs in one communicator list and user IDs in other communicator lists stored in the first storage device in association with the user IDs in the one communicator list And a step of transmitting the candidate list to the one communication terminal.

  In yet another aspect, the present invention includes a server, a first storage device accessible by the server, and a plurality of communication terminals that include the second storage device and are connected to the server via a communication network. The present invention relates to a method of performing communication between a plurality of communication terminals in a communication system. In this communication method, when one communication terminal communicates with another communication terminal, a step of receiving a user ID from the other communication terminal, and a communicator list listing user IDs received from the other communication terminal And a user who uses the communication terminal to read the communicator list from the second storage device when the communication terminal is connected to the server via the communication network. Transmitting to the server together with the ID, and when the server receives one communicator list and one user ID from the one communication terminal, the first communicator list is associated with the one user ID in the first storage While storing in the device, the user ID in the one communicator list and other communication stored in the first storage device in association with the user ID in the one communicator list Collecting a user ID in the list and creating a candidate list; a server transmitting a candidate list including one or more user IDs to the one communication terminal; and the one communication terminal: Receiving an input designating a user ID in the candidate list, and communicating with another communication terminal using the designated user ID via a server.

  According to the present invention, it is possible to provide a communication system, a server, a program, and a communication method that enable a user to easily find a partner who can easily apply for communication, and to improve the convenience of the user who uses the communication system.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the description of the drawings, the same elements are denoted by the same reference numerals, and redundant description is omitted.

  Hereinafter, a network game system will be described as an embodiment of a communication system according to the present invention. FIG. 1 is a schematic diagram showing the configuration of the network game system 100. The network game system 100 includes a plurality of communication terminals 1, a communication network 2, and a server 3. Each of the communication terminals 1 can connect to the server 3 via the communication network 2 and communicate with other communication terminals via the server 3. In the network game system 100, a user who operates one communication terminal 1 can enjoy a battle play with a user who operates another communication terminal 1 using such communication.

  FIG. 2 is a schematic diagram for explaining a form of communication between the communication terminals 1. As shown in FIG. 2, the communication terminal 1 can communicate with other communication terminals 1 via the server 3 and can directly communicate with other communication terminals 1. This direct communication can be realized, for example, by connecting the communication terminals 1 with each other using a communication cable or by performing wireless communication between the communication terminals 1. Accordingly, a plurality of users can bring a communication terminal 1 and perform direct communication so that a battle can be performed without going through the server 3.

  The communication terminal 1 operates as a client of the server 3. Examples of the communication terminal 1 include a mobile phone, a personal computer having a communication function, a game machine, and a PDA (Personal Data Assistant). The communication terminal 1 may be a mobile terminal such as a mobile phone or a fixed terminal such as a desktop computer.

  FIG. 3 is a block diagram showing the configuration of the communication terminal 1. The communication terminal 1 includes a CPU (Central Processing Unit) 10, a RAM (Random Access Memory) 12, a storage unit 14, a communication unit 16, an input device 20, and a display device 22. These components are connected to each other by a bus 24. Data and control signals are transmitted between these components over bus 24.

  The CPU 10 is a control arithmetic device that controls the operation of the communication terminal 1 by executing a game program. The RAM 12 is a main storage device that is used by the CPU 10 to execute a game program. The RAM 12 stores a game program executed by the CPU 10 and data necessary for the execution.

  The storage unit 14 is an auxiliary storage device of the communication terminal 1 and includes an internal memory 14 a and a reading device 14 b for the external memory 15. The built-in memory 14a is a storage device fixed inside the communication terminal 1, and is, for example, a nonvolatile memory such as a flash memory or a hard disk drive. The built-in memory 14a stores user data 51, a friend list 52, and a battle history list 53. Details of these data will be described later.

  The reading device 14 b is a device for reading data from the external memory 15 that is detachable from the communication terminal 1. The external memory 15 is, for example, a CD-ROM, a DVD-ROM, other disk media, or various card type memories.

  In the present embodiment, the game program is stored in the built-in memory 14a. When the game program is executed, the game program is read into the RAM 12 from the built-in memory 14a. However, the game program may be stored in the external memory 15 and read into the RAM 12 by the reading device 14b.

  The communication unit 16 includes a communication interface 17 and an individual communication unit 18. The communication interface 17 is connected to the communication network 2 and controls communication between the communication terminal 1 and the server 3. The connection between the communication interface 17 and the communication network 2 may be wireless or wired. The individual communication unit 18 is connected to the individual communication unit 18 of another communication terminal 1 and controls direct communication between the communication terminals 1 without using the server 3. The connection between the individual communication units 18 may be a wireless method (for example, infrared communication, wireless LAN) or a wired method (for example, cable connection).

  The input device 20 is used for inputting commands and data to the communication terminal 1. The input device 20 may be a device directly operated by a user, such as a button, dial, keyboard, mouse, stylus, or may be a voice recognition device that discriminates a voice uttered by the user.

  The display device 22 displays various information under the control of the CPU 10. As will be described later, a list of battle candidates received from the server 3 is also displayed on the display device 22.

  The server 3 is a computer system that provides a network game service to the communication terminal 1 that is a client. The server 3 may be composed of a single computer or may be composed of a plurality of computers operating in cooperation with each other.

  FIG. 4 is a block diagram showing the configuration of the server 3. The server 3 includes a CPU 30, a RAM 32, a hard disk drive 34, a communication device 36, an input device 38, and a display device 40. These components are connected to each other by a bus 42. Data and control signals are transmitted between these components over bus 42.

  The CPU 30 is a control arithmetic device that controls the operation of the server 3 by executing a server program. The RAM 32 is a main storage device that is used by the CPU 30 to execute a server program. The RAM 32 stores a server program executed by the CPU 30 and data necessary for the execution.

  The hard disk drive 34 is an auxiliary storage device of the server 3. In addition to the server program, the hard disk drive 34 stores a user information database 54 and a friend squirrel database 55. Details of these databases (hereinafter “DB”) will be described later. When the server is started, a server program is read from the hard disk drive 34 into the RAM 32 and executed by the CPU 30.

  The communication device 36 controls communication between the communication network 2 and the server 3. The input device 38 is used to input commands and data to the server 3. The display device 40 displays various information under the control of the CPU 30.

  FIG. 5 is a schematic diagram showing a configuration of user data 51 stored in the built-in memory 14a of the communication terminal 1. The user data 51 includes information related to the user who operates the communication terminal 1, that is, “user ID”, “user name”, “registration date” and “latest match date”. These pieces of information are associated with each other. The user ID is a unique ID (Identification Data) assigned to the user who operates the communication terminal 1, and the user name is a name used by the user during game play. The registration date and time is the date and time when the user has issued a user ID from the server 3, and the latest battle date and time is the latest date and time when the user played against another user.

  FIG. 6 is a schematic diagram showing the configuration of the friend list 52 stored in the built-in memory 14a of the communication terminal 1. As shown in FIG. 6A, the friend list 52 includes a plurality of friend data 56 arranged in sequence. These friend data 56 are arranged from the top of the friend list 52 in descending order of priority. An upper limit is set for the number of friend data 56 that can be stored in the friend list 52. Hereinafter, this upper limit is represented by M (natural number).

  FIG. 6B schematically shows the configuration of friend data. In the present embodiment, an opponent user who has played in the past is regarded as a “friend”, and the ID of the opponent user and other information are collected to create friend data 56. As shown in FIG. 6B, the friend data 56 includes, as its data items, “user ID”, “user name”, “oldest match date”, “latest match date”, “direct match count”, It includes “direct battle win / loss”, “server battle count”, and “server battle win / loss”. These pieces of information are associated with each other. The user ID and the user name are the user ID and the user name of the opponent when a certain user operates the communication terminal 1 and battles with another user (that is, the opponent). The oldest match date and the latest match date are the oldest date and the newest date and time when both users played. The number of direct battles is the number of battles in which the communication terminals 1 of both users are directly connected without going through the server 3, and the direct battle win / loss is data indicating the winning / losing results of those battles. The number of server battles is the number of times that the communication terminals 1 of both users are connected to the server 3 and battles are performed, and the server battle win / loss is data indicating the results of the battles.

  In the friend list 52, the friend data 56 having a higher number of direct battles is arranged higher. This point will be described in detail later. In this specification, a user who uses the user ID in the friend data 56 registered in the friend list 52 may be described as “a user registered in the friend list 52”.

  FIG. 7 is a schematic diagram showing the configuration of the battle history list 53 stored in the built-in memory 14a of the communication terminal 1. As shown in FIG. 7A, the battle history list 53 includes a plurality of battle history data 57. Note that an upper limit may be set for the number of battle history data 57 in the battle history list 53.

  FIG. 7B schematically shows the structure of the battle history data 57. As shown in FIG. 7B, the battle history data 57 includes “user ID”, “win / loss”, and “match format” as its data items. These pieces of information are associated with each other. The user ID is the user ID of the opponent when the user operates the communication terminal 1 and battles with another user (that is, the opponent). The win / loss is data indicating the result of the battle, that is, either winning or losing. The battle format is data indicating either a direct battle in which the battle is performed by directly connecting the communication terminal 1 without going through the server 3 or a server battle in which the communication terminal 1 is connected to the server 3.

  When the communication terminal 1 is shared by a plurality of users, a plurality of user data 51, a friend list 52, and a battle history list 53 are stored in the built-in memory 14a. The user data 51, the friend list 52, and the battle history list 53 of each user are stored in association with the ID of the user. The user data 51, the friend list 52, and the battle history list 53 may be stored as one save data.

  Below, the process performed by the communication terminal 1 and the server 3 is demonstrated. FIG. 8 is a flowchart showing a game execution process on the communication terminal 1. This process is controlled by a game program that runs on the communication terminal 1. When the game program is executed, first, a screen for inquiring whether or not the user who plays the game uses a new user name is displayed on the display device 22 (step S802). When the user selects to use a new user name (Yes in step S802), a user information registration process is executed (step S804).

  FIG. 9 is a flowchart showing user information registration processing. This figure also shows the flow of processing executed by the server 3 in relation to this processing. This process is controlled by a server program that runs on the server.

  The communication terminal 1 displays a screen for prompting the user to input a user name and accepts the input of the user name (step S902). When the user operates the input device 20 to input a user name (step S904), the communication terminal 1 transmits an ID issue request to the server 3 together with the input user name (step S906). When the server 3 receives the ID issuance request and the user name (step S922), the server 3 issues a user ID unique to the user name and transmits it to the communication terminal 1 together with the date and time of issuance (step S924). The communication terminal 1 is specified when data is transmitted from the server 3 to the communication terminal 1 using the IP address included in the request transmitted from the communication terminal 1. This also applies to the following processing.

  The server 3 further associates the user name and user ID with each other and registers them in the user information database 54 in the hard disk drive 34 (step S926). FIG. 10 is a schematic diagram showing the configuration of the user information database 54. As shown in FIG. 10A, the user information database 54 is a database that accumulates user data 58. As shown in FIG. 10B, the user data 58 includes the same information as the user data 51 on the communication terminal 1 side described above. The server 3 creates user data 58 by associating the date and time when the user ID is issued together with the user ID and the user name, and stores the user data 58 in the user information database 54. Here, the ID issue date is stored as “registration date” in the user data 51. Here, the latest battle date and time in the user data 58 is blank. The server 3 can freely access user data 58 in the user information database 54.

  Note that the transmission of the user ID to the communication terminal 1 (step S904) and the registration to the user information database 54 (step S936) may be performed in reverse order or in parallel.

  Upon receiving the user ID from the server 3 (step S908), the communication terminal 1 creates the user data 51 by associating the user ID with the user name input in step S904 and the ID issuance date / time received from the server 3, Store in the built-in memory 14a (step S910). Here, the ID issuance date / time is stored as “registration date / time” in the user data 51, and the “latest match date / time” in the user data 51 is blank.

  Refer to FIG. 8 again. If the user selects not to use a new user name (No in step S802), communication terminal 1 reads registered user names from user data 51 in internal memory 14a and displays those user names on the screen. Then, the user is prompted to select a user name to be used in the subsequent game play (step S806). When the user operates the input device 20 to select a user name (step S808) or the user data registration process (step S804) is completed, the communication terminal 1 displays a title screen and waits for input of a command ( Step S810).

  On the title screen, buttons representing several play modes in which the user can play are displayed. These play modes include single play, direct battle and server battle. Single play is a mode in which a user plays a game alone. The direct battle and the server battle are play modes in which the users battle each other. Note that these battles may be performed with three or more users participating at the same time. An end button for instructing the end of the game program is also displayed on the title screen. The user can operate the input device 20 and click any button to instruct the communication terminal 1 to specify a play mode corresponding to the button or end the game program.

  When the end of the game program is instructed (Yes in step S812), the title screen is cleared and the game program ends. If the end of the game program is not instructed (No in step S812) and any play mode is specified (step S814), processing corresponding to the play mode is executed. Below, the process corresponding to each play mode is demonstrated sequentially.

  When the single play mode is designated in step S814, the communication terminal 1 executes a single game process (step S816). In this case, the communication terminal 1 executes the program for a single game stand-alone without performing communication with the other communication terminals 1.

  When the direct battle mode is designated in step S814, the communication terminal 1 executes a direct battle process (step S818). The direct battle mode is based on the premise that the communication terminal 1 has established a direct communication connection with another communication terminal 1 via the individual communication unit 18. Hereinafter, a user who operates one communication terminal 1 is simply referred to as a “user”, and a user who operates the other communication terminal 1 is referred to as a “competitor”.

  FIG. 11 is a flowchart showing the direct battle process. In this process, first, it is confirmed whether or not a communication connection between the communication terminals 1 has been established (step S1102). If the communication connection is not established, the communication terminal 1 displays the error message and then displays the title screen again. If the communication connection is established, the user name and the user ID are exchanged between the communication terminals 1 (step S1104). The communication terminal 1 reads the user name selected in step S808 or input in the user data registration process (S804) and the user ID associated with the user name from the user data 51, and sends it to the communication terminal 1 of the opponent. Send. A similar process is performed on the communication terminal side of the opponent. Thus, both communication terminals 1 exchange user names and user IDs. The user name and user ID received from the communication terminal 1 of the opponent are stored in the RAM 12, but may be saved in the built-in memory 14a as necessary.

  Next, the communication terminal 1 directly executes a battle game (step S1106). The communication terminal 1 acquires operation information (information on how the opponent operated the communication terminal 1) from the communication terminal 1 of the opponent, processes it in a predetermined method together with its own operation information, and directly Advance the battle game.

  When the direct battle game ends, the communication terminal 1 updates various information in the internal memory 14a, that is, the user data 51, the friend list 52, and the battle history list 53 (step S1108). FIG. 12 is a flowchart showing this information update processing. In this process, first, the user data 51 is updated (step S1201). Specifically, the latest battle date and time in the user data 51 is rewritten to the current battle date and time.

  Next, the communication terminal 1 registers the user data 51 of the opponent in the friend list 52 as necessary. Specifically, first, it is determined whether or not the user data 51 of the opponent is already registered in the friend list 52 (step S1202). The communication terminal 1 searches the friend list 52 for the user ID of the opponent received in step S1104, and determines that the user data of the opponent is not registered when the user ID is not found (in step S1202). No).

  In this case, the communication terminal 1 determines whether or not the number of registered users in the friend list 52 has reached the upper limit (step S1204). If the number of registered users has reached the upper limit (Yes in step S1204), the friend data with the lowest priority is deleted (step S1206). Subsequently, friend data 56 relating to the opponent is created (step S1208). Similarly, when it is determined that the number of registered users has not reached the upper limit (No in step S1204), friend data 56 is created. In the friend data 56, the user name and user ID of the opponent acquired in step S1104 are stored as data items “user ID” and “user name”. In addition, the date and time of this battle are stored in “oldest battle date and time” and “latest battle date and time”. “1” is stored in the “number of direct battles”. Further, “1” is stored in the “number of direct battles” if the user has won the current battle, and “0” is stored if the user has lost. “0” is stored in the “server battle count” and the “server battle win count”.

  On the other hand, when the opponent user ID received in step S1104 is found in the friend list 52, it is determined that the user data of the opponent is registered in the friend list 52 (No in step S1202). In this case, the communication terminal 1 reads the friend data 56 including the user ID received in step S1104 from the friend list 52 in the friend list 52, and updates the content (step S1210). Specifically, the “latest match date” is rewritten to the current match date, and the “direct match count” is incremented by one. In addition, if the user has won the current battle, the “number of direct battles” is also incremented by one.

  Subsequently, the communication terminal 1 updates the battle history list 53 (step S1212). The communication terminal 1 creates battle history data 57 related to the opponent and adds it to the battle history list 53. In the battle history data 57, the user ID of the opponent acquired in step S1104 is stored as a data item “user ID”. In addition, “win / lose” stores data indicating the current match result, and “match format” stores data indicating a direct match.

  Next, the communication terminal 1 rearranges, that is, sorts the friend data 56 in the friend list 52 in the descending order of the number of direct matches (step S1214). When there are a plurality of friend data 56 having the same number of direct battles, the friend data 56 having a larger number of server battles is arranged higher. Further, when there are a plurality of friend data 56 having the same number of direct battles and the same number of server battles, the friend data 56 with the newest battle date is arranged higher. In addition, when there are a plurality of friend data 56 having the same number of direct battles, the ranking may be determined by giving priority to the latest battle date and time rather than the number of server battles. In this case, among the friend data 56 having the same number of direct matches, the friend data 56 having the newest match date and time is arranged higher, and the friend data 56 having the same direct match count and the latest match date and time has a larger number of server matches. The friend data 56 is arranged higher.

  As other sorting methods, the following methods can be considered. That is, the communication terminal 1 first refers to the battle history list 53, and arranges the friend data 56 including the user ID having a large number of direct battles in the latest predetermined number (for example, 50) of battles higher in the friend list 52. Then, sorting is performed by the above method. According to this method, the latest battle situation can be more easily reflected in the priority order (arrangement order) of the friend data 56.

  Refer to FIG. 11 again. When the update of the user data 51, the friend list 52, and the battle history list 53 is completed, the communication terminal 1 displays a screen for inquiring whether or not to play the game again for the user (step S1110). When the user operates the input device 20 and instructs to play again, the processes after step S1102 are executed again. On the other hand, when the user inputs an instruction to refuse to play again to the communication terminal 1, a title screen is displayed (step S810).

  Next, processing related to server battle will be described. When the server battle mode is designated in step S814, the communication terminal 1 executes server battle processing (step S820). FIG. 13 is a flowchart showing the server battle process. This figure also shows a flow of processing executed by the server 3 in connection with server battle processing at the communication terminal 1. This process is controlled by the server program.

  The communication terminal 1 first connects to the server 3 via the communication network 2 and transmits a battle request to the server 3 (step S1302). This battle request is accompanied by a user ID and a friend list 52. The communication terminal 1 reads the friend list 52 associated with the currently used user ID from the built-in memory 14a and transmits it to the server 3 together with the user ID and the battle request. Hereinafter, the fact that the user connects the communication terminal 1 to the server 3 may be conventionally expressed as “the user is connected to the server 3” or the like.

  When the server 3 receives the battle request, the user ID, and the friend list 52 from the communication terminal 1 (step S1322), the server 3 updates the friend list database 55 in the hard disk drive 34 (step S1324). FIG. 14 schematically shows the configuration of the friend list database 55. The friend list database 55 stores a friend list 52 transmitted from various communication terminals 1. The friend list 52 is stored in the friend list database 55 in association with the user ID transmitted together from the communication terminal 1.

  When the server 3 receives the user ID and the friend list 52 together with the battle request from the communication terminal 1, the server 3 searches the friend list database 55 for the friend list 52 associated with the user ID. When the friend list 52 is not found, the friend list 52 transmitted from the communication terminal 1 is stored in the friend list database 55. On the other hand, when the friend list 52 is found, the contents of the friend list 52 are matched with the contents of the friend list 52 transmitted from the communication terminal 1. This may be executed by overwriting the friend list 52 in the friend list database 55 with the friend list 52 transmitted from the communication terminal 1. As described above, the friend list 52 in the friend list database 55 is synchronized with the friend list 52 on the communication terminal 1 side when the communication terminal 1 is connected to the server 3.

  Subsequently, the server 3 creates a candidate list to be provided to the communication terminal 1 that has issued the battle request (step S1326). As will be described later, the server 3 selects a battle candidate from the users connected to the server 3 based on a predetermined standard, creates a candidate list listing information on the battle candidates, and requests a battle Is provided to the communication terminal 1 that issued.

  Hereinafter, the user who selects the server battle mode and connects the communication terminal 1 to the server 3 is represented as “user A”, and the communication terminal 1 used by the user A is represented by reference numeral 1A. As described above, in this embodiment, a user who has a large number of battles with the user A is regarded as a “friend” of the user A. In the following, this “friend” user is represented by the symbol FA. If there is a user who has a large number of battles in addition to the user A, the friend user FA corresponds to the “friend” of the “friend” as viewed from the user A. In the following, this “friend of a friend” user is represented by the symbol FFA.

  FIG. 15 schematically shows the configuration of the candidate list. As shown in FIG. 15A, the candidate list 60 includes candidate data 61 arranged in sequence. FIG. 15B schematically shows the configuration of the candidate data 61. The “user ID” and “user name” in the candidate data 61 indicate the user ID and user name of the user selected as a battle candidate by the server 3. Further, “friend ID” and “friend name” in the candidate data 61 indicate who “friend” the candidate for the match is. That is, if the battle candidate is the friend user FFA of the friend user FA, the user ID and user name of the friend user FA are stored in “friend ID” and “friend name”. When the battle candidate is a friend user FA, a value (“0” in the present embodiment) indicating that the friend is himself is stored in “friend ID”, and “friend name” is blank. Further, when the battle candidate is a general user who is neither a friend user nor a friend friend user, both “friend ID” and “friend name” are blank.

  There is an upper limit on the number of candidate data registered in the candidate list 60. Hereinafter, this upper limit is represented by N (natural number). When the total number of users connected to the server 3 exceeds the upper limit N, only some users are selected as candidates. In the candidate list, candidate data with higher priority is arranged higher. One of the features of this embodiment is an algorithm for determining this priority order. That is, the server 3 selects the above-mentioned friend user and friend friend user as candidates with priority over other general users.

  Hereinafter, the candidate list creation process will be specifically described with reference to FIG. FIG. 16 is a flowchart showing candidate list creation processing. The candidate list 60 is created in the RAM 32 of the server 3, but may be saved in the hard disk drive 34 as necessary.

  First, the server 3 sets 0 as an initial value to a variable “candidate count” representing the number of selected candidates (step S1602). This “candidate count” is used to determine whether or not the number of candidate data 61 listed in the candidate list 60 has reached the upper limit N.

Next, the server 3 reads the friend list 52 associated with the user ID (user A's ID) transmitted from the communication terminal 1A together with the battle request from the friend list database 55 into the RAM 32 (step S1604). In the following, the friend list 52 of the user A is denoted by reference numeral 52 _FL , and the friend list 52 of the friend user FA registered in the friend list 52 _FL is denoted by reference numeral 52 _FFL, which are distinguished from each other. Also, the friend data registered in the m-th place (m is a natural number) of the friend list 52 _FL is represented by reference numeral 56 _m , and the friend user who uses the user ID in the friend data 56 _m is represented by reference sign FA _m .

If the friend user FA ₁ registered at the top of the friend list 52 _FL currently connects the communication terminal 1 to the server 3, the server 3 selects the friend user FA ₁ as a candidate. To be more specific, the server 3 first, the first pointer P1 is created in RAM 32, it sets the storage position of the uppermost friends data 56 ₁ in the Friends list 52 to the pointer P1 (step S1606). This pointer P1 is used to read the friend data 56 in the friend list 52 _FL in order from the top.

Next, the server 3 reads the user ID (that is, the ID of the friend user FA ₁ ) from the friend data 56 (currently the highest friend data 56 ₁ ) stored at the position indicated by the pointer P1 (step S1608). . Then, the server 3 searches for the communication terminal 1 connected to the server 3 using the read user ID (step S1610). When such a communication terminal 1 is not found (No in step S1610), the process of step S1618 described later is executed. On the other hand, when such a communication terminal 1 is found (Yes in step S1610), the server 3 stores the friend data 56 stored at the position indicated by the pointer P1 (currently, the highest friend data 56 ₁ ). The candidate data 61 storing the user ID and the user name is created, and the candidate list 60 having the candidate data 61 at the top is created (step S1612). A value “0” indicating that the candidate is a friend user is set in the “friend ID” in the candidate data 61.

Thereafter, the server 3 increments the “candidate count” by 1 to indicate that the number of selected candidates has increased by one (step S1614). Subsequently, the server 3 compares the “candidate count” with the upper limit N, and determines whether or not the number of selected candidates has reached the upper limit N (step S1616). When the “candidate count” is equal to N (Yes in step S1616), it is determined that the number of selected candidates has reached the upper limit N, and the creation of the candidate list is terminated. On the other hand, if “candidate count” is not equal to N (No in step S1616), server 3 determines that the number of selected candidates has not reached the upper limit N. In this case, the server 3, the candidate has been (now, friend user FA ₁₎ friend user determines whether to select within user by the above process with reference to the buddy list 52 _FFL of listed their friends list 52 _FFL A process of selecting a candidate from the user who has been, that is, the friend user FFA of the friend is executed (step S1618).

FIG. 17 is a flowchart showing the “friends of friends” selection process. The server 3 reads the friend list 52 _FFL associated with the ID of the friend user FA (currently the friend user FA ₁ ) acquired in step S1608 from the friend list database 55 into the RAM 32 (step S1702). Below, the friend data registered in the nth place (n is a natural number) of the friend list 52 _FFL of friends is represented as “friend friend data 56 _FFLn ”, and the user ID in the friend friend data 56 _FFLn The friend user of the friend to be used is represented by the symbol FFA _n .

If the server 3 is a user registered at the top of the friend list 52 _FFL , that is, if the friend user FFA ₁ of the friend currently connects the communication terminal 1 to the server 3, the friend friend user FFA ₁ Is selected as a candidate. More specifically, the server 3 first creates the second pointer P2 in the RAM 32, and stores the storage position of the friend friend data 56 _FFL1 arranged at the top in the friend friend list 52 _FFL as the pointer P2. (Step S1704). This pointer P2 is used to read the friend data 56 of the friends in the friend list 52 _FFL in order from the top.

Next, the server 3 _{reads the} user ID (that is, the ID of the friend friend user FFA ₁ ) from the friend data 56 of the friend stored at the position indicated by the pointer P2 (currently, the highest friend data 56 _FFL1 ). (Step S1706). Then, the server 3 searches for the communication terminal 1 connected to the server 3 using the read user ID (step S1708). When such a communication terminal is not found (No in step S1708), the processing after step S1722 described later is executed. On the other hand, when such a communication terminal 1 is found (Yes in step S1708), the server 3 stores the friend data 56 of the friend stored at the position indicated by the pointer P2 (currently, the friend of the top friend). The candidate data 61 including the user ID and the user name in the data 56 _FFL1 ) is created, and the candidate data 61 is registered in the candidate list 60 (step S1710). At this stage, “friend ID” and “friend name” in the candidate data 61 are blank. When other candidate data 61 is already registered in the candidate list 60, the new candidate data 61 is arranged in the next rank after the existing lowest candidate data 61.

Next, the server 3 checks whether or not the user ID in the registered candidate data 61, that is, the ID of the friend user FFA of the friend exists in the friend list 52 of the user A (step S1712). If the ID of the friend user FFA of the friend exists in the friend list 52 of the user A (Yes in step S1712), the user FFA is the “friend of friend” of the user A and at the same time the “friend of user A It ’s also. In this case, a value “0” indicating that the candidate is a friend user is set in the “friend ID” of the candidate data 61 registered in step S1710 (step S1714). On the other hand, if the ID of the friend user FFA of the friend does not exist in the friend list 52A (No in step S1712), the friend user FA (currently, The user ID and user name of friend user FA ₁ ) are set (step S1716).

Thereafter, the server 3 increments the “candidate count” by 1 to indicate that the number of selected candidates has increased by one (step S1718). Subsequently, the server 3 compares the “candidate count” with the upper limit N, and determines whether or not the number of selected candidates has reached the upper limit N (step S1720). When the “candidate count” is equal to N (Yes in step S1720), the server 3 determines that the number of selected candidates has reached the upper limit N, and the creation of the candidate list is terminated. On the other hand, if “candidate count” is not equal to N (No in step S1720), server 3 determines that the number of selected candidates has not reached the upper limit N. In this case, the server 3 determines whether or not the processing from step S1706 has been executed on the friend data 56 of all the friends registered in the friend list 52 _FFL of the friend (step S1722). If the friend data 56 of the unprocessed friend remains in the friend friend list 52 _FFL (No in step S1722), the server 3 determines the next rank (here, the second rank) in the friend friend list 52 _FFL. ) Is stored in the pointer P2 (step S1724). Thereafter, the processing after step S1706 is executed again.

On the other hand, when there is no friend data 56 of the unprocessed friend in the friend list 52 _FFL of the friend (Yes in step S1722), the server 3 adds all the friend data 56 registered in the friend list 52 _FL. Then, it is determined whether or not the processing after step S1608 has been executed (step S1726). If unprocessed friend data 56 remains in friend list 52 _FL (No in step S1726), server 3 sets the storage position of friend data 56 of the next rank in friend list 52 _FL in pointer P1. (Step S1728). Thereafter, the processing after step S1608 is executed again.

  As described above, when the number of selected candidates reaches the upper limit N while selecting candidates from the users registered in the friend list and the friend list of friends according to the above procedure, the creation of the candidate list ends there. To do. However, the selection for all of these users may be completed, and the number of selected candidates may not reach the upper limit N. In this case, the server 3 selects other general users connecting the communication terminal 1 to the server 3 as candidates until the number of candidates reaches the upper limit N, creates candidate data 61, and creates a candidate list. 60 (step S1730). “Friend ID” and “friend name” in the candidate data 61 of the general user are both left blank. An algorithm for selecting candidates from general users is arbitrary.

  Refer to FIG. 13 again. The server 3 transmits the candidate list 60 created in step S1326 to the communication terminal 1A (step S1328). The communication terminal 1A receives the candidate list 60 from the server 3, reads the user name from the candidate data 61 listed in the list 60, and displays it on the display device 22 (step S1304).

  FIG. 18 shows an example of a candidate list screen showing these user names as battle candidates. In the “nickname” column 71, user names in the candidate list 60 received from the server 3 are displayed as a scrollable list. The user can scroll the user names listed in the “nickname” column 71 up and down by operating the input device 20 and moving the cursor 75. In this case, the display of “who's friend?”, “Last match date / time / match format” and “friendship degree” which will be described later is also scrolled together with the user name. The user can perform an input designating the user name by moving the cursor 75 to one of the user names and operating the input device 20 by a predetermined method (for example, pressing a predetermined button).

  In the “who's friend?” Column 72, “friend name” associated with the user name in the candidate list 60 in order to indicate which user's “friend” the user name in the “nickname” column 71 is. Is displayed. If this “friend name” is blank and the corresponding “friend ID” is “0”, the user name in the “nickname” column 71 corresponds to “friend” of user A himself, so “?” Is displayed in the “?” Column 72. When both “friend name” and “friend ID” are blank, the user name in the “nickname” column 71 is neither “friend” nor “friend of friend” of the user A. “---” is displayed in the “who's friend?” Column 72.

  In the “last match date / time / match format” column 73, if a user who uses these user names has been played in the past, the latest match date / time and match format are displayed. The battle type “real” means a direct battle, and “online” means a server battle.

  In the “friendship degree” column 74, “friendship degree” indicating whether the battle candidate is a friend user, a friend user of a friend, or another general user is displayed as symbols S, A, B, and C. Is done. The “friendship degree” indicates a high familiarity in the order of S, A, B, and C. Specifically, “S” and “A” indicate friend users. The difference between “S” and “A” is the presence or absence of direct competition experience. That is, S indicates a friend user who has a direct battle experience in the past, and A indicates a friend user who has only a server battle experience. B indicates a friend user of a friend, and “C” indicates another general user.

  If the friend ID in candidate data 61 is “0”, communication terminal 1A sets “degree of friendship” to “S” or “A”. In this case, the communication terminal 1 </ b> A reads the user ID in the candidate data 61 and searches for the friend data 56 including the user ID in the friend list 52. Then, the communication terminal 1A refers to the number of direct battles in the searched friend data 56 to determine whether the “friendship degree” of the friend user corresponds to “S” or “A”. Thus, in this embodiment, a friend user who has a direct battle experience is displayed as a more intimate user. If the “friend ID” in the candidate data 61 is neither “0” nor blank, the communication terminal 1A determines that the “user name” in the candidate data 61 is a friend user of the friend, and the friendship degree “B”. Assign and display. When the “friend ID” in the candidate data 61 is blank, the communication terminal 1 determines that the “user name” in the candidate data 61 is the name of a general user and assigns and displays the friendship degree “C”. To do.

The communication terminal 1 reads the candidate data 61 of the candidate list 60 in order from the top of the list according to the arrangement order (priority order), and the candidate list includes the candidate user names included in the candidate data 61 in the same order. Display on the screen. Therefore, if the friend user FA ₁ located at the top of the friend list 52 _FL is connected to the server 3, the user name is displayed at the top of the screen. Below the user name of a friend user FA _1, users are connected to the server 3 of the friend user FFA of friend user FA ₁ is displayed. Below the friend friend user name of the user FA _1, friend user FA ₂ located in the second position of the friend list 52 _FL is if the connection to the server 3, the user name is displayed. The names of other general users are displayed under the names of the friend user FA and the friend user FFA of the friend.

  The candidate user names displayed in the “nickname” column 71 on the candidate list screen are “who are friends?” Column 72, “last match date / time / match format” column 73, and “friendship degree” column 74. Items can be sorted by key. For example, the character string “who friends?” Arranged on the “who friends?” Column 72 is clickable, and when the cursor 75 is clicked with the cursor 75, the users in the “who friends?” Column 72 are clicked. The names are rearranged in a predetermined order, and the notations in other fields are rearranged accordingly. By performing the same operation for the other fields 73 and 74, the candidate user names can be sorted based on the “last battle date / time / match format” or “friendship degree”. Since such sorting is possible, even when there are many candidate user names, it becomes possible to easily search for a desired opponent.

  Refer to FIG. 13 again. When the user operates the input device 20 and designates one of the user names on the screen as a battle candidate (step S1306), the communication terminal 1A sets the user ID of the battle candidate (user B) as candidate data. It is read from 61 and transmitted to the server 3 together with the battle application request and the ID of the user A (step S1308). Upon receiving the battle application request (step S1330), the server 3 transmits a battle application notification to the communication terminal 1B connected to the server 3 using the user ID of the battle applicant received together with the battle application request (step S1332). ). The battle application notification includes the user ID and user name of the user A used in the communication terminal 1A applying for the battle, in addition to the code indicating the battle application.

  The communication terminal 1B executes a battle request response process in response to a battle application notification from the server 3 (step S1334). FIG. 19 is a flowchart showing a battle desired response process. When receiving a battle application notification from the server 3 (step S1902), the communication terminal 1B displays a screen for inquiring whether or not to accept the battle on the display device 22 (step S1904). On this screen, the user ID and user name of the user A who has applied for the match are displayed. When user B inputs a battle acceptance command to communication terminal 1B (Yes in step S1906), communication terminal 1B transmits a notice of acceptance to server 3 (step S1908). On the other hand, when user B inputs a battle rejection command to communication terminal 1B (No in step S1906), communication terminal 1B transmits a rejection notification to server 3 (step S1910).

  Refer to FIG. 13 again. The server 3 receives either the acceptance notification or the rejection notification from the communication terminal 1B, and transfers the notification to the communication terminal 1A (step S1335). When receiving the notification (step S1310), the communication terminal 1A confirms the content of the notification and determines whether or not the match has been accepted (step S1312). If the notification includes a code indicating a battle rejection, the communication terminal 1A determines that the battle is rejected (No in step S1312), and displays a message indicating the battle rejection on the screen (step S1313). Thereafter, the communication terminal 1 </ b> A executes the processes after step S <b> 1302 again.

  On the other hand, if the notification includes a code representing the match, the communication terminal 1A determines that the match has been accepted (Yes in step S1312), and plays the server battle game with the communication terminal 1B via the server 3. It executes (step S1314). The server 3 also confirms the content of the notification from the communication terminal 1B (step S1336), and when the battle is accepted, performs processing for executing the server battle (step S1338). Further, the server battle game is also executed in the communication terminal 1B in the same manner as the communication terminal 1A. The communication terminal 1A acquires operation information (information regarding how the user B operated the communication terminal 1B) from the communication terminal 1B via the server 3, and uses a predetermined method together with the operation information of the communication terminal 1A. Process and advance the server battle game. Similarly, the communication terminal 1B acquires operation information from the communication terminal 1A via the server 3, processes the information together with the operation information of the communication terminal 1B by a predetermined method, and advances the server battle game.

  When the server battle game ends, the communication terminals 1A and 1B update various information in the internal memory 14a, that is, the user data 51, the friend list 52, and the battle history list 53 according to the result of the server battle (step S1316). ). This procedure is the same as that described with reference to FIG. However, this time, “server battle count” and “server battle win count” are updated instead of “direct battle count” and “direct battle win count”. The server 3 also updates various information in the hard disk drive 34, that is, the user data 58 in the user information database 54 and the friend list 52 in the friend list database 55 according to the result of the server battle (step S1340). .

  When the information update process is completed, the communication terminals 1A and 1B display a screen for inquiring whether or not to play the game again to the user (step S1318). When the user operates the input device 20 and instructs to play again, the processes after step S1302 are executed again. When the user refuses to play again, a title screen is displayed (step S810).

  Below, the advantage of this embodiment is demonstrated. As described above, in this embodiment, the server 3 is a “friend user” registered in the friend list of the user who wants to play a server match, and the “friend user of a friend” registered in the friend list of the “friend user”. Is preferentially selected as a battle candidate, and the information of the battle candidate is provided to the user's communication terminal 1. The “friend user” registered in the user's friend list is a person who has experienced a battle with the user in the past, and in many cases, it should be easy to apply for a battle. In addition, “friend user of friend” registered in the friend list of “friend user” also has a common point that it has played against a common “friend user” and can talk about it, so compared to other users Easy to apply for a match. Therefore, in the network game system 100 according to the present embodiment, the user can easily find a partner to which the user can apply for the battle, and the convenience for the user is high.

  In addition, considering that there is a high possibility that users who are playing many matches are friends, the present system 100 that preferentially selects users who have a large number of battles as candidates, makes it easy for users to apply for matches. Can be selected reliably.

  In particular, since the system 100 preferentially selects a user who has a large number of direct battles as candidates, it is possible to further increase the possibility that the candidate is an opponent who is actually easy to apply for a battle for the user. Users who have played a direct battle are acquainted with reality and have a high probability of being friends. Therefore, it is considered that these users have a relationship that makes it easy to apply for a battle. By preferentially selecting such a user as a candidate, the user's friendship can be easily reflected in the candidate list. As a result, the user can easily face a friendly partner and can play a more interesting game.

  In this system 100, if the number of battles is the same, a new user with the latest communication date and time is preferentially selected as a candidate. Thereby, it is possible to further increase the possibility that the selected candidate is an opponent who is actually easy to apply for a match for the user. This is because it is considered that users who are fighting at a newer date and time are more likely to remember each other and it is easier to apply for a fight.

  Further, in the present system 100, only the ID of the user connecting the communication terminal 1 to the server 3 is registered in the candidate list 60, so that an offline user is selected as a candidate and the user is wasted time. There is nothing wrong.

  The server 3 ends the creation of the candidate list 60 when the number of candidate data in the candidate list 60 reaches the upper limit. Since it is not necessary to list all users connected to the server 3 in the candidate list, the processing load on the server 3 can be reduced. Moreover, since the data size of the candidate list 60 is reduced, the processing load on the communication terminal 1 that displays the candidate user name based on the candidate list 60 is also reduced. Further, there is an advantage that the candidate list screen displayed on the communication terminal 1 can be easily browsed.

  The system 100 can reduce the storage capacity for temporarily storing the candidate data 61 by storing the candidate data 61 in the candidate list 60 in the order in which the candidate IDs are selected. In addition, the candidate list 60 can be efficiently created. Further, since the order of arrangement of the candidate data 61 represents the priority order of the candidate data 61 as it is, it is not necessary to prepare special data to express the priority order. Therefore, the storage capacity for storing the candidate list 61 can be reduced.

  In the present system 100, the candidate data 61 is read in the arrangement order, and the user names in the candidate data 61 are displayed in the arrangement order of the candidate data 61. For this reason, the storage capacity for temporarily storing the candidate data 61 can be reduced, and the process for displaying the candidate list screen can be efficiently executed.

  On the candidate list screen, candidates with a higher number of battles are displayed higher and can be viewed without the need for scrolling, so that the user can easily find a candidate who can easily apply for a battle. Further, even if the “friend user” is not connected to the server 3, the “friend friend user” can be selected as a candidate, so that the disadvantage that the number of selection candidates is small is unlikely to occur.

  The present invention has been described in detail based on the embodiments. However, the present invention is not limited to the above embodiment. The present invention can be variously modified without departing from the gist thereof. For example, in the above embodiment, the user information DB 54 and the friend list DB 55 are stored in the hard disk drive 34 in the server 3, but these DBs may be stored in separate database servers accessible by the server 3. Good.

  In the above embodiment, the friend list 52 is first sorted based on the number of direct matches, but the friend list 52 may be sorted based on the total number of matches, that is, the total of the number of direct matches and the number of server matches. With respect to a plurality of friend data 56 having the same total number of matches, the friend data 56 with the newest match date may be arranged higher, or the friend data 56 having a larger number of direct matches may be arranged higher. With respect to the friend data 56 having the same total number of matches and the latest match date and time, the friend data 56 having a greater number of direct matches may be placed higher. Further, regarding the friend data 56 having the same total number of matches and the number of direct matches, the friend data 56 with the newest match date may be arranged higher.

  The above embodiment is an example in which the present invention is applied to a network game system. However, the present invention is not limited to such an example, and other arbitrary communication is performed between communication terminals via a server. The present invention can also be applied to other communication systems. Examples of such a communication system include an online chat system and a file exchange system.

  In the above embodiment, the communication unit 16 includes a communication device (communication interface 17) for connecting to the server and a communication device (individual communication unit 18) for connecting to another communication terminal 1. However, these communication devices may be replaced with a single communication device having both functions.

It is the schematic which shows the structure of a network game system. It is the schematic for demonstrating the form of communication between communication terminals. It is a block diagram which shows the structure of a communication terminal. It is a block diagram which shows the structure of a server. It is the schematic which shows the structure of the user data memorize | stored in the communication terminal. It is the schematic which shows the structure of the friend list memorize | stored in the communication terminal. It is the schematic which shows the structure of the battle history list memorize | stored in the communication terminal. It is a flowchart which shows the game execution process on a communication terminal. It is a flowchart which shows a user information registration process. It is the schematic which shows the structure of a user information database. It is a flowchart which shows a direct battle | competition process. It is a flowchart which shows an information update process. It is a flowchart which shows a server battle | competition process. It is a figure which shows roughly the structure of a friend list database. It is a figure which shows the structure of a candidate list | wrist roughly. It is a flowchart which shows a candidate list creation process. It is a flowchart which shows a "friend of friends" selection process. It is a figure which shows a candidate list screen. It is a flowchart which shows a battle | competition desired response process.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Communication terminal, 2 ... Communication network, 3 ... Server, 34 ... Hard disk drive, 51 ... User data, 52 ... Friend list (communication list), 53 ... Competition history list, 54 ... User information database, 55 ... Friend list Database 56 ... Friend data 57 ... Competition history data 58 ... User data 60 ... Candidate list 61 ... Candidate data 100 ... Network system.

Claims (17)

Server,
A first storage device accessible by the server;
A plurality of communication terminals connected to the server via a communication network and capable of communicating with each other via the server;
When one communication terminal connects to the server, the server transmits a candidate list including one or more user IDs to the one communication terminal, and the one communication terminal transmits the candidate list. A communication system that communicates with the other communication terminal using the specified user ID via the server when receiving an input specifying the user ID in
Each of the communication terminals has a second storage device. When communicating with another communication terminal, the communication terminal receives a user ID from the other communication terminal and creates a communicator list including the user ID. Stored in the second storage device and connected to the server, the communication list is read from the second storage device, and transmitted to the server together with the user ID used by the communication terminal,
When the server receives one communicator list and one user ID from one communication terminal, the server associates the one communicator list with the one user ID and stores it in the first storage device. On the other hand, a user ID in the one communication person list, and a user ID in the other communication person list stored in the first storage device in association with the user ID in the one communication person list, To create the candidate list,
Communications system. The server
Read one user ID from the one correspondent list,
Determining whether the communication terminal using the one user ID is connected to the server;
When it is determined that it is connected, the one user ID is selected as a candidate ID,
Sequentially reading the user ID from the other communication list stored in the first storage device in association with the one user ID;
Determine whether the communication terminal using each read user ID is connected to the server;
When it is determined that the user is connected, the user ID is selected as a candidate ID,
Read the next user ID from the one correspondent list,
The communication system according to claim 1, wherein the candidate list is created by collecting the candidate IDs selected by repeating the process. In the communicator list created by one communication terminal, each of the user IDs is stored in association with the number of communication between the other communication terminal using the user ID and the one communication terminal. ,
The server reads from the one communication person list earlier the user ID associated with a greater number of communication times,
The communication system according to claim 2.   4. The communication system according to claim 3, wherein each of the communication terminals can directly communicate with another communication terminal without going through the server, and the number of communication is the number of direct communication. . In the communicator list created by one communication terminal, each user ID in the communicator list is further updated to the latest communication date and time between the other communication terminal using the user ID and the one communication terminal. Associated with,
The server reads the user ID associated with the newest latest communication date and time from the plurality of user IDs associated with the same number of communications earlier from the one communication party list.
The communication system according to claim 3 or 4.   The communication system according to claim 2, wherein the server ends the creation of the candidate list when the number of user IDs in the candidate list reaches a predetermined upper limit.   The communication system according to any one of claims 2 to 6, wherein in the candidate list, the candidate IDs are arranged in an order in which the candidate IDs are selected. Each of the communication terminals has a display device,
When the communication terminal receives the candidate list from the server, the communication terminal reads the candidate ID from the candidate list in the order in which the candidate IDs are arranged, and displays the notation corresponding to the candidate ID in the order. Arranging and displaying on the display device,
The communication system according to claim 7. A server connected to a plurality of communication terminals via a communication network and capable of accessing the first storage device,
The plurality of communication terminals can communicate with each other via the server,
Each of the communication terminals has a second storage device. When communicating with another communication terminal, the communication terminal receives a user ID from the other communication terminal and creates a communicator list including the user ID. When the information is stored in the second storage device and connected to the server, the communicator list is read from the second storage device and transmitted to the server together with the user ID used by the communication terminal. Upon receiving the candidate list including the above user IDs and receiving an input designating the user ID in the candidate list, communication is performed with the other communication terminal using the designated user ID via the server. And
Means for receiving one communicator list and one user ID from one communication terminal, and storing the one communicator list in the first storage device in association with the one user ID;
Collecting user IDs in the one communicator list and user IDs in the other communicator list stored in the first storage device in association with the user IDs in the one communicator list Means for creating the candidate list;
Means for transmitting the candidate list to the one communication terminal;
A server comprising The means for creating the candidate list is:
Read one user ID from the one correspondent list,
Determining whether the communication terminal using the one user ID is connected to the server;
When it is determined that it is connected, the one user ID is selected as a candidate ID,
Sequentially reading the user ID from the other communication list stored in the first storage device in association with the one user ID;
Determine whether the communication terminal using each read user ID is connected to the server;
When it is determined that the user is connected, the user ID is selected as a candidate ID,
Read the next user ID from the one correspondent list,
The server according to claim 9, wherein the candidate list is created by collecting the candidate IDs selected by repeating the process. In the communicator list created by one communication terminal, each of the user IDs is stored in association with the number of communication between the other communication terminal using the user ID and the one communication terminal. ,
The means for creating the candidate list reads from the one correspondent list earlier as the user ID associated with a greater number of communications.
The server according to claim 10.   The server according to claim 11, wherein each of the communication terminals can directly communicate with another communication terminal without going through the server, and the number of communication is the number of direct communication. In the communicator list created by one communication terminal, each user ID in the communicator list is further updated to the latest communication date and time between the other communication terminal using the user ID and the one communication terminal. Associated with,
The means for creating the candidate list reads the user ID associated with the newest latest communication date / time from the plurality of user IDs associated with the same number of times of communication, from the one correspondent list first.
The server according to claim 11 or 12.   The means for creating the candidate list ends creation of the candidate list when the number of user IDs in the candidate list reaches a predetermined upper limit. server.   The server according to claim 10, wherein in the candidate list, the candidate IDs are arranged in the order in which the candidate IDs are selected. A program for controlling a server connected to a plurality of communication terminals via a communication network and capable of accessing the first storage device,
The plurality of communication terminals can communicate with each other via the server,
Each of the communication terminals has a second storage device. When communicating with another communication terminal, the communication terminal receives a user ID from the other communication terminal and creates a communicator list including the user ID. When the information is stored in the second storage device and connected to the server, the communicator list is read from the second storage device and transmitted to the server together with the user ID used by the communication terminal. Upon receiving the candidate list including the above user IDs and receiving an input designating the user ID in the candidate list, communication is performed with the other communication terminal using the designated user ID via the server. And
When receiving one communicator list and one user ID from one communication terminal, the one communicator list is stored in the first storage device in association with the one user ID, while Collecting user IDs in one communicator list and user IDs in other communicator lists stored in the first storage device in association with user IDs in the one communicator list Creating a candidate list;
Transmitting the candidate list to the one communication terminal;
That causes the server to execute Server,
A first storage device accessible by the server;
A plurality of communication terminals having a second storage device and connected to the server via a communication network;
In a communication system comprising: a method for performing communication between the plurality of communication terminals,
Receiving one user ID from the other communication terminal when the one communication terminal communicates with the other communication terminal;
Creating a correspondent list enumerating user IDs received from the other communication terminals and storing them in the second storage device;
When the communication terminal connects to the server via the communication network, reads the communicator list from the second storage device, and transmits it to the server together with a user ID used by the communication terminal;
When the server receives one communicator list and one user ID from one communication terminal, the server stores the one communicator list in the first storage device in association with the one user ID. On the other hand, a user ID in the one communication person list, and a user ID in the other communication person list stored in the first storage device in association with the user ID in the one communication person list, Collecting the candidate list to create a list of candidates,
A server transmitting a candidate list including one or more user IDs to the one communication terminal;
The one communication terminal receives an input designating a user ID in the candidate list and communicates with another communication terminal using the designated user ID via the server;
A communication method comprising:

Images