WO2005111815A1 - 情報伝達の過程で内容が変化する情報伝達方法および情報伝達システム - Google Patents

情報伝達の過程で内容が変化する情報伝達方法および情報伝達システム Download PDF

Info

Publication number
WO2005111815A1
WO2005111815A1 PCT/JP2005/008368 JP2005008368W WO2005111815A1 WO 2005111815 A1 WO2005111815 A1 WO 2005111815A1 JP 2005008368 W JP2005008368 W JP 2005008368W WO 2005111815 A1 WO2005111815 A1 WO 2005111815A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
sentence
terminal
data entry
game
Prior art date
Application number
PCT/JP2005/008368
Other languages
English (en)
French (fr)
Inventor
Noriyuki Shimoda
Wataru Nakanishi
Taku Kihara
Daichi Katagiri
Makoto Osaki
Original Assignee
Sega Corporation
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 Sega Corporation filed Critical Sega Corporation
Priority to JP2006513529A priority Critical patent/JP4697137B2/ja
Priority to EP05737098A priority patent/EP1755043A4/en
Publication of WO2005111815A1 publication Critical patent/WO2005111815A1/ja
Priority to US11/588,324 priority patent/US7716053B2/en

Links

Classifications

    • A63F13/12
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/332Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using wireless networks, e.g. cellular phone networks
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/85Providing additional services to players
    • A63F13/87Communicating with other players during game play, e.g. by e-mail or chat
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features 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/50Features 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
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features 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/50Features 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/55Details of game data or player data management
    • A63F2300/5546Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features 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/50Features 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/57Features 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 details of game services offered to the player
    • A63F2300/572Communication between players during game play of non game information, e.g. e-mail, chat, file transfer, streaming of audio and streaming of video
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features 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/80Features 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/807Role playing or strategy games

