WO2007029603A1 - サーバ装置およびゲームシステム - Google Patents

サーバ装置およびゲームシステム Download PDF

Info

Publication number
WO2007029603A1
WO2007029603A1 PCT/JP2006/317276 JP2006317276W WO2007029603A1 WO 2007029603 A1 WO2007029603 A1 WO 2007029603A1 JP 2006317276 W JP2006317276 W JP 2006317276W WO 2007029603 A1 WO2007029603 A1 WO 2007029603A1
Authority
WO
WIPO (PCT)
Prior art keywords
identification information
player
public
play
information
Prior art date
Application number
PCT/JP2006/317276
Other languages
English (en)
French (fr)
Inventor
Kenji Kobayashi
Yukizumi Terao
Yukihiro Sato
Masaru Nakamura
Original Assignee
Konami Digital Entertainment Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Konami Digital Entertainment Co., Ltd. filed Critical Konami Digital Entertainment Co., Ltd.
Priority to EP06797236A priority Critical patent/EP1923109A4/en
Priority to US12/065,824 priority patent/US8409007B2/en
Priority to CN2006800325261A priority patent/CN101257954B/zh
Publication of WO2007029603A1 publication Critical patent/WO2007029603A1/ja
Priority to HK08112157.6A priority patent/HK1120456A1/xx

Links

Classifications

    • A63F13/12—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/406—Transmission via wireless network, e.g. pager or GSM
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/556—Player lists, e.g. online players, buddy list, black list
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/80—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game specially adapted for executing a specific type of game
    • A63F2300/8047—Music games