Definitions

  • the present invention relates to an information transmission method and an information transmission system for transmitting uncertain information.
  • a small-scale connection form there is one in which information terminals are connected by a cable and a battle play is performed in which characters operating with each other play a battle.
  • a service is provided via a network.
  • an information terminal is connected to the server and the same game as the player of the information terminal connected to the server is played.
  • some players have a chat function that allows players to communicate with each other via a display screen by inputting character information using an input means such as a game controller. is there.
  • the information exchanged includes various information such as information indicating the strength and state of the opponent, information input by the player using the chat function, and information that synchronizes the progress of the game between information terminals.
  • the information transmission form does not change between the transmitting side and the receiving side, and definite information transmission is performed.
  • an object of the present invention is to provide an information transmission method for automatically propagating information via an information terminal and increasing uncertainty in the process of propagation. It is what. Means for solving the problem
  • the above object is to execute an entertainment information transmission method performed between a plurality of information terminals configured to exchange information with each other via a communication path.
  • a plurality of sentence generation fixed sentences are stored, and a sentence generation fixed sentence selected from the plurality of sentence generation fixed sentences is A step of generating a sentence by inserting a word that is input to the information terminal or selected in association with an event that occurs in the information terminal, and the generated sentence is transmitted through the communication path.
  • a determination step for determining whether or not to change the received sentence and in the determination step, if the received sentence is not changed, the received sentence is transferred to another information terminal.
  • the second sentence generation fixed phrase associated with the first sentence generation fixed sentence included in the received sentence Is selected from the plurality of sentence generation fixed phrases, and the first sentence generation fixed sentence is replaced with the second sentence generation fixed sentence, or the inserted sentence included in the received sentence is inserted.
  • a second transfer in which a new sentence is generated by replacing the generated word with another word or symbol, and the generated new sentence is transferred to the other information terminal via the communication path. It is achieved by providing an application program, characterized by chromatic and steps.
  • the above object is according to the second aspect of the present invention, in the first aspect, other information terminal power transfer number information included in the received data and the degree of change of Z or received text.
  • the accuracy of the received sentence is further calculated, and an accuracy reference value is defined in advance in each of the plurality of stored sentence generation fixed sentences.
  • This is achieved by providing an application program that performs processing for comparing the calculated accuracy value with the accuracy reference value set in advance for the received sentence.
  • the above object is according to the third aspect of the present invention, in the first or second aspect. This is achieved by providing an application program in which the event is generated by the progress of a game executed on the information terminal.
  • the object is any one of the first to third aspects.
  • the information terminal is a mobile terminal, and each information terminal is configured to be connectable via a wireless communication path. When one information terminal enters a distance range where communication with another information terminal is possible, the transmission is performed. Or an application program configured to enable execution of the first transfer step or the second transfer step.
  • the object is connected to a plurality of information terminals each executing the application program of any one of the first to fourth aspects via a communication path.
  • a server that does not change in the process of entertainment information transfer between the plurality of information terminals, and a storage unit that stores deterministic text, and one information terminal of the plurality of information terminals.
  • a control unit that transmits the deterministic text stored in the storage unit in response to the information acquisition request.
  • the object is that, in the fifth aspect, the control unit transmits the information acquisition request from the one information terminal together with the information acquisition request. Receiving the sentence, storing it in the storage unit, and responding to the information acquisition request from another information terminal different from the one information terminal, together with the definitive sentence, the one information terminal power This is achieved by providing a server characterized in that the received text is transmitted to the other information terminal.
  • the above-described object is achieved through a communication path to a plurality of information terminals each executing the application program according to any one of the first to fourth aspects.
  • the server is connected to a storage unit that stores a plurality of fixed-form sentences for sentence generation and a fixed-form sentence for sentence generation selected from the plurality of fixed-form sentences for sentence generation.
  • a function to generate a sentence by inserting a word selected in association with an event occurring in the server, and the generated sentence to the communication A transmission function for transmitting to the information terminal via a path, a function for receiving the sentence transmitted by the execution of the application program to the information terminal via the communication path, and the reception.
  • a plurality of information terminals each executing the application program according to any one of the first to fourth aspects, and a communication path to the information terminals.
  • a storage unit that stores deterministic text and one piece of information included in the plurality of information terminals, and is not changed in the process of entertainment information transmission performed between the plurality of information terminals. This is achieved by providing an information system including a server having a control unit that transmits the deterministic text stored in the storage unit in response to an information acquisition request from a terminal.
  • the object is that, in the eighth aspect, the control unit of the server, together with the information acquisition request from the one information terminal, The sentence transmitted by the information terminal is received, stored in the storage unit, and in response to the information acquisition request from another information terminal different from the one information terminal, together with the definite sentence, the one sentence
  • the control unit of the server together with the information acquisition request from the one information terminal, The sentence transmitted by the information terminal is received, stored in the storage unit, and in response to the information acquisition request from another information terminal different from the one information terminal, together with the definite sentence, the one sentence
  • a plurality of information terminals each executing the application program according to any one of the first to fourth aspects, and a communication path to the information terminals.
  • An information system comprising a server connected via a server, wherein the server is a storage unit storing a plurality of sentence generation fixed sentences and a sentence selected from the plurality of sentence generation fixed sentences.
  • a function for generating a sentence by inserting a word that is input to the server or selected in association with an event that occurs in the server, and the generated sentence A transmission function for transmitting to the information terminal via the communication path, a function for receiving the sentence transmitted by the execution of the application program to the information terminal via the communication path, and the received
  • This is achieved by providing an information system comprising a control unit that realizes a transfer function for transferring a sentence to another information terminal.
  • indeterminate information about the game is propagated from the information source to the game terminal one after another.
  • the content of this uncertain information is changed during the propagation process.
  • the user (player) obtains indefinite information, a desire to confirm the authenticity is born, which makes the game more interesting and has the effect of attracting the player's interest for a long time.
  • obtaining information about other players has the effect of stimulating the desire for new games.
  • an event can be generated by propagating an event that matches the progress of the game as indeterminate information.
  • uncertain information is accumulated from a nearby game terminal or the like only by the player carrying the game terminal.
  • the accumulation process is performed in the background of the game program and does not place a burden on the player. It doesn't depend on the player's ability to communicate.
  • the high input capability required for real-time communication such as chat is not required, and it can be realized with a general-purpose game terminal.
  • FIG. 1 is a diagram showing a configuration of a first embodiment of an information transmission system to which a method of the present invention is applied.
  • FIG. 2 is a block diagram showing a configuration of a game terminal.
  • FIG. 3 This is an example of the data structure of a sentence DB that stores fixed phrases used for uncertain information.
  • FIG. 4 is a data configuration example of user information.
  • FIG. 5 A is an example of the data structure of the data entry stored in the indeterminate information DB 21, and B is an example of the data structure of the ID.
  • FIG. 6 is a diagram for explaining that the diffusion of information becomes finite depending on the maximum number of transmissions, the maximum number of receptions, and the remaining number of transmissions.
  • FIG.7 Data structure example of event DB that stores the contents of events that occur in the game It is.
  • Figure 10 This is an example of the data structure of the change rule DB that stores how to change data entries.
  • FIG. 11 This is an example of the data structure of the word candidate DB.
  • A is a flowchart explaining the case where indeterminate information is generated as a data entry as user information is created and updated, and B is according to the checkpoint reached by the player as the game progresses It is a flowchart explaining the case where uncertain information is generated as a data entry, and C is a flow explaining the case where a player directly inputs a value for each item of the data entry to generate a data entry of uncertain information. It is a chart.
  • FIG. 14 is a screen example in step S 101 of FIG. 13A.
  • FIG. 15 An example of a screen displayed when the item “update user information” is selected on screen 63 in FIG.
  • FIG. 16 is a screen example at step S 1 in FIG. 13C.
  • FIG. 17 Steps in which transmission / reception processing is subdivided are shown.
  • FIG. 18 A is a flowchart explaining a case where a forbidden loopback process is performed at the time of transmission using a serial number, and B is a case where a forbidden loopback process is performed at the time of transmission using an event flag. It is a flowchart.
  • FIG. 19 is a diagram for explaining an example in which the process of FIG. 18A is specifically specified.
  • FIG. 20 is a diagram for explaining an example in which the process of FIG. 18B is specifically specified.
  • FIG. 21 A is a flowchart for explaining the case where forbidden loopback processing is performed at the time of reception using an ID, and B is a flowchart for explaining the case of performing forbidden loopback processing at the time of reception using a serial number. C is a flowchart for explaining a case where a forbidden loopback process is performed at the time of reception using an event flag.
  • FIG. 22 is a diagram for explaining an example in which the process of FIG. 21B is specifically specified.
  • FIG. 23 is a diagram for explaining an example in which the processing of FIG. 22C is specifically specified.
  • FIG. 24 A is a flowchart for explaining a case where a data entry is changed based on a rule stored in the change rule DB23, and B is a data entry by changing a fixed sentence to another fixed sentence. Is a flowchart for explaining the case where a change is made, C is a flowchart for explaining a case where a data entry is changed by replacing a word used in the boilerplate, and D is a boilerplate 5 is a flowchart for explaining a case where a data entry is changed by partially using a word used in the above.
  • FIG. 25 This is an example of a screen when a fixed sentence is changed to another fixed sentence as shown in FIG. 24A and FIG. 24B.
  • FIG.26 This is a sample screen when a word is replaced.
  • FIG. 28 is a configuration diagram of an information transmission system in a second embodiment.
  • FIG. 29 is a block diagram showing a configuration of an information relay terminal.
  • FIG. 30 A is a data configuration example of user information in the second embodiment, and B is a participating terminal.
  • FIG. 31 is a block diagram showing a configuration of a server.
  • FIG. 32 is a data configuration example of an indeterminate information DB in the second embodiment.
  • FIG. 33 is a data configuration example of a software management table in which the correspondence between serial numbers and game titles is stored.
  • FIG. 34 shows an example of the data structure of the user authentication DB.
  • FIG. 35 is a data configuration example of relay terminal authentication DB63.
  • FIG. 36 is a time chart for explaining the operation of the server and information terminal I in the second embodiment.
  • FIG. 37 is a screen example of an information relay terminal for explaining a situation where information stored in a server is downloaded to a game terminal.
  • FIG. 38 is an example of a screen for explaining an example of authentication 'billing processing.
  • FIG. 1 is a diagram showing a configuration of a first embodiment of an information transmission system to which the method of the present invention is applied.
  • rumors about the game are stored as indeterminate information in the game terminal 1.
  • the players communicate with each other between the game terminals 1 having a wireless communication function, play a battle, or exchange indefinite information stored in each game terminal 1 to enjoy the game.
  • the indeterminate information stored in each game terminal 1 is repeatedly exchanged in a plurality of game terminals 1 and the indeterminate information is propagated.
  • the indefinite information of this embodiment is propagated as a sentence generated based on a fixed sentence stored in advance in the information terminal. By inserting a word into the fixed sentence, it becomes various uncertain information.
  • the inserted word is the name of a player who is considered a rival among players who have played in the past, items obtained by the player, etc., which are input to the game terminal 1 or stored in the game terminal 1 in advance.
  • the power of things is selected.
  • the game terminal 1 executes a program for executing the method of the present invention, controls the terminal, and advances the game.
  • the game terminal 1 is realized by an information terminal such as a portable game machine, a mobile phone, or a PDA (Personal Digital Assistance).
  • the uncertain information is stored in an uncertain information database (hereinafter abbreviated as uncertain information DB) 21 provided in each game terminal 1.
  • FIG. 1 shows an example of the data structure of the indeterminate information DB. Uncertain information
  • Each row of DB21 is the data entry described above.
  • uncertain information is propagated between the game terminals 1.
  • the data entries shown in Fig. 1 include "identifier (ID)”, “sentence code”, “accuracy”, and “word”.
  • ID identifier
  • Sens a management number for specifying a data entry.
  • text code is associated with a fixed text in a text database to be described later, and specifies a fixed text in a certain worm-eaten state.
  • the word at least one word / phrase is stored according to the number of worm-eaters in the fixed phrase.
  • “Accuracy” is the accuracy of a sentence created by applying a word to a fixed phrase specified by a sentence code, and this numerical value changes in the process of transmitting a data entry. If the accuracy falls below a predetermined threshold, the data entry is changed and information uncertainty is increased.
  • the Changing the data entry means that the text code is changed, or that a word to be used is replaced with another word, or is replaced with an abbreviation.
  • 100 is the highest value and 0 is the lowest value.
  • the entity that reduces the accuracy may be either the sending information terminal or the receiving information terminal.
  • “Taro” and “Hanako” are the word codes corresponding to the fixed phrases that have worm-eaten in two places, “That seems to be rival”. It is assumed that it is stored in the indeterminate information DB of the game terminal 1A. Sentences made by combining words with canonical sentences (this is indeterminate information) is "Taro seems to think Hanako is a rival”. Thus, a sentence is completed for each data entry by a combination of a sentence code corresponding to the fixed sentence and a word used in the fixed sentence, and this sentence is propagated as uncertain information 2.
  • the game terminal 1C may check whether the same data entry as the received data entry identifier has already been stored in the indeterminate information DB 21, and store only the data entry. Then, data entries from a plurality of routes (in the above example, data entries that are directly propagated from the game terminal 1A to 1C without going through the game terminal 1B in the game terminal 1C) are not stored redundantly. The amount of storage capacity used can be saved. Also, the data entry received once or the data entry of the source of the own terminal is another source. It is also possible to prevent the game terminal 1 from returning to the game terminal 1 through the game terminal 1 and storing again.
  • FIG. 2 is a block diagram showing a configuration of the game terminal 1.
  • the game terminal 1 includes an input unit 11, a display unit 12, a transmission / reception unit 13, a control unit 14, and a storage unit 20.
  • the control unit 14 includes a game progress management unit 15, a user information management unit 16, and indeterminate information management. Part 17 is included.
  • the game progress management unit 15, the user information management unit 16, and the indeterminate information management unit 17 are realized by a program executed by a CPU (not shown) provided in the control unit 14. However, it can also be realized by a hardware circuit.
  • the game progress management unit 15 displays a game screen on the display unit 12, receives a command input from the player via the input unit 11, and performs processing according to the command. For example, the game progress management unit 15
  • Uncertain information The data entry stored in the database is displayed on the display unit 12, and information indicating the achieved checkpoints among various checkpoints set in the game is stored.
  • the game progress management unit 15 refers to the event database (event DB) 28 in which events generated in the game are stored, and an event flag is set in the data entry of the received indeterminate information. If so, a corresponding event is generated in the game.
  • the input unit 11 corresponds to, for example, the cross key or button in FIG. 1
  • the display unit 12 corresponds to, for example, the screen in FIG.
  • the input unit 11 and the display unit 12 function as an interface with the player.
  • the user information management unit 16 manages the user information 24 of the player stored in the storage unit 20.
  • the user information 24 is data exchanged between the game terminals 1 including the name of the player that identifies the player (or the character operated by the player).
  • the user information management unit 16 accumulates the player's name in the communication history database (communication history DB) 27 among the user information input from the other game terminals 1 via the transmission / reception unit 13.
  • the name of the player stored in the communication history DB 27 is displayed on the display unit 12 and used, for example, when setting a player who is considered a rival.
  • the indeterminate information management unit 17 refers to the checkpoint DB 22 and the user information 24, generates indeterminate information as a data entry, and generates the generated data entry as an indeterminate information database (indeterminate information (DB) 21 and manage the indefinite information DB21 by deleting data entries that are no longer needed due to expiration.
  • the indeterminate information management unit 17 stores the sentence database (sentence DB) 25 in which the fixed sentence and the sentence code are stored in association with each other, the phrase used in the fixed sentence and the sentence.
  • the word candidate database (word candidate DB) 26 that stores words, etc.
  • the change rule database (change rule DB) 23 that stores rules that determine how to change data entries.
  • the data entry is changed, and the changed data entry is stored in the indeterminate information DB21. Further, the indeterminate information management unit 17 selects a data entry to be transmitted to the communication partner game terminal 1 and gives it to the transmission / reception unit 13.
  • the transmission / reception unit 13 has a wireless communication function capable of wirelessly communicating with other game terminals 1 via a communication antenna 10 (see FIG. 1) built in or externally attached to the game terminal 1.
  • the data entry stored in the user information 24 and the indeterminate information DB 21 is transmitted to and received from the communication partner game terminal 1 (hereinafter referred to as communication partner terminal).
  • the communication antenna 10 may be provided as an expansion device connected to the game terminal 1 via an expansion device connector (not shown).
  • the transmission / reception unit 13 When there is a communication partner terminal capable of wireless communication, the transmission / reception unit 13 is obtained via the control unit 14. User information 24 and indeterminate information sent to the communication partner terminal. Then, the transmission / reception unit 13 gives the user information received from the communication partner terminal to the user information management unit 16, and gives the data entry received from the communication partner terminal to the indeterminate information management unit 17.
  • the storage unit 20 includes a terminal control program (not shown), uncertain information DB21, checkpoint DB22, change rule DB23, user information 24, sentence DB25, word candidate DB26, communication history DB27, event DB28, and other game terminals. Stores data necessary for processing performed in 1.
  • the storage unit 20 is a storage unit such as a RAM, a flash ROM, a hard disk, or the like that has been backed up.
  • the data structure for each data stored in the storage unit 20 is as follows: text DB25, user information 24, uncertain information DB21, event DB28, checkpoint DB22, communication history DB27, change rule DB23, word candidate Explanation will be made in the order of DB26.
  • FIG 3 shows an example of the data structure of the sentence DB25 that stores the fixed phrases used for indeterminate information.
  • Sentence DB25 stores “fixed sentences” of worm-eaten states, “sentence codes” for identifying the fixed phrases, and “word items” necessary to fill the fixed phrases of worm-eaten and states. Talk to you.
  • a fixed phrase corresponding to sentence code 001 “has considered to be a rival” has two empty spaces (worm eaters) in the sentence, and is stored in the word It can be seen that the items are “subject” and “rival”. This means that the word used to fill in the worm can be selected from words stored in the word items “subject” and “rhino” in the word candidate DB described later.
  • Text DB25 contains initial fixed text selected when general uncertain information is generated, fixed fixed text selected when data entry is changed during propagation, check set in game Stored are checkpoint correspondence fixed phrases used for indeterminate information generated when the player reaches the point, event flag correspondence fixed sentences for events generated in the game, and the like. Check points and events will be described later.
  • FIG. 4 is a data configuration example of the user information 24.
  • the user information 24 stores user information (principal data) of the player of the game terminal 1 itself.
  • the game progress management unit 15 displays a user information input screen at the start of the game, prompts the player to input, is initially set with the input content, and is input via the input unit 11 during the game execution
  • the game progress management unit 15 displays the called update screen, prompts the player to input, and is updated with the input content.
  • the user information includes data items such as "serial number”, “name”, “gender”, “home”, “rival”, “companion”, and “rare item”.
  • the “serial number” is a number that specifies a storage medium such as a ROM cartridge, CD, or DVD in which a game program is stored.
  • the game program is not provided by the storage medium.
  • the "serial number" may be the device unique number of the game terminal 1.
  • the game program is coded to have a different identification number for each program, that identification number can be used as the “serial number”.
  • Name is a name that identifies a player who plays the game. “Name” may be your real name or a nickname just for playing the game. Select “male” or “male” for “gender”. Players can keep it secret if they do not want to choose either. In this case, “secret” is stored in “sex”.
  • “Home” sets an area where the player usually lives. Once the headquarters is set, uncertain information limited to the region can be obtained. Players can keep it secret if they do not want to set their home base. In this case, “None” is stored in “Home”.
  • “Rival” and “friend” each store the “name” of another player. At the start of the game, there is usually no information regarding the opponent player, and “No Setting” is stored in “Rivals” and “Friends”. In the “rare item”, the name of an item (rare item) that is classified as an item that appears less frequently or is difficult to obtain among items obtained in the game by the player is stored. [0055] When valid values are stored in "rivals”, “companies”, and “rare items”, indefinite information related to them is generated. For example, in battle play, there is a special effect that you can get bonus points when you win a player designated as a “rival”, and you can get the opponent's items.
  • a player designated as a “friend” has a special effect such as being able to take cooperative actions in missions and battle play in the game. Therefore, if this item is set, the player can experience a different development from playing the game alone, so that the fun of the game can be further accelerated and the interest in the game can be maintained. In addition, if uncertain information regarding these items is propagated between the game terminals 1, the user moves in search of a match with the player, and the uncertain information is more likely to spread.
  • FIG. 5A is a data configuration example of the data entry stored in the indeterminate information DB21.
  • the "ID”, “sentence code”, “accuracy”, and “word” explained in Fig. 1 are used, and “transmission limit count”, “transmission remaining count”, “reception limit count” ”,“ Type ”,“ Event Flag ”,“ Expiration Date ”, and“ Region ”.
  • items other than “ID”, “text code”, “accuracy”, and “word” are additional data items for making the game more enjoyable and easy to manage.
  • FIG. 5B is an example of a data configuration of “ID” that is a management number for specifying a data entry.
  • ID is a management number for specifying a data entry.
  • the serial number included in the user information 24 see FIG. 4
  • the date, and the serial number assigned when the data entry is generated by the indeterminate information management unit 17 are connected with a hyphen symbol. Yes.
  • This is what the indeterminate information management unit 17 generates on the date obtained from the serial number obtained from the user information 24 and the clock provided to the game terminal 1 (not shown in FIG. 2). It is obtained by creating an ID with a sequential number indicating the second indeterminate information.
  • the indeterminate information management unit 17 stores the received data entry in the indeterminate information DB 21 when there is no data entry with the same ID. Then, the same data entry is not stored repeatedly. In other words, it is possible to prevent a phenomenon in which a data entry received once or a data entry originating from the terminal itself loops back through another game terminal. As a result, it is possible to prevent a situation in which the player is confused by receiving data entries in which the data entries repeatedly circulate repeatedly between the same game terminals and become unclear each time they are received.
  • the “text code” is a text code that identifies the “standard text” stored in the text DB 25 of FIG. “Word” is a phrase, word, or the like for filling in the worm-eaten of a fixed phrase specified by “text code”.
  • Uncertain information is provided to the player by combining the fixed phrase specified by the “text code” and “word”. For example, if “Sentence Code” is “001” and “Taro, Hanako” is stored as “Word”, refer to the fixed phrase corresponding to Sentence Code 001 in FIG. When Hanako is regarded as a rival, the text “Rarashi” is created and provided to the player as uncertain information.
  • “Accuracy” is a numerical value indicating the accuracy of indeterminate information. This numerical value is set to 100 as an initial value, and decreases as uncertain information propagates between game terminals 1. The data entry is changed when the accuracy falls below a predetermined threshold.
  • the same content as when the indeterminate information is generated is propagated to the game terminal 1 that is closer in time or distance to the source of the indeterminate information.
  • the game terminal 1 that is far away from the mobile phone has the effect that the content with increased ambiguity propagates.
  • the subject that reduces the accuracy may be either the game terminal 1 on the transmission side or the reception side.
  • Transmission limit number indicates the number of times that a data entry can be transmitted to another game terminal 1.
  • the “remaining transmission count” is set with the “transmission limit count” as an initial value, and is decreased by 1 each time a data entry is transmitted to another game terminal 1.
  • Information with “Remaining transmission number” set to 0 is not transmitted any more.
  • “Reception limit number” is a numerical value indicating the number of times reception is possible. Game terminal 1 receives When storing the data entry in the indeterminate information DB, the value is decremented by one. Then, the information whose reception count power SO is not transmitted any more. Unless otherwise specified, the “reception limit count” and “transmission limit count” are set to predetermined values, for example, 3 times each. If specified by input, that value is used. The “transmission limit count”, “transmission remaining count”, and “reception limit count” function as transfer count information for preventing data entries from being spread infinitely. The situation is explained in the next figure.
  • FIG. 6 is a diagram for explaining that information diffusion is limited by the transmission limit number, the reception limit number, and the remaining transmission number. Assume that there is a data entry that is set to 3 transmission limits and 3 reception limits. Depending on the maximum number of transmissions, the game terminal 1 of the player A can transmit this data entry to the three game terminals 1, which are transmitted to the game terminals 1 of the players B, C, and D, respectively. Each time one transmission is made, the remaining transmission number stored in the game terminal 1 of the player A is decremented by 1, and when the data entry is transmitted to the game terminal 1 of the player D, the remaining transmission number becomes 0. The data entry is not transmitted from the game terminal 1 to any other game terminal 1 any more.
  • the reception limit number is updated to a value reduced by one.
  • the game terminal 1 of the player B that has received the data entry from the player A can also transmit this data entry to the other three game terminals 1. In this way, the game terminal power of the player B is also transmitted to the game terminals 1 of the players E, F, and G.
  • the reception limit count is updated to a value reduced by one.
  • the player E's game terminal 1 power is also updated to a value obtained by reducing the reception limit number by one by sending a data entry to the game terminals 1 of the players H, I, and J.
  • the reception limit count is zero. Therefore, the propagation of this data entry stops here, and this information is no longer spread. The same is true for the information transmitted to Player C and Player D.
  • Information of 3 transmission limit times and 3 reception limit times is propagated to 27 information terminals. When generalized, it propagates to X powers of y (X: transmission limit count, y: reception limit count) It will be. Thereby, the number of information to be spread can be limited in advance. In other words, annoying behavior equivalent to spam mail and chain mail can be prevented.
  • Type is information indicating the type of data entry. For example, 0 means a data entry about a rival, 1 means a data entry about a peer, 2 means a data entry about the progress of a game, and 3 means a data entry that is not changed by propagation. Data entry.
  • a data entry related to a rival is generated when a certain player sets another player as a linole on the game terminal.
  • the data entry related to a friend is generated when one player sets another player as a friend on the game terminal.
  • the data entry relating to the progress of the game is generated when the player reaches the check point set in the game.
  • the data entry which does not change due to propagation, is called demarcation information, and includes, for example, official information announced by the game vendor and information for notifying that an event will occur in the game in conjunction with the program.
  • the data entry changes in the process of propagation, and if the “type” is 3, the data entry does not change.
  • all information generated by the game terminal 1 is indeterminate information other than “type” of 3. It is.
  • a case where a data entry having “type” force S3 is generated will be described in the second embodiment. Note that the number of types is not limited to four, and can be freely set by the person who executes this information transmission method.
  • Event flag is flag information used to generate an event in the game in conjunction with the game program. If the value is 1, an event is set, and if 0, an event is set. This means that no event is set. An event to be generated corresponding to an event flag is coded in advance in the program, and if the event flag is set in the received information, the corresponding event is generated in the game.
  • Figure 7 shows an example of the data structure of the event DB 28 that stores the contents of events that occur in the game in response to received data entries.
  • the text code included in the received data entry the content of the event corresponding to the text code, and the flag information indicating whether the event has been triggered, an “on'off flag” Stored in association.
  • the last data entry has an event flag of 1, indicating that the data entry includes some event.
  • the value of the sentence code is 1001.
  • the game progress management unit 15 searches the text DB 25 in FIG. 3 and the event DB 28 in FIG. 7 with the value of the text code included in the received data entry, and notifies the player via the display unit 12 ⁇ Indefinite information is provided that it seems that you will get a rare item power S if you win 5 consecutive wins.
  • the game progress management unit 15 After being displayed on the display unit 12 and the player confirming the data entry, the game progress management unit 15 "provides a rare item of a gold medal if the other player wins five consecutive times within the information acquisition month" t , Generate an event and change the “ON'OFF flag” in Fig. 7 to ON.
  • the “expiration date” is information indicating a period and date for which the data entry is valid.
  • a data entry with an expiry date becomes invalid after a certain period of time. Since invalid data entries are not transmitted any more, there is also an effect of preventing unnecessary spread of data entries.
  • a data entry with an expiration date is propagated as confirmation information to attract the player's interest in the game. Good
  • “Region” is information indicating the diffusion range of the data entry. For example, prefectural units and Become. The region is used together with the “Home” (see Figure 4) included in the user information. For example, if Tokyo is selected as the “region”, it is possible to transmit information only to players whose “base” matches that of Tokyo. In this way, it is possible to create data entries that spread within a specific region and data entries that spread nationwide.
  • Figure 8 shows an example of the data structure of checkpoint DB22.
  • checkpoint code “on / off flag”, “sentence code”, “word”, and “condition” for specifying the checkpoint are stored in association with each other.
  • Fig. 9 shows an example of the data structure of the communication history DB27.
  • the communication history DB 27 communicated with the player name (“name” in FIG. 4) extracted from the user information transmitted from the other game terminal 1 that has communicated with the game terminal 1 in the past. Stores the date and time. If the communication date is recorded and there is not enough storage capacity, the oldest is deleted.
  • Figure 10 shows the data in the change rule database that stores how data entries are changed.
  • FIG. The change rule DB23 in Fig. 10 shows that each sentence code included in the received data entry ("Received sentence code”) is classified as “Accuracy” and the sentence code when the accuracy is included in that classification. (“Text code after change”) and "word item” used in the fixed phrase corresponding to "text code after change” are stored. “Accuracy” in FIG. 10 is an accuracy reference value set in advance for each fixed sentence, and it is determined whether to change the data entry according to the category to which the accuracy of the received data entry belongs.
  • Figure 11 shows an example of the data structure of the word candidate DB26 used when changing the data entry in a different way from that in Figure 10.
  • words after replacement a plurality of candidates that can replace the word of the item in the data entry.
  • Numberer is an identification number for specifying “word after replacement” when “word item” is specified.
  • “Subject and rival” is the name of the communication partner stored in the communication history DB 27 shown in FIG. That is, when communication with another game terminal 1 is performed, the name of the communication partner is stored in the “subject and rival” column of the word candidate DB 26 together with the communication history DB 27. Paid.
  • the word candidate DB26 in FIG. 11 is referred to when changing the data entry by replacing some words without changing the sentence code. For example, suppose that the sentence code is 001, and the data entry with the subject “Taro” and the rival “Nonako” is stored in the indefinite information DB 21 as the word corresponding to the fixed sentence of the sentence code. When the accuracy is less than the predetermined threshold, the indeterminate information management unit 17 searches the sentence DB25 of Fig. 3 for the sentence code of the received data entry, and obtains the word item that is used! To do.
  • the indeterminate information management unit 17 selects an item to be changed from this item.
  • One or more items may be changed. For example, to change only the “subject”, search the “word item” in the word candidate DB of FIG. 5 with “subject”, and the indeterminate information management unit 17 selects the corresponding “word after replacement”. Select one word from and replace.
  • FIG. 12 is a flowchart for explaining the operation of the game terminal in the first embodiment.
  • the checkpoint is added to the game terminal 1.
  • DB22, change rule DB23, sentence DB25, word candidate DB26, event DB are copied.
  • the word candidate DB26 that is copied during installation is the initial data recorded in the program, and as the game progresses, new data (names of players who exchanged indeterminate information, Place etc.) is added.
  • the indeterminate information management unit 17 accumulates data entries to be propagated as indeterminate information in the indeterminate information DB 21 (Sl).
  • the data entry is stored on the game terminal.
  • the processing of step S1 is interrupted when data entry is received when indeterminate information is generated, and the original processing is resumed when data entry accumulation is completed.
  • there are multiple types of processes for generating uncertain information details of which will be described later with reference to FIG.
  • the indeterminate information management unit 17 determines whether there is another game terminal that can communicate with the game terminal via the transmission / reception unit 13 (S2). If there is no communicable game terminal (S2 No), the process returns to step S1 and waits for the communicable game terminal to move within the communication range.
  • the indeterminate information management unit 17 sends the user information 24 of the own terminal and the data entry of the indeterminate information DB21 to the transmission / reception unit 13.
  • the transmission / reception unit 13 transmits them to the communication partner terminal (S3). It may be limited by the number or data size that does not output all data entries.
  • the transmission / reception unit 13 receives the user information of the communication partner terminal and outputs the user information to the user information management unit 16, and the user information management unit 16 displays the “of the communication partner terminal player included in the user information”.
  • Store “Name” see Figure 4
  • the transmitting / receiving unit 13 receives the communication partner terminal power data entry and outputs it to the indeterminate information management unit 17 (also S3).
  • the indeterminate information management unit 17 updates the accuracy of the received data entry to a value reduced by a predetermined number (S4).
  • the accuracy (predetermined number) to be reduced once is a predetermined value (for example, the accuracy is decreased by 20 each time), which may be different for each force data entry or different for each game terminal. .
  • the data structure of the uncertain information DB shown in FIG. This is realized by reducing the value stored in the “predetermined number” from the “accuracy” by the game terminal 1 for each received data entry.
  • a predetermined number is stored in advance in the storage unit 20 of the game terminal 1, and the game terminal 1 reduces the predetermined number stored in the storage unit 20 from the “accuracy” of the received data entry.
  • the predetermined number can be changed every time.
  • the indeterminate information management unit 17 compares the accuracy updated in step S4 with a predetermined threshold, and when the accuracy falls below the predetermined threshold (S5 Yes), changes to the received data entry are made. After completion of the process is performed (S6) 0 step S6, the process proceeds to step S1, indeterminate information management unit 17 stores the data entry change processing is performed in the uncertain information DB. In step S5, if the accuracy is equal to or greater than the predetermined threshold (S5 No), the process proceeds to step S1, and the indeterminate information management unit 17 stores the received data entry as it is in the indeterminate information DB.
  • step S6 There are a plurality of types of modification processing for the received data entry in step S6, and the details will be described later with reference to FIG. In addition, how to set the predetermined threshold value in step S6 varies depending on the data entry changing process, which will also be described with reference to FIG.
  • step S1 of FIG. 1 An operation example in the game terminal 1 when the indeterminate information is generated as a data entry and stored in the indeterminate information DB 21 will be described. This is included in step S1 of FIG.
  • FIG. 13A is a flowchart for explaining a case where uncertain information is generated as a data entry in accordance with creation and update of user information.
  • the game progress management unit 15 displays a user information creation / update screen via the display unit 12 (S101). On this screen, you can enter values for user information data items (see Figure 4). Then, the input value is stored in the storage unit 20 as user information 24 shown in FIG. 4 (S102).
  • the indeterminate information management unit 17 periodically monitors the update of the user information 24, and checks whether "rival”, “companion”, and "rare item” are set among the data items of the user information 24. Judgment is made (S103). If the update power of the user information 24 is not for these three items (S10 3No), the process proceeds to step S2 in FIG.
  • the indeterminate information management unit 17 If the update of the user information 24 is for these three items, the indeterminate information management unit 17 generates a data entry and stores it in the indeterminate information DB 21 (S 104). Uncertain The information management unit 17 searches for “word item” in the sentence DB2 5 of FIG. 3 using the data item set in step S103 as a key, and selects one “sentence code” of the matching entry. The uncertain information management unit 17 searches for “rivals” if “rivals” is set, searches for “mates” if “comrades” is set, and sets “rare items” if “rare items” is set. Search for “items” and select those that match these items or are paired with the subject.
  • the reason why the set with the subject is included is that the name of the player can be obtained by checking the user information, so that the "subject” can be used freely.
  • the item strengths of the words in Fig. 3 “Rivals”, “Friends”, “Items”, “Subjects, rivals”, “Subjects, companions”, “Subjects, Items” are selected. . In this way, the “text code” is determined.
  • the value input in step S1 is used. “Accuracy” is set to 100 as an initial value. There is no specific specification for “transmission limit number” and “reception limit number”, so a predetermined initial value (for example, three times each) is set. The “transmission remaining number” is set to the same value as the “transmission limit number” as an initial value. “Type” is set to 0 indicating indefinite information here.
  • the "event flag” is set to 1 if the selected sentence code is included in the event DB of FIG. 7, otherwise set to 0.
  • “Expiration date” and “Region” are set to “No setting” here.
  • the “ID” is created based on the serial number of the user information, date, and uncertain information generated on that day. Thus, one data entry is generated and stored in the indeterminate information DB 21.
  • FIG. 14 is a screen example in step S101 of FIG. 13A. That is, the display contents controlled by the game progress management unit 15 when the user information 24 is created / updated are drawn.
  • the game terminal 1 when the game terminal 1 is turned on, the title and menu are first displayed (screen 61).
  • RPG Roll Playing Game
  • select Menu 1 New Start
  • select Menu 2 Start from Recording
  • menu 1 When menu 1 is selected, a screen for creating new user information is displayed (screen 62).
  • the name of the character operated by the player the gender of the character operated by the player, the prefecture where the player lives (the headquarters), the rhino record Enter information, friend information, and acquired rare items. Only the “Name” entry is required.
  • the game is started (screen 63). If menu 2 is selected on screen 61, the name already registered for the program is displayed, and when the player selects a name from that, the game where the play was interrupted with the selected name is resumed. (Screen 65).
  • the screen 63 displays an in-game menu 141 that is called by operating the input unit 11 while the game is running, and displays the current user information 24 by selecting the item “User Information Display”. (Screen 64).
  • the user information 24 can be updated by calling the in-game menu 141 shown on the screen 63. Based on this update, indefinite information is generated as described in FIG. 13A.
  • FIG. 15 is an example of a screen displayed when the item “update user information” is selected on the screen 63 of FIG.
  • a menu for selecting an item to be updated is displayed (screen 66). For example, when setting a rival, 3 is selected from the menu and the screen switches to the rival input screen (screen 67).
  • screen 69 appears, allowing you to directly enter the name of the rival player.
  • screen 68 is displayed, and the names of communication partners stored in communication history DB27 are displayed in a list, from which rivals are selected.
  • rival selection is completed on screen 68 or screen 69, it is displayed that rival settings are complete (screen 70).
  • FIG. 13B is a flowchart for explaining a case where uncertain information is generated as a data entry in accordance with the checkpoint reached by the player as the game progresses.
  • the indeterminate information management unit 17 periodically monitors the update of the checkpoint DB 22, and determines whether there is an on-off flag switched to "ON" (SI 13). If the checkpoint DB 22 update is not an on / off flag update (S113 No), for example, if a new checkpoint is added or a sentence code is changed, proceed to step S2 in Fig. 12. .
  • the indeterminate information management unit 17 If there is an ON / OFF flag switched to "ON" due to the update of the checkpoint DB, the indeterminate information management unit 17 generates a data entry and stores it in the indeterminate information DB (S114).
  • the indeterminate information management unit 17 sets “sentence code” and “word” of the checkpoint code switched to “ON” in step S3 to “sentence code” and “word” of the data entry.
  • the “name” see FIG. 4 of the player who can obtain the user information ability is stored.
  • the other items are the same as in FIG. 13A, and the explanation is omitted.
  • one data entry is generated and stored in the indeterminate information DB21.
  • FIG. 13C is a flowchart for explaining a case where the data entry of the indeterminate information is generated by the player directly inputting the value for each item of the data entry.
  • the game progress management unit 15 displays an indeterminate information input screen via the display unit 12 (S121). On this screen, you can enter values for the data items of the data entry.
  • the input value is given to the indeterminate information management unit 17, and the indeterminate information management unit 17 stores it in the indeterminate information DB 21 as a data entry (S122).
  • FIG. 16 shows an example of the screen in step S1 of FIG. 13C. That is, the display contents controlled by the game progress management unit 15 when the uncertain information is input by the user are drawn.
  • the indeterminate information input screen is displayed first (screen 71). This is the screen displayed when the item “input indeterminate information” is selected on screen 63 in FIG.
  • a player who has received indeterminate information created based on a checkpoint may, for example, obtain the rumors that another player may have reached an unknown area. Driven by the desire to go there and see what happens, you can try to play the game deeper and keep your interest in the game longer. In addition, this information can be helpful hints for game beginners.
  • FIG. 17 shows steps obtained by subdividing the transmission / reception processing.
  • the game terminal acquires user information from the communication partner game terminal, and extracts the serial number contained therein (S301). Subsequently, which game terminal transmits the data entry first is determined as the terminal order (S302).
  • the terminal rank in step S302 is determined based on the priority set in the data entry. Here, it is assumed that a data entry having a higher number assigned to the “type” of data entry has a higher priority. Then, each game terminal calculates the total value of the priorities of all data entries stored in the indeterminate information DB, and exchanges the total value. [0129] The total value is larger! /, The terminal ranking is higher, and the game terminal is higher. In step S302, the game terminal performs processing in the order of high ranking, transmission processing (S303), and reception processing (S304), and the low ranking game terminal performs reception processing (S304) and transmission processing (S303). ), The transmission / reception process ends. The flow shown in Fig. 17 shows the former.
  • an average value obtained by dividing the total priority value not the total priority value by the number of data entries stored in the uncertain information DB may be used. it can.
  • the game terminal having more data entries with the highest priority for example, the one with the larger number of data entries having “type” of 3) may be determined as the terminal with the highest terminal ranking.
  • Fig. 18A shows the case where the forbidden loopback processing is performed at the time of transmission using the serial number.
  • a data entry to which a data item “transfer history” is further added is used. Which transmission process is applied is determined in advance, so use the appropriate data entry for that decision.
  • the game terminal that received the data entry obtains the serial number (determined by the storage medium inserted at that time) by referring to the user information 24 of the own terminal. And the date and time are recorded in the “transfer history” of the received data entry. In this way, by looking at the “transfer history” of a data entry, it is possible to grasp the details of the propagation of that data entry.
  • the uncertain information management unit 17 determines the data entry to be transmitted from now on. Read from the information DB and refer to the “transfer history” of the data entry. Then, it is checked whether or not the “transfer history” includes the serial number related to the opponent game terminal acquired in step S301 (S331). If the serial number acquired in step S301 is included in “Transfer history” (S331 Yes), transmission is not performed (S334), and the serial number acquired in step S301 is included in “Transfer history”. If not (S331 No), the data entry is transmitted (S333). In this way, it is possible to prevent the player who once acquired the data entry from seeing the same information and to prevent confusion.
  • the data entry may be presented to the player again after a predetermined time has elapsed. Even if a data entry that has been received in the past is received again after a sufficient amount of time has passed, the player will not be confused by the data entry, but conversely, he will have a sense of strength. This is to bring about the effect of recalling or forgetting information that has been forgotten. For example, the data entry triggered the player to remember the current situation of the town, people, events, etc. in the game that attracted attention, or the player was curious about the current situation, and the player could not search the game again. .
  • step S332 is provided for determining whether the previous receiving power has also passed the predetermined time, and the predetermined time has passed. If so (S332 Yes), the data entry may be transmitted (S333). In step S332, if the predetermined time has not elapsed (S332 No), there is still a possibility that the player is confused, and the data entry is not transmitted (S334).
  • the predetermined time in step S332 can be set to 6 months, for example.
  • the indeterminate information management unit 17 repeats the process of Fig. 18A.
  • the number and selection of data entries to be transmitted can be freely set using data items included in the data entries. Therefore, for example, using the date information included in the “ID” of the data entry, the system designer (system operator) can control the transmission policy for sending 10 latest data entries.
  • FIG. 19 is a diagram for explaining an example in which the processing of FIG. 18A is specifically performed.
  • terminal A When terminal A receives the data entry, it is inserted into terminal A in the “transfer history” of the data entry. Record the serial number and date / time of software A.
  • the transfer history 191 represents the "transfer history" when the terminal A receives the data entry.
  • the data entry indicated by the transfer history 191 indicates that the software X is also the source of the serial number described at the top. And since it is the next serial number software A, it can be seen that it is a data entry propagated from the source to terminal A where software A was inserted directly.
  • terminal A when terminal A becomes communicable with terminal B and transmits a data entry, terminal A obtains user information of terminal B and uses the software serial number inserted into terminal B. Extract (step S301 in FIG. 17). Then, since the transfer history of the data entry is not described in the serial number power transfer history 191 of the software B inserted into the terminal B that is the communication partner game terminal, the terminal A transmits this data entry to the terminal B. (FIG. 18A Step S331No ⁇ S333).
  • terminal B Upon receiving this data entry, terminal B records the serial number and date of software B inserted in terminal B in the "transfer history".
  • the transfer history 192 represents the “transfer history” when the terminal B receives the data entry.
  • terminal B when terminal B becomes communicable with terminal C and transmits a data entry, the serial of software C inserted into terminal C, which is the communication partner game terminal, in the transfer history of the data entry. Since it is not listed in the number power transfer history 192, terminal B sends this data entry to the terminal.
  • Transfer history 193 represents “transfer history” when terminal C receives the data entry in the same manner as described above. At this time, even if the terminal C and the terminal A become communicable, the data entry transfer history is described in the serial number power transfer history 192 of the software A inserted in the terminal A which is the communication partner game terminal. Therefore, terminal C does not transmit a data entry to terminal A (FIG. 18A, step S331 Yes ⁇ S334).
  • step S332 Yes in FIG. 18A when transmitting from terminal C to terminal A, it is determined whether a predetermined time has elapsed, and if it has elapsed (step S332 Yes in FIG. 18A), the data entry may be transmitted. Na Yes.
  • the game terminal acquires the event DB of the communication partner game terminal (S335). Then, the indeterminate information management unit 17 reads the data entry to be transmitted from the indeterminate information DB and refers to the “event flag” of the data entry. If the “event flag” indicates that it is ON (for example, the value 1 is stored), the communication partner game terminal acquired in step S335 is used using the text code of the data entry. The state of the “ON / OFF flag” in the event DB of is checked (S336). If the on-off flag of the communication partner game terminal is off (S336 No), it means that an event related to the data entry to be transmitted has not occurred in the communication partner game terminal, so that data entry is transmitted. (S333).
  • the indeterminate information management unit 17 repeatedly performs the process of FIG. 18B.
  • FIG. 20 is a diagram for explaining an example in which the process of FIG. 18B is embodied.
  • the event DB 20 1 is obtained by extracting the state of the event DB of the terminal A at a certain time.
  • the event DB 201 indicates that the data entry corresponding to the text code 1001 has been received and that an event related to it has occurred.
  • terminal A when terminal A becomes communicable with terminal B and transmits a data entry whose sentence code is 1001, terminal A obtains event DB 202 of terminal B (FIG. 18B, step S335). ). Then, when it is confirmed in the event DB 202 of terminal B that the “on'off flag” of the entry corresponding to the text code 1001 is off, terminal A transmits this data entry to terminal B (FIG. 18B, step S336No ⁇ S333).
  • terminal B when terminal B becomes communicable with terminal C and transmits this data entry, terminal B obtains terminal C's event DB 203, and the sentence code is 1 in event DB 203. When it is confirmed that the “on'off flag” of the entry corresponding to 001 is off, terminal B transmits this data entry to terminal C.
  • Terminal C does not send a data entry to terminal A because “on'off flag” of the entry corresponding to sentence code 1001 is already on in event DB201! ( Figure 18
  • Fig. 21A uses the ID for identifying each data entry (see Fig. 5A) to perform forbidden loopback processing upon reception.
  • the indeterminate information management unit 17 checks whether or not a data entry having the same ID as the “ID” of the received data entry has already been stored in the indeterminate information DB (S341). If it has not been stored yet (S341 No), the received data entry is stored in the indeterminate information DB (S343), and if it has already been stored (S341 Yes), the received data entry is discarded (S344). In this way, it is possible to prevent the player who has once acquired the data entry from seeing the same information and to prevent confusion.
  • step S342 the data entry may be stored (S343).
  • step S342 if the predetermined time has not passed (S342N ⁇ ), there is still a possibility that the player is confused, and the data entry is discarded (S344).
  • the predetermined time in step S342 can be set to 6 months, for example.
  • FIG. 21B is a diagram in which forbidden loopback processing is performed at the time of reception using a serial number.
  • the indeterminate information management unit 17 refers to the “transfer history” of the received data entry.
  • serial number included in the user information of the receiving terminal is included in the “transfer history” (S345). If the serial number of the terminal is included in the “transfer history” (S345 Yes), the received data entry is discarded (S334), and the serial number of the terminal is included in the “transfer history”. In the case (S345 No), the serial number and date / time of the terminal itself are recorded in the “transfer history” of the received data entry, and the data entry is stored (S343). In this way, it is possible to prevent the player who has once acquired the data entry from seeing the same information and to prevent confusion.
  • step S342 for determining whether or not the previous receiving power has also passed the predetermined time is provided, and the predetermined time has passed. If so (S342 Yes), the data entry may be stored (S343).
  • step S342 if the predetermined time has not elapsed (S342 No), there is still a possibility that the player is confused, and the data entry is discarded (S344).
  • the predetermined time in step S342 can be set to 6 months, for example.
  • the indeterminate information management unit 17 repeats the process of Fig. 21B.
  • FIG. 22 is a diagram for explaining an example in which the process of FIG. 21B is specifically performed.
  • the transfer history 221 represents a transfer history when a data entry with a terminal A is transmitted to a terminal B.
  • Terminal A directly receives the data entry originating from software X as well as the serial number described at the beginning of the transfer history, and also the serial number of software A inserted in its own terminal and the reception date. It can be seen that was recorded.
  • Terminal B includes the serial number of software B inserted into terminal B in the “transfer history” of the received data entry, so that it is inserted into terminal B! The serial number and date are recorded in the “transfer history”, and the received data entry is stored in the indeterminate information DB of terminal B (step S345 No ⁇ S343 in FIG. 21B).
  • the transfer history 222 represents the transfer history when the terminal B transmits the data entry to the terminal C.
  • Terminal C contains the serial number of software C inserted into terminal C in the “transfer history” of the received data entry! /, NA! /, So that software C is inserted into terminal C!
  • the serial number and date are recorded in the “transfer history” and the received data entry is stored in the indeterminate information DB of terminal C.
  • Transfer history 223 represents a transfer history when terminal C transmits its data entry to terminal A. Since terminal A contains the serial number of software A inserted into terminal A in the “transfer history” of the received data entry, terminal A discards the data entry (FIG. 21 B step S 345 Yes ⁇ S 344 ).
  • step S342 Yes in FIG. 21B when transmitting from terminal C to terminal A, it is determined whether a predetermined time has elapsed, and if it has elapsed (step S342 Yes in FIG. 21B), processing may be performed to store the data entry. Absent.
  • the indeterminate information management unit 17 obtains the sentence code included in the received data entry, and refers to the "on'off flag" of the entry corresponding to the sentence code in the event DB of its own terminal ( S346). If the ON flag is off (S346 No), it means that the event related to the received data entry has not occurred yet, so that the data entry is stored in the indeterminate information DB and the event The “on / off flag” of the corresponding entry in the DB is turned on, and the event is triggered (S347). However, if the ON'OFF flag is ON (S346Yes), the data entry has already been received and the corresponding This means that the event has already occurred, and the data entry is discarded (S344).
  • FIG. 23 is a diagram for explaining an example in which the process of FIG. 21C is embodied.
  • the event DB 23 1 is obtained by extracting the state of the event DB of the terminal A at a certain time.
  • the event DB 231 is informed that a data entry corresponding to a text code of 1001 has been received and an event related thereto has occurred.
  • terminal B obtains its own event DB232 and terminal B's event
  • DB232 When it is confirmed in DB232 that the “on / off flag” of the entry corresponding to the sentence code 1001 is OFF, this data entry is stored and the entry corresponding to the sentence code 1001 is updated to ON (FIG. 21C).
  • Step S346No ⁇ S347) When “On'off flag” is turned on, an event corresponding to the sentence code 1001 occurs on terminal B.
  • terminal C obtains its own event DB 233 and writes the text code at event DB 233. If the “ON / OFF flag” of the entry corresponding to 1001 is confirmed to be OFF, terminal C stores this data entry.
  • terminal A already has an "ON 'OFF flag" for the entry corresponding to the sentence code 1001 in event DB231. Since terminal A is on, terminal A discards the data entry (FIG. 21C, step S346No ⁇ S344).
  • FIG. 24A is a flowchart for explaining the case where the data entry is changed based on the rule stored in the change rule DB23.
  • the indeterminate information management unit 17 changes the change rule when the accuracy of the received data entry is reduced to a value below a predetermined threshold.
  • the indeterminate information management unit 17 updates the "sentence code” and "word” of the received data entry to the "sentence code” and "word” determined in step S1 (S602), In step S1, the data entry is stored in the indeterminate information DB21.
  • the change rule DB in Fig. based on the change rule DB in Fig.
  • FIG. 24B is a flowchart for explaining a case where the data entry is changed by changing the standard text to another standard text.
  • the indeterminate information management unit 17 specifies the item of the word used in the fixed phrase corresponding to the sentence code of the received data entry when the accuracy of the received data entry is reduced and becomes less than the predetermined threshold. (S611). For example, if the text code of the received data entry is 004, referring to the text DB25 in FIG. 3, it is obvious that “enemy, item” is used as the first item.
  • the indeterminate information management unit 17 selects from the sentence DB a fixed phrase having the same word item as the word item specified in step S1 (S612). Then, the “sentence code” corresponding to the fixed sentence is determined. For example, the same “enemy, item” as above If you refer to the sentence DB25 in Fig. 3 as a fixed phrase, you can list the fixed sentence with the sentence code 006.
  • step S1 the "sentence code” of the received data entry is updated to the "sentence code” of the fixed phrase selected in step S2 (S613), and the process proceeds to step S1, where the indeterminate information management unit 17 Uncertain information Stores the data entry in DB21.
  • the data entry corresponding to the indefinite information that "It seems that you can get a scroll when you kill the demon” that is, the sentence code is 004 and the word is "Demon, scroll”
  • it becomes a data entry corresponding to the indefinite information that “Daemon seems to be able to defeat using a scroll” that is, sentence code power ⁇ 006 ⁇ change).
  • FIG. 25 is a screen example when the fixed sentence is changed to another fixed sentence as shown in FIGS. 24A and 24B.
  • Indeterminate information is collected, for example, when the game is activated (screen 71). In this case, when the power to the game terminal 1 is turned on, a force determination is made that has a game terminal 1 capable of communicating in the vicinity (S2 in FIG. 12).
  • the game progress management unit 15 displays that fact (screen 73).
  • the data entry of indeterminate information is expressed as rumors and notified to the player.
  • Indeterminate information can also be collected during game play (screen 72). For example, the screen 72 is displayed when the item “acquire uncertain information” is selected in the in-game menu 141 on the screen 63 in FIG. If “Yes” is selected on the screen 72, the process proceeds to the screen 73.
  • FIG. 25 the force displayed in two separate directions is displayed.
  • the left column is the data entry before the data entry is changed.
  • the right column is the data entry is changed in the process of propagating the data entry between the game terminals. It is a state after.
  • a data entry for indeterminate information is received, the date received, name of the communication partner, and title are displayed in a list (screen 74, screen 76). If you select indeterminate information you want to check from the list, its contents are displayed (screen 75, screen 77). From Fig. 25, it can be seen that the displayed text differs before and after the change depending on the change of the text code and word of the data entry.
  • FIG. 24A and FIG. 24B are for changing the fixed sentence
  • FIG. 24C is a flowchart for explaining the case where the data entry is changed by replacing the word used in the fixed sentence.
  • the indeterminate information management unit 17 when the indeterminate information management unit 17 reduces the accuracy of the received data entry and becomes less than a predetermined threshold, it identifies a fixed phrase corresponding to the sentence code of the received data entry.
  • the word item used in the fixed phrase is selected (S621). For example, if the sentence code of the received data entry is 501, refer to the sentence DB25 in Fig. 3 and find that "subject, place, enemy, item” is used as the word item.
  • the indeterminate information management unit 17 generates a random number, calculates the remainder obtained by dividing the random number by the number of items in the word, and selects the corresponding item according to the selection. do it.
  • the number of items is power, if the remainder of dividing the random number by 4 is 0, select “Subject”; if 1, select “Location”; Select “Enemy”, and if it ’s 3, select “Item”.
  • the indeterminate information management unit 17 may select a plurality of words to be replaced at a time.
  • the indeterminate information management unit 17 selects the “word after replacement” corresponding to the word item selected in step S621 from the word candidate DB 26 of FIG. 11 (S622). For example, “Ryujo Castle” is selected from the four word candidates (Onigashima, Ryugu Castle, Kanmura, and Minatomachi) listed in “Place” in Fig. 11. The selection in step S622 may be performed using the random number described in step S621 as an example. Then, the indeterminate information management unit 17 updates only the word of the received data entry by replacing only the word item selected in step S621 with the “replaced word” selected in step S622. (S623), go to step S1, and store the data entry in the indeterminate information DB21.
  • “Ryujo Castle” is selected from the four word candidates (Onigashima, Ryugu Castle, Kanmura, and Minatomachi) listed in “Place” in Fig. 11.
  • the selection in step S622 may be performed using the random number described in step
  • FIG. 26 shows an example of a screen when words are replaced.
  • the indeterminate information shown on the first screen 78 changes as screen 79 ⁇ screen 80 ⁇ screen 81 in the process of propagation between game terminals.
  • here is a numerical value that is simply calculated as (reception limit number + 1) * 25 as an example. Display this credible number to the player as a reference value.
  • FIG. 24D is a flowchart for explaining a case where a data entry is changed by partially using a word used in a fixed phrase as a hidden character.
  • the indeterminate information management unit 17 specifies a fixed phrase corresponding to the sentence code of the received data entry, and uses that fixed sentence.
  • the word item to be used is selected (S631). For example, if the sentence code of the received data entry is 501, referring to the sentence DB25 in FIG. 3, it can be seen that “subject, place, enemy, item” is used as the word item. Select "Location".
  • the selection in step S631 may be performed by the random number described in step S621.
  • the indeterminate information management unit 17 selects a plurality of words to be abbreviated.
  • the indeterminate information management unit 17 converts a part of the word corresponding to the selected word item into a prone character (S632). For example, if the value “Onigashima” is stored as “Place”, two of the three characters are converted to Fuzzy characters (in this case, they are displayed as American signs). The number and position of the characters to be abbreviated may be arbitrary. Then, the indeterminate information management unit 17 updates the word by replacing only the word item selected in step S631 with the word partially converted in step S632 in the received data entry word ( Proceed to step S633), and store the data entry in the indeterminate information DB.
  • FIG. 27 shows an example of a screen in the case where a part of a word is made a hidden character.
  • the indeterminate information shown on the first screen 82 changes in the process of propagation between game terminals as screen 82 ⁇ screen 83 ⁇ screen 84.
  • the force with the number credibility displayed is the same as shown in Figure 26.
  • substitution of prone characters has progressed more than screen 85, and the uncertainty is increased.
  • the accuracy is defined as a value that is, for example, an initial value of 100 and is reduced by a predetermined number (for example, 20) each time it is received.
  • a predetermined number for example, 20
  • the authenticity it may be a value calculated based on the transfer count information ("reception limit count” etc.)! Further, it may be a value calculated according to the degree of change of the received data entry. For example, if a part of the data entry changes, it can be calculated as (number of characters in the Z number of characters included in the Z sentence) * 100, etc.
  • the accuracy decreases, and if the accuracy is less than a predetermined threshold, the data entry As the information is changed, the information becomes more indeterminate, and the user who acquires it becomes very interested in the authenticity of the information. Then, it is possible to attract interest in programs that are executed by information terminals that check the authenticity of information.
  • the accuracy of the data entry may be reduced at the receiving information terminal, even if it is reduced at the transmitting information terminal.
  • the player can, for example, Get tips on places you have never been to (such as the existence of places and how to get there). In this way, it is possible to reach a place where one player can not capture and enjoy the game deeper. In addition, the player can have curiosity to go to the place in the game and have the game played for a longer time. Also, when the progress status of other players is obtained as indeterminate information, the motivation for playing the game is given to the players who do not want to delay the other players. In addition, you can set up rivals and friends in the game, and if you search for these players in the real world, you will be able to enjoy the game longer and more interesting by motivating you. In addition, with the action of the player in the real world, the game terminal moves and the indeterminate information is more easily propagated.
  • information that you do not want to change according to the data items used in the data entry stored in the indeterminate information DB shown in Fig. 5 (for example, official information published by the manufacturer) Can be transmitted together with information that changes the contents, the same data entry is prevented from looping between information terminals, and the data entry is infinite by setting the range, number of times, and expiration date of the data entry.
  • FIG. 28 is a configuration diagram of an information transmission system in the second embodiment.
  • the server 6 and a plurality of information relay terminals 8 are connected via the Internet 7, and the indeterminate information stored in the server 6 is transferred to the game terminal 1 via the information relay terminal 8. Propagate.
  • the player operates a menu displayed on the information relay terminal 8 to transmit an uncertain information acquisition request to the server 6.
  • the information relay terminal 8 transfers the indeterminate information transmitted from the server 6 to the game terminal 1 of the player who transmitted the acquisition request.
  • uncertain information of each game terminal can be concentrated by using a server.
  • the server is the only entity that can deliver confirmed information whose data entry does not change to the game terminal, and can execute promotion information, a campaign, etc., making the game more interesting.
  • the game terminal Since the configuration and operation are the same as those of the first embodiment, description thereof is omitted.
  • FIG. 29 is a block diagram showing the configuration of the information relay terminal 8.
  • the information relay terminal 8 includes an input unit 31, a display unit 32, a transmission / reception unit 33, a control unit 34, and a storage unit 40.
  • the control unit 34 includes a display management unit 35 and a participating terminal management unit 36.
  • the display management unit 35 and the participating terminal management unit 36 can also be realized by a force S, which is a program module executed by a CPU (not shown) provided in the control unit 34, and a hardware circuit. .
  • the display management unit 35 displays a screen for operating the information relay terminal 8 on the display unit 32, receives a command input from the player via the input unit 31, and displays a screen corresponding to the command.
  • the input unit 31 corresponds to, for example, a keyboard, touch panel, buttons, and the like (not shown) provided in the information relay terminal 8
  • the display unit 32 corresponds to, for example, a liquid crystal screen (not shown).
  • the input unit 31 and the display unit 32 function as an interface with the player.
  • the participating terminal management unit 36 manages a participating terminal database (participating terminal DB) 41 in which information on game terminals that can communicate with the information relay terminal 8 is stored. Participating terminal management unit 36 deletes information on game terminal 1 that has moved out of the communication range of information relay terminal 8 from game terminals 1 stored in participating terminal DB 41, and updates participating terminal DB 41 to the latest state. To do.
  • the participating terminal DB 41 has the address (IPQnternet) of the game terminal 1 required when the information relay terminal 8 transfers the indeterminate information transmitted from the server 6.
  • the transmission / reception unit 33 has a communication function for communicating with the server 6 connected to the Internet 7 and the game terminal 1 gathered at the information relay terminal 8. This may be realized by a wireless communication function via a communication antenna built in the information relay terminal 8 or attached externally, communicates with the game terminal 1 wirelessly, and communicates with the server 6 with a cable. Connected wired communication may be performed.
  • the transmission / reception unit 33 acquires the user information and outputs the user information together with the address to the participation terminal management unit 36, and the player inputs information via the input unit 31.
  • a confirmation information acquisition request is sent to the server 6.
  • the storage unit 40 includes a control program, a participating terminal DB41, relay terminal identification information 42, and others. Data necessary for processing performed at the information relay terminal 8 is stored.
  • the storage unit 40 is, for example, a storage unit such as a not-backed RAM, flash ROM, or hard disk.
  • the relay terminal identification information is, for example, the address (IPdnternet) of the information relay terminal 8 required when the information relay terminal 8 transmits the user information of the game terminal to the server 6.
  • FIG. 30A is a data configuration example of user information in the second embodiment.
  • the server since the server provides indeterminate information about multiple games, the indeterminate information acquired by the game terminal can be unrelated to the game currently running on that game terminal. There is sex. Therefore, in addition to the data items included in the user information shown in FIG. 4, a “game title” is provided that identifies the game program being executed on the game terminal.
  • a description of items that overlap those in FIG. 4 is omitted.
  • the “game title” can identify the power of which indeterminate information relates to which game, and the game terminal receives the received information when the received indeterminate information is irrelevant to the game running on its own terminal. Uncertain information can be discarded.
  • FIG. 30B is a data configuration example of the participating terminal DB 41 in the second embodiment.
  • the participating car terminal DB41 in FIG. 30 includes an “IP address” in addition to the data items included in the user information in FIG. 30A.
  • the “IP address” stores the source IP address acquired from the packet when the information relay terminal 8 acquires the user information from the game terminal 1.
  • the “IP address” is referred to when indefinite information transmitted from the server 6 is transferred to the game terminal 1.
  • FIG. 31 is a block diagram showing the configuration of the server 6.
  • Server 6 includes input unit 51, display unit 52, and input unit 51, display unit 53, and input unit 54, and display unit 55.
  • the control unit 54 includes a display management unit 55, an authentication management unit 56, and an indeterminate information management unit 57.
  • the display management unit 55, the authentication information management unit 56, and the indeterminate information management unit 57 are power hardware circuits that are program modules executed by a CPU (not shown) provided in the control unit 54. It can be realized by
  • the display management unit 55 displays a screen for operating the server 6 on the display unit 52, and the input unit 5 In response to a command input from the server administrator via 1, the screen corresponding to the command is output.
  • the input unit 51 corresponds to a keyboard (not shown)
  • the display unit 52 corresponds to, for example, a liquid crystal screen (not shown).
  • the input unit 51 and the display unit 52 function as an interface with the server administrator.
  • the authentication information management unit 56 authenticates the relay terminal authentication database (relay terminal authentication DB) 63 used for authentication of the information relay terminal 8 that has transmitted the acquisition request for indeterminate information and the player who made the acquisition request. Manages the user authentication database (user authentication DB) 52.
  • relay terminal authentication DB 63 an address (IP address, MAC address, etc.) for identifying the legitimate information relay terminal 8 is stored in advance via the input unit 51.
  • the user authentication DB 62 stores in advance the serial number (see Fig. 4) included in the user information of the user permitted to download the data entry stored in the indeterminate information DB of the server 6.
  • the information stored in these DBs is collated, and it is determined whether transmission of the data entry stored in the indeterminate information DB 61 is permitted.
  • the indeterminate information management unit 57 receives the confirmed information input via the input unit 51 in addition to the data entry stored via the information relay terminal 8 and stored in the game terminal 1 ("Type" in FIG. 5). ”) And indeterminate information are stored in the indeterminate information DB61.
  • the indeterminate information here is stored in the indeterminate information DB in the same format as the data entry whose contents change during propagation between game terminals. Also, delete the data entry that is no longer needed due to expiration, etc., and manage the indeterminate information DB61.
  • the indeterminate information management unit 57 outputs indeterminate information and / or confirmed information to the transmission / reception unit 53 according to the type of request.
  • the transmission / reception unit 53 has a communication function for communicating with the information relay terminal 8 connected to the Internet 7. This may be realized by a wireless communication function through a force built in the server 6 or an external communication antenna, or wired communication connected by a cable may be performed.
  • the storage unit 60 stores a control program (not shown), a user authentication DB 62, a relay terminal authentication DB 63, an indeterminate information DB 61, and other data necessary for processing performed by the server 6.
  • the storage unit 60 is a storage unit such as a battery-backed RAM, flash ROM, hard disk, or the like.
  • FIG. 32 is a data configuration example of the indeterminate information DB 61 in the second embodiment. Since the server stores uncertain information about multiple game programs, the uncertain information DB in FIG. 32 contains the data items included in the uncertain information DB (FIG. 5) in the first embodiment. In addition, a “game title” is provided to specify which game program each indeterminate information relates to. A description of data items that overlap those in FIG. 5 is omitted.
  • FIG. 33 is a data configuration example of a software management table in which the correspondence between serial numbers and game titles is stored.
  • the software management table is stored in the storage unit 60 of the server.
  • the serial number assigned to each game title is set in advance so as to follow the classification shown in FIG. 33 (for example, at the time of product shipment by a game maker or the like).
  • the game program executed on the game terminal can be specified.
  • the serial number is embedded in the “ID” of each data entry (see Figure 32), and the game program in use without specifying the “game title” in the user information and uncertain information DB must be specified. Can do.
  • FIG. 34 is a data configuration example of the user authentication DB 62.
  • the “serial number” (see the user information in FIG. 4) of the user permitted to download the data entry of the indeterminate information DB stored in the server 6 is stored.
  • FIG. 35 is a data configuration example of the relay terminal authentication DB 63.
  • the IP address of the legitimate information relay terminal 8 is stored, but other identification information that can uniquely identify the information relay terminal 8 may be used.
  • FIG. 36 is a time chart for explaining operations of the server 6 and the information relay terminal 8 in the second embodiment. Also in the second embodiment, the propagation of information between game terminals is Force to be performed Since this is the same operation as shown in the first embodiment, here, the operation of the information relay terminal and the server will be mainly described.
  • step S41 data entries are accumulated in the indeterminate information DB (S41).
  • the storage of the data entry in the uncertain information DB 61 of the server 6 is similar to the storage of the data entry in the game terminal 1 in the first embodiment.
  • the processing described in FIG. 13C is performed by the indeterminate information management unit 57 of the server 6.
  • step S41 is interrupted when the data entry is received, and then control is returned to the original process again.
  • the transmission / reception unit 33 (information relay terminal) performs transmission / reception when the information relay terminal 8 and the game terminal are within the communicable range of each other, and an IP packet including user information (see FIG. 30A) is transmitted from the game terminal 1 to the information relay terminal. Sent to 8.
  • the transmission / reception unit 33 (information relay terminal) extracts the user information and the source address from the received IP packet, and outputs them to the participation terminal management unit 36.
  • the participation terminal management unit 36 stores them in the participation terminal DB41. To do. In this way, information about game terminals that can communicate with the information relay terminal 8 is accumulated in the participating terminal DB 41.
  • the display management unit 35 displays a menu for services available to the player via the display unit 32, and the player operates the menu screen via the input unit 31.
  • the information relay terminal 8 transmits to the server a request for obtaining uncertain information and definite information regarding the game to be played. Therefore, the display management unit 35 determines whether an acquisition request for information stored in the server 6 is input from the input unit 31 (S32).
  • the information relay terminal 8 sends the input acquisition request, the user information of the requesting game terminal 1 stored in the participating terminal DB 41, and the game terminal 1
  • the data entry stored in the uncertain information DB and the identification information 42 of the information relay terminal 8 are transmitted to the server 6 (S33).
  • server 6 Upon receiving the information acquisition request stored in server 6 (S42 Yes), server 6 stores the data entry received thereafter as interrupt processing in the indeterminate information DB, and Information relay terminal authentication based on the received identification information is performed (S43).
  • the authentication management unit 56 may determine whether or not the IP address that matches the source IP address included in the received packet is stored in the relay terminal authentication DB 63. If a matching number is not stored (S43 No), an error process is performed because it is not an information acquisition request transmitted via the legitimate information relay terminal 8 (S51). In the error processing in step S51, for example, the IP address of the information relay terminal 8 that has requested unauthorized information acquisition is recorded as a log.
  • step S43 If the information relay terminal authentication is successful in step S43 (S43 Yes), then user authentication based on the user information is performed (S44).
  • the authentication information management unit 56 also extracts the serial number from the received user information card, and searches for a match with the serial number stored in the user authentication DB 62. If there is no match (S44 No), it is an acquisition request by an unregistered user, and error processing is performed (S52).
  • the server 6 notifies the information relay terminal 8 of an unregistered error, and the information relay terminal 8 displays that the user is not registered on the display unit 32, and further displays to the user. Display a screen prompting you to register.
  • the server 6 sends information to the information relay terminal 8 in response to the acquisition request (S45), returns to step S42, and receives another acquisition request from the information relay terminal 8. Wait in preparation for. Then, the information relay terminal 8 transmits the information transmitted from the server 6 to the corresponding game terminal 1 (S34), returns to step S32, and a new acquisition request for the information stored in the server 6 is input to the player power. Wait for it.
  • the server since the server provides uncertain information regarding a plurality of types of game programs, the uncertain information received by the game terminal is It may not necessarily be related to a game executed on the game terminal. Therefore, in the game terminal that receives the information transmitted in step S34, refer to the “game title” of the indeterminate information received and the “game title” included in the user information of the own terminal. Also, you can perform a process to discard the indeterminate information.
  • the "game title" is not used but the serial number is used.
  • Sano identifies the game title from the “serial number” included in the user information transmitted in step S33, using the software management table shown in FIG. To do.
  • the server extracts the serial number extracted from the “ID” of the uncertain information scheduled to be transmitted to the game title being executed (identified) on the game terminal. Only those included in the number band associated with the management table may be transmitted to the information relay terminal.
  • FIG. 37 is a screen example of the information relay terminal 8 for explaining a state where information stored in the server 6 is downloaded to the game terminal 1.
  • the game title to be provided is first displayed (screen 371).
  • screen 371 the name of information relay terminal 8 and four game titles are displayed.
  • menu 1 Advanced A
  • a list of services provided for “A's Adventure” is displayed (screen 372).
  • menu 5 (rumor GET!) Is selected.
  • the participating terminal DB 41 is read, and the “name” (see FIG. 30) stored in the participating terminal DB 41 is displayed (screen 373). Select your player name from these.
  • the details button is prepared on the screen 373, and when this button is pressed, the details of the user information can be viewed. Since the user information includes a serial number (see Fig. 4), it is possible to verify the identity by comparing the serial number displayed on the information supply terminal 2 with your serial number. Your serial number can be confirmed on the information terminal 1 (see Fig. 14).
  • a screen for selecting information to be downloaded is displayed (screen 374).
  • menu 1 official information
  • the process of step S33 in FIG. 36 is executed.
  • the relay terminal 8 is an official information acquisition request, “Taro” user information stored in the participating terminal DB 41, a data entry stored in the indeterminate information DB of the “Taro” game terminal 1, and an information relay terminal.
  • the identification information 42 of 8 is transmitted to the server 6.
  • the server authenticates the information relay terminal and performs user authentication based on whether the serial number included in the user information of "Taro" is a user registered in the user authentication DB. If successful, the data entry stored in the indeterminate information DB of the server 6 and having “type” 1 (see FIG. 5A) is transmitted to the information relay terminal 8.
  • the information relay terminal 8 refers to the "address" of the entry corresponding to "Taro" from the participating terminal DB41, obtains the IP address of the game terminal of "Taro", and includes the data entry received from the server. Create a packet with the IP address as the destination address and send it to the game terminal.
  • a completion screen is displayed (screen 375). If you select menu 2 on screen 374, the data entry with “Type” of 0 (indeterminate) will be sent out of the information stored in the uncertain information DB of server 6, and if you select menu 3. Regardless of the “type”, the data entry is sent.
  • FIG. 38 is an example of a screen for explaining an example of the authentication / billing process.
  • the information supply terminal 2 displays an authentication number (authentication code) (screen 381). This is a number randomly generated by the authentication management unit. Then, a screen for inputting an authentication code is displayed on the game terminal of the player selected on screen 373 (screen 382).
  • the player inputs the authentication code displayed on screen 381 to the game terminal.
  • the entered number is transmitted to the information relay terminal 8, and the information relay terminal 8 confirms that the same number as the authentication code displayed on the screen 381 is entered, and the authentication is completed (screen 383).
  • Game terminal power If the received number and the displayed authentication code do not match, authentication fails and information is not downloaded.
  • the billing process such as the insertion of cash is performed at the front stage of the screen 381
  • the billing process and the authentication process can be performed at a time.
  • the second embodiment it is possible to store the confirmation information in which the data entry does not change in the process of propagation in the server and propagate the confirmation information to the game terminal (information terminal).
  • the game terminal information terminal
  • information announced by the game maker as official information can be propagated to the game terminal in real time and at an appropriate timing.
  • the effect of attracting customers can also be expected by installing information relay terminals.
  • the information relay terminal 2 can be omitted so that the game terminal 1 can be directly connected to the server 3.

Abstract

 情報を伝達させる過程で、不確かさを増すように伝達させる情報伝達方法が確立されていなかった。  情報端末は、複数の文章生成用定型文を有し、前記複数の文章生成用定型文から選択される文章生成用定型文に、前記情報端末に入力される、又は前記情報端末で発生するイベントに関連して選択される、言葉を挿入することによって文章を生成する。通信路を介して、他の情報端末にて受信される文章は、その文章を変化させるか否かが判定され、変化させる場合には、受信した文章に含まれる文章生成用定型文に対応付けられる別の文章生成用定型文で入れ替えるか、又は、受信した文章に含まれる言葉を、別の言葉もしくは記号と入れ替えることによって新しい文章が生成され、生成された新しい文章が通信路を介して別の情報端末に転送される。

Description

明 細 書
情報伝達の過程で内容が変化する情報伝達方法および情報伝達システ ム
技術分野
[0001] 不確定な情報を伝達するための情報伝達方法及び情報伝達システムに関する。
背景技術
[0002] 従来のビデオゲームは、 PC(Personal
Computer), PDA(Personal Digital Assistant),携帯電話、家庭に設置される家庭用ゲ ーム機、ゲームセンタ等のアミューズメント施設に設置される業務用ゲーム機等の情 報端末単体でプログラムが実行され、利用者 (プレイヤ)は 1人で遊ぶことが主流であ つた。近年、複数の情報端末を接続して 1つのビデオゲームに複数人が同時参加す る遊び方が提案されている。
[0003] 小規模な接続形態として、情報端末同士をケーブルにより接続し、互いに操作する キャラクタを対戦させる対戦プレイを行うものがあり、大規模な接続形態として、ネット ワークを介してサービスを提供するサーバに情報端末を接続し、同様にサーバに接 続された情報端末のプレイヤと同じゲームを遊ぶ場合等がある。また、複数の情報端 末を接続する場合、プレイヤがゲームコントローラ等の入力手段により文字情報を入 力することで、プレイヤ同士が表示画面を介して会話を行うチャット機能を有している ものがある。
[0004] こうして接続された情報端末間では、さまざまな情報のやり取りが行われる。やり取 りされる情報には、対戦相手の強さや状態を表す情報、チャット機能を利用しプレイ ャが入力した情報、ゲームの進行状況を各情報端末間で同期させる情報等さまざま な情報が含まれるが、その情報伝達形態は、送信側と受信側でその内容が変化しな い、確定的な情報伝達が行われる。
[0005] 一方現実的には、情報が伝播する過程で不確定な要素を含んでいき、情報は真実 と離れていくことが多い。従って、自分が入手した情報の真偽が定かではないことも あるし、数人を経るうちに情報の内容が最初と変わってしまうことがよくある。ところが、 真偽が定かでない情報の中には真実が含まれることもあるので、自分に興味のある 情報を入手するとその真偽を確認した 、と 、う好奇心が刺激される。
[0006] 従って、情報端末間で情報を伝播させる過程で情報 (の内容)が不確定さを増すよ うに変化する伝達方法があれば、その伝達方法を利用して情報を伝播させることによ つて、最初は正確な情報がいずれ不確定さを含む情報に変化していく。そして、プレ ィャは真偽が定かでない情報を受信することによって、好奇心が刺激され、ゲームに 対するプレイヤの興味を長い間引き付けることができ、ゲームをより魅力的なものとす ることがでさる。
[0007] なお、従来技術において、情報端末間で情報を伝播させる過程で情報 (の内容)が 不確定さを増すように変化する伝達方法に関する有効な先行技術文献情報を発見 することはできな力つた。
発明の開示
発明が解決しょうとする課題
[0008] し力しながら、従来情報端末間で行われる情報伝達は、上述したように確定的な情 報伝達しか行われてこな力つた。また、従来の情報伝達方法においては、情報端末 同士を接続するのにプレイヤ同士の同意が前提となる場合があり、情報の伝達範囲 は限られてしまう。
[0009] また、チャット機能により不特定多数のプレイヤと会話する場合、親しい人間同士で ないと会話が弾まず、会話の巧みな主導者力 ^、ないと会話が続力ない。会話が盛り 上がらないと、伝達される情報も少ない。また、得られた情報は同時に参加可能なプ レイヤのみで共有され、持ち込まれる情報は参加プレイヤが知って 、ることに限定さ れてしまう。
[0010] さらに、携帯型の情報端末 (携帯電話等)でチャットに参加する場合、入力手段が PCのキーボード等と比較すると貧弱なため、会話 (文字入力)が遅れがちでプレイヤ がチャットをためらうなど、十分に情報伝達がなされるとは言い難い。
[0011] そこで本発明は上記課題に鑑みてなされたものであり、情報を情報端末を介して自 動的に伝播させ、伝播の過程でより不確かさを増す情報伝達方法を提供することを 目的とするものである。 課題を解決するための手段
[0012] 上記目的は、本発明の第一の態様によれば、通信路を介して相互に情報交換可 能に構成された複数の情報端末間で行われる娯楽的情報伝達方法を実行するため のアプリケーションプログラムであって、前記情報端末にそれぞれインストールされる ことによって、複数の文章生成用定型文が保存されると共に、前記複数の文章生成 用定型文から選択される文章生成用定型文に、前記情報端末に入力される、又は 前記情報端末で発生するイベントに関連して選択される、言葉を挿入することによつ て文章を生成するステップと、前記生成された文章を前記通信路を介して他の前記 情報端末に送信する送信ステップと、前記他の情報端末にお!、て前記アプリケーシ ヨンプログラムの実行により送信された前記文章を前記通信路を介して受信するステ ップと、前記受信した文章を変化させる力否かを判定する判定ステップと、前記判定 ステップにおいて、前記受信した文章を変化させない場合、前記受信した文章を別 の前記情報端末に転送する第一の転送ステップと、前記判定ステップにおいて、前 記受信した文章を変化させる場合、前記受信した文章に含まれる第一の文章生成用 定型文に対応付けられる第二の文章生成用定型文を前記複数の文章生成用定型 文から選択し、前記第一の文章生成用定型文を前記第二の文章生成用定型文と入 れ替えるか、又は、前記受信した文章に含まれる前記挿入された言葉を、別の言葉 もしくは記号と入れ替えることによって新しい文章を生成し、前記生成された新しい文 章を前記通信路を介して前記別の情報端末に転送する第二の転送ステップとを有 することを特徴とするアプリケーションプログラムを提供することにより達成される。
[0013] また上記目的は、本発明の第二の態様によれば、第一の態様において、他の情報 端末力 受信したデータに含まれる転送回数情報および Zまたは受信した文章の変 化の度合いに基づき、受信した文章の正確度を算出するステップをさらに有し、前記 保存された複数の文章生成用定型文のそれぞれには予め正確度基準値が定義され ており、前記判定ステップにおいて、前記算出された正確度の値を前記受信した文 章に対し予め設定される前記正確度基準値と比較する処理を行うことを特徴とするァ プリケーシヨンプログラムを提供することにより達成される。
[0014] また上記目的は、本発明の第三の態様によれば、第一または第二の態様において 、前記イベントが、前記情報端末で実行されるゲームの進行によって発生することを 特徴とするアプリケーションプログラムを提供することにより達成される。
[0015] また上記目的は、本発明の第四の態様によれば、第一乃至第三のいずれかの態 様に い 、
前記情報端末は携帯端末であり、各情報端末は無線通信路を介して接続可能に構 成されており、一の情報端末が他の情報端末と通信可能な距離範囲に入ったとき、 前記送信ステップ又は前記第一の転送ステップ若しくは前記第二の転送ステップを 実行可能にするように構成されたアプリケーションプログラムを提供することにより達 成される。
[0016] また上記目的は、本発明の第五の態様によれば、第一乃至第四の態様のいずれ 力のアプリケーションプログラムがそれぞれ実行される複数の情報端末に通信路を介 して接続されたサーバであって、前記複数の情報端末間で行われる娯楽的情報伝 達の過程で変化しな!、確定的文章が格納される記憶部と、前記複数の情報端末の 一の情報端末からの情報取得要求に応じて、前記記憶部に格納される前記確定的 文章を送信する制御部とを有することを特徴とするサーバを提供することにより達成 される。
[0017] また上記目的は、本発明の第六の態様によれば、第五の態様において、前記制御 部は、前記一の情報端末からの前記情報取得要求と共に、該一の情報端末が送信 する前記文章を受信して、前記記憶部に格納し、前記一の情報端末とは異なる別の 情報端末からの前記情報取得要求に応じて、前記確定的文章と共に、前記一の情 報端末力 受信した前記文章を該別の情報端末に送信することを特徴とするサーバ を提供することにより達成される。
[0018] また上記目的は、本発明の第七の態様によれば、第一乃至第四の態様のいずれ 力に記載のアプリケーションプログラムがそれぞれ実行される複数の情報端末に通 信路を介して接続されたサーバであって、複数の文章生成用定型文が格納される記 憶部と、前記複数の文章生成用定型文から選択される文章生成用定型文に、前記 サーバに入力される、又は前記サーバで発生するイベントに関連して選択される、言 葉を挿入することによって文章を生成する機能と、前記生成された文章を前記通信 路を介して前記情報端末に送信する送信機能と、前記情報端末にお!、て前記アプリ ケーシヨンプログラムの実行により送信された前記文章を前記通信路を介して受信す る機能と、前記受信した文章を別の前記情報端末に転送する転送機能とを実現する 制御部とを有することを特徴とするサーバを提供することにより達成される。
[0019] また上記目的は、本発明の第八の態様によれば、第一乃至第四のいずれかに記 載のアプリケーションプログラムがそれぞれ実行される複数の情報端末と、前記情報 端末に通信路を介して接続され、前記複数の情報端末間で行われる娯楽的情報伝 達の過程で変化しな!、確定的文章が格納される記憶部と、前記複数の情報端末に 含まれる一の情報端末からの情報取得要求に応じて、前記記憶部に格納される前 記確定的文章を送信する制御部とを有するサーバとを備える情報システムを提供す ること〖こより達成される。
[0020] また上記目的は、本発明の第九の態様によれば、第八の態様において、前記サー バの前記制御部は、前記一の情報端末からの前記情報取得要求と共に、該一の情 報端末が送信する前記文章を受信して、前記記憶部に格納し、前記一の情報端末 とは異なる別の情報端末からの前記情報取得要求に応じて、前記確定的文章と共に 、前記一の情報端末力 受信した前記文章を該別の情報端末に送信することを特徴 とする情報システムを提供することにより達成される。
[0021] また上記目的は、本発明の第十の態様によれば、第一乃至第四のいずれかに記 載のアプリケーションプログラムがそれぞれ実行される複数の情報端末と、前記情報 端末に通信路を介して接続されるサーバを備えた情報システムであって、前記サー バは、複数の文章生成用定型文が格納される記憶部と、前記複数の文章生成用定 型文から選択される文章生成用定型文に、前記サーバに入力される、又は前記サー バで発生するイベントに関連して選択される、言葉を挿入することによって文章を生 成する機能と、前記生成された文章を前記通信路を介して前記情報端末に送信する 送信機能と、前記情報端末にお!、て前記アプリケーションプログラムの実行により送 信された前記文章を前記通信路を介して受信する機能と、前記受信した文章を別の 前記情報端末に転送する転送機能とを実現する制御部とを有することを特徴とする 情報システムを提供することにより達成される。 発明の効果
[0022] 本情報伝達方法を使用することで、例えばゲームに関する不確定情報が情報発生 源から次々にゲーム端末に伝播してゆく。この不確定情報は、伝播の過程でその内 容が変更される。こうして、利用者 (プレイヤ)が不確定情報を入手すると、その真偽 を確認したいという欲求が生まれ、ゲームをより面白くし、プレイヤの興味を長くその ゲームに引き付ける効果を持つ。また、他のプレイヤに関する情報を入手すると新た なゲームへの欲求を刺激する効果もある。更に、ゲームの進行に合わせたイベントを 不確定情報として伝播させ、イベントを発生させることも可能となる。
[0023] 本情報伝達方法を使用すれば、プレイヤがゲーム端末を携帯するだけで近くのゲ ーム端末等から不確定情報が蓄積される。その蓄積処理はゲームプログラムのバッ クグラウンドで行われ、プレイヤに負担をかけることがない。プレイヤのコミュニケーシ ヨン能力に依存することもな 、。チャット等のリアルタイムコミュニケーションに要求され る高い入力能力も不要で、汎用のゲーム端末で実現させることが可能である。
[0024] また、本情報伝達方法にお!、ては、情報の伝達範囲を限定することによりスバム、 チェーンメールのような迷惑行為の発生を防止できる。本発明の情報伝達方法を使 用すれば、現実世界における噂が伝播する様子を、ゲーム端末で実行されるビデオ ゲームの世界で再現することが可能になる。
図面の簡単な説明
[0025] [図 1]本発明の方法が適用される情報伝達システムの第一の実施形態の構成を示す 図である。
[図 2]ゲーム端末の構成を示すブロック図である。
[図 3]不確定情報に使用される定型文が格納される文章 DBのデータ構成例である。
[図 4]ユーザ情報のデータ構成例である。
[図 5] Aは、不確定情報 DB21に格納されるデータエントリのデータ構成例であり、 B は、 IDのデータ構成の一例である。
[図 6]送信限度回数、受信限度回数、そして送信残数によって情報の拡散が有限と なることを説明する図である。
[図 7]ゲーム内に発生させるイベントの内容が格納されたイベント DBのデータ構成例 である。
[図 8]チェックポイント DBのデータ構成例である。
[図 9]通信履歴 DBのデータ構成例である。
[図 10]データエントリをどのように変更するかが格納される変更ルール DBのデータ構 成例である。
[図 11]ワード候補 DBのデータ構成例である。
圆 12]第一の実施形態におけるゲーム端末の動作を説明するフローチャートである。 圆 13]Aは、ユーザ情報の作成、更新に伴い不確定情報がデータエントリとして生成 される場合を説明するフローチャートであり、 Bは、ゲームの進行に伴い、プレイヤが 到達したチェックポイントに応じて不確定情報がデータエントリとして生成される場合 を説明するフローチャートであり、 Cは、プレイヤがデータエントリの各項目に対する 値を直接入力して不確定情報のデータエントリが生成される場合を説明するフロー チャートである。
[図 14]図 13Aのステップ S 101における画面例である。
[図 15]図 14の画面 63にて、「ユーザ情報更新」なる項目を選択した場合に表示され る画面例である。
[図 16]図 13Cのステップ S 1における画面例である。
[図 17]送受信処理を細分したステップを示している。
[図 18]Aは、シリアル番号を利用して禁ループバック処理を送信時に行う場合を説明 するフローチャートであり、 Bは、イベントフラグを利用して禁ループバック処理を送信 時に行う場合を説明するフローチャートである。
[図 19]図 18Aの処理を具体ィ匕した例を説明するための図である。
[図 20]図 18Bの処理を具体ィ匕した例を説明するための図である。
[図 21]Aは、 IDを利用して禁ループバック処理を受信時に行う場合を説明するフロー チャートであり、 Bはシリアル番号を利用して禁ループバック処理を受信時に行う場合 を説明するフローチャートであり、 Cは、イベントフラグを利用して禁ループバック処理 を受信時に行う場合を説明するフローチャートである。
[図 22]図 21Bの処理を具体ィ匕した例を説明するための図である。 [図 23]図 22Cの処理を具体ィ匕した例を説明するための図である。
[図 24]Aは、変更ルール DB23に格納されたルールに基づき、データエントリの変更 が行われる場合を説明するフローチャートであり、 Bは、定型文を別の定型文に変更 して、データエントリの変更が行われる場合を説明するフローチャートであり、 Cは、定 型文で使用されるワードを置換して、データエントリの変更が行われる場合を説明す るフローチャートであり、 Dは、定型文で使用されるワードを一部伏字にして、データ エントリの変更が行われる場合を説明するフローチャートである。
[図 25]図 24A,図 24Bのように定型文が別の定型文に変更される場合の画面例であ る。
[図 26]ワードが置換される場合の画面例である。
[図 27]ワードが一部伏字にされる場合の画面例である。
[図 28]第二の実施形態における情報伝達システムの構成図である。
[図 29]情報中継端末の構成を示すブロック図である。
[図 30]Aは、第二の実施形態におけるユーザ情報のデータ構成例、 Bは、参加端末
DBのデータ構成例である。
[図 31]サーバの構成を示すブロック図である。
[図 32]第二の実施形態における不確定情報 DBのデータ構成例である。
[図 33]シリアル番号とゲームタイトルの対応関係が格納されるソフト管理テーブルの データ構成例である。
[図 34]ユーザ認証 DBのデータ構成例である。
[図 35]中継端末認証 DB63のデータ構成例である。
[図 36]第二の実施形態におけるサーバと情報中 «I端末の動作を説明するタイムチヤ ートである。
[図 37]サーバに格納された情報をゲーム端末にダウンロードする様子を説明するた めの情報中継端末の画面例である。
[図 38]認証'課金処理の一例を説明する画面例である。
発明を実施するための最良の形態
以下、本発明の実施の形態について図面に従って説明する。し力しながら、本発 明の技術的範囲は力かる実施の形態に限定されるものではなぐ特許請求の範囲に 記載された発明とその均等物にまで及ぶものである。
[0027] 図 1は、本発明の方法が適用される情報伝達システムの第一の実施形態の構成を 示す図である。第一の実施形態では、ゲームに関する噂がゲーム端末 1に不確定情 報として格納される。プレイヤは、無線通信機能を備えたゲーム端末 1同士で互いに 通信を行い、対戦プレイを行ったり、各ゲーム端末 1に格納された不確定情報を交換 しゲームを楽しむ。各ゲーム端末 1に格納された不確定情報が複数のゲーム端末 1 にて交換されることが繰り返され、不確定情報が伝播する。本実施形態の不確定情 報は、予め情報端末に格納される定型文を基に生成される文章として伝播する。そ の定型文に言葉 (ワード)を挿入することにより、さまざまな不確定情報となる。挿入さ れる言葉は、過去に対戦したプレイヤのうち、ライバルと思うプレイヤの名前や、プレ ィャが入手したアイテム等であり、ゲーム端末 1に入力されるかあるいはゲーム端末 1 に予め格納されて 、るもの力ら選択される。
[0028] ゲーム端末 1は、本発明の方法を実施するためのプログラムを実行して端末を制御 し、ゲームを進行させる。ゲーム端末 1は、例えば、携帯型ゲーム機、携帯電話、 PDA(Personal Digital Assistance)等の情報端末で実現される。第一の実施形態にお いて、不確定情報は、各ゲーム端末 1に備えられた不確定情報データベース(以下、 不確定情報 DBと略す) 21に格納される。
[0029] 図 1には、不確定情報 DBのデータ構成例が示されている。不確定情報 DB21の各 行が上述したデータエントリである。このデータエントリをゲーム端末 1が送受信するこ とによってゲーム端末 1間に不確定情報が伝播する。図 1に示されるデータエントリに は、「識別子 (ID)」、「文章コード」、「正確度」、「ワード」が含まれる。「識別子」は、デ ータエントリを特定するための管理番号である。「文章コード」は、後述する文章デー タベースにて定型文と対応付けられており、ある虫食い状態の定型文を特定する。
[0030] 「ワード」には、定型文の虫食いの数に応じて少なくとも 1つの語句が格納される。「 正確度」は、文章コードにより特定される定型文に、ワードを当てはめて作成される文 章の正確度であり、データエントリを伝達する過程において、この数値が変化する。 正確度が、所定の閾値を下回ると、データエントリは変更され、情報の不確定さが増 す。データエントリの変更とは、文章コードが変更される、又は、使用されるワードが 他のワードに置換される、伏字に置換されるなどの処理が施されることである。
[0031] 正確度は、例えば、 100が最高値で 0が最低値である。正確度が高ければ高いほ ど、不確定情報が発生したときの内容に近ぐ正確度が所定の閾値未満では、その 内容が変更されている恐れがあることを意味する。また、正確度を減らす主体は、送 信側の情報端末、受信側の情報端末のどちらでもよ 、。
[0032] 例えば、 "〜は〜をライバルと思っているらしい"という 2箇所に虫食いのある定型文 の文章コードと、その定型文に対応するワードとして、 "タロウ"、 "ハナコ"が図 1のゲ ーム端末 1Aの不確定情報 DBに格納されているとする。定型文にワードを組み合わ せてできる文章 (これが不確定情報である)は、 "タロウはハナコをライバルと思ってい るらしい"となる。こうして、定型文に対応する文章コードと、その定型文に使用される ワードとの組合せにより文章がデータエントリ毎に完成され、この文章が不確定情報 2 として伝播する。
[0033] そして、このデータエントリがゲーム端末 1Bを介してゲーム端末 1Cに伝播される過 程で、正確度が減らされ、正確度が所定の閾値未満となったとき、例えば、 "ハナコを ライノ レと思う人間がいるらしい"という新たな不確定情報 3へと変更される。これは、 ゲーム端末 1Cの不確定情報 DBのデータエントリにお 、て、別の定型文"〜をライバ ルと思う人間がいるらしい"に対応する文章コードに変更されると共に、 1箇所の虫食 いに対応するワードが"ノヽナコ"に変更されたことを意味する。こうして、定型文に対応 する文章コードと、その定型文に使用されるワードとの組合せにより文章がデータェ ントリ毎に完成され、データエントリを伝播させると、この文章が不確定情報として伝 播しプレイヤ〖こ提供されること〖こなる。
[0034] ゲーム端末 1Cは、受信したデータエントリの識別子と同じデータエントリが不確定 情報 DB21に既に格納されて 、な 、か確認し、新し 、データエントリのみを格納する ようにしてもよい。すると、複数の経路からのデータエントリ(上記例で言えば、ゲーム 端末 1Cにおいて、ゲーム端末 1Bを介さずに直接ゲーム端末 1Aから 1Cに伝播する データエントリ)が重複して格納されることがなぐ記憶容量の使用量を節約できる。ま た、一度受信したデータエントリあるいは、 自端末が発生源のデータエントリが他のゲ ーム端末 1を介して再び自ゲーム端末 1に戻り重複して格納されることも防止できる。
[0035] このように、ゲーム端末 1への伝播の過程で不確定情報の内容がよりあやふやにな るよう、言い換えると不確定さを増すようにデータエントリが変更される。多くのゲーム 端末 1に伝播するほど正確度は下がり、その内容が不明確で真偽のほどが定かでは なくなる。こうして、不確定情報の発生から時間が経過すればするほど、また情報が 経由したゲーム端末 1の台数が増えるほど、真偽が不確かになる状況を作り出すこと ができる。
[0036] データエントリは上述したようにより不確定さを増すよう変更されるので、プレイヤは 単独のデータエントリを入手するだけでは情報の真偽を断定することができな 、。そ して、プレイヤは、真偽のほどを確かめようと実際にゲームを操作したり、別の情報を 収集するために別のゲーム端末 1から情報を取得しようと現実世界を移動したり、他 のプレイヤと顔を合わせて会話しようと相手を探したりする。こうして長い期間、プレイ ャの興味をゲームに引きつけることができる。
[0037] 図 2は、ゲーム端末 1の構成を示すブロック図である。ゲーム端末 1は、入力部 11、 表示部 12、送受信部 13、制御部 14、記憶部 20、を有し、制御部 14は、ゲーム進行 管理部 15、ユーザ情報管理部 16、不確定情報管理部 17を含む。本実施形態にお いては、ゲーム進行管理部 15、ユーザ情報管理部 16、不確定情報管理部 17は、制 御部 14に備えられた図示省略された CPUにより実行されるプログラムで実現されるが 、ハードウェア回路により実現することもできる。
[0038] ゲーム進行管理部 15は、ゲーム画面を表示部 12に表示し、入力部 11を介してプ レイヤより入力される命令を受け、その命令に応じた処理を行う。例えば、ゲーム進行 管理部 15は、
不確定情報 DBに格納されたデータエントリを表示部 12に表示し、また、ゲームに設 けられたさまざまなチェックポイントのうち達成済みチェックポイントを示す情報を記憶 部 20のチェックポイントデータベース(チェックポイント DB) 22に格納する。
[0039] 更に、ゲーム進行管理部 15は、ゲーム内で発生させるイベントが格納されたィベン トデータベース (イベント DB) 28を参照し、受信した不確定情報のデータエントリにィ ベントフラグが設定されていれば、対応するイベントをゲーム内に発生させる。 [0040] 入力部 11は、例えば、図 1の十字キーやボタンが該当し、表示部 12は、例えば、図 1の画面が該当する。入力部 11、表示部 12はプレイヤとのインタフェースとして機能 する。
[0041] ユーザ情報管理部 16は、記憶部 20に格納されるプレイヤのユーザ情報 24を管理 する。ユーザ情報 24は、プレイヤ (あるいはそのプレイヤが操作するキャラクタ)を特 定するプレイヤの名前を含み、ゲーム端末 1間で交換されるデータである。また、ュ 一ザ情報管理部 16は、送受信部 13を介して他のゲーム端末 1より入力されるユーザ 情報のうちプレイヤの名前を通信履歴データベース (通信履歴 DB) 27に蓄積する。 通信履歴 DB27に格納されたプレイヤの名前は、例えば、ライバルと思うプレイヤを設 定する際に表示部 12に表示されて使用される。
[0042] 不確定情報管理部 17は、チェックポイント DB22やユーザ情報 24を参照して、不確 定情報をデータエントリとして生成し、生成したデータエントリを不確定情報データべ ース (不確定情報 DB) 21に格納し、また、有効期限切れ等で不要になったデータェ ントリを削除して、不確定情報 DB21を管理する。通信相手のゲーム端末 1よりデータ エントリを受信すると、不確定情報管理部 17は、定型文と文章コードが対応付けられ 格納される文章データベース (文章 DB) 25、定型文と共に使用される語句、文章、単 語等が格納されるワード候補データベース (ワード候補 DB) 26、及びデータエントリ の変更をどのように行うかを決めるルールが格納される変更ルールデータベース(変 更ルール DB) 23を参照してデータエントリの変更処理を行い、変更後のデータェント リを不確定情報 DB21に格納する。更に、不確定情報管理部 17は、通信相手のゲー ム端末 1へ送信するデータエントリを選択し送受信部 13に与える。
[0043] 送受信部 13は、ゲーム端末 1に内蔵されるか若しくは外付けされた通信アンテナ 1 0 (図 1参照)を介して他のゲーム端末 1と無線通信可能な無線通信機能を有し、ュ 一ザ情報 24及び不確定情報 DB21に格納されたデータエントリを通信相手のゲーム 端末 1 (以下、通信相手端末と称す)に対し送受信する。通信アンテナ 10は、ゲーム 端末 1に備えられた図示しな ヽ拡張機器コネクタを介して接続される拡張機器として 提供されてもよい。
[0044] 送受信部 13は、無線通信可能な通信相手端末がある場合、制御部 14を介して得 られるユーザ情報 24と不確定情報 DB21に格納されたデータエントリを通信相手端 末に送信する。そして、送受信部 13は、通信相手端末から受信したユーザ情報をュ 一ザ情報管理部 16に与え、通信相手端末から受信したデータエントリを不確定情報 管理部 17に与える。
[0045] 記憶部 20には、図示しない端末制御プログラム、不確定情報 DB21、チェックボイ ント DB22、変更ルール DB23、ユーザ情報 24、文章 DB25、ワード候補 DB26、通信 履歴 DB27、イベント DB28、その他ゲーム端末 1で行われる処理に必要なデータが 格納される。記憶部 20は、例えば、ノ ッテリーバックアップされた RAM、フラッシュロム 、ハードディスク等の記憶手段である。
[0046] 続いて、記憶部 20に格納されるデータ毎のデータ構成を、文章 DB25、ユーザ情 報 24、不確定情報 DB21、イベント DB28、チェックポイント DB22、通信履歴 DB27、 変更ルール DB23、ワード候補 DB26の順に説明する。
[0047] [文章データベース]
図 3は、不確定情報に使用される定型文が格納される文章 DB25のデータ構成例 である。文章 DB25には、虫食い状態の「定型文」と、その定型文を特定する「文章コ ード」と、虫食 、状態の定型文を埋めるのに必要な「ワードの項目」とが格納されて ヽ る。
[0048] 図 3において、例えば、文章コード 001に対応する定型文"〜は〜をライバルと思つ ているらしい"は、文中に 2箇所の空き(虫食い)があり、そこに格納されるワードの項 目は「主語」、「ライバル」であることがわかる。これは、虫食いを埋めるのに使用される ワードが、後述するワード候補 DBにてワードの項目「主語」、「ライノ レ」に格納された ワードから選択可能であることを意味する。文章 DB25には、一般的な不確定情報が 生成されるときに選択される初期定型文、伝播の過程でデータエントリが変更すると きに選択される変更用定型文、ゲーム内に設定されたチェックポイントにプレイヤが 到達するときに生成される不確定情報に使用されるチェックポイント対応用定型文、 ゲーム内で発生させるイベント用のイベントフラグ対応用定型文等が格納される。チ エックポイント、イベントについても後述する。
[0049] [ユーザ情報] 図 4は、ユーザ情報 24のデータ構成例である。ユーザ情報 24は、ゲーム端末 1の プレイヤ自身のユーザ情報 (本人データ)が格納される。ユーザ情報は、ゲーム開始 時にゲーム進行管理部 15がユーザ情報入力画面を表示して、プレイヤに入力を促 し、入力された内容で初期設定される他、ゲーム実行中に入力部 11を介して呼び出 された更新画面をゲーム進行管理部 15が表示して、プレイヤに入力を促し、入力さ れた内容で更新される。
[0050] ユーザ情報には、「シリアル番号」、「名前」、「性別」、「本拠地」、「ライバル」、「仲間 」、「レアアイテム」と 、うデータ項目が含まれる。「シリアル番号」は、ゲームプログラム が格納された ROMカートリッジ、 CD、 DVD等の記憶媒体を特定する番号である。
[0051] ゲームプログラムが記憶媒体により提供されるのではなぐ例えば、サーバから直接 ゲーム端末 1にダウンロードされるのであれば、「シリアル番号」はゲーム端末 1の機 器固有番号でもよい。あるいは、プログラム毎に異なる識別番号を持つようにゲーム プログラムがコーディングされていれば、「シリアル番号」にはその識別番号を使用す ることもできる。このシリアル番号をデータエントリの IDの一部に使用することで、不確 定情報が一意に特定され、同じ不確定情報を重複して不確定情報 DBに蓄積するこ とを回避することがでさる。
[0052] 「名前」は、ゲームを遊ぶプレイヤを特定する名前である。「名前」には、自分の本名 を使用しても、ゲームを遊ぶためだけのニックネームを使用してもよい。「性別」は、男 性か女性力選択する。プレイヤは、どちらかを選択したくない場合、秘密にすることも できる。その場合、「性別」には「秘密」が格納される。
[0053] 「本拠地」は、プレイヤが普段生活する地域を設定する。本拠地を設定すると、地域 限定の不確定情報を入手することができる。プレイヤは、本拠地を設定したくない場 合、秘密にすることができる。その場合、「本拠地」には、「指定なし」が格納される。
[0054] 「ライバル」と「仲間」はそれぞれ、他のプレイヤの「名前」が格納される。ゲーム開始 時は、相手のプレイヤに関する情報がない場合が普通であり、「ライバル」、「仲間」に は、それぞれ「設定なし」が格納される。「レアアイテム」には、プレイヤがゲーム内で 入手したアイテムのうち、出現頻度が少ないあるいは入手が困難なアイテムとして分 類されるもの(レアアイテム)の名前が格納される。 [0055] 「ライバル」、「仲間」、「レアアイテム」に有効な値が格納されると、それに関する不 確定情報が生成される。例えば、対戦プレイにおいて、「ライバル」に指定されたプレ ィャに勝利するとボーナスポイントが得られる、相手のアイテムが入手できるといった 特殊効果がある。「仲間」に指定されたプレイヤとは、ゲーム内の任務や対戦プレイに おいて、協力した行動を取ることができるといった特殊効果がある。従って、この項目 を設定すると 1人でゲームをプレイするのとは異なる展開をプレイヤは体験できるので 、よりゲームの面白さを加速し、またゲームに対する興味を持続させることができる。 またこれらの項目に関する不確定情報がゲーム端末 1間で伝播すると、そのプレイヤ との対戦を求めてユーザが移動し、より不確定情報が拡散しやすくなる。
[0056] また、レアアイテムを欲しいと思うプレイヤは、それを持つプレイヤとの対戦プレイに 勝利して入手するか、そのプレイヤがレアアイテムを入手したゲーム内での場所に行 く力、そのプレイヤ本人に話を聞こうする。従って、レアアイテムに関する不確定情報 をゲーム端末 1間に伝播させることは、ゲーム内外でのこのような行動を喚起し、やは りゲーム対する興味を持続させることになる。
[0057] [不確定情報データベース]
図 5Aは、不確定情報 DB21に格納されるデータエントリのデータ構成例である。図 5Aのデータエントリには、図 1で説明した「ID」、「文章コード」、「正確度」、「ワード」に カロえて、「送信限度回数」、「送信残数」、「受信限度回数」、「種類」、「イベントフラグ」 、「有効期限」、「地域」が含まれる。このうち「ID」、「文章コード」、「正確度」、「ワード」 以外は、ゲームをより楽しくするためや管理を容易にするための付加的なデータ項目 である。
[0058] 図 5Bは、データエントリを特定するための管理番号である「ID」のデータ構成の一 例である。図 5Bには、一例として、ユーザ情報 24に含まれるシリアル番号(図 4参照) と、日付と、不確定情報管理部 17によりデータエントリの生成時に付けられる連続番 号がハイフン記号で結ばれている。これは、不確定情報管理部 17が、ユーザ情報 2 4から得られるシリアル番号と、ゲーム端末 1に備えられた時計(図 2にて図示省略)か ら得られる日付に、その日に生成した何番目の不確定情報かを示す連続番号を付 与して IDを作成することで得られる。 [0059] 不確定情報管理部 17は、他のゲーム端末 1からデータエントリを受信すると、同一 IDのデータエントリがない場合に、受信したデータエントリを不確定情報 DB21に格 納する。すると、同じデータエントリが重複して格納されることはない。つまり、一度受 信したデータエントリあるいは、自端末が発生源であるデータエントリが他のゲーム端 末を介してループバックする現象を防止できる。これにより、データエントリが何度も 同じゲーム端末間で堂々巡りし、受信する度に不明確になっていくデータエントリを 受信することでプレイヤが混乱する事態を防止することができる。
[0060] 図 5Aに戻り、「文章コード」は、図 3の文章 DB25に格納された「定型文」を特定する 文章コードである。「ワード」は、「文章コード」によって特定される定型文の虫食いを 埋めるための語句、単語等である。
[0061] この「文章コード」により特定される定型文と「ワード」を組み合わせることにより不確 定情報がプレイヤに提供される。例えば、「文章コード」が" 001"で、「ワード」として" タロウ、ハナコ"が格納されたデータエントリであれば、図 3にて文章コード 001に対応 する定型文を参照し、 "タロウはハナコをライバルと思って 、るらし 、"と 、う文章が作 成され、これが不確定情報としてプレイヤに提供される。
[0062] 「正確度」は、不確定情報の正確さを示す数値である。この数値は、初期値として 1 00が設定され、不確定情報がゲーム端末 1間で伝播するに従って減少する。そして 正確度が所定の閾値未満になったときデータエントリが変更される。
[0063] この正確度によって、不確定情報の発生源に、時間的あるいは距離的に近いゲー ム端末 1には、より不確定情報が発生したときと同じ内容が伝播し、時間的あるいは 距離的に遠いゲーム端末 1には内容の不明確さが増した内容が伝播するという効果 がある。正確度を減らす主体は、送信側、受信側のゲーム端末 1のどちらであっても よい。
[0064] 「送信限度回数」は、他のゲーム端末 1にデータエントリを送信可能な回数を示す。
「送信残数」は、「送信限度回数」を初期値として設定され、他のゲーム端末 1にデー タエントリを送信する度に 1ずつ減らされる。「送信残数」が 0になった情報は、それ以 上送信されない。
[0065] 「受信限度回数」は、受信可能な回数を示す数値である。ゲーム端末 1は、受信し たデータエントリを不確定情報 DBに格納するとき、数値を 1減らす。そして、受信回数 力 SOになった情報は、それ以上送信されない。「受信限度回数」、「送信限度回数」は 特に指定されない限り、所定の値、例えば、それぞれ 3回と決められている。入力によ り指定された場合は、その値が使用される。上記「送信限度回数」、「送信残数」、「受 信限度回数」は、データエントリが無限に拡散されることを防止するための転送回数 情報として機能する。次図にてその状況を説明する。
[0066] 図 6は、送信限度回数、受信限度回数、そして送信残数によって情報の拡散が有 限となることを説明する図である。送信限度回数 3回、受信限度回数 3回に設定され たデータエントリがあるとする。送信限度回数により、プレイヤ Aのゲーム端末 1からは 3台のゲーム端末 1にこのデータエントリを送信可能であり、それぞれプレイヤ B、 C、 Dのゲーム端末 1に送信する。 1回送信する度に、プレイヤ Aのゲーム端末 1に格納さ れた送信残数が 1減らされ、プレイヤ Dのゲーム端末 1にデータエントリを送信すると 送信残数が 0になるので、プレイヤ Aのゲーム端末 1からそれ以上他のゲーム端末 1 にこのデータエントリが送信されることはない。
[0067] プレイヤ Aから送信されたデータエントリがプレイヤ Bのゲーム端末 1に格納される 際、受信限度回数が 1減らされた値に更新される。プレイヤ Aからのデータエントリを 受信したプレイヤ Bのゲーム端末 1も又、他の 3台のゲーム端末 1にこのデータェント リを送信可能である。こうして、プレイヤ Bのゲ―ム端末力もプレイヤ E、 F、 Gのゲーム 端末 1へデータエントリが伝播する。
[0068] 同様に、プレイヤ B力も送信されたデータエントリがプレイヤ Eのゲーム端末 1に格 納される際、受信限度回数が 1減少した値に更新される。プレイヤ Eのゲーム端末 1 力もはプレイヤ H、 I、 Jのゲーム端末 1にデータエントリが送信され、受信限度回数が 1減少した値に更新される。プレイヤ H、 I、 Jのゲーム端末 1にデータエントリが格納さ れると、受信限度回数は 0となる。従って、ここでこのデータエントリの伝播は停止し、 これ以上この情報が広まることはなくなる。プレイヤ C、プレイヤ Dに伝播した情報に 関しても同じことが言える。
[0069] 送信限度回数 3回、受信限度回数 3回の情報は 27台の情報端末に伝播する。一 般化すると、 Xの y乗 (X :送信限度回数、 y :受信限度回数)台の情報端末に伝播する ことになる。これにより、情報を広める台数を予め制限することができる。つまり、スパ ムメールやチェーンメールに相当する迷惑行為を防止することができる。
[0070] 図 5Aに戻り、不確定情報 DB21のデータエントリに含まれるデータ項目の説明を続 ける。「種類」は、データエントリの種類を示す情報である。例えば、 0は、ライバルに 関するデータエントリを意味し、 1は、仲間に関するデータエントリを意味し、 2は、ゲ ームの進行状況に関するデータエントリを意味し、 3は、伝播によっても変化しないデ ータエントリを意味する。
[0071] ライバルに関するデータエントリは、あるプレイヤが別のプレイヤをライノ レとしてゲ ーム端末において設定する際に生成されるものである。仲間に関するデータエントリ は、あるプレイヤが別のプレイヤを仲間としてゲーム端末において設定する際に生成 されるちのである。
[0072] ゲームの進行状況に関するデータエントリは、プレイヤがゲームに設定されたチエツ クポイントに到達することで生成されるものである。伝播によっても変化しな 、データ エントリは、画定情報と呼ばれ、例えば、ゲームベンダが発表する公式な情報やプロ グラムに連動してゲーム内でイベントを発生させることを予告する情報がある。
[0073] 従って、上記例においては、「種類」が 3以外であれば、データエントリが伝播の過 程で変化し、「種類」が 3の場合、データエントリは変化しない。第一の実施形態にお いては、偽の情報がプレイヤにより確定情報として作成されることを防止するため、ゲ ーム端末 1で生成される情報はすべて「種類」が 3以外の不確定情報である。「種類」 力 S3であるデータエントリが生成される場合については第二の実施形態で説明する。 なお、種類は 4つに限られるものではなぐ本情報伝達方法の実行者が自由に設定 することが可能である。
[0074] こうして、「種類」を使用すれば、ゲーム大会予告や宣伝情報等の公式情報をもプ レイヤに伝播することが可能となる。そして、公式情報は内容が変更されないことが保 証される。例えば、広告主を募集し、広告をゲーム端末 1に伝播させることでゲーム ベンダがその広告料を新たな収益源とすることもできる。
[0075] 「イベントフラグ」は、ゲームプログラムと連動してゲーム内にイベントを発生させるの に使用されるフラグ情報であり、値が 1であればイベントの設定有り、 0であればィべ ントの設定無しを意味する。予めプログラムには、イベントフラグに対応して発生させ るイベントがコーディングされており、受信した情報にイベントフラグが設定されてい れば、対応するイベントがゲーム内で発生する。
[0076] [イベントデータベース]
図 7は、受信したデータエントリに応じて、ゲーム内に発生させるイベントの内容が 格納されたイベント DB28のデータ構成例である。図 7に示されるように、受信したデ ータエントリに含まれる文章コードと、その文章コードに対応するイベントの内容と、そ のイベントが発動されているかを示すフラグ情報である「オン'オフフラグ」が対応付け られて格納されている。
図 7の文章コードを、図 3の文章 DBにおいて検索すれば、プレイヤにイベントの内容 を提供するための不確定情報を特定することができる。
[0077] 例えば、図 5Aにおいて最後のデータエントリは、イベントフラグが 1であり、何らかの イベントを含んだデータエントリであることがわかる。今、その文章コードの値は 1001 である。ゲーム進行管理部 15は、受信したデータエントリに含まれる文章コードの値 で、図 3の文章 DB25と図 7のイベント DB28を検索し、表示部 12を介してプレイヤに、 「今月中に対戦で 5連勝するとレアアイテム力 Sもらえるらしい」という不確定情報を提供 する。
[0078] 表示部 12に表示し、プレイヤがデータエントリを確認した後、ゲーム進行管理部 15 は、「情報取得月内に他のプレイヤに 5連勝すれば、ゴールドメダルというレアアイテ ムを与える」 t 、うイベントを発生させ、図 7の「オン'オフフラグ」を ONに変更する。
[0079] 図 5Aに戻り、「有効期限」は、データエントリが有効な期間や日付を示す情報であ る。有効期限の設定されたデータエントリは、発生してから一定期間を過ぎると無効と なる。無効なデータエントリはそれ以上送信されないので、データエントリの余計な拡 散を防止する効果もある。また、より多くのプレイヤにゲームに参加してもらうためのプ 口モーションとして期間限定のイベントを行う場合等に有効期限を設定したデータェ ントリを確定情報として伝播させ、ゲームに対するプレイヤの興味を引きつけてもよい
[0080] 「地域」は、データエントリの拡散範囲を示す情報である。例えば、都道府県単位と なる。地域は、ユーザ情報に含まれる「本拠地」(図 4参照)と合わせて活用される。例 えば、「地域」として東京都が選択されているとすると、「本拠地」が東京都に一致する プレイヤにだけ情報が伝播されるようにすることが可能である。こうして、特定の地域 内で拡散するデータエントリと全国規模に広がるデータエントリとを作成することがで きる。
[0081] [チェックポイントデータベース]
図 8は、チェックポイント DB22のデータ構成例である。チェックポイント DBには、チェ ックポイントを特定する「チェックポイントコード」、「オン'オフフラグ」、「文章コード」、「 ワード」、「条件」が互いに関連付けられ格納される。プレイヤがゲーム内で「条件」に 記載された条件を満たせば、プレイヤがそのチェックポイントを達成したかどうかを示 すフラグ情報である「オン'オフフラグ」力 「ON」に切り替わる。
[0082] すると、到達したチェックポイントに関する不確定情報が生成されるが、その際「文 章コード」、「ワード」が参照される。なお、「ワード」に含まれる項目のうち、「主語」以 外には、項目ごとに対応する値力 コール記号で結ばれて格納され、その値が使用 される。「主語」は、ゲーム端末 1でプレイするプレイヤの名前(図 4のユーザ情報の「 名前」)が使用される。
[0083] 例えば、図 8にてチェックポイントコードが 001の場合、プレイヤ("タロウ"とする)が 狼を倒すことにより、オン'オフフラグが「ON」になり、文章コードが 501であり(図 3参 照)、ワードが、「主語、狼」であることから、 "タロウは変装して狼を騙したらしい"という 不確定情報のデータエントリが生成されることになる。こうして、プレイヤが「条件」を 満たす度に、チェックポイント DB22が更新され、不確定情報が生成される。
[0084] [通信履歴データベース]
図 9は、通信履歴 DB27のデータ構成例である。通信履歴 DB27には、ゲーム端末 1と過去に通信したことのある他のゲーム端末 1から送信されたユーザ情報力 抽出 された、プレイヤの名前(図 4の「名前」)と通信が行われた日時が格納される。通信日 時が記録されており、記憶容量に余裕がない場合、古いものから削除される。
[0085] [変更ノレ一ノレデータベース]
図 10は、データエントリをどのように変更するかが格納される変更ルール DBのデー タ構成例である。図 10の変更ルール DB23〖こは、受信したデータエントリに含まれる 文章コード(「受信した文章コード」)毎に、「正確度」の区分と、正確度がその区分に 含まれるときの文章コード(「変化後の文章コード」 )と、「変化後の文章コード」に対応 する定型文で使用される「ワードの項目」が格納される。図 10の「正確度」は、定型文 毎に予め設定される正確度基準値であり、受信したデータエントリの正確度が属する 区分に応じてデータエントリを変化させるかが決定される。
[0086] 図 10では、例えば、「受信した文章コード」が 003の場合、正確度が 60以上 80未 満になると、文章コードが 102に変更され、受信したデータエントリにて使用されてい たワードの項目の内、「場所」と「アイテム」を引き継!/、だ新たなデータエントリに変更さ れる。具体的には、「主語」(=プレイヤの名前)が「タロウ」、「場所」が「鬼ヶ島」、「ァ ィテム」が「巻物」であるとすると、変更前は、文章コードが 003あることから、 "タロウは 鬼ヶ島で巻物を手に入れたらしい"という不確定情報が、変更後は、文章コードが 10 2であることから、 "鬼ヶ島で巻物を手に入れた人間がいるらしい"と変更され、誰が手 に入れたのかが不明になる。
[0087] 更に正確度が 60未満になると、文章コードが 103となり、受信したデータエントリに て使用されていたワードの項目の内「アイテム」が引き継がれ、 "巻物を手に入れた人 間がいるらしい"と変更され、誰力 何処で手に入れたかが不明になる。こうして、不 確定情報がより不確定さを増すようにデータエントリが変更されていく。
[0088] [ワード候補データベース]
図 11は、データエントリを図 10とは別の方法で変更する際に使用される、ワード候 補 DB26のデータ構成例である。図 11には、「ワードの項目」毎に、データエントリに てその項目のワードを置換可能な候補(「置換後のワード」 )が複数対応して 、る。「 番号」は、「ワードの項目」を特定したとき、「置換後のワード」を特定するための識別 番号である。
[0089] 図 11の「ワードの項目」のうち、「主語とライバル」に対応する項目以外は、予めヮー ド候補 DBに格納される。「主語とライバル」は、図 9に示される通信履歴 DB27に格納 される通信相手の名前である。即ち、他のゲーム端末 1との通信が行われると、通信 履歴 DB27と共に、ワード候補 DB26の「主語とライバル」欄に、通信相手の名前が格 納される。
[0090] 図 11のワード候補 DB26は、文章コードはそのままで、ワードをいくつか置換してデ ータエントリを変更する際に参照される。例えば、文章コードが 001であり、その文章 コードの定型文に対応するワードとして、主語が「タロウ」、ライバルが「ノヽナコ」である データエントリが不確定情報 DB21に格納されているとする。正確度が所定の閾値未 満となったとき、不確定情報管理部 17は、受信したデータエントリの文章コードを、図 3の文章 DB25で検索し、使用されて!、るワードの項目を取得する。
[0091] ここでは、文章コード 001の定型文にて「主語」、「ライバル」が使用されることがわか る。次に、不確定情報管理部 17は、この項目から変更する項目を選択する。変更す る項目は、 1つでも複数でもよい。例えば、「主語」のみを変更する場合、図 5のワード 候補 DBの「ワードの項目」を「主語」で検索し、不確定情報管理部 17は、対応する複 数の「置換後のワード」から 1つワードを選択し置換する。
[0092] 上記の例で、図 11のワード候補 DBの「主語とライバル」の 4エントリから、「ダイスケ」
(番号 003)が選択されると、置換後のデータエントリは、文章コードはそのままで、ヮ ードが「タロウ、ハナコ」から「タロウ、ダイスケ」となり、 "タロウはダイスケをライバルと思 つて 、るらし!、"と!/、う不確定情報に変更される。
[0093] 以上に説明したゲーム端末の構成に基づいて、次に第一の実施形態におけるゲ ーム端末の動作を説明する。
[0094] 図 12は、第一の実施形態におけるゲーム端末の動作を説明するフローチャートで ある。本実施形態においては、制御部 14を、ゲーム進行管理部 15、ユーザ情報管 理部 16、不確定情報管理部 17として機能させるプログラムをゲーム端末にインスト ールすると、ゲーム端末 1に、チェックポイント DB22、変更ルール DB23、文章 DB25 、ワード候補 DB26、イベント DBがコピーされる。インストール時にコピーされるワード 候補 DB26は、そのプログラムに記録された初期データであり、ゲームの進行に伴つ て新たなデータ (不確定情報の交換を行ったプレイヤの名前や、ゲーム内で立ち寄 つた場所等)が追加される。
[0095] まず、不確定情報管理部 17は、不確定情報 DB21に不確定情報として伝播させる データエントリを蓄積する(Sl)。データエントリの蓄積は、そのゲーム端末において 生成された不確定情報が格納される場合と、他のゲーム端末から受信したデータェ ントリを格納する場合と 2種類ある。ステップ S1の処理は、不確定情報の生成時ゃデ ータエントリの受信時に割り込み処理され、データエントリの蓄積が完了すると元の処 理が再開される。また、不確定情報が生成される過程は複数種類存在し、その詳細 は図 13を用いて後述する。
[0096] 次に、不確定情報管理部 17は、送受信部 13を介してゲーム端末と通信可能な他 のゲーム端末が存在するかを判定する(S2)。もし、通信可能なゲーム端末がなけれ ば (S2No)、ステップ S1に戻り、通信可能なゲーム端末が通信圏内に移動するのを 待機する。
[0097] 自端末と通信可能なゲーム端末 (通信相手端末)があれば (S2Yes)、不確定情報 管理部 17は、自端末のユーザ情報 24と不確定情報 DB21のデータエントリを送受信 部 13に出力し、送受信部 13は、それらを通信相手端末に送信する(S3)。すべての データエントリを出力するのではなぐ個数やデータサイズで制限してもよい。
[0098] また、送受信部 13は、通信相手端末のユーザ情報を受信してユーザ情報管理部 1 6に出力し、ユーザ情報管理部 16は、ユーザ情報に含まれる通信相手端末のプレイ ャの「名前」(図 4参照)を通信履歴 DB27とワード候補 DB26の「主語とライバル」欄に 格納する。また送受信部 13は、通信相手端末力 データエントリを受信して不確定 情報管理部 17に出力する(同じく S3)。
[0099] ある特定のゲーム端末の通信可能圏内に複数のゲーム端末があっても、送受信処 理はその内の 1台に対して行われる。 1対 1の送受信処理が終了した後、通信可能圏 内にある別のゲーム端末ゲーム端末とその特定のゲーム端末との送受信処理が開 始される。従って、 1対 1の送受信処理が終了したとき、ゲーム端末が移動して、通信 可能圏内に他のゲーム端末が存在しなくなれば、送受信処理は終了する。
[0100] 不確定情報管理部 17は、受信したデータエントリの正確度を所定数減らした値に 更新する(S4)。 1回に減らす正確度 (所定数)は、予め決められた値 (例えば、毎回 20ずつ正確度を減らす)である力 データエントリ毎に異なる値、ゲーム端末毎に異 なる値とすることもできる。例えば、データエントリ毎に異なる値を減らす場合、図 5A に示された不確定情報 DBのデータ構成力 更に、図示しない「所定数」のデータ項 目を含み、受信したデータエントリ毎に、ゲーム端末 1が「所定数」に格納された値を「 正確度」から減らすことで実現できる。また、ゲーム端末 1の記憶部 20に予め所定数 を記憶しておき、ゲーム端末 1が、受信したデータエントリの「正確度」から記憶部 20 に格納された所定数を減らすことで、ゲーム端末毎に所定数を変えることができる。
[0101] そして、不確定情報管理部 17は、ステップ S4で更新された正確度を所定の閾値と 比較し、正確度が所定の閾値を下回った場合 (S5Yes)、受信したデータエントリに 対する変更処理を行う (S6) 0ステップ S6が済むと、ステップ S1に進み、不確定情報 管理部 17が、変更処理が行われたデータエントリを不確定情報 DBに格納する。ステ ップ S5において、正確度が所定の閾値以上であれば(S5No)、ステップ S1に進み、 不確定情報管理部 17が、受信したデータエントリをそのまま不確定情報 DBに格納す る。
[0102] ステップ S6における受信したデータエントリに対する変更処理は複数種類存在し、 その詳細は図 24を用いて後述する。またステップ S6において、所定の閾値をどのよ うに設定するかにするかは、データエントリの変更処理に応じて変わるのでこれも図 2 4にて説明する。
[0103] 続いて、不確定情報がデータエントリとして生成され、不確定情報 DB21に蓄積され る際のゲーム端末 1での動作例を説明する。これは、図 12のステップ S1に含まれる。
[0104] 図 13Aは、ユーザ情報の作成、更新に伴い不確定情報がデータエントリとして生成 される場合を説明するフローチャートである。ゲーム進行管理部 15は、表示部 12を 介してユーザ情報作成'更新画面を表示する(S101)。この画面では、ユーザ情報 のデータ項目(図 4参照)に対する値を入力することができる。そして、入力された値 は図 4に示されるユーザ情報 24として記憶部 20に格納される(S 102)。
[0105] 不確定情報管理部 17は、ユーザ情報 24の更新を定期的に監視し、ユーザ情報 2 4のデータ項目のうち、「ライバル」、「仲間」、「レアアイテム」が設定されたかを判定す る(S103)。ユーザ情報 24の更新力これら 3つの項目に対するものでない場合(S10 3No)、図 12のステップ S2に進む。
[0106] ユーザ情報 24の更新がこれら 3つの項目に対するものである場合、不確定情報管 理部 17は、データエントリを生成し不確定情報 DB21に格納する(S 104)。不確定情 報管理部 17は、ステップ S103で設定されたデータ項目をキーとして図 3の文章 DB2 5の「ワードの項目」を検索し、一致するエントリの「文章コード」を 1つ選択する。不確 定情報管理部 17は、「ライバル」が設定されれば「ライバル」で検索し、「仲間」が設定 されれば「仲間」で検索し、「レアアイテム」が設定されれば、「アイテム」で検索し、こ れらの項目と一致するか、主語との組になっているものを選択する。
[0107] 主語との組が含まれる理由は、ユーザ情報を確認すればプレイヤの名前が得られ るので、「主語」は自由に使用することができるためである。つまり、図 3のワードの項 目力 「ライバル」、「仲間」、「アイテム」、「主語、ライバル」、「主語、仲間」、「主語、ァ ィテム」となっているものの中力も選択が行われる。こうして、「文章コード」が決まる。
[0108] 「ワード」は、ステップ S1で入力された値が使用される。「正確度」は、初期値として 1 00が設定される。「送信限度回数」、「受信限度回数」は特に指定がないので、所定 の初期値 (例えば、 3回ずつ)が設定される。「送信残数」は、初期値として、「送信限 度回数」と同じ値が設定される。「種類」は、ここでは不確定情報を示す 0が設定され る。
[0109] 「イベントフラグ」は、選択された文章コードが図 7のイベント DBに含まれる場合は 1 力 そうでない場合は 0が設定される。「有効期限」、「地域」は、ここでは「設定なし」と 設定される。「ID」は、ユーザ情報のシリアル番号、日付、その日に生成した不確定情 報に基づいて作成される。こうして、 1つのデータエントリが生成され、不確定情報 DB 21に格納される。
[0110] 図 14は、図 13Aのステップ S101における画面例である。つまり、ユーザ情報 24が 作成 ·更新される際にゲーム進行管理部 15が制御する表示内容が描かれる。図 14 において、ゲーム端末 1に電源を入れると、まず、タイトルとメニューが表示される(画 面 61)。ここでは、「Aの冒険」という RPG(Roll Playing Game)とする。最初から開始す る場合メニュー 1 (新たに開始)を選択し、途中から再開する場合メニュー 2 (記録から 開始)を選択する。
[0111] メニュー 1が選択されると、ユーザ情報を新規に作成するための画面が表示される( 画面 62)。ここでは、プレイヤが操作するキャラクタに対する名前と、プレイヤが操作 するキャラクタに対する性別と、プレイヤが住んでいる都道府県 (本拠地)、ライノ レ 情報、仲間情報、取得済みのレアアイテムを入力する。「名前」の入力だけが必須で ある。
[0112] そして、入力が完了すると、ゲームが開始される(画面 63)。画面 61でメニュー 2を 選択した場合は、そのプログラムに対して既に登録された名前が表示され、プレイヤ がその中から名前を選択すると、選択された名前でプレイを中断した箇所力 ゲーム が再開される(画面 65)。画面 63には、ゲーム実行中に入力部 11を操作すること〖こ より呼び出されるゲーム内メニュー 141が表示され、「ユーザ情報表示」なる項目を選 択することにより、現在のユーザ情報 24が表示されることになる(画面 64)。
[0113] ゲームをプレイする時間が増えると、他のゲーム端末 1と不確定情報を交換する機 会が増えることで、他のプレイヤの情報が入手でき、ライバルや仲間の設定がしゃす くなる。また、自らのゲームも進行し、レアアイテムを入手する機会が増え、レアアイテ ムの設定がしゃすくなる。そのような場合、画面 63に示されるゲーム内メニュー 141 を呼び出し、ユーザ情報 24を更新することができる。そして、この更新に基づいて図 13 Aで述べたように不確定情報が生成される。
[0114] 図 15は、図 14の画面 63にて、「ユーザ情報更新」なる項目を選択した場合に表示 される画面例である。まず、更新したい項目を選択するメニューが表示される(画面 6 6)。例えば、ライバルを設定する場合、メニューで 3が選択され、ライバル入力画面に 切り替わる(画面 67)。「直接入力」を選択すると、画面 69が表示され、ライバルプレイ ャの名前を直接入力できる。
[0115] 「通信履歴から選択」を選択すると、画面 68が表示され、通信履歴 DB27に格納さ れた通信相手の名前が一覧表示され、この中からライバルが選択される。画面 68ま たは画面 69にてライバルの選択が完了すると、ライバルの設定が完了したことが表 示される(画面 70)。
[0116] 図 13に戻り、説明を続ける。図 13Bは、ゲームの進行に伴い、プレイヤが到達した チェックポイントに応じて不確定情報がデータエントリとして生成される場合を説明す るフローチャートである。
[0117] ゲームの進行に伴い、プレイヤがチェックポイント DBに格納された条件を満たすと、 プレイヤはチェックポイントに到達したことになり(S111)、ゲーム進行管理部 15は、 チェックポイント DB22 (図 8参照)にて該当するチェックポイントのオン ·オフフラグを「 ONJにする(S 112)。
[0118] 不確定情報管理部 17は、チェックポイント DB22の更新を定期的に監視し、オン'ォ フフラグが「ON」に切り替わったものがあるかを判定する(SI 13)。チェックポイント DB 22の更新が、オン'オフフラグの更新でない場合 (S113No)、例えば、新たなチエツ クポイントの追加や、文章コード等の変更である場合等には、図 12のステップ S2〖こ 進む。
[0119] チェックポイント DBの更新により、オン.オフフラグが「ON」に切り替わったものがある 場合、不確定情報管理部 17はデータエントリを生成し不確定情報 DBに格納する(S 114)。不確定情報管理部 17は、ステップ S3で「ON」に切り替わったチェックポイント コードの「文章コード」と「ワード」を、データエントリの「文章コード」「ワード」に設定す る。「ワード」に「主語」が含まれる場合、ユーザ情報力も得られるプレイヤの「名前」( 図 4参照)を格納する。その他の項目については、図 13Aの場合と同じであり説明は 省略する。こうして、 1つのデータエントリが生成され、不確定情報 DB21に格納される
[0120] 図 13Cは、プレイヤがデータエントリの各項目に対する値を直接入力して不確定情 報のデータエントリが生成される場合を説明するフローチャートである。ゲーム進行管 理部 15は、表示部 12を介して不確定情報入力画面を表示する(S121)。この画面 では、データエントリのデータ項目に対する値を入力することができる。そして、入力 された値は不確定情報管理部 17に与えられ、不確定情報管理部 17は、データェン トリとして不確定情報 DB21に格納する(S 122)。
[0121] 図 16は、図 13Cのステップ S1における画面例である。つまり、不確定情報がユー ザにより入力される際にゲーム進行管理部 15が制御する表示内容が描かれる。図 1 6では、まず不確定情報入力画面が表示される(画面 71)。これは、図 14の画面 63 にお ヽて、「不確定情報入力」なる項目を選択すると表示される画面である。
[0122] 画面 71には、プレイヤに定型文の選択を入力させる画面が表示され、プルダウンメ ニュー 161で表示された文章コードを変更すると、文章 DB25でその文章コードに対 応する定型文が枠 162に表示される。 [0123] 画面 71で定型文が決定すると、「文章コード」が確定し、ゲーム進行管理部 15は、 次にその定型文で使用される「ワード」を入力させる画面を表示する(画面 72)。ヮー ドの入力が済むと、「送信限度回数」、「受信限度回数」を入力させる画面を表示する (画面 73)。最後に、「有効期限」、「地域」を入力させる画面を表示する (画面 74)。 各画面で入力された値は、データエントリの対応する項目に格納され、「ID」はバック グラウンドで自動的に生成されるので、こうして 1つのデータエントリが生成され、不確 定情報管理部 17はデータエントリを不確定情報 DB21に格納する。
[0124] 以上に述べたデータエントリの蓄積処理によって、さまざまな種類の不確定情報が 生成されることになる。ユーザ情報に設定したライバル、仲間、レアアイテム等により 生成された不確定情報を受信したプレイヤは、他のプレイヤを探そうとする。仲間プ レイヤを発見できれば、それまで攻略できない相手に協力して挑むことができたり、ラ ィバルプレイヤを発見できれば、レアアイテムを見つけることができる力もしれないか らである。
[0125] チェックポイントに基づいて作成された不確定情報を受信したプレイヤは、例えば、 自分が未知の領域に他のプレイヤが到達した力もしれな 、と 、う噂を入手することで 、自分もそこで行きたい、そして何が起こるのか実際に確認したいという気持ちに駆ら れ、よりゲームを深く遊ぼうとし、ゲームに対する興味を長く保つことができる。また、こ れらの情報が攻略のヒントとなり、ゲーム初心者の助けとなることもある。
[0126] 次に、データエントリの送受信処理(図 12S3)について詳述する。
[0127] 図 17は、送受信処理を細分したステップを示している。まず、ゲーム端末は、通信 相手のゲーム端末からユーザ情報を取得し、そこに含まれるシリアル番号を抽出する (S301)。続いて、どちらのゲーム端末が先にデータエントリを送信するかを端末順 位として決定する(S 302)。
[0128] ステップ S302における端末順位は、データエントリに設定された優先度を基に決 定される。ここでは、データエントリの「種類」に割り当てられた数字の大きいものがより 優先度が高いデータエントリであるとする。そして、各ゲーム端末が不確定情報 DBに 格納されたすベてのデータエントリの優先度の合計値を算出し、その合計値を交換 する。 [0129] 合計値が大き!/、方が端末順位の高 、ゲーム端末である。ステップ S302にお 、て、 順位の高 、ゲーム端末が送信処理 (S303)、受信処理 (S304)の順で処理を行 、、 順位の低いゲーム端末は、受信処理 (S304)、送信処理 (S303)の順で処理を行つ て、送受信処理が終了する。図 17に示されているフローは前者を示したものである。
[0130] ステップ S302における端末順位の決定法としては、優先度の合計値ではなぐ優 先度の合計値を不確定情報 DBに格納されたデータエントリ数で割った平均値を使 用することもできる。または、最高位の優先度のデータエントリをより多く有するゲーム 端末 (例えば、「種類」が 3であるデータエントリ数がより多い方)を端末順位の高い端 末と決定してもよい。
[0131] 次に、送信処理(図 17S303)、受信処理(図 17S304)について詳述する。不確定 情報を含むデータエントリをゲーム端末間で伝播させるにあたり、一度受信したデー タエントリを再受信しない処理ゃ自端末が発生源のデータエントリが他のゲーム端末 を介して再び受信しな!、処理 (以上をまとめて禁ループバック処理と呼ぶことにする) を施す。これは、既読の不確定情報ゃ自端末が発生源であるデータエントリを再度 プレイヤに提示する必要はないこと、また、そのような再受信を許可すると、データェ ントリの内容が短時間の内に改変され、前に受信した情報との整合性が取れず、プレ ィャを混乱させる恐れがあることを防止するための処理である。
[0132] まず、送信処理を説明する。
[0133] 図 18Aは、シリアル番号を利用して禁ループバック処理を送信時に行うものである 。図 18Aの処理を行う場合、更に「転送履歴」というデータ項目が追加されたデータ エントリが使用される。どの送信処理が適用されるかは予め決定されるので、その決 定に合わせて適切なデータエントリを使用すればょ 、。
[0134] 図 18Aの処理を行う場合、データエントリを受信したゲーム端末は、自端末のユー ザ情報 24を参照して得られる(そのとき挿入された記憶媒体等により決定される)シリ アル番号と日時を受信したデータエントリの「転送履歴」に記録する。こうして、データ エントリの「転送履歴」を見れば、そのデータエントリの伝播の経緯を把握することが できる。
[0135] まず、不確定情報管理部 17が、これから送信しょうとするデータエントリを不確定情 報 DBから読み出し、そのデータエントリの「転送履歴」を参照する。そして、その「転 送履歴」に、ステップ S301で取得した相手ゲーム端末に関するシリアル番号が含ま れているかを調べる(S331)。そして、「転送履歴」にステップ S301で取得したシリア ル番号が含まれている場合 (S331Yes)には、送信を行わず (S334)、「転送履歴」 にステップ S301で取得したシリアル番号が含まれていない場合(S331No)には、そ のデータエントリを送信する(S333)。こうして、一度そのデータエントリを取得したプ レイヤが同じ情報を目にすることを防止でき、混乱を防ぐことができる。
[0136] し力しながら、重複するデータエントリであっても、所定時間を経過していれば再び プレイヤに提示することにしてもよい。過去に受信したことのあるデータエントリを、十 分な時間が経過して力も再度受信したとしても、プレイヤはそのデータエントリによつ て混乱することはなぐ逆にプレイヤに懐力しさを抱力せたり、忘れていた情報を思い 出させる効果をもたらすためである。例えば、そのデータエントリがきっかけとなって 注目されたゲーム内の町、人、イベント等の当時の状況をプレイヤは思い出したり、 現状に対する好奇心が生じ、プレイヤは再度ゲーム内を探索する力もしれない。
[0137] そこで、 S331Yesの場合、以前に同じデータエントリを受信していることになるが、 その前回の受信力も所定時間が経過しているかを判定するステップ(S332)を設け、 所定時間を経過している場合 (S332Yes)、そのデータエントリを送信するようにして もよい(S333)。ステップ S332において、所定時間が経過していなければ(S332N o)、まだ、プレイヤを混乱させる可能性が残されており、そのデータエントリの送信は 行わない(S334)。ステップ S332の所定時間は、例えば、 6ヶ月等と設定することが できる。
[0138] 送信するデータエントリが複数ある場合には、不確定情報管理部 17は、図 18Aの 処理を繰り返し行う。送信するデータエントリの個数や、選択は、データエントリに含ま れるデータ項目を利用して自由に設定することができる。従って、例えば、データェ ントリの「ID」に含まれる日付情報を利用して、最新のデータエントリを 10個送信する t ヽつた送信ポリシーをシステム設計者 (システム運営者)が制御できる。
[0139] 図 19は、図 18Aの処理を具体ィ匕した例を説明するための図である。端末 Aは、デ ータエントリを受信すると、そのデータエントリの「転送履歴」に現在端末 Aに挿入され ているソフト Aのシリアル番号と日時を記録する。
[0140] 転送履歴 191は、端末 Aがそのデータエントリを受信した際の「転送履歴」を表した ものである。転送履歴 191によって示されるデータエントリは、先頭に記述されたシリ アル番号力もソフト Xが発生源であることがわかる。そして、次のシリアル番号力ソフト Aであることから、発生源から直接ソフト Aが挿入された端末 Aに伝播されたデータェ ントリであることがわかる。
[0141] このとき、端末 Aが端末 Bと通信可能状態になり、データエントリの送信を行う場合、 端末 Aは端末 Bのユーザ情報を取得して、端末 Bに挿入されたソフトのシリアル番号 を抽出する(図 17ステップ S301)。そして、そのデータエントリの転送履歴に通信相 手ゲーム端末である端末 Bに挿入されたソフト Bのシリアル番号力 転送履歴 191に 記載されていないことから、端末 Aは端末 Bにこのデータエントリを送信する(図 18A ステップ S331No→S333)。
[0142] このデータエントリを受信した端末 Bは、端末 Bに挿入されているソフト Bのシリアル 番号と日付を「転送履歴」に記録する。転送履歴 192は、端末 Bがそのデータエントリ を受信した際の「転送履歴」を表したものである。
[0143] このとき、端末 Bが端末 Cと通信可能状態になり、データエントリの送信を行う場合、 そのデータエントリの転送履歴に通信相手ゲーム端末である端末 Cに挿入されたソフ ト Cのシリアル番号力 転送履歴 192に記載されていないことから、端末 Bは端末じに このデータエントリを送信する。
[0144] 転送履歴 193は、上記と同様にして、端末 Cがそのデータエントリを受信した際の「 転送履歴」を表したものである。このとき、端末 Cと端末 Aが通信可能状態になっても 、そのデータエントリの転送履歴に通信相手ゲーム端末である端末 Aに挿入されたソ フト Aのシリアル番号力 転送履歴 192に記載されているため、端末 Cは端末 Aにデ ータエントリを送信しない(図 18Aステップ S331Yes→S334)。
[0145] こうして、転送履歴に記載が残されたシリアル番号のソフトが挿入されたゲーム端末 に対しては、データエントリを送信しないようにすることができる。なお、図 19において 、端末 Cから端末 Aに送信する際、所定時間が経過済みかを判定し、経過していれ ば(図 18Aステップ S332Yes)、そのデータエントリを送信するよう処理しても構わな い。
[0146] 図 18Bに戻り、続いてイベントフラグを利用して禁ループバック処理を送信時に行う ものを説明する。図 18Bの処理は、イベントフラグが設定されたデータエントリに適用 が可能である。
[0147] まず、ゲーム端末は、通信相手ゲーム端末のイベント DBを取得する(S335)。そし て、不確定情報管理部 17が、これから送信しょうとするデータエントリを不確定情報 DBから読み出し、そのデータエントリの「イベントフラグ」を参照する。そして、その「ィ ベントフラグ」が ONであることを示す場合 (例えば、値 1が格納されている場合)、その データエントリの文章コードを使用して、ステップ S335で取得した通信相手ゲーム端 末のイベント DBの「オン'オフフラグ」の状態を確認する(S336)。通信相手ゲーム端 末のオン 'ォフフラグがオフであれば(S336No)、これから送信するデータエントリに 関するイベントが通信相手ゲーム端末にて未発生であることを意味するので、そのデ ータエントリは送信される(S333)。しかし、通信相手ゲーム端末のオン'オフフラグが オンであれば(S336Yes)、既に、通信相手ゲーム端末は、そのデータエントリを受 信済みで対応するイベントが発生済みであることを意味し、そのデータエントリは送信 されない(S334)。送信するデータエントリが複数ある場合には、不確定情報管理部 17は、図 18Bの処理を繰り返し行う。
[0148] 図 20は、図 18Bの処理を具体化した例を説明するための図である。イベント DB20 1はある時点での端末 Aのイベント DBの状態を抜き出したものである。端末 Aでは、 文章コードが 1001に対応するデータエントリを受信し、それに関連するイベントが発 生していることが、イベント DB201からわ力る。
[0149] このとき、端末 Aが端末 Bと通信可能状態になり、文章コードが 1001であるデータ エントリの送信を行う場合、端末 Aは端末 Bのイベント DB202を取得する(図 18Bステ ップ S335)。そして、端末 Bのイベント DB202で文章コードが 1001に対応するェント リの「オン'オフフラグ」がオフであることを確認すると、端末 Aは端末 Bにこのデータェ ントリを送信する(図 18Bステップ S336No→S333)。
[0150] 同様に、端末 Bが端末 Cと通信可能状態になり、このデータエントリの送信を行う場 合にも、端末 Bは端末 Cのイベント DB203を取得し、イベント DB203で文章コードが 1 001に対応するエントリの「オン'オフフラグ」がオフであることを確認すると、端末 Bは 端末 Cにこのデータエントリを送信する。
[0151] そして、端末 Cと端末 Aが通信可能状態になると、端末 Cは端末 Aのイベント DB20
1を取得し、イベント DB201で文章コードが 1001に対応するエントリの「オン'オフフ ラグ」がすでにオンであるため、端末 Cは端末 Aにデータエントリを送信しな!、(図 18
Bステップ S336No→S334)。
[0152] こうして、イベント DBの「オン ·オフフラグ」に応じてデータエントリの送信を行うことで
、既にデータエントリを受信してイベントが発生している場合には、データエントリが送 信されず、同じデータエントリの重複受信を避けることができる。
[0153] 次に、受信処理を説明する。
[0154] 図 21Aは、各データエントリを識別する ID (図 5A参照)を利用して禁ループバック 処理を受信時に行うものである。不確定情報管理部 17は、データエントリを受信する と、受信したデータエントリの「ID」と同じ IDを持つデータエントリが不確定情報 DBに 格納済みでないかを確認する(S341)。そして、まだ格納されていなければ(S341N o)、受信したデータエントリを不確定情報 DBに格納し (S343)、既に格納されていれ ば (S341Yes)、受信したデータエントリを破棄する(S344)。こうして、一度そのデー タエントリを取得したプレイヤが同じ情報を目にすることを防止でき、混乱を防ぐことが できる。
[0155] しかし、重複するデータエントリであっても、所定時間を経過していれば再びプレイ ャに提示することにしてもよい。この理由は、図 18A^テツプ S332の送信処理のとき と同じぐプレイヤに懐力しさを抱力せたり、忘れていた情報を思い出させる効果をも たらすためである。
[0156] そこで、 S341Yesの場合、以前に同じデータエントリを受信していることになるが、 その前回の受信力も所定時間が経過しているかを判定するステップ(S342)を設け、 所定時間を経過している場合 (S342Yes)、そのデータエントリを格納するようにして もよい(S343)。ステップ S342において、所定時間が経過していなければ(S342N 〇)、まだ、プレイヤを混乱させる可能性が残されており、そのデータエントリを破棄す る(S344)。ステップ S342の所定時間は、例えば、 6ヶ月等と設定することができる。 [0157] 受信するデータエントリが複数ある場合には、不確定情報管理部 17は、図 21Aの 処理を繰り返し行う。
[0158] 図 21Bは、シリアル番号を利用して禁ループバック処理を受信時に行うものである。
図 21Bの処理を行う場合も図 18Aの説明で紹介した「転送履歴」というデータ項目が 追加されたデータエントリが使用される。
[0159] まず、不確定情報管理部 17が、受信したデータエントリの「転送履歴」を参照する。
そして、その「転送履歴」に、受信端末のユーザ情報に含まれるシリアル番号が含ま れているかを調べる(S345)。そして、「転送履歴」に自端末のシリアル番号が含まれ ている場合 (S345Yes)には、受信したデータエントリを破棄し (S334)、「転送履歴」 に自端末のシリアル番号が含まれて 、な 、場合(S345No)には、自端末のシリアル 番号と日時を受信したデータエントリの「転送履歴」に記録すると共に、そのデータェ ントリを格納する(S343)。こうして、一度そのデータエントリを取得したプレイヤが同 じ情報を目にすることを防止でき、混乱を防ぐことができる。
[0160] し力しながら、重複するデータエントリであっても、所定時間を経過していれば再び プレイヤに提示することにしてもよい。そこで、 S345Yesの場合、以前に同じデータ エントリを受信していることになるが、その前回の受信力も所定時間が経過しているか を判定するステップ (S342)を設け、所定時間を経過している場合 (S342Yes)、そ のデータエントリを格納するようにしてもよい(S343)。ステップ S342において、所定 時間が経過していなければ (S342No)、まだ、プレイヤを混乱させる可能性が残さ れており、そのデータエントリを破棄する(S344)。ステップ S342の所定時間は、例 えば、 6ヶ月等と設定することができる。
[0161] 受信するデータエントリが複数ある場合には、不確定情報管理部 17は、図 21Bの 処理を繰り返し行う。
[0162] 図 22は、図 21Bの処理を具体ィ匕した例を説明するための図である。転送履歴 221 は、端末 Aがあるデータエントリを端末 Bに送信する際の転送履歴を表したものであ る。端末 Aは、転送履歴の先頭に記述されたシリアル番号カゝらソフト Xが発生源であ るデータエントリを、発生源力も直接受信し、自端末に挿入されたソフト Aのシリアル 番号と受信日付を記録したことがわかる。 [0163] 端末 Bは受信したデータエントリの「転送履歴」に端末 Bに挿入されたソフト Bのシリ アル番号が含まれて 、な 、ことから、端末 Bに挿入されて!、るソフト Bのシリアル番号 と日付を「転送履歴」に記録して、受信したデータエントリを端末 Bの不確定情報 DB に格納する(図 21Bステップ S345No→S343)。
[0164] 転送履歴 222は、端末 Bがそのデータエントリを端末 Cに送信する際の転送履歴を 表したものである。端末 Cは受信したデータエントリの「転送履歴」に端末 Cに挿入さ れたソフト Cのシリアル番号が含まれて!/、な!/、ことから、端末 Cに挿入されて!、るソフト Cのシリアル番号と日付を「転送履歴」に記録して、受信したデータエントリを端末 C の不確定情報 DBに格納する。
[0165] 転送履歴 223は、端末 Cがそのデータエントリを端末 Aに送信する際の転送履歴を 表したものである。端末 Aは受信したデータエントリの「転送履歴」に端末 Aに挿入さ れたソフト Aのシリアル番号が含まれていることから、そのデータエントリを破棄する( 図 21 Bステップ S 345 Yes→S 344)。
[0166] こうして、転送履歴に記載が残されたシリアル番号のソフトが挿入されたゲーム端末 に対しては、データエントリを受信しないようにすることができる。なお、図 22において 、端末 Cから端末 Aに送信する際、所定時間が経過済みかを判定し、経過していれ ば(図 21Bステップ S342Yes)、そのデータエントリを格納するよう処理しても構わな い。
[0167] 図 21Cに戻り、続いてイベントフラグを利用して禁ループバック処理を受信時に行う ものを説明する。図 21Cの処理は、イベントフラグが設定されたデータエントリに適用 が可能である。
[0168] まず、不確定情報管理部 17は、受信したデータエントリに含まれる文章コードを取 得し、 自端末のイベント DBでその文章コードに対応するエントリの「オン'オフフラグ」 を参照する(S346)。オン 'ォフフラグがオフであれば(S346No)、受信したデータ エントリに関するイベントは受信端末にぉ 、て未発生であることを意味するので、その データエントリは不確定情報 DBに格納されると共に、イベント DBにて対応するェント リの「オン.オフフラグ」がオンにされ、イベントが発動する(S347)。しかし、オン'オフ フラグがオンであれば (S346Yes)、既に、そのデータエントリを受信済みで対応する イベントが発生済みであることを意味し、そのデータエントリは破棄される(S344)。
[0169] 図 23は、図 21Cの処理を具体化した例を説明するための図である。イベント DB23 1はある時点での端末 Aのイベント DBの状態を抜き出したものである。端末 Aでは、 文章コードが 1001に対応するデータエントリを受信し、それに関連するイベントが発 生していることが、イベント DB231からわ力る。
[0170] このとき、端末 Aが端末 Bと通信可能状態になり、文章コードが 1001であるデータ エントリを端末 Bで受信する場合、端末 Bは自端末のイベント DB232を取得し、端末 Bのイベント DB232で文章コードが 1001に対応するエントリの「オン.オフフラグ」が オフであることを確認すると、このデータエントリを格納して、文章コードが 1001に対 応するエントリをオンに更新する(図 21Cステップ S346No→S347)。「オン'オフフ ラグ」がオンになったことにより、端末 Bにて文章コードが 1001に対応するイベントが 発生する。
[0171] 同様に、端末 Bが端末 Cと通信可能状態になり、このデータエントリを端末 Cで受信 する場合にも、端末 Cは自端末のイベント DB233を取得し、イベント DB233で文章コ ードが 1001に対応するエントリの「オン ·オフフラグ」がオフであることを確認すると、 端末 Cはこのデータエントリを格納する。
[0172] そして、端末 Cと端末 Aが通信可能状態になり、端末 Aでこのデータエントリを受信 する場合、端末 Aはイベント DB231で文章コードが 1001に対応するエントリの「オン 'オフフラグ」がすでにオンであるため、端末 Aはデータエントリを破棄する(図 21Cス テツプ S346No→S344)。
[0173] こうして、イベント DBの「オン'オフフラグ」に応じてデータエントリの受信を行うことで 、既にデータエントリを受信してイベントが発生している場合には、データエントリが送 信されず、同じデータエントリの重複受信を避けることができる。
[0174] また、以上の説明では、データエントリが重複して格納されるのを防止するため、不 確定情報 DBへの格納前に処理を行って!/、るが、ー且すべてのデータエントリを不確 定情報 DBに格納するものの、転送履歴、イベントフラグ等の設定に応じてプレイヤへ の表示を制限することもできる。その場合、図 21に示される受信時の処理において、 ステップ S343の「格納する」を「表示する」、ステップ S344の「破棄する」を「表示しな い」と読み替えた処理を表示前に行えばよい。他にも、所定の日時を過ぎていれば 表示しな!、と!/ヽつた設定も可能である。
[0175] 続いて、受信したデータエントリに対する変更処理について説明する。これは、図 1
2のステップ S6に含まれる。
[0176] 図 24Aは、変更ルール DB23に格納されたルールに基づき、データエントリの変更 が行われる場合を説明するフローチャートである。不確定情報管理部 17は、受信し たデータエントリの正確度を減らした結果所定の閾値未満になったとき、変更ルール
DB23に基づき、変更後の定型文の「文章コード」と「ワード」を決定する(S601)。
[0177] 例えば、図 10に示す変更ルール DB23において、受信したデータエントリの文章コ ードが 001であり、正確度が 60未満になった場合、文章コードは 100に変更されると 共にワードの項目として「ライバル」が引き継がれた不確定情報に変更される。
[0178] そして、不確定情報管理部 17は、受信したデータエントリの「文章コード」と「ワード」 を、ステップ S1で決定された「文章コード」と「ワード」に更新して(S602)、ステップ S 1に進み、不確定情報 DB21にそのデータエントリを格納する。上記例でいうと、図 10 の変更ルール DBに基づき、変更前、 "タロウはジロウをライバルと思っているらしい"と いう不確定情報に対応するデータエントリ(つまり、文章コードが 001、ワードが「タロ ゥ、ジロウ」である)力 変更後は、 "ジロウをライノ レと思っている人間がいるらしい"と いう不確定情報に対応するデータエントリ(つまり、文章コードが 100、ワードが「ジロ ゥ」である)となる。
[0179] 図 24Bは、定型文を別の定型文に変更して、データエントリの変更が行われる場合 を説明するフローチャートである。不確定情報管理部 17は、受信したデータエントリ の正確度を減らした結果所定の閾値未満になったとき、受信したデータエントリの文 章コードに対応する定型文で使用されるワードの項目を特定する(S611)。例えば、 受信したデータエントリの文章コードが 004であれば、図 3の文章 DB25を参照し、ヮ 一ドの項目として「敵、アイテム」が使用されて 、ることがわ力る。
[0180] 次に、不確定情報管理部 17は、ステップ S1で特定されたワードの項目と同じワード の項目を持つ定型文を文章 DBから選択する(S612)。すると、その定型文に対応す る「文章コード」が決定される。例えば、上記と同じ「敵、アイテム」をワードの項目とし て持つ定型文として、図 3の文章 DB25を参照すれば、文章コードが 006の定型文が 挙げられる。
[0181] そして、受信したデータエントリの「文章コード」を、ステップ S2で選択された定型文 の「文章コード」に更新して(S613)、ステップ S1に進み、不確定情報管理部 17は、 不確定情報 DB21にそのデータエントリを格納する。上記例でいえば、変更前、 "大 鬼を倒すと巻物が手に入るらしい"という不確定情報に対応するデータエントリ(つま り、文章コードが 004、ワードが「大鬼、巻物」である)が、変更後は、 "大鬼は巻物を 使うと倒せるらしい"という不確定情報に対応するデータエントリ(つまり、文章コード 力 ^006〖こ変更)となる。
[0182] 図 25は、図 24A,図 24Bのように定型文が別の定型文に変更される場合の画面例 である。不確定情報の収集は、例えば、ゲーム起動時に行われる(画面 71)。この場 合、ゲーム端末 1への電源投入時に付近に通信可能なゲーム端末 1がある力判定が 行われる(図 12S2)。そして、データエントリを受信すると、ゲーム進行管理部 15は、 その旨を表示する(画面 73)。ここでは、不確定情報のデータエントリを噂と表現し、 プレイヤに通知している。
[0183] 不確定情報の収集は、ゲームプレイ中に行うこともできる(画面 72)。例えば、図 14 の画面 63のゲーム内メニュー 141にて、「不確定情報取得」なる項目が選択された 場合に画面 72が表示される。画面 72にて、「はい」が選択されると、画面 73へ進む。
[0184] 図 25において、この先 2手に分かれて表示される力 左側の列が、データエントリの 変更前、右側の列が、ゲーム端末間をデータエントリが伝播する過程でデータェント リが変更された後の様子である。不確定情報のデータエントリを受信すると、受信日、 通信相手の名前、タイトルがリスト状に表示される(画面 74、画面 76)。そして、そのリ ストから確認したい不確定情報を選択すれば、その内容が表示される(画面 75、画 面 77)。図 25により、変更前と、変更後では、データエントリの文章コード、ワードの 変更に応じて、表示される文章が違うことがわかる。
[0185] 図 24に戻り、説明を続ける。図 24A、図 24Bは、定型文毎変更するものだが、図 2 4Cは、定型文で使用されるワードを置換して、データエントリの変更が行われる場合 を説明するフローチャートである。 [0186] 図 24Cでは、不確定情報管理部 17が、受信したデータエントリの正確度を減らした 結果所定の閾値未満になったとき、受信したデータエントリの文章コードに対応する 定型文を特定し、その定型文で使用されるワードの項目を選択する(S621)。例えば 、受信したデータエントリの文章コードが 501であれば、図 3の文章 DB25を参照し、 ワードの項目として「主語、場所、敵、アイテム」が使用されていることがわかり、ここで は、「場所」を選択する。
[0187] ワードの項目の選択は、例えば、不確定情報管理部 17が、乱数を発生させ、その 乱数をワードの項目数で割った余りを算出し、そのあまりに応じて対応する項目を選 択すればよい。上述した例では、項目数力 であるので、乱数を 4で割った余りが 0で あれば、「主語」を選択し、 1であれば、「場所」を選択し、 2であれば、「敵」を選択し、 3であれば「アイテム」を選択する。なお、ステップ S621において、不確定情報管理 部 17が、一度に置換するワードを複数個選択してもよい。
[0188] 次に、不確定情報管理部 17は、図 11のワード候補 DB26から、ステップ S621で選 択されたワード項目に対応する「置換後のワード」を選択する(S622)。例えば、図 1 1の「場所」に挙げられた 4つのワード候補 (鬼ヶ島、竜宮城、寒村、港町)の中から「 竜宫城」を選択する。ステップ S622での選択も、一例としてステップ S621で説明し た乱数による選択を行えばよい。そして、不確定情報管理部 17は、受信したデータ エントリのワードのうち、ステップ S621で選択されたワードの項目だけ、ステップ S62 2で選択された「置換後のワード」に置き換えてワードを更新し (S623)、ステップ S1 に進み、不確定情報 DB21にそのデータエントリを格納する。
[0189] 具体的には、変更前、 "タロウは鬼ヶ島で大鬼を倒して巻物を手に入れたらしい"と いう不確定情報に対応するデータエントリ(つまり、文章コードが 501、ワードが「タロ ゥ、鬼ヶ島、大鬼、巻物」である)が、変更後は、 "タロウは竜宫城で大鬼を倒して巻物 を手に入れたらしい"という不確定情報に対応するデータエントリ(つまり、ワードが「タ ロウ、竜宮城、大鬼、巻物」に変更)となる。
[0190] 図 26は、ワードが置換される場合の画面例である。最初画面 78に示される不確定 情報が、ゲーム端末間での伝播の過程で、画面 79→画面 80→画面 81のように変化 していく。図 26においては、「信憑性」という数字が表示されている力 これは、デー タエントリの「正確度」(図 5A参照)とは別に、ここでは一例として (受信限度回数 + 1) * 25により簡単に算出される数値である。この信憑性のような数字をプレイヤに参考 値として表示してちょい。
[0191] ここで、画面 79→画面 80においては、データエントリの内容は変更されないものの 、信憑性は減じられる。画面 81では、ワードの項目「アイテム」も置換され、より不確定 さが増している。
[0192] 図 24に戻り説明を続ける。図 24Dは、定型文で使用されるワードを一部伏字にして 、データエントリの変更が行われる場合を説明するフローチャートである。不確定情 報管理部 17は、受信したデータエントリの正確度を減らした結果所定の閾値未満に なったとき、受信したデータエントリの文章コードに対応する定型文を特定し、その定 型文で使用されるワードの項目を選択する(S631)。例えば、受信したデータエントリ の文章コードが 501であれば、図 3の文章 DB25を参照し、ワードの項目として「主語 、場所、敵、アイテム」が使用されていることがわかり、ここでは、「場所」を選択する。 ステップ S631での選択も、ステップ S621で説明した乱数による選択を行えばよい。 なお、ステップ S631において、不確定情報管理部 17が、伏字にするワードを複数個 選択してちょい。
[0193] 次に、不確定情報管理部 17は、その選択されたワードの項目に対応するワードの 一部を伏字に変換する(S632)。例えば、「場所」として「鬼ヶ島」という値が格納され ている場合、その 3文字のうち 2文字を伏字 (ここでは、米印として表示する)に変換す る。伏字にする文字数や位置は任意でよい。そして、不確定情報管理部 17は、受信 したデータエントリのワードのうち、ステップ S631で選択されたワードの項目だけ、ス テツプ S632で一部伏字に変換されたワードに置き換えてワードを更新し (S633)、ス テツプ S 1に進み、不確定情報 DBにそのデータエントリを格納する。
[0194] 具体的には、変更前、 "タロウは鬼ヶ島で大鬼を倒して巻物を手に入れたらしい"と いう不確定情報に対応するデータエントリ(つまり、文章コードが 501、ワードが「タロ ゥ、鬼ヶ島、大鬼、巻物」である)が、変更後は、 "タロウは※※島で大鬼を倒して巻物 を手に入れたらしい"という不確定情報に対応するデータエントリ(つまり、ワードが「タ ロウ、※※島、大鬼、巻物」に変更)となる。 [0195] 図 27は、ワードが一部伏字にされる場合の画面例である。最初画面 82に示される 不確定情報が、ゲーム端末間での伝播の過程で、画面 82→画面 83→画面 84のよう に変化していく。図 27においては、信憑性という数字が表示されている力 これは、 図 26に示されるものと同じである。画面 82では、画面 85より伏字の置換が進み、より 不確定さを増している。
[0196] 以上に説明したデータエントリの変更処理によって、受信したデータエントリの正確 度が所定の閾値を下回ると、別の定型文に対応する文章コードを選択したり、受信し たデータエントリに使用されるワードを一部置換したり、一部を伏字にすることによつ て、データエントリが不確定さをますように変更されていく。こうして、不確定情報の発 生源に時間的、空間的に近いゲーム端末には、ある程度正確な情報が伝達され、時 間的、距離的に遠いゲーム端末には、不明確さを増した情報が届けられる。こうして 、さまざまな不確定情報が真偽が定かでない状態で混在することになり、プレイヤの 不確定情報に対する好奇心を刺激し、よりゲームに対する興味を引き、かつ持続さ せることができる。
[0197] なお、第一の実施形態において、正確度は、例えば、初期値を 100とし、受信の度 に所定数 (例えば、 20)ずつ減らされる値として定義されるが、図 26において説明し た信憑性同様、転送回数情報(「受信限度回数」等)を基に算出される値としてもよ!、 。また、受信したデータエントリの変化の度合いに応じて算出される値でもよい。例え ば、データエントリの変化の過程で一部が伏字になる場合であれば、(伏字の数 Z文 章に含まれる文字数) * 100等として算出することができる。
[0198] 以上第一の実施形態によれば、情報端末間でデータエントリ(不確定情報)が伝播 される過程で、正確度が減っていき、正確度が所定の閾値未満の場合、データェント リが変更されるので、情報がより不確定なものとなり、それを取得した利用者がその情 報の真偽に非常に関心を持つことになる。そして、情報の真偽を確認すベぐ情報端 末で実行されるプログラムに対する興味を惹きつけることができる。また、データェン トリの正確度は、送信側の情報端末で減らされても、受信側の情報端末で減らされて ちょい。
[0199] プレイヤは不確定情報を入手することによって、例えば、そのプレイヤ自身がゲー ム内で行ったことのない場所に関するヒント (場所の存在や場所への行き方等)を入 手する。こうして、プレイヤが 1人では攻略しきれない場所まで到達することができ、ゲ ームをより深く楽しむことができる。また、自分もゲーム内でその場所へ行ってみょうと いう好奇心をプレイヤに抱力せることができ、ゲームをより長い時間遊んでもらえる効 果がある。また、他のプレイヤの進拔状況を不確定情報として入手する場合、他のプ レイヤに遅れを取りたくないプレイヤに対しゲームを遊ぶ動機付けを与える。また、ゲ ーム内でのライバルや仲間を設定でき、こうしたプレイヤを現実世界で探すと 、う行 動を動機付けることで、ゲームをより長く面白く楽しんでもらうことにつながる。また、こ うした現実世界でのプレイヤの行動に伴い、ゲーム端末が移動し、より不確定情報が 伝播しやすくなる。
[0200] また、図 5に示される不確定情報 DBに格納されるデータエントリに使用するデータ 項目に応じて、内容を変化させたくない情報 (例えば、メーカーが公式に発表する公 式情報等)を、内容を変化させる情報と合わせて伝達させたり、同じデータエントリが 情報端末間でループすることを防止したり、データエントリが拡散される範囲や回数、 有効期限を設定してデータエントリが無限に拡散されることを防止したり、ある期間だ け有効なデータエントリを作成してプロモーションやキャンペーン情報として使用する ことができる。
[0201] 次に、第二の実施形態の情報端末の動作について説明する。
[0202] 図 28は、第二の実施形態における情報伝達システムの構成図である。第二の実施 形態では、インターネット 7を介して、サーバ 6と複数の情報中継端末 8を接続し、サ ーバ 6に格納された不確定情報を、情報中継端末 8を介してゲーム端末 1に伝播さ せる。プレイヤは、情報中継端末 8に表示されるメニューを操作して、サーバ 6に不確 定情報の取得要求を送信する。そして、情報中継端末 8は、サーバ 6から送信される 不確定情報を、取得要求を送信したプレイヤのゲーム端末 1に転送するものである。
[0203] 第二の実施形態においては、サーバを利用することで、各ゲーム端末の不確定情 報を集中することができる。また、サーバは唯一データエントリが変化しない確定情報 をゲーム端末に配信することが可能な存在であり、プロモーション情報や、キャンべ ーン等の実行を可能にし、よりゲームを面白くすることができる。また、ゲーム端末の 構成および動作は第一の実施形態と同じであるので説明は省略する。
[0204] 図 29は、情報中継端末 8の構成を示すブロック図である。情報中継端末 8は、入力 部 31、表示部 32、送受信部 33、制御部 34、記憶部 40を有し、制御部 34は、表示 管理部 35、参加端末管理部 36を含む。本実施形態においては、表示管理部 35、 参加端末管理部 36は、制御部 34に備えられた図示省略された CPUにより実行され るプログラムモジュールである力 S、ハードウェア回路により実現することもできる。
[0205] 表示管理部 35は、情報中継端末 8を操作するための画面を表示部 32に表示し、 入力部 31を介してプレイヤより入力される命令を受け、その命令に応じた画面を出 力する。入力部 31は、例えば、情報中継端末 8に備えられた図示しないキーボード、 タツチパネル、ボタン等が該当し、表示部 32は、例えば、図示しない液晶画面が該 当する。入力部 31、表示部 32はプレイヤとのインタフェースとして機能する。
[0206] 参加端末管理部 36は、情報中継端末 8と通信可能なゲーム端末に関する情報が 格納される参加端末データベース (参加端末 DB) 41を管理する。参加端末管理部 3 6は、参加端末 DB41に格納されたゲーム端末 1のうち、情報中継端末 8の通信圏外 に移動したゲーム端末 1に関する情報を削除し、参加端末 DB41を最新の状態に更 新する。参加端末 DB41には、プレイヤのユーザ情報の他、情報中継端末 8がサー バ 6から送信された不確定情報を転送する際に必要なゲーム端末 1のアドレス( IPQnternet
Protocol)アドレス、 MAC(Media Access Control)アドレス等)が格納される。
[0207] 送受信部 33は、インターネット 7に接続されたサーバ 6、情報中継端末 8に集まるゲ ーム端末 1と通信する通信機能を有している。これは、情報中継端末 8に内蔵される か若しくは外付けされた通信アンテナを介して、無線通信機能により実現されてもよ いし、ゲーム端末 1とは無線通信を行い、サーバ 6とはケーブルで接続された有線通 信が行われてもよい。
[0208] 送受信部 33は、無線通信可能なゲーム端末 1がある場合、そのユーザ情報を取得 してアドレスと共に参加端末管理部 36に出力し、また、プレイヤが入力部 31を介して 入力する不確定情報の取得要求をサーバ 6に送信する。
[0209] 記憶部 40には、制御プログラム、参加端末 DB41、中継端末識別情報 42、その他 情報中継端末 8で行われる処理に必要なデータが格納される。記憶部 40は、例えば 、ノ ッテリーバックアップされた RAM、フラッシュロム、ハードディスク等の記憶手段で ある。中継端末識別情報は、例えば、情報中継端末 8がサーバ 6へゲーム端末のュ 一ザ情報等を送信する際に必要な情報中継端末 8のアドレス (IPdnternet
Protocol)アドレス、 MAC(Media Access Control)アドレス等)が格納される。
[0210] 図 30Aは、第二の実施形態におけるユーザ情報のデータ構成例である。第二の実 施形態においては、サーバが複数のゲームに関する不確定情報を提供するため、ゲ ーム端末が取得する不確定情報が、現在そのゲーム端末で実行中のゲームと無関 係である可能性がある。そこで、図 4に示すユーザ情報に含まれるデータ項目に加え て、ゲーム端末で実行中のゲームプログラムを特定する「ゲームタイトル」が設けられ る。
[0211] 図 4と重複する項目についての説明は省略する。「ゲームタイトル」により、各不確定 情報がどのゲームに関するもの力を特定することができ、ゲーム端末は、受信した不 確定情報が自端末で実行中のゲームと無関係なものである場合、受信した不確定情 報を破棄することができる。
[0212] 図 30Bは、第二の実施形態における参加端末 DB41のデータ構成例である。図 30 の参カロ端末 DB41には、図 30Aのユーザ情報に含まれるデータ項目に加えて、「IP アドレス」が含まれる。「IPアドレス」は、情報中継端末 8がゲーム端末 1からユーザ情 報を取得した際のパケットから取得される送信元 IPアドレスを記憶したものである。「IP アドレス」は、サーバ 6から送信される不確定情報をゲーム端末 1に転送する際に参 照される。
[0213] 図 31は、サーバ 6の構成を示すブロック図である。サーバ 6は、入力部 51、表示部
52、送受信部 53、制御部 54、記憶部 60、を有し、制御部 54は、表示管理部 55、認 証管理部 56、不確定情報管理部 57を含む。本実施形態においては、表示管理部 5 5、認証情報管理部 56、不確定情報管理部 57は、制御部 54に備えられた図示省略 された CPUにより実行されるプログラムモジュールである力 ハードウェア回路により 実現することちでさる。
[0214] 表示管理部 55は、サーバ 6を操作するための画面を表示部 52に表示し、入力部 5 1を介してサーバ管理者より入力される命令を受け、その命令に応じた画面を出力す る。入力部 51は、例えば、図示しないキーボードが該当し、表示部 52は、例えば、図 示しない液晶画面が該当する。入力部 51、表示部 52はサーバ管理者とのインタフエ ースとして機能する。
[0215] 認証情報管理部 56は、不確定情報の取得要求を送信した情報中継端末 8の認証 に使用する中継端末認証データベース(中継端末認証 DB) 63及び取得要求を行つ たプレイヤを認証するユーザ認証データベース (ユーザ認証 DB) 52を管理する。中 継端末認証 DB63には、予め入力部 51を介して、正規の情報中継端末 8を特定する アドレス(IPアドレス、 MACアドレス等)が蓄積される。
[0216] また、ユーザ認証 DB62には、予め、サーバ 6の不確定情報 DBに格納されたデータ エントリのダウンロードを許可するユーザのユーザ情報に含まれるシリアル番号(図 4 参照)が蓄積される。不確定情報の取得要求に対し、これらの DBに格納された情報 が照合され、不確定情報 DB61に格納されたデータエントリの送信が許可されるか判 断される。
[0217] 不確定情報管理部 57は、情報中継端末 8を介して受信する、ゲーム端末 1に格納 されたデータエントリに加え、入力部 51を介して入力される確定情報(図 5の「種類」 の説明を参照)と不確定情報を不確定情報 DB61に格納する。ここでの不確定情報 は、ゲーム端末間で伝播する過程で内容が変化するデータエントリ同様の形式で不 確定情報 DBに格納される。また、有効期限切れ等で不要になったデータエントリを 削除して、不確定情報 DB61を管理する。情報中継端末 8より情報の取得要求を受 信すると、不確定情報管理部 57は、要求の種類に応じて、不確定情報あるいは確定 情報、またはその両方を送受信部 53に出力する。
[0218] 送受信部 53は、インターネット 7に接続された情報中継端末 8と通信する通信機能 を有している。これは、サーバ 6に内蔵される力若しくは外付けされた通信アンテナを 介して、無線通信機能により実現されてもよいし、ケーブルで接続された有線通信が 行われてもよい。
[0219] 記憶部 60には、図示しない制御プログラム、ユーザ認証 DB62、中継端末認証 DB 63、不確定情報 DB61、その他サーバ 6で行われる処理に必要なデータが格納され る。記憶部 60は、例えば、バッテリーバックアップされた RAM、フラッシュロム、ハード ディスク等の記憶手段である。
[0220] 図 32は、第二の実施形態における不確定情報 DB61のデータ構成例である。サー バには複数のゲームプログラムに関する不確定情報が格納されるため、図 32の不確 定情報 DBには、第一の実施形態における不確定情報 DB (図 5)に含まれるデータ項 目に加えて、各不確定情報がどのゲームプログラムに関するものかを特定する「ゲー ムタイトル」が設けられる。図 5と重複するデータ項目に関する説明は省略する。
[0221] サーバが複数種類のゲームプログラムに関する不確定情報を格納する場合、図 30 A、図 32で説明するように、「ゲームタイトル」のデータ項目をユーザ情報、不確定情 報 DBで加える方法の他に、「ゲームタイトル」を追加せずに、不確定情報がどのゲー ムプログラムに関するものかを特定する方法もある。それには、シリアル番号を使用す る。
[0222] 図 33は、シリアル番号とゲームタイトルの対応関係が格納されるソフト管理テープ ルのデータ構成例である。ソフト管理テーブルは、サーバの記憶部 60に格納される。 予め、第二の実施形態においては、ゲームタイトル毎に割り振られるシリアル番号が 図 33に示される区分に従うよう(例えば、ゲームメーカ等により製品出荷時に)設定さ れており、従って、シリアル番号により、ゲーム端末で実行されるゲームプログラムを 特定することができる。各データエントリの「ID」には、シリアル番号が埋められており( 図 32参照)、ユーザ情報、不確定情報 DBにおいて、「ゲームタイトル」を設けることな ぐ使用中のゲームプログラムを特定することができる。
[0223] 図 34は、ユーザ認証 DB62のデータ構成例である。図 34では、サーバ 6に格納さ れた不確定情報 DBのデータエントリのダウンロードが許可されたユーザの「シリアル 番号」(図 4のユーザ情報参照)が格納される。
[0224] 図 35は、中継端末認証 DB63のデータ構成例である。図 35では、正規の情報中継 端末 8の IPアドレスが格納されるが、情報中継端末 8を一意に特定できる別の識別情 報が用いられてもよい。
[0225] 図 36は、第二の実施形態におけるサーバ 6と情報中継端末 8の動作を説明するタ ィムチャートである。第二の実施形態においても、ゲーム端末間での情報の伝播は 行われる力 それは、第一の実施形態に示したのと同じ動作であるため、ここでは情 報中継端末とサーバの動作を中心に説明する。
[0226] まず、サーバ 6では不確定情報 DBにデータエントリが蓄積される(S41)。サーバ 6 の不確定情報 DB61へのデータエントリの蓄積は、第一の実施形態におけるゲーム 端末 1へのデータエントリの蓄積と同様、サーバ 6において生成された不確定情報が 格納される場合と、情報中継端末 8を介してゲーム端末力 受信したデータエントリを 格納する場合と 2種類ある。前者については、図 13Cで説明した処理がサーバ 6の 不確定情報管理部 57により行われる。後者については、データエントリの受信時に 割り込み的にステップ S41が行われ、その後再び元の処理に制御が戻される。
[0227] 一方、情報中継端末 8では通信圏内のゲーム端末 1に関する情報が参加端末 DB4 1に登録される(S31)。送受信部 33 (情報中継端末)は、情報中継端末 8とゲーム端 末が互いに通信可能圏内に入ると送受信を行い、ゲーム端末 1からはユーザ情報( 図 30A参照)を含む IPパケットが情報中継端末 8に送信される。送受信部 33 (情報中 継端末)は、受信した IPパケットからユーザ情報と発信元アドレスを抽出して、参加端 末管理部 36に出力し、参加端末管理部 36は参加端末 DB41にそれらを格納する。 こうして、情報中継端末 8と通信可能なゲーム端末に関する情報が参加端末 DB41に 蓄積される。
[0228] 情報中継端末 8では、表示部 32を介してプレイヤが利用可能なサービスに対する メニューを表示管理部 35が表示しており、このメニュー画面をプレイヤが入力部 31を 介して操作することによって、情報中継端末 8は、自分のプレイするゲームに関する 不確定情報、確定情報の取得要求をサーバに送信する。そこで、表示管理部 35は、 入力部 31よりサーバ 6に格納された情報の取得要求が入力されたかを判定する(S3 2)。サーバ 6に格納された情報の取得要求が入力された場合、情報中継端末 8は、 入力された取得要求、参加端末 DB41に格納された要求元のゲーム端末 1のユーザ 情報と、そのゲーム端末 1の不確定情報 DBに格納されたデータエントリと、情報中継 端末 8の識別情報 42をサーバ 6に送信する(S33)。
[0229] サーバ 6では、サーバ 6に格納された情報の取得要求を受信すると(S42Yes)、そ の後受信するデータエントリを割り込み処理として不確定情報 DBに格納すると共に、 受信した識別情報に基づく情報中継端末認証を行う(S43)。ここでは、認証管理部 56が、受信したパケットに含まれる発信元 IPアドレスと一致する IPアドレス力 中継端 末認証 DB63に格納されている力否かを判定すればよい。一致する番号が格納され ていない場合 (S43No)、正規の情報中継端末 8を介して送信された情報取得要求 ではないため、エラー処理が行われる(S51)。ステップ S51のエラー処理では、例え ば、不正な情報取得を要求してきた情報中継端末 8の IPアドレス等がログとして記録 される。
[0230] ステップ S43で情報中継端末認証に成功すると(S43Yes)、次に、ユーザ情報に 基づくユーザ認証を行う(S44)。認証情報管理部 56は、受信したユーザ情報カもシ リアル番号を抽出し、ユーザ認証 DB62に格納されたシリアル番号に一致するものが あるかを検索する。一致するものがない場合は(S44No)、登録外のユーザによる取 得要求であり、エラー処理が行われる(S52)。ステップ S52のエラー処理では、例え ば、サーバ 6が情報中継端末 8に未登録エラーを通知し、情報中継端末 8が、ユーザ が未登録であることを表示部 32に表示し、更に、ユーザに登録を促す画面を表示す る。
[0231] ユーザ認証に成功すると(S44 Yes)、サーバ 6は取得要求に応じて情報を情報中 継端末 8に送信し (S45)、ステップ S42に戻り、情報中継端末 8からの他の取得要求 に備えて待機する。そして、情報中継端末 8は、サーバ 6より送信される情報を対応 するゲーム端末 1に送信し (S34)、ステップ S32に戻り、プレイヤ力もサーバ 6に格納 された情報の新たな取得要求が入力されるのを待つ。
[0232] また、図 36のフローチャートでは図示省略されている力 第二の実施形態において は、サーバが複数種類のゲームプログラムに関する不確定情報を提供する関係上、 ゲーム端末が受信する不確定情報が必ずしもそのゲーム端末で実行されるゲームに 関するものでない場合もありうる。そこで、ステップ S 34で送信される情報を受信する ゲーム端末において、受信する不確定情報の「ゲームタイトル」と、自端末のユーザ 情報に含まれる「ゲームタイトル」を参照し、一致しない場合には、その不確定情報を 破棄する処理を行ってもょ ヽ。
[0233] また、図 33で説明したように、「ゲームタイトル」を用いずに、シリアル番号によって 不確定情報がどのゲームプログラムに関するものかを特定する場合には、まずサー ノ が、ステップ S33で送信されるユーザ情報に含まれる「シリアル番号」から図 33に 示すソフト管理テーブルによりゲームタイトルを特定する。そして、ステップ S45で不 確定情報を送信する際に、サーバが、送信予定の不確定情報の「ID」から抽出される シリアル番号が、ゲーム端末で実行中の(特定された)ゲームタイトルにソフト管理テ 一ブルにて対応付けられる番号帯に含まれるものだけを情報中継端末に送信するよ うにしてもよい。「シリアル番号」に基づき、サーバが送信する不確定情報を制限する ことで、ゲーム端末が自端末で実行されるゲームプログラムと無関係な不確定情報を 受信することが防止される。
[0234] 図 37は、サーバ 6に格納された情報をゲーム端末 1にダウンロードする様子を説明 するための情報中継端末 8の画面例である。情報中継端末 8の表示部 32には、まず サービス提供対象のゲームタイトルが表示される(画面 371)。画面 371〖こは、情報中 継端末 8の名前と 4つのゲームタイトルが表示される。ここでは第二の実施形態を利 用するゲームとして、メニュー 1 (Aの冒険)が選択されるとする。すると、次に、「Aの 冒険」に対して提供中のサービス一覧が表示される(画面 372)。
[0235] 次に、サーバ 6に格納された情報をダウンロードするため、メニュー 5 (うわさ GET! )が選択される。すると、参加端末 DB41が読み出され、参加端末 DB41に格納された 「名前」(図 30参照)が表示される(画面 373)。この中から自分のプレイヤ名を選択す る。
[0236] 参加者の中には自分と同じプレイヤ名を持った人間がいることがある。その時のた めに、画面 373には詳細ボタンが用意されており、このボタンを押すとユーザ情報の 詳細を見ることができる。ユーザ情報にはシリアル番号が含まれるので(図 4参照)、 情報供給端末 2に表示されるシリアル番号と、自分のシリアル番号を比較することで 本人確認ができる。自分のシリアル番号は、情報端末 1にて確認可能である(図 14参 照)。
[0237] そして、プレイヤが選択されると、ダウンロードする情報を選択する画面が表示され る(画面 374)。ここでは、メニュー 1 (公式情報)が選択され、図 36のステップ S33の 処理が実行される。画面 373で選択されたプレイヤが「タロウ」であるとすると、情報中 継端末 8は、公式情報の取得要求、参加端末 DB41に格納された「タロウ」のユーザ 情報と、「タロウ」のゲーム端末 1の不確定情報 DBに格納されたデータエントリと、情 報中継端末 8の識別情報 42をサーバ 6に送信する。
[0238] サーバは、情報中継端末の認証を行い、「タロウ」のユーザ情報に含まれるシリアル 番号がユーザ認証 DBに登録されたユーザであるかによりユーザ認証を行 、、 V、ずれ も認証に成功すれば、サーバ 6の不確定情報 DBに格納されたデータエントリのうち「 種類」が 1 (図 5A参照)のデータエントリを情報中継端末 8に送信する。
[0239] 情報中継端末 8は、参加端末 DB41から「タロウ」に該当するエントリの「アドレス」を 参照して「タロウ」のゲーム端末の IPアドレスを取得し、サーバから受信したデータェ ントリを含み、その IPアドレスをあて先アドレスとするパケットを作成し、ゲーム端末に 送信する。
[0240] そして、ダウンロードが完了すると、完了画面が表示される(画面 375)。画面 374で 、メニュー 2を選択すれば、サーバ 6の不確定情報 DBに格納された情報のうち、「種 類」が 0 (不確定)であるデータエントリが送信され、メニュー 3を選択すれば、「種類」 に関係なくデータエントリが送信される。
[0241] また、画面 373で選択されるプレイヤ名と実際に情報供給端末に対し一連の操作 を行う人物が同一であるかを確認するために、画面 373と画面 374の処理の間に認 証処理を行ってもよ!ヽ。合わせて有料サービスを提供する場合課金処理を行うことも できる。
[0242] 図 38は、認証'課金処理の一例を説明する画面例である。図 37の画面 373の後、 情報供給端末 2には、認証用の番号 (認証コード)が表示される(画面 381)。これは 、認証管理部によりランダムに作成される番号である。そして、画面 373で選択された プレイヤのゲーム端末には、認証コードを入力する画面が表示される(画面 382)。
[0243] そして、プレイヤは画面 381に表示された認証コードをゲーム端末に入力する。入 力された番号は、情報中継端末 8に送信され、情報中継端末 8は、画面 381で表示 した認証コードと同じ番号が入力されていることを確認し、認証が完了する(画面 383 )。ゲーム端末力 受信した番号と、表示した認証コードが一致しなければ認証は失 敗し、情報のダウンロードは行われない。 [0244] また、画面 381の前段で現金の投入等の課金処理が行われた後でないと、画面 38 1が表示されないように設定すれば、課金処理と認証処理を一度に行うことができる。 この認証方法によれば、画面 383で自分が操作するキャラクタ以外を誤って選択して も、情報中継端末 81に表示される認証コードがわ力もな 、と認証に成功しな!、ので、 本人以外のプレイヤが認証される可能性は低 、。
[0245] こうして、第二の実施形態によれば、サーバに、データエントリが伝播の過程で変化 しない確定情報を格納し、確定情報をゲーム端末 (情報端末)に伝播させることがで きる。こうして、ゲームメーカが公式情報として発表する情報をゲーム端末にリアルタ ィムにしかも、適切なタイミングに伝播させることができる。また、情報中継端末を設置 することによる集客効果も期待できる。
[0246] そして、サーバでゲーム端末からの不確定情報を格納しておくことで、普段、近くに ゲームをするプレイヤがいないプレイヤが、情報中継端末を介してサーノくから不確定 情報をダウンロードし、全国力もの不確定情報を入手することができる。また、サーバ 6によってのみ確定情報を発生させることができるので、偽の確定情報が発生するこ ともない。確定情報として、期間限定のイベントをゲーム内、あるいは現実世界で開 催する告知をすることもでき、よりゲームの遊戯性を高めることができる。
[0247] なお、第二の実施形態において、ゲーム端末 1をサーバ 3に直接接続できるように して、情報中継端末 2を省略することも可能である。