Definitions

  • the present invention relates to a server device and a game system.
  • JP 2005-118543 A discloses a system in which a plurality of game devices arranged in a store (game arcade) and a server device are connected via a network.
  • the server device collects data indicating the results obtained when the player plays the game, also by the game device power, generates ranking data, and publishes the ranking.
  • the mobile terminal accesses the server device and displays the ranking of the players.
  • notification can be automated.
  • the ranking of the ranking is disclosed to the public, so that all players who participate in the ranking will be able to choose, so it is not possible to choose an opponent who will be notified of the play status.
  • the notification can be automated.
  • the operation in an example of such a modification is as follows. A player One (the first player) notifies the other player (second player) who wants to know the player's play status of the player's identification information.
  • the second player registers the identification information in the server device in association with the self.
  • the server device transmits the data indicating the play status of the first player specified by the registered identification information to the mobile terminal of the second player associated with the registration of the identification information. Send to.
  • the player's mind may change as to whether or not the notification of the play status is possible. For example, a player may allow the above data transmission once and notify other players of his / her identification information, but later want to stop this data transmission.
  • One method for realizing this cancellation is to change the identification information. However, if the change is made simply, the identification information registered for the data transmission will also be changed and the data transmission will continue. End up.
  • the identification information of a player is used in various services provided by the system for the player and is associated with various data. This involves complicated work.
  • a method of receiving a request from a player who wishes to cancel and invalidating registration performed using the identification information of the player can be considered.
  • the identification information of one player is changed, other players whose registration is invalidated can perform registration using the identification information again.
  • the present invention has been made in view of the above-described problems, and in a system capable of notifying other users of information on contents according to a user operation of an operation device such as a game device, the user It is an object of the present invention to provide a server device and a game system that can easily realize the cancellation of notification.
  • a server device (3) is a server device (3) that communicates with each of a plurality of operation devices (1) that can be operated by a plurality of users.
  • a storage unit (33) having a personal data area (Tl, T2, T4) for storing written information and a human-related data area (T3) for storing written information;
  • Disclosure identification information for identifying each of the plurality of users, operation status information indicating the contents of the operation on one or more of the operation devices (1), identification information for disclosure of individual users, and A personal data writing unit (31, 31A, 31B) for writing operation status information in association with the personal data area (Tl, T2, T4);
  • a self-disclosure identification information transmission unit (31, 31A, 32) for transmitting information for
  • the human association data writing unit (31, 31C) is identified by the public identification information addressed to the second user and associated with the second user in the human association data area (T3).
  • the public identification information is changed to change the public identification information stored in the personal data area (Tl, T2, T4). Part (31, 31G).
  • the “operation device” is, for example, a game device that causes a player to play a game.
  • the “user” is, for example, a player who plays a game on the game device.
  • “write each user's public identification information and operation status information in the area” means focusing on a certain user and the public identification information of the user in association with the user. This means that the operation status information of the user is written in the area.
  • “write information to an area in association with a user” includes, for example, writing this information and identification information for identifying the user in association with each other, Includes writing information to an exclusive area assigned to this user in the area
  • this server device (3) when transmitting the operation status information of the first user to the second user, the public identification information of the first user in the human association data area is used. It is done. The public identification information is grasped by the first user, and the first user can inform the second user of his public identification information. On the other hand, what is changed in response to the request from the first user is the public identification information in the personal data area. Therefore, when the public identification information is changed in response to a request from the first user, the process of transmitting the operation status information of the first user to the second user can be stopped.
  • the user operation status information is stored in association with the user rather than the user identification information. Therefore, it is possible to construct a system so that other services will not be affected even if the user identification information is changed.
  • this server device (3) it is possible to easily realize that the user cancels the notification in a system capable of notifying other users of the operation status information of the user.
  • the public identification information may be generated by the server device (3) and written in the personal data area, or may be passed from the outside to the server apparatus (3) and written in the personal data area. May be. In the latter case, in the server device (3), it should be checked that there is no duplication of public identification information among a plurality of users, and then writing to the personal data area should be performed. In the latter case, the method of passing the public identification information is arbitrary. For example, the user may notify the operator of his / her public identification information by telephone, and the operator may input the public identification information to the server device (3).
  • Another server device (3) according to the present invention is a server device (3) that communicates with each of a plurality of game devices (1) that can be operated by a plurality of players, respectively.
  • a storage unit (33) having a personal data area (Tl, T2, T4) for storing written information and a human-related data area (T3) for storing written information;
  • Non-public identification information for identifying each of the plurality of players public identification information for identifying each of the plurality of players, and one or more of the game devices
  • a personal data writing unit (31) that writes play status information indicating the result of the play in (1) in the personal data area in association with each player's private identification information, public identification information, and play status information. , 31A, 31B)
  • a self-disclosure identification information transmission section (31, 31A. 32) for transmission;
  • the public identification information changing unit (31) When receiving a request for changing the public identification information from the player, the public identification information changing unit (31) changes the public identification information stored in the personal data area (Tl, T2, T4) for the player. , 31G).
  • the player cancels the notification in a system in which the player's play status information can be notified to other players for the same reason as described above for the server device (3). Can easily be realized.
  • An association clear unit (31, 31H) for deleting the public identification information from the human association data area (T3) may be provided. As a result, the process of transmitting play status information based on the changed old public identification information is not performed. In other words, useless processing can be reduced in the server device (3).
  • the game system includes a server device (3) that communicates with each of a plurality of game devices that can be operated by a plurality of players, and a plurality of terminal devices that communicate with the server device (4).
  • a game system comprising:
  • the server device (3) The server device (3)
  • a storage unit (33) having a personal data area (Tl, T2, T4) for storing written information and a human-related data area (T3) for storing written information;
  • Non-public identification information for identifying each of the plurality of players public identification information for identifying each of the plurality of players, and one or more of the game devices
  • the play status information indicating the result of play in (1) is associated with the individual data area (Tl, T2, T4) by associating each player's non-disclosure identification information, disclosure identification information and play status information.
  • the written public identification information is sent to the player identified by the written public identification information.
  • a self-disclosure identification information transmission section (31, 31A, 32) to be transmitted;
  • the identification information for public disclosure of the first player is received from the terminal device (4) used by the second player
  • the identification information for public disclosure of the first player is received as the private identification of the second player.
  • the terminal device used by the player When the terminal device used by the player receives a request for changing the public identification information, the public identification information stored in the personal data area (Tl, T2, T4) for the player is changed.
  • an identification information changing section (31, 31G) With an identification information changing section (31, 31G),
  • a friend public identification information input section (44) that allows a player to input another player's public identification information
  • a self-disclosure identification information change processing section (41) that transmits a request for changing the player's public identification information to the server device. , 41E).
  • the player's play status information can be notified to other players for the same reason as described above for the server device (3), and the player cancels the notification. Can be easily realized.
  • the public identification information and the play status information can be stored in an arbitrary area in the personal data area. Therefore, the degree of freedom of services that the game system can provide increases.
  • the play status information of the player is received by the terminal device (4) of the other player. Therefore, the other player can handle the play status information using the terminal device (4). Also, the player can change his / her public identification information using his / her terminal device (4).
  • Another game system includes a plurality of game devices (1) that can be operated by a plurality of players, and a server device (3) that communicates with each of the plurality of game devices (1).
  • a game system comprising:
  • the server device (3) The server device (3)
  • a storage unit having a personal data area (Tl, T2, T4) for storing written information and a human association data area (T3) for storing written information;
  • Play status information generation for generating player play status information based on the received play data each time the play data is received together with the medium identification information from one of the game devices (1).
  • the personal data writing unit (31, T4) that writes the medium identification information, the play status information of the player, and the public identification information for identifying the player in the personal data area (T1, T2, T4) in association with each other 31A, 31B)
  • the written public identification information is sent to the player identified by the written public identification information.
  • a self-disclosure identification information transmission section (31, 31A, 32) to be transmitted;
  • the received first player's public identification information is used as the medium identification information of the second player's information recording medium (2) or A human association data writing unit (3) for writing to the human association data area (T3) in association with the public identification information of the second player 1, 31G)
  • the medium identification information of the information recording medium (2) of the second player or the identification information for disclosure of the second player in the human association data area (T3) Friend play history transmission for transmitting information indicating play status information stored in the personal data area (Tl, T2, T4) for the first player identified by the public identification information associated with Part (31, 31E, 31F, 32),
  • the public identification information changing unit (31) When receiving a request for changing the public identification information from the player, the public identification information changing unit (31) changes the public identification information stored in the personal data area (Tl, T2, T4) for the player. , 31G).
  • the player's play status information can be notified to other players for the same reason as described above for the server device (3), and the player cancels the notification. Can be easily realized.
  • the public identification information and the play status information can be stored in an arbitrary area in the personal data area. Therefore, the degree of freedom of services that the game system can provide increases.
  • the game device reads the medium identification information from the player's information recording medium (2) and transmits it to the server device (3), and the server device (3) transmits the medium identification information. Received and used as the above-mentioned non-public identification information. Therefore, there is no need for the player to manually input private identification information.
  • the information recording medium (2) is one in which its own medium identification information is recorded so as to be difficult to rewrite, or one in which its own medium identification information is recorded with a method that is difficult to visually recognize. It can also be used. This is useful to prevent so-called “spoofing”.
  • An example of a recording method that is difficult to see with the naked eye is a magnetic recording method.
  • an apparatus having a server device and a terminal device is regarded as a game system.
  • an apparatus having a server device and a plurality of game devices may be used. As described above, it is a game system.
  • the server device has the same identification information for disclosure in the personal data area (Tl, T2, T4) changed by the disclosure identification information changing unit (31, 31G).
  • An association clear unit (31, 31H) for deleting the public identification information from the human association data area (T3) may be provided. As a result, it is possible to reduce unnecessary processing in the server device (3).
  • FIG. 1 is a block diagram showing a communication system provided with a game system according to a first embodiment of the present invention.
  • FIG. 2 is a perspective view showing an external appearance of game device 1 constituting the communication system of FIG.
  • FIG. 3 is a block diagram showing a configuration of the game apparatus 1.
  • FIG. 4 is a diagram showing an example of a game screen displayed in display area 151 of game device 1.
  • FIG. 5 is a block diagram showing a configuration of server device 3 of the communication system in FIG. 1.
  • FIG. 6 is a diagram showing an appearance of the mobile terminal 4 of the communication system of FIG.
  • FIG. 7 is a block diagram showing a configuration of the mobile terminal 4.
  • FIG. 8 is a diagram showing screen transition when the terminal program P is executed in the mobile terminal 4.
  • FIG. 9 is a diagram showing the functions of the communication system of FIG. 1, particularly the functions of the game system.
  • FIG. 10 is a diagram showing an overall operation flow in the usage example of the communication system of FIG. 1.
  • FIG. 11 is a diagram showing a flow of update reflection processing performed by the server device 3.
  • FIG. 12 is a diagram showing the flow of program processing performed in the mobile terminal 4 and the flow of initial processing performed in the server device 3 in accordance with the program processing in association with each other.
  • FIG. 13 is a diagram showing a flow of friend registration request processing performed by the mobile terminal 4 and friend registration processing performed by the server device 3.
  • FIG. 14 Long-term play history acquisition processing performed by mobile terminal 4 and long-term processing performed by server device 3 It is a figure which shows the flow of ray history response processing.
  • FIG. 15 is a diagram showing a flow of a transition process to the calendar screen G1 performed by the mobile terminal 4.
  • FIG. 16 is a diagram showing an example of a calendar screen G1 displayed on the mobile terminal 4.
  • FIG. 17 is a diagram showing an example of a calendar screen G1 displayed when an operation of pressing the previous month button in the calendar screen G1 shown in FIG. 16 is input.
  • FIG. 18 is a diagram showing a flow of specific day play history acquisition processing performed by the mobile terminal 4 and specific day play history response processing performed by the server device 3.
  • FIG. 19 is a diagram showing an example of a detail screen G7 displayed on the mobile terminal 4.
  • FIG. 20 Public ID change request processing performed by mobile terminal 4 and public I performed by server device 3
  • FIG. 21 is a diagram showing a flow of program processing according to the second embodiment of the present invention in association with a flow of program handling processing performed by the server device 3 in accordance with the program processing.
  • FIG. 22 is a diagram showing a flow of specific day play history acquisition processing performed by the mobile terminal 4 in the second embodiment of the present invention.
  • FIG. 1 is a block diagram showing a communication system including the game system according to the first embodiment of the present invention.
  • This communication system provides a notification service in which a large number of players play a predetermined game, while notifying the player's friends of the player's growth regarding the skill of the predetermined game. It has a game device 1, a large number of cards 2, and the above game system.
  • the game system provides the notification service and includes a server device 3 and a large number of mobile terminals (terminal devices) 4.
  • the game device 1 is an operation device that is used by a player who plays a predetermined game and causes the player to play the predetermined game for a fee.
  • a game arcade (game arcade) ) Are installed one by one or more.
  • the player is A game result can be obtained by playing a predetermined game using the game apparatus 1 in the store, and the game apparatus 1 generates play data indicating the game result.
  • the game result is an evaluation made by the game apparatus 1 for one play and includes a score at the end of the play.
  • the card 2 is a portable information recording medium that magnetically records information, and records its own card ID (medium identification information) in a manner that is difficult to rewrite.
  • the card ID is unique information that is different for each card 2, and each of all the cards 2 can be identified by the card ID.
  • the force ID is read by the game device 1 or collected by the server device 3 in order to prevent unauthorized use of the force ID! Therefore, the card ID is a private ID that identifies the card and thus the player who owns the card. In this embodiment, the player may own another recording medium in place of the power card that owns the card.
  • card 2 means a card 2 for a predetermined game.
  • the usage status of the card 2 is roughly classified into unregistered in the game system and registered in the game system.
  • the card ID of the card 2 registered in the game system is managed by the server device 3.
  • the server device 3 is a computer that collects the power play data and card ID of each of a large number of game devices 1 and transmits data relating to the skill of a predetermined game to a specific mobile terminal 4.
  • the server device 3 may be configured as a single computer, or may be configured by connecting multiple computers over a network.
  • the server device 3 and each of the multiple game devices 1 can perform data communication via the Internet 5.
  • the mobile terminal 4 is a computer that is owned by the player, receives data from the server device 3, and performs display according to the data.
  • the mobile terminal 4 provides data communication and telephone communication services.
  • Base stations 61 are distributed and arranged to cover the service area of mobile communication network 6.
  • Each base station 61 can wirelessly communicate with the mobile terminal 4 in the cell that it covers.
  • the mobile terminal 4 uses the mobile communication network 6 by wirelessly communicating with the base station 61 covering the cell including its own location.
  • a computer that does not function as a mobile phone may be used instead of the mobile terminal 4 by modifying this embodiment, or a stationary type converter may be used.
  • the mobile communication network 6 is connected to the Internet 5 via a gateway 7.
  • the gateway 7 converts the communication protocol between the mobile communication network 6 and the Internet 5 to each other. Therefore, the server apparatus 3 and each of the large number of mobile terminals 4 can perform data communication via the mobile communication network 6 and the Internet 5.
  • FIG. 2 is a perspective view showing the appearance of the game apparatus 1 constituting the communication system
  • FIG. 3 is a block diagram showing the structure of the game apparatus 1.
  • the game apparatus 1 includes a processor 11, a storage unit 12, a card reading unit 13, an operation unit 14, a display unit 15, a speaker 16, a communication interface 17 (transmission unit), and a storage unit 18.
  • the storage unit 12 discriminates coins inserted from the insertion slot 121 formed in the housing 19, stores the coins if they are predetermined coins, and indicates that the coins have been inserted.
  • the predetermined coin is a coin having a value equivalent to one play fee of one or more predetermined games, for example, a hard maney.
  • the card reading unit 13 has a slot 131 opened in the housing 11, and when the card 2 is inserted from the insertion slot 131, the card reading unit 13 reads the card ID from the card 2 and sends a signal indicating the card ID to the processor 11 To supply.
  • the operation unit 14 includes nine operators 141 that are operated by a player in a predetermined game play. When any one of the operators 141 is operated, a signal unique to the operator 141 is output. Supply to processor 11. A predetermined one of the nine operators 141 also serves as a start button for starting a predetermined game play.
  • the display unit 15 has a display area 151, receives image data from the processor 11, and displays a game screen in the display area 151.
  • the speaker 16 receives the tone signal from the processor 11 and emits the sound.
  • the communication interface 17 is connected to the Internet 5 via a relay device such as a router or directly, and relays data between the processor 11 and the Internet 5.
  • the storage unit 18 includes a nonvolatile memory such as a ROM (Read Only Memory) and a rewritable memory such as a RAM (Random Access Memory). Variable data such as play data and card ID is written to the rewritable memory. Non-volatile memory stores invariant data such as game programs.
  • the game apparatus 1 When the processor 11 executes this game program, the game apparatus 1 reads the card 2 card ID inserted in the slot 131, performs a game process for causing the player to play a predetermined game, Various requests are transmitted to the server device 3 and various responses described later are received from the server device 3.
  • the content of the predetermined game will be described.
  • FIG. 4 is a view showing an example of the game screen displayed in the display area 151 of the game apparatus 1.
  • a game area R is secured in the center of the game screen.
  • an oval object OB appears in the upper part of the figure according to the music pre-selected by the player, and drops and disappears in the lower part of the figure along any of the nine columns.
  • the music is played and emitted from the speaker 16.
  • the score is an integrated value of the points given in a single play and increases as the play progresses.
  • the level meter LM indicates the level of play by the length of the partial image. This level is a value indicating the quality of the play up to the present time in one play, and is a statistical value of the quality of the operations performed so far in one play. The quality of an operation increases when the operation is performed with high accuracy and decreases when the operation is performed with low accuracy.
  • the game result includes only the score of the play, which is the score at the end of the play. Instead, the result of granting a clearing reward medal in that play is included.
  • Clear reward medals are virtual rewards given to players who have cleared a given game, and there are two types: the best “perfect” and the next best “no bad”.
  • the award of the clear reward medal may be accompanied by paying out tangible items as prizes.
  • FIG. 5 is a block diagram showing a configuration of the server device 3 constituting the communication system.
  • the server device 3 includes a processor 31, a communication interface 32 (play data receiving unit, friend registration request receiving unit, long-term play history request receiving unit, specific day play history request receiving unit) and storage unit 33. (Server storage).
  • the communication interface 32 is connected to the Internet 5 via a relay device such as a router or directly, and relays data between the processor 31 and the Internet 5.
  • the storage unit 33 includes a ROM in which an IPL (Initial Program Loader) is written, a RAM used as a work area, and a hard disk.
  • IPL Initial Program Loader
  • the latest play data table T1 personal data area
  • public ID table T2 personal data area
  • person association table T3 person association data area
  • terminal supply play data table T4 Personal data area
  • the hard disk stores a terminal program ⁇ that is installed in the mobile terminal 4 and can be executed by the mobile terminal 4.
  • the terminal program ⁇ is a program (program product) for causing the mobile terminal 4 to function as a device that informs a friend of the player about the player's growth regarding the skill of a predetermined game.
  • a management program (not shown) is stored in the hard disk, and the processor 31 starts executing the management program by executing an IPL. When the processor 31 executes this management program, the server device 3 virtually generates functional units including the units shown in FIG.
  • FIG. 6 is a diagram showing an appearance of the mobile terminal 4 constituting the communication system
  • FIG. 7 is a mobile terminal.
  • 4 is a block diagram showing a configuration of 4.
  • the mobile terminal 4 includes a processor 41 (memory management unit), a microphone 42, a speaker 43, an operation unit 44, a display unit 45, and a wireless communication interface 46 (reception unit, in-terminal reception unit). And a storage unit 47 (terminal storage unit).
  • the microphone 42 is used during a call and supplies a signal corresponding to the user's voice to the processor 41.
  • the speaker 43 is used during a call and receives a sound signal from the processor 41 and emits the sound.
  • the operation unit 44 includes a plurality of keys operated by the user, and supplies a signal specific to the pressed key to the processor 41 when the key is pressed.
  • the display unit 45 has a display area 451, receives image data from the processor 11, and displays a screen corresponding to the image data in the display area 451.
  • the wireless communication interface 46 includes an antenna 461 and relays data between the processor 41 and the base station 61.
  • the communication path between the radio communication interface 46 and the base station 61 is a radio communication path.
  • Storage unit 47 includes RAM, ROM and EEPROM (Electrically Erasable Programmable
  • the ROM stores the operating system of the mobile terminal 4 and is executed when the mobile terminal 4 is started.
  • This operating system is a program
  • the processor 41 is provided with a telephone communication function, a data communication function, a function for downloading another program, a function for executing a downloaded program, and the like. With this function, the processor 41 executes the above-described terminal program P, so that a functional unit including each unit shown in FIG.
  • a program area 471 for storing the downloaded program and a data area 472 corresponding to this area are secured.
  • the processor 41 that is executing the program stored in the program area 471 can access the data area 472.
  • the storage unit 47 has a terminal identifier area 473 for storing a terminal identifier unique to the mobile terminal 4.
  • the terminal identifier is information that can identify each of a large number of mobile terminals 4, and examples of such information include the telephone number of the mobile terminal 4.
  • FIG. 8 is a diagram showing screen transition when the terminal program P is executed in the mobile terminal 4.
  • the screen displayed in the display area 451 includes operations such as a cursor that moves within the screen and buttons pressed by the user via software. Images of possible objects can be included.
  • the plurality of keys provided in the operation unit 44 include a movement key 441 for moving the cursor and a determination key 442 for the user to press a button on the screen via software! / .
  • FIG. 9 shows the functions of the communication system, particularly the game system.
  • the processor 31 of the server device 3 includes a card registration unit 31A, a play data update unit 31B, a friend registration unit 31C, an update reflection unit 31D (terminal supply data recording unit), and a long-term play history. It functions as the response unit 31E (friend play history transmission unit), specific day play history response unit 31F (friend play history transmission unit), public ID change unit 31G, and association clear unit 31H. Since these functions are also functions of the server apparatus 3, in the following description, the server apparatus 3 is not the processor 31 but is the main subject of operation for convenience.
  • the processor 41 of the portable terminal 4 functions as a friend registration processing unit 41A, a long-term play history acquisition unit 41B, a control unit 41C, a specific day play history acquisition unit 41D, and a public ID change processing unit 41E. Since these functions are also functions of the mobile terminal 4, in the following description, the mobile terminal 4 rather than the processor 41 is used as the subject of operation for convenience. These functions and the functions of the game apparatus 1 will be described in accordance with a usage example of the communication system.
  • FIG. 10 is a diagram showing an overall operation flow in a communication system usage example.
  • a certain player hereinafter referred to as “Player A”
  • Player A plays a predetermined game on a certain game device 1 using a card 2 that is not registered in the game system that he / she owns.
  • the player A inserts the card 2 into the entrance 131 of the game apparatus 1, the game apparatus 1 reads the card ID (for example, “00000001”) from the card 2, and the use state of the card 2 ( Confirming the power / power registered in the game system, player A inserts a coin of sufficient value from the slot 121, operates the start button, and the game device 1 starts the game process triggered by this operation. It starts with.
  • the card ID for example, “00000001”
  • the processor 11 of the game apparatus 1 first functions as a play data generation unit to generate play data indicating the game result obtained by the play, while the player A self-exists. Enter the player ID and name of card 2 in question.
  • the processor 11 functions as a transmission unit, and is a card that is a message requesting registration of the card 2 and update of the latest play data (described later) related to the card 2 via the communication interface 17 (transmission unit).
  • the registration request ml is sent to the server device 3.
  • the card registration request ml includes the input player ID, the read card ID, name data indicating the input name, and generated play data.
  • the player ID is information that differs for each player, and is assigned in advance to all players that can use this communication system and is managed by the server device 3. It is difficult to rewrite the player ID.
  • the player ID is input to the game device 1, managed by the server device 3, or input to the mobile terminal 4. In order to prevent unauthorized use, the player ID of a player is It will not be disclosed to other players.
  • the server device 3 When the communication interface 32 (play data receiving unit) receives the card registration request ml, the server device 3 functions as the card registration unit 31A (personal data writing unit) and registers the card 2. Specifically, the card ID in the card registration request ml is stored in the storage unit 33 in association with the player ID in the card registration request ml. On the other hand, a public ID (public identification information) is generated, and the public ID, the card ID, and the name data in the card registration request ml are associated with each other and stored in the public ID table T2.
  • the public ID table T2 stores public IDs and name data for each card ID.
  • the latest play data table T1 stores the latest play data for each card ID.
  • this card 2 is already registered in the game system.
  • the card ID recorded on the card 2 registered in the game system can be used as identification information for identifying each of a large number of players in the server device 3.
  • the public ID is information that can be used as identification information for identifying each of a large number of players in the server device 3 in the same manner as the card ID recorded in the registered card 2.
  • the record of the latest play data table T1 has a field for the latest play data.
  • the latest play data (play status information) indicates the result of the player's play on one or more game devices 1, that is, the proficiency of a predetermined game, and is the highest value of the play score obtained in the past. It includes data indicating a certain high score, data indicating the acquisition status of clear reward medals, and data indicating the number of times played, and the field for the latest play data is divided into small fields for these data. Yes.
  • the acquisition status of clear reward medals is the best of the results of granting clear reward medals obtained in the past.
  • the server device 3 functions as a play data update unit 31B that is a part of the card registration unit 31A, and performs update processing of the latest play data based on the card registration request ml.
  • the latest play data corresponding to the card ID in the card registration request ml is updated.
  • the server device 3 functions as a play status information generation unit, and generates the latest play data (play status information) based on the play data in the card registration request ml. “Generating” here includes including the contents of the play data in the card registration request ml as the latest play data as they are.
  • the play data update unit 31B writes the latest play data corresponding to the card ID in the latest play data table T1.
  • the latest play data is rewritten for each small field.
  • the contents of the play data in the card registration request ml are written in the small field indicating the noisy score and the clear field indicating the acquisition status of the clear reward medal, and the small number indicating the number of plays. 1 is written to the field.
  • the server device 3 functions as a card registration unit 31A (self-disclosure identification information transmission unit), and registers the card 2 via the communication interface 32 (self-disclosure identification information transmission unit).
  • a card registration response m2 is returned as a message indicating that the card has been updated and that the update of the latest play data for the card 2 has been completed.
  • the card registration response m2 includes a public ID corresponding to the card ID recorded on the card 2.
  • the server device 3 functions as the update reflection unit 31D, and performs an update reflection process for reflecting the update contents of the latest play data in the terminal supply play data table T4 described in detail later.
  • FIG. 11 is a diagram showing a flow of update reflection processing performed by the server device 3.
  • the server device 3 starts with the card ID or the card. It is determined whether the public ID corresponding to the host ID is stored in the human association table T3 (step Sal).
  • the human association table T3 includes the card ID of the registered card 2 owned by the first player and the registered card 2 owned by one or two second players designated by the first player. The card ID is stored in association with the public ID corresponding to the card ID. However, in the human association table T3, the public identification information of the first player and the public identification information of one or two second players designated as the first player are associated with each other. It may be stored.
  • the judgment result of step Sal is negative, and the update reflection process is terminated without performing any process.
  • the game device 1 displays an image indicating that registration of the card 2 is completed and an ID for disclosure in the card registration response m2.
  • player A can know the public ID corresponding to card 2. Therefore, thereafter, Player A can inform the friend player of this public ID.
  • Player A can know the public ID using the mobile terminal 4 at a later stage. Therefore, even if the embodiment is modified so that the card registration response m2 does not include the public ID and the game device 1 does not display an image representing the public ID, the player A You will still be able to share your public ID with your friends.
  • the player A installs the terminal program P in the portable terminal 4 owned! /. Specifically, by operating the mobile terminal 4, the terminal program P is transmitted from the server device 3 to the mobile terminal 4 and stored in the storage unit 47. At this time, as shown in FIG. 10, the mobile terminal 4 responds to the operation of the player A and the terminal program P A program transmission request, which is a message requesting transmission of, is transmitted to the server device 3.
  • This program transmission request includes the player ID of player A input by player A and the terminal identifier in terminal identifier area 473 of storage unit 47.
  • the server device 3 Upon receiving this program transmission request, the server device 3 (identity information transmission unit for self-publication) responds to the player ID in this program transmission request via the communication interface 32 (identity information transmission unit for self-publication). Returns a card list that is a list of public ID and name data pairs corresponding to all the card IDs (the power of all cards this player has -KID). This list also includes public IDs corresponding to cards for games other than the predetermined game.
  • the mobile terminal 4 Upon receiving this card list, the mobile terminal 4 displays a list of pairs in the card list, and selects a pair corresponding to the card for a predetermined game, that is, a pair corresponding to the card 2 from the player A. Prompt. This allows player A to know the public ID corresponding to his card 2. Then, when the player A operates the portable terminal 4 to select a pair corresponding to the card 2, the selection instruction including the public ID in the pair is transmitted to the server device 3. Upon receiving this selection instruction, the server device 3 stores the card ID corresponding to the public ID in the selection instruction, the player ID and the terminal identifier in the program transmission request, in association with each other, and stores them for the terminal. A program transmission response including program P and the corresponding player ID is returned. Note that this embodiment may be modified to include data indicating the name of the game in the set in the card list.
  • the mobile terminal 4 Upon receiving this program transmission response, the mobile terminal 4 stores the terminal program P in the program transmission response in the program area 471 of the storage unit 47, while the data area 472 corresponding to the program area 471.
  • a calendar area C for storing data such as calendar data, which will be described later
  • a player ID area U for storing the player ID are secured, and the player ID in the program transmission response is stored in the player ID area U. Is stored.
  • the processor 41 of the mobile terminal 4 reads the terminal program P from the program area 471 and executes it.
  • the processing performed by the portable terminal 4 by this execution is called program processing.
  • Terminal pro When Gram P is executed for the first time, the server device 3 performs the initial process accordingly. Further, when the server apparatus 3 receives a request from the mobile terminal 4 performing the program processing, the server apparatus 3 performs a request response process corresponding to the request. Details of the initial processing and request processing will be described later.
  • the server device 3 pursues a record in the human association table T3! Suppose that the card ID of the registered card 2 owned by player A is stored in the card ID field of the record.
  • the server device 3 functions as a friend registration unit 31C (human association data writing unit), and the card ID of the registered card 2 owned by the player A is entered in the card ID field of the record.
  • Player A is informed of Player IDs by Player B and Player C.
  • the processor 11 of the game apparatus 1 functions as a transmission unit, and sends an update request m3, which is a message requesting the update of the latest play data, to the server apparatus 3 via the communication interface 17 (transmission unit). Send to.
  • the update request m3 includes the play data generated for the play and the card ID.
  • the server device 3 functions as the play data update unit 31B (personal data writing unit), and updates the latest play data based on the update request m3. Process.
  • the processor 31 of the server device 3 functions as a play status information generation unit, and generates the latest play data (play status information) based on the play data in the update request m3. “Generating” here also includes making the play data in the card registration request ml the latest play data as it is. Then, the play data update unit 31B writes the latest play data corresponding to the card ID in the latest play data table T1. As a result, the latest play data corresponding to the card ID recorded on the card 2 becomes the latest. . In the update based on the update request m3, the latest play data is rewritten for each small field. Whether or not rewriting is performed is determined according to a predetermined condition for each small field. This “condition” is a concept including unconditional.
  • the data in the small field for high-score data is rewritten because the play score in the play data in the update request exceeds the score indicated by the current data.
  • the data in the small field is rewritten so as to indicate the score of the play in the update request.
  • the data in the small field for data indicating the acquisition status of the clear reward medal is rewritten by the play data in the update request rather than the acquisition status of the clear reward medal currently indicated by the data. This is only when the result of assignment is better.
  • the data in the small field is rewritten so as to indicate the result of assignment in the update request.
  • the data in the small field for data indicating the number of times of play is always rewritten in the update process of the latest play data. This rewriting is performed so that the number of plays indicated by the data increases by one.
  • the latest play data to be updated corresponds to the force ID in the update request m3, and the response that is returned completes the update of the latest play data for the card 2.
  • the server device 3 When the update process of the latest play data is completed, the server device 3 functions as the update reflection unit 31D and performs the update reflection process of FIG. If the above initial processing has been executed, the result of the determination of whether or not the force ID or the public ID corresponding to the card ID is stored in the human association table T3 (step Sal) is positive. It becomes. Therefore, the server device 3 performs a reflection process for reflecting the latest play data corresponding to the card ID in the terminal supply play data table T4 (step Sa2), and ends the update reflection process.
  • the terminal-supplied play data table T4 is a predetermined game skill of the player who has the card 2 whose card ID or public ID is stored in the human association table T3. It is for recording the growth related to the previous.
  • the card ID of the card 2 the play data for terminal supply indicating the skill of the predetermined game of the player who owns the card 2, and the play data for terminal supply In order to obtain it, date data indicating the date on which the player has played a predetermined game is stored in association with each other.
  • Play data for terminal supply is a subset of the latest play data, including data indicating high score, data indicating the acquisition status of clear reward medals, data indicating the number of plays, etc. Can be supplied to the mobile terminal 4. As shown in FIG.
  • step Sa2 first, based on the latest play data (that is, based on the play data in the card registration request ml or update request m3), the player's skill is improved.
  • the terminal supply play data shown is generated.
  • the “generation” here includes the content of the latest play data as it is as the play data for terminal supply.
  • a record is added to the terminal supply play data table T4, and the terminal supply play data obtained based on the card ID, the latest play data corresponding to the card ID, and the current date are added to the record.
  • the date data shown are stored in association with each other.
  • the server device 3 every time the server device 3 receives an update request from the game device 1, the update processing of the latest play data is performed, and the card ID in the update request is further processed.
  • a public ID corresponding to the card ID is stored in the human association table T3, an update reflection process is performed to update the terminal-supplied play data table T4.
  • the player A performs a predetermined operation and the terminal program P is executed on the portable terminal 4 to perform the program process. If this execution is the second time, the initial processing is performed in server device 3. It will never be.
  • the server device 3 can only perform request response processing in response to a request from the mobile terminal 4. In these processes, terminal supply play data and date data corresponding to Player B and Player C are transmitted to the mobile terminal 4 owned by Player A, and Player B An image showing the date of the game play and the player B's proficiency on that date is displayed, the date of the date when the player C played the predetermined game, and an image showing the prowess of the player C on that date are displayed Or
  • FIG. 12 is a diagram showing the flow of program processing performed in the mobile terminal 4 and the flow of initial processing performed in the server device 3 in accordance with the program processing.
  • the portable terminal 4 first determines whether or not the terminal program P is executed for the first time (step Sbl). This determination can be realized, for example, by securing in the data area 472 a flag that is turned on immediately after installation of the terminal program P and turned off after the determination. If the determination result is affirmative, the mobile terminal 4 transmits a record addition request, which is a message requesting addition of a record to the human association table T3, to the server device 3 (step Sb2).
  • This record addition request includes the player ID in the player ID area U and the terminal identifier in the terminal identifier area 473.
  • the server device 3 Upon receiving this record tracking request in the initial processing (step Scl), the server device 3 adds a record to the human association table T3 (step Sc2), and in the card ID field of this record, Stores the player ID and card ID corresponding to the terminal identifier in the record addition request (step Sc3), and returns a record addition response, which is a message indicating that the addition of the record to the human association table T3 has been completed. (Step Sc4).
  • This record addition response includes the public ID and name data corresponding to the card ID.
  • the portable terminal 4 receives this record addition response, and writes the public ID and name data in this record addition response to the data area 472 (step Sb3).
  • the display screen is changed to the calendar screen G1 in FIG. 8 (step Sb4).
  • terminal program Even when the determination result of whether or not the ram P is executed for the first time is negative, the display screen is changed to the calendar screen G1 in FIG. 8 (step Sb4).
  • the public ID and name data for the player whose portable terminal 4 is the owner may be written to the data area 472 when the terminal program P is downloaded.
  • the record addition response need not include the public ID and name data.
  • the portable terminal 4 waits for an operation input by the player who is the owner (step Sb5), determines whether or not the input operation is an end operation (step Sb6), and determines the result. If the result is negative, the process corresponding to the operation corresponding to the operation is performed (step Sb7). This repetition ends when an end operation is input, and thus the program processing ends.
  • the content of the operation handling process varies depending on the input operation.
  • the display screen may only be changed to the menu screen G2.
  • a request is sent to the server device 3 and a response is received from the server device 3.
  • the server apparatus 3 performs a request handling process with contents corresponding to the request from the mobile terminal 4.
  • the request response process according to the operation handling process includes a friend registration process according to the friend registration request process, a long-term play history response process according to the long-term play history acquisition process, and a specific day play history acquisition process.
  • FIG. 13 is a diagram showing a flow of friend registration request processing performed by the mobile terminal 4 and friend registration processing performed by the server device 3.
  • the mobile terminal 4 performs the friend registration request process when an operation input for pressing the friend registration button in the menu screen G2 in FIG. 8 is made.
  • the mobile device 4 first selects the type of friend (first friend Z second friend) to register and input the public ID of the friend to register. And a transition to the registration start screen G3 prompting the input of the registration operation (step Sdl).
  • step Sd2 the player who is the owner of the mobile terminal 4 (second player) waits for an operation input at the operation unit 44 (friend identification information input unit) (step Sd2) and is input.
  • step Sd3 Process to reflect the operation on the screen (step Sd3), determine whether the input operation is a registration operation (step Sd4), and if the result of this determination is negative, return the process to step Sd2. repeat.
  • Other operations that can be entered in this iteration include entering the public ID of another player (friend) and selecting the type of friend you want to register (first friend Z second friend).
  • the registration operation is an operation of pressing the registration button in the registration start screen G3.
  • the mobile terminal 4 functions as the friend registration processing unit 41 A, sends a friend registration request m5, which is a message requesting friend registration, to the server device 3 (step Sd5), and displays the display screen during registration. Transition to the registration screen G4 indicating that there is something (step Sd6).
  • the friend registration request m5 is a friend selection flag indicating the type of the selected friend, the public ID of the entered friend (first player), the player of the owner (second player) in the player ID area U ID and terminal identifier in terminal identifier area 473 are included.
  • the server device 3 When the server device 3 receives the friend registration request m3 via the communication interface 32 (friend registration request receiving unit) in the friend registration process (step Sel), the server device 3 functions as the friend registration unit 31C. , A field for the type of friend indicated by the friend selection flag in the friend registration request m5 of the record storing the card ID corresponding to the player ID and the terminal identifier in the friend registration request m5 in the human association table T3 The public ID in the friend registration request m5 is stored in (Step Se2). Next, the server device 3 functions as the friend registration unit 31C, acquires the name data corresponding to the public ID from the public ID table T2 (Step Se3), and includes this name data. The friend registration response m6, which is a message indicating that the friend registration has been completed, is returned (step Se4). This completes the friend registration process.
  • the mobile terminal 4 functions as the friend registration processing unit 41A and receives the friend registration response m6 (step Sd7), the name data in the friend registration response m6 and the entered public ID are selected.
  • the corresponding type (first friend Z second friend) is stored in the calendar area C, and the display screen is changed to the registration completion screen G5 using the name data (step Sd8).
  • the corresponding ID is displayed as a friend of the selected type. An image showing that the corresponding card 2 has been registered is included.
  • step Sd9 the portable terminal 4 waits for an operation input (step Sd9), and determines whether the input operation is an operation of pressing the menu button in the registration completion screen G5, that is, whether or not the force is a transition operation to the menu screen G2. Judgment is made (step SdlO), and if this judgment result is negative, the process of step Sd9 is repeated. This repetition ends when a transition operation to the menu screen G2 is input. Then, the mobile terminal 4 changes the display screen to the menu screen G2 (step Sdl l). Thus, the friend registration request process ends.
  • FIG. 14 is a diagram showing the flow of the long-term play history acquisition process performed by the mobile terminal 4 and the long-term play history response process performed by the server device 3.
  • the mobile terminal 4 is supplied with terminals for the owner of the mobile terminal 4 and friends of the owner within a predetermined short period (second period described later). Date data on play data and date of play is provided, and the owner of the mobile device 4 can see the growth of himself and his friends.
  • date data related to the date of play by the owner of the mobile terminal 4 and the friend of the owner for a predetermined long period (the first period described later) is stored. Supplied to the portable terminal 4, the owner of the portable terminal 4 can see the date played by the owner of the portable terminal 4 and the friend of the owner.
  • the mobile terminal 4 performs the long-term play history acquisition process when an operation input for pressing the update button in the menu screen G2 in FIG. 8 is made.
  • the mobile terminal 4 first functions as the long-term play history acquisition unit 41B (long-term play history request transmission unit), and will be described later via the wireless interface 46 (long-term play history request transmission unit).
  • a long-term play history request m7 which is a message requesting batch transmission of calendar data, is transmitted (step Sfl).
  • the long-term play history request m7 includes a player ID in the player ID area U and a terminal identifier in the terminal identifier area 473.
  • the mobile terminal 4 functions as the long-term play history acquisition unit 41B, and transitions the display screen to the updating screen G6 indicating that updating is in progress (step Sf2).
  • the server device 3 uses the communication interface 32 (long) for long-term play history response processing.
  • the long-term play history response unit 31E functions as a card ID corresponding to the player ID and terminal identifier in the long-term play history request m7.
  • Card ID of the owner of the mobile terminal 4 and the card ID (card ID of other player) corresponding to the public ID stored in the human association table T3 in association with the card ID
  • an extraction target period consisting of the first period and the second period is specified (step Sg2).
  • the target of batch transmission is the data in the record that stores the specified card ID and the date data indicating the date within the extraction target period among the records in the play data table T4 for terminal supply.
  • the second period is the period from the current date to a predetermined short period (for example, 30 days).
  • the first period is a period obtained by excluding the second period from the period (extraction target period) from the current date to a predetermined long period (for example, one year) before.
  • the server device 3 functions as the long-term play history response unit 31E, and among the records of the terminal supply play data table T4, the identified card ID (the card ID of the owner of the portable terminal 4 and the The calendar data to be sent in a batch is extracted from the record that stores the date data indicating the dates within the extraction target period, and the card ID of the extracted data is for release. Convert to ID (step Sg3). This extraction is done by period.
  • the card ID (the card ID of the owner of the mobile device 4 and the other player's Card ID), terminal-supplied play data, and date data are extracted, and from the record that stores date data indicating the date within the first period that is longer and older, it is stored in the record as calendar data.
  • Card ID (the card ID of the owner of the portable terminal 4 and the card ID of another player) and date data are extracted.
  • the server device 3 functions as the long-term play history response unit 31E, and more specifically functions as an encoding unit, and encodes the data obtained in step Sg3 (step Sg4).
  • This encoding is performed by replacing the original bit pattern with a shorter bit pattern according to a certain encoding rule. That is, the data obtained in step Sg3 is compressed by this encoding.
  • this compression is possible for the play data table for terminal supply.
  • the data format of the play data for terminal supply in Bull T4 and the latest play data in the latest play data table T1 is redundant. The reason why these data formats are redundant is to ensure compatibility with existing systems. Therefore, if it is not necessary to ensure compatibility with existing systems, the data format of these data can be made redundant and the above sign can be omitted.
  • the server device 3 functions as a long-term play history response unit 31E (friend play history transmission unit), and the encoded data is transmitted via the communication interface 32 (friend play history transmission unit).
  • the encoded data included in the long-term play history response m8 is called “calendar data” because it includes date data, and the reply of the long-term play history response m8 is a batch transmission of calendar data.
  • the long-term play history response process ends.
  • data derived from the same record is handled as one set in the mobile terminal 4.
  • the portable terminal 4 functions as the long-term play history acquisition unit 41B and receives the long-term play history response m8 (step Sf3).
  • the calendar data in the calendar area C is the calendar data in the long-term play history response m8. Is updated (step Sf4). As a result, the calendar data in the calendar area C is updated.
  • the mobile terminal 4 changes the display screen to the menu screen G2 (step Sf5).
  • the long-term play history acquisition process ends.
  • the calendar data is transmitted in a pull type that the mobile terminal 4 gives a trigger. Therefore, the calendar data can be transmitted only when the user of the mobile terminal 4 feels necessary. Therefore, transmission with less waste is possible, and the communication load can be further reduced.
  • FIG. 15 is a diagram illustrating a flow of the transition process to the calendar screen G1 performed by the mobile terminal 4.
  • the owner of the portable terminal 4 can see information based on the data supplied to the portable terminal 4 in the long-term play history acquisition process and the long-term play history response process together with the calendar.
  • the portable terminal 4 functions as a decoding unit, and first reads calendar data from the calendar area and decodes it according to the decoding rule related to the encoding rule in the server device described above. (Step Shl). By this decoding, the data is replaced with a bit pattern that is longer than the bit pattern of the original encoded data, so that the calendar data is expanded.
  • the mobile terminal 4 functions as the control unit 41C, generates an image showing the calendar screen G1 using the decrypted calendar data (step Sh2), and displays the image to display the calendar screen G1. (Step Sh3).
  • FIG. 16 is a diagram showing an example of a calendar screen G1 displayed on the mobile terminal 4.
  • the calendar screen G1 has a character string that represents the year and month to be displayed, a character string that represents the current time, and a font that contains 28 to 31 numbers that represent the day of the month.
  • Aligned date table, text box for scrolling detailed information about the play of the owner of the selected date, menu button for transition to menu screen G2, end button for ending program processing, display target Next month button to set the current month to the next month, Previous month button to set the displayed month to the previous month, Select a date, scroll the message, and press the button Includes the cursor and icon legend area.
  • ⁇ corresponding to the date of March 23, 2005 (current day) is highlighted.
  • this embodiment may be modified to change the configuration of the calendar screen G1.
  • the text box and the legend area may be excluded from the calendar screen G1.
  • the icons include a circular icon indicating the owner of the mobile terminal 4, a triangular icon indicating the first friend, and a square icon indicating the second friend.
  • the legend is based on the public ID and name data stored in calendar area C.
  • an icon is placed in the cage corresponding to the date indicated by the date data in the calendar area C for each public ID data in the same group as the date data. Therefore, up to three icons can be placed in one frame.
  • FIG. 17 is a diagram showing an example of the calendar screen G1 displayed when an operation of pressing the previous month button in the calendar screen G1 shown in FIG. 16 is input.
  • the shape of the cocoon for example, color
  • the above-mentioned predetermined short period is 30 days
  • the above-mentioned predetermined long period is one year
  • the long-term play history acquisition process was last performed on March 22, 2005.
  • the second period is after February 22, 2005.
  • the cursor is positioned on the side corresponding to the date of March 19, 2005.
  • This date is the date of the second period, and this box contains an owner icon, so the text box contains detailed information about the owner's play on this day ( The image to be displayed is scrolled.
  • the cursor is positioned at the base corresponding to the date of February 8, 2005.
  • the power of the owner's icon in this cage This date is a date outside the second period, so the text box will not display detailed information about the owner's play on that date. Since the cursor can be moved by the movement key 441 (FIG. 6), the movement key 441 is a date designating unit that allows the owner of the portable terminal 4 to designate the date.
  • FIG. 18 is a diagram illustrating the flow of the specific day play history acquisition process performed by the mobile terminal 4 and the specific day play history response process performed by the server device 3.
  • the mobile terminal 4 is supplied with terminal-supplied play data for the owner of the mobile terminal 4 on one day and the friend of the owner.
  • the owner of the portable terminal 4 can see the performance of the play of that day by himself and his friends. More specifically, the information corresponding to the terminal-supplied play data within the predetermined short period (second period) obtained by the long-term play history acquisition process and the long-term play history response process is the specific day play history acquisition process. And immediately displayed on the mobile terminal 4. Also.
  • the mobile terminal 4 requests the server device 3 for play data for supplying the terminal, and the specific day play history response process causes the play data for terminal supply to be transmitted from the server device 3 to the mobile terminal 4. To be supplied.
  • the specific terminal play history acquisition process is performed by the mobile terminal 4 when a predetermined operation input is made when the cursor is positioned on the side where the icon in the calendar screen G1 in FIG. 8 is placed. When an appropriate date is entered.
  • the mobile terminal 4 first functions as the control unit 41C and determines whether or not the date corresponding to the bag is a date within the second period (step 3 ⁇ 41). ).
  • the calendar screen G1 at this point is as shown in FIG. 16, and the above determination result is affirmative.
  • the mobile terminal 4 functions as the control unit 41C and changes the display screen to the detail screen G7 (step 3 ⁇ 44).
  • FIG. 19 is a diagram showing an example of the detailed screen G7 displayed on the mobile terminal 4, and corresponds to the calendar screen G1 shown in FIG.
  • the detailed screen G7 includes an image corresponding to the play data for terminal supply in the same set as the date data indicating the date of March 19, 2005.
  • information indicating the proficiency of a predetermined game as of March 19, 2005 is stored in the mobile terminal 4 on the same day of the owner (Mimi) and registered friends (Bob, Nick). It will be displayed for the player who played the game.
  • the detailed screen G7 shown in Fig. 19 shows the skills of three people. The information shown is displayed.
  • the detail screen G7 is a screen that displays information indicating the skill by switching one by one.
  • a specific key e.g., left Key, right key to move the cursor to the right, etc.
  • the portable terminal 4 functions as the control unit 41C, waits for an operation input (step 3 ⁇ 45), and the input operation is an operation of pressing the return button in the details screen G7, that is, the calendar screen G1. It is determined whether or not the force is a transition operation (step 3 ⁇ 46), and if this determination result is negative, the process of returning to step Sj5 is repeated. This repetition ends when a transition operation to the calendar screen G1 is input. Then, the mobile terminal 4 functions as the control unit 41C and changes the display screen to the calendar screen G1 (step 3 ⁇ 47). In this way, special The fixed day play history acquisition process ends.
  • the mobile terminal 4 determines that the specific day play history acquisition unit 41D (specific (Date Play History Request Transmitter) via the wireless interface 46 (Specified Day Play History Request Transmitter), the date corresponding to the trap where the cursor is located (in Fig. 17, February 2005 within the first period) On the 8th), a specific day play history request ml 1 is transmitted, which is a message requesting transmission of play data for terminal supply for one day (3 ⁇ 42).
  • the specific day play history request mil includes a player ID in the player ID area U, a terminal identifier in the terminal identifier area 473, and date data indicating the date.
  • the server device 3 When the server device 3 receives the specific day play history request ml 1 by the communication interface 32 (specific day play history request receiving unit) in the specific day play history response process (step Ski), the server device 3 It functions as the day play history response unit 31F, and the card ID corresponding to the player ID and terminal identifier in the specific day play history request m 11 (card ID of the owner of the mobile terminal 4) and the human being associated with the card ID.
  • the card ID corresponding to the public ID stored in the association table T3 (the card ID of the other player) is identified, and the identified card ID (the card ID of the owner of the mobile device 4 and the card of the other player)
  • the terminal supply play data table T4 force is also extracted corresponding to the ID) and the date indicated by the date data in the specific day play history request ml 1 (step Sk2).
  • the server device 3 functions as a specific day play history response unit 31F (friend play history transmission unit), and supplies the extracted terminal via the communication interface 32 (friend play history transmission unit).
  • Reply with specific day play history response ml 2 including play data (step Sk3).
  • This reply is the transmission of play data for terminal supply for one day.
  • the specific day play history response process is completed.
  • the mobile terminal 4 functions as the specific day play history acquisition unit 41D, and receives the specific day play history response ml2 (step 3 ⁇ 43). Thereafter, the mobile terminal 4 functions as the control unit 41C, and performs the processing from Step 3 to Step 4.
  • an image corresponding to the play data for terminal supply in the specific day play history response m12 is included in the detailed screen G7.
  • Play data for terminal supply within the first period that is within the extraction target period and outside the second period can also be received.
  • the desired terminal supply play data can be received without increasing the communication load. be able to.
  • the specific day play history acquisition process is not performed even if a predetermined operation input is made when the cursor is positioned at the base when the icon is arranged. Therefore, according to the present embodiment, it is possible to avoid a situation where the communication and the specific day play history response process are performed wastefully.
  • FIG. 20 is a diagram showing the flow of the public ID change request process performed by the mobile terminal 4 and the public ID change process performed by the server apparatus 3. Through the public ID change request process and the public ID change process, the owner of the mobile terminal 4 can change his public ID.
  • the mobile terminal 4 performs the public ID change request process by pressing the public ID change button in the player-user screen G2 that is the owner of the mobile terminal 4 on the operation unit 44 (identification information for self-publication). This is when an operation input is made via the software in the change instruction input unit).
  • the mobile terminal 4 functions as the public ID change processing unit 41E (self-identification identification information change processing unit).
  • the public ID change request is a message requesting the change of the public ID.
  • m9 is transmitted to server device 3 (step Sml).
  • the public ID change request m9 includes a player ID in the player ID area U and a terminal identifier in the terminal identifier area 473.
  • the server device 3 Upon receiving the public ID change request m9 in the public ID changing process (step Snl), the server device 3 functions as the public ID changing unit 31G (public identification information changing unit), and is publicly available. ID is generated (step Sn2). Next, the server device 3 functions as the public ID changing unit 31G, specifies the force ID corresponding to the layer ID and the terminal identifier in the public ID change request m9, and discloses the force ID corresponding to the card ID. The public ID stored in the public ID table T2 is updated with the generated public ID (step Sn3).
  • the server device 3 functions as the association clearing unit 31H, and clears the public ID before being updated from the human association table T3 (step Sn4).
  • the association table T3 there is no public ID corresponding to the card ID. Therefore, unless the player who owns the card 2 in which the card ID is recorded does not inform others of the updated public ID, data indicating the player's skill is sent to the mobile terminal 4 of the other person. None happen.
  • the server device 3 functions as the public ID changing unit 31G, and returns a public ID change response mlO, which is a message indicating that the change of the public ID has been completed.
  • Public ID change response mlO contains the updated public ID.
  • the mobile terminal 4 functions as the public ID change processing unit 41E.
  • the mobile terminal 4 receives the public ID change response mlO
  • the mobile terminal 4 sets the public ID in the calendar area C with the public ID in the public ID change response mlO.
  • Update step Sm2
  • the mobile terminal 4 changes the display screen to the change completion screen G9 (step Sm3).
  • This screen contains an image showing the updated public ID. Therefore, the user of the mobile terminal 4 can know the updated public ID, and can also notify others of the updated public ID.
  • step Sm4 the portable terminal 4 waits for an operation input (step Sm4), and the input operation is completed.
  • the operation is performed by pressing the menu button in the screen G9, that is, whether or not the force is a transition operation to the menu screen G2. Judgment is made (step Sm5), and if this judgment result is negative, the process of returning to step Sm4 is repeated. This repetition ends when a transition operation to the menu screen G2 is input.
  • step Sdl l the mobile terminal 4 changes the display screen to the menu screen G2 (step Sdl l).
  • the public ID change request process ends.
  • a player who is a user of the mobile terminal 4 can increase the potential of a friend player regarding the skill of a predetermined game by looking at the arrangement of icons. Can be ascertained over the extraction period (for example, the past year). Further, the player who is the user of the mobile terminal 4 can grasp the growth of the friend's player regarding the skill of the game over the second period (for example, the past 30 days).
  • the terminal supply play data passed to the mobile terminal 4 is limited to data corresponding to date data indicating dates within the second period, all terminal supplies corresponding to date data indicating dates within the extraction target period are provided. Compared to the case where the play data is passed to the mobile terminal 4, the communication load is reduced.
  • the identification information for identifying each of a large number of players, and the identification information that the player informs other players to use the notification service can be easily changed later.
  • Public ID Therefore, according to the present embodiment, other players can easily change their public ID, and this change allows their play data to be used in the notification service. Can be stopped reliably. In addition, by notifying others of the changed public ID, it is possible to change who can use their own play data in the notification service.
  • the configuration of the communication system according to the present embodiment is the same as that of the communication system according to the first embodiment.
  • the terminal program P and the management program stored in the hard disk of the server device 3 are different from those in the first embodiment. For this reason, some operations among the functional units virtually generated in the server device 3 and the portable terminal 4 are different from those in the first embodiment. These differences are explained next.
  • FIG. 21 is a diagram showing the flow of program processing in the present embodiment in association with the flow of program handling processing performed by the server device 3 in accordance with the program processing.
  • the mobile terminal 4 functions as the long-term play history acquisition unit 41B in the program processing, and the long-term play history request m7 without determining whether or not the terminal program P is executed for the first time. Is transmitted to server device 3.
  • the display screen is changed to the updating screen G6 (step Sp2).
  • step Sql when the server device 3 receives the long-term play history request m7 in the program response process (step Sql), it functions as the long-term play history response unit 31E, and the terminal device P having the power of the portable terminal 4 is loaded. It is determined whether or not the used access is the first time (step Sq2). In this determination, for example, a flag that is on in the initial state and turned off after the determination is secured in the storage unit 33 for each player who is a user of the mobile terminal 4 that has transmitted the terminal program P. This can be realized.
  • the server device 3 adds a record to the human association table T3 (step Sq3), and in the card ID field of this record, the card corresponding to the player ID and terminal identifier in the long-term play history request m7. Store the ID (step Sq4).
  • the server device 3 functions as the long-term play history response unit 31E, and the card ID corresponding to the player ID and terminal identifier in the long-term play history request m7 and the card While identifying the card ID corresponding to the public ID stored in the human association table T3 in association with the ID, the extraction target period consisting of the second period and the first period is identified (step Sq5).
  • the specific contents of the extraction target period are as described in the first embodiment.
  • the server device 3 functions as the long-term play history response unit 31E, stores the identified card ID among the records of the terminal supply play data table T4, and within the extraction target period. If the number of specified records is greater than a predetermined maximum number of transmissions (for example, 10), the maximum number of transmission records is identified from the record according to a predetermined policy. Data to be sent in batch is extracted from the records thus identified, and the card ID in the extracted data is converted to a public ID (step Sq6). This extraction is performed for each period as in the first embodiment.
  • a predetermined maximum number of transmissions for example, 10
  • the determination as to whether or not the specified record is equal to or greater than the upper limit number of transmissions is also a force that allows a large number of records storing the same card ID and the same date data. This can happen because the contents of the reflection process (step Sa2 in Fig. 11) in the update reflection process are different. That is, in the reflection process in the present embodiment, the server device 3 always functions as the update reflection unit 31D and adds a record to the terminal-supplied play data table T4 every time the latest play data is updated. . Since it is practically difficult to limit the number of records storing the same card ID and the same date data, in this embodiment, the number of records is larger than the upper limit of transmission. Limited to a limited number (eg 20) or less.
  • the latest play data updated by the update process does not include data indicating the number of plays.
  • the latest play data according to the second embodiment is the past data as data indicating the proficiency of a predetermined game of the player. Not only data that shows the best or best results across all plays, but also data that shows the results of a single play (for example, data that shows the score that was obtained at the last play if not the best), It also includes data that shows the best or best results throughout the day's play (eg, data that shows the high score for the day). Therefore, the latest play data corresponding to a certain card 2 is updated every time a predetermined game is played using the card 2.
  • the server device 3 functions as an encoding unit, encodes the data obtained in step Sq6 (step Sq7), functions as the long-term play history response unit 31E, and is encoded.
  • the long-term play history response m8 including the received data is returned (step Sq8).
  • the contents of the above encoding are as described in the first embodiment.
  • the mobile terminal 4 When the mobile terminal 4 functions as the long-term play history acquisition unit 41B and receives the long-term play history response m8 (step Sp3), it updates the calendar data in the calendar area C with the calendar data in the long-term play history response m8 (Ste Sp4). As a result, the calendar data in calendar area C is updated. Next, the mobile terminal 4 performs a transition process to the calendar screen G1 (step Sb4).
  • the subsequent processing is the same as that described for the first embodiment.
  • the long-term play history acquisition process and the long-term play history response process in this embodiment conform to the above-described processes.
  • the calendar screen G1 displayed here is as shown in FIG. 16, and even if an operation of pressing the previous month button in the calendar screen G1 is input, the calendar screen G1 displayed by this is displayed in the second period. Is not displayed. In other words, the form of cocoons before February 21, 2005 and the form of cocoons after February 22, 2005 are common. However, it is still possible to avoid unnecessary communication and specific day play history response processing. The reason for this will be described next.
  • FIG. 22 is a diagram showing the flow of the specific day play history acquisition process performed by the mobile terminal 4 in the present embodiment.
  • the mobile terminal 4 functions as the control unit 41C, determines whether the date corresponding to the bag is a date within the second period (step 3 ⁇ 4 1), If the determination result is affirmative, the mobile terminal 4 performs steps 3 ⁇ 44 to 3 ⁇ 47. These The contents of the processing are the same as those described for the first embodiment.
  • the detailed screen G7 a display equivalent to 10 records of terminal-supplied play data for one player is displayed at the maximum. Therefore, the detailed screen G7 is preferably a screen that switches and displays information indicating prowess one by one.
  • step Srl If the above determination result is negative, that is, if the date corresponding to the bag is a date outside the second period, the mobile terminal 4 functions as the control unit 41C, and the display screen Is changed to a communication confirmation screen (not shown) that prompts for an operation indicating communication permission Z non-permission (step Srl).
  • the portable terminal 4 functions as the control unit 41C, and determines whether or not an operation input indicating permission of communication has been made (step Sr2).
  • step Sr2 determines whether or not an operation input indicating permission of communication has been made.
  • the mobile terminal 4 performs the processing from step 3 ⁇ 4 2 onward.
  • the contents of these processes are the same as those described in the first embodiment.
  • the specific day play history acquisition process ends.
  • the mobile terminal 4 displays the communication confirmation screen and gives the player an opportunity to specify communication permission Z non-permission. give. That is, the player knows that he has specified a date outside the second period. Therefore, the player can only permit communication when it is necessary to perform communication and specific day play history response processing. Therefore, according to the present embodiment, it is possible to avoid a situation where the communication and the specific day play history response process are performed unnecessarily. According to the present embodiment, it is possible to obtain the same effects as the various effects described in the first embodiment.
  • the terminal when updating the terminal supply play data table T4, the terminal is set according to the partial update status of the latest play data that is a superset of the terminal supply play data.
  • Supply play data may be generated. For example, if the data indicating the high score included in the latest play data that is a superset has been updated, and the data indicating the acquisition status of the clear reward medal has been updated, the clear reward medal acquisition status It may be possible to generate play data for terminal supply without including data indicating the situation!
  • the player's skill as a user can be displayed on the mobile terminal 4, but the player whose deformable and displayable skill is the user is displayed. It may be limited only to the skill of the player specified in.
  • the number of friends that can be registered is one or three or more, the number of friends can be changed. It may be modified so that identification information (for example, a public ID) for identifying each person is not transmitted.
  • the extraction target period and the second period are defined with the day before the current day as the starting day, but this is modified to extract multiple days before the current day as the starting day.
  • a target period and a second period may be defined.
  • the server device 3 performs batch transmission of terminal supply play data and the like in response to a long-term play history request from the mobile terminal 4, but this is modified to provide a server device. 3 may perform batch transmission at a predetermined period.
  • the card ID recorded on the card 2 is mainly used as the identification information for identifying each of the plurality of players. However, the present invention is not limited to this. An ID or a terminal identifier may be mainly used.
  • the server device 3 receives the friend registration request of the mobile terminal 4 and performs the friend registration process.
  • the user of the mobile terminal 4 is the administrator of the server device 3.
  • a request may be made by telephone, and the administrator may operate the server device 3 in response to this request to cause the server device 3 to perform friend registration processing.
  • the latest play data is first written to the latest play data table T1 for a certain card 2
  • the first play is recorded in the terminal supply play data added to the terminal supply play data table T4. Include data to show.
  • the best The force using the new play data table Tl it is also possible to modify this so that the latest play data table T1 is not used. For example, each time a player plays a predetermined game on the game apparatus 1 from each of a large number of game apparatuses 1 on the server apparatus 3, a play indicating a result obtained by the player playing the predetermined game is displayed.
  • a play data receiving unit for receiving data and identification information (for example, force ID) for identifying each of a large number of players given to the player is provided, and the data received by the play data receiving unit is provided. It is also possible to generate terminal supply play data and update the terminal supply play data table T4 directly based on the above.
  • a game system in which the game device 1 and the server device 3 communicate with each other is illustrated, but the present invention is not limited to the game device and can be used for communication between other operation devices and the server device 3, and the scope of the present invention. Includes such a game system and a server device.

Abstract

ゲームシステムのゲームシステムにおいて、複数のゲーム装置（１）と通信するサーバ装置（３）は、複数のプレイヤーの各々についての、プレイデータと複数のプレイヤーの各々を識別するための公開用ＩＤを最新プレイデータテーブル（Ｔ１）および公開用ＩＤテーブル（Ｔ２）に格納する。その一方、プレイヤーが使用中の携帯端末（４）へ、そのプレイヤーが自身の友達として人間関連付けテーブル（Ｔ３）に登録した他のプレイヤーについての最新プレイデータテーブル（Ｔ１）に格納されている最新プレイデータに応じた情報を送信する。その一方、プレイヤーが使用中の携帯端末（４）から公開用ＩＤ変更要求を受信すると、そのプレイヤーについて公開用ＩＤテーブル（Ｔ２）に格納されている公開用ＩＤを変更する。

Description

明 細 書
サーバ装置およびゲームシステム 技術分野
[0001] 本発明は、サーバ装置およびゲームシステムに関する。
背景技術
[0002] 特開 2005— 118543号公報〖こは、店舗 (game arcade)に配置された複数のゲーム 装置とサーバ装置とをネットワークで接続したシステムが開示されて 、る。このシステ ムでは、サーバ装置は、プレイヤーがゲームをプレイして得られる結果を示すデータ をゲーム装置力も収集してランキングデータを生成し、ランキングを公開する。一方、 携帯端末は、サーバ装置にアクセスしてプレイヤーのランキングを表示する。
発明の開示
発明が解決しょうとする課題
[0003] ところで、友人のゲームのプレイ状況を知りたいと思うプレイヤーが存在する。一方 、 自己のプレイ状況を親しくないプレイヤーには知らせたくないが友人には知らせて もよいと思うプレイヤーが存在する。両者が友人同士であれば、後者のプレイ状況を 前者に通知することが可能となる。この通知により、前者の願望が満たされるから、前 者にとってはゲームの趣向性が向上することになる。この通知は、例えば、前者が後 者と行動を共にして後者がゲームをプレイした日の日付を記録したり、後者が記録し たハイスコアを目視して日付に対応付けて記録したり、前者が後者から日付やハイス コアを随時聞き出したりして行われており、容易ではない。
[0004] この問題の解決策としては通知の自動化が挙げられる。しかし、個々のプレイヤー 相互の通知を自動化したシステムは存在しない。例えば、前述のシステムではランキ ングが公開される力 ランキングの公開はそこに参加する全プレイヤーに対して行わ れるから、プレイ状況を知らせる相手を選ぶことができな 、。
[0005] なお、前述のシステムでは、ゲームのプレイ状況を示すデータがサーバ装置に集 約される力ら、当該データを携帯端末へ送信するように変形すれば、通知の自動化 が可能となる。このような変形の一例における動作は以下の通りである。あるプレイヤ 一 (第 1のプレイヤー）が、当該プレイヤーの識別情報を、当該プレイヤーのプレイ状 況を知りたいと思う他のプレイヤー（第 2のプレイヤー）に通知する。次に当該第 2の プレイヤーが、当該識別情報を自己に対応付けてサーバ装置に登録する。以降、サ ーバ装置は、登録された識別情報で特定される第 1のプレイヤーのプレイ状況を示 すデータを、当該識別情報の登録の際に対応付けられた第 2のプレイヤーの携帯端 末へ送信する。
[0006] ところで、プレイ状況の通知の可否に関して、プレイヤーの気が変わることがありうる 。例えば、あるプレイヤ一力 上記のデータ送信を一度は許可して他のプレイヤーに 自己の識別情報を通知したものの、後に、このデータ送信を中止させたいと思ったり する。この中止を実現するための一つの方法として識別情報の変更が考えられるが、 単純に変更すると、そのデータ送信のために登録された識別情報も変更されてしま い、当該データ送信が継続されてしまう。また、単純でない変更を行うにしても、一般 に、プレイヤーの識別情報は、当該プレイヤーに対してシステムが提供する様々なサ 一ビスにおいて利用され、様々なデータと関連付けられているから、その変更には繁 雑な作業が伴う。
[0007] 他の方法としては、中止を望むプレイヤーからの依頼を受けて、当該プレイヤーの 識別情報を用いて行われた登録を無効とする方法が考えられうる。しかし、プレイヤ 一の識別情報は変更されて 、な 、から、登録を無効とされた他のプレイヤーが再び 当該識別情報を用いた登録を行うことが可能である。この登録をも無効にするには、 中止を望むプレイヤーからの再依頼が必要であったり、この登録を再依頼なしに無 効とする仕組みを新たに設けたりする必要がある。
[0008] 本発明は上述した問題に鑑みてなされたものであり、ゲーム装置等の操作装置の ユーザの操作に応じた内容の情報を他のユーザに通知可能なシステムにおいて、当 該ユーザが当該通知を中止させることを容易に実現することができるサーバ装置およ びゲームシステムを提供することを目的とする。
課題を解決するための手段
[0009] 以下、本発明について説明する。なお、本発明の理解を容易にするために添付図 面の参照符号を括弧書きにて付記するが、それにより本発明が図示の形態に限定さ れるものではない。
[0010] 上述した課題を解決するため、本発明に係るサーバ装置（3)は、複数のユーザに それぞれ操作されうる複数の操作装置（1)の各々と通信するサーバ装置（3)であつ て、
書き込まれた情報を記憶する個人データ領域 (Tl, T2, T4)と書き込まれた情報 を記憶する人間関連付けデータ領域 (T3)とを有する格納部 (33)と、
前記複数のユーザの各々を識別するための公開用識別情報と、 1つ以上の前記操 作装置（1)での操作の内容を示す操作状況情報とを、個々のユーザの公開用識別 情報と操作状況情報を対応付けて、前記個人データ領域 (Tl, T2, T4)に書き込む 個人データ書き込み部（31, 31A, 31B)と、
前記個人データ領域 (Tl, T2, T4)に公開用識別情報が書き込まれると、前記書 き込まれた公開用識別情報で識別されるユーザに宛てて、前記書き込まれた公開用 識別情報を知らせるための情報を送信する自己公開用識別情報送信部（31, 31A , 32)と、
第 1のユーザの公開用識別情報を第 2のユーザ力 受け取ると、前記受け取った第 1のユーザの公開用識別情報を前記第 2のユーザに対応付けて前記人間関連付け データ領域 (T3)に書き込む人間関連付けデータ書き込み部（31, 31C)と、 前記第 2のユーザに宛てて、前記人間関連付けデータ領域 (T3)内で前記第 2の ユーザに対応付けられている前記公開用識別情報で識別される前記第 1のユーザ について前記個人データ領域 (Tl, T2, T4)に記憶されている操作状況情報を示 す情報を送信する友達プレイ履歴送信部（31, 31E, 31F, 32)と、
ユーザから公開用識別情報の変更の要求を受けると、前記ユーザにつ!、て前記個 人データ領域 (Tl, T2, T4)に記憶されている公開用識別情報を変更する公開用 識別情報変更部（31, 31G)とを備える。
[0011] 「操作装置」は、例えば、プレイヤーにゲームをプレイさせるゲーム装置である。また 、「ユーザ」は、例えば、上記ゲーム装置でゲームをプレイするプレイヤーである。ま た、「個々のユーザの公開用識別情報と操作状況情報を…領域に書き込む」とは、あ るユーザに着目すると、当該ユーザに対応付けて当該ユーザの公開用識別情報と 当該ユーザの操作状況情報とを領域に書き込むことを意味する。また、「情報を…ュ 一ザに対応付けて…領域に書き込む」には、例えば、この情報とこのユーザを識別 するための識別情報とを相互に対応付けて当該領域に書き込むことや、この情報を 当該領域内のこのユーザに割り当てられた排他的な領域に書き込むことが含まれる
[0012] このサーバ装置（3)によれば、第 1のユーザの操作状況情報を第 2のユーザに宛て て送信するときには、人間関連付けデータ領域内の第 1のユーザの公開用識別情報 が用いられる。この公開用識別情報は第 1のユーザに把握されるものであり、第 1の ユーザは自己の公開用識別情報を第 2のユーザに知らせることが可能である。一方 、第 1のユーザからの要求を受けて変更されるのは個人データ領域内の公開用識別 情報である。したがって、第 1のユーザ力 の要求を受けて公開用識別情報が変更さ れることにより、第 1のユーザの操作状況情報を第 2のユーザに宛てて送信する処理 を中止することができる。
また、ユーザの操作状況情報は、当該ユーザの公開用識別情報に対応付けるので はなぐ当該ユーザに対応付けて記憶されている。したがって、当該ユーザの公開用 識別情報が変更されても、他のサービスに影響が出ないようにシステムを構築するこ とが可能である。
以上より、このサーバ装置（3)によれば、ユーザの操作状況情報を他のユーザに通 知可能なシステムにおいて、当該ユーザが当該通知を中止させることを容易に実現 することができる。
[0013] なお、公開用識別情報は、上記サーバ装置（3)により生成されて個人データ領域 に書き込まれてもよいし、外部から上記サーバ装置（3)に渡されて個人データ領域 に書き込まれてもよい。後者の場合には、上記サーバ装置（3)において、複数のュ 一ザにお 、て公開用識別情報が重複しな 、ことをチェックした上で個人データ領域 への書き込みを行うべきである。また、後者の場合、公開用識別情報の渡され方は任 意である。例えば、ユーザが電話により自己の公開用識別情報をオペレータに通知 し、オペレータが上記サーバ装置 (3)に当該公開用識別情報を入力する、といった 形態でもよい。 また、本発明に係る別のサーバ装置（3)は、複数のプレイヤーにそれぞれ操作され うる複数のゲーム装置（1)の各々と通信するサーバ装置（3)であって、
書き込まれた情報を記憶する個人データ領域 (Tl, T2, T4)と書き込まれた情報 を記憶する人間関連付けデータ領域 (T3)とを有する格納部 (33)と、
前記複数のプレイヤーの各々を識別するための非公開識別情報、前記複数のプレ ィヤーの各々を識別するための公開用識別情報、および 1つ以上の前記ゲーム装置
(1)でのプレイの結果を示すプレイ状況情報を、個々のプレイヤーの非公開用識別 情報と公開用識別情報とプレイ状況情報を対応付けて前記個人データ領域に書き 込む個人データ書き込み部（31, 31A, 31B)と、
前記個人データ領域 (Tl, T2, T4)に公開用識別情報が書き込まれると、前記書 き込まれた公開用識別情報で識別されるプレイヤーに宛てて、前記書き込まれた公 開用識別情報を送信する自己公開用識別情報送信部（31, 31A. 32)と、
第 1のプレイヤーの公開用識別情報を第 2のプレイヤ一力 受信すると、前記受け 取った第 1のプレイヤーの公開用識別情報を前記第 2のプレイヤーの非公開識別情 報または公開用識別情報に対応付けて前記人間関連付けデータ領域 (T3)に書き 込む人間関連付けデータ書き込み部（31, 31C)と、
前記第 2のプレイヤーに宛てて、前記人間関連付けデータ領域 (T3)内で前記第 2 のプレイヤーの前記非公開識別情報または前記公開用識別情報に対応付けられて いる前記公開用識別情報で識別される前記第 1のプレイヤーについて前記個人デ ータ領域 (Tl, T2, T4)に記憶されているプレイ状況情報を示す情報を送信する友 達プレイ履歴送信部（31, 31E, 31F, 32)と、
プレイヤーから公開用識別情報の変更の要求を受けると、前記プレイヤーについ て前記個人データ領域 (Tl, T2, T4)に記憶されている公開用識別情報を変更す る公開用識別情報変更部 (31, 31G)とを備える。
このサーバ装置（3)によれば、前述のサーバ装置（3)について述べた理由と同様 の理由により、プレイヤーのプレイ状況情報を他のプレイヤーに通知可能なシステム において、当該プレイヤーが当該通知を中止させることを容易に実現することができ る。 [0015] なお、上記各サーバ装置（3)において、前記公開用識別情報変更部（31, 31G) が変更する前記個人データ領域 (Tl, T2, T4)内の前記公開用識別情報と同一の 前記公開用識別情報を前記人間関連付けデータ領域 (T3)から削除する関連付け クリア部（31, 31H)を備えるようにしてもよい。これにより、変更された古い公開用識 別情報に基づいてプレイ状況情報を送信しょうとする処理が行われなくなる。つまり、 サーバ装置（3)にお 、て無駄な処理を削減することができる。
[0016] また、本発明に係るゲームシステムは、複数のプレイヤーにそれぞれ操作されうる 複数のゲーム装置の各々と通信するサーバ装置（3)と、前記サーバ装置と通信する 複数の端末装置 (4)とを有するゲームシステムであって、
前記サーバ装置 (3)は、
書き込まれた情報を記憶する個人データ領域 (Tl, T2, T4)と書き込まれた情報 を記憶する人間関連付けデータ領域 (T3)とを有する格納部 (33)と、
前記複数のプレイヤーの各々を識別するための非公開識別情報、前記複数のプレ ィヤーの各々を識別するための公開用識別情報、および 1つ以上の前記ゲーム装置
(1)でのプレイの結果を示すプレイ状況情報を、個々のプレイヤーの非公開用識別 情報と公開用識別情報とプレイ状況情報を対応付けて前記個人データ領域 (Tl, T 2, T4)に書き込む個人データ書き込み部と、
前記個人データ領域 (Tl, T2, T4)に公開用識別情報が書き込まれると、前記書 き込まれた公開用識別情報で識別されるプレイヤーに宛てて、前記書き込まれた公 開用識別情報を送信する自己公開用識別情報送信部（31, 31A, 32)と、
第 1のプレイヤーの公開用識別情報を第 2のプレイヤーに使用されている端末装置 (4)から受信すると、前記受け取った第 1のプレイヤーの公開用識別情報を前記第 2 のプレイヤーの非公開識別情報または公開用識別情報に対応付けて前記人間関連 付けデータ領域 (T3)に書き込む人間関連付けデータ書き込み部（31, 31C)と、 前記第 2のプレイヤーが使用して 、る前記端末装置 (4)へ、前記人間関連付けデ ータ領域 (T3)内で前記第 2のプレイヤーの前記非公開識別情報または前記公開用 識別情報に対応付けられている前記公開用識別情報で識別される前記第 1のプレイ ヤーについて前記個人データ領域 (Tl, T2, T4)に記憶されているプレイ状況情報 を示す情報を送信する友達プレイ履歴送信部（31, 31E, 31F, 32)と、
プレイヤーが使用している端末装置力 公開用識別情報の変更の要求を受信する と、前記プレイヤーについて前記個人データ領域 (Tl, T2, T4)に記憶されている 公開用識別情報を変更する公開用識別情報変更部 (31, 31G)とを備え、
前記複数の端末装置 (4)の各々は、
プレイヤーが他のプレイヤーの公開用識別情報を入力することができる友達公開 用識別情報入力部 (44)と、
前記友達公開用識別情報入力部 (44)に入力された前記公開用識別情報を前記 サーバ装置（3)へ送信する友達登録処理部 (41, 41A)と、
前記サーバ装置 (3)から前記端末装置 (4)に宛てて送信された情報を受信する受 信部 (46)と、
プレイヤーが前記プレイヤーの公開用識別情報の変更の指示を入力することがで きる自己公開用識別情報変更指示入力部 (44)と、
前記自己公開用識別情報変更指示入力部 (44)に前記指示が入力されると、前記 プレイヤーの公開用識別情報の変更の要求を前記サーバ装置へ送信する自己公開 用識別情報変更処理部 (41, 41E)とを備える。
このゲームシステムによれば、前述のサーバ装置（3)について述べた理由と同様の 理由により、プレイヤーのプレイ状況情報を他のプレイヤーに通知可能であるととも に、当該プレイヤーが当該通知を中止させることを容易に実現することができる。また 、このゲームシステムによれば、個人データ領域において公開用識別情報およびプ レイ状況情報を任意の領域に記憶させることができる。したがって、当該ゲームシス テムが提供可能なサービスの自由度が高くなる。また、このゲームシステムによれば、 プレイヤーのプレイ状況情報は他のプレイヤーの端末装置 (4)に受信される。したが つて、他のプレイヤ一はその端末装置 (4)を用いてプレイ状況情報を取り扱うことが できる。また、プレイヤ一は、自己の端末装置 (4)を用いて、 自己の公開用識別情報 の変更を行うことができる。つまり、プレイヤ一はその端末装置 (4)を用いて、 自己の プレイ状況情報の取り扱いを定めたり、自己以外のプレイヤーのプレイ状況情報を取 り扱ったりすることができる。 また、本発明に係る別のゲームシステムは、複数のプレイヤーにそれぞれ操作され うる複数のゲーム装置（1)と、前記複数のゲーム装置（1)の各々と通信するサーバ装 置（3)とを有するゲームシステムであって、
前記複数のゲーム装置（1)の各々は、
前記ゲーム装置（1)でプレイヤーがプレイする度に、ゲームのプレイの結果を示す プレイデータを生成するプレイデータ生成部（11)と、
前記ゲーム装置（1)でプレイするために使用されるプレイヤーの情報記録媒体（2) から、前記情報記録媒体 (2)を識別するために前記情報記録媒体 (2)に記録されて いる媒体識別情報を読み取る読み取り部（13)と、
前記ゲーム装置（1)でプレイヤーが前記プレイヤーの情報記録媒体（2)を用いて プレイする度に、前記生成されたプレイデータを、前記読み取られた前記媒体識別 情報と共に前記サーバ装置 (3)へ送信する送信部（11, 17)とを備え、
前記サーバ装置 (3)は、
書き込まれた情報を記憶する個人データ領域 (Tl, T2, T4)と書き込まれた情報 を記憶する人間関連付けデータ領域 (T3)とを有する格納部と、
前記複数の前記ゲーム装置（ 1)の 1つから前記媒体識別情報と共に前記プレイデ ータを受信する度に、受信した前記プレイデータに基づ 、てプレイヤーのプレイ状況 情報を生成するプレイ状況情報生成部（31)と、
前記媒体識別情報、前記プレイヤーの前記プレイ状況情報および前記プレイヤー を識別するための公開用識別情報を、互いに対応付けて前記個人データ領域 (T1 , T2, T4)に書き込む個人データ書き込み部（31, 31A, 31B)と、
前記個人データ領域 (Tl, T2, T4)に公開用識別情報が書き込まれると、前記書 き込まれた公開用識別情報で識別されるプレイヤーに宛てて、前記書き込まれた公 開用識別情報を送信する自己公開用識別情報送信部（31, 31A, 32)と、
第 1のプレイヤーの公開用識別情報を第 2のプレイヤ一力 受信すると、前記受け 取った第 1のプレイヤーの公開用識別情報を前記第 2のプレイヤーの情報記録媒体 (2)の媒体識別情報または前記第 2のプレイヤーの公開用識別情報に対応付けて 前記人間関連付けデータ領域 (T3)に書き込む人間関連付けデータ書き込み部 (3 1, 31G)と、
前記第 2のプレイヤーに宛てて、前記人間関連付けデータ領域 (T3)内で前記第 2 のプレイヤーの前記情報記録媒体 (2)の前記媒体識別情報または前記第 2のプレイ ヤーの前記公開用識別情報に対応付けられている前記公開用識別情報で識別され る前記第 1のプレイヤーについて前記個人データ領域 (Tl, T2, T4)に記憶されて いるプレイ状況情報を示す情報を送信する友達プレイ履歴送信部（31, 31E, 31F , 32)と、
プレイヤーから公開用識別情報の変更の要求を受けると、前記プレイヤーについ て前記個人データ領域 (Tl, T2, T4)に記憶されている公開用識別情報を変更す る公開用識別情報変更部 (31, 31G)とを備える。
このゲームシステムによれば、前述のサーバ装置（3)について述べた理由と同様の 理由により、プレイヤーのプレイ状況情報を他のプレイヤーに通知可能であるととも に、当該プレイヤーが当該通知を中止させることを容易に実現することができる。また 、このゲームシステムによれば、個人データ領域において公開用識別情報およびプ レイ状況情報を任意の領域に記憶させることができる。したがって、当該ゲームシス テムが提供可能なサービスの自由度が高くなる。また、このゲームシステムによれば、 ゲーム装置が、プレイヤーの情報記録媒体 (2)から媒体識別情報を読み取ってサー バ装置 (3)へ送信し、サーバ装置 (3)が、この媒体識別情報を受信して前述の非公 開識別情報として用いる。したがって、プレイヤーが非公開識別情報を手入力する必 要がない。
また、このゲームシステムでは、情報記録媒体 (2)として、自己の媒体識別情報を 書き換え困難に記録したものを用いることや、自己の媒体識別情報を肉眼で視認困 難な方式で記録したものを用いることもできる。これは、いわゆる「なりすまし」を防ぐた めに有益である。肉眼で視認困難な記録方式としては、例えば磁気記録方式が挙げ られる。なお、後述する本発明の実施形態の説明では、混乱を避けるために、サー バ装置および端末装置を有するものをゲームシステムとして捉えて 、るが、サーバ装 置および複数のゲーム装置を有するものもゲームシステムであることは前述の通りで ある。 また、上記各ゲームシステムにおいて、前記サーバ装置は、前記公開用識別情報 変更部（31, 31G)が変更する前記個人データ領域 (Tl, T2, T4)内の前記公開用 識別情報と同一の前記公開用識別情報を前記人間関連付けデータ領域 (T3)から 削除する関連付けクリア部（31, 31H)を備えるようにしてもよい。これにより、サーバ 装置（3)にお 、て無駄な処理を削減することができる。
発明の効果
[0018] 本発明によれば、ゲーム装置等の操作装置のユーザの操作に応じた内容の情報 を他のユーザに通知可能なシステムにおいて、当該ユーザが当該通知を中止させる ことを容易に実現することができる。
図面の簡単な説明
[0019] [図 1]本発明の第 1実施形態に係るゲームシステムを備えた通信システムを示すプロ ック図である。
[図 2]図 1の通信システムを構成するゲーム装置 1の外観を示す斜視図である。
[図 3]ゲーム装置 1の構成を示すブロック図である。
[図 4]ゲーム装置 1の表示領域 151に表示されるゲーム画面の一例を示す図である。
[図 5]図 1の通信システムのサーバ装置 3の構成を示すブロック図である。
[図 6]図 1の通信システムの携帯端末 4の外観を示す図である。
[図 7]携帯端末 4の構成を示すブロック図である。
[図 8]携帯端末 4において端末用プログラム Pが実行されているときの画面遷移を示 す図である。
[図 9]図 1の通信システムの機能、特にゲームシステムの機能を示す図である。
[図 10]図 1の通信システムの利用例における全体の動作の流れを示す図である。
[図 11]サーバ装置 3が行う更新反映処理の流れを示す図である。
[図 12]携帯端末 4で行われるプログラム処理の流れと当該プログラム処理に応じてサ ーバ装置 3で行われる初回処理の流れとを対応付けて示す図である。
[図 13]携帯端末 4が行う友達登録要求処理およびサーバ装置 3が行う友達登録処理 の流れを示す図である。
[図 14]携帯端末 4が行う長期プレイ履歴取得処理およびサーバ装置 3が行う長期プ レイ履歴応答処理の流れを示す図である。
[図 15]携帯端末 4が行うカレンダー画面 G1への遷移処理の流れを示す図である。
[図 16]携帯端末 4が表示するカレンダー画面 G1の一例を示す図である。
[図 17]図 16に示すカレンダー画面 G 1内の前月ボタンを押す操作が入力されたとき に表示されるカレンダー画面 G1の一例を示す図である。
[図 18]携帯端末 4が行う特定日プレイ履歴取得処理およびサーバ装置 3が行う特定 日プレイ履歴応答処理の流れを示す図である。
[図 19]携帯端末 4が表示する詳細画面 G7の一例を示す図である。
[図 20]携帯端末 4が行う公開用 ID変更要求処理およびサーバ装置 3が行う公開用 I
D変更処理の流れを示す図である。
[図 21]本発明の第 2実施形態におけるプログラム処理の流れと当該プログラム処理に 応じてサーバ装置 3で行われるプログラム対応処理の流れとを対応付けて示す図で ある。
[図 22]本発明の第 2実施形態において携帯端末 4が行う特定日プレイ履歴取得処理 の流れを示す図である。
発明を実施するための最良の形態
[0020] [第 1実施形態]
[構成]
図 1は、本発明の第 1実施形態に係るゲームシステムを備えた通信システムを示す ブロック図である。この通信システムは、多数のプレイヤーに所定のゲームをプレイさ せる一方、所定のゲームの腕前 (skill)に関するプレイヤーの成長を当該プレイヤー の友達のプレイヤーに知らせる通知サービスを提供するものであり、多数のゲーム装 置 1、多数のカード 2、および上記のゲームシステムを有する。上記ゲームシステムは 上記通知サービスを提供するものであり、サーバ装置 3および多数の携帯端末 (端末 装置) 4を有する。
[0021] ゲーム装置 1は、所定のゲームをプレイするプレイヤーに使用されて当該プレイヤ 一に所定のゲームを有償でプレイさせる操作装置であり、来訪者にゲーム装置 1を使 用させる店舗 (game arcade)内に 1または複数台ずつ設置されている。プレイヤ一は 、店舗においてゲーム装置 1を使用して所定のゲームをプレイすることによってゲー ム結果を得ることが可能であり、このゲーム装置 1は当該ゲーム結果を示すプレイデ ータを生成する。ゲーム結果とは 1回のプレイに対してゲーム装置 1が下した評価で あり、当該プレイの終了時点のスコアを含む。
[0022] カード 2は、情報を磁気的に記録する可搬型の情報記録媒体であり、自己のカード ID (媒体識別情報)を書き換え困難に記録している。カード IDはカード 2毎に相違す るユニークな情報であり、全てのカード 2の各々はカード IDにより識別可能である。力 ード IDは、ゲーム装置 1に読み取られたり、サーバ装置 3に収集されたりする力 その 不正使用を防ぐために、 、ずれの局面にお!、ても如何なるプレイヤーに対しても公 開されない。従って、カード IDは、カードひいてはカードを所持するプレイヤーを識 別する非公開 IDである。この実施の形態では、プレイヤ一はカードを所有する力 力 ードの代わりに他の記録媒体をプレイヤーが所有してもよ 、。
[0023] また、カード 2には複数の種類があり、それぞれ異なるゲームに用いられる。プレイ ヤーは複数種類のカード 2を所有することが可能である。ただし、この通信システムが 提供する全てのサービスを受けるためには、所定のゲーム用のカード 2を用いる必要 がある。よって、以降の説明では、特に断らない限り、「カード 2」は所定のゲーム用の カード 2を意味する。また、カード 2の使用状態は、ゲームシステムに未登録とゲーム システムに登録済みに大別される。ゲームシステムに登録済みのカード 2のカード ID は、サーバ装置 3により管理される。
[0024] サーバ装置 3は、多数のゲーム装置 1の各々力 プレイデータおよびカード IDを収 集して所定のゲームの腕前に関するデータを特定の携帯端末 4へ送信するコンビュ ータである。サーバ装置 3は 1台のコンピュータ力も構成されてもよいし、複数のコンビ ユータをネットワーク接続して構成されてもょ 、。サーバ装置 3と多数のゲーム装置 1 の各々とは、インターネット 5を介してデータ通信を行うことができる。
[0025] 携帯端末 4は、プレイヤーに所有され、サーバ装置 3からデータを受信して当該デ ータに応じた表示を行うコンピュータであり、データ通信および電話通信サービスを 提供する移動体通信網 6を基地局 61経由で使用可能な携帯電話機として機能する 。基地局 61は移動体通信網 6のサービスエリアをカバーするように分散して配置され ており、各基地局 61は自己のカバーするセル内の携帯端末 4と無線通信可能である 。携帯端末 4は自己の位置を含むセルをカバーする基地局 61と無線通信することに よって移動体通信網 6を使用する。なお、本実施形態を変形し、携帯端末 4に代えて 、携帯電話機として機能しないコンピュータを用いてもよいし、据え置き型のコンビュ ータを用いてもよい。
[0026] 移動体通信網 6は、ゲートウェイ 7を介してインターネット 5に接続されている。ゲート ウェイ 7は移動体通信網 6とインターネット 5の間で通信プロトコルを相互に変換する。 よって、サーバ装置 3と多数の携帯端末 4各々とは、移動体通信網 6およびインター ネット 5を介してデータ通信を行うことができる。
[0027] 図 2は通信システムを構成するゲーム装置 1の外観を示す斜視図であり、図 3はゲ ーム装置 1の構成を示すブロック図である。これらの図に示すように、ゲーム装置 1は 、プロセッサ 11、貯留部 12、カード読取部 13、操作部 14、表示部 15、スピーカ 16、 通信インターフェイス 17 (送信部）および格納部 18を有する。
[0028] 貯留部 12は、筐体 19に形成された投入口 121から投入されたコインを弁別し、所 定のコインであれば当該コインを貯留するとともに、当該コインが投入された旨の信 号をプロセッサ 11に供給する。なお、所定のコインとは、 1または複数枚で所定のゲ ームの 1回のプレイ料金に相当する価値を有するコインであり、例えば硬貨 (hard maney)である。カード読取部 13は、筐体 11に開口した揷入口 131を有し、この挿入 口 131からカード 2が挿入されると、このカード 2からカード IDを読み取り、このカード I Dを示す信号をプロセッサ 11に供給する。
[0029] 操作部 14は、所定のゲームのプレイにおいてプレイヤーに操作される 9個の操作 子 141を備え、いずれかの操作子 141が操作されると、この操作子 141に固有の信 号をプロセッサ 11に供給する。 9個の操作子 141のうちの所定の 1つは、所定のゲー ムのプレイを開始するためのスタートボタンを兼ねて 、る。表示部 15は表示領域 151 を有し、プロセッサ 11からの画像データを受けてゲーム画面を表示領域 151に表示 する。スピーカ 16はプロセッサ 11からの楽音信号を受けて放音する。通信インターフ ェイス 17はルータ等の中継装置を介して又は直接的にインターネット 5に接続されて おり、プロセッサ 11とインターネット 5との間でデータを中継する。 [0030] 格納部 18は、 ROM (Read Only Memory)等の不揮発性メモリと RAM (Random Access Memory)等の書き換え可能なメモリを有する。書き換え可能なメモリには、プ レイデータやカード ID等の可変のデータが書き込まれる。不揮発性メモリにはゲーム プログラム等の不変のデータが書き込まれて 、る。このゲームプログラムをプロセッサ 11が実行することによって、ゲーム装置 1は、揷入口 131に挿入されているカード 2 力 カード IDを読み取ったり、プレイヤーに所定のゲームをプレイさせるゲーム処理 を行ったり、後述の各種要求をサーバ装置 3へ送信したり、後述の各種応答をサー バ装置 3から受信したりする。ここで、所定のゲームの内容について説明する。
[0031] 図 4はゲーム装置 1の表示領域 151に表示されるゲーム画面の一例を示す図であ る。この図に示すように、ゲーム画面では、その中央部にゲーム領域 Rが確保されて いる。ゲーム領域 Rには、プレイヤ一により予め選択された楽曲に合わせて楕円形の オブジェクト OBが図中上方に現れて 9本の列のいずれかに沿って図中下方に落ち て消える様子が表示される。この際、楽曲が再生されてスピーカ 16から放音される。 オブジェクト OBが消える地点のわずかに上方には列に直交する水平ライン HLが存 在し、この水平ライン HLの下方には操作子 141を表す 9個の画像が 9本の列に対応 付けて配置されている。プレイヤ一は、この水平ライン HLにオブジェクト OBが重なつ たときに、このオブジェクト OBが位置する列に対応する画像で表される操作子 141を 操作するべきことがルールづけられている。この操作の精度が所定の範囲内であれ ば得点が付与される。
[0032] ゲーム画面の下側には、スコアおよびレベルメータ LMを示す画像が表示される。
スコアは 1回のプレイにおいて付与された得点の積算値であり、当該プレイの進行に ともなって増加する。レベルメータ LMはプレイのレベルをその部分画像の長さで表し ている。このレベルは、 1回のプレイにおける現時点までのプレイの質を示す値であり 、 1回のプレイにおいて現時点までに行われた上記の操作の質の統計値である。操 作の質は、当該操作が高い精度で行われると高くなり、当該操作が低い精度で行わ れると低くなる。
[0033] 楽曲の再生が終了すると、 1回のプレイが終了し、プレイヤ一はゲーム結果を得る。
ゲーム結果には、当該プレイの終了時点でのスコアである当該プレイのスコアのみな らず、当該プレイでのクリア報奨メダル（clearing reward medal)の付与結果が含まれ る。クリア報奨メダルは、所定のゲームをクリアしたプレイヤーに付与される仮想的な 報奨であり、最善の「パーフェクト」と次善の「ノーバッド」の 2種類がある。クリア報奨メ ダルの付与結果には 3つのパターンがある。 1つ目はクリア報奨メダルが付与されな 力つたパターン、 2つ目はノーバッドのクリア報奨メダルが付与されたパターン、 3つ目 はパーフェクトのクリア報奨メダルが付与されたパターンである。 V、ずれのパターンと なるかは、当該プレイの終了時点でのレベルに応じて定まる。なお、クリア報奨メダル の付与は、賞品としての有体物の払い出しを伴ってもよい。
[0034] 図 5は通信システムを構成するサーバ装置 3の構成を示すブロック図である。この図 に示すように、サーバ装置 3は、プロセッサ 31、通信インターフェイス 32 (プレイデー タ受信部、友達登録要求受信部、長期プレイ履歴要求受信部、特定日プレイ履歴要 求受信部)及び格納部 33 (サーバ内格納部）を備える。通信インターフェイス 32はル ータ等の中継装置を介して又は直接的にインターネット 5に接続されており、プロセッ サ 31とインターネット 5との間でデータを中継する。図示を略すが、格納部 33は、 IPL (Initial Program Loader)が書き込まれている ROM、ワークエリアとして用いられる R AM、およびハードディスクを有する。
[0035] ハードディスクには最新プレイデータテーブル T1 (個人データ領域）、公開用 IDテ 一ブル T2 (個人データ領域）、人間関連付けテーブル T3 (人間関連付けデータ領 域)、端末供給用プレイデータテーブル T4 (個人データ領域)が確保されている。ま た、ハードディスクには携帯端末 4にインストールされて、携帯端末 4において実行可 能な端末用プログラム Ρが記憶されている。端末用プログラム Ρは、所定のゲームの 腕前に関するプレイヤーの成長を当該プレイヤーの友人に知らせる装置として携帯 端末 4を機能させるためのプログラム (プログラム製品）である。また、ハードディスクに は図示せぬ管理プログラムが記憶されており、プロセッサ 31は IPLを実行することに より当該管理プログラムの実行を開始する。この管理プログラムをプロセッサ 31が実 行することにより、サーバ装置 3には図 9に示す各部を含む機能部が仮想的に生成さ れる。
[0036] 図 6は通信システムを構成する携帯端末 4の外観を示す図であり、図 7は携帯端末 4の構成を示すブロック図である。これらの図に示すように、携帯端末 4は、プロセッサ 41 (記憶管理部）、マイク 42、スピーカ 43、操作部 44、表示部 45、無線通信インター フ イス 46 (受信部、端末内受信部）および格納部 47 (端末内格納部）を有する。
[0037] マイク 42は通話時に使用され、使用者の音声に応じた信号をプロセッサ 41に供給 する。スピーカ 43は通話時に使用され、プロセッサ 41からの音声信号を受けて放音 する。操作部 44は使用者に操作される複数のキーを備え、キーが押されると、押され たキーに固有の信号をプロセッサ 41に供給する。表示部 45は表示領域 451を有し、 プロセッサ 11からの画像データを受けて当該画像データに応じた画面を表示領域 4 51に表示する。無線通信インターフェイス 46はアンテナ 461を備え、プロセッサ 41と 基地局 61との間でデータを中継する。無線通信インターフェイス 46と基地局 61との 間の通信路は無線通信路である。
[0038] 格納部 47は RAM、 ROMおよび EEPROM (Electrically Erasable Programmable
ROM)を有する。 ROMには携帯端末 4のオペレーティングシステムが格納されてお り、携帯端末 4の起動時に実行される。このオペレーティングシステムはプログラムで あり、プロセッサ 41に、電話通信機能やデータ通信機能、他のプログラムをダウン口 ードする機能、ダウンロードしたプログラムを実行する機能などを持たせる。この機能 によってプロセッサ 41が前述の端末用プログラム Pを実行することにより、携帯端末 4 には図 9に示す各部を含む機能部が仮想的に形成される。
[0039] EEPROMにはダウンロードしたプログラムを記憶するためのプログラム領域 471と この領域に対応したデータ領域 472が確保される。プログラム領域 471に記憶されて いるプログラムを実行中のプロセッサ 41は、データ領域 472にアクセスすることができ る。また、格納部 47には携帯端末 4に固有の端末識別子を記憶するための端末識 別子領域 473が確保されている。端末識別子は、多数の携帯端末 4の各々を識別可 能な情報であり、そのような情報としては、例えば携帯端末 4の電話番号を挙げること ができる。
[0040] 図 8は、携帯端末 4において端末用プログラム Pが実行されているときの画面遷移を 示す図である。この図に示すように、表示領域 451に表示される画面には、当該画面 内を移動するカーソルやユーザによってソフトウェアを介して押されるボタン等の操作 可能なオブジェクトの画像が含まれ得る。このため、操作部 44が備える複数のキーに は、カーソルを移動させるための移動キー 441や画面内のボタンをユーザがソフトゥ エアを介して押すための決定キー 442が含まれて!/、る。
[0041] [機能]
図 9は、通信システムの機能、特にゲームシステムの機能を示す図である。この図 に示すように、サーバ装置 3のプロセッサ 31は、カード登録部 31 A、プレイデータ更 新部 31B、友達登録部 31C、更新反映部 31D (端末供給用データ記録部）、長期プ レイ履歴応答部 31E (友達プレイ履歴送信部）、特定日プレイ履歴応答部 31F (友達 プレイ履歴送信部）、公開用 ID変更部 31G、および関連付けクリア部 31Hとして機 能する。これらの機能はサーバ装置 3の機能でもあるから、以降の説明では、プロセ ッサ 31ではなくサーバ装置 3を便宜的に動作の主体とする。一方、携帯端末 4のプロ セッサ 41は、友達登録処理部 41A、長期プレイ履歴取得部 41B、制御部 41C、特 定日プレイ履歴取得部 41D、および公開用 ID変更処理部 41Eとして機能する。これ らの機能は携帯端末 4の機能でもあるから、以降の説明では、プロセッサ 41ではなく 携帯端末 4を便宜的に動作の主体とする。これらの機能およびゲーム装置 1の機能 について、通信システムの利用例に即して説明する。
[0042] lj用例]
図 10は通信システムの利用例における全体の動作の流れを示す図である。この図 に示すように、あるプレイヤー（以降、「プレイヤー A」）が、 自身が所有しているゲーム システムに未登録のカード 2を用いて、あるゲーム装置 1で所定のゲームをプレイした とする。このプレイは、プレイヤー Aが当該カード 2を当該ゲーム装置 1の揷入口 131 に挿入し、当該ゲーム装置 1が当該カード 2からカード ID (例えば「00000001」）を 読み取り、当該カード 2の使用状態 (ゲームシステムに登録済み力否力 を確認し、プ レイヤー Aが投入口 121から十分な価値のコインを投入し、スタートボタンを操作し、 この操作を契機として当該ゲーム装置 1がゲーム処理を開始することにより始まる。
[0043] このゲーム処理が終わると、このゲーム装置 1のプロセッサ 11は、まず、プレイデー タ生成部として機能し当該プレイで得られたゲーム結果を示すプレイデータを生成す る一方、プレイヤー Aに自己のプレイヤー IDと当該カード 2の名前を入力させる。次 に、プロセッサ 11は送信部として機能し、通信インターフェイス 17 (送信部）を介して 、このカード 2の登録と当該カード 2に係る最新プレイデータ (後述する）の更新を要 求するメッセージであるカード登録要求 mlをサーバ装置 3へ送信する。カード登録 要求 mlは、入力されたプレイヤー ID、読み取ったカード ID、入力された名前を示す 名前データ、および生成したプレイデータを含む。
[0044] プレイヤー IDは、プレイヤー毎に相違する情報であり、この通信システムを使用し 得る全てのプレイヤーに予め付与されてサーバ装置 3に管理されて 、る。プレイヤー IDの書き換えは困難である。プレイヤー IDは、ゲーム装置 1に入力されたり、サーバ 装置 3に管理されたり、携帯端末 4に入力されたりするが、その不正使用を防ぐため に、いずれの局面においても、あるプレイヤーのプレイヤー IDは当該プレイヤー以外 のプレイヤーに対して公開されることはない。
[0045] サーバ装置 3は、通信インターフェイス 32 (プレイデータ受信部）がカード登録要求 mlを受信すると、まず、カード登録部 31A (個人データ書き込み部）として機能し、 当該カード 2を登録する。具体的には、カード登録要求 ml内のカード IDをカード登 録要求 ml内のプレイヤー IDに対応付けて格納部 33に記憶させる。その一方では、 公開用 ID (公開用識別情報)を生成し、この公開用 IDと当該カード IDとカード登録 要求 ml内の名前データとを相互に対応付けて公開用 IDテーブル T2に格納する。 公開用 IDテーブル T2はカード ID毎に公開用 IDおよび名前データを格納するもの である。その一方では、最新プレイデータテーブル T1に新しいレコードを追加し、こ のレコードの所定のフィールドに、カード登録要求 ml内のカード IDを格納する。最 新プレイデータテーブル T1はカード ID毎に最新プレイデータを格納するものである 。こうして、このカード 2がゲームシステムに登録済みとなる。
[0046] ゲームシステムに登録済みのカード 2に記録されているカード IDは、サーバ装置 3 において、多数のプレイヤーの各々を識別するための識別情報として使用可能とな る。また、公開用 IDは、登録済みのカード 2に記録されているカード IDと同様、サー バ装置 3において、多数のプレイヤーの各々を識別するための識別情報として使用 可能な情報である。
[0047] 最新プレイデータテーブル T1のレコードには最新プレイデータ用のフィールドがあ る。最新プレイデータ (プレイ状況情報）は、 1つ以上のゲーム装置 1でのプレイヤー のプレイの結果、すなわち所定のゲームの腕前を示すものであり、過去に得られたプ レイのスコアの最高値であるハイスコアを示すデータや、クリア報奨メダルの取得状況 を示すデータ、プレイした回数であるプレイ回数を示すデータを含み、最新プレイデ ータ用のフィールドは、これらのデータ用の小フィールドに分かれている。なお、クリア 報奨メダルの取得状況とは、過去に得られたクリア報奨メダルの付与結果のうちの最 善のものである。
[0048] 次にサーバ装置 3は、カード登録部 31Aの一部であるプレイデータ更新部 31Bとし て機能し、カード登録要求 mlに基づいて、最新プレイデータの更新処理を行う。こ の更新処理では、カード登録要求 ml内のカード IDに対応する最新プレイデータが 更新される。まずサーバ装置 3は、プレイ状況情報生成部として機能し、カード登録 要求 ml内のプレイデータに基づ 、て最新プレイデータ (プレイ状況情報）を生成す る。ここでいう「生成」は、カード登録要求 ml内のプレイデータの内容をそのまま最新 プレイデータとすることも含む。そして、プレイデータ更新部 31Bは、最新プレイデー タテーブル T1内のカード IDに対応する最新プレイデータを書き込む。カード登録要 求 mlに基づく更新では、最新プレイデータが、小フィールド毎に書き換えられる。つ まり現在書き込まれて 、な 、ノヽイスコアを示す小フィールド、およびクリア報奨メダル の取得状況を示す小フィールドに、カード登録要求 ml内のプレイデータの内容が書 き込まれ、プレイ回数を示す小フィールドには 1が書き込まれる。
[0049] 次に、サーバ装置 3は、カード登録部 31A (自己公開用識別情報送信部）として機 能し、通信インターフェイス 32 (自己公開用識別情報送信部）を介して、当該カード 2 の登録が完了した旨および当該カード 2に係る最新プレイデータの更新を完了した 旨のメッセージであるカード登録応答 m2を返信する。カード登録応答 m2には、当該 当該カード 2に記録されているカード IDに対応する公開用 IDが含まれている。次に サーバ装置 3は、更新反映部 31Dとして機能し、最新プレイデータの更新内容を後 に詳述する端末供給用プレイデータテーブル T4に反映させる更新反映処理を行う。
[0050] 図 11はサーバ装置 3が行う更新反映処理の流れを示す図である。この図に示すよ うに、サーバ装置 3は、更新反映処理において、まず、当該カード IDまたは当該カー ド IDに対応する公開用 IDが人間関連付けテーブル T3に格納されているか否かを判 定する (ステップ Sal)。人間関連付けテーブル T3は、第 1のプレイヤーが所有する 登録済みのカード 2のカード IDと、当該第 1のプレイヤーに指定された 1人または 2人 の第 2のプレイヤーが所有する登録済みのカード 2のカード IDに対応する公開用 ID とを対応付けて格納するものである。但し、人間関連付けテーブル T3には、第 1のプ レイヤーの公開用識別情報と、第 1のプレイヤーに指定された 1人または 2人の第 2の プレイヤーの公開用識別情報とを互いに対応付けて格納してもよい。カード 2の登録 が完了した直後の段階では、ステップ Salの判定結果が否定的となり、何の工程も行 わずに更新反映処理が終了する。
[0051] 一方、カード登録応答 m2を受信すると、ゲーム装置 1は、当該カード 2の登録が完 了した旨とカード登録応答 m2内の公開用 IDを表す画像を表示する。これにより、プ レイヤー Aは当該カード 2に対応する公開用 IDを知ることができる。したがって、以降 、プレイヤー Aは、この公開用 IDを友達のプレイヤーに知らせることができる。なお、 詳しくは後述するが、プレイヤー Aは、この公開用 IDを後の段階で携帯端末 4を用い て知ることができる。したがって、本実施形態を変形し、カード登録応答 m2にこの公 開用 IDが含まれておらず、この公開用 IDを表す画像をゲーム装置 1が表示しない、 という形態としても、プレイヤー Aが、この公開用 IDを友達のプレイヤーに知らせるこ とができることに変わりはない。
[0052] 上述した動作は、プレイヤー Aの友達であるプレイヤー Bが任意のゲーム装置 1で 所有して!/、る未登録のカード 2を用いて所定のゲームをプレイしたときや、プレイヤー Aの友達であるプレイヤー Cが任意のゲーム装置 1で所有している未登録のカード 2 を用いて所定のゲームをプレイしたときにも行われる。この結果、図 9に示すように、 最新プレイデータテーブル T1には、プレイヤー A〜Cの各々が所有している計 3枚 のカード 2に応じた 3つのレコードが作成される。
[0053] 一方、プレイヤー Aは、所有して!/、る携帯端末 4に端末用プログラム Pをインスト一 ルする。具体的には、この携帯端末 4を操作することにより、端末用プログラム Pをサ ーバ装置 3から当該携帯端末 4へ送信させて格納部 47に記憶させる。この際、図 10 に示すように、この携帯端末 4は、プレイヤー Aの操作に応じて、端末用プログラム P の送信を要求するメッセージであるプログラム送信要求をサーバ装置 3へ送信する。 このプログラム送信要求は、プレイヤー Aにより入力されたプレイヤー Aのプレイヤー I Dと格納部 47の端末識別子領域 473内の端末識別子とを含む。このプログラム送信 要求を受信すると、サーバ装置 3 (自己公開用識別情報送信部）は、通信インターフ ェイス 32 (自己公開用識別情報送信部）を介して、このプログラム送信要求内のプレ ィヤー IDに対応する全てのカード ID (このプレイヤーが所持するすべてのカードの力 -KID)に対応する公開用 IDおよび名前データの組のリストであるカードリストを返信 する。このリストには、所定のゲーム以外のゲーム用のカードに対応する公開用 IDも 含まれている。
[0054] このカードリストを受信すると、携帯端末 4は、カードリスト内の組を一覧表示し、所 定のゲーム用のカードに対応する組、すなわちカード 2に対応する組の選択をプレイ ヤー Aに促す。これにより、プレイヤー Aは自己のカード 2に対応する公開用 IDを知 ることができる。そして、プレイヤー Aが当該携帯端末 4を操作してカード 2に対応す る組を選択すると、当該組内の公開用 IDを含む選択指示をサーバ装置 3へ送信す る。この選択指示を受信すると、サーバ装置 3は、この選択指示内の公開用 IDに対 応するカード IDと当該プログラム送信要求内のプレイヤー IDおよび端末識別子とを 相互に対応付けて記憶し、端末用プログラム Pおよび当該プレイヤー IDを含むプロ グラム送信応答を返信する。なお、本実施形態を変形し、カードリスト内の組に、ゲー ムの名前を示すデータを含ませてもょ 、。
[0055] このプログラム送信応答を受信すると、携帯端末 4は、このプログラム送信応答内の 端末用プログラム Pを格納部 47のプログラム領域 471に格納する一方、このプロダラ ム領域 471に対応するデータ領域 472に、後述のカレンダーデータ等のデータを格 納するためのカレンダー領域 C、およびプレイヤー IDを格納するためのプレイヤー I D領域 Uを確保し、このプレイヤー ID領域 Uに当該プログラム送信応答内のプレイヤ 一 IDを格納する。
[0056] 端末用プログラム Pのインストール後、プレイヤー Aが所定の操作を行う度に、携帯 端末 4のプロセッサ 41は、プログラム領域 471から端末用プログラム Pを読み出して 実行する。この実行により携帯端末 4が行う処理をプログラム処理と呼ぶ。端末用プロ グラム Pの実行が初回の場合、これに応じて、サーバ装置 3は初回処理を行う。また、 サーバ装置 3は、プログラム処理を行っている携帯端末 4から要求を受信すると、この 要求に応じた要求対応処理を行う。初回処理および要求対応処理の内容について は後に詳述する。
[0057] 今、サーバ装置 3は、初回処理において、人間関連付けテーブル T3にレコードを 追力！]し、当該レコードのカード IDのフィールドにプレイヤー Aが所有する登録済みの カード 2のカード IDを格納するものと想定する。その一方、要求対応処理において、 サーバ装置 3は、友達登録部 31C (人間関連付けデータ書き込み部）として機能し、 当該レコードのカード IDのフィールドにプレイヤー Aが所有する登録済みのカード 2 のカード IDを格納し、第 1友達のフィールドにプレイヤー Bが所有しているカード 2に 記録されているカード IDに対応する公開用 IDを格納し、第 2友達のフィールドにプレ ィヤー Cが所有して 、るカード 2に記録されて 、るカード IDに対応する公開用 IDを格 納するものと想定する。この前提として、プレイヤー Aはプレイヤー Bおよびプレイヤ 一 Cから各々の公開用 IDを知らされて 、る。
[0058] 次に、プレイヤー Bが自身が所有しているゲームシステムに登録済みのカード 2を 用いてゲーム装置 1で所定のゲームをプレイしたと想定する。このプレイが終わると、 このゲーム装置 1のプロセッサ 11は送信部として機能し、通信インターフェイス 17 (送 信部）を介して、最新プレイデータの更新を要求するメッセージである更新要求 m3を サーバ装置 3へ送信する。更新要求 m3は、当該プレイについて生成されたプレイデ ータと当該カード IDとを含む。次にサーバ装置 3は、通信インターフェイス 32 (プレイ データ受信部）が更新要求 m3を受信すると、プレイデータ更新部 31B (個人データ 書き込み部）として機能し、更新要求 m3に基づいて最新プレイデータの更新処理を 行う。まずサーバ装置 3のプロセッサ 31は、プレイ状況情報生成部として機能し、更 新要求 m3内のプレイデータに基づ 、て最新プレイデータ (プレイ状況情報）を生成 する。ここでいう「生成」は、カード登録要求 ml内のプレイデータをそのまま最新プレ ィデータとすることも含む。そして、プレイデータ更新部 31Bは、最新プレイデータテ 一ブル T1内のカード IDに対応する最新プレイデータを書き込む。これにより、当該 カード 2に記録されているカード IDに対応する最新プレイデータが最新のものとなる 。更新要求 m3に基づく更新では、最新プレイデータが、小フィールド毎に書き換えら れる。また、書き換えを行うか否かは、小フィールド毎に予め定められた条件に従って 定まる。この「条件」は無条件を含む概念である。
[0059] 例えば、ハイスコアを示すデータ用の小フィールド内のデータが書き換えられるの は、現在の当該データが示すノ、イスコアを当該更新要求内のプレイデータが示すプ レイのスコアが上回っている場合のみであり、この場合には、当該更新要求内のプレ ィのスコアを示すように当該小フィールド内のデータが書き換えられる。また例えば、 クリア報奨メダルの取得状況を示すデータ用の小フィールド内のデータが書き換えら れるのは、現在の当該データが示すクリア報奨メダルの取得状況よりも当該更新要 求内のプレイデータが示す付与結果の方が良い場合のみであり、この場合には、当 該更新要求内の付与結果を示すように当該小フィールドのデータが書き換えられる。 また例えば、プレイ回数を示すデータ用の小フィールド内のデータは、最新プレイデ ータの更新処理において必ず書き換えられる。この書き換えは、当該データが示す プレイ回数が 1だけ増えるように行われる。
[0060] なお、この更新処理において、更新される最新プレイデータは更新要求 m3内の力 ード IDに対応したものであり、返信される応答は当該カード 2に係る最新プレイデー タの更新を完了した旨のメッセージである更新応答 m4である。ところで、このように更 新される最新プレイデータを通知サービス以外のサービスに用いるシステムが現に 存在する。つまり、本実施形態に係る通信システムは既存のシステムと親和性が高く 、既存のシステムに機能を追加する形で本実施形態を得ることも可能である。
[0061] 最新プレイデータの更新処理を終えると、サーバ装置 3は、更新反映部 31Dとして 機能し、図 11の更新反映処理を行う。上記の初回処理が実行済みの場合、当該力 ード IDまたは当該カード IDに対応する公開用 IDが人間関連付けテーブル T3に格 納されている力否かの判定 (ステップ Sal)の結果は肯定的となる。よって、サーバ装 置 3は、当該カード IDに対応する最新プレイデータを端末供給用プレイデータテー ブル T4に反映する反映処理を行い (ステップ Sa2)、更新反映処理を終える。
[0062] 端末供給用プレイデータテーブル T4は、人間関連付けテーブル T3にカード IDま たは公開用 IDが格納されているカード 2を所有するプレイヤーの所定のゲームの腕 前に関する成長を記録するためのものであり、当該カード 2のカード IDと、当該カード 2を所有するプレイヤーの所定のゲームの腕前を示す端末供給用プレイデータと、当 該端末供給用プレイデータを得るために当該プレイヤーが所定のゲームをプレイし た日の日付を示す日付データとが対応付けて格納される。端末供給用プレイデータ は最新プレイデータのサブセットであり、ハイスコアを示すデータや、クリア報奨メダル の取得状況を示すデータ、プレイ回数を示すデータ等を含み、携帯端末 4からの要 求に応じて、携帯端末 4に供給されうる。図 9に示すように、最新プレイデータテープ ル T1内の最新プレイデータでは、各カード IDにっき 1つのレコードが設けられており 、 日付データは対応づけられていないが、端末供給用プレイデータテーブル T4内の 端末供給用プレイデータでは、各カード IDにっき 1つ以上のレコードが設けられてお り、それらのレコードに日付データが対応づけられている。従って、端末供給用プレイ データテーブル T4内の端末供給用プレイデータには、各カード IDに応じたプレイヤ 一の腕前の成長が記録されて 、る。
[0063] 上記の反映処理 (ステップ Sa2)では、具体的には、まず、最新プレイデータに基づ いて（つまりカード登録要求 mlまたは更新要求 m3内のプレイデータに基づいて）、 プレイヤーの腕前を示す端末供給用プレイデータを生成する。ここでいう「生成」は、 最新プレイデータの内容をそのまま端末供給用プレイデータとすることも含む。そし て、端末供給用プレイデータテーブル T4にレコードを追カ卩し、このレコードに、当該 カード IDと当該カード IDに対応する最新プレイデータに基づいて得られる端末供給 用プレイデータと現在の日付を示す日付データとを対応付けて格納する。
[0064] 以上より明らかなように、本実施形態では、サーバ装置 3がゲーム装置 1から更新要 求を受信する度に、最新プレイデータの更新処理が行われ、さらに当該更新要求内 のカード IDまたは当該カード IDに対応する公開用 IDが人間関連付けテーブル T3 に格納されて ヽる場合には、更新反映処理が行われて端末供給用プレイデータテー ブル T4が更新される。
[0065] 今、最新プレイデータの更新処理が繰り返し行われた後に、プレイヤー Aが所定の 操作を行 、、携帯端末 4で端末用プログラム Pが実行されてプログラム処理が行われ たと想定する。この実行が 2回目であれば、サーバ装置 3において初回処理が行わ れることはない。このプログラム処理に応じてサーバ装置 3で行われ得るのは、携帯 端末 4からの要求に応じた要求対応処理のみである。これらの処理において、プレイ ヤー Aが所有する携帯端末 4へ、プレイヤー Bおよびプレイヤー Cに対応する端末供 給用プレイデータおよび日付データが送信されたり、この携帯端末 4において、プレ ィヤー Bが所定のゲームをプレイした日の日付や当該日付におけるプレイヤー Bの腕 前を表す画像が表示されたり、プレイヤー Cが所定のゲームをプレイした日の日付や 当該日付におけるプレイヤー Cの腕前を表す画像が表示されたりする。
[0066] [プログラム処理]
図 12は、携帯端末 4で行われるプログラム処理の流れと当該プログラム処理に応じ てサーバ装置 3で行われる初回処理の流れとを対応付けて示す図である。この図に 示すように、携帯端末 4は、プログラム処理において、まず、端末用プログラム Pの実 行が初回である力否かを判定する (ステップ Sbl)。この判定は、例えば、端末用プロ グラム Pのインストール直後の状態がオンで当該判定の後にはオフとなるフラグをデ ータ領域 472に確保しておくことにより実現可能である。この判定結果が肯定的な場 合、携帯端末 4は、人間関連付けテーブル T3へのレコードの追加を要求するメッセ ージであるレコード追加要求をサーバ装置 3へ送信する（ステップ Sb2)。このレコー ド追加要求は、プレイヤー ID領域 U内のプレイヤー IDと、端末識別子領域 473内の 端末識別子とを含む。
[0067] サーバ装置 3は、初回処理において、このレコード追カ卩要求を受信すると (ステップ Scl)、人間関連付けテーブル T3にレコードを追加し (ステップ Sc2)、このレコードの カード IDのフィールドに、当該レコード追加要求内のプレイヤー IDおよび端末識別 子に対応するカード IDを格納し (ステップ Sc3)、人間関連付けテーブル T3へのレコ 一ドの追カ卩が完了した旨のメッセージであるレコード追加応答を返信する (ステップ S c4)。このレコード追加応答には、当該カード IDに対応する公開用 IDおよび名前デ ータが含まれている。
[0068] 携帯端末 4は、このレコード追加応答を受信し、このレコード追加応答内の公開用 I Dおよび名前データをデータ領域 472に書き込む (ステップ Sb3)。次に、表示画面 を図 8におけるカレンダー画面 G1へ遷移させる（ステップ Sb4)。一方、端末用プログ ラム Pの実行が初回である力否かの判定結果が否定的な場合にも、表示画面を図 8 におけるカレンダー画面 G1へ遷移させる (ステップ Sb4)。なお、携帯端末 4が自己 の所有者であるプレイヤーについて公開用 IDおよび名前データをデータ領域 472 に書き込むのは、端末用プログラム Pのダウンロード時であってもよい。この場合、レ コード追加応答が公開用 IDおよび名前データを含む必要はない。
[0069] 次に携帯端末 4は、その所有者であるプレイヤーによる操作入力を待ち (ステップ S b5)、入力された操作が終了操作である力否かを判定し (ステップ Sb6)、この判定結 果が否定的であれば、当該操作に応じた内容の操作対応処理を行う（ステップ Sb7) 、という処理を繰り返す。この繰り返しは、終了操作が入力されると終了し、これによつ てプログラム処理が終了する。
[0070] 操作対応処理の内容は入力された操作に応じて異なり、表示画面をメニュー画面 G2へ遷移させるだけの場合もあれば、サーバ装置 3へ要求を送信してサーバ装置 3 から応答を受信する場合もある。後者の場合には、サーバ装置 3において、携帯端 末 4からの要求に応じた内容の要求対応処理が行われる。
[0071] 操作対応処理に応じた要求応答処理としては、友達登録要求処理に応じた友達登 録処理、長期プレイ履歴取得処理に応じた長期プレイ履歴応答処理、特定日プレイ 履歴取得処理に応じた特定日プレイ履歴応答処理、および公開用 ID変更要求処理 に応じた公開用 ID変更処理がある。以降、これらの処理およびカレンダー画面 G1へ の遷移処理について、具体的に説明する。
[0072] [友達登録]
図 13は、携帯端末 4が行う友達登録要求処理およびサーバ装置 3が行う友達登録 処理の流れを示す図である。携帯端末 4が友達登録要求処理を行うのは、図 8にお けるメニュー画面 G2内の友達登録ボタンを押す操作入力がなされたときである。友 達登録要求処理では、携帯端末 4は、まず、表示画面を、登録しょうとする友達の種 類 (第 1友達 Z第 2友達)の選択と、登録しょうとする友達の公開用 IDの入力と、登録 操作の入力とを促す登録開始画面 G3へ遷移させる (ステップ Sdl)。
[0073] 次に、当該携帯端末 4の所有者であるプレイヤー (第 2のプレイヤー）による操作部 44 (友達公開用識別情報入力部)での操作入力を待ち (ステップ Sd2)、入力された 操作を画面に反映させ (ステップ Sd3)、入力された操作が登録操作であるか否かを 判定し (ステップ Sd4)、この判定結果が否定的であれば、処理をステップ Sd2に戻す 、という処理を繰り返す。この繰り返しにおいて入力される他の操作としては、他のプ レイヤー (友達)の公開用 IDを入力する操作と、登録しょうとする友達の種類 (第 1友 達 Z第 2友達)を選択する操作がある。登録操作とは、登録開始画面 G3内の登録ボ タンを押す操作である。
[0074] この繰り返しは、登録操作が入力されると終了する。すると、携帯端末 4は、友達登 録処理部 41 Aとして機能し、友達の登録を要求するメッセージである友達登録要求 m5をサーバ装置 3へ送信し (ステップ Sd5)、表示画面を、登録中であることを表す 登録中画面 G4へ遷移させる (ステップ Sd6)。友達登録要求 m5は、選択された友達 の種類を示す友達選択フラグ、入力された友達 (第 1のプレイヤー）の公開用 ID、プ レイヤー ID領域 U内の所有者 (第 2のプレイヤー）のプレイヤー ID、および端末識別 子領域 473内の端末識別子を含む。
[0075] サーバ装置 3は、友達登録処理にお!、て、通信インターフェイス 32 (友達登録要求 受信部）を介して、友達登録要求 m3を受信すると (ステップ Sel)、友達登録部 31C として機能し、人間関連付けテーブル T3にお 、て友達登録要求 m5内のプレイヤー IDおよび端末識別子に対応するカード IDを格納しているレコードの、友達登録要求 m5内の友達選択フラグが示す種類の友達用のフィールドに、友達登録要求 m5内 の公開用 IDを格納する (ステップ Se2)。次に、サーバ装置 3は、友達登録部 31Cとし て機能し、当該公開用 IDに対応する名前データを公開用 IDテーブル T2から読み出 すことによって取得し (ステップ Se3)、この名前データを含み、友達の登録が完了し た旨のメッセージである友達登録応答 m6を返信する (ステップ Se4)。こうして、友達 登録処理が終了する。
[0076] 一方、携帯端末 4は、友達登録処理部 41Aとして機能し、友達登録応答 m6を受信 すると (ステップ Sd7)、友達登録応答 m6内の名前データと入力された公開用 IDと選 択された種類 (第 1友達 Z第 2友達)とを対応付けてカレンダー領域 Cに格納するとと もに、当該名前データを用いて、表示画面を登録完了画面 G5へ遷移させる (ステツ プ Sd8)。登録完了画面 G5には、選択された種類の友達として当該公開用 IDに対 応するカード 2を登録した旨を表す画像が含まれている。
[0077] 次に携帯端末 4は、操作入力を待ち (ステップ Sd9)、入力された操作が登録完了 画面 G5内のメニューボタンを押す操作、すなわちメニュー画面 G2への遷移操作で ある力否かを判定し (ステップ SdlO)、この判定結果が否定的であれば処理をステツ プ Sd9〖こ戻す、という処理を繰り返す。この繰り返しは、メニュー画面 G2への遷移操 作が入力されると終了する。すると、携帯端末 4は、表示画面をメニュー画面 G2へ遷 移させる (ステップ Sdl l)。こうして、友達登録要求処理が終了する。
[0078] [長期プレイ履歴取得]
図 14は、携帯端末 4が行う長期プレイ履歴取得処理およびサーバ装置 3が行う長 期プレイ履歴応答処理の流れを示す図である。長期プレイ履歴取得処理および長期 プレイ履歴取得処理では、携帯端末 4に、所定の短期間 (後述する第 2期間）内での その携帯端末 4の所有者およびその所有者の友達についての端末供給用プレイデ ータおよびプレイした日付に関する日付データが供給され、その携帯端末 4の所有 者は、自分および友達の成長を見ることができる。さらにまた、長期プレイ履歴取得 処理および長期プレイ履歴取得処理では、所定の長期間（後述する第 1期間）での その携帯端末 4の所有者およびその所有者の友達がプレイした日付に関する日付 データが携帯端末 4に供給され、その携帯端末 4の所有者は、その携帯端末 4の所 有者およびその所有者の友達がプレイした日付を見ることができる。
[0079] 携帯端末 4が長期プレイ履歴取得処理を行うのは、図 8におけるメニュー画面 G2内 の更新ボタンを押す操作入力がなされたときである。長期プレイ履歴取得処理では、 携帯端末 4は、まず、長期プレイ履歴取得部 41B (長期プレイ履歴要求送信部）とし て機能し、無線インターフェイス 46 (長期プレイ履歴要求送信部）を介して、後述する カレンダーデータの一括送信を要求するメッセージである長期プレイ履歴要求 m7を 送信する（ステップ Sfl)。長期プレイ履歴要求 m7は、プレイヤー ID領域 U内のプレ ィヤー IDと端末識別子領域 473内の端末識別子を含む。次に、携帯端末 4は長期 プレイ履歴取得部 41Bとして機能し、表示画面を、更新中であることを表す更新中画 面 G6に遷移させる（ステップ Sf 2)。
[0080] サーバ装置 3は、長期プレイ履歴応答処理にぉ 、て、通信インターフェイス 32 (長 期プレイ履歴要求受信部）によって長期プレイ履歴要求 m7を受信すると (ステップ S gl)、長期プレイ履歴応答部 31Eとして機能し、長期プレイ履歴要求 m7内のプレイ ヤー IDおよび端末識別子に対応するカード ID (携帯端末 4の所有者のカード ID)と 、当該カード IDに対応付けて人間関連付けテーブル T3に格納されて 、る公開用 ID に対応するカード ID (他のプレイヤーのカード ID)とを特定する一方、第 1期間およ び第 2期間からなる抽出対象期間を特定する (ステップ Sg2)。一括送信の対象となる のは、端末供給用プレイデータテーブル T4のレコードのうち、特定されたカード IDを 格納し、かつ、抽出対象期間内の日付を示す日付データを格納したレコード内のデ ータである。第 2期間は、現在日から所定の短期間 (例えば 30日）前までの期間であ る。第 1期間は、現在日から所定の長期間 (例えば 1年)前までの期間 (抽出対象期 間)から第 2期間を除いた期間である。
[0081] 次に、サーバ装置 3は、長期プレイ履歴応答部 31Eとして機能し、端末供給用プレ ィデータテーブル T4のレコードのうち、特定されたカード ID (携帯端末 4の所有者の カード IDおよび他のプレイヤーのカード ID)を格納し、かつ、抽出対象期間内の日 付を示す日付データを格納したレコードから、一括送信するカレンダーデータを抽出 し、抽出したデータのうちのカード IDを公開用 IDに変換する (ステップ Sg3)。この抽 出は期間別に行われる。すなわち、短く最近の第 2期間内の日付を示す日付データ を格納したレコードからは、カレンダーデータとして、当該レコードに格納されている カード ID (携帯端末 4の所有者のカード IDおよび他のプレイヤーのカード ID)、端末 供給用プレイデータおよび日付データが抽出され、より長くてより古い第 1期間内の 日付を示す日付データを格納したレコードからは、カレンダーデータとして、当該レコ ードに格納されているカード ID (携帯端末 4の所有者のカード IDおよび他のプレイヤ 一のカード ID)および日付データが抽出される。
[0082] 次に、サーバ装置 3は、長期プレイ履歴応答部 31Eとして機能し、より詳細には符 号ィ匕部として機能し、ステップ Sg3で得られたデータを符号化する (ステップ Sg4)。こ の符号ィ匕は、ある符号化ルールに従って元のビットパターンをより短 、ビットパターン で置換すること〖こより行われる。つまり、ステップ Sg3で得られたデータは、この符号 化によって圧縮される。なお、この圧縮が可能なのは、端末供給用プレイデータテー ブル T4内の端末供給用プレイデータ、ひ 、ては最新プレイデータテーブル T1内の 最新プレイデータのデータ形式が冗長だ力 である。これらのデータのデータ形式が 冗長なのは、既存のシステムとの親和性を確保するためである。したがって、既存の システムとの親和性を確保する必要がなければ、これらのデータのデータ形式を冗 長でな 、形式とし、上記の符号ィ匕を省略してもよ 、。
[0083] 次に、サーバ装置 3は、長期プレイ履歴応答部 31E (友達プレイ履歴送信部）として 機能し、通信インターフェイス 32 (友達プレイ履歴送信部）を介して、符号化されたデ ータを含む長期プレイ履歴応答 m8を返信する (ステップ Sg5)。長期プレイ履歴応答 m8に含まれる符号化されたデータは、 日付データを含んでいるので「カレンダーデ ータ」と呼ばれ、長期プレイ履歴応答 m8の返信がカレンダーデータの一括送信であ る。こうして、長期プレイ履歴応答処理が終了する。なお、長期プレイ履歴応答 m8内 のカレンダーデータにおいて、同一のレコードに由来するデータは、携帯端末 4にお いて 1組として扱われる。
[0084] 携帯端末 4は、長期プレイ履歴取得部 41Bとして機能し、長期プレイ履歴応答 m8 を受信すると (ステップ Sf 3)、長期プレイ履歴応答 m8内のカレンダーデータでカレン ダー領域 C内のカレンダーデータを更新する（ステップ Sf4)。これにより、カレンダー 領域 C内のカレンダーデータが最新となる。次に、携帯端末 4は、表示画面をメ-ュ 一画面 G2に遷移させる (ステップ Sf 5)。こうして、長期プレイ履歴取得処理が終了す る。
[0085] このように、本実施形態では、カレンダーデータの送信は、携帯端末 4がトリガを与 えるプル型 (pull type)の送信となる。したがって、携帯端末 4の使用者が必要と感じた ときにだけ、カレンダーデータを送信することができる。よって、無駄の少ない送信が 可能となり、通信負荷をより軽減することができる。
[0086] [カレンダー画面への遷移]
図 15は、携帯端末 4が行うカレンダー画面 G1への遷移処理の流れを示す図であ る。この遷移処理では、長期プレイ履歴取得処理および長期プレイ履歴応答処理で 携帯端末 4に供給されたデータに基づく情報をカレンダーとともに、その携帯端末 4 の所有者が見ることができる。 [0087] この遷移処理では、携帯端末 4は、復号部として機能し、まず、カレンダー領域じか らカレンダーデータを読み出し、これを前述のサーバ装置での符号化ルールに関連 した復号ルールに従って復号する（ステップ Shl)。この復号により、元の符号化デー タのビットパターンより長 、ビットパターンで置換されるので、カレンダーデータが伸長 される。次に、携帯端末 4は制御部 41Cとして機能し、復号後のカレンダーデータを 用いてカレンダー画面 G1を示す画像を生成し (ステップ Sh2)、この画像を表示する ことにより、表示画面をカレンダー画面 G1へ遷移させる（ステップ Sh3)。
[0088] 図 16は、携帯端末 4が表示するカレンダー画面 G1の一例を示す図である。この図 では、現在日を 2005年 3月 23日と仮定している。この図に示すように、カレンダ一画 面 G1には、表示対象の年月を表す文字列、現在時刻を表す文字列、当該月の日を 示す 28〜31個の数字がそれぞれ入った桥を整列した日付テーブル、選択された日 の所有者のプレイに関する詳細な情報をスクロール表示するためテキストボックス、メ ニュー画面 G2へ遷移するためのメニューボタン、プログラム処理を終了するための 終了ボタン、表示対象の年月を次の月とするための次月ボタン、表示対象の年月を 前の月とするための前月ボタン、 日付を選択したりメッセージをスクロール表示させた りボタンを押したりするためのカーソル、アイコンの凡例の領域が含まれている。また、 2005年 3月 23日（現在日）の日付に相当する桥が強調表示されている。なお、本実 施形態を変形し、カレンダー画面 G1の構成を変更してもよい。例えば、カレンダ一画 面 G1から上記のテキストボックスや上記の凡例の領域を除いてもよい。
[0089] アイコンには、携帯端末 4の所有者を示す円形のアイコンと、第 1友達を示す三角 形のアイコンと、第 2友達を示す四角形のアイコンがある。凡例は、カレンダー領域 C に格納されている公開用 IDおよび名前データに応じたものとなる。また、アイコンは、 カレンダー領域 C内の日付データが示す日付に相当する桥内に、当該日付データと 同じ組内の公開用 IDデータ毎に配置される。したがって、 1つの枠内には最高で 3つ のアイコンが配置される。
[0090] 図 17は、図 16に示すカレンダー画面 G1内の前月ボタンを押す操作が入力された ときに表示されるカレンダー画面 G1の一例を示す図である。この図においては、 20 05年 2月 21日と 2005年 2月 22日との間を境にして、桥の形態 (例えば色）が相違し ている。これは、前述の所定の短期間が 30日であり、かつ前述の所定の長期間が 1 年であり、かつ最後に長期プレイ履歴取得処理が行われた日が 2005年 3月 22日で ある、という前提条件があるからである。つまり、これらのカレンダー画面 G1において 、第 2期間は 2005年 2月 22日以降となっている。
[0091] また、図 16に示すカレンダー画面 G1では、 2005年 3月 19日の日付に相当する桥 にカーソルが位置している。この日付は第 2期間内の日の日付であり、かつ、この桥 には所有者のアイコンが配置されているから、テキストボックスには、この日の所有者 のプレイに関する詳細な情報 (腕前を表す画像）がスクロール表示される。一方、図 1 7では、カーソルが 2005年 2月 8日の日付に相当する桥にカーソルが位置している。 この桥には所有者のアイコンが配置されている力 この日付は第 2期間外の日の日 付であるから、テキストボックスには、この日の所有者のプレイに関する詳細な情報は 表示されない。カーソルの移動は移動キー 441 (図 6)により行うことができるので、移 動キー 441は、携帯端末 4の所有者が日付を指定することができる日付指定部であ る。
[0092] [特定日プレイ履歴取得]
図 18は、携帯端末 4が行う特定日プレイ履歴取得処理およびサーバ装置 3が行う 特定日プレイ履歴応答処理の流れを示す図である。特定日プレイ履歴応答処理で は、携帯端末 4に、ある日のその携帯端末 4の所有者およびその所有者の友達につ いての端末供給用プレイデータが供給される。特定日プレイ履歴取得処理では、そ の携帯端末 4の所有者は、自分および友達のその日のプレイの成績を見ることがで きる。より具体的には、長期プレイ履歴取得処理および長期プレイ履歴応答処理で 得られた所定の短期間 (第 2期間）内での端末供給用プレイデータに応じた情報は、 特定日プレイ履歴取得処理で、直ちに携帯端末 4で表示される。また。長期プレイ履 歴取得処理および長期プレイ履歴応答処理で、 日付データは得られても日付データ に対応する端末供給用プレイデータが得られな力つた長くて古い第 1期間内のプレ ィ履歴については、特定日プレイ履歴取得処理で、携帯端末 4はサーバ装置 3にそ の端末供給用プレイデータを要求し、特定日プレイ履歴応答処理によってサーバ装 置 3からその端末供給用プレイデータが携帯端末 4に供給される。 [0093] 携帯端末 4が特定日プレイ履歴取得処理を行うのは、図 8におけるカレンダー画面 G1内のアイコンが配置されている桥にカーソルが位置しているときに所定の操作入 力がなされたとき、すなわち適切な日付が入力されたときである。特定日プレイ履歴 取得処理では、携帯端末 4は、まず、制御部 41Cとして機能し、当該桥に相当する日 の日付が上記の第 2期間内の日付である力否かを判定する (ステップ ¾1)。ここでは 、まず、この時点におけるカレンダー画面 G1が図 16に示す通りであり、上記の判定 結果が肯定的となるものと仮定する。すると、携帯端末 4は、制御部 41Cとして機能し 、表示画面を詳細画面 G7へ遷移させる (ステップ ¾4)。
[0094] 図 19は、携帯端末 4が表示する詳細画面 G7の一例を示す図であり、図 16に示す カレンダー画面 G1に対応している。この図に示すように、詳細画面 G7は、 2005年 3 月 19日の日付を示す日付データと同じ組内の端末供給用プレイデータに応じた画 像を含む。つまり、携帯端末 4には、 2005年 3月 19日時点での所定のゲームの腕前 を表す情報が、所有者 (Mimi)および登録された友達 (Bob、 Nick)のうちの当該日 に所定のゲームをプレイしたプレイヤーにつ 、て表示されることになる。図 16に示す ように、 2005年 3月 19日（第 2期間内）に相当する桥には全員のアイコンが配置され ているから、図 19に示す詳細画面 G7では、 3人分の腕前を示す情報が表示される。 なお、本実施形態を変形し、詳細画面 G7を、腕前を示す情報を 1人ずつ切り替えて 表示する画面としてもよい。つまり、複数人のアイコンが配置されている桥の日付が 入力されると、 1人分の腕前を示す情報を表示し、特定のキー (例えば、左方向へ力 一ソルを移動させるための左キーや、右方向へカーソルを移動させるための右キー 等）が操作されると、表示中の情報で腕前が示されるプレイヤーとは別のプレイヤー の腕前を示す情報が表示されるようにしてもょ ヽ。
[0095] 次に携帯端末 4は、制御部 41Cとして機能し、操作入力を待ち (ステップ ¾5)、入 力された操作が詳細画面 G7内の戻るボタンを押す操作、すなわちカレンダー画面 G 1への遷移操作である力否かを判定し (ステップ ¾6)、この判定結果が否定的であれ ば処理をステップ Sj 5に戻す、という処理を繰り返す。この繰り返しは、カレンダ一画 面 G1への遷移操作が入力されると終了する。すると、携帯端末 4は、制御部 41Cとし て機能し、表示画面をカレンダー画面 G1へ遷移させる (ステップ ¾7)。こうして、特 定日プレイ履歴取得処理が終了する。
[0096] 一方、ステップ Sj lでの判定の時点におけるカレンダー画面 G1が図 17に示す通り であり、上記の判定結果が否定的となると、携帯端末 4は、特定日プレイ履歴取得部 41D (特定日プレイ履歴要求送信部）として機能し、無線インターフェイス 46 (特定日 プレイ履歴要求送信部）を介して、カーソルが位置する桥に相当する日付（図 17で は第 1期間内の 2005年 2月 8日）の 1日分の端末供給用プレイデータの送信を要求 するメッセージである特定日プレイ履歴要求 ml 1を送信する（¾2)。特定日プレイ履 歴要求 mi lは、プレイヤー ID領域 U内のプレイヤー IDと、端末識別子領域 473内 の端末識別子と、当該日付を示す日付データとを含む。
[0097] サーバ装置 3は、特定日プレイ履歴応答処理にお!、て、通信インターフェイス 32 ( 特定日プレイ履歴要求受信部）によって特定日プレイ履歴要求 ml 1を受信すると (ス テツプ Ski)、特定日プレイ履歴応答部 31Fとして機能し、特定日プレイ履歴要求 m 11内のプレイヤー IDおよび端末識別子に対応するカード ID (携帯端末 4の所有者 のカード ID)と、当該カード IDに対応付けて人間関連付けテーブル T3に格納されて いる公開用 IDに対応するカード ID (他のプレイヤーのカード ID)とを特定し、特定し たカード ID (携帯端末 4の所有者のカード IDおよび他のプレイヤーのカード ID)と特 定日プレイ履歴要求 ml 1内の日付データが示す日付とに対応して 、る端末供給用 プレイデータを端末供給用プレイデータテーブル T4力も抽出する (ステップ Sk2)。
[0098] 次に、サーバ装置 3は、特定日プレイ履歴応答部 31F (友達プレイ履歴送信部）と して機能し、通信インターフェイス 32 (友達プレイ履歴送信部）を介して、抽出した端 末供給用プレイデータを含む特定日プレイ履歴応答 ml 2を返信する (ステップ Sk3) 。この返信が、 1日分の端末供給用プレイデータの送信となる。こうして、特定日プレ ィ履歴応答処理が終了する。一方、携帯端末 4は、特定日プレイ履歴取得部 41Dと して機能し、特定日プレイ履歴応答 ml2を受信する (ステップ ¾3)。以降、携帯端末 4は、制御部 41Cとして機能し、ステップ ¾4以降の処理を行う。ただし、特定日プレ ィ履歴応答 m 12内の端末供給用プレイデータに応じた画像が詳細画面 G7に含まれ ることになる。
[0099] 上述した特定日プレイ履歴取得処理および特定日プレイ履歴応答処理によれば、 抽出対象期間内であって第 2期間外である第 1期間内の端末供給用プレイデータを も受け取ることができる。しかも、使用者であるプレイヤーに指定された日付を示す日 付データに対応する端末供給用プレイデータだけが送信されるため、通信負荷をさ ほど重くすることなぐ所望の端末供給用プレイデータを受け取ることができる。なお、 アイコンが配置されて 、な 、桥にカーソルが位置して 、るときに所定の操作入力がな されても特定日プレイ履歴取得処理は行われない。したがって、本実施形態によれ ば、無駄に通信および特定日プレイ履歴応答処理が行われる事態を避けることがで きる。
[0100] [公開用 ID変更]
図 20は、携帯端末 4が行う公開用 ID変更要求処理およびサーバ装置 3が行う公開 用 ID変更処理の流れを示す図である。公開用 ID変更要求処理および公開用 ID変 更処理によって、携帯端末 4の所有者は、自分の公開用 IDを変更することができる。
[0101] 携帯端末 4が公開用 ID変更要求処理を行うのは、携帯端末 4の所有者であるプレ ィヤーカ -ユー画面 G2内の公開用 ID変更ボタンを操作部 44 (自己公開用識別情 報変更指示入力部)でソフトウェアを介して押す操作入力がなされたときである。変更 要求処理では、携帯端末 4は、公開用 ID変更処理部 41E (自己公開用識別情報変 更処理部）として機能し、まず、公開用 IDの変更を要求するメッセージである公開用 I D変更要求 m9をサーバ装置 3へ送信する (ステップ Sml)。公開用 ID変更要求 m9 は、プレイヤー ID領域 U内のプレイヤー IDと端末識別子領域 473内の端末識別子 を含む。
[0102] サーバ装置 3は、公開用 ID変更処理において、公開用 ID変更要求 m9を受信する と (ステップ Snl)、公開用 ID変更部 31G (公開用識別情報変更部)として機能し、公 開用 IDを生成する (ステップ Sn2)。次に、サーバ装置 3は公開用 ID変更部 31Gとし て機能し、公開用 ID変更要求 m9内のレイヤー IDおよび端末識別子に対応する力 ード IDを特定し、このカード IDに対応付けて公開用 IDテーブル T2に格納されて ヽ る公開用 IDを、生成した公開用 IDで更新する (ステップ Sn3)。
[0103] 次に、サーバ装置 3は、関連付けクリア部 31Hとして機能し、更新される前の公開 用 IDを人間関連付けテーブル T3からクリアする (ステップ Sn4)。これにより、人間関 連付けテーブル T3には、当該カード IDに対応する公開用 IDは存在しないこととなる 。したがって、当該カード IDが記録されているカード 2を所有しているプレイヤーが自 ら更新後の公開用 IDを他人に知らせない限り、当該プレイヤーの腕前を示すデータ が他人の携帯端末 4に送信されることはない。次に、サーバ装置 3は、公開用 ID変更 部 31Gとして機能し、公開用 IDの変更が完了した旨のメッセージである公開用 ID変 更応答 mlOを返信する。公開用 ID変更応答 mlOは、更新後の公開用 IDを含む。
[0104] 携帯端末 4は、公開用 ID変更処理部 41Eとして機能し、公開用 ID変更応答 mlO を受信すると、公開用 ID変更応答 mlO内の公開用 IDでカレンダー領域 C内の公開 用 IDを更新する (ステップ Sm2)。次に携帯端末 4は、表示画面を変更完了画面 G9 に遷移させる (ステップ Sm3)。この画面には更新後の公開用 IDを表す画像が含ま れている。したがって、携帯端末 4の使用者は、更新後の公開用 IDを知ること、更に は更新後の公開用 IDを他人に知らせることも可能となる。
[0105] 次に携帯端末 4は、操作入力を待ち (ステップ Sm4)、入力された操作が変更完了 画面 G9内のメニューボタンを押す操作、すなわちメニュー画面 G2への遷移操作で ある力否かを判定し (ステップ Sm5)、この判定結果が否定的であれば処理をステツ プ Sm4に戻す、という処理を繰り返す。この繰り返しは、メニュー画面 G2への遷移操 作が入力されると終了する。すると、携帯端末 4は、表示画面をメニュー画面 G2へ遷 移させる (ステップ Sdl l)。こうして、公開用 ID変更要求処理が終了する。
[0106] [効果]
以上説明したように、本実施形態によれば、携帯端末 4の使用者であるプレイヤー は、アイコンの配置を眺めることにより、所定のゲームの腕前に関する友達のプレイヤ 一の成長の可能性 (potential)を抽出対象期間（例えば過去 1年）にわたつて把握す ることができる。また、携帯端末 4の使用者であるプレイヤ一は、ゲームの腕前に関す る友達のプレイヤーの成長を第 2期間（例えば過去 30日）にわたつて把握することが できる。また、携帯端末 4に渡される端末供給用プレイデータは第 2期間内の日付を 示す日付データに対応するものに限られるから、抽出対象期間内の日付を示す日付 データに対応する全ての端末供給用プレイデータが携帯端末 4に渡される場合に比 較して、通信負荷が軽くなる。 [0107] また、本実施形態では、多数のプレイヤーの各々を識別する識別情報であって、プ レイヤーが通知サービスを利用するために他のプレイヤーから知らせてもらう識別情 報は、後に変更容易な公開用 IDとなる。したがって、本実施形態によれば、他のプレ ィャ一は、自己に係る公開用 IDを容易に変更することが可能であり、この変更により 、通知サービスにおいて自己のプレイデータが利用されることを確実に停止すること ができる。また、変更後の公開用 IDを他人に知らせることにより、通知サービスにお いて自己のプレイデータを利用可能な人を変更することができる。
[0108] [第 2実施形態]
次に、本発明の第 2実施形態に係るゲームシステムを備えた通信システムについて 説明する。本実施形態に係る通信システムの構成は、第 1実施形態に係る通信シス テムと同様である。ただし、サーバ装置 3のハードディスクに記憶されている端末用プ ログラム Pおよび管理プログラムは、第 1実施形態におけるものと異なる。このため、サ ーバ装置 3および携帯端末 4に仮想的に生成される機能部のうちのいくつかの動作 は、第 1実施形態におけるものと相違する。これらの相違点について、次に説明する
[0109] 図 21は、本実施形態におけるプログラム処理の流れと当該プログラム処理に応じて サーバ装置 3で行われるプログラム対応処理の流れとを対応付けて示す図である。こ の図において、図 12と共通する部分には同一の符号が付されている。この図に示す ように、携帯端末 4は、プログラム処理において、長期プレイ履歴取得部 41Bとして機 能し、端末用プログラム Pの実行が初回であるか否かを判定することなぐ長期プレイ 履歴要求 m7をサーバ装置 3へ送信する。次に、表示画面を更新中画面 G6に遷移さ せる（ステップ Sp2)。
[0110] 次にサーバ装置 3は、プログラム応答処理において、長期プレイ履歴要求 m7を受 信すると (ステップ Sql)、長期プレイ履歴応答部 31Eとして機能し、当該携帯端末 4 力もの端末用プログラム Pを用いたアクセスが初回である力否かを判定する (ステップ Sq2)。この判定は、例えば、初期状態ではオンで当該判定の後にはオフとなるフラ グを、端末用プログラム Pを送信した携帯端末 4の使用者であるプレイヤー毎に、格 納部 33に確保しておくことにより実現可能である。この判定結果が肯定的な場合、サ ーバ装置 3は、人間関連付けテーブル T3にレコードを追カ卩し (ステップ Sq3)、このレ コードのカード IDのフィールドに、当該長期プレイ履歴要求 m7内のプレイヤー IDお よび端末識別子に対応するカード IDを格納する (ステップ Sq4)。
[0111] 上記の判定結果が否定的な場合に、サーバ装置 3は、長期プレイ履歴応答部 31E として機能し、長期プレイ履歴要求 m7内のプレイヤー IDおよび端末識別子に対応 するカード IDと、当該カード IDに対応付けて人間関連付けテーブル T3に格納され ている公開用 IDに対応するカード IDとを特定する一方、第 2期間および第 1期間か らなる抽出対象期間を特定する (ステップ Sq5)。抽出対象期間の特定の内容は第 1 実施形態について述べた通りである。
[0112] 次に、サーバ装置 3は、長期プレイ履歴応答部 31Eとして機能し、端末供給用プレ ィデータテーブル T4のレコードのうち、特定されたカード IDを格納し、かつ、抽出対 象期間内の日付を示す日付データを格納したレコードを特定し、特定したレコードの 数が所定の送信上限数 (例えば 10)よりも多ければ所定の方針に従って当該レコー ドから送信上限数のレコードを特定し、こうして特定されたレコードから、一括送信す るデータを抽出し、抽出したデータのうちのカード IDを公開用 IDに変換する (ステツ プ Sq6)。この抽出は第 1実施形態と同様に期間別に行われる。
[0113] なお、特定したレコードが送信上限数以上である力否かの判定を行うのは、同一の カード IDおよび同一の日付データを格納したレコードが多数になり得る力もである。 このようになり得るのは、更新反映処理における反映処理（図 11のステップ Sa2)の 内容が異なるからである。つまり、本実施形態における反映処理では、サーバ装置 3 は、最新プレイデータの更新処理を行われる度に、必ず、更新反映部 31Dとして機 能し、端末供給用プレイデータテーブル T4にレコードを追加する。なお、同一のカー ド IDおよび同一の日付データを格納したレコードの数を無制限とするのは現実的に 困難であるから、本実施形態では、当該レコードの数を送信上限数よりも多い格納上 限数 (例えば 20)以下に制限している。
[0114] また、上記の更新処理により更新される最新プレイデータは、第 1実施形態におけ るものと異なり、プレイ回数を示すデータを含んでいない。しかし、第 2実施形態に係 る最新プレイデータは、プレイヤーの所定のゲームの腕前を示すデータとして、過去 の全てのプレイを通じて最高または最善の結果を示すデータだけでなく、 1回のプレ ィでの結果を示すデータ (例えば、最高でなくても最後のプレイで得られたスコアを 示すデータ）や、 1日のプレイを通じて最高または最善の結果を示すデータ (例えば、 その日のハイスコアを示すデータ）をも含んでいる。したがって、あるカード 2に対応 する最新プレイデータは、当該カード 2を用いて所定のゲームがプレイされる度に更 新されること〖こなる。
[0115] 次に、サーバ装置 3は、符号ィ匕部として機能し、ステップ Sq6で得られたデータを符 号ィ匕し (ステップ Sq7)、長期プレイ履歴応答部 31Eとして機能し、符号化されたデー タを含む長期プレイ履歴応答 m8を返信する (ステップ Sq8)。上記の符号化の内容 は第 1実施形態につ 、て述べた通りである。
携帯端末 4は、長期プレイ履歴取得部 41Bとして機能し、長期プレイ履歴応答 m8 を受信すると (ステップ Sp3)、長期プレイ履歴応答 m8内のカレンダーデータでカレ ンダー領域 C内のカレンダーデータを更新する（ステップ Sp4)。これにより、カレンダ 一領域 C内のカレンダーデータが最新となる。次に、携帯端末 4は、カレンダー画面 G1への遷移処理を行う（ステップ Sb4)。
[0116] 以降の処理は、第 1実施形態について述べたものと同様となる。ただし、本実施形 態における長期プレイ履歴取得処理および長期プレイ履歴応答処理は、上述した処 理に準じたものとなる。また、ここで表示されるカレンダー画面 G1が図 16に示すもの となり、このカレンダー画面 G1内の前月ボタンを押す操作が入力されたとしても、こ れにより表示されるカレンダー画面 G1では、第 2期間を示す表示は為されない。つま り、 2005年 2月 21日以前の桥の形態と 2005年 2月 22日以降の桥の形態が共通で ある。しかし、それでも、無駄に通信および特定日プレイ履歴応答処理が行われる事 態を回避可能である。この理由について次に説明する。
[0117] 図 22は、本実施形態において携帯端末 4が行う特定日プレイ履歴取得処理の流 れを示す図である。この図において、図 18と共通する部分には同一の符号が付され ている。この図に示すように、携帯端末 4は、制御部 41Cとして機能し、当該桥に相 当する日の日付が第 2期間内の日付であるか否かを判定し (ステップ ¾ 1)、この判定 結果が肯定的な場合には、携帯端末 4はステップ ¾4〜¾ 7の処理を行う。これらの 処理の内容は第 1実施形態について述べたものと同様である。ただし、詳細画面 G7 では、 1人のプレイヤーについて最大で 10レコード分の端末供給用プレイデータに 相当する表示が為される。したがって、詳細画面 G7としては、腕前を示す情報を 1人 ずつ切り替えて表示する画面が好適である。
[0118] 上記の判定結果が否定的な場合、すなわち、当該桥に相当する日の日付が第 2期 間外の日付である場合には、携帯端末 4は制御部 41Cとして機能し、表示画面を、 通信の許可 Z不許可を示す操作の入力を促す通信確認画面（図示略)へ遷移させ る (ステップ Srl)。次に、携帯端末 4は制御部 41Cとして機能し、通信の許可を示す 操作入力が為されたカゝ否かを判定する (ステップ Sr2)。許可を示す操作入力が為さ れた場合には、携帯端末 4はステップ ¾ 2以降の処理を行う。これらの処理の内容は 第 1実施形態について述べたものと同様である。一方、不許可を示す操作入力が為 された場合には特定日プレイ履歴取得処理が終了する。
[0119] このように、携帯端末 4は、第 2期間外の日付が指定された場合には、通信確認画 面を表示させ、プレイヤーに対して、通信の許可 Z不許可を指定する機会を与える。 つまり、プレイヤ一は、自己が第 2期間外の日付を指定したことを知ることになる。した がって、プレイヤ一は、本当に通信および特定日プレイ履歴応答処理を行わせる必 要があるときにだけ、通信を許可することができる。よって、本実施形態によっても、無 駄に通信および特定日プレイ履歴応答処理が行われる事態を回避することができる 。なお、本実施形態によれば、第 1実施形態について述べた各種の効果と同等の効 果を得ることができる。
[0120] [変形例]
以上、現時点において、最も実践的であり、かつ好ましいと思われる実施形態に関 連して本発明を説明したが、本発明は明細書中に開示された実施形態に限定される ものではなぐ請求の範囲及び明細書全体力 読みとられる発明の要旨あるいは思 想に反しない範囲で適宜変更可能であり、そのような変更を伴う態様もまた本発明の 技術的範囲に包含されるものとして理解されなければならない。
[0121] 例えば、端末供給用プレイデータテーブル T4を更新する際に、端末供給用プレイ データのスーパーセットとなる最新プレイデータの部分的な更新状況に応じて端末 供給用プレイデータを生成するようにしてもよい。例えば、スーパーセットとなる最新 プレイデータに含まれているハイスコアを示すデータが更新されていてクリア報奨メダ ルの取得状況を示すデータが更新されて ヽな ヽ場合に、クリア報奨メダルの取得状 況を示すデータを含まな!/ヽ端末供給用プレイデータを生成するようにしてもょ ヽ。
[0122] また、上記各実施形態においては、携帯端末 4においてその使用者であるプレイヤ 一の腕前を表示可能になっているが、これを変形し、表示可能な腕前が当該使用者 であるプレイヤーに指定されたプレイヤーの腕前だけに限られるようにしてもよい。さ らに、登録可能な友達の数が 1人または 3人以上となるように変形してもよぐ 1人の 場合には、端末供給用プレイデータ等の一括送信において、複数のプレイヤーの各 々を識別するための識別情報 (例えば公開用 ID)を送信しな ヽように変形してもよ ヽ
[0123] また、上記各実施形態においては、現在日の 1日前を起算日として抽出対象期間 および第 2期間を定めているが、これを変形し、現在日の複数日前を起算日として抽 出対象期間および第 2期間を定めるようにしてもよい。また、上記各実施形態におい ては、携帯端末 4からの長期プレイ履歴要求に応じてサーバ装置 3が端末供給用プ レイデータ等の一括送信を行うようにしたが、これを変形し、サーバ装置 3が所定の周 期で一括送信を行うようにしてもよい。また、上記各実施形態においては、複数のプ レイヤーの各々を識別する識別情報として、主に、カード 2に記録されているカード I Dを用いるようにしたが、これに限るものではなぐ例えば、プレイヤー IDや端末識別 子を主に用いるようにしてもよい。また、上記各実施形態においては、サーバ装置 3 が携帯端末 4力 の友達登録要求を受けて友達登録処理を行うようにしたが、例えば 、携帯端末 4の使用者がサーバ装置 3の管理者に電話で依頼し、この依頼を受けて 管理者がサーバ装置 3を操作し、サーバ装置 3に友達登録処理を行わせるようにして もよい。また、あるカード 2について最新プレイデータテーブル T1に最初に最新プレ ィデータが書き込まれたときに端末供給用プレイデータテーブル T4に追加されるレ コードの端末供給用プレイデータに最初のプレイであることを示すデータを含ませて ちょい。
[0124] また、上記各実施形態においては、既存のシステムとの親和性を高くするために最 新プレイデータテーブル Tlを用いている力 これを変形し、最新プレイデータテープ ル T1を用いない構成としてもよい。例えば、サーバ装置 3に、多数のゲーム装置 1の 各々から、プレイヤーが当該ゲーム装置 1で所定のゲームをプレイする度に、当該プ レイヤーが所定のゲームをプレイして得られた結果を示すプレイデータと、当該プレ ィヤーに与えられた多数のプレイヤーの各々を識別するための識別情報 (例えば力 ード ID)とを受信するプレイデータ受信部を設け、このプレイデータ受信部が受信し たデータに直接的に基づいて、端末供給用プレイデータを生成し、端末供給用プレ ィデータテーブル T4を更新するようにしてもょ 、。
上記実施形態では、ゲーム装置 1とサーバ装置 3が通信するゲームシステムを例示 したが、本発明はゲーム装置に限られず他の操作装置とサーバ装置 3の通信にも利 用でき、本発明の範囲はそのようなゲームシステム、サーバ装置を包含する。

Claims

請求の範囲
[1] 複数のユーザにそれぞれ操作されうる複数の操作装置の各々と通信するサーバ装 置であって、
書き込まれた情報を記憶する個人データ領域と書き込まれた情報を記憶する人間 関連付けデータ領域とを有する格納部と、
前記複数のユーザの各々を識別するための公開用識別情報と、 1つ以上の前記操 作装置での操作の内容を示す操作状況情報とを、個々のユーザの公開用識別情報 と操作状況情報を対応付けて、前記個人データ領域に書き込む個人データ書き込 み部と、
前記個人データ領域に公開用識別情報が書き込まれると、前記書き込まれた公開 用識別情報で識別されるユーザに宛てて、前記書き込まれた公開用識別情報を知ら せるための情報を送信する自己公開用識別情報送信部と、
第 1のユーザの公開用識別情報を第 2のユーザ力 受け取ると、前記受け取った第 1のユーザの公開用識別情報を前記第 2のユーザに対応付けて前記人間関連付け データ領域に書き込む人間関連付けデータ書き込み部と、
前記第 2のユーザに宛てて、前記人間関連付けデータ領域内で前記第 2のユーザ に対応付けられている前記公開用識別情報で識別される前記第 1のユーザについ て前記個人データ領域に記憶されている操作状況情報を示す情報を送信する友達 プレイ履歴送信部と、
ユーザから公開用識別情報の変更の要求を受けると、前記ユーザにつ!、て前記個 人データ領域に記憶されている公開用識別情報を変更する公開用識別情報変更部 と
を備えるサーバ装置。
[2] 複数のプレイヤーにそれぞれ操作されうる複数のゲーム装置の各々と通信するサ ーバ装置であって、
書き込まれた情報を記憶する個人データ領域と書き込まれた情報を記憶する人間 関連付けデータ領域とを有する格納部と、
前記複数のプレイヤーの各々を識別するための非公開識別情報、前記複数のプレ ィヤーの各々を識別するための公開用識別情報、および 1つ以上の前記ゲーム装置 でのプレイの結果を示すプレイ状況情報を、個々のプレイヤーの非公開用識別情報 と公開用識別情報とプレイ状況情報を対応付けて前記個人データ領域に書き込む 個人データ書き込み部と、
前記個人データ領域に公開用識別情報が書き込まれると、前記書き込まれた公開 用識別情報で識別されるプレイヤーに宛てて、前記書き込まれた公開用識別情報を 送信する自己公開用識別情報送信部と、
第 1のプレイヤーの公開用識別情報を第 2のプレイヤ一力 受信すると、前記受け 取った第 1のプレイヤーの公開用識別情報を前記第 2のプレイヤーの非公開識別情 報または公開用識別情報に対応付けて前記人間関連付けデータ領域に書き込む人 間関連付けデータ書き込み部と、
前記第 2のプレイヤーに宛てて、前記人間関連付けデータ領域内で前記第 2のプ レイヤーの前記非公開識別情報または前記公開用識別情報に対応付けられている 前記公開用識別情報で識別される前記第 1のプレイヤーについて前記個人データ 領域に記憶されているプレイ状況情報を示す情報を送信する友達プレイ履歴送信部 と、
プレイヤーから公開用識別情報の変更の要求を受けると、前記プレイヤーについ て前記個人データ領域に記憶されている公開用識別情報を変更する公開用識別情 報変更部と
を備えるサーバ装置。
[3] 前記公開用識別情報変更部が変更する前記個人データ領域内の前記公開用識 別情報と同一の前記公開用識別情報を前記人間関連付けデータ領域から削除する 関連付けクリア部
を備えることを特徴とする請求項 1または 2に記載のサーバ装置。
[4] 複数のプレイヤーにそれぞれ操作されうる複数のゲーム装置の各々と通信するサ ーバ装置と、前記サーバ装置と通信する複数の端末装置とを有するゲームシステム であって、
前記サーバ装置は、 書き込まれた情報を記憶する個人データ領域と書き込まれた情報を記憶する人間 関連付けデータ領域とを有する格納部と、
前記複数のプレイヤーの各々を識別するための非公開識別情報、前記複数のプレ ィヤーの各々を識別するための公開用識別情報、および 1つ以上の前記ゲーム装置 でのプレイの結果を示すプレイ状況情報を、個々のプレイヤーの非公開用識別情報 と公開用識別情報とプレイ状況情報を対応付けて前記個人データ領域に書き込む 個人データ書き込み部と、
前記個人データ領域に公開用識別情報が書き込まれると、前記書き込まれた公開 用識別情報で識別されるプレイヤーに宛てて、前記書き込まれた公開用識別情報を 送信する自己公開用識別情報送信部と、
第 1のプレイヤーの公開用識別情報を第 2のプレイヤーに使用されている端末装置 から受信すると、前記受け取った第 1のプレイヤーの公開用識別情報を前記第 2のプ レイヤーの非公開識別情報または公開用識別情報に対応付けて前記人間関連付け データ領域に書き込む人間関連付けデータ書き込み部と、
前記第 2のプレイヤーが使用している前記端末装置へ、前記人間関連付けデータ 領域内で前記第 2のプレイヤーの前記非公開識別情報または前記公開用識別情報 に対応付けられている前記公開用識別情報で識別される前記第 1のプレイヤ一につ V、て前記個人データ領域に記憶されて 、るプレイ状況情報を示す情報を送信する 友達プレイ履歴送信部と、
プレイヤーが使用している端末装置力 公開用識別情報の変更の要求を受信する と、前記プレイヤ一につ!/、て前記個人データ領域に記憶されて!、る公開用識別情報 を変更する公開用識別情報変更部とを備え、
前記複数の端末装置の各々は、
プレイヤーが他のプレイヤーの公開用識別情報を入力することができる友達公開 用識別情報入力部と、
前記友達公開用識別情報入力部に入力された前記公開用識別情報を前記サー バ装置へ送信する友達登録処理部と、
前記サーバ装置から前記端末装置に宛てて送信された情報を受信する受信部と、 プレイヤーが前記プレイヤーの公開用識別情報の変更の指示を入力することがで きる自己公開用識別情報変更指示入力部と、
前記自己公開用識別情報変更指示入力部に前記指示が入力されると、前記プレ ィヤーの公開用識別情報の変更の要求を前記サーバ装置へ送信する自己公開用 識別情報変更処理部とを備える、
ことを特徴とするゲームシステム。
複数のプレイヤーにそれぞれ操作されうる複数のゲーム装置と、前記複数のゲーム 装置の各々と通信するサーバ装置とを有するゲームシステムであって、
前記複数のゲーム装置の各々は、
前記ゲーム装置でプレイヤーがプレイする度に、ゲームのプレイの結果を示すプレ ィデータを生成するプレイデータ生成部と、
前記ゲーム装置でプレイするために使用されるプレイヤーの情報記録媒体から、前 記情報記録媒体を識別するために前記情報記録媒体に記録されて 、る媒体識別情 報を読み取る読み取り部と、
前記ゲーム装置でプレイヤーが前記プレイヤーの情報記録媒体を用いてプレイす る度に、前記生成されたプレイデータを、前記読み取られた前記媒体識別情報と共 に前記サーバ装置へ送信する送信部とを備え、
前記サーバ装置は、
書き込まれた情報を記憶する個人データ領域と書き込まれた情報を記憶する人間 関連付けデータ領域とを有する格納部と、
前記複数の前記ゲーム装置の 1つから前記媒体識別情報と共に前記プレイデータ を受信する度に、受信した前記プレイデータに基づ 、てプレイヤーのプレイ状況情 報を生成するプレイ状況情報生成部と、
前記媒体識別情報、前記プレイヤーの前記プレイ状況情報および前記プレイヤー を識別するための公開用識別情報を、互いに対応付けて前記個人データ領域に書 き込む個人データ書き込み部と、
前記個人データ領域に公開用識別情報が書き込まれると、前記書き込まれた公開 用識別情報で識別されるプレイヤーに宛てて、前記書き込まれた公開用識別情報を 送信する自己公開用識別情報送信部と、
第 1のプレイヤーの公開用識別情報を第 2のプレイヤ一力 受信すると、前記受け 取った第 1のプレイヤーの公開用識別情報を前記第 2のプレイヤーの情報記録媒体 の媒体識別情報または前記第 2のプレイヤーの公開用識別情報に対応付けて前記 人間関連付けデータ領域に書き込む人間関連付けデータ書き込み部と、
前記第 2のプレイヤーに宛てて、前記人間関連付けデータ領域内で前記第 2のプ レイヤーの前記情報記録媒体の前記媒体識別情報または前記第 2のプレイヤーの 前記公開用識別情報に対応付けられている前記公開用識別情報で識別される前記 第 1のプレイヤーについて前記個人データ領域に記憶されているプレイ状況情報を 示す情報を送信する友達プレイ履歴送信部と、
プレイヤーから公開用識別情報の変更の要求を受けると、前記プレイヤーについ て前記個人データ領域に記憶されている公開用識別情報を変更する公開用識別情 報変更部とを備える、
ことを特徴とするゲームシステム。
前記サーバ装置は、前記公開用識別情報変更部が変更する前記個人データ領域 内の前記公開用識別情報と同一の前記公開用識別情報を前記人間関連付けデー タ領域力 削除する関連付けクリア部を備える、
ことを特徴とする請求項 4または 5に記載のゲームシステム。
PCT/JP2006/317276 2005-09-05 2006-08-31 サーバ装置およびゲームシステム WO2007029603A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP06797236A EP1923109A4 (en) 2005-09-05 2006-08-31 SERVER DEVICE AND GAME SYSTEM
US12/065,824 US8409007B2 (en) 2005-09-05 2006-08-31 Server apparatus and game system
CN2006800325261A CN101257954B (zh) 2005-09-05 2006-08-31 服务器设备和游戏系统
HK08112157.6A HK1120456A1 (en) 2005-09-05 2008-11-06 Server device and game system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005256819A JP3946735B2 (ja) 2005-09-05 2005-09-05 サーバ装置およびゲームシステム
JP2005-256819 2005-09-05

Publications (1)

Publication Number Publication Date
WO2007029603A1 true WO2007029603A1 (ja) 2007-03-15

Family

ID=37835722

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/317276 WO2007029603A1 (ja) 2005-09-05 2006-08-31 サーバ装置およびゲームシステム

Country Status (8)

Country Link
US (1) US8409007B2 (ja)
EP (1) EP1923109A4 (ja)
JP (1) JP3946735B2 (ja)
KR (1) KR20080042929A (ja)
CN (1) CN101257954B (ja)
HK (1) HK1120456A1 (ja)
TW (1) TWI316864B (ja)
WO (1) WO2007029603A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5449827B2 (ja) * 2009-03-31 2014-03-19 株式会社コナミデジタルエンタテインメント ゲームシステム、ゲーム装置及びゲーム用プログラム
JP5017462B2 (ja) * 2010-12-27 2012-09-05 株式会社東芝 情報処理装置及びリムーバブルメディア管理方法
US8562434B2 (en) 2011-01-16 2013-10-22 Google Inc. Method and system for sharing speech recognition program profiles for an application
JP6302614B2 (ja) * 2011-02-25 2018-03-28 任天堂株式会社 通信システム、情報処理装置、プログラム及び情報処理方法
US8696468B2 (en) * 2011-08-04 2014-04-15 Ami Entertainment Network, Llc Amusement device including provision for tracking a player's top score
US8924432B2 (en) 2011-09-26 2014-12-30 Ami Entertainment Network, Llc Portable hand held controller for amusement device
US8827798B2 (en) * 2011-09-28 2014-09-09 Igt Gaming system and method providing a user device that receives and stores reel sets for subsequent game plays
US8591314B2 (en) 2011-09-28 2013-11-26 Igt Gaming system and method providing a server that determines a reel set for an initial game play and reel sets for subsequent game plays
US8968073B2 (en) 2011-09-28 2015-03-03 Igt Gaming system and method providing a server that determines reel sets for subsequent game plays
US8668574B2 (en) 2011-09-28 2014-03-11 Igt Gaming system and method providing a user device that receives and stores a reel set for an initial game play and reel sets for subsequent game plays
US8915783B2 (en) 2012-04-27 2014-12-23 Tipping Point Group, Llc Gaming machines with player reservation feature
JP6360280B2 (ja) * 2012-10-17 2018-07-18 任天堂株式会社 ゲームプログラム、ゲーム装置、ゲームシステム、およびゲーム処理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003085102A (ja) * 2001-09-10 2003-03-20 Sony Communication Network Corp 情報授受システムおよび情報授受方法
JP2005071002A (ja) * 2003-08-22 2005-03-17 Ricoh Co Ltd 共同検索システム、プログラムおよび記録媒体
JP2005118543A (ja) * 2003-09-24 2005-05-12 Sega Corp ランキングデータ生成プログラム

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5830064A (en) 1996-06-21 1998-11-03 Pear, Inc. Apparatus and method for distinguishing events which collectively exceed chance expectations and thereby controlling an output
JP3492265B2 (ja) * 1999-10-29 2004-02-03 ボーダフォン株式会社 デジタル無線電話によるメッセージ通信システム
JP2001325514A (ja) 2000-05-15 2001-11-22 Kyubunkan:Kk サーバー装置、端末装置および記録媒体
US20020002074A1 (en) 2000-06-30 2002-01-03 Cyop Systems Method for an online player game payment system
JP3642750B2 (ja) 2000-08-01 2005-04-27 株式会社ソニー・コンピュータエンタテインメント 通信システム、コンピュータプログラム実行装置、記録媒体、コンピュータプログラム及び番組情報編集方法
JP2002149577A (ja) 2000-11-13 2002-05-24 Net Seeds Corp サイトの運営方法およびサイトの運営システム
US20030177187A1 (en) * 2000-11-27 2003-09-18 Butterfly.Net. Inc. Computing grid for massively multi-player online games and other multi-user immersive persistent-state and session-based applications
US7780529B2 (en) 2001-04-04 2010-08-24 Igt System, method and interface for monitoring player game play in real time
KR20070108283A (ko) * 2001-05-09 2007-11-08 가부시키가이샤 세가 게임장치, 서버장치, 프로그램 및 기록매체
JP3422784B2 (ja) 2001-05-30 2003-06-30 株式会社コナミコンピュータエンタテインメント大阪 ネットゲームシステム及びネットゲーム管理方法
US7311605B2 (en) * 2002-06-12 2007-12-25 Igt Player tracking assembly for complete patron tracking for both gaming and non-gaming casino activity
US7640300B2 (en) * 2002-06-10 2009-12-29 Microsoft Corporation Presence and notification system for maintaining and communicating information
US20030228908A1 (en) * 2002-06-10 2003-12-11 Daniel Caiafa Statistics system for online console-based gaming
JP3831695B2 (ja) 2002-09-11 2006-10-11 株式会社コナミデジタルエンタテインメント ゲームシステム及びサーバ装置
JP4431353B2 (ja) 2002-10-30 2010-03-10 株式会社コナミデジタルエンタテインメント ゲーム用サーバ装置及びゲーム管理用プログラム
US7798905B2 (en) 2003-05-09 2010-09-21 Microsoft Corporation Method and apparatus for associating data with online game ratings
US7214133B2 (en) 2003-05-09 2007-05-08 Microsoft Corporation Method and apparatus for retrieving recorded races for use in a game
NZ526910A (en) * 2003-07-07 2006-07-28 Simworks Internat Ltd Synchronising the address books of users on a network
WO2005026870A2 (en) 2003-09-16 2005-03-24 Yakir Terebilo Massive role-playing games or other multiplayer games system and method using cellular phone or device
US7288028B2 (en) * 2003-09-26 2007-10-30 Microsoft Corporation Method and apparatus for quickly joining an online game being played by a friend
JP4322614B2 (ja) * 2003-09-30 2009-09-02 株式会社スクウェア・エニックス 広告配信システム
JP4588310B2 (ja) 2003-11-12 2010-12-01 ソニー株式会社 通信システム、サーバおよび端末装置
EP1560104A1 (en) * 2004-01-28 2005-08-03 Sony Ericsson Mobile Communications AB Device with game-dependent user interface, method, game module and computer program product therefor
US7914381B2 (en) * 2004-03-16 2011-03-29 Xfire, Inc. System and method for facilitating multiplayer online gaming
US8425331B2 (en) * 2004-12-07 2013-04-23 Microsoft Corporation User interface for viewing aggregated game, system and personal information
US8241129B2 (en) 2005-06-20 2012-08-14 Microsoft Corporation Setting up on-line game sessions out of a game context

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003085102A (ja) * 2001-09-10 2003-03-20 Sony Communication Network Corp 情報授受システムおよび情報授受方法
JP2005071002A (ja) * 2003-08-22 2005-03-17 Ricoh Co Ltd 共同検索システム、プログラムおよび記録媒体
JP2005118543A (ja) * 2003-09-24 2005-05-12 Sega Corp ランキングデータ生成プログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Minna no GOLF Online Kaisetsusho, Received by National Center for Industrial Property Information and Training", SONY COMPUTER ENTERTAINMENT INC., 25 December 2003 (2003-12-25), pages 12 - 13, AND 44 - 49, XP003009764 *
VIRTUA FIGHTER 4 EVOLUTION: "Perfect Guide", vol. 1ST ED., 4 October 2002, SOFTBANK PUBLISHING INC., ISBN: 4-7973-2182, pages: 008, XP003009765 *

Also Published As

Publication number Publication date
KR20080042929A (ko) 2008-05-15
US8409007B2 (en) 2013-04-02
EP1923109A1 (en) 2008-05-21
JP3946735B2 (ja) 2007-07-18
TWI316864B (en) 2009-11-11
EP1923109A4 (en) 2009-08-05
CN101257954B (zh) 2011-07-20
US20090298593A1 (en) 2009-12-03
TW200718458A (en) 2007-05-16
JP2007068655A (ja) 2007-03-22
CN101257954A (zh) 2008-09-03
HK1120456A1 (en) 2009-04-03

Similar Documents

Publication Publication Date Title
WO2007029603A1 (ja) サーバ装置およびゲームシステム
KR101031136B1 (ko) 게임 시스템, 서버 장치, 단말 장치 및 기록 매체
US8007363B2 (en) Game system, game server device therefor, and method of controlling game server device, and game device therefor and method of controlling game device
US8038536B2 (en) Game system, game server device therefor, method of controlling game server device, and terminal device therefor and control program product for controlling terminal device
US20090176575A1 (en) Game server system, game element providing method, game device, and program product
KR100901553B1 (ko) 게임 시스템 및 그 제어 방법, 게임 서버 장치, 및 게임장치
US10413831B2 (en) Game system, and control method and storage medium used in same
JP2017195920A (ja) メッセージ配信ゲームシステム、メッセージ配信ゲーム方法及びプログラム
JP2019188156A (ja) ゲームシステム、およびゲームプログラム
JP3738264B2 (ja) ゲームキャラクタ提供方法、ゲームキャラクタ提供装置およびプレーヤ端末

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200680032526.1

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006797236

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12065824

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 1020087008140

Country of ref document: KR