Claims

請求の範囲
[1] 通信路を介して相互に情報交換可能に構成された複数の情報端末間で行われ る娯楽的情報伝達方法を実行するためのアプリケーションプログラムであって、前記 情報端末にそれぞれインストールされることによって、複数の文章生成用定型文が保 存されると共に、
前記複数の文章生成用定型文から選択される文章生成用定型文に、前記情報端 末に入力される、又は前記情報端末で発生するイベントに関連して選択される、言葉 を挿入することによって文章を生成するステップと、
前記生成された文章を前記通信路を介して他の前記情報端末に送信する送信ス テツプと、
前記他の情報端末において前記アプリケーションプログラムの実行により送信され た前記文章を前記通信路を介して受信するステップと、
前記受信した文章を変化させる力否かを判定する判定ステップと、
前記判定ステップにおいて、前記受信した文章を変化させない場合、前記受信し た文章を別の前記情報端末に転送する第一の転送ステップと、
前記判定ステップにおいて、前記受信した文章を変化させる場合、前記受信した 文章に含まれる第一の文章生成用定型文に対応付けられる第二の文章生成用定型 文を前記複数の文章生成用定型文から選択し、前記第一の文章生成用定型文を前 記第二の文章生成用定型文と入れ替えるか、又は、前記受信した文章に含まれる前 記挿入された言葉を、別の言葉もしくは記号と入れ替えることによって新しい文章を 生成し、前記生成された新 、文章を前記通信路を介して前記別の情報端末に転 送する第二の転送ステップとを有することを特徴とするアプリケーションプログラム。
[2] 他の情報端末力 受信したデータに含まれる転送回数情報および Zまたは受信 した文章の変化の度合いに基づき、受信した文章の正確度を算出するステップをさ らに有し、
前記保存された複数の文章生成用定型文のそれぞれには予め正確度基準値が定 義されており、
前記判定ステップにお 、て、前記算出された正確度の値を前記受信した文章に対 し予め設定される前記正確度基準値と比較する処理を行うことを特徴とする請求の 範囲 1記載のアプリケーションプログラム。
[3] 前記イベントが、前記情報端末で実行されるゲームの進行によって発生すること を特徴とする、請求の範囲 1または 2記載のアプリケーションプログラム。
[4] 前記情報端末は携帯端末であり、各情報端末は無線通信路を介して接続可能に 構成されており、一の情報端末が他の情報端末と通信可能な距離範囲に入ったとき 、前記送信ステップ又は前記第一の転送ステップ若しくは前記第二の転送ステップ を実行可能にするように構成された請求の範囲 1乃至 3のいずれかに記載のアプリケ ーシヨンプログラム。
[5] 請求の範囲 1乃至 4のいずれかに記載のアプリケーションプログラムがそれぞれ 実行される複数の情報端末に通信路を介して接続されたサーバであって、
前記複数の情報端末間で行われる娯楽的情報伝達の過程で変化しない確定的文 章が格納される記憶部と、
前記複数の情報端末の一の情報端末からの情報取得要求に応じて、前記記憶部 に格納される前記確定的文章を送信する制御部とを有することを特徴とするサーバ。
[6] 前記制御部は、
前記一の情報端末からの前記情報取得要求と共に、該一の情報端末が送信する 前記文章を受信して、前記記憶部に格納し、
前記一の情報端末とは異なる別の情報端末力 の前記情報取得要求に応じて、 前記確定的文章と共に、前記一の情報端末から受信した前記文章を該別の情報端 末に送信することを特徴とする請求の範囲 5記載のサーバ。
[7] 請求の範囲 1乃至 4のいずれかに記載のアプリケーションプログラムがそれぞれ 実行される複数の情報端末に通信路を介して接続されたサーバであって、
複数の文章生成用定型文が格納される記憶部と、
前記複数の文章生成用定型文から選択される文章生成用定型文に、前記サーバ に入力される、又は前記サーバで発生するイベントに関連して選択される、言葉を挿 入することによって文章を生成する機能と、前記生成された文章を前記通信路を介し て前記情報端末に送信する送信機能と、前記情報端末にお!、て前記アプリケーショ ンプログラムの実行により送信された前記文章を前記通信路を介して受信する機能と 、前記受信した文章を別の前記情報端末に転送する転送機能とを実現する制御部と を有することを特徴とするサーバ。
[8] 請求の範囲 1乃至 4のいずれかに記載のアプリケーションプログラムがそれぞれ 実行される複数の情報端末と、
前記情報端末に通信路を介して接続され、前記複数の情報端末間で行われる娯 楽的情報伝達の過程で変化しない確定的文章が格納される記憶部と、
前記複数の情報端末に含まれる一の情報端末力 の情報取得要求に応じて、前 記記憶部に格納される前記確定的文章を送信する制御部とを有するサーバとを備え る†青報システム。
[9] 前記サーバの前記制御部は、
前記一の情報端末からの前記情報取得要求と共に、該一の情報端末が送信する 前記文章を受信して、前記記憶部に格納し、
前記一の情報端末とは異なる別の情報端末力 の前記情報取得要求に応じて、 前記確定的文章と共に、前記一の情報端末から受信した前記文章を該別の情報端 末に送信することを特徴とする請求の範囲 8記載の情報システム。
[10] 請求の範囲 1乃至 4のいずれかに記載のアプリケーションプログラムがそれぞれ 実行される複数の情報端末と、
前記情報端末に通信路を介して接続されるサーバを備えた情報システムであって 前記サーバは、
複数の文章生成用定型文が格納される記憶部と、
前記複数の文章生成用定型文から選択される文章生成用定型文に、前記サー バに入力される、又は前記サーバで発生するイベントに関連して選択される、言葉を 挿入することによって文章を生成する機能と、前記生成された文章を前記通信路を 介して前記情報端末に送信する送信機能と、前記情報端末にお!、て前記アプリケー シヨンプログラムの実行により送信された前記文章を前記通信路を介して受信する機 能と、前記受信した文章を別の前記情報端末に転送する転送機能とを実現する制御 部とを有することを特徴とする情報システム。
PCT/JP2005/008368 2004-05-17 2005-05-06 情報伝達の過程で内容が変化する情報伝達方法および情報伝達システム WO2005111815A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2006513529A JP4697137B2 (ja) 2004-05-17 2005-05-06 情報伝達の過程で内容が変化する情報伝達方法および情報伝達システム
EP05737098A EP1755043A4 (en) 2004-05-17 2005-05-06 INFORMATION TRANSMISSION METHOD AND INFORMATION TRANSMISSION SYSTEM IN WHICH CONTENT IS CHANGED DURING THE INFORMATION TRANSMISSION PROCESS
US11/588,324 US7716053B2 (en) 2004-05-17 2006-10-27 Information transmission method and information transmission system in which content is varied in process of information transmission

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004-146053 2004-05-17
JP2004146053 2004-05-17

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/588,324 Continuation US7716053B2 (en) 2004-05-17 2006-10-27 Information transmission method and information transmission system in which content is varied in process of information transmission

Publications (1)

Publication Number Publication Date
WO2005111815A1 true WO2005111815A1 (ja) 2005-11-24

Family

ID=35394325

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/008368 WO2005111815A1 (ja) 2004-05-17 2005-05-06 情報伝達の過程で内容が変化する情報伝達方法および情報伝達システム

Country Status (6)

Country Link
US (1) US7716053B2 (ja)
EP (1) EP1755043A4 (ja)
JP (1) JP4697137B2 (ja)
KR (1) KR100851445B1 (ja)
CN (1) CN100520743C (ja)
WO (1) WO2005111815A1 (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8433375B2 (en) 2010-06-11 2013-04-30 Nintendo Co., Ltd. Portable information terminal, portable information system, and computer-readable storage medium having stored thereon portable information terminal control program
US8505008B2 (en) 2010-06-11 2013-08-06 Nintendo Co., Ltd. Portable information terminal having control for executing a task via dedicated access points, and method for controlling execution of a task in a portable information terminal via dedicated access points
US8700478B2 (en) 2010-05-31 2014-04-15 Nintendo Co., Ltd. Computer-readable storage medium, information processing apparatus, information processing system, and information processing method
JP2014520348A (ja) * 2011-06-24 2014-08-21 シーメンス プロダクト ライフサイクル マネージメント ソフトウェアー インコーポレイテッド 情報伝達のためのモデル化された物的環境
US8874037B2 (en) 2010-12-28 2014-10-28 Nintendo Co., Ltd. Communication system, computer-readable storage medium having stored thereon information processing program, information processing method, information processing apparatus, and information processing system
US8903934B2 (en) 2009-06-19 2014-12-02 Nintendo Co., Ltd. Data exchange in an information processing system
US8990299B2 (en) 2010-06-10 2015-03-24 Nintendo Co., Ltd. Information processing apparatus, method of controlling information processing apparatus, and recording medium storing control program
US9433861B2 (en) 2010-09-17 2016-09-06 Nintendo Co., Ltd. Computer-readable storage medium having information processing program stored therein, handheld terminal apparatus, system, information processing method, and communication system
US9450917B2 (en) 2009-09-09 2016-09-20 Nintendo Co., Ltd. Information processing system, apparatus, method and control program capable of executing efficient data communication dispensing with communication with once communicated partner
US9588748B2 (en) 2010-06-11 2017-03-07 Nintendo Co., Ltd. Information processing terminal, information processing system, computer-readable storage medium having stored thereon information processing program, and information processing method

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7789757B2 (en) * 2005-09-22 2010-09-07 At&T Intellectual Property I, L.P. Video games on demand with anti-piracy security
US8892645B2 (en) * 2006-12-08 2014-11-18 International Business Machines Corporation Method and system for selective sharing of flagged information in a group chat environment
US20080162489A1 (en) * 2006-12-29 2008-07-03 Nokia Corporation Apparatus and method for exchanging information between devices
JP5019897B2 (ja) * 2007-02-07 2012-09-05 任天堂株式会社 ゲームプログラムおよびゲーム装置
JP5240976B2 (ja) * 2007-02-16 2013-07-17 任天堂株式会社 ネットワークゲームシステム
JP4240509B2 (ja) * 2007-08-02 2009-03-18 株式会社コナミデジタルエンタテインメント ゲームシステム、端末機及びコンピュータプログラム
US8454441B2 (en) 2010-08-13 2013-06-04 Zynga Inc. Game-based incentives for location-based actions
US9713774B2 (en) 2010-08-30 2017-07-25 Disney Enterprises, Inc. Contextual chat message generation in online environments
US9552353B2 (en) * 2011-01-21 2017-01-24 Disney Enterprises, Inc. System and method for generating phrases
US8812356B1 (en) 2011-06-30 2014-08-19 Zynga Inc. Voting with your feet
US8608570B1 (en) 2011-06-30 2013-12-17 Zynga Inc. Enabling game features based on location-based actions
US9626689B1 (en) 2011-06-30 2017-04-18 Zynga Inc. Incentivizing location-based actions by groups
US8496532B1 (en) 2011-06-30 2013-07-30 Zynga Inc. Clan wars
US9220985B1 (en) 2011-06-30 2015-12-29 Zynga Inc. Providing virtual items based on location-based actions
US8556719B1 (en) 2011-06-30 2013-10-15 Zynga Inc. Linking virtual items to real-world items
US8292743B1 (en) 2011-06-30 2012-10-23 Zynga Inc. Changing virtual items based on location-based actions
US8870661B2 (en) * 2012-12-21 2014-10-28 Sony Computer Entertainment America Llc Cloud-based game slice generation and frictionless social sharing with instant play
US10303762B2 (en) 2013-03-15 2019-05-28 Disney Enterprises, Inc. Comprehensive safety schema for ensuring appropriateness of language in online chat
JP5676676B2 (ja) * 2013-04-08 2015-02-25 株式会社スクウェア・エニックス ビデオゲーム処理装置、及びビデオゲーム処理プログラム
JP2014236785A (ja) * 2013-06-06 2014-12-18 任天堂株式会社 情報処理装置、情報処理システム、情報処理プログラムおよび情報処理方法
US10503836B2 (en) 2015-04-13 2019-12-10 Equivalentor Oy Method for generating natural language communication
US10606828B2 (en) * 2017-10-19 2020-03-31 Jpmorgan Chase Bank, N.A. Storage correlation engine
US20190188955A1 (en) 2017-12-18 2019-06-20 Igt System and method for utilizing location-based analytics to provide gaming awards
JP7101735B2 (ja) * 2020-10-20 2022-07-15 株式会社スクウェア・エニックス 画像生成プログラム及び画像生成システム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002032305A (ja) * 2000-07-19 2002-01-31 Hitachi Kokusai Electric Inc メッセージ作成方法およびそれを用いた携帯端末
JP2002245203A (ja) * 2001-02-19 2002-08-30 Ricoh Co Ltd データ収集装置
JP2003085096A (ja) * 2001-09-12 2003-03-20 Nec Corp 電子メール作成方式

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4406475B2 (ja) * 1998-12-16 2010-01-27 任天堂株式会社 携帯型データ送受信端末装置及びそれを用いた携帯型通信システム
US6542750B2 (en) * 2000-06-10 2003-04-01 Telcontar Method and system for selectively connecting mobile users based on physical proximity
JP2002032605A (ja) 2000-07-18 2002-01-31 Sharp Corp 仲介装置および仲介プログラムを記録したコンピュータ読取可能な記録媒体
JP3818428B2 (ja) * 2000-09-21 2006-09-06 株式会社セガ 文字通信装置
US20020055835A1 (en) * 2000-10-26 2002-05-09 Carcoba Olivares Luis G. System and method for integrated communications, funds transfers, confirmation and e-commerce applications
JP3709423B2 (ja) * 2001-04-13 2005-10-26 繁幸 梨木 口コミ情報伝送装置、口コミ情報伝送方法、及び口コミ情報伝送プログラム
JP4479126B2 (ja) * 2001-06-05 2010-06-09 カシオ計算機株式会社 広告配信装置、広告配信方法、広告配信プログラム
US6756882B2 (en) * 2002-09-09 2004-06-29 Motorola, Inc. Method and controller for providing a location-based game associated with a plurality of mobile stations
JP3534344B1 (ja) * 2002-10-18 2004-06-07 コナミ株式会社 ゲームプログラム及びゲーム装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002032305A (ja) * 2000-07-19 2002-01-31 Hitachi Kokusai Electric Inc メッセージ作成方法およびそれを用いた携帯端末
JP2002245203A (ja) * 2001-02-19 2002-08-30 Ricoh Co Ltd データ収集装置
JP2003085096A (ja) * 2001-09-12 2003-03-20 Nec Corp 電子メール作成方式

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1755043A4 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8903934B2 (en) 2009-06-19 2014-12-02 Nintendo Co., Ltd. Data exchange in an information processing system
US10086290B2 (en) 2009-06-19 2018-10-02 Nintendo Co., Ltd. Information processing system, information processing apparatus and information processing system control method, capable of providing, regardless of execution/non-execution of an application, data usable by the application to other information processing apparatus
US9089773B2 (en) 2009-06-19 2015-07-28 Nintendo Co., Ltd. Information processing system, information processing apparatus and information processing system control method, capable of providing, regardless of execution/non-execution of an application, data usable by the application to other information processing apparatus
US9450917B2 (en) 2009-09-09 2016-09-20 Nintendo Co., Ltd. Information processing system, apparatus, method and control program capable of executing efficient data communication dispensing with communication with once communicated partner
US9656173B2 (en) 2010-05-31 2017-05-23 Nintendo Co., Ltd. Computer-readable storage medium, information processing apparatus, information processing system, and information processing method
US8700478B2 (en) 2010-05-31 2014-04-15 Nintendo Co., Ltd. Computer-readable storage medium, information processing apparatus, information processing system, and information processing method
US8990299B2 (en) 2010-06-10 2015-03-24 Nintendo Co., Ltd. Information processing apparatus, method of controlling information processing apparatus, and recording medium storing control program
US8954118B2 (en) 2010-06-11 2015-02-10 Nintendo Co., Ltd. Portable information system
US9588748B2 (en) 2010-06-11 2017-03-07 Nintendo Co., Ltd. Information processing terminal, information processing system, computer-readable storage medium having stored thereon information processing program, and information processing method
US8433375B2 (en) 2010-06-11 2013-04-30 Nintendo Co., Ltd. Portable information terminal, portable information system, and computer-readable storage medium having stored thereon portable information terminal control program
US9832718B2 (en) 2010-06-11 2017-11-28 Nintendo Co., Ltd. Portable information terminal using near field communication
US8505008B2 (en) 2010-06-11 2013-08-06 Nintendo Co., Ltd. Portable information terminal having control for executing a task via dedicated access points, and method for controlling execution of a task in a portable information terminal via dedicated access points
US10296319B2 (en) 2010-06-11 2019-05-21 Nintendo Co., Ltd. Information processing terminal, information processing system, computer-readable storage medium having stored thereon information processing program, and information processing method
US9433861B2 (en) 2010-09-17 2016-09-06 Nintendo Co., Ltd. Computer-readable storage medium having information processing program stored therein, handheld terminal apparatus, system, information processing method, and communication system
US8874037B2 (en) 2010-12-28 2014-10-28 Nintendo Co., Ltd. Communication system, computer-readable storage medium having stored thereon information processing program, information processing method, information processing apparatus, and information processing system
JP2014520348A (ja) * 2011-06-24 2014-08-21 シーメンス プロダクト ライフサイクル マネージメント ソフトウェアー インコーポレイテッド 情報伝達のためのモデル化された物的環境
US9911257B2 (en) 2011-06-24 2018-03-06 Siemens Product Lifecycle Management Software Inc. Modeled physical environment for information delivery

Also Published As

Publication number Publication date
EP1755043A4 (en) 2011-08-10
US20070213975A1 (en) 2007-09-13
CN1954305A (zh) 2007-04-25
US7716053B2 (en) 2010-05-11
EP1755043A1 (en) 2007-02-21
CN100520743C (zh) 2009-07-29
JP4697137B2 (ja) 2011-06-08
KR100851445B1 (ko) 2008-08-08
KR20070014177A (ko) 2007-01-31
JPWO2005111815A1 (ja) 2008-03-27

Similar Documents

Publication Publication Date Title
JP4697137B2 (ja) 情報伝達の過程で内容が変化する情報伝達方法および情報伝達システム
JP3576994B2 (ja) ゲームサーバ、ネットゲーム進行制御プログラム及びネットゲーム進行制御方法
KR101130381B1 (ko) 인스턴트 메세징 서비스의 적어도 두 사용자에게 게임을 제공하는 방법, 인스턴트 메세징 시스템의 사용자들에게 게임의 프리미엄 버젼을 배포하는 방법, 및 컴퓨터 판독가능 저장 매체
RU2434295C2 (ru) Способ и система рекламы, сервер управления рекламой и мобильное устройство
KR100467413B1 (ko) 네트워크 게임 시스템 및 네트워크 게임 관리 방법
US20100022307A1 (en) Skill-Based Electronic Gaming Tournament Play
EP1621239A1 (en) Game system and game server
JP6090935B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP3822825B2 (ja) サーバシステム
JP5491573B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP2009511200A (ja) プレーヤのための望ましいマルチプレーヤ・ゲームを見つけるための方法及び装置
JP2004261202A (ja) ゲームシステム及びゲームサーバ
JP2003030368A (ja) ゲームサイト運営装置
JP2010104695A (ja) ゲームシステム及びゲームの制御方法
WO2013011849A1 (ja) コミュニケーション機能を備えたアミューズメントシステム
KR100721887B1 (ko) 정보 공급 단말기
JP3531676B1 (ja) データ配信システム
JP2003022341A (ja) ゲームサイト運営装置
JP2013165899A (ja) プログラム、ゲームシステム、ゲーム制御方法
JP2004229845A (ja) ゲームシステム及びゲームサーバ
CN107547492B (zh) 用于减少网络中断的影响的系统和方法
JP2003058451A (ja) ゲームサイト運営装置
JP4518739B2 (ja) 遊技システム
JP2005118282A (ja) 遊技店用管理システム
JP2003022396A (ja) ゲームサイト運営装置

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

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: 2006513529

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2005737098

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11588324

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1020067024024

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 200580015915.9

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWP Wipo information: published in national office

Ref document number: 1020067024024

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2005737098

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11588324

Country of ref document: US